Project genericvessel - spacecraft3 and multistage2 replacement project

Just a quick comment: there's always room for script based add-ons, whatever interpreter is used. SC3 is only one of the, multistage is another, and now genericvessel does the same. Indeed it´s fast and a good starting point for custom development.

As for genericvessel I've only tested it casually but it works. At least no CTDs. :thumbup:
 
More joints in the robotics would be great !!!
 
More joints in the robotics would be great !!!

6 is what you need, 7 is luxury for having more configurations... but more than 7?
 
It's not just for a robot arm. With the robotics feature, I'm able to animate a whole astronaut, ankle bend, knee bend, waist bend and swivel, both arms from shoulder to wrist, with a visor and head turn to boot, all with a hand that can grab tools.
 
It's not just for a robot arm. With the robotics feature, I'm able to animate a whole astronaut, ankle bend, knee bend, waist bend and swivel, both arms from shoulder to wrist, with a visor and head turn to boot, all with a hand that can grab tools.

Have you ever prototyped that on a spacecraft3 RMS vessel before? I strongly suspect it wouldnt look right simulating the human body that way. And UMMU support is planned eventually...
 

Impressive stuff, particularly how you got the arm to rotate along its axis while raising. With regards to it being added, its obviously not my choice, but it would be nice to have. in a new SC3

I still prefer UMMU myself, and you cant really simulate a spacewalk perfectly with a SC3 (how does it ingress the shuttle?). I wonder though...

If we were to ask dansteph very nicely, maybe he could insert a little feature using this into UMMU. The feature would basically add a UMMU specialty class alongside Tech, capt, Sci, etc. When the UMMU is created at egress & vice versa at ingress, it would have your SC3 vessel spawned attached to it so we can have the best of both worlds. That would be pretty neat IMO.

I am a little confused about how you managed this though, is the start of the RMS at the feet working up? That would mean you can only animate one arm at a time right?
 
And UMMU support was here since the days this was called SC3->DLL converter :)

Indeed. However, I was unable to find the code that actually parses the crew settings from the INI. os_gen.pas fills the struct with one crew entry, but this entry's maxcrew is set to zero, so the linked vessel source is skipping the entry area definition, thus rendering the vessel inert regarding UMmu interaction.

So although the support is there, it is deactivated ATM, at least it seems so to me.
 
As a matter of fact, there never was an accepted INI format for the crew - you needed an external DLL editor or converter parameter to set that variable.

How about CREWCOUNT in the main section?

While we are at it, why did you punctured the layered architecture i laid in?
 
Impressive stuff, particularly how you got the arm to rotate along its axis while raising. With regards to it being added, its obviously not my choice, but it would be nice to have. in a new SC3

I still prefer UMMU myself, and you cant really simulate a spacewalk perfectly with a SC3 (how does it ingress the shuttle?). I wonder though...

If we were to ask dansteph very nicely, maybe he could insert a little feature using this into UMMU. The feature would basically add a UMMU specialty class alongside Tech, capt, Sci, etc. When the UMMU is created at egress & vice versa at ingress, it would have your SC3 vessel spawned attached to it so we can have the best of both worlds. That would be pretty neat IMO.

I am a little confused about how you managed this though, is the start of the RMS at the feet working up? That would mean you can only animate one arm at a time right?

Only one animation works at a time. Is that what you meant ?
 
Only one animation works at a time. Is that what you meant ?

Well, just that Ive never seen an RMS arm that forked. My guess on how youre doing that would be that youve set up the RMS to joint at the hips & shoulders of the astronaut. That should allow for animating one arm at a time, but not two. If you did one arm after another, the second arm would be dependent on the first, inevitably causing some weird behaviour.

By the way, I think Ive got it, why not include the attachment point for the UMMU turbopack on your SC3 spacewalker. That way, users can just grapple the animated suit to their UMMU while on EVA & dispose of it at the end of the spacewalk.

See this is what SC3 is really useful for. Anything that needs to be done quickly and edited quickly works great when its accessible through config files :)
 
Last edited:
As a matter of fact, there never was an accepted INI format for the crew - you needed an external DLL editor or converter parameter to set that variable.

How about CREWCOUNT in the main section?

I see. Well, as there are more parameters than just the count, I'd say a dedicated [UMMU] section would already make sense.

While we are at it, why did you punctured the layered architecture i laid in?

I'm just trying out an approach with the native INI parsing using the Windows infrastructure for it. The payload jettison was a welcome opportunity to get my hands dirty with it.

To be honest, I'm not very happy with the strict parser/module separation, now that I got to know your code base better. I miss the concept of object encapsulation in it.

Please don't see it as an affront, I respect your valuable work. I'm just trying out things in my branch. It is not like my repo is special in any way, that's the beauty in DVCS: you can always clone it, or simply branch off and do whatever you see as better way to do it. We can always merge things in to whatever branch we work on later on. That's why I've put up the two bookmarks "Artlav/master" and "Face/master".
 
Well, just that Ive never seen an RMS arm that forked. My guess on how youre doing that would be that youve set up the RMS to joint at the hips & shoulders of the astronaut. That should allow for animating one arm at a time, but not two. If you did one arm after another, the second arm would be dependent on the first, inevitably causing some weird behaviour.

By the way, I think Ive got it, why not include the attachment point for the UMMU turbopack on your SC3 spacewalker. That way, users can just grapple the animated suit to their UMMU while on EVA & dispose of it at the end of the spacewalk.

See this is what SC3 is really useful for. Anything that needs to be done quickly and edited quickly works great when its accessible through config files :)

Didn't you watch the video ? The arms move independently. It is two arms within an arm. Or am I confusing your meaning?

Unfortunatly it doesn't work when converted to .dll.
 
Didn't you watch the video ? The arms move independently. It is two arms within an arm. Or am I confusing your meaning?

Unfortunately it doesn't work when converted to .dll.

I did watch the video, I just cant figure out how you made it work like that.

But if it works who cares :)

Would you consider adding that UMMU grapple point & uploading it as an add-on? I would love to check this out.
 
Last edited:
There are two in my ISS A2Z addon. One with the ankles and knees with arms, and one with just the arms, but the wrists pitch and roll.
 
There are two in my ISS A2Z addon. One with the ankles and knees with arms, and one with just the arms, but the wrists pitch and roll.

Gonna go check. If I recall correctly, the only issue with SC3 RMS is that it needs a specific attachment Id to lock onto, correct?
 
Yes, the Child has to have a "GS" ID.
 
This doesn't seem to read the animation positions at scenario start up. Also, the animations should continue to the end, when you release the lshift before the keypad2/8
 
Back
Top