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
