Space Shuttle Ultra 1.25 Revision B development

[Donamy]

I didn't optimize a simple mesh. Although trusses might be different.

 

[Urwumpe]

I didn't optimize a simple mesh. Although trusses might be different.

I mean simple geometrically - a not necessarily convex shape, but without many holes.

 

[DaveS]

So where do we stand on these things I would want to see prior to a new public release:

• Active Ku antenna, so we have to follow actual procedures for deploy/activation and stowing
• Post-MECO MPS dump and SSME stow
• C&W Master Alarm for APU/HYD shutdown
• ADI with rate needles!
• Upgraded and corrected SPI, OMS/MPS and APU/HYD MEDS screens with correct graphics
• Correct physical behaviour of the SRMS so that the rate gauge on A8U is active.

 

[Urwumpe]

So where do we stand on these things I would want to see prior to a new public release:

• Active Ku antenna, so we have to follow actual procedures for deploy/activation and stowing
• Post-MECO MPS dump and SSME stow
• C&W Master Alarm for APU/HYD shutdown
• ADI with rate needles!
• Upgraded and corrected SPI, OMS/MPS and APU/HYD MEDS screens with correct graphics
• Correct physical behaviour of the SRMS so that the rate gauge on A8U is active.

Some nautical miles away. With the sensors done, I can at least have the primary C&W implemented, the secondary C&W would rely on the MDMs.

 

[DaveS]

Some nautical miles away. With the sensors done, I can at least have the primary C&W implemented, the secondary C&W would rely on the MDMs.

Is that only for the C&W or all of them? How about creating a rough implementation of each element mentioned and hooking them up to actual physical systems later? Essentially "scarring" the vehicle in advance.

 

[Urwumpe]

Is that only for the C&W or all of them? How about creating a rough implementation of each element mentioned and hooking them up to actual physical systems later? Essentially "scarring" the vehicle in advance.

The problem is, we would have a lot of code duplicated for this, which a slower approach would deal better. Also I see, as developer, the bigger problem behind the insanely chaotic code structure we still have in SSU. It requires a large set of knowledge for finding which subsystem is implemented in which place. Splitting the large subsystems into smaller work packages, that can be tested independently, ideally even without needing Orbiter running at all, but by a unit test tool, would in my eyes offer more gain for SSU, than fast new features. What does it bring us to have the features run in a fast way quickly, when this code is hard to be replaced?

The Ku-band antenna could be done independent of this, since it has a large set of special electronics for that, but the MPS dumps would require the Shuttle Bus system. And the displays could also be done independent, but would require more time, since there is a lot of behavior behind them.

 

[DaveS]

The problem is, we would have a lot of code duplicated for this, which a slower approach would deal better. Also I see, as developer, the bigger problem behind the insanely chaotic code structure we still have in SSU. It requires a large set of knowledge for finding which subsystem is implemented in which place. Splitting the large subsystems into smaller work packages, that can be tested independently, ideally even without needing Orbiter running at all, but by a unit test tool, would in my eyes offer more gain for SSU, than fast new features. What does it bring us to have the features run in a fast way quickly, when this code is hard to be replaced?

True. Maybe that should be made the top priority, a code clean up? No new features until this is completed.

The Ku-band antenna could be done independent of this, since it has a large set of special electronics for that, but the MPS dumps would require the Shuttle Bus system. And the displays could also be done independent, but would require more time, since there is a lot of behavior behind them.

OK. Could the Ku dish gimbals be implemented so that they can for now be controlled by Computerex' RemoteAnimation MFD?

That'll be my last request ahead of the code clean-up.

 

[Urwumpe]

True. Maybe that should be made the top priority, a code clean up? No new features until this is completed.

No problem with new features for me currently, since we are not having the planned reentry phase features done for the "next release". I just mean that the transition to a cleaner code should be done at a higher priority than just adding these features ASAP.

Also, SSU is a huge project for just three point five coders, we need a good structure for compensating our weakness in numbers. We would even need more coders, if we could also integrate them, which again needs more structure. We can't hack all things into Atlantis.h and make all things depend on it.

The better the code structure is, the easier it is to integrate even less experienced coders into the project.

OK. Could the Ku dish gimbals be implemented so that they can for now be controlled by Computerex' RemoteAnimation MFD?

Is already implemented as animation for quite a while, missing is only the code to point it.

That'll be my last request ahead of the code clean-up.

A complete code clean-up should maybe take place when the mandatory features for the next version are done. If we aren't done with it then.

 

[DaveS]

Is already implemented as animation for quite a while, missing is only the code to point it.

Then I just need to find how how exactly the RAMFD works as currently when I use it with SSU it does nothing. Could you provide a list in numerological order of the various animations we currently have in the main SSU vessel?

 

[Urwumpe]

