Criticism of Space Shuttle Ultra

zerofay32

Buckeye
Joined
Feb 6, 2008
Messages
471
Reaction score
2
Points
16
Location
Columbus, Ohio
I understand that not everyone has the time to read 100,000+ pages of NASA documents to learn how to run a (free) computer simulation, but as SSU continues, the 'cost' of entry is only going to get higher as SSU becomes more complex. You will always have people who don't RTFM, and with SSU (currently and in the future) these will be the most vocal, and annoying, sinners.

Personally, other than a change log/added component list, the included documentation is where it should be. Is it a WIP? Of course, just like the addon as a whole. But other than covering the Orbiter specific quarks of running a space plane with a keyboard and mouse, the SSU manual should point the user to the NASA documentation and call it a day. No need to reinvent the wheel, as long as SSU is accurate in regards to the NASA docs.

In a full/competed addon, if a user complained that they didn't know what switches work and what switches didn't and was frustrated as a result, this would be a real problem. But in a WIP that has been 'released' largely incomplete (ie early versions of SSU), the end user needs to just deal with it and realize that it is an unfinished product. Again, would a change log help? Sure but only if the user reads the included documentation. Even then, they will still need to do their own homework and read the NASA docs to learn about what is working, and will most likely still complain about the complexity and level of knowledge needed to start.

Tutorials are needed for sure but will need to constantly be updated as SSU continues. In-sim promps are also a 'fix' but turns SSU into Space Shuttle Mission Simulator 2007(TM). If all a user wants to do is be told when to click this button or that, SSMS is still avalible to buy. (I would never recommend it to anyone that loves STS)

If you actually would like to learn about the Shuttle (and rocket science, orbital mechanics, NASA operations) then you have to put in the time and effort to learn these things. And of coarse, plans are in place to add features to help the would-be shuttle commander complete the mission (AI crew, Mission Control, ext)

SSU is not a direct replacement for either the Stock Shuttle or Shuttle Fleet. It's goal is in the same vain as NASSP.

Sorry, became more of a rant then I intended.... :lol:
 

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
Personally, other than a change log/added component list, the included documentation is where it should be. Is it a WIP? Of course, just like the addon as a whole. But other than covering the Orbiter specific quarks of running a space plane with a keyboard and mouse, the SSU manual should point the user to the NASA documentation and call it a day. No need to reinvent the wheel, as long as SSU is accurate in regards to the NASA docs.

What about a less digital approach of "WIP vs. Final", with a gradual transition? Like:

During development: NASA FDF, development documentation.
As WIP release: NASA FDF, Change log, Short CHM help
Final: SSU Manual, supplemented by NASA FDF. Full CHM Help.

I think the problem is not that the information stands in the NASA FDF. Thats absolutely correct. But those FDF are not easy to read and if you are no SSU veteran, you might not know, which FDF applies now and where you can find which procedure. Especially the ascent CL with its cue cards and flip book is pretty tough to read in PDF format. And the acronyms are also not helping you. The language is not English, its STS.

I think the primary criticism right now is, that SSU is leaving the new player alone far too often. Maybe we should be a bit more newb tolerant there.

Also, the idea of a change log makes sense, but then, I am strongly against using a manual solution, that is a dumb task for a dumb computer, IMHO.
 

zerofay32

Buckeye
Joined
Feb 6, 2008
Messages
471
Reaction score
2
Points
16
Location
Columbus, Ohio
I think the problem is not that the information stands in the NASA FDF. Thats absolutely correct. But those FDF are not easy to read and if you are no SSU veteran, you might not know, which FDF applies now and where you can find which procedure. Especially the ascent CL with its cue cards and flip book is pretty tough to read in PDF format. And the acronyms are also not helping you. The language is not English, its STS.

I see what you're saying. There is also the wrinkle of custom missions. Mission Developers will need to create their own mission supplements to insert into the generic FDFs. Also, any payload integration is going to be interesting for sure.

Laying out which checklist to use, and when, is fine but I don't understand how that is not self explanatory (ie accent CL = accent, entry CL, post-insertion, ext) Also a large number of items in the checklists can be totally ignored at this time anyways. The Flipbooks in general are 'for reference' and info that for the CDR or PLT should be more or less committed to memory. As you say, they are not meant to be read and certainly not meant to teach.

Don't know how to get around the acronyms. Most NASA docs have an acronyms dictionary included. It's just another thing the user has to learn in order to fly STS... :shrug: If users want to use SSU a certain level of knowledge and proficiency MUST be reached for full enjoyment, be that NASA Speak or orbital mechanics.

EDIT: In reference to a change log/what is working... I wonder if including switch diagrams (akin to those in the enty switch config section) that shows what switches function would help the user figure out what CL items are necessary or not? This could be included in the SSU manual along with a change log that would cover the additions that are more 'under the hood'.
 
Last edited:

Urwumpe

Not funny anymore
Addon Developer
Donator
Joined
Feb 6, 2008
Messages
37,588
Reaction score
2,312
Points
203
Location
Wolfsburg
Preferred Pronouns
Sire
EDIT: In reference to a change log/what is working... I wonder if including switch diagrams (akin to those in the enty switch config section) that shows what switches function would help the user figure out what CL items are necessary or not? This could be included in the SSU manual along with a change log that would cover the additions that are more 'under the hood'.

I see your idea... and I possibly have an idea for a new Orbiter tool.

What about having some pages at the end of our manual that show in an info graphic like style, which switches and subsystems are working and which need more work?

Like having a short input file with the feature states, a definition of the graphics and a tool produces the tex files for the pages... would not need to be much code.
Not sure if it could even be made with custom laTex commands.
 
Top