Space Shuttle Ultra 1.25 Revision B development

[Donamy]

Better, but could you make them somewhat lighter at the top and darker on the bottom ?

 

[Loru]

Better, but could you make them somewhat lighter at the top and darker on the bottom ?

With current emiter settings it's impossible. Orbiter uses the same texture through entire particle stream. There is a workaround however.

You can create 3 particle emiters each at specified distance from the nozzle and use different textures for each emitter. Near the nozzle you can use almost white "fire", then few meters below a little darker one, and more dark texture at the end. It will create 3-colored flame and with correct overlapping of emiters it should produce nice gradual change in exhaust color.

1st emiter (we're counting from nozzle) has smallest initial particle size.
2nd is bigger and 3rd is the biggest.

The timing is the key to correct effect so you have adjust timer correctly:

2nd emiter starts working as soon as particles from 1st one reach 2nd one.
The same for 3rd emiter. I think programing timers for it won't be a problem for you guys.

Also particle lifetime has to be adjusted, so that particle reaching next emiter should dissapear.
Due to this fact overall amount of particles will be roughle the same so FPS impact should be minimal.

Here is schematic for what I have in mind:

I can make textures but I'm not a coder so programming correct emiters is your task.

I hope that will help.

 

[Donamy]

I don't code either, hopefully one of the other code gurus will do it.

 

[DaveS]

Checked in updated animations for the Ku band antenna. The dish now rotates to the correct MIP position which is the equivalent to 0 EL/0 AZ. I also fixed the rotation axis for the alpha and beta gimbal animations.

So the antenna animations are now ready for comm/rendezvous radar ops!

So, maybe it is getting time to implement the IUS so the TDRS constellation can be launched?

 

[Donamy]

With the retirement of the Orbiter Shuttle FLeet, should we have a SSU download on O-H, so people can get it easier ?

 

[Urwumpe]

With the retirement of the Orbiter Shuttle FLeet, should we have a SSU download on O-H, so people can get it easier ?

We would need some kind of build management then. Otherwise, we will never have something that we could let dumbest-possible-users download.

 

[SiameseCat]

It should be easy enough to zip up a single revision from Sourceforge along with compiled binaries, and put the file on Orbithangar. I don't think we'll need build management.

 

[DaveS]

How is the automation of the entry guidance coming along? I'm just looking for a general progress.

 

[Urwumpe]

It should be easy enough to zip up a single revision from Sourceforge along with compiled binaries, and put the file on Orbithangar. I don't think we'll need build management.

Well, then I want to be not responsible for any bug reports that are generated that way.

I don't suggest build management for fun, it is already a requirement for much smaller projects than SSU. It must not be a complete department of build managers testing our software and creating the zipped add-on package. But we should have a way set, how we can release something properly and be later able to identify the bugs that are reported to the version that had been shipped - just saying "install the latest version and we will see" is not helpful for finding bugs.

 

[DaveS]

Well, then I want to be not responsible for any bug reports that are generated that way.

I don't suggest build management for fun, it is already a requirement for much smaller projects than SSU. It must not be a complete department of build managers testing our software and creating the zipped add-on package. But we should have a way set, how we can release something properly and be later able to identify the bugs that are reported to the version that had been shipped - just saying "install the latest version and we will see" is not helpful for finding bugs.

A while ago I got an offer from Tex about setting up a SSU bug reporting project here on the forum. Could this be a good way of tracking bugs?

 

[Urwumpe]

A while ago I got an offer from Tex about setting up a SSU bug reporting project here on the forum. Could this be a good way of tracking bugs?

Yes, but that is not effective without a proper build management. 90% of the problem is finding the parts of your software, that had been working properly when released.

 

[DaveS]

Yes, but that is not effective without a proper build management. 90% of the problem is finding the parts of your software, that had been working properly when released.

The good thing about the project is that you can select the affected version as well as set the priority.

 

[Cras]

SSU is more complicated than Shuttle Fleet ever was. And it SSU becomes easily available, many people I think would end up seeing it as a replacement for it. Would get frustrated by it, and very few will be able to offer solid bug reports. Most would end up reporting things as broken, not because they are, but because they are doing it wrong, installed it wrong, or the like.

 

[Urwumpe]

The good thing about the project is that you can select the affected version as well as set the priority.

Yes, but we need to know the internal state of things at this point of release. We need to test first and that for every release if all things are to the requirements, even if these requirements get enhanced when bug reports show problems. We can't find all bugs before we release, but we should make sure that we catch what we can.

And that is why build management was invented. To have a defined process from when you stop adding new features, to increased test cycles and bug fixing, to automatic pre-release tests and the final release.

We currently do pretty much nothing in that direction, to be honest. We have open source code and lots of things are added, but we couldn't really plan a new release or say when something was working properly in a release.

 

[DaveS]

Yes, but we need to know the internal state of things at this point of release. We need to test first and that for every release if all things are to the requirements, even if these requirements get enhanced when bug reports show problems. We can't find all bugs before we release, but we should make sure that we catch what we can.

And that is why build management was invented. To have a defined process from when you stop adding new features, to increased test cycles and bug fixing, to automatic pre-release tests and the final release.

We currently do pretty much nothing in that direction, to be honest. We have open source code and lots of things are added, but we couldn't really plan a new release or say when something was working properly in a release.

So what is your proposal to make this work? I could take on this role as build manager if needed.

 

[SiameseCat]

We can move the code into a separate branch before a release, then make any bugfixes in the release branch. We can also use Sourceforge binaries for a beta release before putting the file on Orbithangar.

I'm not sure we need to be quite so selective about releases; my inclination would be to put a set of binaries on Sourceforge, and, if we don't get any complaints after a week, put the same binaries on OH.

I think the most important thing we need is good documentation: a lot of the 'bugs' I've seen reported (sometimes by SSU developers) are actually undocumented features (the RCS code would be a good example of this).

---------- Post added at 05:25 PM ---------- Previous post was at 05:22 PM ----------

How is the automation of the entry guidance coming along? I'm just looking for a general progress.

I've wasted a lot of time trying to figure out how to calculate the required roll angle. Now I've got that figured out (I think), and I'm hoping to have working code in a few days.

BTW, the tanking problem has been fixed (although I haven't checked the code in yet).

 

[Urwumpe]

So what is your proposal to make this work? I could take on this role as build manager if needed.

Ok, you have volunteered, the forum may be my witness. :lol:

Then we just need to decide how much build management we need, I think it would be needed that you make sure what is released on O-H does work properly, keep track of the changes and make sure all what we programmers claim to work is also included properly, and maybe also kick us programmers a bit into the softer parts, if we do too many new features and not enough maintenance of the existing ones.

I would like to volunteer on the source code quality management, but I currently lack time, barely find the time to just switch back into C++ after a work week full of Java and a lot of free time hours learning NetBeans RCP.

 

[Poscik]

SSU is more complicated than Shuttle Fleet ever was. And it SSU becomes easily available, many people I think would end up seeing it as a replacement for it. Would get frustrated by it, and very few will be able to offer solid bug reports. Most would end up reporting things as broken, not because they are, but because they are doing it wrong, installed it wrong, or the like.

That's why it's called "Ultra". Fleet was adressed to people who wanted to have quick fun, hit enter and fly. SSU needs more accuracy, attention on some things, time to learn, and especially patience. But I'm 100% sure it's worth of it. Also there is the best manual ever available - NASA checklists. At this point of development, some orbital maneuvers may be difficult, like plane changing and approaching the station, as burns have to be executed through GPC. But I hope this will also change in future.

 

[Urwumpe]

But I hope this will also change in future.

I already look into exploiting some new acquired skills for doing a proper mission editor, but that is currently somewhere on page 200 of our priority list. The subsystems should be working first.

 

[DaveS]

BTW, the tanking problem has been fixed (although I haven't checked the code in yet).

Thanks for fixing it. I got some shots of the actual PC-GOAL display used to monitor the tanking process, if wanted.