# Projectgenericvessel - spacecraft3 and multistage2 replacement project

#### Michael_Chr

##### New member
That is indeed a good explanation
Got it solved in the meantime. Rewrote the entire routine from bottom up and then it worked...must have made something wrong but dunno what...
I swear....Sometimes you feel that that code is just staring back at you in disapproval...You know that feeling? :lol:
Anyway...like genericvessel very much...Espacially the reload routine... And you guys manage to get some of vinkas old bugs in the proces.

#### Artlav

##### Aperiodic traveller
Beta Tester
Do you still have the broken code?
That is, can you reproduce the issue?

It might be something worth fixing, a parsing error perhaps.

I.e. ": === Animation Components ===" line looks suspicious in what you posted.

#### Michael_Chr

##### New member
Do you still have the broken code?
That is, can you reproduce the issue?

Whilst feverishly trying reproduce the "bug" I realized where the problem was. The problem was actually reading and understanding the GV manual:facepalm:. My goal was to try and use the new way of implementing a ship via a cfg file (called "the second way" in the manual). As the manual says:

Code:
The second way is to create a regular cfg, and put ClassName = genericvessel into it.
The module looks for vessel name first, and class name second.

I thought the way this worked was that you took an sc3 .ini file changed the file extension from .ini to .cfg and added the line ClassName = genericvessel into the top of it. Then it would parse the contents below in the .cfg file

But I now realized that the way it must work when working with .cfg files vs. genericvessel is that if you insert ClassName = genericvessel in the .cfg file it will parse the contents of the corresponding .ini file. I.e: if you have a cfg file called "myspacecraft.cfg" with the line "ClassName = genericvessel" as the only contents of that file then the module will parse the file "myspacecraft.ini" in the \config\spacecraft folder.

Hope that it correctly understood because that is what I experience (alltough a confirmation would be nice if anyone else in the future looks in here):thumbup:

In short terms...genericvessel works as advertized. And at that does a better job than the original SC3 and at least one major bug from SC3 that I am aware of has been cleared making what I want to do much more simple.

I think I will send you (Artlav) a suggestion for a rephrasing of that paragraph in the GV manual if you dont mind

#### Face

Beta Tester
I thought the way this worked was that you took an sc3 .ini file changed the file extension from .ini to .cfg and added the line ClassName = genericvessel into the top of it. Then it would parse the contents below in the .cfg file

But I now realized that the way it must work when working with .cfg files vs. genericvessel is that if you insert ClassName = genericvessel in the .cfg file it will parse the contents of the corresponding .ini file. I.e: if you have a cfg file called "myspacecraft.cfg" with the line "ClassName = genericvessel" as the only contents of that file then the module will parse the file "myspacecraft.ini" in the \config\spacecraft folder.

Actually that was true in the first versions of genericvessel. You could just rename the INI to a CFG and put the entries you mentioned into the first lines. Artlav removed this feature in his latest version, but it is rather easy to put it back in.

IMHO, there is no real reason to stick with the separate INI file approach (besides having it working additionally for legacy support), but if people really find it easier that way, so be it.

#### Artlav

##### Aperiodic traveller
Beta Tester
Hope that it correctly understood because that is what I experience (alltough a confirmation would be nice if anyone else in the future looks in here):thumbup:
The idea is that you make a cfg file with that content:
Code:
ClassName = myvessel
Module = genericvessel

Then genericvessel will look for myvessel.ini (not cfg_name.ini!)

"The module looks for vessel name first, and class name second." line is meant to read that GV checks the classic method of name-in-scn first, and then looks for ClassName ini file.

IMHO, there is no real reason to stick with the separate INI file approach
Separation.
Orbiter's approach to cfg files can just change into something incompatible.

Your way: Everyone need to rewrite their vessel's cfgs
INI way: Everything works as usual (since two-line cfg is almost certain to remain compatible)

No need to overentangle your implementation for minimal gains.

#### Face

Beta Tester
Separation.
Orbiter's approach to cfg files can just change into something incompatible.

Your way: Everyone need to rewrite their vessel's cfgs
INI way: Everything works as usual (since two-line cfg is almost certain to remain compatible)

No need to overentangle your implementation for minimal gains.

