Orbiter 2010 + spacecraft3.dll + multistage2.dll

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,314
Reaction score
189
Points
63
Location
Code 347
Hi,
I'm just wondering how Vinka's modules "Spacecraft3.dll, Multistage2.dll & stage.dll" are working for other folks using Orbiter2010?

After a couple of quick tries, I'm happy to say that spacecraft3.dll seems to be working OK for me, although I haven't tried jettisoning any payloads yet.

Multistage2.dll also seems to be functioning OK (although I see a post on Dansteph's forum to the contrary, but no details)

The stage.dll (which handles the jettisoned stages from multistage2.dll vessels) is NOT working for me - no mesh is visible.

So I made myself a quick and dirty replacement "stage.dll" (.zip attached to this post) - it's a bit clunky but it'll do for me until Vinka, or someone, makes a proper one. C++ Code is included in the .zip for people to laugh or cry at.

For info, I'm running Windows XP, with VC++ 2003 and VC++ 2008 Express compilers installed.

Cheers,
Brian
 

Attachments

  • stage_dll_2010.zip
    27.4 KB · Views: 894

simcosmos

Addon Developer
Addon Developer
Joined
Mar 23, 2008
Messages
95
Reaction score
1
Points
8
Website
simcosmos.planetaclix.pt
[FONT=Arial, sans-serif]Thanks Brian![/FONT]


[FONT=Arial, sans-serif]I will have to wait for the weekend to at least try do do some preliminary tests with Vinka's generic dlls on Orbiter2010 (not sure if will be possible, else only in the other weekend)[/FONT]


[FONT=Arial, sans-serif]For the moment, and as also noted on...[/FONT]

[FONT=Arial, sans-serif]Multistage2 not fully functional[/FONT]
[FONT=Arial, sans-serif]http://www.orbiter-forum.com/project.php?issueid=115[/FONT]

… [FONT=Arial, sans-serif]I confirm that, in what regards Multistage, the original stage.dll file causes the launcher components to disappear on staging. Brian, after a very quick test your preliminary stage.dll does seem to at least fix that visual issue, thanks very much for sharing it![/FONT]

[FONT=Arial, sans-serif]
There might exist (or not) a few extra considerations about this topic but would really need extra time to properly test some things out... On a side note, Orbinauts / Generic DLL developers might need to better study some Orbiter2010 changes - such as the denser atmospheric model for Earth – as well might need to be aware of already existing implementation constraints of the generic dlls on Orbiter2006P1 in order to then better compare generic dlls behavior between Orbiter2006P1 and Orbiter2010. This of course requires clean installs (perhaps with Orbiter Sound too) and some methodology.
[/FONT]



[FONT=Arial, sans-serif]Spacecraft DLL[/FONT]

[FONT=Arial, sans-serif]Regarding spacecraft dll powered stuff, haven't yet fully tested it. In any case, would like to link to a few previous development / bug report threads, because – and following what have written above - it might be handy to have a centralized reference (so that users / developers might be better aware of already existing [/FONT][FONT=Arial, sans-serif]limitations of spacecraft dlls on [/FONT][FONT=Arial, sans-serif]Orbiter2006P1 and *not* caused by Orbiter2010 'compatibility' issues). The current thread seems to be a good place for it:[/FONT]


[FONT=Arial, sans-serif]Vinka's spacecraft2/3.dll on Orbiter2006P1: payload mass bug on quick save (?) [/FONT]
[FONT=Arial, sans-serif]http://orbiter-forum.com/showthread.php?t=1755[/FONT]

[FONT=Arial, sans-serif]Vinka's Spacecraft 3 Aerodynamics params [/FONT]
[FONT=Arial, sans-serif]http://orbiter-forum.com/showthread.php?t=2059[/FONT]


[FONT=Arial, sans-serif]To conclude, although the generic dlls seem to mostly work on Orbiter2010 (still need to make some extra careful tests about a few details) it would still be great to have 'officially' updated multistage (+stage) and spacecraft dlls for Orbiter2010 but I'm aware that sometimes the major 'incompatibility' is really to have time regarding real life vs virtual life so, Vinka, if you are reading this, please do not feel pressured (although, if possible, it would be nice to hear something from you :) )[/FONT]

[FONT=Arial, sans-serif]All for now[/FONT]
[FONT=Arial, sans-serif]Thanks,[/FONT]
[FONT=Arial, sans-serif]António[/FONT]
 
Last edited:

garyw

O-F Administrator
Administrator
Addon Developer
Tutorial Publisher
Joined
May 14, 2008
Messages
10,416
Reaction score
14
Points
113
Location
Kent
Website
blog.gdwnet.com
I tried multistage two and my favourite multistage addon, [ame="http://www.orbithangar.com/searchid.php?ID=3001"]Model Rockets[/ame] which worked fine.

I also installed the 2006P1 version of spacecraft3 and tested out the sample scenarios. The Russian dolls scenario has multiple attached vessels and all separated without a problem.
 

Yury

New member
Joined
Jun 9, 2010
Messages
1
Reaction score
0
Points
0
Thanks! Now I can delete my Orbiter-2006 :)
 

