MPS development

[Donamy]

I can send you what I have with an ini and scenario if you wish ?

 

[SiameseCat]

Donamy: That might be helpful.

 

[SiameseCat]

I've been working on adding the flames mesh for the exhaust, and the mesh causes transparency problems (see attached image). I've also checked the exhaust mesh in (Meshes\SSU\launchflame.msh)

 

[Urwumpe]

I've been working on adding the flames mesh for the exhaust, and the mesh causes transparency problems (see attached image). I've also checked the exhaust mesh in (Meshes\SSU\launchflame.msh)

that is a show stopper...

 

[Donamy]

Makes me sad too.

 

[Urwumpe]

I want to make a cheated solution for the GPC - Subsystem communication today and in this pass enable the EIU and the ME Controller parts, which are currently rather bypassed.

Attempting to implement the proper I/O model of the GPCs and the standard communication protocols on the Shuttle Bus system is appearing more and more impractical, It takes unreasonable much time to do, I still have many missing informations about communication (for example the MEC command words), and for a while, it will not be noticed by the player (We have no GPC emulation in sight and failures caused by the bus protocols are not yet simulated)

 

[DaveS]

I've been working on adding the flames mesh for the exhaust, and the mesh causes transparency problems (see attached image). I've also checked the exhaust mesh in (Meshes\SSU\launchflame.msh)

Hmmm..... Show-stopper indeed. From my experience dealing with issues like this one, the solution could be as simple as swapping the order of the SSME and SRB thruster definitions.

Currently we define the SSME thrusters first and the SRBs last. In order for Orbiter to render the SSME thrusters on top of the SRB thrusters, the SSME thrusters need to be defined last, not first.

Have you tried this?

 

[Urwumpe]

DaveS: Thruster order does not matter, only mesh order does. And I think the SSME flame meshes are already defined last in the list, otherwise the mesh order would have changed.

 

[SiameseCat]

The SRB exhaust just uses particle streams, not meshes; I don't think changing the order will work.

---------- Post added at 06:36 PM ---------- Previous post was at 06:20 PM ----------

Just tested it; changing the order doesn't help.

 

[DaveS]

The SRB exhaust just uses particle streams, not meshes; I don't think changing the order will work.

---------- Post added at 06:36 PM ---------- Previous post was at 06:20 PM ----------

Just tested it; changing the order doesn't help.

Too bad. Could we maybe live with this as the actual exhaust is only visible for 40-50 seconds into flight? After that only the nozzle glow is visible.

 

[Urwumpe]

Too bad. Could we maybe live with this as the actual exhaust is only visible for 40-50 seconds into flight? After that only the nozzle glow is visible.

Honestly - I think we should drop this for now. It makes no sense to me, to add a visual feature, that has to be "tolerated" for most of the time it is visible.

maybe a new version of Orbiter, or a different renderer, will make such things possible.

 

[Donamy]

Honestly - I think we should drop this for now. It makes no sense to me, to add a visual feature, that has to be "tolerated" for most of the time it is visible.

maybe a new version of Orbiter, or a different renderer, will make such things possible.

How are the regular SSME exhausts able to render correctly ?

 

[Urwumpe]

How are the regular SSME exhausts able to render correctly ?

They are billboards and rendered in a different pass of the Orbiter engine, as it can assume them to be transparent.

 

[Donamy]

Meshes can't do that ?

 

[Urwumpe]

Meshes can't do that ?

As far as I know, not. we could attempt replacing the exhaust flame texture in flight.

 

[Donamy]

But can they be animated ?

 

[GLS]

I want to make a cheated solution for the GPC - Subsystem communication today and in this pass enable the EIU and the ME Controller parts, which are currently rather bypassed.

Attempting to implement the proper I/O model of the GPCs and the standard communication protocols on the Shuttle Bus system is appearing more and more impractical, It takes unreasonable much time to do, I still have many missing informations about communication (for example the MEC command words), and for a while, it will not be noticed by the player (We have no GPC emulation in sight and failures caused by the bus protocols are not yet simulated)

What do you have in mind?

 

[Urwumpe]

What do you have in mind?

Something like a Proxy design pattern, if you know what I mean (From the "Gang of Four" book)

 

[GLS]

Something like a Proxy design pattern, if you know what I mean (From the "Gang of Four" book)

not a clue...:huh:

 

[Urwumpe]

not a clue...:huh:

Translation:
http://en.wikipedia.org/wiki/Proxy_pattern

[ame="http://www.amazon.com/Design-Patterns-Object-Oriented-Addison-Wesley-Professional/dp/0201633612/ref=sr_1_1/181-1628426-6845750?ie=UTF8&s=books&qid=1246891459&sr=8-1"]Amazon.com: Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series): Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides: Books[/ame]