YAGNI. The chance that Orbiter's approach to cfg files will change into something incompatible in the foreseeable future is minimal, while the gains are a clear concentration of class definition into one file.

---------- Post added at 16:04 ---------- Previous post was at 13:43 ----------

I thought the way this worked was that you took an sc3 .ini file changed the file extension from .ini to .cfg and added the line ClassName = genericvessel into the top of it. Then it would parse the contents below in the .cfg file

So what do you think from the POV of a genericvessel user? Is it clearer to have the configuration inside the CFG file, or in a separated INI file? It is not like anything is set in stone here.

I can imagine having all 3 addressing systems probed in some order, but that might introduce complexity. That said, the "classical" SC3 way had flaws regarding multi-instance scenarios (where you want more than one instance of your vessel), so a name-based loading is a valuable extension of SC3, making it at least 2.

#### Urwumpe

##### Not funny anymore
Donator
YAGNI. The chance that Orbiter's approach to cfg files will change into something incompatible in the foreseeable future is minimal, while the gains are a clear concentration of class definition into one file.

But also SSoT. I think EAFP.

#### Michael_Chr

##### New member
So what do you think from the POV of a genericvessel user? Is it clearer to have the configuration inside the CFG file, or in a separated INI file? It is not like anything is set in stone here.

If I should make a requirement list for GV it would be:
1. Backwards capability - Scenarios with Legacy SC3 addons in them should be supported. SC3 still has so immense impact on the creator community that no direct support of old sc3 based scenarios must be a no-go.
2. .cfg support - The fact that you add multiple instances of same type using the scenario editor is also a clear winner. Makes it easier and much less failureprone to build scenarios in this way instead of doing the old trick of copying/renaming ini files and fiddle with the scenario in a texteditor.
3. Coding as simple as possible. Even if I cant code I know enough about it to realize that the more complex the code the more risk the enduser has not getting his stuff to work as expected. Therefore...if it can be done simple...make it simple. Will eventually make everyones life easier.

If these requirement are combined I think the answer is there. Given req. 1) there has to the classical inifile support meaning the ini files has to continue and if thats the case then given 3) To make it simple...both for coding and for end users to understand...then put all the vessel definitions in the ini file. During vessel construction...once the ini is build...then add a cfg with the two required line. Having the possibility of putting vessel definition in both ini and/or cfg is confusing to most. I think I demonstrated that myself today (see above).

Ini file for the vessel parameters and the two line cfg file for added support and only that. Its like both having your cake and eating it (If only Vinka had figured that out long ago).

The only thing is...This needs to be clearer in the manual... But will get back to that

Just my 2c

Last edited:

#### Face

Beta Tester
Having the possibility of putting vessel definition in both ini and/or cfg is confusing to most. I think I demonstrated that myself today (see above).

Hm. IMHO you demonstrated that you expected it to work within the CFG. With earlier genericvessel version, it would have just worked. That's the whole point of the discussion here.

But as I said, if people find it actually easier to make 2 files for their vessels instead of 1, that's OK. It sure fits the "added feature" view, like in "it works as usual, but you can add this here and then you can use it like any other vessel".

---------- Post added at 18:02 ---------- Previous post was at 17:50 ----------

If only Vinka had figured that out long ago

What makes you so sure that it was an actual oversight? Perhaps he knew it, but opted for ease of use.

After all, users "just" had to edit the scenario file and one INI to get their vessel to work. The name in the SCN and the name of the INI had to match, while the class name in the SCN addressed the generator "spacecraft".

To get a working set with the current 2-file approach, you need to edit the scenario file, one INI and one CFG. The class name in the SCN has to match both the INI and the CFG, while the CFG needs to address the generator "genericvessel" properly.

With the 1-file approach you do as you would with any regular Orbiter vessel class: create a CFG and address it in your SCN. The fact that the CFG file "gains" another syntax to configure the class is more or less transparent.

#### Donamy

Donator
Beta Tester
Has anyone thought of implimenting a second robotic arm ?

#### Donamy

Donator
Beta Tester
A big thankyou Face !!

One big thing that needs to be fixed, is the ability to have an animation continue to run, when you change to do a different animation. Now the first animation has to be completed, or stopped, when selecting another animation. SC3 was able to do this but GV does not. Some animations run a long time.

