Space Shuttle Ultra development thread

[DaveS]

Yes, I noticed the same when looking at the auxiliary attachment arrow. To correct it, one constant in Atlantis.h would need to be corrected, but I have no idea where we we want to have the docking port. I think good would be the position for hard dock.

Currently the docking ring on the mesh is the FINAL position which is the fully retracted position for harddock.

 

[Urwumpe]

Currently the docking ring on the mesh is the FINAL position which is the fully retracted position for harddock.

Yes. That's IMHO also the position we should have our docking port.

 

[Donamy]

Could we have two different docking ports ? One for hard and one for soft,two different meshes maybe ?

 

[SiameseCat]

I think we should move the docking port based on the state of the docking ring. When retracting the ring while docked, we can create temporary attachments to hold the vessels together.

 

[DaveS]

I think we should move the docking port based on the state of the docking ring. When retracting the ring while docked, we can create temporary attachments to hold the vessels together.

Sounds like the best way.

 

[GLS]

On the .scn files, I can't use any line starting by "MPS" because panel R2 will *eat* it....hsnap:
I think we should really stop for a few minutes and decide on a system for the .scn file. Perhaps something like a 3 or 4 (lowercase) letter prefix followed by the name of the parameter (uppercase)... Ex: mpsSTUCKVALVE, pr4ALOTOFSWITCHES, gearFLATTIRE, rmsSHOULDERPAIN....

 

[Urwumpe]

GLS: I think about changing the syntax for the scenario file the following way:

Subsystems get started by a line
SUBSYSTEM name (followed by data reserved for future extension)

and end with a line "SUBSYSTEM." or better... (I think "BEGIN_SUBSYSTEM"/"END_SUBSYSTEM" would be cooler, but I don't know how orbiter likes it)

For everything between these, the subsystem itself has full autonomy.

Similar for the panels, which will get handled by "PANEL panelname" followed by a number of switch positions until "PANEL." or "END_PANEL".

 

[GLS]

Your solution is nice but I think it would need more overhead.... mine is simple, but not pretty.........

 

[Urwumpe]

Your solution is nice but I think it would need more overhead.... mine is simple, but not pretty.........

Well, the overhead might be controllable - instead of parsing one line and give control back to the main loop, each subsystem has it's one loop. Much more overhead is also possible...(Parsing the scenario in one pass and allow the subsystems to access stored constants)

The problem i have not solved yet, is the chain of responsibility pattern - we will have such a pattern in the parsing of subsystems, but how can we implement it most effective?

The problem I wanted to solve this way is more: We will get an extreme number of subsystem classes in SSU, which all want to save and store parameters. With your solution, we will quickly have to use huge numbers of prefixes, and locate them for every line we read in the file. You are right, from the point of view of a single subsystem, your idea is simple, but what if you have to deal with around 50 subsystems?

We will have at least one subsystem object for each LRU in the Shuttle, maybe even more for motors and actuators.

 

[SiameseCat]

Here's my suggestion: we have an array of strings. Each time we find the start of a subsystem block, we read the entire block into the array, then pass it it to the subsystem to read the data.

 

[Urwumpe]

I would suggest string pairs then, using a key and the data.

Also I would suggest dropping the data after the loading scenario phase, as it could use a serious amount of memory finally, which we don't need.

 

[SiameseCat]

I would suggest string pairs then, using a key and the data.

Also I would suggest dropping the data after the loading scenario phase, as it could use a serious amount of memory finally, which we don't need.

We can probably use the same array repeatedly and then delete it once the scenario is fully loaded.

Another possible method of loading data is to store the index of the subsystem corresponding to the current block, and pass each individual string to that subsystem for processing. This would avoid having to store strings in an array.

 

[Urwumpe]

Another possible method of loading data is to store the index of the subsystem corresponding to the current block, and pass each individual string to that subsystem for processing. This would avoid having to store strings in an array.

I think that idea is not really bad, something like that could sure be done and would allow extending the format easily.

 

[Donamy]

I've sent Dennis the new "Standard" SSUVC. Almost 10 meg and 42 textures.

 

[DaveS]

I've sent Dennis the new "Standard" SSUVC. Almost 10 meg and 42 textures.

Can't wait to see it! Does this mean you could start working on the STS-125 payloads now?

 

[Donamy]

If Dennis doesn't need more mesh work done from me, then yes.

 

[DaveS]

If Dennis doesn't need more mesh work done from me, then yes.

Great! Just a FYI: KSC PAO has uploaded several nice photos of the various STS-125 payload carriers: http://mediaarchive.ksc.nasa.gov/search.cfm?cat=180

 

[Urwumpe]

I only need some missing textures now, otherwise I have for the moment no further requests for panels. It looks already great.

I have an idea for making the payload panel code more robust, but this would require some more mesh work on the VC. Not sure if all people agree to this, it is currently just a very crude idea. Instead of adding the optional meshes to the VC mesh as overlay, we make the texture, where the current optional panels are, look like empty openings with some unconnected cable bundles visible (would have to be fictional, as I have no photos). For missions without RMS for example, we would place a PanelA8Empty.msh at this place, without any animations. When a RMS is flown, we place a PanelA8RMS.msh at this place, and define the animations for it. (When swapping the panels during ground overhaul, we could made the old panel invisible for a while, by setting it MESHVIS_NEVER, until we installed the new panel)

The mid deck could also use some low thrust work, as it is still a bit crude, but it is not like our add-on depends on it.

When I upload the new VC mesh, the PanelA8 code needs to be revamped. I would suggest the following code changes:

The current PanelA8 code gets turned into a RMS subsystem. Either as simple single class or split into robot arm, motors, cameras and MCIU (which would allow a more detailled simulation, especially of failures)

The panel related code gets moved into a new class vc:anelA8, which becomes an optional panel.

BTW, could this image be helpful for improving the umbilical well area? As far as I remember, it is just a flat texture currently, while it actually even gets hydraulically retracted before closing the umbilical doors.

 

[DaveS]

BTW, could this image be helpful for improving the umbilical well area? As far as I remember, it is just a flat texture currently, while it actually even gets hydraulically retracted before closing the umbilical doors.

Yes and the main umbilical plates actually gets angled during Orbiter/ET mate operations in the VAB so that orbiter umbilical plates end up 100% pure vertical to match up with the corresponding plate on the ET.

 

[Donamy]

A blank panel for the A8 panel would be easy, but would it interfer with the animations not having all the switch groups ?