Arthur Dent

Absolutely Mental
Donator
Joined
Feb 8, 2008
Messages
337
Reaction score
1
Points
16
Location
Dresden
Website
wasa.pottyland.de
spacecraft and multistage.dll are essential to me. Not just for the many add-ons based on them, but also for my "private" VSA project. As it is to many other devs and users.

Thanks Brian for your efforts! I'll drink an extra beer for you on Friday! ;)

And indeed, it would be nice, to at least hear from Vinka if he is planning to release an updated version of his dlls. I hope he knows how many people actually appreciate his work!
 

PhantomCruiser

Wanderer
Moderator
Tutorial Publisher
Joined
Jan 23, 2009
Messages
5,496
Reaction score
23
Points
113
Location
Cleveland
I'm having problems with the 2010 release with my multistage2 project... My rocket will launch fine, but there is no staging. I couldn't manually jettison the stage with the [J] key, nor deploy the fairings. Nor would it work with a jettison command in the guidance file.
Using the Universal AutoPilot it would stage as it should (I didn't try the fairing though).

edit-
Fairing sep works under UAP.
I don't understand, it works with a vanilla install of Orbiter '06. And I believe it worked with one of the betas. Any ideas guys?
It could be I'm overlooking something very simple and can't see the forest for the trees.
 
Last edited:

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,314
Reaction score
189
Points
63
Location
Code 347
Thanks Brian for your efforts! I'll drink an extra beer for you on Friday! ;)
..and I'll have one for Martin! :cheers:

And indeed, it would be nice, to at least hear from Vinka if he is planning to release an updated version of his dlls. I hope he knows how many people actually appreciate his work!
Seconded.

I agree with Antonio that multistage/spacecraft dll's could use a makeover for Orbiter 2010 and clear up some of the old issues.

There was some mention on Dansteph's forum that Vinka was working on the next generation of spacecraft/multistage dll's, but that was a while back.

PhantomCruiser said:
I couldn't manually jettison the stage with the [J] key, nor deploy the fairings.
I've found that you can't jettison stages before the current the "BurnDelay" parameter (if used) has expired - but that shouldn't affect the fairing. Try a different multistage launcher and see if it works - if yes, then the problem is with your .ini somewhere.

Cheers,
Brian
 

DaveS

Space Shuttle Ultra Project co-developer
Addon Developer
Donator
Beta Tester
Joined
Feb 4, 2008
Messages
8,950
Reaction score
252
Points
173
There was some mention on Dansteph's forum that Vinka was working on the next generation of spacecraft/multistage dll's, but that was a while back.
Yes, over three years ago(April 2007). Maybe someone could ask him to release the Multistage and Spacecraft source code.
 

BrianJ

Addon Developer
Addon Developer
Joined
Apr 19, 2008
Messages
1,314
Reaction score
189
Points
63
Location
Code 347
Good news... Vinka IS working on the .dll's for Orbiter 2010 :)
 

Columbia42

Member
Joined
Dec 4, 2009
Messages
884
Reaction score
0
Points
16
Location
C:\ProgramFiles\Orbiter
Good news... Vinka IS working on the .dll's for Orbiter 2010 :)

Great!

BTW, I remember seeing the source code for spacecraft and multistage somewhere but I can't quite remember where...

BTBTW, Doesn't the script vessel thingy in Orbiter 2010 sort of replace spacecraft3 for most stuff? (I haven't really tried it out but it seems to have a lot of the same sorts of features).
 

Hielor

Defender of Truth
Donator
Beta Tester
Joined
May 30, 2008
Messages
5,632
Reaction score
0
Points
0
Good news... Vinka IS working on the .dll's for Orbiter 2010 :)
Nice!