#### Face

Beta Tester
One big thing that needs to be fixed, is the ability to have an animation continue to run, when you change to do a different animation. Now the first animation has to be completed, or stopped, when selecting another animation. SC3 was able to do this but GV does not. Some animations run a long time.

Yeah, I've seen your discussion with Artlav about that. I too think that it was a bug in SC3, but I also think that genericvessel should not "fix" this for the sake of fixing alone, especially not if exploiting the bug was useful after all. Although genericvessel can't really reproduce the "bug", it should at least try to reproduce the "feature".

I'll see if I can do something about it.

#### Artlav

##### Aperiodic traveller
Beta Tester
AFAIR, i reproduced some of the animation bug-features, and couldn't think of a way to restore the others.

It might be a good idea to start from scratch.
What animation control interface would be good?
Not in terms of fixing the lack of old bugs that turned useful, but in terms of "holding the key all the time as it moves is boring, needs a way to latch it" and similar.

That is the only way i can see of succeeding at integrating all these bug-features.

Unfortunately, it's about as easy to do as to add multiple robotic arms - 10 minutes of coding, but no idea about interface and definitions.

#### Face

Beta Tester
Working on the multiple arm support, I've found that the legacy Atlantis RMS example supplied by vinka did not work anymore, because the mesh changed during the years. I've pushed a modification to the original SC3 SDK to make this work again with 2010P1.

For the additional arm sections, I'm working with the following definition at first:

• [ROBOTIC_ARM] defines the first arm as usual, but is optional.
• [ROBOTIC_ARM_X] defines additional arms, with X>1 (the default arm gets zero).
• TIP_1, TIP_2, TIP_3 in [ANIM_COMP_X] works as usual for the default arm.
• TIP_X_1, TIP_X_2, TIP_X_3, defines the grapple position for arm X.
• Arm control display gains another selection slot: the arm number. You can switch through the arms with SHIFT-Numpad7 and SHIFT-Numpad9.
So a question to all multiple arm requesters: is that what you had in mind? Could you perhaps contribute an example for multiple arms to the project, so I can test the implementation against your expectations?

#### Donamy

Donator
Beta Tester
Working on the multiple arm support, I've found that the legacy Atlantis RMS example supplied by vinka did not work anymore, because the mesh changed during the years. I've pushed a modification to the original SC3 SDK to make this work again with 2010P1.

For the additional arm sections, I'm working with the following definition at first:

• [ROBOTIC_ARM] defines the first arm as usual, but is optional.
• [ROBOTIC_ARM_X] defines additional arms, with X>1 (the default arm gets zero).
• TIP_1, TIP_2, TIP_3 in [ANIM_COMP_X] works as usual for the default arm.
• TIP_X_1, TIP_X_2, TIP_X_3, defines the grapple position for arm X.
• Arm control display gains another selection slot: the arm number. You can switch through the arms with SHIFT-Numpad7 and SHIFT-Numpad9.
So a question to all multiple arm requesters: is that what you had in mind? Could you perhaps contribute an example for multiple arms to the project, so I can test the implementation against your expectations?

I guess that would work. I was thinking of having my EVAguy with two working arms, that could also grab and hold items. A third "arm" could be the attachment for a tool. I can send you what you need.

#### Face

Beta Tester
I was thinking of having my EVAguy with two working arms, that could also grab and hold items. A third "arm" could be the attachment for a tool. I can send you what you need.

That would be great. Just be aware that by default I'd upload all content to the repository, making it released under GPL. If you don't want that, please state it, because I'd then have to keep on looking for an includable example (which of course would not make your example useless for testing!).

#### Donamy

Donator
Beta Tester
That would be great. Just be aware that by default I'd upload all content to the repository, making it released under GPL. If you don't want that, please state it, because I'd then have to keep on looking for an includable example (which of course would not make your example useless for testing!).

That would be fine.

#### Face

Beta Tester
I've finished implementation of the multiple arm support as outlined above: http://bitbucket.org/face/genericvessel/get/tip.zip . Documentation is updated, too.

Just be aware that this is basically a shot into the blue. As soon as I get some examples I'll test it, but of course feedback on this early version is also welcome.

