MPS development

[DaveS]

OK, then it is caused by the orbiter bug of using thrusters while being attached. I remember I found a fix for it for the SubOrb project, could look into the old sources.

I remember reading about it. All the force from the constant thrusting while attached is applied all at once released. That does explain the severe vertical speed on lift-off.

 

[Urwumpe]

I remember reading about it. All the force from the constant thrusting while attached is applied all at once released. That does explain the severe vertical speed on lift-off.

Yeah, a rubber band effect. I don't yet know what causes it, as it is contrary to what the remaining behavior of attachment points is like.

I think I solved it by manually setting the rvel parameter of the state to the rvel of the pad.

 

[DaveS]

Oh and think I found a cure for your SSME start troubles: make sure the ENGINE POWER switches on R2 is set to ON.

 

[Urwumpe]

Update: I have now included the EIU subsystems, added four MIAs (generally called BIU) to them and connected them to the flight critical buses.

Now, I would just need to implement some functions for sending information over a bus, and receive it again. I think the real-world solution is something around defining a structure for the data, so we should do something similar.

The data structures would also appear identical in GPC memory, as the I/O over the IOP functions mostly over simple Direct Memory Access commands.

 

[GLS]

I still can't test what I've written!! It keeps CTDing me!!!!:compbash2::compbash:

I've put some break points inside prestep (which looks like the last thing it does before it CTD) and funny thing: it arrives at some code for OMS engines and then it goes back, up to the subsys prestep call!!:blink: Also, I can't see the value of some variables in that funct: "something thrust" and "i" and someother variable, are like outside vars that aren't accessible...
Or VS08 is FUBAR or there's some mem corruption going on. I'll keep dig'in... I'll now try a version from last week when it still worked and see what changed......

 

[Urwumpe]

I still can't test what I've written!! It keeps CTDing me!!!!

No automatic CTD here, but I notice that we don't create SSMEs when we load the Orbiter only configuration. No problem for you if you stay on the interface code I have written, as it ignores requests then.

I've put some break points inside prestep (which looks like the last thing it does before it CTD) and funny thing: it arrives at some code for OMS engines and then it goes back, up to the subsys prestep call!!:blink: Also, I can't see the value of some variables in that funct: "something thrust" and "i" and someother variable, are like outside vars that aren't accessible...
Or VS08 is FUBAR or there's some mem corruption going on. I'll keep dig'in... I'll now try a version from last week when it still worked and see what changed......

I will look at it, if you debug with the DLL object code being optimized, you can always observe some very strange behaviors.

The OMS code is correct like it is now (Better: No reason to change it now), it should have other causes.

EDIT: As the SSME gimbal animation currently depends on the direction of the SSME thruster, this might also be a potential CTD cause. I think I will put same safeguards around this as well.

 

[GLS]

Hello! Here goes a little update about the SSME development.
Well... it's going slowly but it's going. I think the engine controller input is mostly done, and now I'm working on engine control and here is where it slows down big time: the logic to check sensor redlines (and to qualify the sensor) is pretty confusing when you start considering sensor failures...:suicide: and also the redlines change with the controller mode.... so I'm just making some redlines and them I'm skipping ahead to controller output so that I can have a working version ASAP! Assuming no show stoppers I think by April I'll have a working version to upload....

 

[Donamy]

...sitting tight.

 

[Urwumpe]

GLS: I would make a basic sensor class and use special subclasses of the sensor class for implementing pressure, temperature, etc. sensors. There, you could then also implement failure behavior.

 

[Urwumpe]

Found this one during a short research phase, could maybe be interesting:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19820003911_1982003911.pdf

 

[GLS]

Found this one during a short research phase, could maybe be interesting:

http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/19820003911_1982003911.pdf

Thanks Urwumpe, but I already have that one.......

 

[Urwumpe]

Thanks Urwumpe, but I already have that one.......

I wasn't sure, and more than you just saying this could not go wrong.

 

[Donamy]

Are we going to do some updating to the SSME animatios and graphics ? I got a few ideas.

 

[Urwumpe]

Are we going to do some updating to the SSME animatios and graphics ? I got a few ideas.

of course, feel free to say them. As it involves graphics, I know you can do them.

I have an update to the GPC code in the baking, will have the Shuttle Bus stuff finally implemented, I am just wondering about doing the message passing call by value or call by reference. The first is slower, but more robust to bugs.

 

[Donamy]

My idea is to have each SSME fire in turn, with a short burst of red thrust, then disappear, while the shock diamonds appear and each engine cycles to launch position. Does anyone know, at what altitude the the shock diamonds disappear and turn to a white glow of the engine bells? Then I think they gradually turn orange and then to a reddish hue before shut-down.

 

[DaveS]

My idea is to have each SSME fire in turn, with a short burst of red thrust, then disappear, while the shock diamonds appear and each engine cycles to launch position. Does anyone know, at what altitude the the shock diamonds disappear and turn to a white glow of the engine bells? Then I think they gradually turn orange and then to a reddish hue before shut-down.

What happened to the animated SSME exhaust you made a while ago? Look fantastic in the short video you sent me.

 

[Donamy]

I plan on using something like that for the diamond shock phase.

---------- Post added at 05:14 PM ---------- Previous post was Yesterday at 09:17 PM ----------

Should I add the exaust mesh to the shuttle mesh, or have them be put in like the chute by code?

 

[SiameseCat]

How do you want the exhaust mesh to be displayed? It's probably better if this is a separate mesh, but I'd like to have an idea of the effect you want.

 

[Donamy]

First I need a short pulse of red exhaust thrust, then the exaust mesh which is tubular shaped with a alpha texture, that is spun for the effect. The shock diamond needs to be scaled from up inside engine bell center, down to it's position for launch.

 

[SiameseCat]

I think a separate mesh would be best for this. Also, it might be a good idea to have the mesh contain exhaust for only one engine, and use it multiple times (instead of having one mesh have three exhaust streams).