Don't suppose there's any possibility of allowing vessel types to be defined by vessel *class* instead of *name*?
 

simcosmos

Addon Developer
Addon Developer
Joined
Mar 23, 2008
Messages
95
Reaction score
1
Points
8
Website
simcosmos.planetaclix.pt
[FONT=Arial, sans-serif]Will write this quick note about Vinka's multistage2.dll particle settings on Orbiter2010: I have noticed, on some development work regarding eventual future Orbiter2010 compatibility of a few of my released (and not yet released) virtual toys, that a few parameters might need to be non strictly zero on multistage2.dll INI definitions in order to, in this message case, in order to have some particle streams rendered in Orbiter2010 (while in Orbiter2006P1 the particle streams would render fine even if with some of those values at zero). Only for completeness, was using my (really old / outdated) Direct SDLV v0.1 to test some compatibility related stuff (and noticed that the SRB exhaust – 'SRBex' – (not the smoke) was apparently not working on Orbiter2010 unless tweaking a few of the particle settings to become non-zero).[/FONT]


[FONT=Arial, sans-serif]Assuming that what I have written is true (would need to do extra tests, with more time) a custom dll or other generic dlls (other than Vinka multistage2.dll) might also need to be updated either on the source code or on INI definitions for better Orbiter2010 compatibility (regarding particle settings).[/FONT]


[FONT=Arial, sans-serif]But again, this is just and only a quick side comment which would really require extra time to properly test and confirm and that might or not be applied to other dlls being that, in the case of Vinka's work, what I have written above might be fixed with the eventual future release of updated dll versions (or, meanwhile, with INI configuration 'tweaks' on existing versions, example, instead of a parameter being zero, by editing it to be 0.001 or something). [/FONT]


[FONT=Arial, sans-serif]António[/FONT]
 

scienceguy99

New member
Joined
Jul 29, 2010
Messages
12
Reaction score
0
Points
0
I have multistage2 and spacecraft3 with orbiter 2010 and when the stages go to seperate they simply vanish :facepalm:I hope this .dll fixes it!!
 

simcosmos

Addon Developer
Addon Developer
Joined
Mar 23, 2008
Messages
95
Reaction score
1
Points
8
Website
simcosmos.planetaclix.pt
Hi all,

I believe that this is probably one of the most indicated places to write a little about Multistage2.dll aerodynamics stuff (in order to keep all info in the same spot, despite the time difference from the last post). At least it should be useful and relevant for future reference purposes.


---------------------------------------------------------------------------------------------------
Multistage2.dll and Drag (Vector Display vs Orbiter Version?)
(Orbiter2006P1 vs Orbiter2010P1 vs Orbiter2010P1 with R12 D3D client)
---------------------------------------------------------------------------------------------------


Some atmospheric related stuff changed from Orbiter2006P1 to Orbiter2010P1: this means that multistage.dll (and other addons) guidance files need to be adapted in relation to pre-Orbiter2010P1 simulation scenarios, in particular if the launcher being simulated ends the ascent in a sub-orbital MECO condition or if the first mission objective is to achieve a low Earth parking orbit, etc.


Next, a quote from one of my development threads, just for context (and also following one of my previous posts in the current thread):

(...)

----------------------------------------------------------------------------------------------------
II. AresI Tests: Vinka's Multistage2.dll : Orbiter2006 vs Orbiter2010
-----------------------------------------------------------------------------------------------------


All AresI files (.scn, .msh, .dds, .cfg and .ini, Vinka's dlls) for a fresh update to my older '20070107dev' are already in their proper directories: the launcher looks good.

I have however noticed two development issues:


II.a) Multistage2.dll 'Drag Compatibility Bug' in Orbiter2010:

What I will write next isn't probably fresh news but I will leave it here for reference: the performance of multistage2.dll launchers are consistently slightly better in Orbiter2010 than in Orbiter2006... With the ' F4 > Visual Helpers > Body Forces ON ' it is easy to see that the changes in Orbiter2010 may have caused some compatibility issues on aerodynamic parameters of multistage2.dll...

In Orbiter2006 I then have a good drag vector display from liftoff all the way to about 85km altitude or so... In Orbiter2010 such drag vector still appears, but really mostly around the time for maximum dynamic pressure and/or at other times, with reduced values (compared to Orbiter2006)...

