Space Shuttle Ultra 1.25 Revision B development

[Donamy]

Well, when we started SSU, we had not been the inofficial successor of Shuttle Fleet. We wanted to be different to justify our effort.

Also I think we have still a lot of room for assisting the player during gameplay that would not break realism:

• We could add the other crew members to the simulation and let them do tasks with the player only commanding the mission.
• We could have mission control assist in tasks and provide guidance parameters.
• We could include executive packages printed on a simulated printer.
• We still make no use of Online help.

The thing is, I'm not getting any younger.:facepalm:

 

[Urwumpe]

The thing is, I'm not getting any younger.:facepalm:

Get me 150 programmers, and we would be done in a year. :dry:

 

[STS]

What good is it if only one person uses it ?

That is not true.

 

[DaveS]

That is not true.

Very much so. Here's an unanswered SSU thread on Dan's french Orbiter forum: http://orbiter.dansteph.com/forum/read.php?f=3&i=85664&t=85664&last=1

---------- Post added at 02:37 PM ---------- Previous post was at 02:32 PM ----------

So how shall we proceed from this point? Considering everything, I think I can take on the role as the project coordinator/manager if that is required.

---------- Post added at 05:39 PM ---------- Previous post was at 02:37 PM ----------

It's going to take more time and work, but I really want to fly the 2 "death star" missions :thumbup:

Well, everything is there, Centaur and the CISS, they just someone to integrate them properly with SSU.

IA note about calculating MECO speed for orbital insertion: the SSMEs don't shutdown immediately, so there is always some "extra" dV produced in the tailoff that must be taken into account.

Do you know how much extra dV this tail-off produces? If this is known, then I think we could subtract this amount in the MECO velocity calculation done by MECOCalc. This is something I think we all could accept as an temporary solution until MECOCalc could be properly integrated with a full Mission Editor.

 

[GLS]

Do you know how much extra dV this tail-off produces? If this is known, then I think we could subtract this amount in the MECO velocity calculation done by MECOCalc. This is something I think we all could accept as an temporary solution until MECOCalc could be properly integrated with a full Mission Editor.

No I don't, but that wouldn't be hard to measure. It's the dV between MECO and MECO+6s. At the moment I don't have time, but I could do it in a few days.

 

[Donamy]

That is not true.

Alright, two then.

 

[SiameseCat]

No I don't, but that wouldn't be hard to measure. It's the dV between MECO and MECO+6s. At the moment I don't have time, but I could do it in a few days.

How big is this dV? The impression I had was that it would increase the apogee by a few km. IIRC, the MECOTool problems result in the shuttle being below the correct orbit. I don't think the SSME tailoff thrust is what's causing the issue; it sounds more like there's a problem in the math somewhere.

 

[DaveS]

How big is this dV? The impression I had was that it would increase the apogee by a few km. IIRC, the MECOTool problems result in the shuttle being below the correct orbit. I don't think the SSME tailoff thrust is what's causing the issue; it sounds more like there's a problem in the math somewhere.

To me it looks like the tail-off dV is around 15-40 m/s².

 

[Urwumpe]

About the coordinator job: It should involve some professional knowledge about project management. I don't mean: You have to work as project manager. I don't do that as well, but I know the methods and tools for managing professional projects.

As such, the project coordinator must not be a coder, but must be capable of reading the code and understanding it well enough to ensure that source code standards are kept. We are open source, the source code is our important good and without strict discipline in the sources, we are in trouble.

The coordinator must also be uninvolved in the development. If he takes part in it, his horizon is limited to his current tasks. That is bad. His task is the big picture. Thus I doubt anybody of us is really perfectly qualified. Maybe we should ask for somebody else, after we agreed on what the project coordinator should be doing.


For the short term problem solving: We should have three documents for our project defined:

A "working agreement", in which we all declare how we are going to develop SSU. It contains how we develop, which tools we use, which standards we keept. It could contain how many tasks we have maximally active during development, how we react to bug reports, etc. Just what is needed to ensure that we all really cooperate and are not in a constant misunderstanding.

Next, we need to write down our project standards. We have no standard source code format. Comments are not done. Much worse is the graphics world, we are totally depending on the person who made the graphics. We can't just let somebody else fix something and all will work. The standards should also contain standard processes for us: For example how a new feature is implemented, how it is maintained until release and how SSU is maintained after a release.

Finally: We do need a SSU manifesto. I think we all have similar goals, but not all equal goals. It would be better for us if we have the common goals written down and agree to them. And if somebody wants to join the project, he would also know what we are up to.

We should also have the version numbering defined in written form. Since we currently use Shuttle mission numbers as hint, why not going this path completely? I would suggest we name our releases according to the mission numbering in the 80s.

STS-11A would be our next release.
STS-12A would be (STS-X2X = Launches from Vandenberg) would be the first hypothetical extension pack.
STS-11B would be the first bugfix release.
STS-11C the second, etc.
STS-21A would be the second stable release, etc.

I think such a naming convention would be a great way to keep some STS atmosphere in the project alive - I think now that the Shuttle does not launch every other month, we start losing the feeling for our subject. It becomes nostalgia... and that is exactly what I wanted to prevent by this project.

Also, I think it would be a good idea to have a separation between the standard historical Space Shuttle and the alternative history/fictional extensions. First of all, because the primary priority should have the historic view. Next, it would permit us to have a good reason to increase our release rate:

1. We first do the standard SSU release. No new fictional extensions.
2. We do the needed bugfixing.
3. Then, when bugfixing pressure drops again, we start developing an alternative history extension pack. Just a small one. Maybe one or two new missions or features.
4. We release this extension pack.
5. We do some bug fixing again.
6. When the number of bug reports drop, we start working on the next standard release.

