Orbiter-Forum  

Go Back   Orbiter-Forum > Orbiter Addons > Addon Development
Register Blogs Orbinauts List Social Groups FAQ Projects Mark Forums Read

Addon Development Developers post news, updates, & discussions here about your projects in development.

Reply
 
Thread Tools
  #1  
Old
Artlav's Avatar
Artlav Artlav is offline
Aperiodic traveller

Default GenericVessel 140205, the SC3 open-source replacement
by Artlav 01-23-2014, 07:48 PM

Old thread: http://www.orbiter-forum.com/showthread.php?t=30362

As Face put it before:
Quote:
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.
Safe to use for add-ons.

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.
-No need to restart Orbiter each time for add-on makers. Change your INI in a text editor, open GV dialog in Orbiter, press "Reload", vessel gets updated to your changes.

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.

ADHD version:
Open-source SC3 remake, get it here: genericvessel-140205.zip
Try it with your or your favourite SC3 add-ons, report bugs, thus helping these add-ons survive the potential death of SC3.
To uninstall, reinstall SC3.

Last edited by Artlav; 10-04-2014 at 10:13 PM. Reason: Distribution version, updated links
Reply With Quote
Views 51463 Comments 129
Total Comments 129

Comments

Old 01-23-2014, 07:58 PM   #2
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

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?
Urwumpe is offline   Reply With Quote
Old 01-23-2014, 08:03 PM   #3
Loru
Moderator
 
Loru's Avatar


Default

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.
Loru is offline   Reply With Quote
Old 01-23-2014, 08:05 PM   #4
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by Urwumpe View Post
 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?

Quote:
Originally Posted by Loru View Post
 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 by Artlav; 01-23-2014 at 08:12 PM.
Artlav is offline   Reply With Quote
Old 01-23-2014, 08:12 PM   #5
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by Artlav View Post
 
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.
Urwumpe is offline   Reply With Quote
Old 01-23-2014, 08:17 PM   #6
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by Urwumpe View Post
 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.
Artlav is offline   Reply With Quote
Old 01-23-2014, 08:27 PM   #7
jedidia
shoemaker without legs
 
jedidia's Avatar
Default

Quote:
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?

Quote:
Why Lua specifically?
Because everyone loves a good Jigsaw puzzle
jedidia is offline   Reply With Quote
Thanked by:
Old 01-23-2014, 08:34 PM   #8
Urwumpe
Not funny anymore
 
Urwumpe's Avatar

Default

Quote:
Originally Posted by jedidia View Post
 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.
Urwumpe is offline   Reply With Quote
Thanked by:
Old 01-23-2014, 08:50 PM   #9
Donamy
Beta Tester


Default

GV doesn't seem to be looking for .inis in modules/server/config/spacecraft in D3D9 client.
Donamy is offline   Reply With Quote
Old 01-23-2014, 09:07 PM   #10
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 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.
Face is offline   Reply With Quote
Old 01-23-2014, 09:09 PM   #11
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 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)?
orb is offline   Reply With Quote
Old 01-23-2014, 09:14 PM   #12
Donamy
Beta Tester


Default

It does look for them in config/spacecraft, but regular SC3 looks in both.
Donamy is offline   Reply With Quote
Old 01-23-2014, 09:18 PM   #13
Face
Beta Tester
 
Face's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 It does look for them in config/spacecraft, but regular SC3 looks in both.
And which one takes precedence? The modules/server one?
Face is offline   Reply With Quote
Old 01-23-2014, 09:21 PM   #14
Artlav
Aperiodic traveller
 
Artlav's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 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?
Artlav is offline   Reply With Quote
Old 01-23-2014, 09:30 PM   #15
orb
O-F Administrator
Ninja
 
orb's Avatar

Default

Quote:
Originally Posted by Donamy View Post
 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).
orb is offline   Reply With Quote
Thanked by:
Reply

  Orbiter-Forum > Orbiter Addons > Addon Development


Thread Tools

Posting Rules
BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts
Forum Jump


All times are GMT. The time now is 10:11 PM.

Quick Links Need Help?


About Us | Rules & Guidelines | TOS Policy | Privacy Policy

Orbiter-Forum is hosted at Orbithangar.com
Powered by vBulletin® Version 3.8.11
Copyright ©2000 - 2019, vBulletin Solutions Inc.
Copyright 2007 - 2017, Orbiter-Forum.com. All rights reserved.