#### Donamy

Donator
Beta Tester
Let me know if this looks correct. The three robotic animations work fine but there are no parent attachments. I may have the syntax wrong.

Code:
[CONFIG]
MESHNAME="EVAEMU2"
EMPTY_MASS=250
FUEL_MASS=60
MAIN_THRUST=0
ATTITUDE_THRUST=10
ISP=500
SIZE=5
FOCUS=1
CAMERA=(0,1,0)
VISIBLE=1

[PARENT_ATTACH_0]      ;Right hand
POS=(0.465,-0.053,-0.033)
DIR=(0,0,-1)
ROT=(0,1,0)
LOOSE=0
RANGE=0.5

[PARENT_ATTACH_1]      ;Left hand
POS=(-0.465,-0.053,-0.033)
DIR=(0,0,-1)
ROT=(0,1,0)
LOOSE=0
RANGE=0.5

[PARENT_ATTACH_2]      ;tool
POS=(0.263,0.195,-0.075)
DIR=(-1,0,0)
ROT=(0,1,0)
LOOSE=0
RANGE=0.5

[CHILD_ATTACH_0]	;to Foot Restraint
POS=(0.0,-0.89,-0.135)
DIR=(0,1,0)
ROT=(0,0,1)
LOOSE=0
ID="GS"

[CHILD_ATTACH_1]	;to COG
POS=(0.0,0,0)
DIR=(0,1,0)
ROT=(0,0,1)
LOOSE=0
ID="GS"

[ROBOTIC_ARM]
JOINT_0_NAME="ankle bend"
JOINT_0_SEQ=0
JOINT_0_RANGE=(-160,160)
JOINT_1_NAME="knee bend"
JOINT_1_SEQ=1
JOINT_1_RANGE=(-60,60)
JOINT_2_NAME="waist bend"
JOINT_2_SEQ=2
JOINT_2_RANGE=(-160,160)
JOINT_3_NAME="waist swivel"
JOINT_3_SEQ=3
JOINT_3_RANGE=(-100,100)
GRAP_SEQ=3
GRAP_ATTACH=2

[ROBOTIC_ARM(1)]
JOINT_0_NAME="left arm swing"
JOINT_0_SEQ=4
JOINT_0_RANGE=(-160,160)
JOINT_1_NAME="left arm raise"
JOINT_1_SEQ=5
JOINT_1_RANGE=(-60,60)
JOINT_2_NAME="left wrist roll"
JOINT_2_SEQ=6
JOINT_2_RANGE=(-90,90)
JOINT_3_NAME="left wrist pitch"
JOINT_3_SEQ=7
JOINT_3_RANGE=(-100,100)
GRAP_SEQ=7
GRAP_ATTACH=1

[ROBOTIC_ARM(2)]
JOINT_0_NAME="right arm swing"
JOINT_0_SEQ=8
JOINT_0_RANGE=(-160,160)
JOINT_1_NAME="right arm raise"
JOINT_1_SEQ=9
JOINT_1_RANGE=(-60,60)
JOINT_2_NAME="right wrist roll"
JOINT_2_SEQ=10
JOINT_2_RANGE=(-90,90)
JOINT_3_NAME="Right wrist pitch"
JOINT_3_SEQ=11
JOINT_3_RANGE=(-100,100)
GRAP_SEQ=11
GRAP_ATTACH=0

[ANIM_SEQ_0]	; ankle bend
INIT_POS=0.6
DURATION=6

[ANIM_SEQ_1]	; knee bend
INIT_POS=0.88
DURATION=12

[ANIM_SEQ_2]	; waste bend
INIT_POS=0.15
DURATION=6

[ANIM_SEQ_3]	; waste swivel
INIT_POS=0.5
DURATION=6

[ANIM_SEQ_4]	; left arm swing
INIT_POS=0.12
DURATION=6

[ANIM_SEQ_5]	; left Arm raise
INIT_POS=0.5
DURATION=6

[ANIM_SEQ_6]	;left wrist roll
INIT_POS=0.5
DURATION=4

[ANIM_SEQ_7]	;left wrist pitch
INIT_POS=0.5
DURATION=4

