Space Shuttle Ultra development thread

[kulch]

2Urwumpe:
I was wrong yesterday. PM_SetSlotRotationAngles sets the rotation of payload in the slot. This is not affect jettison direction (but may be useful to emulate spin - banking rotation - of Shuttle payload before detachment...).
To rotate the payload slot itself (and to set jettison direction) you can use the PM_SetSlotAttachmentParams function.
I will add the notice about that in sdk documentation.

 

[Donamy]

Urwumpe,

Any idea when a fixed build, with the new scaling, will be released ? I'm anxious to start on the payload panels etc.

 

[Urwumpe]

Donamy: No idea yet, the MFDs don't work completely yet, the power button seems to make trouble. working on it.

Also, before we make a new release, we might want to change the file names of our meshes/textures...i remember Shuttle Fleet 4.0 uses the default Atantis VC, if we overwrite this with our scaled meshes, ShuttleFleet will be broken and that is really bad style.

 

[Donamy]

How about UltraAtlantis,UltraVC and Ultracockpit ?

 

[C3PO]

How about UltraAtlantis,UltraVC and Ultracockpit ?

"Ultra-" is kind of generic. How about SSUltra-?

 

[Donamy]

That would be fine. Or SSUAtlantis ...etc.

 

[Urwumpe]

I would suggest naming the subfolders "SSU" (as its already our trademark) and remove the Atlantis from all the filenames, as we will do other shuttles. As we could maybe, one day in the future also have the non-MEDS shuttle cockpits, what about naming the files with the prefix "MEDS" which are MEDS-specific.

 

[DaveS]

I have made myself a custom module for my FSS/RSS, but I have a problem with it.

The problem is that while I can create the FSS/RSS vessel in Orbiter using the Scenario Editor, it refuses to load the scenario once I exit the scenario and re-enter it.

Could someone take a look on the source code? It's adapted from the default HST sources that come with the Orbiter SDK and it compiles just fine, but refuses to load once you have exited a scenario and try to re-enter it.

 

[SiameseCat]

In the LoadState function, the line
ParseScenarioLineEx (line, vs);
should be outside all the if/else if statements.

 

[DaveS]

In the LoadState function, the line
ParseScenarioLineEx (line, vs);
should be outside all the if/else if statements.

Thanks! I will correct this now!

Edit:
Fixed it and it cleared the CTD problem right up! Now I won't have to fight with ever changing meshgroup numbers anymore!

 

[SiameseCat]

Quick correction: the ParseScenariolLineEx line should have its own else statement, below everything else.

 

[Donamy]

Any updates ?

 

[C3PO]

CRT MFD Manual.pdf

Items 19-21: Target ÄV in X, Y and Z axes in feet per second(fps) in an LVLH reference
frame. The +X vector is parallel to the velocity vector. The +Z vector points toward the
centre of the Earth. The +Y vector points toward the south and is perpendicular to the +X

and +Z vectors.

​

​

​

This is a bit confusing. +X points in the prograde direction, but +Z points up (away from the center of the Earth) and the +Y points North.​

 

[SiameseCat]

C3PO: That's not how it should work. I'll check if the directions are getting mixed up.
EDIT: The +Z vector is in the right direction, and I'm fairly sure the Y vector works too.

 

[DaveS]

C3PO: That's not how it should work. I'll check if the directions are getting mixed up.

Well, if it is Shuttle Orbiter coordinates then here's the complete list:

+X=Forward
-X=Aft
+Y=Right
-Y=Left
+Z=Up
-Z=Down

 

[C3PO]

C3PO: That's not how it should work. I'll check if the directions are getting mixed up.
EDIT: The +Z vector is in the right direction, and I'm fairly sure the Y vector works too.

OOPS! I was using an older version.:sorry:

I downloaded v1.06 again and now +Z points nadir. But +Y still points +normal (North).

I used the Atlantis Cockpit scenario, and entered +50 fps. Still +normal.

 

[SiameseCat]

I'll look into that once we have working MFDs. It's probably a missing minus sign.

 

[SiameseCat]

Is there a way of disabling manual control inputs without deleting any thruster groups? I want to allow autopilots to work, but prevent the user from firing thrusters.

 

[Urwumpe]

SiameseCat: No idea how to do this in the current version except overriding all. Intercept the direct keyboard events (ConsumeKey) and handle joystick yourself.

I would personally prefer a callback function to handle the mapping from user inputs to thruster/aerodynamic control surface activity, but I think this API extension will not come before Orbiter 2010.

 

[SiameseCat]

Urwumpe: What would dealing with joystick input involve? There don't seem to be any API functions for that.
What I was thinking of doing was using the GetManualControlLevel function to get the commanded input, and use this to 'cancel out' the user input from the thruster commands. Would this work, or am I missing something here?