Then I just need to find how how exactly the RAMFD works as currently when I use it with SSU it does nothing. Could you provide a list in numerological order of the various animations we currently have in the main SSU vessel?

Can take a while. Would it be enough for you if I just dump all animation codes in a text file?

 

[DaveS]

Can take a while. Would it be enough for you if I just dump all animation codes in a text file?

For now, yes.

 

[Urwumpe]

For now, yes.

Ok, THIS can be done...when I am back home. OrbiterLog or special file?

 

[DaveS]

Ok, THIS can be done...when I am back home. OrbiterLog or special file?

Take it to a special file.

 

[Urwumpe]

ANIMATION LOG
anim_door    137 ( 0x89)
anim_rad    138 ( 0x8a)
anim_gear    143 ( 0x8f)
anim_kubd    144 ( 0x90)
anim_kualpha    145 ( 0x91)
anim_kubeta    146 ( 0x92)
anim_chute_deploy    147 ( 0x93)
anim_chute_spin    148 ( 0x94)
anim_elev    149 ( 0x95)
anim_bf    150 ( 0x96)
anim_laileron    151 ( 0x97)
anim_raileron    152 ( 0x98)
anim_rudder    153 ( 0x99)
anim_spdb    154 ( 0x9a)
anim_camFLyaw    155 ( 0x9b)
anim_camFLpitch    156 ( 0x9c)
anim_camFRyaw    157 ( 0x9d)
anim_camFRpitch    158 ( 0x9e)
anim_camBLyaw    159 ( 0x9f)
anim_camBLpitch    160 ( 0xa0)
anim_camBRyaw    161 ( 0xa1)
anim_camBRpitch    162 ( 0xa2)
anim_letumbdoor    163 ( 0xa3)
anim_retumbdoor    164 ( 0xa4)
anim_ssmeTyaw    165 ( 0xa5)
anim_ssmeTpitch    166 ( 0xa6)
anim_ssmeLyaw    167 ( 0xa7)
anim_ssmeLpitch    168 ( 0xa8)
anim_ssmeRyaw    169 ( 0xa9)
anim_ssmeRpitch    170 ( 0xaa)
anim_adpl    171 ( 0xab)
anim_adpr    172 ( 0xac)
anim_stzd    173 ( 0xad)
anim_styd    174 ( 0xae)

 

[DaveS]

Thanks for the log. What do the various numbers refer to?

 

[Urwumpe]

Thanks for the log. What do the various numbers refer to?

The format is:

1. name of variable.
2. decimal handle
3. hexadecimal handle

 

[DaveS]

Could check in compilable versions of EIU.h and BIU.h? They're giving me 83 errors when I try to compile the latest revision of the sources.

 

[Urwumpe]

Could check in compilable versions of EIU.h and BIU.h? They're giving me 83 errors when I try to compile the latest revision of the sources.

Added the EIU stuff, BIU.h should have been up to date. I also added the latest changes to the Atlantis.cpp, including a central SSUOptions class, for making it easier to store central SSU options, like which computer/IDP model should be used. Could also be used for switching other static options, that are not part of mission, hardware or scenario.

Also, I committed the option to write a HTML file which contains a report on the subsystem performance.

 

[DaveS]

Added the EIU stuff, BIU.h should have been up to date. I also added the latest changes to the Atlantis.cpp, including a central SSUOptions class, for making it easier to store central SSU options, like which computer/IDP model should be used. Could also be used for switching other static options, that are not part of mission, hardware or scenario.

Also, I committed the option to write a HTML file which contains a report on the subsystem performance.

Ooops! You forgot to check in SSUOptions.h. And it still complains about about EIU.h:

1>e:\shuttle ultra\orbitersdk\space shuttle ultra\dps\GPC.h(113) : error C2259: 'dps::BIU' : cannot instantiate abstract class
1>        due to following members:
1>        'dps::BUS_COMMAND_WORD dps::BIU::busCommand(dps::BUS_COMMAND_WORD,unsigned long,short *)' : is abstract
1>        e:\shuttle ultra\orbitersdk\space shuttle ultra\dps\BIU.h(97) : see declaration of 'dps::BIU::busCommand'
1>        'void dps::BIU::busCommandPhase(void)' : is abstract
1>        e:\shuttle ultra\orbitersdk\space shuttle ultra\dps\BIU.h(98) : see declaration of 'dps::BIU::busCommandPhase'
1>        'void dps::BIU::busReadPhase(void)' : is abstract
1>        e:\shuttle ultra\orbitersdk\space shuttle ultra\dps\BIU.h(99) : see declaration of 'dps::BIU::busReadPhase'

 

[Urwumpe]

Ooops! You forgot to check in SSUOptions.h. And it still complains about about EIU.h:

Doesn't complain here, I'll check why it is so.

Argh, found it. You misled me by writing EIU.h, in reality it is GPC.h/GPC.cpp, which I didn't commit yet because it was WIP. Now it should work.