General Question Spacecraft3.dll in Orbiter 2010

[DaveS]

I have Orbitersound 4.0 on, however with 3d sound disabled

And there we go, 3D sound is the thing in OS 4.0 that leads to the drop.

 

[orb]

And there we go, 3D sound is the thing in OS 4.0 that leads to the drop.

This might be an OrbiterSound's issue then and not GenericVessel's.

 

[Face]

I see what you mean, Dave. To me it looks like the welcome message of OS4 is causing this. Even with standard scenario it drops the FPS to around 30. If you press space to get rid of this message, the FPS climbs up again.

While I have configured the project to use Dan's SDKs, I don't think that they are linked in any way, because I'm not including headers ATM. Perhaps I should even revert to 3.5 for further development, if OS4 is giving troubles?

 

[DaveS]

I see what you mean, Dave. To me it looks like the welcome message of OS4 is causing this. Even with standard scenario it drops the FPS to around 30. If you press space to get rid of this message, the FPS climbs up again.

For me the drop is present even without the message. I haven't seen the message since I installed OS 4.0.

 

[Face]

So if you start a scenario without the genericvessel class loaded, you don't get the drop, just with it loaded?

 

[DaveS]

So if you start a scenario without the genericvessel class loaded, you don't get the drop, just with it loaded?

This is correct. I get it even if it is the only vessel loaded. SSU which s far mor complex, doesn't drop the FPS.

 

[Face]

This is correct. I get it even if it is the only vessel loaded. SSU which s far mor complex, doesn't drop the FPS.

So two questions here:
Is it also dropping with a standard scenario without any OS4 compatible vessel loaded?
Is SSU - in the version you use to test - OS4 compatible?

 

[Ripley]

260 FPS with d3d9 R7 client...

Loru, R8 has been out for a while.
http://d3d9client.codeplex.com/

 

[DaveS]

So two questions here:
Is it also dropping with a standard scenario without any OS4 compatible vessel loaded?
Is SSU - in the version you use to test - OS4 compatible?

SSU is OS 4 compatible. And it seems this is a OS 4.0 bug for sure as all non OS 4.0 vessels exhibit the problem.

Thanks for the help and uncovering a OS 4.0 bug!

 

[Face]

SSU is OS 4 compatible. And it seems this is a OS 4.0 bug for sure as all non OS 4.0 vessels exhibit the problem.

Thanks for the help and uncovering a OS 4.0 bug!

All right. I've checked the DLL with dependency walker just to be sure, and there really is no import/export to Dan's SDK. So to OS4 it should look like a stock vessel.

Thanks for the info. Sounds like OS4 compatibility just went mandatory :lol: .

 

[DaveS]

All right. I've checked the DLL with dependency walker just to be sure, and there really is no import/export to Dan's SDK. So to OS4 it should look like a stock vessel.

Which it does as even the default Carina vessel behaves exactly the same in terms of OS 4.0 FPS drop.

 

[orb]

Sounds like OS4 compatibility just went mandatory :lol: .

Well, I think it should be rather the other way around, i.e. OrbiterSound should be fully compatible with vessels not using its SDK, e.g. with stock vessels.

I'd rather fill in bug report for the OrbiterSound than include OrbiterSound SDK in the project without really using its features, only to make it happy.

 

[Loru]

I think merging multistage with spacecraft3 into single framework would be nice.

"ini" file structure.

spacecraft 3 is pretty well designed and ini files are very self explanatory however in my opinion and to implement some features I think it needs a bit of improvement. Below is my example of structure:

[TEXTURE_LIST]
TEX_1=texture1 filename
TEX_2=texture2 filename
TEX_3=texture3 filename


[PARTICLESTREAM_1]
NAME=name used in particular effect
SRCSIZE=8.0
SRCRATE=3

and so on with particle stream defenitions

[B][CONFIG1] [/B]- here we'll define our main vessel
MESHNAME="dg\DeltaGlider"
SIZE=9.
CAMERA=(0,1.467,6.782)
EMPTY_MASS=12000
......and so on with all parameters ALONG WITH AERODYNAMICS, DOCKING PORTS, ATTACHMENTS and ANIMATIONS

in here we're adding bottom/rear) mounting point for booster/tug etc.
STAGE_MOUNT_B=(0,0,-10) 


[B][CONFIG2][/B] - here we'll define stage below main vessel (booster, EDS stage etc)
STAGE_MOUNT_T=(0,0,10)                                       <- this line is top mounting point for vessel
DETACH_UPPER=should next stage should be detached??
IGNITE_UPPER=should next stage main engine should be ignited??

