SSU Documentation

[zerofay32]

I was in communications with Urwumpe about a month ago about helping with creating the documentation for SSU.I am still interested. He pointed me to the idea of using laTex to create the actual files, so I did some research and created a test doc. I recreated the SSU v1.25 manual in laTex (those are attached to this post in the form of the .txt file that is a copy of the latex “code” and the resulting PDF).

Further development has stopped on my part due to real life but now I wanted to continue to pursue the possibility of working on the docs. My intention with this initial post is to get feedback from the others on this game plan and approval to perhaps do this work for SSU.

 

[Urwumpe]

The general direction looks good, I would just do some small cosmetics on the visual side, for example making a helvetica font standard. But that template work can happen also later.

More important for me is that we can have the manual developed over SVN and spread over multiple files if possible.

 

[SiameseCat]

Sounds like a good idea to me. It'll also be great to have up-to-date documentation.

 

[Donamy]

Let me know if you need any screen shots.

 

[zerofay32]

Methodology

Well, great then. The next task then would be for Urwumpe to tell me the basics of using the SVN. I've read how one can reference several separate .tex files then have them combined into one PDF when it is created, which is I think what Urwumpe was talking about.

Long term, I think the docs should be broken in to sections like:

STS:
basicly used to go over anything that can't be directly referenced from the SCOM like keystrokes (if there are any), dialog boxes, ect. (Otherwise we simply point the user to the nessesary SCOM section.

Ground OPS:
With the pads nearly finnished and with the potental for stacking operations, this section/doc would be used for things from Wheels Stop to the Terminal Countdown (whatever is actualy simulated in this area). For now it would mainly be how to control things like the crawler, MLP, OWP, RSS, ect.

Terminal Countdown:
a section/doc that describes what needs to be done to complete the countdown (say T-1 day to T-0 including RSLS abort and scubs) once (if ever) implimented (at the very least, it can be a small section the describes the current, mostly auto, countdown)

Mission specific Documentation:
This is were it can get tricky. For historical missions (even "simple" ones like STS-1, 2, and 3) how much material do we include in the base install? Do we include mission specific checklists (are these created "in house" or are they NASA copies)? Do we include mission timelines and Flight Plans or do we just tell the user the Launch date and the Landing date and let them figure the rest out on their own? Also this section may include explanation of items included in the Mission File for the specific mission. EXAMPLE, the Doc for STS-1 would give an overview of what one would find in the mission file for STS-1. (The Documentation of the MISSION FILES themselves would be covered in its own section).

Scenario Files, Mission Files, and Payload Handeling:
This section would be used by people who want to create there own missions or to developers looking to create or adapt payloads to be used with SSU. It can range from simply describing and documenting all the required perameters that need to be present as well as describing all available entries.

External Programs Doc:
Urwumpe has mentioned that there may be small external programs that are used with SSU (his example was a program that creates mass memory tape images). Any of these would either be together in a grouped Doc or in seprate docs for each.


Now, don't think I've gone off the deep end.

For the short term (ie before the next public release) I'm thinking of continuing with the setup we already have. One manual that contains the descriptions and some checklists.

The first goal is to update the current manual with all the stuff that has been added (or not even covered) since the v1.25 doc. Once I get cought up, maintaining the manual and spliting it into the aformentioned sections will be much easier.

What do ya'll think? questions...? comments...?

 

[Donamy]

To save file space, could the missions be downloaded seperately, and a program to load them into the correct folders ?

 

[Urwumpe]

I would say, mission specific manuals should be done extra, maybe by using the templates of the main SSU manual. This way we can also distribute the missions as packs without having to blow up the manual.

About the tools, I would say too development specific stuff should go into an extra manual, explaining what exists already and how to use it.

The user manual should get all the tools needed for flying a mission or making new missions, also we should maybe consider doing a special "SSU Payloads manual" to explain details about these.