Snif, this kind of 'breaks' some things regarding the performance assessment of the launch vehicles... Without surprise, Orbiter2006 + multistage2.dll are a more stable combination.

I will still have to decide how will work around this issue... Will probably have to introduce some kind of performance penalty on Orbiter2010 implementation...
(...)


Achieving a better multistage2.dll performance in Orbiter2010P1 vs Orbiter2006P1 was something that I was not expecting... In fact, I was expecting the exact opposite due to the extension of the atmospheric model + micro-drag, etc in Orbiter2010.

In the quoted text I associated such non-expected increased performance in Orbiter2010P1 with some kind of eventual compatibility issue between Vinka's cool multistage2.dll aerodynamic parameters and Orbiter2010P1...

… But I meanwhile did a number of extra tests and tried the same files in a simulation session of Orbiter2010P1 with Jarmonik's D3D9 (R12) client and... surprise (!!!)... I had a good (non-erratic, smooth) drag vector right from liftoff and even beyond the altitudes that experienced in Orbiter2006P1! This IS what I would expect for those files running on 2010P1 and it seems to be more representative of reality.


My question is:

Anyone else ever researched or experienced what I have described above in relation to multistage2.dll (?), I mean:
a) Orbiter2006P1 : good drag vector (although with a 'cut-off' altitude)
b) Orbiter2010P1 : apparently not so good drag (?) (mostly around maxQ and then somehow erractic, causing excess of vehicle performance)
c) Orbiter2010P1 (with D3D9 R12 client) : good drag again and with extended envelope than in Orbiter2006 (drag at higher altitudes plus micro-drag)

(all the above when using the same launcher files across the different installs)

Maybe I'm missing something (or maybe I have messed up something, hehehe), I would really still need to do proper tests, with 100% clean orbiter installations and a dummy / very simple multistage2.dll launcher configuration (as well would need to test with other launchers / spacecraft) but, meanwhile, I would be very interested about knowing if other developers have experienced something similar to what I have described (?).

In particular, why do I seem to experience good drag simulation with the external graphics client on Orbiter2010P1 but not so good without such client?


As noted above, this is not very critical if the orbinaut aims for a stable parking orbit above say 250 km or so (and while doing it with robust LV performance margins)... However, for some other simulation cases (examples: STS, AresI, other SDLV, and so on), where we may have to go for sub-orbital MECO conditions related with the safe disposal of 'dead' launcher components and/or where the specific mission performance margins may be tighter... this topic becomes something a bit more relevant ;-)

Thanks for any input or research direction, in case I have missed a previous discussion about this topic on the forums!

António Maia

PS: Not sure when (it may take a while) but, for a future occasion, I will try to share some screenshots to better show the different drag vector displays (same launcher / scn running on the mentioned different Orbiter installs)
 
Last edited:

Ripley

Tutorial translator
Donator
Joined
Sep 12, 2010
Messages
2,958
Reaction score
188
Points
78
Location
Rome
Website
www.tuttovola.org
...In particular, why do I seem to experience good drag simulation with the external graphics client on Orbiter2010P1 but not so good without such client?...
Could it be because of increased fps?
What is your fps figure with and w/o D3D9?
 

PhantomCruiser

Wanderer
Moderator
Tutorial Publisher
Joined
Jan 23, 2009
Messages
5,496
Reaction score
23
Points
113
Location
Cleveland
Could it be because of increased fps?
What is your fps figure with and w/o D3D9?

That's kind of what I was thinking. I was working on a multistage project when Orbiter 10 became the gold standard, and I did notice a change in the way the guidance file acted. And when I added the D3D9 into the mix, it changed again. Of course I did have a triple frame rate increase too.

I figured that there's more power to do the math now that something else is doing the graphics.
 

simcosmos

Addon Developer
Addon Developer
Joined
Mar 23, 2008
Messages
95
Reaction score
1
Points
8
Website
simcosmos.planetaclix.pt
Hi all,

Thanks for the input, Ripley, PhantomCruiser.

I agree that the framerate plays an important role when coding and executing an automatic guidance but I think that I may be experiencing something else.

I was not able yet to test things out on my main computer (where I do final tests and tweaks to all files). The following results are then from the mobile development computer (EeePC 1000H with integrated Mobile Intel(R) 945 Express Chipset). Both computers running XPSP3 and 2GB RAM. When coding in the EeePC, the guidance files are developed at lower screen resolutions and in internal view (Int) in order to minimize adverse impacts on guidance accuracy.

