Space Shuttle Ultra 1.25 Revision B development

[DaveS]

We are doing open-source development, so the end-user IS dev as well possibly. Not all people who work with the SSU source code are SSU developers.

Yes, but are they necessary in a release package? We already have SVN for the dev stuff. If we're going to include all the dev stuff, we might as well only package the modules and point to the SVN repository for the rest.

 

[Urwumpe]

Yes, but are they necessary in a release package? We already have SVN for the dev stuff. If we're going to include all the dev stuff, we might as well only package the modules and point to the SVN repository for the rest.

We should at minimum have a link in the release documentation, where to find the development stuff.

 

[Donamy]

Can we get some generic launch and on orbit scenarios ? Would make it easier for testing and adding different payloads.

 

[Urwumpe]

Can we get some generic launch and on orbit scenarios ? Would make it easier for testing and adding different payloads.

What do you mean with generic?

We should have one on-orbit scenario. But maybe a special folder with some on-orbit show-cases of SSU might be sweet. Any suggestions for orbiters, orbits and payloads?

 

[DaveS]

What do you mean with generic?

We should have one on-orbit scenario. But maybe a special folder with some on-orbit show-cases of SSU might be sweet. Any suggestions for orbiters, orbits and payloads?

I had hoped for either Chandra/IUS and/or the Centaur as those were the bread and butter type missions that the shuttle used do through the 80's/90's.

 

[Urwumpe]

I had hoped for either Chandra/IUS and/or the Centaur as those were the bread and butter type missions that the shuttle used do through the 80's/90's.

Yes, but for those we would need some more coding.

 

[DaveS]

Yes, but for those we would need some more coding.

That is true, but the payload support in SSU currently is pretty limiting. The only thing worth using payload wise is the RMS which limits us to ISS assembly missions as well as static payload missions like STS-107.

 

[Urwumpe]

That is true, but the payload support in SSU currently is pretty limiting. The only thing worth using payload wise is the RMS which limits us to ISS assembly missions as well as static payload missions like STS-107.

Yes. I would also like support for the PAM cradles. But the main problem is, we have more than enough people who can do great graphics, but we need more people doing the coding.

I currently always run out of coding time with my 60 hours week, I am no help at all, if I ever was one. I want to get the hydraulics done, then I want to finish the MDM simulation, so we have more options for subsystem simulation. C&W would be another one for me, but I still hope for some optimizations in the cockpit, not sure if they have been done already.

 

[SiameseCat]

Can we get some generic launch and on orbit scenarios ? Would make it easier for testing and adding different payloads.

There's a Launch Test scenario (starts at T-32 seconds) in the main SSU scenarios folder and an Atlantis in orbit.scn in the Testing Scenarios folder.

 

[DaveS]

Yes. I would also like support for the PAM cradles. But the main problem is, we have more than enough people who can do great graphics, but we need more people doing the coding.

I currently always run out of coding time with my 60 hours week, I am no help at all, if I ever was one. I want to get the hydraulics done, then I want to finish the MDM simulation, so we have more options for subsystem simulation. C&W would be another one for me, but I still hope for some optimizations in the cockpit, not sure if they have been done already.

What we need for payloads is a generic module that can handle the carriers. Those are the things that needs to interact with SSU, the upper stages can be handled through either SC3 or GenericVessel.

 

[Urwumpe]

What we need for payloads is a generic module that can handle the carriers. Those are the things that needs to interact with SSU, the upper stages can be handled through either SC3 or GenericVessel.

Well, make a good module design for such a generic module and somebody can sure implement it. I can't imagine yet how you will make that generic.

Also, we have the payload interactions via PI.

EDIT: Also, are four-five different carriers really a reason for a generic module? Wouldn't it be better to make carrier modules share common source code?

 

[DaveS]

EDIT: Also, are four-five different carriers really a reason for a generic module? Wouldn't it be better to make carrier modules share common source code?

They do work similarly, especially the IUS ASE and the Centaur CISS, both using a central tilt table that holds the upper stage and then rotates to a specific angle for deploy.

 

[Urwumpe]

They do work similarly, especially the IUS ASE and the Centaur CISS, both using a central tilt table that holds the upper stage and then rotates to a specific angle for deploy.

That is what I mean. We have a few different functions in them that can be accessed by the DPS and switches as user interface, but otherwise, many aspects are similar.

Some aspects could be easily described by a script, but many others would be simpler done hard coded.

 

[DaveS]

That is what I mean. We have a few different functions in them that can be accessed by the DPS and switches as user interface, but otherwise, many aspects are similar.

Some aspects could be easily described by a script, but many others would be simpler done hard coded.

