SSU Roadmap

[Urwumpe]

For planning the next steps, a coarse roadmap might be useful.

2.0 - current release
2.0.1 - next batch of bug fixes for this release (?)
2.1 - next minor update with:

• New meshes
• New MECO Calc tool --> SSU Mission Toolbox

2.2 - minor update

• Hydraulics
• File with landing and abort site data

2.3 - minor update with:

• MDM/Shuttlebus network
• ODS Bugfixes

2.4 - minor update with:

• SSU Mission Toolbox: Support for selecting landing sites and abort trajectory targets
• SSU Mission Toolbox: MDM PROM compiler tool

2.5 - minor update with:

• Ku-Band antenna improvements
• TBD

3.0 - current release

• MEDS displays
• Mesh improvements
• ODS improvements

4.0 -next major release:

• SSU Workbench (AKA Mission editor)
• RealRCS (tm) implementation
• Partition-based DPS implementation
• IUS
• Centaur

5.0

• VAB

I try to keep the tickets small and keep the tasks spread over the preferences of the developers, so not one developer is responsible for one version step. If a developers feels like he has not enough or too much work for his freetime budget, he should feel free to say it - we are not evil. Really. If a new developer wants to help the team without joining it completely, we can maybe also offer some smaller "How you can help us" tasks for people who have some boring rainy holidays and need a challenge.

The tasks in the major version step should be something that can brew for a while on low-intensity and be done in smaller tasks between the minor version steps. We can use SVN to manage which features we will include in a release and which can still be developed in a development version.

Please tell me what you think about it, this post will be edited for reflecting the current state of the projects future. This roadmap is meant to change a lot, since this is no professional payware project. Thank you for your patience there.

 

[Donamy]

The SSU toolbox ? I think this group should commit itself to the task of Landing a man on the moon...Oh, wait. I mean turning out different missions with payloads and Eva's if needed, about once a month. thoughts ?

 

[Urwumpe]

The SSU toolbox ? I think this group should commit itself to the task of Landing a man on the moon...Oh, wait. I mean turning out different missions with payloads and Eva's if needed, about once a month. thoughts ?

That sounds like a good idea and thats what the toolbox is aiming at.

The toolbox is essentially a mission editor and STS Orbiter modification tool that should grow with SSU. Currently, I am looking at JavaFX there as base, since anybody who can write HTML/Javascript could also take part in development there (with FXML), compared to the alternative platforms.

In the best case, in a more or less distant future, it should really take you about a week to get from the idea for a mission to a set of mission files for SSU, including flight plan and checklists, and a full set of basic scenario files for SSU including simple scripted failures or failure chances. I don't want to promise that you can just say "fly me to the ISS" and you will have a mission that is useful, some work would be neccessary, especially if you want to release the mission.

-----------------------------------------------------

If you also want to launch your own payloads, a common idea between DaveS and me was to create a number of Space Shuttle compatible spacecraft bus or payload modules and just edit a configuration file to install your own sensors or experiments into it. Think of the SPAS satellite there.

The less you interact with SSU, the more freedom you might have there in the payload department anyway. If you don't need a PI, and just strap the payload on a IUS, you could even launch a spacecraft3 based payload.

But it would be cool if we could at least make some get away specials collect data during a SSU mission and have successful science data included in a post-mission report.

Or have an AI astronaut in the crew grow attached to an experiment and threaten to jump out of the hatch without a space suit should the experiment get declared dead....

Also, we still have the "mars landing" dream of offering the player a way to define flight manifests one day, and have multiple missions to be flown in a longer campaign, for example to assemble a space station.

But that is so far away from current development problems, that I did not yet want to schedule it in the roadmap. If you think its important, we could maybe start working for it from 3.0 to 4.0.

 

[Donamy]

There are already many payloads available. All that's needed is away to drop them in the bay and go.

 

[Urwumpe]

There are already many payloads available. All that's needed is away to drop them in the bay and go.

The "and go" is the main problem there. dropping them into the payload bay is easy and can already be done. Manipulating things with the RMS is no problem.

But everything beyond that... stop hammertime.

 

[Donamy]

The "and go" is the main problem there. dropping them into the payload bay is easy and can already be done. Manipulating things with the RMS is no problem.

But everything beyond that... stop hammertime.

truth

 

[SiameseCat]

There are already many payloads available. All that's needed is away to drop them in the bay and go.

If the payload doesn't require any interaction with the shuttle (outside of deployment with the RMS), we can do that already. We should be able to simulate most ISS missions (from the shuttle side, at least) and Hubble deployment.

 

[Urwumpe]

truth

If you really want to get some joy... I remember you having a good EMU mesh which allowed some animation. I would really love to have a proper EVA in SSU... :lol:

 