Could also mean a lot more fun to develop, because, even if we decide to skip one or two fictional releases, it could still mean a nice distraction for us developers (Doing something different and maybe less serious) and it would be a great fun for our users/fanboys.

If we could do one standard release and one fictional release per year, it would be IMHO an epic pace for such a small team.

What do you think there?

And finally: I think we should aim our standard release at the 12th April of the year. No mandatory release...but a good aim.

 

[DaveS]

About the coordinator job: It should involve some professional knowledge about project management. I don't mean: You have to work as project manager. I don't do that as well, but I know the methods and tools for managing professional projects.

As such, the project coordinator must not be a coder, but must be capable of reading the code and understanding it well enough to ensure that source code standards are kept. We are open source, the source code is our important good and without strict discipline in the sources, we are in trouble.

The coordinator must also be uninvolved in the development. If he takes part in it, his horizon is limited to his current tasks. That is bad. His task is the big picture. Thus I doubt anybody of us is really perfectly qualified. Maybe we should ask for somebody else, after we agreed on what the project coordinator should be doing.


For the short term problem solving: We should have three documents for our project defined:

A "working agreement", in which we all declare how we are going to develop SSU. It contains how we develop, which tools we use, which standards we keept. It could contain how many tasks we have maximally active during development, how we react to bug reports, etc. Just what is needed to ensure that we all really cooperate and are not in a constant misunderstanding.

Next, we need to write down our project standards. We have no standard source code format. Comments are not done. Much worse is the graphics world, we are totally depending on the person who made the graphics. We can't just let somebody else fix something and all will work. The standards should also contain standard processes for us: For example how a new feature is implemented, how it is maintained until release and how SSU is maintained after a release.

Finally: We do need a SSU manifesto. I think we all have similar goals, but not all equal goals. It would be better for us if we have the common goals written down and agree to them. And if somebody wants to join the project, he would also know what we are up to.

We should also have the version numbering defined in written form. Since we currently use Shuttle mission numbers as hint, why not going this path completely? I would suggest we name our releases according to the mission numbering in the 80s.

STS-11A would be our next release.
STS-12A would be (STS-X2X = Launches from Vandenberg) would be the first hypothetical extension pack.
STS-11B would be the first bugfix release.
STS-11C the second, etc.
STS-21A would be the second stable release, etc.

I think such a naming convention would be a great way to keep some STS atmosphere in the project alive - I think now that the Shuttle does not launch every other month, we start losing the feeling for our subject. It becomes nostalgia... and that is exactly what I wanted to prevent by this project.

Also, I think it would be a good idea to have a separation between the standard historical Space Shuttle and the alternative history/fictional extensions. First of all, because the primary priority should have the historic view. Next, it would permit us to have a good reason to increase our release rate:

1. We first do the standard SSU release. No new fictional extensions.
2. We do the needed bugfixing.
3. Then, when bugfixing pressure drops again, we start developing an alternative history extension pack. Just a small one. Maybe one or two new missions or features.
4. We release this extension pack.
5. We do some bug fixing again.
6. When the number of bug reports drop, we start working on the next standard release.

Could also mean a lot more fun to develop, because, even if we decide to skip one or two fictional releases, it could still mean a nice distraction for us developers (Doing something different and maybe less serious) and it would be a great fun for our users/fanboys.

If we could do one standard release and one fictional release per year, it would be IMHO an epic pace for such a small team.

What do you think there?

And finally: I think we should aim our standard release at the 12th April of the year. No mandatory release...but a good aim.

I agree fully here. This is fully workable plan and should lead to something goo.

 

[Donamy]

Sounds great ! But I would strongly urge a review team, so that if changes were made to something , that would break a release could be voted on, as to be needed or wanted.

 

[Urwumpe]

Sounds great ! But I would strongly urge a review team, so that if changes were made to something , that would break a release could be voted on, as to be needed or wanted.

Yes, but such a consequence is often only visible by a very careful review. Much better would be saying that breaking anything that has not been cleared is a bug.

I can't promise backwards compability for all eternity or even just long-term support for a version at this early point of development (we are still early). But we could at least give you ample time of warning and a chance to react before the new version rolls out.

 

[Donamy]

Then a locked release then, that no one can break, until a next release.

 

[Urwumpe]

Then a locked release then, that no one can break, until a next release.

Yes, that is what I want to have with the bugfix releases. We can continue on developing new features but those don't affect the sources of the current stable release.

We should define this process somewhere, but all should also be happy with the solution then. What I find easy to work, is having the "/trunk" line in the repository for bugfixes of the current release and use branches for developing features of the next releases. E.g. "/branches/STS-12-A" or "/branches/STS-21-A"

 

[Donamy]

April 12, did you say ? :shifty:

That's not a Tuesday, is it ?

 

[Urwumpe]

April 12, did you say ? :shifty:

That's not a Tuesday, is it ?

AFAIR not this year. :lol:

 

[Donamy]

I will work to update my mission packs, when we get the first release.
(wish there was a cross your fingers smiley)

 

[Urwumpe]

I will work to update my mission packs, when we get the first release.
(wish there was a cross your fingers smiley)

When we are reliable like a Swiss bank (before 1990).... :lol:

 

[SiameseCat]

If we're targeting a release April 12, we should probably update the documentation. It would be nice if everyone had a look at the latest version of the manual and we decide what information needs to be added.

 

[Donamy]

If we're targeting a release April 12, we should probably update the documentation. It would be nice if everyone had a look at the latest version of the manual and we decide what information needs to be added.

Where is it located ?