# ProjectGenericVessel 140205, the SC3 open-source replacement

#### Artlav

##### Aperiodic traveller
Beta Tester

As Face put it before:
This project intends to create a generic framework for the Orbiter Space Flight simulator. It should enable users without C++ knowledge (or compilers) to create vessel add-ons that leverage as much as possible of the possibilities the Orbiter SDK offers. In this regards, it is similar to (and compatible with) the legacy frameworks spacecraft3 and multistage2.

Simply speaking, it's an open remake for spacecraft3.dll, with stretch goals of improving on top of it.

Current version is 140205.

Distribution version:
genericvessel-140205_safe.zip (223Kb)
This contains only GenericVessel itself, without replacing any SC3 files.

Testing version (replaces SC3 files, includes SC3 demos by Vinka):
genericvessel-140205.zip (262Kb)
This is configured as a drop-in replacement (overwrites SC3 cfgs), so most SC3 vessels will be running with GenericVessel after you install this.
To abort, just reinstall SC3 again (get it at at Vinka's site, or at https://bitbucket.org/face/genericvessel ).

Some vessels define SC3 on their own in cfg files, and would avoid such installation. You will have to edit their cfgs on your own.
Many SC3 vessels distribute SC3 with them, effectively uninstalling GenericVessel. Be aware.

Loose list of changes since the last thread:
-Support for launch/landing configurations
-Fixed RCS power and exhaust definitions
-Animation saved states are now matching SC3
-Fixed various input checking bugs (all the weird behaviour here and there)
-Fixed several animation logic issues
-Fixed vessel class/name detection in non-standard locations
(SC3: Check for name.ini, fail if not)
( GV: Check for name.ini, if not check for class.ini, if not fail)
-Added RCS and SURFACE disable keys (sort of)

140126:
-Fixed ARM animation issues when tip is poorly defined
-Fixed abnormal section definition glitch
-Changed arm key handling to match SC3

140204:
-Refubrished the manual
-Fixed some more defaults
-Fixed arm handling some more
-Fixed wrong arm attachment position after state load
-Fixed status for arm when changing focus

140205:
-Fixed animations firing while working arm
-Fixed arm joints limit

Why use GenericVessel?
-No limitations (SC3 allows 10 ships per scenario, 16 exhausts, 16 ports, etc)
-No name restrictions. Name your ship whatever you want, define module and class in cfg instead.
-Guaranteed to be compatible with next Orbiter version

What new features are already there?
-UMMU support. Just add [UMMU] section with airlock and crew definitions.

Backstory:
Act one.
Once upon a time i made an Orbiter Shipyard that produced DLL vessels from your mouse clicks, and thought it to be nice to have it be able to load SC3 vessels.
Some time later i thought, why not make a dedicated converter from SC3 to DLL, to go around the annoyance of naming restrictions in things like SSBB.
I asked Vinka, and he was cool with it.
The converter worked, albeit quite imprecise, and went obscure for lack of use.

Act two.
Enter Face.
He had the idea to make a generic framework akin to SC3, and i had an SC3->DLL converter.
Putting two together produced a largely functional, but incomplete blend of my SC3 implementation and his tweaks, that could be a drop-in replacement for SC3.
By that time Vinka was MIA for a while, and SC3 was showing it's age, so this was actually useful.
After some decaying hammering into shape it went somewhat obscure again, for lack of sufficient precision to meet the goals.

Act three.
Sometimes, even though you were looking straight at something, you didn't realize what you were looking at until you happened to think exactly the right thought.
At some point i realized that GenericVessel was made out of pieces that make Spaceway (my precioussss), and thus i had SC3 support in there for free.
This got me Really Interested in SC3 and getting my implementation into shape.
Many bugs died from the fallout.

Present days.
At this point i desynced from Face, and am for the moment working on my own.
It's easier for me to get this done working alone, since our code styles are about as compatible as thermite and ice.
From user point of view there is no difference.

Right now, the goal is to get GenericVessel as closely compatible to SC3 as possible.
Thus, making it a viable drop-in replacement for SC3.

First step is getting all the functional stuff.
Things that don't work are:
-PARTICLESTREAM_*
-TEXTURE_LIST
-SOUND
Everything else should work precisely as in SC3, or it's a bug.
This is what is being worked on right now.
You can help by testing your own or your favourite add-ons with GV, and reporting what went wrong (if any).

Second step is to get working all that is missing from the first.

Third step is to add multistage.dll support (which is the most aged one, that is already falling apart).

Then, extended mission would follow - maybe extend with things like UCGO, UMMU, etc, maybe turn it into SPSDK likeness - time will tell.

Open-source SC3 remake, get it here: genericvessel-140205.zip
To uninstall, reinstall SC3.

Last edited:

#### Urwumpe

##### Not funny anymore
Donator
Would it be possible to include a special Lua interface, that allows implementing event handlers for a generic vessel? Like for example a special key handler or maybe custom HUD painting?

#### Loru

##### Moderator
Donator
Quick testing shows animations are working correctly up to level 3 parenting. I couldn't turn off RCS in glass cockpit mode by clicking on "OFF button" in d3d9 client (R12).

---------- Post added at 10:03 PM ---------- Previous post was at 10:00 PM ----------

However this seems to be fixed after scenario reload.

#### Artlav

##### Aperiodic traveller
Beta Tester
Would it be possible to include a special Lua interface, that allows implementing event handlers for a generic vessel? Like for example a special key handler or maybe custom HUD painting?
Theoretically should be easy.
How should it work from the user side?
Why Lua specifically?

I couldn't turn off RCS in glass cockpit mode by clicking on "OFF button" in d3d9 client (R12).
Huh? That sounds completely unrelated to a specific vessel.

Last edited:

#### Urwumpe

##### Not funny anymore
Donator

Theoretically should be easy.
How should it work from the user side?
Why Lua specifically?

How it should work is hard to tell, I have no real idea yet, I just think it could be a good extension on what is already possible with spacecraft3

Maybe have the possibility to define your own script file for a vessel (not a script loaded by a scenario file) and have function variables in the script context, that can be overloaded or daisychained with new event handlers.

Like:

Code:
Me.clbkConsumeBufferedKey = function(key, pressed, kstate) ... end

Lua, because it is already included in Orbiter, pretty easy to learn and not a big library to include.

#### Artlav

##### Aperiodic traveller
Beta Tester
Maybe have the possibility to define your own script file for a vessel (not a script loaded by a scenario file) and have function variables in the script context, that can be overloaded or daisychained with new event handlers.
Sounds like i'd better look up how Lua is used in Orbiter.

The only way it would make sense in GV is if i could tap into Orbiter's own Lua OAPI, otherwise i'll have to re-implement everrrrything in Lua or suffer another paserscript.

If it is possible, then it is likely.

#### jedidia

##### shoemaker without legs
Would it be possible to include a special Lua interface

Hmmm... that seems kind of redundant. If you know LUA, you can already use it to make vessels for orbiter... what exactly would be the advantage of using GV instead of programming the thing directly in LUA?

Why Lua specifically?

Because everyone loves a good Jigsaw puzzle

#### Urwumpe

##### Not funny anymore
Donator
Hmmm... that seems kind of redundant. If you know LUA, you can already use it to make vessels for orbiter... what exactly would be the advantage of using GV instead of programming the thing directly in LUA?

That you
a) don't need to program everything in Lua.
b) can use spacecraft3 workflow and just extend this, if needed.
c) Can let things get handled by the fast C++ code and only if needed use the slightly slower Lua code.