MESHNAME="dg\awesome_2nd_stage"
SIZE=19.
CAMERA=(0,1.467,6.782)
EMPTY_MASS=32000
......and so on with all parameters ALONG WITH AERODYNAMICS, DOCKING PORTS, ATTACHMENTS and ANIMATIONS

STAGE_MOUNT_B=(0,0,-10)

[B][CONFIG3] [/B]- here we'll define stage below our 2nd stage )
STAGE_MOUNT_T=(0,0,10)                                        <- this line is top mounting point for vessel
DETACH_UPPER=TRUE
IGNITE_UPPER=TRUE

MESHNAME="dg\awesome_first_stage"
SIZE=19.
CAMERA=(0,1.467,6.782)
EMPTY_MASS=32000
......and so on with all parameters ALONG WITH AERODYNAMICS, DOCKING PORTS, ATTACHMENTS and ANIMATIONS

STAGE_MOUNT_B=(0,0,-10)

BOOSTER_MOUNT1=(2,0,-10)        <--------- those are lines for mounting booster rockets, RATOs etc. Could be defined in any stage 
BOOSTER_MOUNT2=(-2,0,-10)

[B][BOOSTER1][/B]
BASE_STAGE= number of config stage for booster to attach to
BASE_POINT= number of BOOSTER_MOUNT point to attach to
SEPARATION= TRUE/FALSE - booster separates or not automatically
SEPARATION_TIME= time after burnout for separation
SEPARATION_VECTOR= vector for separation and speed of separation

MESHNAME="dg\awesome_booster"

ZROT=deg - angle for Z axis for booster to attach (to avoid mesh multiplying as in multistage)

SIZE=19.
EMPTY_MASS=10000
......and so on with all parameters.

[B][BOOSTER2][/B]
BASE_STAGE= 3
BASE_POINT= 2
SEPARATION= TRUE
SEPARATION_TIME= 1
SEPARATION_VECTOR= (0,1,0) 3

MESHNAME="dg\awesome_booster"

ZROT=180

SIZE=19.
EMPTY_MASS=10000
......and so on with all parameters.

---------- Post added at 05:40 PM ---------- Previous post was at 05:25 PM ----------

 

[Pipcard]

So we'll combine spacecraft and multistage?

 

[Loru]

So we'll combine spacecraft and multistage?

Sorry - first sentence didn't paste :/ Combining it will be nice idea IMO. It would solve a lot of problems and potentially simplyfied payload manager system would make it trully universal launcher design framework.

 

[BruceJohnJennerLawso]

Sorry - first sentence didn't paste :/ Combining it will be nice idea IMO. It would solve a lot of problems and potentially simplyfied payload manager system would make it trully universal launcher design framework.

THAT, would make a huge difference :thumbup:. A Payload manager system for this would be perfect. Maybe it could have a really simple abort/launch info system like the Energia project did.

 

[Face]

I think merging multistage with spacecraft3 into single framework would be nice.
<spec proposal snipped>

Thanks for the input. Would you mind me putting this up on the Wiki?

So we'll combine spacecraft and multistage?

I'm not sure if there is a "we" that can decide this yet .

My idea - that I will outline as code in my repository - is to first produce a module that works as replacement for both SC3 and MS2. If there is sufficient "we" (aka. enough community interest and input) with a specification that is agreed upon, I will also try my hands on developing the replacement into that direction.
If there is not, at least the code for the framework that is used by so many quality add-ons is not lost, as I'll make the replacement framework code GPL.

 

[BruceJohnJennerLawso]

Thanks for the input. Would you mind me putting this up on the Wiki?



I'm not sure if there is a "we" that can decide this yet .

My idea - that I will outline as code in my repository - is to first produce a module that works as replacement for both SC3 and MS2. If there is sufficient "we" (aka. enough community interest and input) with a specification that is agreed upon, I will also try my hands on developing the replacement into that direction.
If there is not, at least the code for the framework that is used by so many quality add-ons is not lost, as I'll make the replacement framework code GPL.

I hope backwards compatibility can work, but Im not sure. For example, how will the new convex hull points work with landing upside down?

 

[Loru]

Thanks for the input. Would you mind me putting this up on the Wiki?

Sure. I hope staging and overall logic of the file doesn't need further explanation.

 

[Izack]

I'm not sure if there is a "we" that can decide this yet .

My idea - that I will outline as code in my repository - is to first produce a module that works as replacement for both SC3 and MS2. If there is sufficient "we" (aka. enough community interest and input) with a specification that is agreed upon, I will also try my hands on developing the replacement into that direction.

You have what tiny ability I have, if there's any use for it beyond housekeeping.

I hope backwards compatibility can work, but Im not sure. For example, how will the new convex hull points work with landing upside down?

Presumably this would only be compiled against the current stable release, and won't need to worry about convex hull points for "anywhere between a year and a (very small) handful of decades."