Essentially: If you read the user manual, you should know how to fly SSU. You already know how to use mission planning or mission control tools, but not too the extend of being completely able to make your own missions easily... its just the basics needed for for example dealing with scrubs or turn arounds. Stacking operations should be explained, but separate enough from the other parts, that you could fly a mission without knowing it.

The User manual should already contain information for using "cooperative multiplayer" in the sense of being able to support or observe a mission by a mission control tool, like Poscik currently develops.

 

[zerofay32]

So how about this set up.

Base SSU Docs

• SSU Manual (includes Mutiplayer ops, Scenario and mission file stuff)
• Ground Ops Manual (maybe seprate)
• SSU Payloads Manual

Individual Mission Packs w/ seprate Manuals/FDFs

Developer and Tools Manuals

This way we create three main groups that are at the top of the overall structure.

Also, how do you feel about directly referencing the SCOM once a subsystem is "fully simulated" or even "acuratly simulated"? That would decrease the size of the base manual as complexity increases and would keep us from rewriting whats already been writen.

EDIT: Would we "endorse" a specific Mutiplayer?

 

[Urwumpe]

That structure is fine for me. The crawler can maybe be included in the ground operation manual, despite really already being worthy its own manual.

Also, how do you feel about directly referencing the SCOM once a subsystem is "fully simulated" or even "acuratly simulated"? That would decrease the size of the base manual as complexity increases and would keep us from rewriting whats already been writen.

Should be preferred. But maybe we can include an own summary of the subsystem in the manual, so even if you don't read the SCOM (and work books) completely, you can understand its role and what the lack of it means. Also we should maybe conclude every chapter with references to NASA literature and reports under the heading "Would you like to know more?"

 

[zerofay32]

That structure is fine for me. The crawler can maybe be included in the ground operation manual, despite really already being worthy its own manual.



Should be preferred. But maybe we can include an own summary of the subsystem in the manual, so even if you don't read the SCOM (and work books) completely, you can understand its role and what the lack of it means. Also we should maybe conclude every chapter with references to NASA literature and reports under the heading "Would you like to know more?"

That's what I was hoping to do. Give a general blurb about a subsystem like what it is, what it does, and how it impacts typical mission procedures. Then add a reference to the SCOM section for further, and fuller, reading and understanding.

EDIT: And I forgot about the workbooks. I only have a few myself but I've read the SCOM cover to cover.

 

[Urwumpe]

EDIT: Would we "endorse" a specific Mutiplayer?

No. Actually I don't even want to recommend any currently because otherwise we get into hell for having to do support for the multiplayer despite having more problems and work with our own stuff.

I called it multi-player in the sense of permitting multiple players taking part in a mission, that somebody flies as commander, others as flight controllers or spectators. It is the best option we could get working on our own and is the kind of multi-player that works best for us.

It also permits some cheat for us... human flight controller interfaces spare us from having to develop really good AI flight controllers for managing a mission. Let a VSA handle this.

 

[zerofay32]

Ah. I get ya.

 

[Urwumpe]

The developer manuals should also get a section with contribution guidelines...once we can define some better ones than "You want to contribute, fine, you are welcome".

 

[zerofay32]

The developer manuals should also get a section with contribution guidelines...once we can define some better ones than "You want to contribute, fine, you are welcome".

That will be up to you and the others to define those guidlines. Just so you know.

 

[zerofay32]

Mission Files

Alright, I've been gathering my notes and going through some of the other SSU threads (mainly the v1.25 bug thread). First I want to hammer down the Mission File entries. Here is a list of entries that I have found so far and what, if anything, I can discribe about them:

NAME (does this have to reflect anything specific? like Mission file name, name of the shuttle vessel in the scenario file or something else?)
Orbiter (I beleave that this determines the nameplate on the shuttle or does it determine the mesh used?)
OrbiterTexture (this entry determines which texture is used on the orbiter) Avalible entries are: Early_Columbia, LateColumbia, and Atlantis_Original.
TargetInc Sets the target Inclination for the AP. (what in the range of this entry?)
TargetLan Sets the target Lan for the AP. (exactly how is this used and what is the range of accepted values?)
MECOAlt Sets the target altitude for MECO. (what is the units, km, nm, other?)
MECOVel Sets taget velocity to be acheaved at MECO. (Units? km/s, fps, other?)
MECOFPA (Just not sure what this one is and don't want to guess wrong)
Use ExtAL true/false - determines if the External Airlock is present.
UseRMS true/fase - determines if the SRMS is present on the Port PLB sill
UseODS true/false - determines if the Obiter Docking System is present on the Ext A/L. (Does UseExtAL must be true for this entry to work? or if this entry is true does it force the A/L to be present?)
MaxSSMEThrust sets the maximum thrust of the SSMEs. 100, 104, (109?)
UseStbdMPM true/false - determines if the Starboard MPMs are present but dose not create the OBSS. OBSS must be defined in the Scenario file. (Does this do anything to the attachment points of the orbiter? ie make/move one to be used by the OBSS or is the OBSS attachment pt always there?)
PayloadZPos1 (what are all the payload entries for the mission file and what do they determine?)

Thats all I was able to figure out for the mission file. Let me know what I have wrong, or right, and any entries that I missed.

Andrew

 

[Urwumpe]

FPA = Flight Path Angle.

 

[zerofay32]

FPA = Flight Path Angle.

What does it do?

 

[Urwumpe]

What does it do?

Defines at which angle above the horizon the velocity vector should be at MECO.

 

[zerofay32]

Ok, makes sense. Any comments on any of the other entries?

 

[SiameseCat]

Alright, I've been gathering my notes and going through some of the other SSU threads (mainly the v1.25 bug thread). First I want to hammer down the Mission File entries. Here is a list of entries that I have found so far and what, if anything, I can discribe about them:

NAME (does this have to reflect anything specific? like Mission file name, name of the shuttle vessel in the scenario file or something else?)
Orbiter (I beleave that this determines the nameplate on the shuttle or does it determine the mesh used?)
OrbiterTexture (this entry determines which texture is used on the orbiter) Avalible entries are: Early_Columbia, LateColumbia, and Atlantis_Original.
TargetInc Sets the target Inclination for the AP. (what in the range of this entry?)
TargetLan Sets the target Lan for the AP. (exactly how is this used and what is the range of accepted values?)
MECOAlt Sets the target altitude for MECO. (what is the units, km, nm, other?)
MECOVel Sets taget velocity to be acheaved at MECO. (Units? km/s, fps, other?)
MECOFPA (Just not sure what this one is and don't want to guess wrong)
Use ExtAL true/false - determines if the External Airlock is present.
UseRMS true/fase - determines if the SRMS is present on the Port PLB sill
UseODS true/false - determines if the Obiter Docking System is present on the Ext A/L. (Does UseExtAL must be true for this entry to work? or if this entry is true does it force the A/L to be present?)
MaxSSMEThrust sets the maximum thrust of the SSMEs. 100, 104, (109?)
UseStbdMPM true/false - determines if the Starboard MPMs are present but dose not create the OBSS. OBSS must be defined in the Scenario file. (Does this do anything to the attachment points of the orbiter? ie make/move one to be used by the OBSS or is the OBSS attachment pt always there?)
PayloadZPos1 (what are all the payload entries for the mission file and what do they determine?)

Thats all I was able to figure out for the mission file. Let me know what I have wrong, or right, and any entries that I missed.

Andrew

MECOAlt: alt in km
MECOVel: speed in m/s
MECOFPA: angle in degrees
TargetInc: inclination in degrees. Should be between 0 degrees and 180 (in practice, max/min values will be limited by latitude of launch site).
TargetLAN: ignored at the moment; angle in degrees from -180 to +180

OrbiterTexture: texture used for shuttle mesh; in theory this can be any texture in the Textures/SSU folder.
Orbiter: Name painted on shuttle; requires 'EnableWingPainting' to be TRUE (ignored otherwise)