Space Shuttle Ultra development thread

[DaveS]

DaveS: Can you try the latest version? The MPM code works fine for me, so I'm not sure what's causing this bug.

Well, it doesn't crash now but the MPMs doesn't show up.

 

[SiameseCat]

I commented out the code to display the MPMs, which is why they don't show up. You might want to make sure the OBSSMPMs.msh file is in the Meshes/SSU directory.

 

[DaveS]

I commented out the code to display the MPMs, which is why they don't show up. You might want to make sure the OBSSMPMs.msh file is in the Meshes/SSU directory.

It's there.

 

[DaveS]

An update: The code does if I substitute the OBSS for the MPMs. I don't understand why it works with the OBSS and not the MPMs.

 

[SiameseCat]

So the code works with the OBSS mesh, but not withthe OBSSMPMs mesh? That's really odd.

 

[DaveS]

So the code works with the OBSS mesh, but not withthe OBSSMPMs mesh? That's really odd.

Indeed it is. I have checked the MPM mesh, nothing unusual there. I have even imported it into GMAX and re-exported it just to be on the safe side, no help there!

I now plan to do one last thing: ripping the MPMs from the RMS mesh and exporting those as the OBSS MPMs just to see if it is anything about the original MPMs that it doesn't like.

 

[Urwumpe]

Indeed it is. I have checked the MPM mesh, nothing unusual there. I have even imported it into GMAX and re-exported it just to be on the safe side, no help there!

I now plan to do one last thing: ripping the MPMs from the RMS mesh and exporting those as the OBSS MPMs just to see if it is anything about the original MPMs that it doesn't like.

I am only a few minutes away from committing a first version of the payload handling, shall I take a look at the code and fix my interpretation of the bug?

 

[DaveS]

I am only a few minutes away from committing a first version of the payload handling, shall I take a look at the code and fix my interpretation of the bug?

Hmmm, as tempting as it sounds, I would suggest not, at least not without an explanation of what you think is causing the bug!

I don't know about SiameseCat, but I really, really hate Unexplained Anomalies(UAs) and right now this is a UA!

Edit:
Further development: I now really went drastic and made the code load the default MMU and it came with a really interesting effect: the helmet of the MMU/EMU was a full orbiter wing span off to the starboard side of the main body of the MMU guy!

So something funny is going on here!

 

[Urwumpe]

Hmmm, as tempting as it sounds, I would suggest not, at least not without an explanation of what you think is causing the bug!

I don't know about SiameseCat, but I really, really hate Unexplained Anomalies(UAs) and right now this is a UA!

I suspect simply that the way we currently calculate the offset for the mesh is not robust and can CTD. After all, we give orbiter a pointer to the result of a internal calculation. I don't know what the standard says about this kind of code, but my programmer feeling is, we are using implicit behavior and implicit behavior is always bad.

I wanted to test the code making it a more explicit statement and look how the code reacts.

Also possible cause: We change the mesh order for animations by adding this mesh. We should look into the runtime to examine which meshes change their indices and fix them. The mesh handling for the panels and optional subsystems for example is far from as robust as I would like it.

 

[DaveS]

I suspect simply that the way we currently calculate the offset for the mesh is not robust and can CTD. After all, we give orbiter a pointer to the result of a internal calculation. I don't know what the standard says about this kind of code, but my programmer feeling is, we are using implicit behavior and implicit behavior is always bad.

I wanted to test the code making it a more explicit statement and look how the code reacts.

Also possible cause: We change the mesh order for animations by adding this mesh. We should look into the runtime to examine which meshes change their indices and fix them. The mesh handling for the panels and optional subsystems for example is far from as robust as I would like it.

Makes sense as it sure explains why the helmet ended up where it did. Committ the fix and we'll see if it fixes anything.

 

[Urwumpe]

Makes sense as it sure explains why the helmet ended up where it did. Committ the fix and we'll see if it fixes anything.

I committed the payload code, now I look at the MPM code. I suspect the biggest problem are the mesh indices which went wrong.

We currently define the bulk of the animations BEFORE any meshes are added. This is a big problem for us, as we for example always define the RMS animations, even if they are not used.

 

[SiameseCat]

It's probably the mesh indices. The indices are in order of when they are created, so the MPM should be created last of all to avoid changing other indices.

 

[Urwumpe]

I think we could save some trouble if we only define those animations before adding any meshes, which are always available. so Kuband and RMS should have to go...

 

[SiameseCat]

I moved the DefineAnimations() call to the end of the UpdateMeshes() function.

 

[Donamy]

Do any of these meshes have to be fixed, in a 3D program?

 

[DaveS]

Do any of these meshes have to be fixed, in a 3D program?

If you're talking about the OBSS MPMs, then no. I was just debugging the code.


Edit:
Good news to report! The MPM code now works without CTDs or missing MPMs! So it seems we're on the right track here!

 

[DaveS]

Any other progress reports?

 

[Urwumpe]

Any other progress reports?

Not much from my side, only spend a hour today researching the EPS a bit more. Found out that my image of the MCAs was not correct - they are not practically identical, but instead each type of MCA (forward, mid, aft) has different behavior and connections.

 

[DaveS]

Not much from my side, only spend a hour today researching the EPS a bit more. Found out that my image of the MCAs was not correct - they are not practically identical, but instead each type of MCA (forward, mid, aft) has different behavior and connections.

Interesting. BTW, the ODS have a offset problem, it's way off in the Z-axis(up/down) being too much towards -Z.

 

[Urwumpe]

Interesting. BTW, the ODS have a offset problem, it's way off in the Z-axis(up/down) being too much towards -Z.

Yes, I noticed the same when looking at the auxiliary attachment arrow. To correct it, one constant in Atlantis.h would need to be corrected, but I have no idea where we we want to have the docking port. I think good would be the position for hard dock.