Criticism of Space Shuttle Ultra

[Urwumpe]

I hope nobody complains about me starting a new thread for this, I think it distracts from the question, if SSU will support Orbiter 2016 soon. And I am sure, its better to keep the topic where the responsible people will sure read it.

I branched off from here: http://orbiter-forum.com/showthread.php?p=541208&postcount=58

Sorry to step in guys and please note this NOT a critique to the devs: SSU is probably, as you say, the "future Shuttle" for Orbiter.

First of all, nobody of us is immune against criticism, we are all learning and making errors. And there are good reasons for criticism, as I see it as involved. We are nearing the tenth anniversary of SSU and what have we achieved in that time? Should I be really sarcastic, you can really claim SSU will always stay the future Shuttle for Orbiter.

On the other side, we have really achieved great things in that time. Not always visible in the add-on. We have dug out more data, information and documentation about the Space Shuttle than many other people in the world. In the beginning of the project we discussed about missing switches in the Atlantis VC. Now we discuss actual logic diagrams and blueprints, about relay logic and even errors in NASA documentation.

SSU was about keeping the Shuttle program in all its glory and madness alive in Orbiter and maybe we got too similar to NASA in the process.

But in terms of the add-on there is also a lot achieved, that made it into Orbiter, and there will be more. Or look at the implementation of the crawler now. SF models more of the surrounding infrastructure and that is something we still lack, because our focus was on other topics.

I know the enormous effort and dedication that you guys are putting in such an ambitious project but let me say something from the "user" side: SSU development started something like 7-8 years ago with huge expectations from everybody in the community. We all had the feeling that the Fleet was eventually getting kind of obsolete with no further development by the author and I think Shuttle enthusiats like hutchinson66 would be very happy to fly SSU on their STS missions.

Wrong there though. We never wanted to replace SF. At one place early in the project, there was a short moment when we had too choose between becoming a SF clone first and then adding more detail or dive into the details and eventually support full missions like SF does. With SF returning shortly later, the choice for the latter was made easy for us. We let SF be SF and SSU be SSU. We are looking at the same spacecraft from different angles (In terms of SSU, I fear we are lost somewhere in the pipes in the aft compartment).

And yes, SSU is a very long-running project and every next release is a miracle to me. Another 8 years of SSU and we have to worry about our contributors pushing up the daisies. Its really a good question to ask, if all of us will ever be alive to see a complete SSU. But we can only work so fast. SSU does not put food on the table and depending on donations would kill the project eventually. We have to stay non-commercial and free from "investor pressure".

IMHO SSU has one big problem:it is very difficult to understand how it works (and what works so far and what does not). The fact that it is still under development together with (let me say it) the lack of a complete documentation on how to use it (or maybe some tutorials) generates quite a lot of frustration.

I think the key question is: Can a single astronaut fly the Space Shuttle all alone? Right now we expect it somehow. SSU is a huge construction site, and at every corner, you need to improvise. Its too much workload to do a mission without getting frustrated.

In my opinion, we can fix this without changing the character of the add-on. But this takes time and more work. We will add a mission control to SSU rather soon and I think having AI astronauts on board could also allow making SSU easier to fly.

Of course, it will always be one level harder to fly than SF. Also, the more we do in that direction, the harder it will become to make missions for SSU, regardless how good the tools for that task become. The more intelligence we expect from a AI in SSU, the more information the AI needs about the mission.

How would you solve this problem?

Yes, you can say "look at the NASA FDF, these are the docs and checklists for SSU" but even using those manuals and checkilists is not straight forward as it may seem: not everybody is a Space Shuttle geek. I wonder how many people currently use SSU and how many don't for the above reasons.

Call us one-percenters. Only 1% of the Space Shuttle fans in the Orbiter world use SSU. It is not like we place popularity high in our priorities. I actually don't mind that much about it. I have given up trying to be popular for attracting developers to make SSU better.

But yes, we can't always point to the FDF, when the actual user interface is keyboard, joystick and mouse. We need to explain more.

 

[GLS]

Another 8 years of SSU and we have to worry about our contributors pushing up the daisies.

Actually, there have been days when I went to bed after spending the day working in SSU, and I was so exhausted that I thought to myself: "this thing is going to kill me". :uhh:

 

[Urwumpe]

Actually, there have been days when I went to bed after spending the day working in SSU, and I was so exhausted that I thought to myself: "this thing is going to kill me". :uhh:

Trust me, there are days when I wake up after just a short nap between researching SSU and going to work and loudly declare "I am getting too old for this "

And still do it again.

 

[Wolf]

Thanks for starting this new thread and for your detailed answers. I think that shows you take into consideration other orbinauts thoughts/views (and why not, criticism) who might post here, given the fact that SSU is your creature and the choice of what, how, who and when rests solely with you and the other SSU team members

 

