How long until next release?

[STS]

Guys if this question has no answer please ignore it.

How far are you for a release?

Thank you very much

 

[Urwumpe]

I moved this out of the development thread, in the sense of the first post of it. Please do not ask for support in the development thread, which is just for coordinating the current development work.

We have no fixed release dates, but there are some many tasks that need to be done before the next version can be released. The coarse goal for the next release had been set once to be about reentry, and as you can see the vastly improved aerodynamics code is one important item in development.

But as you can see, there is no fixed schedule and as long as SSU has a strong tendency for bugs, it will only be available as source code from sourceforge, requiring you to use a Visual C++ compiler (Express or Professional) to produce the latest modules.

Once we release a "stable" version again, the number of known bugs should be low enough that we can deal with the questions and reports.

If you want to accelerate things, volunteer. We have more work than people, and programming is actually already the best covered part of it, so a lack of programming skills is no problem. We for example need people who want to write manuals. Having some people who do reviews of the source code, ideally without advanced C++ skills, would also be an advantage for us.

Also, there are many Shuttle landing sites, which need some development work, since we have now a few landing sites that shine, and many that are completely missing.

 

[hribek]

Since nobody does manuals for example, you can set the standards easily. I would just wish (personally) that you use pdfTex, since it would have a few advantages in formatting and collaboration (the source files can be managed on the subversion). For example, we could easily make translations use the same layout as the English master manual.

Actually, I have another idea. You know I've been studying the Orbiter API and such, because of Skylon and Fluyt. And the best file to use for me was neither of the PDFs, but the .chm compiled help file. It's much easier to browse.

Better yet, could the manual be available from within Orbiter, maybe? In my opinion, it would be cooler at least by a factor of two. It's sort of like having a flight plan aboard.
What do you think?

 

[Urwumpe]

Better yet, could the manual be available from within Orbiter, maybe? In my opinion, it would be cooler at least by a factor of two. It's sort of like having a flight plan aboard.
What do you think?

if you want to make CHM help, it is ok for me, but a PDF manual for being printed for off-line use might also be desired.

 

[tblaxland]

Doxygen? It will do pdf, html, chm, etc and support multiple languages.

 

[Wally]

We for example need people who want to write manuals.

Depending on what this implies and how will this work, I might volunteer for writing manuals (though I'm not a native English speaker). Can you send me more details about the workflow?

 

[Urwumpe]

Depending on what this implies and how will this work, I might volunteer for writing manuals (though I'm not a native English speaker). Can you send me more details about the workflow?

That is a tough question, I never thought about workflows there. Good that you ask.

I would say, you need to follow the dev threads about new features, so you know about coming changes. Since we work open-source, the same should apply to the documentation. What you write should be seen by everybody in preliminary form, and available for comment. It would be good if you can use a format, that can deal with version management - LaTex would be preferred as optimal solution (because it permits a "cooperate identity" combined with version control since the input files are pure text), but is not mandatory.

You don't need to copy what is mentioned already in the Shuttle check lists. Instead, you need to explain in the manuals, that differs. Eg, keyboard bindings, Lua interfaces, scenario file parameters and the many tools that we created around the pure Orbiter simulation.

 

[Wally]

I won't promise anything yet, but I'll have a look into the svn and see what I can do. I'll let you know when I have any draft or any deliverable.

 

[Urwumpe]

I won't promise anything yet, but I'll have a look into the svn and see what I can do. I'll let you know when I have any draft or any deliverable.

Well, thank you for at least trying.

 

[LoserSVK]

Hello. Im just wondering what happened because 1.25 is not on hangar?

Anyway meshes are made with blender?

 

[DaveS]

Anyway meshes are made with blender?

No. Primarily with GMAX and AC3D.

Hello. Im just wondering what happened because 1.25 is not on hangar?

It was removed as it is no longer supported with the release of Orbiter 2010. New version is in progress, just be patient. Or you can just do what we devs do: Compile your own modules from the SVN source code. Always guaranteed to be 100% up to date.

 

[LoserSVK]

Okey. Thanks for info. Good luck

 

[SiameseCat]

Posted zip with compiled dlls on sourceforge for anyone who wants to try SSU in O2010. This is NOT a proper release, so no support will be provided if you have any problems.