Space Shuttle Ultra development thread

[Urwumpe]

Redburne works on a API to FlyByWire, which could be useful for dealing with joystick inputs. In Orbiter2005, the GetManualControlLevel function failed when no thruster groups had been defined, I don't know if this got fixed in 2006.

 

[Donamy]

I think Urwumpe, may need to know exactly, why you need to do what you are doing. You are trying to switch the control, from the left aft cockpit position to be thrusters, and the right side to RMS control, correct ?

 

[SiameseCat]

I want to be able to enable/disable manual thruster control. At the moment this would only be used based on cockpit position, but eventually it would also be based on whether the flight dech hand controllers are powered on.

 

[DaveS]

I want to be able to enable/disable manual thruster control. At the moment this would only be used based on cockpit position, but eventually it would also be based on whether the flight dech hand controllers are powered on.

How about SetAttitudeMode? That one works exactly the same as Ctrl-NumPad Divide which enable/disables manual RCS input while allowing the thrusters themselves to remain active for automatic attitude controlling.

Se page 42 of the API Reference Manual for info on SetAttitudeMode.

 

[SiameseCat]

The problem with SetAttitudeMode is that there are cases where the manual input will be used to control the RMS. I think SetAttitudeMode will cause all thruster input to be completely ignored.

 

[SiameseCat]

I'm thinking of working on the attitude control autopilots for the moment. The main reason I want to keep the default thruster groups defined is so AttitudeMFD and the default autopilots will work with SSU. If we had a better autopilot in CRT MFD, we could just replace the default attitude control groups with other ones.

 

[Urwumpe]

Regarding the discussion about AMSO: We don't plan to encrypt our meshes, do we?

 

[FordPrefect]

Hi,

I was wondering, do you have plans to implement the runway outlines being rendered/projected on the HUD during the approach phase? I love that feature on the real shuttle. Though it probably is pretty difficult to do and perhaps not feasible in the VC but only the generic (glass) cockpit view, as it would require the simulated collimated HUD display to adjust itself to the FoV and location of the user's eyes (TrackIR).

 

[Urwumpe]

Hi,

I was wondering, do you have plans to implement the runway outlines being rendered/projected on the HUD during the approach phase? I love that feature on the real shuttle. Though it probably is pretty difficult to do and perhaps not feasible in the VC but only the generic (glass) cockpit view, as it would require the simulated collimated HUD display to adjust itself to the FoV and location of the user's eyes (TrackIR).

I think it can be done, it will only look good when you are in the correct seat position, but technically, it is just projecting 4 points onto the HUD and connecting them with lines.

 

[tblaxland]

I'm thinking of working on the attitude control autopilots for the moment. The main reason I want to keep the default thruster groups defined is so AttitudeMFD and the default autopilots will work with SSU. If we had a better autopilot in CRT MFD, we could just replace the default attitude control groups with other ones.

Interested in an SSU fork of AttitudeMFD? Would the graphics need to be like Universal Pointing MFD?

This would easily allow different thruster group definitions to be implemented. By the way, see this thread. I'd like to get those bugs sorted first, before inflicting them on SSU

Also, SSU is published under GPL - I'd like to check with original authors Chris Knestrick and Bob Denny but I don't see any issues there since the AttitudeMFD copyright is pretty open.

 

[Urwumpe]

I have now commited code which fixes at least the CDR MDU buttons, so they can be used again. The other MFDs will come soon, i just can't promise everytime, that they will work. While the positions of CDR1 BRT and CDR2 PWR are correct according to Mesh Wizard, Orbiter generates no mouse events for them.

tblaxland: I would prefer the universal pointing algorithm working inside the Atlantis DLL as simulated GPC Software module.

 

[DaveS]

Just a status update on the FSS/RSS:

I have now started work on the RSS. Not much to show right now other than a basic back frame for the RSS. Should have something showable tommorow.

 

[tblaxland]

tblaxland: I would prefer the universal pointing algorithm working inside the Atlantis DLL as simulated GPC Software module.

I think that would be best for overall integration in your project. I also worry that AttitudeMFD is getting a bit bloated after the numerous revisions.

You mention the algorithm - does this work very differently from AttitudeMFD's methodology? There are definitely areas were AttitudeMFD could be improved and made more realistic (coupled rotations and discrete rather than infinitely variable thruster firings, to name two).

 

[Urwumpe]

I have the PLT MDUs fixed now. All 4 rotary switches (PWR and BRT) work now, strange enough I just used the CDR coordinates and mirrored them.

Now I have to do the first row of F7 MDUs.

 

[SiameseCat]

tblaxland: SSU has its own attitude control code already. The attitude control should probably be done by the Atlantis module, as opposed to an external MFD. Also, one of the main things I want to do is rewrite the SSU code so it always uses inertial attitude internally, which is what I think the real shuttle does.

 

[SiameseCat]

The SSU algorithm is fairly different from the one used in AttitudeMFD. It only maneuvers in one axis at a time, to avoid coupling problems. Also, SSU seems to be more fuel-efficient, whereas AttitudeMFD is better at maintaining tight deadbands. This is probably due to the differences in thruster control; AttitudeMFD seems to be constantly firing thrusters at very low levels, whereas SSU fires thrusters at higher levels, but only when attitude goes out of limits.

 

[DaveS]

Well, it went alot faster than I thought that get the basic RSS done, so here's a few screenshots pf it under construction.

And another thing that could need simulation is the small thrust from the APUs when they're started up and operating in orbit. Believe it or not, the APUs do produce quite a bit of thrust that the RCS have to counter.

 

[Urwumpe]

On the wish list, I would repeat something: The AFD should be included as MFD, just like all others. It is practically the same MDU unit as everywhere else.

And the rotary switches on each MDU should appear as small 3D cylinder. They don't need to be a separate mesh group each, it would just be helpful to have a tiny reference in mesh wizard and of course, it would look better.

EDIT: The Center MDUs are fixed now, only missing is the CRT4 MDU now.

 

[Marg]

So what`s going on? I see quite a big activity. May i ask what will be the improvements in the next release of Shuttle Ultra? And version number - is it going to be 1.07 and what is approximate release date?

 

[Urwumpe]

We need a change log.

The scale of the Shuttle Orbiter changed and some details. But no release date yet. I would prefer adding some more essential features like payload handling or ODS before we make the next major release. Also, I still want to include a GLS simulation for keeping the number of people who fail to launch the shuttle low.

EDIT: I just started defining a class "Mission", which provides an access to the Mission Data File, we wanted to have. I also define it in a way, that the same mission object can be used for any other object we create.