Space Shuttle Ultra 1.25 Revision B development

[DaveS]

Yes. You could of course reduce the velocity target by the error value.

That will take alot of time. I still haven't nailed it down after 20+ launches. What am I supposed to look at when I have my desired MECO apogee altitude?

 

[SiameseCat]

I have an important question for you: How should we handle drag chute/no drag chute? After alot of research, I have come to the conclusion that the drag chute compartment was not a "bolt-on" modification to the orbiter vertical tail as I had initially thought.

It required a reshaping of the lower fairing of the vertical tail in order to be fitted. This means for us, two different vertical tail meshes in order to be accurate.

I think the best solution is to have a mission file variable indicating if the shuttle has the drag chute, and using the appropriate tail mesh. The main orbiter mesh would be missing a tail, and we would have a separate mesh for the tail with and without the drag chute.

As far as releases go, I don't think there's any issue with regular beta releases on Sourceforge containing both the modules and the other files. SSU tends to be pretty stable - there are a lot of incomplete features, but few bugs, so I don't think regular releases will take a lot of work. Personally, I don't have any problems with releasing the latest revision of Sourceforge right now. I think the big problem with releases is that everyone thinks of them as a big deal, and nothing ever gets done. As long as we keep bugs out of the code (which we've been doing), we should be able to release beta versions regularly without too much effort.

The one problem I do have with our releases are that we tend to change the scenario and mission file structure, which breaks any addons that are using SSU. We've talked about using JSON in the past, and I think we should implement this as soon as possible so we have a stable scenario/mission file system. This, IMHO, is more important than having a mission planner/editor, because it restricts anyone who wants to make addons using SSU.

 

[Donamy]

Donamy, I'm sorry that you feel this way but SSU will be in this mode for long time to come. SSU is alpha software and will be until all systems have been implemented properly. And given just how complex the shuttle really is, this will take a long time.

A good example is the NASSP/Project Apollo add-on. They have been developing their add-on for nearly a decade and they're still not ready for a public release! They do periodic module releases, but you still have to use CVS to get the core stuff (meshes, configs, textures etc).

I'm sorry DaveS, I didn't know that this was your private endeavour. If that is the case, I will no longer be a part of the SSU team. This is not what I signed on for.

 

[DaveS]

I'm sorry DaveS, I didn't know that this was your private endeavour. If that is the case, I will no longer be a part of the SSU team. This is not what I signed on for.

I'm afraid that you got the wrong message from my post. I was just trying to explain that SSU will be in constant change for quite some time. You can't count on something remaining static for a prolonged period of time. You have to remain ready on that the next change will the be the one that breaks your stuff.

 

[Urwumpe]

I'm afraid that you got the wrong message from my post. I was just trying to explain that SSU will be in constant change for quite some time. You can't count on something remaining static for a prolonged period of time. You have to remain ready on that the next change will the be the one that breaks your stuff.

But we should have a roadmap or at least something like a plan. Lately, we didn't even keep on doing what we planned for just the next release. People just added more.

SSU is the sum of all developers private endeavours. But that does not mean we are free to do what we like - we need to pay attention also to the private endeavours of the others.

I for example would really like to jump into your face, when you suggest doing another ground handling feature, when the orbiter is still pretty much an empty hull. It doesn't really help us NOW to completition, but it is your field of interest.

 

[DaveS]

So in the end we need a plan and someone who is willing to act as the project manager?

 

[SiameseCat]

I'm afraid that you got the wrong message from my post. I was just trying to explain that SSU will be in constant change for quite some time. You can't count on something remaining static for a prolonged period of time. You have to remain ready on that the next change will the be the one that breaks your stuff.

We shouldn't be breaking stuff. It'll obviously take a lot of time to create a complete simulation, but we should try to keep SSU stable. It's really annoying to go back to a scenario you created a year ago and find out that it's broken. We'll always be adding features, but ideally we won't be rewriting stuff we did earlier (especially things that could affect users of SSU).

 

[DaveS]

We shouldn't be breaking stuff. It'll obviously take a lot of time to create a complete simulation, but we should try to keep SSU stable. It's really annoying to go back to a scenario you created a year ago and find out that it's broken. We'll always be adding features, but ideally we won't be rewriting stuff we did earlier (especially things that could affect users of SSU).

Well, in my mind this is an impossible task as scenarios get broken when we add a new system and backwards compatibility just makes the code bloated and more complex than it should be.

 

[Urwumpe]

So in the end we need a plan and someone who is willing to act as the project manager?

Yes. I could do that in theory, but practically, I am too far out from development to do that. I would need to get back into programming first.

Also, we should have make sure, that we all have the same goals. It makes no sense to say we are doing a project X, when actually it is already a project Y for long.

---------- Post added at 11:11 PM ---------- Previous post was at 11:10 PM ----------

Well, in my mind this is an impossible task as scenarios get broken when we add a new system and backwards compatibility just makes the code bloated and more complex than it should be.

Not necessarily. We could for example have a mission editor to ensure that. It is easier to make the mission editor backwards compatible, than doing this in SSU, which should be as fast as possible.

The mission editor does not need to know which subsystems are there, it only needs to know how they are described.

 

[SiameseCat]

I think the biggest problem with SSU is the lack of regular releases. This doesn't really affect the coders, but it's annoying for anyone else to have to install Visual C++ and figure out how to compile SSU. I think it might be a good idea to have a release every four months (or some other fixed interval), where we put the compiled modules and other files on Sourceforge.

 

[Urwumpe]

I think the biggest problem with SSU is the lack of regular releases. This doesn't really affect the coders, but it's annoying for anyone else to have to install Visual C++ and figure out how to compile SSU. I think it might be a good idea to have a release every four months (or some other fixed interval), where we put the compiled modules and other files on Sourceforge.

Yes. But for THAT, I would also demand automated tests for everything critical. Otherwise, we can't reach that goal without reducing the number of new features per release.

 

[SiameseCat]

Well, in my mind this is an impossible task as scenarios get broken when we add a new system and backwards compatibility just makes the code bloated and more complex than it should be.

I don't think so. For most systems, it isn't hard to find a default state which works well without loading the exact configuration from a scenario. We can even define the basic configuration (T-9, On orbit, etc.) for the entire shuttle in the scenario, and then have the scenario file list the changes from the basic configuration.

 

[Donamy]

I'm afraid that you got the wrong message from my post. I was just trying to explain that SSU will be in constant change for quite some time. You can't count on something remaining static for a prolonged period of time. You have to remain ready on that the next change will the be the one that breaks your stuff.

The project in my mind, was to develope a Shuttle simulator that showcases Orbiter, and draw more people to this wonderful thing we have here. Which should be the number one goal. SiamesCat's suggestion of a stable release every four month's would be ideal. Let's remember, there is only one of us here, that is bigger than Orbiter.

 

[Urwumpe]

In my mind, it was about keeping the Shuttle alive in a simulation with historical accuracy. Including the chance to test, how things might have been.

 

[DaveS]

In my mind, it was about keeping the Shuttle alive in a simulation with historical accuracy. Including the chance to test, how things might have been.

Then we have the same goal in mind as I have always thought the objective of SSU was to simulate the various elements of the Space Shuttle as accurately as possible.

 

[Donamy]

Then we have the same goal in mind as I have always thought the objective of SSU was to simulate the various elements of the Space Shuttle as accurately as possible.

What good is it if only one person uses it ?

 

[GLS]

About scenario files getting broken, I defend that every time a developer changes something he is responsible for updating the scenarios with the new stuff, then upload. (yes it's boring but I think it's the right way)

As for (more) releases -> OK.
In the last weeks I changed a lot in the controller SW so it's less bloated and does more, added the He system and did a little updating in the CRTMFD MPS display, but it's not ready yet, so it will only show up in the summer . Meanwhile I have no objections to a short-term release(s).

A 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. Likewise the MPS dump also provides some kick.

In my mind, it was about keeping the Shuttle alive in a simulation with historical accuracy. Including the chance to test, how things might have been.

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

 

[SiameseCat]

About scenario files getting broken, I defend that every time a developer changes something he is responsible for updating the scenarios with the new stuff, then upload. (yes it's boring but I think it's the right way)

The problem is that scenarios created by other people are also broken, and we can't fix those. Also, if you have scenarios for every shuttle flight, that's a lot of scenarios to be updating every time someone adds a new system.

 

[Donamy]

That has alot to do with the update. Mesh updates wreck animations, don't really affect scenarios. Updates that break launches, usually break all launches.

 

[Urwumpe]

What good is it if only one person uses it ?

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.