[Donamy]

If you really want to get some joy... I remember you having a good EMU mesh which allowed some animation. I would really love to have a proper EVA in SSU...

It's there for the taking.

If the payload doesn't require any interaction with the shuttle (outside of deployment with the RMS), we can do that already. We should be able to simulate most ISS missions (from the shuttle side, at least) and Hubble deployment.

Just the locks in the bay perhaps.

 

[DaveS]

I have been thinking and would it be too much to ask to have PDRS fleshed out a bit more in the next minor release? I think that having a better implemented PDRS would attract more users.

 

[Urwumpe]

I have been thinking and would it be too much to ask to have PDRS fleshed out a bit more in the next minor release? I think that having a better implemented PDRS would attract more users.

Can you summarize the exact tasks that would be needed to "flesh out the PDRS"? Would make the discussion a lot more productive.

I find it a bit unbalanced, if we keep on focussing too much on the few subsystems we already have to "flesh them out", while others are completely missing, but thats just my two cents there. We can drive a crawler around the cape, but we "Can't talk between two or three buildings yet". We can grapple and move payloads already, but we can't escape the spacecraft in a contigency abort.

Especially: We have no C&W subsystem yet at all. Is it really that unimportant? The DPS is still practically empty and it is not only our biggest problem to solve, but also the most important subsystem all around the Space Shuttle.

And if we really want to attract more users, we don't need to get the details on one subsystem down to the microvibrations, but we should make SSU usable without having to study aerospace engineering first. For example by having an AI crew and not a single player doing it all at once.

 

[DaveS]

For the PDRS, I was thinking along the lines of the automatic functions of the RMS. Butr maybe that does require the DPS to be further implemented?

 

[SiameseCat]

For the PDRS, I was thinking along the lines of the automatic functions of the RMS. Butr maybe that does require the DPS to be further implemented?

I think the RMS is one of the more complete parts of SSU at the moment. I know we don't have automated trajectories yet, but I don't think its a big deal to move the arm manually.

 

[GLS]

This is my idea for next versions:
SSU 3.0 - "hopefully released soon" version.
SSU 3.0.1 - bug fix version, fixed release date of 1 or 2 months after 3.1. Could be released just as a patch (SSU 3.0P1).
SSU 4.0 - major items: mission editor with system configuration upgrades and remaining mesh resizes.
SSU 4.0.1 - bug fix version/patch.
SSU 4.1 - major items: OMS/RCS, and maybe aborts with Centaur dumps and CRTMFD is retired.
SSU 4.1.1 - bug fix version/patch.
(...)
SSU 3427.0 - astronaut biological simulation update. :lol:

Version numbers subject to change. Please discuss.

 

[Urwumpe]

I updated the roadmap based on the current plans and nearly done features.

 

[GLS]

Will we do a bug fix release in a few weeks or can we move on to new stuff?

 

[Urwumpe]

Will we do a bug fix release in a few weeks or can we move on to new stuff?

Both. Lets just go on with new stuff, but I will make a release branch for eventual bug fixes, if enough stuff gets around for a bug fix release, we can then do it.

---------- Post added at 02:35 PM ---------- Previous post was at 02:30 PM ----------

Done. A 3.0 tag for all eternity and a 3.0-release branch.

 

[GLS]

Possible roadmap for future releases:
5.0 - first release for Orbiter 2016
5.1 - texture compression overhaul + mesh group re-order
5.2 - middeck update
5.3 - S2 DPS hack
5.4 - PLB cameras (D3D9 only)
5.5 - the "internal" vc must be repositioned and resized to the new locations of the windows (which have to be correct beforehand), keeping panel re-work to a minimum (the vc major update comes later)
5.6 (or with a version above) - SSU Workbench release, with scenario updates
5.x - new mission file format
(^^^ all versions will contain bug fixing as needed, and might be combined)

x.x - payload attachment improvements
x.x - EVA simulation
x.x - OMS/RCS improvements
x.x - Orbit DAP improvements
x.x - Ascent improvements
x.x - MPS improvements
x.x - major vc update to support MCDS
x.x - PAM-A, PAM-D and PAM-D2 upper stages
x.x - GPC multi-thread simulation

The list only goes into the details the short-term major bug fixes, performance changes and new features. Then, only major subjects are listed. Most, if not all, of the points above will have to be worked in branches, so the trunk is always as releasable as possible.

All this is subject to change and other opinions of course.

 

[Urwumpe]

I started a Wiki page for a new Roadmap on SourceForge:

https://sourceforge.net/p/shuttleultra/wiki/Roadmap/

The current suggestion might lack some ambition, but we have to be realistic with the available number of developers.