Project GenericVessel 140205, the SC3 open-source replacement

[Artlav]

Any reason your Universal Autopilot 0.3.1 would not work with GenericVessel?

In which way does it not work?
Specific vessel?
Specific program?
How to reproduce the issue?

Now, how does it work ? Spacecraft 3 is still required, no ? I'm a bit lost there. Do the new module somehow intercepts and transforms SC3 module data input/output ? :hmm:

Spacecraft 3 is not required, GV is a full reimplementation to be used instead of Spacecraft 3.

GV reads the INI definitions of SC3 vessels, and have to interpret them.
The devil is in the details there - how the uninitialized values are handled, how doing the tip animation without a type is handled, etc.

Usually if you have uninitialized parameters, you choose some reasonable defaults.
Problem is, it's tricky for me to tune in into what Vinka considered "reasonable".

 

[Mandella]

In which way does it not work?
Specific vessel?
Specific program?
How to reproduce the issue?

Sorry for the terrible bug report, but it happened with a custom vessel of my own construction. Tomorrow I will try to make the time to load the autopilot onto a stock craft in a clean environment. I was just asking first to see if there was a known issue.

Oh, and by not work I mean it showed up in the MFD just fine, took input, and appeared to run but aside from the main engines firing there was no control. Swapping back out with the old SC3 returned function to the autopilot.

Like I said, I'll do my best to be back with a better report tomorrow.

 

[4throck]

Good to see development on GV coming along.

I'm more than interested in switching from SC3 into something with more features. Time permitting, I'll setup an Orbiter install just for bug testing. :thumbup:

---------- Post added at 09:13 ---------- Previous post was at 09:07 ----------

Spacecraft 3 is not required, GV is a full reimplementation to be used instead of Spacecraft 3.

Artlav, perhaps GV should come with a backup folder containing the latest patched version of SC3.
I think that may prevent recurrent questions about how to get back to SC3.

 

[N_Molson]

I'm more than interested in switching from SC3 into something with more features.

And more importantly, something that is up-to-date with the current API.

 

[Donamy]

The tip movement is working great.

Three more issues if you would.

1. The animation sequences are not starting where the scenario has them set to, until you press the spacebar, then they snap into position.

2. Could you make it so that when you press and hold the Lshift button, then press the keypad number to start the animation, when you let go of the Lshift button before the keypad number button, the animation continues to the end, then stops. It makes it a lot better for long animations, even switching to a different vessel, while the animation continues to run for the first vessel.

3. When switching to another vessel, the robotic animation or attachment status screen should turn off. Now it stays on even after swiching to a new vessel.

 

[Artlav]

2. Could you make it so that when you press and hold the Lshift button, then press the keypad number to start the animation, when you let go of the Lshift button before the keypad number button, the animation continues to the end, then stops.

I was under impression that i already implemented this in 140126 ("Changed arm key handling to match SC3").
Is it still non-optimal or not working properly?

Artlav, perhaps GV should come with a backup folder containing the latest patched version of SC3.
I think that may prevent recurrent questions about how to get back to SC3.