That is what I mean. Considering how few carriers there were, this could work. I'm envisioning something along Radu094's old Panel&Systems SDK but condensed to only upper stage services (Propellant/electrical) instead of the slew of systems required for a complete spacecraft.

 

[Urwumpe]

That is what I mean. Considering how few carriers there were, this could work. I'm envisioning something along Radu094's old Panel&Systems SDK but condensed to only upper stage services (Propellant/electrical) instead of the slew of systems required for a complete spacecraft.

Yes, that is what I also think works best. We could have a special file format for describing some variable aspects of a carrier or payload and just have the skeleton of a carrier/payload as C++ code.

Do you remember the SPAS satellite... one of the Shuttle payloads that I also want to see in SSU one day and not in a German museum.

 

[SiameseCat]

Leaving aside the discussion of future work, I do think that the release should include everything in SVN, with the possible exception of the Orbitersdk folder and parts of the Doc folder. The main reason for this is so that, if a bug is reported a month from now, we can easily go back to the revision that was released and investigate. If we're leaving some files out of the released package, this could make debugging much harder.

Can someone take a look at this release zip: https://dl.dropboxusercontent.com/u/64239213/SSU Version 2.0.zip
I've included all files except the Doc/SSU/Technotes folder. I've also included a few last-minute changes which I checked in to sourceforge (preventing SSU from overwriting Orbiter's default bases) and ensuring that all scenarios use the correct config file.

I've added a readme file containing installation instructions; it would be nice if someone could take a look at this.

 

[Urwumpe]

The main reason for this is so that, if a bug is reported a month from now, we can easily go back to the revision that was released and investigate. If we're leaving some files out of the released package, this could make debugging much harder.

That is what SVN is for. We create a tag, for creating a read-only snap-shot of the sources at the point of release. So, when somebody has a problem with the release, we can go back to the tag by SVN and investigate.

Next, we implement all new features in a development branch (eg, 1.26-dev). Best practice is doing the same for bug fixes (eg. patch-1.25C), and merge the branches back to the trunk only before a release happens. If we would be a larger project, we would also have test-branches for creating alpha test versions, that separate from the dev-branches.

This way, we can always find the right sources for a release, implement new features, provide bug fixes AND investigate bugs in the source code of any release.

That is what a version control system is for, no need to pack it all into a zip file. What we need to provide is a documentation what work is done in which branch.

The HEAD of the trunk would always be a tested complete version - maybe not a released version, but something contributors and people interested in forks can easily work with.

 

[SiameseCat]

That is what SVN is for. We create a tag, for creating a read-only snap-shot of the sources at the point of release. So, when somebody has a problem with the release, we can go back to the tag by SVN and investigate.

I agree with that. My concern is that the zip release will be missing a lot of files compared to the SVN 'release'.

For future development, I'd prefer to keep most of the changes in the trunk, and reserve branches for features which might disrupt other work done on SSU and bugfixes which need to be applied to the trunk and releases. The trunk is pretty stable already, and I don't see a need to maintain it as a 'tested complete version'; if we're going to create a tested complete version, we may as well release it.

 

[Urwumpe]

I agree with that. My concern is that the zip release will be missing a lot of files compared to the SVN 'release'.

For future development, I'd prefer to keep most of the changes in the trunk, and reserve branches for features which might disrupt other work done on SSU and bugfixes which need to be applied to the trunk and releases. The trunk is pretty stable already, and I don't see a need to maintain it as a 'tested complete version'; if we're going to create a tested complete version, we may as well release it.

I think it would be better to start developing every new feature for SSU in a branch and eventually integrate it into the trunk once it is not breaking it.

Also, we should include some stubs into SSUs source code for getting some fake constant data from subsystems that are not yet in use. When a new feature is done, we just replace the stub by the subsystem.

 

[Face]

Sorry for chiming in so uninvited, but I'd like to give you a warning from my experience with SVN's tags. In SVN, a tag is nothing more but a copy of the trunk at a given time into a separate directory in the tags folder of the root (although this could of course also be called "releases" or whatever). Now there is nothing wrong with this, but the trouble is that nothing stops you from committing into that folder, if you don't have some hooks installed that prevent it.

So if you rely on tags to get back to a certain code state (because you e.g. have no sources in a release zip), you should keep in mind that without additional blocks in place a checkout of a tag is not guaranteed to get you just that. Chances are that some commiter mistakenly committed into the tag folder, and perhaps did not even realize it.

It may sound like there have to be too much things going wrong to get this scenario, but in every SVN repo I have seen with more than one developer, this happened at least once.

Congrats on the upcoming release, BTW! That has been quite some work, folks!