Space Shuttle Ultra development thread

[Urwumpe]

Both sounds like good ideas to me. Since it's all we have right now, how about putting it in work?

well, i still have some (boring) university work to do, before I resume coding, I will take a look at fixing this later.

But I doubt its the mesh order - the animations are defined correctly, it looks more like the initial state of the animation is redefined. When we first load the mesh, it has its initial state(0) = doors closed. After ET separation, it seems like the door animations have changed initial state(0) = doors open. On the first SetAnimation call to something close to 1, the doors state makes a jump, as the animation initially assumed the current state of the animation was 0.0.

As we use 180° as angle for the animation, both are correct end points of the animation, but when we make a 180° rotation from the open position instead of the closed position, it will look just like its observed: The doors jump to the closed position and rotate through the inside from the open position.


I remember that other people observed such bugs with the 2006 version of Orbiter, but I can't find any information on how it got solved.

 

[Donamy]

That is not light reflection. It's a phenonama known as plume recirculation. That is what is causing the foam on the aft dome to become charred.

I meant right from launch, I know about the plume (which would be cool), but the light reflection would be from SRB ignition to sep.

I've got to do some boring real world stuff too, so won't be able to test ar anything till Sat. I was thinking about a bigger Launch aria mesh to hide the steam and smoke from underground.

Go Atlantis !!! ... and God's speed.

 

[Urwumpe]

I've got to do some boring real world stuff too, so won't be able to test ar anything till Sat. I was thinking about a bigger Launch aria mesh to hide the steam and smoke from underground.

I could also make a configuration file switch, which edits the particle effects of the SRBs, removes the contrail and gives the emissive exhaust a shorter lifetime until the shuttle passed 10m altitude. But until the bigger bugs are found, I don't want to add new features.

Two additions: could somebody make a water spray particle texture (more transparent, fine water spray) and a "water fall" like (almost white, opaque) particle texture? I could use such textures for the SSS of the MLP.

BTW: Is the docking port already optional in Atlantis?

 

[Donamy]

By all means, squash those bugs !! Just a wish list.

 

[DaveS]

BTW: Is the docking port already optional in Atlantis?

Don't think so. Speaking of that, could it be made more configurable? Like choosing between, internal airlock, external airlock only and external airlock with the ODS.

Atlantis will fly with the middle config on STS-125, like Discovery flew on STS-103.

 

[Urwumpe]

Like choosing between, internal airlock, external airlock only and external airlock with the ODS.

Sure. But if we do so, we would need to plan with an extra ODS/airlock mesh as well as have specialized animations for them. Also, it might be a good idea develop a system for handling tunnels, eg for Spacelab (or a lunar capsule :rofl.

EDIT: And kudos for the aerodynamics! I can't say it often enough - it flies really realistically instable now.

 

[DaveS]

Any news on the debugging?

 

[Urwumpe]

Any news on the debugging?

I found out that ClearMeshes was overridden and we did not yet include the meshes of KU and RMS into it. Further investigating.

ClearMeshes is only called from with in the function LoadStateEx, which calls it after we changed the position of the ET Doors inside it.

 

[DaveS]

I found out that ClearMeshes was overridden and we did not yet include the meshes of KU and RMS into it. Further investigating.

ClearMeshes is only called from with in the function LoadStateEx, which calls it after we changed the position of the ET Doors inside it.

Good find! Keep us updated on the investigation.

 

[Urwumpe]

Good find! Keep us updated on the investigation.

The last test did not show much good news:

Now, there had been no ET door animation at all, but at least they stayed opened.

the top SSME nozzle has a tiny yaw offset, I will have to find out what causes it and leaves the other engines straight.

 

[DaveS]

The last test did not show much good news:

Now, there had been no ET door animation at all, but at least they stayed opened.

the top SSME nozzle has a tiny yaw offset, I will have to find out what causes it and leaves the other engines straight.

Is there any to revert back to an earlier revision of the code? I'd like to try it, if you haven't.

That way I could incrementally try each new revision until the bug shows up again.

 

[Urwumpe]

That way I could incrementally try each new revision until the bug shows up again.

The Subversion system allows that, you can specify a version you want to checkout..

BTW: I found this... http://orbit.m6.net/Forum/default.aspx?g=posts&t=6780

Does anybody know if this bug was already fixed or if it is still open?

It should only happen for meshes with mesh_index > 0 ... which is strange, because the orbiter is 0, but its exactly the same behavior as described in the bug report.

 

[DaveS]

The Subversion system allows that, you can specify a version you want to checkout..

OK, just tried revision 51, bug not present. Going to try a later revision.

 

[DaveS]

BREAKTHROUGH! Just tried Rev. 58(which adds the new KU band antenna) and I managed to reproduce the ET umbilical door bug!

Any other revision did not reproduce it.

So something with the KU band antenna broke the ET umbilical door bug.

 

[Urwumpe]

BREAKTHROUGH! Just tried Rev. 58(which adds the new KU band antenna) and I managed to reproduce the ET umbilical door bug!

Any other revision did not reproduce it.

So something with the KU band antenna broke the ET umbilical door bug.

Ok, so the problem is related to the KU band antenna. But how is it related to it...

 

[DaveS]

Ok, so the problem is related to the KU band antenna. But how is it related to it...

Seems like it.

How about going back totally and check every single line that was changed to implement it? Maybe you touched something you shouldn't have and broke the ET umbilical door in the process?

 

[Urwumpe]

Seems like it.

How about going back totally and check every single line that was changed to implement it? Maybe you touched something you shouldn't have and broke the ET umbilical door in the process?

I just tested it without the Ku-Band antenna enabled (no adding of the preloaded meshes, no animations are defined), still the same bug. So if at all, it is not directly related to the Ku-Band antenna code


I try making a diff with version 58

 

[Urwumpe]

Found the bug by going through all changes line by line - the second call to DefineAnimations was actually introduced from my side and was not a older code like I believed the last days. I still don't know what caused me to do this, but well, now its gone.

 

[DaveS]

Found the bug by going through all changes line by line - the second call to DefineAnimations was actually introduced from my side and was not a older code like I believed the last days. I still don't know what caused me to do this, but well, now its gone.

Can confirm that the bugs are gone! Great work hunting down the bug and killing it!

 

[Urwumpe]

Can confirm that the bugs are gone! Great work hunting down the bug and killing it!

!

We are among the 2000 most active projects on sourceforge, but 80% of the activity is actually just me searching the bugs I created.

With out you doing the differential debugging, I would have spent a few days more on the problem.