Better, a link to this good SC3 version.
Packing SC3 along will add much more confusion that it could solve, i think (i.e. #39, only for real).

 

[Mandella]

Well, the good news is that loading up Greg Burch's LSTS221 in a more or less clean environment gave me no problem with the AutoPilot at all, so there is probably something wonky in my custom install.

(And speaking of your Universal AutoPilot, any chance you'll brush the dust off of it and continue development for a bit?)

However, I did find another bug. GenericVessel seems to be grabbing some of the wrong meshes for animations. Pressing shift-Num3 to extend the antennae also extends parts of the landing gear out into space.

Closing Orbiter and removing GenericVessel fixes the problem when the scenario is reloaded from save, but adding GenericVessel back in and reloading from current scenario actually makes the problem worse, with the attachments floating further out in space.

 

[Donamy]

I was under impression that i already implemented this in 140126 ("Changed arm key handling to match SC3").
Is it still non-optimal or not working properly?

Animation still stopping when releasing Lshift button before keypad number.

 

[Artlav]

Animation still stopping when releasing Lshift button before keypad number.

That is peculiar.

Just tried it with the Jason scenario you descried in #36 - press spacebar, press and hold Lshift, press and hold Num2 - the platform starts to slide, release Lshift - the platform continues to slide.

-Are we talking ARM animations or something else?
-Does it happen on a specific vessel?
-Are you sure it's actually 140126?
-Anything unusual with your keyboard (laptop, numlock on, etc)?
-Anything unusual in Orbiter setup (full-screen mode, D3D9Client, keymapping addons, etc)?

---------- Post added 28th Jan 2014 at 00:12 ---------- Previous post was 27th Jan 2014 at 23:56 ----------

Pressing shift-Num3 to extend the antennae also extends parts of the landing gear out into space.

No wonder.
Look into LSTS2201.ini:

[ANIM_COMP_5]
; Antenna Front 1
SEQ=2
GROUPS=
RANGE=(0.2,1)
TYPE=TRANSLATE
SHIFT=(2,0,0)
PARENT=4

Do you see the problem?
Defaults, assumptions, malformed input, poorly written vessels - all that must be handled, all that is the last 5% of compatibility that eat up 95% of effort.

Fixed.

I wonder, maybe i should make/add to GV an SC3 syntax checker?
For add-on developers's sake.

---------- Post added at 00:15 ---------- Previous post was at 00:12 ----------

And speaking of your Universal AutoPilot, any chance you'll brush the dust off of it and continue development for a bit?

I can backport changes and fixes accumulated by Spaceway, but there are not much new features - i still haven't mastered re-entry, interplanetary, from-orbit-landing, and so on autopilots.
And without them the tool is quite incomplete.

The only interesting new feature from Spaceway are presets - you say "get me into orbit", and it will compose a program on it's own that would do just that.
Not much use for it in Orbiter's hardcore-only community, however.

 

[Donamy]

Just tried it with the Jason scenario you descried in #36 - press spacebar, press and hold Lshift, press and hold Num2 - the platform starts to slide, release Lshift - the platform continues to slide.

But not when you release the second button.

Something for your UAP, would be multiple button presses in the tool, so animations for SC3 vessels can be used.

 

[Artlav]

But not when you release the second button.

Uh?
So, you release both buttons in the right order, and it should keep on going?
How do you stop it then?

If so, i'm not sure yet - that sounds like an SC3 bug, and it's not entirely clear how to recreate it.

Something for your UAP, would be multiple button presses in the tool, so animations for SC3 vessels can be used.

Sorry, i completely failed to parse this sentence.
Could you rephrase?

 

[Donamy]

Uh?
So, you release both buttons in the right order, and it should keep on going?
How do you stop it then
If so, i'm not sure yet - that sounds like an SC3 bug, and it's not entirely clear how to recreate it.

To stop it you press Lshift and the keypad button again, then release the keypad button first to stop it. Otherwise the animation just continues til it has completed.

Sorry, i completely failed to parse this sentence.
Could you rephrase?

As far as I know, UAP only accepts a single button, such as G to lower gear or K to open a door. Most animations for SC3 need the Lshift button to be activated with the keypad button.

 

[Donamy]

Also a little graphics I did.

 

[4throck]

I wonder, maybe i should make/add to GV an SC3 syntax checker?
For add-on developers's sake.

Please do. At the very least output it to a log file.
That would be very useful.

Perhaps you could add a parameter to the interpreter, in order to make it assume defaults or not. Like a GV strict / SC3 relaxed mode.

That way blame gets placed on the original badly written add-on, not in GV :lol:

 

[Artlav]

Version 140204 is out:
http://spaceway.1gb.ru/files/genericvessel-140204.zip (420Kb)

Changes:
-The Manual ( doc/genericvessel/genericvessel.pdf )
-Fixed defaults some more
-Fixed arm handling some more
-Fixed wrong arm attachment position after state load
-Fixed status for arm when changing focus

How do we distribute this?
Vinka's model was one SC3 per add-on, which can create a version hell.
I suggest that it's a good idea to restrict distribution to a single location - OH for example.
This way there will be no overwrites with different versions.

I expect the updates to be more frequent than SC3, and to be fully backwards-compatible, so that makes sense even more.

What do you think?

The manual
I've refubrished SC3 manual, and turned in into a GV manual.
It should describe what is currently supported.
It also describes the new sections, like UMMU one.

This means open season for new features.
Since they can now be documented.

Also, please check the manual for coherency - it's about 80% copy-paste.

Also a little graphics I did.

Je ne comprends pas...
Please give a step-by step reproduction of the issue, since attachment handling appear to work fine for me.

 

[Mandella]

How do we distribute this?
Vinka's model was one SC3 per add-on, which can create a version hell.
I suggest that it's a good idea to restrict distribution to a single location - OH for example.
This way there will be no overwrites with different versions.

I agree Orbit Hanger makes most sense, as it is where most of us go to download orbiter stuff, with perhaps a back up location on your own server for the times when Orbit Hanger is down.

Here is a thought that might be going too far. But since SC3 is outmoded now, what about putting a note in the spacecraft3.dll section of Orbit Hanger that SC3 is no longer supported and GV might be a better option?

 

[Urwumpe]

Here is a thought that might be going too far. But since SC3 is outmoded now, what about putting a note in the spacecraft3.dll section of Orbit Hanger that SC3 is no longer supported and GV might be a better option?

I think this is a task that a forum is better suited for. Why not have a simply sticky thread, which can also be found, that not only explains, that SC3 or spacecraft3.dll is obsolete, but also, which replacement(s) is available and how you can make old SC3 add-ons compatible?

 

[C3PO]

genericvessel.pdf p.9 UMMU Section

EVA_POS=(x,y,z) : EVA position​

EVA_ROT=(x,y,z) : EVA location

I'm guessing that "location" should be "orientation", right?

 

[Face]

How do we distribute this?
Vinka's model was one SC3 per add-on, which can create a version hell.
I suggest that it's a good idea to restrict distribution to a single location - OH for example.
This way there will be no overwrites with different versions.

I expect the updates to be more frequent than SC3, and to be fully backwards-compatible, so that makes sense even more.

What do you think?

AFAIK you can't restrict distribution on GPL'ed software. I'd instead suggest to add a version check feature, e.g. by offering (and checking) an optional compatibility key for developers to author into the vessel descriptions.

 

[4throck]

I suggest that it's a good idea to restrict distribution to a single location - OH for example.
This way there will be no overwrites with different versions.

Agreed, and add a note on the docs asking addon creators not to redistribute GV. That should be simple enough.