#### Donamy

Donator
Beta Tester
GV doesn't seem to be looking for .inis in modules/server/config/spacecraft in D3D9 client.

#### Face

Beta Tester
GV doesn't seem to be looking for .inis in modules/server/config/spacecraft in D3D9 client.

Isn't this one of the bugs of SC3? Links/copies are necessary for it to work in D3D9 due to the orbiter_ng tactics of calling the orbiter.exe in that server directory, aren't they? I'd call it a bug-fix that this is not necessary anymore. EDIT: IF it works with standard directories, of course. I admit that I didn't check this here.

#### orb

GV doesn't seem to be looking for .inis in modules/server/config/spacecraft in D3D9 client.
Does it look for them in config/spacecraft instead (because that's where it should - looking for stuff relative to the path of the Orbiter executable being currently run, and not by the working path is actually a bug of some add-ons)?

#### Donamy

Donator
Beta Tester
It does look for them in config/spacecraft, but regular SC3 looks in both.

#### Face

Beta Tester
It does look for them in config/spacecraft, but regular SC3 looks in both.
And which one takes precedence? The modules/server one?

#### Artlav

##### Aperiodic traveller
Beta Tester
GV doesn't seem to be looking for .inis in modules/server/config/spacecraft in D3D9 client.
Huh?
And how in the world can they end up in there?

Fixing would be trivial, and i've checked that it works with D3D9 and regular location, but i'm just curious - how?

#### orb

It does look for them in config/spacecraft, but regular SC3 looks in both.
Is this a required "quirk" feature for some SC3 add-ons that would serve different configuration files for external graphics clients (not especially for D3D9, but any other)?

As a reminder, looking for stuff in modules/server is a bug because of using GetModuleFileName function in the add-on to get the path of the Orbiter directory, which isn't the case for non-graphics Orbiter executable (a better solution would be to use GetCurrentDirectory in the add-on to do the same, as this is how Orbiter finds its configuration anyway).

#### Face

Beta Tester
Is this a required "quirk" feature for some SC3 add-ons that would serve different configuration files for external graphics clients (not especially for D3D9, but any other)?

Well, if it really is so, genericvessel should also support it IMHO, even if it is a quirk feature. But then I wonder when vinka released that, because according to my researches (reflected in the historical commits in genericvessel repo) the last version was released in 2006. OVP's first SVN commit was in 2010.

I guess it is just the known bug, but then the fallback to the proper location even more astounds me.

#### Artlav

##### Aperiodic traveller
Beta Tester
Is this a required "quirk" feature for some SC3 add-ons that would serve different configuration files for external graphics clients (not especially for D3D9, but any other)?
A bug, a feature?
Fix or implement?
Make something better?

It might sound surprising, but i have next to no experience playing Orbiter with graphic clients.

Specifically, what add-ons are we talking about, and why would they want to "serve different configuration files" for the clients?

#### Loru

##### Moderator
Donator
This may be a bug. I load sc3 vessel via Config\Spacecraft\Spacecraft3.cfg containing this (one shipped with GV):
Code:
ClassName = Spacecraft3
Module = genericvessel

When I open Genericvessel dialog from F4/Custom menu , editor is empty. When I click on reload it CTDs Orbiter (both inline and d3d9 client).

---------- Post added at 12:12 AM ---------- Previous post was at 12:08 AM ----------

Would be nice if Editor dialog had load button for selecting ini file to spawn new GV vehicles.

#### orb

And which one takes precedence? The modules/server one?
The vessel simply doesn't load for SC3 with graphics client if its configuration isn't present in Modules/Server, nor it doesn't load the vessel if I copy orbiter.exe to .. and run Orbiter with "..\orbiter.exe" (but loads all stock vessels just fine), so it doesn't look in both locations, but only in a single one pointed by GetModuleFileName (which is a bug of the original SC3).