Space Shuttle Ultra 1.25 Revision B development

[Urwumpe]

Ok, lets gather all identified bugs and development tasks by the development team here.

+++ Please don't use this thread for reporting bugs in SSU 1.25 or asking for support, I will erase such posts without thinking or care. +++

I don't want this thread to be cluttered with such requests, especially since this forum had shown often enough, that people are not able to read the first pages of a thread to find out that their "bug" has already been fixed. If the developers find a software bug, we will organize it's removal here.
I so far have the missing feature of the ASCENT TRAJ display, which should get enabled and the task of improving the payload bay (and others) camera handling.

 

[DaveS]

Known bugs with LC-39A:

• Orbiter Access Arm is too long and makes th White Room collide with the orbiter when extended. Fixed in next version of the FSS mesh.
• GH2 vent hardline doesn't line with the GH2 vent umbilical port on on the ET intertank. Fixed in the next version of the FSS mesh.
• GVA GOX vent ducts become decoupled when the hood is raised. Not yet fixed.

 

[DaveS]

Just had an idea I thought I would throw out here. It's not a request or anything, just an idea that occurred to me.

For the OTV camera system implementation, how about we use attachment points? The actual cameras are vessels that you can switch focus to attached to the attachment points.

I tried an early version of this concept before lost everything where the cameras was actual vessels and I got the views to match the real ones pretty good.

 

[Urwumpe]

Just had an idea I thought I would throw out here. It's not a request or anything, just an idea that occurred to me.

For the OTV camera system implementation, how about we use attachment points? The actual cameras are vessels that you can switch focus to attached to the attachment points.

I tried an early version of this concept before lost everything where the cameras was actual vessels and I got the views to match the real ones pretty good.

Well, then we could also remove the attachments and just use either independent landed vessels or make them part of the vessel.

If you want a better dialog to select the camera views on FSS/RSS or MLP, there is also a lot of stuff possible, including automatically switching focus to another vessel.

 

[DaveS]

Well, then we could also remove the attachments and just use either independent landed vessels or make them part of the vessel.

If you want a better dialog to select the camera views on FSS/RSS or MLP, there is also a lot of stuff possible, including automatically switching focus to another vessel.

The main idea was to have one mesh file for all the cameras(the camera+the pan/tilt assy) with the supports being part of the actual FSS/RSS/hardstand meshes. That way we would also only need one config file with proper offsets being on the pad side, not the camera side.

That we also get rid of the pre-set camera views which is only educated guess-work on my part(see the STS-126 launch scenario).

I have an actual OTV Reference Guide from October 1987. A few things have changed since then with most notable item being relocation of camera x01 but other than that, it is still 100% accurate even to this day with all the pad mods that have been done over the years.

 

[Urwumpe]

DaveS: Can't you just copy the PTA/Cams into the meshes as pattern? Animating them object oriented is no problem, as long as they are really all equal except maybe the neutral position.

 

[DaveS]

DaveS: Can't you just copy the PTA/Cams into the meshes as pattern? Animating them object oriented is no problem, as long as they are really all equal except maybe the neutral position.

They're identical in design and function: A white camera tube with a lens in the center mounted on a pan/tilt assy which in turn is mounted on a support strut.

For example: Take a look on the MLP. There all the MLP mounted OTV cameras have been implemented. They all have meshgroup names starting with "OTV".

 

[Urwumpe]

They're identical in design and function: A white camera tube with a lens in the center mounted on a pan/tilt assy which in turn is mounted on a support strut.

For example: Take a look on the MLP. There all the MLP mounted OTV cameras have been implemented. They all have meshgroup names starting with "OTV".

So, it should be no problem to do them all in the code and not have many microvessels in the F3-list. We could use the clbkConsumeBufferKey trick to switch automatically to the right camera if switching focus to another vessel.

 

[DaveS]

So, it should be no problem to do them all in the code and not have many microvessels in the F3-list. We could use the clbkConsumeBufferKey trick to switch automatically to the right camera if switching focus to another vessel.

Sounds like a better solution. We could try with the MLP and implement it from there.

 

[Urwumpe]

Sounds like a better solution. We could try with the MLP and implement it from there.

Fine. What about adding a list box of OTV cameras and a dialog area to pan/tilt the selected camera.

 

[DaveS]

Fine. What about adding a list box of OTV cameras and a dialog area to pan/tilt the selected camera.

Works for me. Subset of the LC-39 control dialog maybe, like we have for the orbiter?

 

[Urwumpe]

Works for me. Subset of the LC-39 control dialog maybe, like we have for the orbiter?

Yes. Maybe with a keyboard shortcut, we currently don't have too many keyboard short cuts on it.

Any other suggestions on the LC-39 which require code work?

 

[DaveS]

Any other suggestions on the LC-39 which require code work?

Actually not. Other than a properly coded GLS that halt the countdown at the proper times. For example, if the APUs have not been been started or reached nominal pressure, the GLS will issue a HOLD at T-4 minutes.

 

[Urwumpe]

Actually not. Other than a properly coded GLS that halt the countdown at the proper times. For example, if the APUs have not been been started or reached nominal pressure, the GLS will issue a HOLD at T-4 minutes.

I can maybe do something like that soon, would just need to get some communication gear done.

 

[DaveS]

I can maybe do something like that soon, would just need to get some communication gear done.

OK, you have a good handle on how the GLS operates? If not, this is a great GLS introduction read thanks to a former CGLS: http://forum.nasaspaceflight.com/index.php?topic=2078.msg51752#msg51752

 

[Urwumpe]

I have read it. I also heard that the S0007 is somewhere around with more information, but my usual intelligence channels are getting dead-ends.

 

[DaveS]

I have read it. I also heard that the S0007 is somewhere around with more information, but my usual intelligence channels are getting dead-ends.

You can get the entire S0007 vol. I-IV for STS-103(Dec. 1999) at http://insideksc.com. Same thing with the LC-39 OTV Reference Guide I mentioned earlier.

 

[Urwumpe]

Ok, got to read it now, and it is really inspiring.

I think I can do something... What do you think about having software agents take the roles of the mission controllers and store their communication in special mission transcript files, one file for each communication circuit? The communication and actions are pretty machine compatible described in the documents, should be possible to have the actions and decisions hard-coded into a DLL.


And I had the XXXX TRAJ wrong - the Delta-H indicator is not shown during a nominal ascent, they only appear on RTLS.

 

[DaveS]

Ok, got to read it now, and it is really inspiring.

I think I can do something... What do you think about having software agents take the roles of the mission controllers and store their communication in special mission transcript files, one file for each communication circuit? The communication and actions are pretty machine compatible described in the documents, should be possible to have the actions and decisions hard-coded into a DLL.

Sounds good.

 

[Urwumpe]

Sounds good.

I doubt I can build it into the Patch though, would be a longer task item. First I would need a generic audio circuit and the functions around to handle the messages.

Where should we store such log files? I current favor "\data\SSU\Mission\transcripts" and then have one plain text file per communication circuit.

I would recommend using a compressed format for the audio communication and turn it into human readable form only when needed, for display or for logging.