Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

I was just suggesting a layout example. I think by going this route we'll have an easier time making the ASEs. And you guys can concentrate on the more important shuttle systems.

Yes, but it also takes much more time for developing all the small stuff that is needed there. For example the electrics. It wouldn't take that long to turn such stuff into something that can be used in a generic way, but it needs some work.

 

[SiameseCat]

One other issue I've seen is that, when the Orbiter shutdown method is set to 'De-allocate memory and display launchpad dialog', Orbiter doesn't shutdown, but just displays 'Please wait while Orbiter is closing down the simulation session'. This only occurs in scenarios with SSU. I suspect this has something to do with the Lua code, because this problem only appeared recently.

Fixed this issue; a pointer (the rsls pointer, if anyone's interested) wasn't initialized, but it was still being used (and deleted).

 

[Urwumpe]

About the future developments: I have a concept in mind, any criticism or suggestions for it?

• In LibUltra, the generic subsystem class is enhanced by interfaces for electrical, fluid transfer and thermal calculations.
• The Subsystem class is enhanced, so it can be constructed out of Component classes, each component modeling one kind of standard behavior. Components can be:
  • Relays, electrical connection patterns (bus, junction) and electrical sensors
  • AC Motors, Torque limiters, differentials
  • Pumps
  • Pyrotechnic devices
  • Fuel cell stacks
  • Lights
  • Connections between subsystems, eg AC Ports, DC Ports, Liquid/gas ports or Shafts
• More complex components can be composed of other components.
• Components can be cloned.
• Direct connections between subsystems are to be reduced.
• Loading and saving of subsystem data in scenarios is moved into a composite/tree class, that is produced once before it is written or while it is read.
• A RelayFactor class is added to the LibUltra that permits producing relay objects by a model name.
• Subsystems can be assigned to vehicle structures. Removing a structure from the simulation model invalidates all connections between subsystems of that structure and the outside world.

Basically, the idea is to have as much standard behavior as possible, and have the LibUltra part prepared for defining subsystems by script files. For that, I think we should get more information made generic, so we only need to worry about parsing a script file and have the subsystems and components tested as often as possible.

Any complaints?

I currently have electrical stuff calculated a few times on the paper, it should not have nasty surprises, but is not 100% realistic - it is just a three iteration solution then. Thermal calculations would need some more work on how far we can go there. If fluid transfers are limited to the calculations of the electric part, it wouldn't be absolutely realistic, but can be calculated quickly.

If electrics, thermal and fluid/gas transfers work, we would have around 50% worst problems of the Shuttle solved.

 

[Donamy]

Up until now, I've been very careful not to change the object order when adding things to the VC, for fear of breaking the animations. Whike adding the curved meter Urwumpe requested, it adds an extra object to the A1 panel. Is this a problem and should I merge it with another object on the panel ( don't know which one) or will it be ok ? And should I add the talkbacks to each panel separately or do I need to have all the talkbacks added at the end of the VC mesh ?

 

[Urwumpe]

Up until now, I've been very careful not to change the object order when adding things to the VC, for fear of breaking the animations. Whike adding the curved meter Urwumpe requested, it adds an extra object to the A1 panel. Is this a problem and should I merge it with another object on the panel ( don't know which one) or will it be ok ? And should I add the talkbacks to each panel separately or do I need to have all the talkbacks added at the end of the VC mesh ?

Don't worry about the order. It is nothing that ssumeshc can't fix afterwards, as long as you don't change the labels of the groups.

 

[DaveS]

I have been thinking a bit about the PLB lights and I think I have a good compromise that should satisfy everyone.

The compromise is a option in SpaceShuttleUltra.cfg file that will toggle between 1 big light and separate lights. That way you can change it to fit your setup.

How does that sound?

 

[Donamy]

Is there any way to get a reflective lightsource from the Earth ?

 

[Urwumpe]

Is there any way to get a reflective lightsource from the Earth ?

You mean the "Earthshine"? Not yet, would also be pretty disturbing if we cheat it in SSU. What about suggesting it to the rendering client teams?

 

[DaveS]

Is there any way to get a reflective lightsource from the Earth ?

I believe that OGLAClient has it implemented. I guess Jarmonik could implement into D3D9Client once he's done with the new atmospheric effects.

---------- Post added 01-22-11 at 12:44 PM ---------- Previous post was 01-21-11 at 04:06 PM ----------

Could someone please fix the problem with the RSLS so that we're able to launch again?

Edit:
Also, how about implementing Lua into SSUPad? That way we can get rid of the dialog while controlling the swing arms and service functions through a standard Lua interface.

Maybe even go as far as using SSULCC for the actual commanding while the SSUPad vessel only responds to those commands. That should increase realism another step. That way we could also control the GLS.

 

[Urwumpe]

Also, how about implementing Lua into SSUPad? That way we can get rid of the dialog while controlling the swing arms and service functions through a standard Lua interface.

Maybe even go as far as using SSULCC for the actual commanding while the SSUPad vessel only responds to those commands. That should increase realism another step. That way we could also control the GLS.

Can be done, it doesn't really hurt to have a Lua interface too much. But you have to include that Lua isn't really fast and doesn't have precise timing, so everything that requires more complex behaviors should be better done by C++, but could then still be scheduled from inside Lua.

About the RSLS - what about finally getting the DPS sorted out and have the behavior properly. The current simplifications work most of the time, but are not even recreating the behavior of the shuttle.

Take for example the behavior of the Major Function switches and the CRT/CRT command, for example:

After launch, if you want to go to SM, you have to switch MF of CRT 1 to SM. Now, there is no SM GPC yet. so the GPC currently driving the IDP will switch to GPC MEMORY OPS. Next, you enter GPC/CRT 4 1 EXEC. This will tell the GPC 4 to drive the IDP 1. Since it does also not support SM, since it is still operating in G1 (It does not load the G2 memory config when the other two GPCs are switched into GNC OPS 201), it will switch to OPS 0 GPC MEMORY, unloading the GNC MF overlay. Now you can load the G2 Memory config on GPC 4, and switch to SM OPS 201.

Then, the PL MF switch position also makes more sense: it is used on the Shuttle during a mission as "usually not supported major function" and thus always allows turning a GPC into OPS 0 again - otherwise you can't get a GPC to run only system software (OPS 0).

 

[DaveS]

About the RSLS - what about finally getting the DPS sorted out and have the behavior properly. The current simplifications work most of the time, but are not even recreating the behavior of the shuttle.

Take for example the behavior of the Major Function switches and the CRT/CRT command, for example.

Not only that, currently the states of the Major Functions switches are not saved/loaded. Also, CRTMFD is full of bugs, just see the bug I reported here:
http://www.orbiter-forum.com/showthread.php?p=208989&highlight=buffer#post208989

 

[Urwumpe]

Not only that, currently the states of the Major Functions switches are not saved/loaded. Also, CRTMFD is full of bugs, just see the bug I reported here:
http://www.orbiter-forum.com/showthread.php?p=208989&highlight=buffer#post208989

I can put maybe some time today into finishing a new feature for the IDP, that I have been working and researching for some time, Format Buffers. Essentially, you describe the whole rendering as string of 16 bit words, divided in a static and dynamic buffer area (For updating the display every 1/6.25 seconds, you only need to overwrite the dynamic buffer). This way, all the CRT functions of the IDP would be easily quickly tested for each graphical primitive. It contains a lot of guess work, because I never had a complete list of Format Control Words, but we would get rid with the hard coded rendering, and get one step closer to the real hardware.

 

[SiameseCat]

Not only that, currently the states of the Major Functions switches are not saved/loaded. Also, CRTMFD is full of bugs, just see the bug I reported here:
http://www.orbiter-forum.com/showthread.php?p=208989&highlight=buffer#post208989

The CRTMFD issue is a simple buffer overflow; I can check in a fix in a day or so (it's already fixed, but I'm making some other changes that still need testing). Are there any other issues?

 

[DaveS]

The CRTMFD issue is a simple buffer overflow; I can check in a fix in a day or so (it's already fixed, but I'm making some other changes that still need testing). Are there any other issues?

Well, the SPI loses the colors during some weired transition phase during entry, somewhere around Mach 5.

Also how about implementing trimming function and a working TGT vs CUR into the MNVR displays? And saving/loading of CRTMFD states.

That should cover things for now.

 

[DaveS]

I have noticed a slight inaccurcy with the PCT sequence. Currently in SSU you both arm and execute it with the BODY FLAP PBI. This is wrong.

The BODY FLAP PBI is only used to arm the PCT. To execute it, the blank PBI on the A6U Orbit DAP is pushed.

 

[SiameseCat]

The STS-133 Rendezvous checklist says that the SB PBI arms the PCT, and either the BF or blank DAP PBIs will start the PCT. Pressing the BF alone shouldn't start the PCT (at the moment it does, but this is a bug).

 

[DaveS]

The STS-133 Rendezvous checklist says that the SB PBI arms the PCT, and either the BF or blank DAP PBIs will start the PCT. Pressing the BF alone shouldn't start the PCT (at the moment it does, but this is a bug).

True. I remembered the wrong PBI (SB vs BF).

 

[Urwumpe]

I HAD BEEN ENLIGHTENED!

The IOP of the Shuttle GPC handles the channel I/O instructions of the System/360, the BCEs are the equivalent of the I/O Channel hardware of the System/360, MSC programs are thus using a reduced System/360 instruction set.

The CPU of the GPC does thus never issue SIO instructions itself, this is only supported in the IOP. Since IOP and CPU share the same memory, the MSC programs are loaded during IPL...

 

[DaveS]

I HAD BEEN ENLIGHTENED!

The IOP of the Shuttle GPC handles the channel I/O instructions of the System/360, the BCEs are the equivalent of the I/O Channel hardware of the System/360, MSC programs are thus using a reduced System/360 instruction set.

The CPU of the GPC does thus never issue SIO instructions itself, this is only supported in the IOP. Since IOP and CPU share the same memory, the MSC programs are loaded during IPL...

How will this enlightenment affect the development of the SSU DPS?

 

[Urwumpe]

How will this enlightenment affect the development of the SSU DPS?

Well, I can provide a much more accurate model of the GPC I/O in general, I could now also program a working emulation of the AP-101.

We still don't have the real software images, but I have the flow charts of around 95% of the first revision of the FCOS software from the ALT test flights, which would be enough for the start. What was added later and changed towards the currently flown software version, would be some detective work, for example how the memory archive works on the AP-101S. The larger memory of it is still completely software compatible to the AP-101B, so it is only an addition to the memory config handling. It is very possible that the FCOS operating system calls by the application software did not change at all since the early versions.

I still search for any NASA document about the AP-101 or the flight software, I get a lot of insight from comparing the NASA documents with the manuals for the System/360, or the modern manuals and checklists with the ALT test software. The behavior of the keyboard and how you switch modes (called reconfiguration in the software specs) is still the same as it was for the ALT tests.