[ANIM_SEQ_8]	; right arm swing
INIT_POS=0.12
DURATION=6

[ANIM_SEQ_9]	; right Arm raise
INIT_POS=0.5
DURATION=6

[ANIM_SEQ_10]	;right wrist roll
INIT_POS=0.5
DURATION=4

[ANIM_SEQ_11]	;right wrist pitch
INIT_POS=0.5
DURATION=4

[ANIM_SEQ_12]	; visor
KEY=1
DURATION=6

[ANIM_COMP_0]  ; ankle bend
SEQ=0
GROUPS=1
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,-0.81,-0.138)
ROT_AXIS=(1,0,0)
ANGLE=45

[ANIM_COMP_1]  ; knee bend
SEQ=1
GROUPS=2
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,-0.381,-0.018)
ROT_AXIS=(1,0,0)
ANGLE=120
PARENT=0

[ANIM_COMP_2]  ; waist bend
SEQ=2
GROUPS=
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,0.14,-0.103)
ROT_AXIS=(1,0,0)
ANGLE=75
PARENT=1

[ANIM_COMP_3]  ; waist swivel
SEQ=3
GROUPS=3,5,6,7,8,9,10
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0,0.2,-0.124)
ROT_AXIS=(0,1,0)
ANGLE=60
PARENT=2

[ANIM_COMP_4] 	;visor
SEQ=12
GROUPS=4
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.0,0.754,-0.001)
ROT_AXIS=(1,0,0)
ANGLE=-85
PARENT=3

[ANIM_COMP_5] 	;left arm swing
SEQ=4
GROUPS=
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(-0.286,0.529,-0.037)
ROT_AXIS=(-0.973053,-0.136754,0.185654)
ANGLE=160
PARENT=3

[ANIM_COMP_6] 	;left arm raise
SEQ=5
GROUPS=11,12,13
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(-0.271,0.514,-0.043)
ROT_AXIS=(0.231807,-0.11855,0.965511)
ANGLE=-60
PARENT=5

[ANIM_COMP_7] 	;left wrist roll
SEQ=6
GROUPS=
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(-0.43,0.11,-0.08)
ROT_AXIS=(0,1,0)
ANGLE=160
PARENT=6

[ANIM_COMP_8] 	;left wrist pitch
SEQ=7
GROUPS=14,15,16
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.,0.05,-0.08)
ROT_AXIS=(1,0,0)
ANGLE=100
PARENT=7

[ANIM_COMP_9] 	;Right arm swing
SEQ=8
GROUPS=
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.286,0.529,-0.037)
ROT_AXIS=(0.973053,-0.136754,0.185654)
ANGLE=-160
PARENT=3

[ANIM_COMP_10] 	;right arm raise
SEQ=9
GROUPS=17,18,19
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.271,0.514,-0.043)
ROT_AXIS=(-0.231807,-0.11855,0.965511)
ANGLE=60
PARENT=9

[ANIM_COMP_11] 	;right wrist roll
SEQ=10
GROUPS=
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.43,0.11,-0.08)
ROT_AXIS=(0,-1,0)
ANGLE=180
PARENT=10

[ANIM_COMP_12] 	;right wrist pitch
SEQ=11
GROUPS=20,21,22
RANGE(0,1)
TYPE=ROTATE
ROT_PNT=(0.,0.05,-0.08)
ROT_AXIS=(1,0,0)
ANGLE=60
PARENT=11

[ANIM_COMP_13] 	;Right hand grab
SEQ=11
TIP(_2)_1=(0.465,-0.053,-0.033)
TIP(_2)_2=(0.465,-0.053,-1.033)
TIP(_2)_3=(0.465,-1.053,-0.033)
PARENT=12

[ANIM_COMP_14] 	;left hand grab
SEQ=7
TIP(_1)_1=(-0.465,-0.053,-0.033)
TIP(_1)_2=(-0.465,-0.053,-1.033)
TIP(_1)_3=(-0.465,-1.053,-0.033)
PARENT=8

[ANIM_COMP_15] 	;tool
SEQ=3
TIP_1=(0.263,0.195,-0.075)
TIP_2=(-1.263,0.195,-0.075)
TIP_3=(0.263,1.195,-0.075)
PARENT=3

Last edited: