Space Shuttle Ultra development thread

Is there a new way to launch the SSU now ?

I press the '+' and the engines ignite, but it doesn't launch, just all engines and SRB's blazing.
Could you post the scenario? Maybe something is not config'ed right in it.

Edit:
Just did a test launch with the latest sources: no problems getting off Earth
 
Last edited:
Never mind !! I had to remove the attached to MLP reference. Why was that taken out? It was awesome!!
 
Never mind !! I had to remove the attached to MLP reference. Why was that taken out? It was awesome!!
It seems to be a problem when I compile the MLP sources, that the MLP never initiates the sound suppression water system and releases the shuttle at T=0.

These are the only warnings I receive when I compile the MLP sources:
Code:
[SIZE=1]
MLP.cpp
..\MLP\MLP.cpp(130) : warning C4101: 'ownRV' : unreferenced local variable
..\MLP\MLP.cpp(161) : warning C4101: 'RP1' : unreferenced local variable
..\MLP\MLP.cpp(159) : warning C4101: 'MP2' : unreferenced local variable
..\MLP\MLP.cpp(159) : warning C4101: 'MP1' : unreferenced local variable
..\MLP\MLP.cpp(160) : warning C4101: 'LP2' : unreferenced local variable
..\MLP\MLP.cpp(158) : warning C4101: 'F' : unreferenced local variable
..\MLP\MLP.cpp(160) : warning C4101: 'LP1' : unreferenced local variable
..\MLP\MLP.cpp(161) : warning C4101: 'RP2' : unreferenced local variable
[/SIZE]
 
Is there a new way to launch the SSU now ?

I press the '+' and the engines ignite, but it doesn't launch, just all engines and SRB's blazing.

Is it one of the scenarios with the Shuttle attached to the MLP?

DaveS: You need to enable the communication with the MLP. I made it optional code as long as the MLP is just a prototype. To do so, you have to define the symbol "USE_MLP" (I hope, I can't look currently) in your compiler settings.
 
One problem with having a slightly large shuttle is that, compared to the authentic values, the RMS X/Y/Z coordinates will be wrong for OBSS operations. At some point I'd like to be able to simulate the whole OBSS scan using realistic procedure, and this could mess things up a bit. Could we get away with shrinking the shuttle and leaving the VC alone or would this cause visible errors?
 
Could we get away with shrinking the shuttle and leaving the VC alone or would this cause visible errors?

I think the VC is only affected by some camera modes, and maybe we can trick a bit to avoid it.

But when we decide to fix the animations anyway, we can as well do them all for once and later work with accurate coordinates for VC as well as for the rest of the shuttle.

The current error for the VC would be 42 cm in Z axis - i don't know how you all think about it, but I consider 42 cm difference worth some effort.
 
42 cm is a pretty big error. If we're going to resize the meshes so they're scaled properly (and I think we should), we should probably do it soon, before we add any new animations.
 
I've rescaled both the Atlantis and the VC. it worked out to about 2.75% smaller.
I agree if we are going to do it it should be now, I can get the new animation points for the RMS with MPM's and the KU, but I don't have a clue with the switches.


edit: I guess that would include the payload bay doors, radiators, gear ,gear doors, ET doors, engines,speedbrake,bodyflap,startrackers, air data probes and any other new animations.
 
Does anyone know a good way of getting switch positions? Normally I'd use MeshWizard, but it can't handle the VC mesh.
 
What do you need to know about them ? AC3D shows the switches.
 
Here is what it shows: click to make it larger

NqGKtatW8W9E0X5jDRcoFMGoWFz61Jwmo9Tl8RBfaS-0303fXwIVUfT_6-mtRyPTDZWM2yD56Q11FUd885iXS25MXQ7f13jQ1lR9N0pfdR8
 
Is it one of the scenarios with the Shuttle attached to the MLP?

DaveS: You need to enable the communication with the MLP. I made it optional code as long as the MLP is just a prototype. To do so, you have to define the symbol "USE_MLP" (I hope, I can't look currently) in your compiler settings.

Are you sure you mean compiler settings and nt in the scenario? If you really mean the compiler, could yu show me exactly where it is supposed to define it?
 
What do you need to know about them ? AC3D shows the switches.

The reference position for each switch (=the point where the rotation axis goes through) would be enough, direction would only be needed for switches, which are not rotating up/down.

The rest of the shuttle would also need new positions, maybe it could be enough to multiply each vector by 0.9725 to get accurate new positions.
 
Are you sure you mean compiler settings and nt in the scenario? If you really mean the compiler, could yu show me exactly where it is supposed to define it?

You should have some project settings, where you can define symbols for the preprocessor. All compilers have such a function. I don't know where they are in VC2005, but in VC6 its called "Preprocessor definitions" and can be found under the C/C++ options...
 
You should have some project settings, where you can define symbols for the preprocessor. All compilers have such a function. I don't know where they are in VC2005, but in VC6 its called "Preprocessor definitions" and can be found under the C/C++ options...
OK, thanks. I'll have a look when I get access to the dev stuff again later today. In the meantime I'll have a look around and see where they have moved it in VC++ 2005.
 
OK, thanks. I'll have a look when I get access to the dev stuff again later today. In the meantime I'll have a look around and see where they have moved it in VC++ 2005.

Theoretically, we could also remove the code option and make the communication standard. But I don't feel like the concept is mature enough to become standard.
 
Theoretically, we could also remove the code option and make the communication standard. But I don't feel like the concept is mature enough to become standard.
How would you define the concept as mature? I think it's working pretty good, assuming you compile it right!
 
How would you define the concept as mature? I think it's working pretty good, assuming you compile it right!

Well, the interface is currently just for testing the MLP - we have no LCC, no LPS, no GLS and the other stuff from the launch infrastructure.

When this gets all added, the interface to the shuttle would have to change critically for dealing with these additions.

If we make the interface now standard, we would have to pay attention to keep it stable even when these additions come. Like it is now, we can say, that its not released yet.
 
Well, the interface is currently just for testing the MLP - we have no LCC, no LPS, no GLS and the other stuff from the launch infrastructure.

When this gets all added, the interface to the shuttle would have to change critically for dealing with these additions.

If we make the interface now standard, we would have to pay attention to keep it stable even when these additions come. Like it is now, we can say, that its not released yet.
OK. I see what you mean. It definetly needs more work.
 
OK. I see what you mean. It definetly needs more work.

Yes. I think when the GLS simulation is defined, we can make the Shuttle-MLP interface fixed. The MLP will stay the only direct interface to the ground for the Shuttle, the question is just how the interface looks like when the GPCs are only responsible for engine ignition and lift-off.
 
Back
Top