The following results (approximated average values) are however taken from sessions running at full screen (1024x600, 32bpp), AresI multistage2.dll simulation (FS = First Stage, US = Upper Stage):

Orbiter------------------FPS FS Ext (Int)---------FPS US Ext (Int)-----------------DRAG-----------------------
2006P1----------------------17-20 (25)----------------30 (60)----------drag from liftoff until ~80km alt.
2010P1------------------------~11 (15)----------------17 (25)----------drag mostly between 4.45km-to-24km/30km
2010P1 (D3D9R12)-------------~10 (14)----------------25 (37)----------drag from liftoff all the way to MECO


The lower FPS during first stage is expected because more things are happening on screen, in terms of surrounding environment (launch pads, etc), extra vehicle stages that need to be rendered, first stage performance implementation, special effects related with the flight in lower atmospheric layers, more intensive guidance commands (roll+pitch-over, gravity turn, etc).

In the main computer, these values are better (QuadCore plus dedicated graphics card) but what is important here is that the behavior relative to the display of Drag is similar to what I have described above for the EeePC: for some reason, the Drag Vector seems to not exist at all (for multistage2.dll?), in Orbiter2010P1, except for the referenced ~4.5km-to-25km or so altitude interval.

:hello: EDIT2: after using Log Scale at 100%, it seems that drag is present on default Orbiter2010P1 also from liftoff and after maxQ to ~85km or so (the "does not exist at all" info was incorrect) but apparentlyat reduced magnitudes than when comparing with 2010P1+D3D9R12. In any case, on default Orbiter2010P1 - and for the stated AresI simulation - there still seems to not exist (?) displayed drag after crossing ~85km/90km or so while in 2010P1 with D3D9R12 client there is always drag.

What is strange is that when I load the exact same files on Orbiter2010P1 running with the D3D9 (R12) client, I do get a good drag, I mean, I get a force similar to Orbiter2006P1 AND an extended drag simulation all the way to MECO, as I would expect from Orbiter2010 atmospheric model enhancements (vs 2006P1).


All the above means that the automatic guidance files developed for Orbiter2006P1 do need some minor tweaks if running in Orbiter2010P1+D3D9R12 in order to account for the extra drag during second stage flight... These are minor tweaks because most of the performance impact happens during first stage. (EDIT3: I mean, the drag in first stage needs a different type of adjustments than the ones to counter-act the cumulative drag on second stage)

However, if running Orbiter2010P1 without the external client, the adjustments to the guidance files increase a little more because, except for the interval mentioned, I seem to have no drag at all (please see EDIT2 for update / correction)... This causes excess of performance and the upper stage's MECO and other things related with US guidance need to be adjusted...

I really need to do a more extensive series of comparative tests to see if this is happening because of something (?) I'm doing with my specific development files or to reach (or not) to the conclusion that this is something more generic related with multistage2.dll and/or even other dll powered launchers vs Orbiter versions, etc.

That is why I asked if other addon developers noticed something similar when running their (multistage2.dll) addons with and without external graphics client on Orbiter2010P1 and when activating the ' F4 > Visual Helpers > Body Forces ON '.

Meanwhile, I leave these comments here, for reference: extra tests needed! :)

Thanks,
António Maia


EDIT1 / UPDATE

Suggestion: if possible, could someone please:
a) load the default Orbiter2010P1 Atlantis Demo scenario ("Space Shuttle Atlantis is launched into orbit by autopilot")
b) run it from external view and with 'F4 > Visual Helpers > Body Forces ON' (make sure drag is selected EDIT2: AND Log Scale at 100%)
b.1) run it in Orbiter2010P1 (default client)
b.2) run it in Orbiter2010P1 with a D3D9 client (R12 if possible)
c) look at the Drag display

I already did it with Orbiter2006P1 (although no auto there) and Orbiter2010P1... and, if possible, would like to compare some notes.


:hello: EDIT2: after using Log Scale at 100%, it seems that drag is present on default Orbiter2010P1 also from liftoff and after maxQ to ~85km or so (the "does not exist at all" info was incorrect) but apparentlyat reduced magnitudes than when comparing with 2010P1+D3D9R12. In any case, on default Orbiter2010P1 - and for the stated AresI simulation - there still seems to not exist (?) displayed drag after crossing ~85km/90km or so while in 2010P1 with D3D9R12 client there is always drag.

Thanks,
António
 
Last edited:
Top