[Poscik]

Thanks for starting this new thread and for your detailed answers. I think that shows you take into consideration other orbinauts thoughts/views (and why not, criticism) who might post here, given the fact that SSU is your creature and the choice of what, how, who and when rests solely with you and the other SSU team members

I think it's normal that dev team choose when and what to implement. It's not client - company relation, where client decides what to do. Look how FSX aircraft development look like. Here is exactly the same situation.

 

[Urwumpe]

Thanks for starting this new thread and for your detailed answers. I think that shows you take into consideration other orbinauts thoughts/views (and why not, criticism) who might post here, given the fact that SSU is your creature and the choice of what, how, who and when rests solely with you and the other SSU team members

Sure. But what we want can be influenced with good arguments and every help that makes it easier to see why we should want it. :tiphat:

 

[fred18]

Hi, very nice and interesting points.

I am one of those users who loves SSU but is lost with it due to its incredible level of realism in the Shuttle systems (and, if I may, to a bit of lack of explanations).

But being an addon developer myself I found out that at some level the addon development can be not only about preparing something that others will be able to use, but also (and mostly) the challenge of actually making it properly. Most of the addons I made entertained me more while building them than flying them afterwards.
So I understand very well that if you get into such a group of Shuttle experts, then it should be very funny to try to build the shuttle exactly as it was in reality, so an incredibly complex machine to fly, and the fun is all into doing it exactly so.

On the other hand I think anyway that such a huge work should be somehow made available a bit more easily to people which can enjoy it more if they are able to use it. It's a bit like writing a book: you do it best if you don't think of other people reading it, but then, once it's written if nobody reads it there was no point in writing it.

The AI pilot seems a great idea but it will surely take a while to have it. Some official guide on how to use SSU with, for example, an entire example mission flown automatically with all the explanations, would help people to get more in touch with it.

These are just random thoughts, the concepts anyway are:
- the job is great, keep it up
- I understand that it's difficult to built it as extremely realistic, but I also think that that's the best fun for developers
- help users a bit more, beause it's really difficult!

Cheers guys
Fred

 

[amalahama]

A quick thought: Had SSU development been quicker, smoother and more effective if it would have started as a commercial product instead of open-source? Had it attracted more development resources in that case?

Sometimes I think you try to achieve so many things but the spare time you have to spend in your hobbies is just that limited...

Regards

 

[Urwumpe]

Some official guide on how to use SSU with, for example, an entire example mission flown automatically with all the explanations, would help people to get more in touch with it.

Well, making a full annotated replay of a SSU mission would be hard because of the many aspects that need to be touched in first place. Maybe interesting once more of SSU is completed. Actually, I have not even a clue, what problems we need to fix first there for recording and replaying a SSU mission.

So, as alternative, what about creating a "walkthrough" PDF for a short mission. Maybe even a simplified fictional mission with less stuff packed into it (Even STS-1 or STS-3 are pretty complex). Maybe structured in short individual episodes, shorter than what we want to do for the normal missions. Would something in that direction be helpful?

I remember that Orbiter also supports in-game help including special files for scenarios, but I am not sure if any add-on ever used it.

 

[fred18]

So, as alternative, what about creating a "walkthrough" PDF for a short mission. Maybe even a simplified fictional mission with less stuff packed into it (Even STS-1 or STS-3 are pretty complex). Maybe structured in short individual episodes, shorter than what we want to do for the normal missions. Would something in that direction be helpful?

Definitely!!! I've been digging around in the docs to find something exactly like that, a walkthrough... I can print it, put it on the desk and start to launch my simple mission and get in touch with the VC. After that's done, flying a more complex mission will be one significant step closer, at least for me.

IMHO I think it would be worth to spend sometimes on this, you'll surely get me as a user.

 

[Urwumpe]

A quick thought: Had SSU development been quicker, smoother and more effective if it would have started as a commercial product instead of open-source? Had it attracted more development resources in that case?

No realistic business case, so fully commercial would be hard. Maybe as NASA project, it could have worked out slightly better, but you then have to look close at what the differences really are. Lets play a bit with alternative universes:

Right now, we can make use of non-commercial licenses for the software tools we use for example, in a commercial project a lot of the money would already be eaten by commercial licenses. You need offices. You need to employ people who do all the other work that developers hate (controlling for example, which developers hate even if they don't need to do it)

By my experience, you can calculate that if an experienced developer has a gross salary of about 55K € (before taxes), you must calculate about two to four times as much revenue per developer before you are really profitable - the smaller the project, the bigger the fixed costs and the harder it is to reduce labor costs. A developer with 30 days off work can do about 200 daily sprints with 8 hours each in a year. 1600 hours. In a very optimistic scenario. In reality, I consider it already effective, if 1200 hours are available for a project in a year.

SSU has about six developers right now, which have contributed about 25000 hours of their lives to SSU in the past 8 years. In the commercial case, that could have been done in about 2 years at the same level of quality, but since you need to exceed customer expectations, better calculate with about 4 years to get a result done with such a small team. Because of the team size, we could allow only little specialization, no junior developers for reducing costs or architects for managing the big picture.

Means, the project budget of SSU would be about 6 * 4 * 55K * 3 = 3,960,000 € . That is more than most indy games cost. Cheap compared to a real Space Shuttle.


Would we sell it at about 40€ per copy (after taxes and other costs for digital distribution, like Steam, which adds about 30%), we would get a need to sell about 100,000 copies. :rofl:

Good Joke.

As you can see, SSU is no project that makes economically sense. Much worse, would money get into the project, we would have lots of paperwork around it that costs us more lifetime than it likely saves in the end. Even asking for support via patreon would be a complicated affair.

I think we work better by the words of Janis Joplin: Freedom is just another word for nothing left to lose.

Of course it means we have to do things differently than a commercial project. We can't afford a central build and testing system (Because it always has a price tag, even if I donate one. TANSTAAFL). Having a central repository is already a luxury for us.

 

[Wolf]

It's a bit like writing a book: you do it best if you don't think of other people reading it, but then, once it's written if nobody reads it there was no point in writing it.

That is exactly what I meant with my initial post. On the other hand Urwumpe was quite clear on this point: they are not looking for popularity, so I guess so far there is not much interest in "selling the book"

---------- Post added at 04:20 PM ---------- Previous post was at 04:18 PM ----------

Definitely!!! I've been digging around in the docs to find something exactly like that, a walkthrough... I can print it, put it on the desk and start to launch my simple mission and get in touch with the VC. After that's done, flying a more complex mission will be one significant step closer, at least for me.

IMHO I think it would be worth to spend sometimes on this, you'll surely get me as a user.

I think this would be a great starting point. And as Urwumpe said maybe using less complex missions like STS-1 STS-2 or STS-3 as a backbone to learn how to use SSU from launch to re-entry

 

[martins]

I remember that Orbiter also supports in-game help including special files for scenarios, but I am not sure if any add-on ever used it.

You can write a CHM (packed html sources) file and refer to it from the scenario. This is then available from within Orbiter with Alt-F1. A good place for checklists etc.

Maybe even better: an interactive tutorial written in Lua:

- print some instructions on the screen
- wait until the user has applied the correct controls, or until the spacecraft has reached the required state

- print the next instructions, etc.

or, if the AI (that is, the Lua script) detects things going wrong:

- print some suggestions how to correct it.

The Shuttle-A ADI ball tutorial is an example for this type.

 

[Urwumpe]

That is exactly what I meant with my initial post. On the other hand Urwumpe was quite clear on this point: they are not looking for popularity, so I guess so far there is not much interest in "selling the book"

Well, not looking for popularity is too hard. :lol: It is just not our first-most goal. Not even the third-most goal. I am not even sure if it made it into the TOP 5.

But if we would not care about popularity, we would also not try to make regular (once in a blue moon) releases. I don't think that this can be called "selling the book". We just allow everybody to read it.

 

[boogabooga]

I'm not sure that it is a 'criticism' of SSU simply to acknowledge that it is not for everyone, and that it is its own thing with its own niche rather than a replacement or substitute for any other add-on.

When I think SSU, I think this:
http://www.nationalmuseum.af.mil/Vi...5/space-shuttle-crew-compartment-trainer.aspx

i.e. Professional astronaut-training software.

Not everyone is going to want to go that far with the systems simulation in Orbiter.

But man, what an awesome ride for those that do, I am sure...

 

[Urwumpe]

You can write a CHM (packed html sources) file and refer to it from the scenario. This is then available from within Orbiter with Alt-F1. A good place for checklists etc.

Just read about the Windows 7 Help SDK, the feature of training cards sounds very interesting.

( See here: https://msdn.microsoft.com/de-de/library/ms524258(v=vs.85).aspx )

Well, maybe a too advanced topic for starting CHM, but sounds like a good way to teach standard procedures like orbital maneuvers.

 

[Thorsten]

Call us one-percenters. Only 1% of the Space Shuttle fans in the Orbiter world use SSU. It is not like we place popularity high in our priorities. I actually don't mind that much about it. I have given up trying to be popular for attracting developers to make SSU better.

vs.

It's a bit like writing a book: you do it best if you don't think of other people reading it, but then, once it's written if nobody reads it there was no point in writing it.

After a few years of OpenSource development, I can much more relate to the former than to the latter sentiment.

First, my experience is whatever you do, someone complains. I get complaints that we're not making use of the most modern features of graphics cards in rendering, yet when I dare to introduce an effect that really doesn't run on six year old integrated chipsets, I get complaints about how dare we drop legacy support.

If a helicopter has realistic dynamics, people complain that it's too hard to get it into the air, if the dynamics is dumbed down that everyone gets it off the pad, people complain that we sacrifice realism.

If I write documentation for the wiki, I get complaints that it's not shipped with the aircraft, if shipped with the aircraft I get complaints that it isn't on the wiki.

Only a certain callousness gets you through these experiences.

My best advice is - do what you believe in when you develop - state the aim of your project up-front so that everyone knows what to expect and then do it.

If I ever were to justify why I code LCD screens which use power according to their brightness setting aboard a Shuttle, I couldn't do it. And for user satisfaction, there are sure many much more pressing issues.

I'm fairly sure even 99% of the interested users will never notice (the power consumption differs so little, it's really hard to see even with DISP 67 open). But one person will know, and that's me. Every time I'm on the virtual flightdeck, I will know that I did a proper and exhaustive job. And that's why I do it.

As OpenSource developer, you scratch the itches you have - you go fix what bothers YOU.

And that's the invitation to everyone here who wants to see better documentation - that's YOUR itch - go scratch it. Read through the docs. Bug the developers with questions if you're not sure how X is implemented. And then get involved and write it up yourself, the way YOU think documentation needs to be done. Take the time to learn it by trial and error and questions and then write a walkthrough - and there'll be one.

It's a lot of work, but there's no reason it needs to be done completely by the same people who wrote the code in the first place. Make it your project, don't wait for others to deliver.

My two cents (and my tried and tested reply to long lists of complaints I've had to read through).

 

[amalahama]

Actually my main complain it's related with the very nature of the free development - you find truly pieces of code art where the developers put all their dedication, but then you also came across with lots of unattended features, still required for a "playable" addon :facepalm: . It's natural that, being a work done by volunteers as a hobby, they just work on those parts that appeal them the most. I think that natural unbalance can only be overcome with a commercial development, where a project manager ensures (or try to) a balanced list of features, optimizing customer satisfaction, development effort and resources available.

Said that, although I'm not very participative in this forum, I've been following SSU development since the very beginning and, with its highs and lows, the level of realism it's achieving currently is truly remarkable. Maybe it would be nice in order to control what's modeled and what's not, to maintain a "track" of new features implemented in a read-only post in SSU forum. It doesn't have to be fully documented, just two lines with the name of the new feature when it's added to the nightly, just for the record, no discussions inside. Diehards like me normally don't wait until new version coming out and knowing what's new can allow us to give support debugging new features.

Regards!

 

[Urwumpe]

Said that, although I'm not very participative in this forum, I've been following SSU development since the very beginning and, with its highs and lows, the level of realism it's achieving currently is truly remarkable. Maybe it would be nice in order to control what's modeled and what's not, to maintain a "track" of new features implemented in a read-only post in SSU forum. It doesn't have to be fully documented, just two lines with the name of the new feature when it's added to the nightly, just for the record, no discussions inside. Diehards like me normally don't wait until new version coming out and knowing what's new can allow us to give support debugging new features.

Well, we have a ticket system, but it is really better suited for tracking bugs than to track development tasks. It is halfway useful, when you are nearing a release and want to make sure the planned features are correctly implemented.

But hey, its free.

 

[Becker]

From the moment I was allowed to stay off school to watch the first launch to the very last I have been enthralled by the whole Shuttle experience. As a long time Orbiter fan I remember the days of the SF with very fond memories, I also remember the days when there were no autopilots whatsoever!

Anyway I came back to Orbiter pretty much on the back of SSU wanting to revive the skills and see what it was made of. I have been very pleasantly surprised. I also found the lack of tutorials a little frustrating then I thought ok, I'll have a go myself.

Months later I am now more fluent in shuttle systems than I ever was. Yes it involved a lot of reading and searching but i'm getting there. My computing skills have also gone up a notch or two thanks to this sim. Anyway ...

I am currently still developing a mission for SSU and hope to have something out very soon, (pending a fix for the radio system in 2016) including step by step guides on how to get from A to B. I'm about 3 months in so far and things could have been done a lot quicker had I known what worked and what didn't from the off but then I wouldn't have learnt anything.

I believe the heart of SSU is in the learning but I appreciate not everyone has the time so ... I'm hoping to bridge the gap a little as soon as I'm satisfied I've done as much as I can to emulate the mission I have in work and do it justice. All things are difficult before they become easy.

Edit - shameless plug to the very first and only movie I made using Orbiter - I feel old - [ame="https://www.youtube.com/watch?v=C-iXsaM82jY"]Orbiter - Space Shuttle Re-Entry and Landing - YouTube[/ame]