SSU V1.25 Release

Status
Not open for further replies.
Just to be on the same line here: At SRB sep the code calls for the texture specified in Atlantis.h DEFAULT_SCORCHED_ET_TEXTURE to be loaded and overwrite the texture specified in the line DEFAULT_NORMAL_ET_TEXTURE right?

Yes. It replaces the texture in the loaded mesh.
 
OK. And none of the logging code for the code in Atlantis.cpp shows up in Orbiter.log so maybe it isn't being executed for some reason? I tried swapping the textures(scorched became normal and normal became scorched) with no effect.

I also tried setting the texture flag in the ET-129.msh to D and it didn't help either. So there's something in the code that prevents this from working correctly.
 
Can you change the LED backgrounds to be black (instead of gray)? The pictures I've seen show a black background for the LEDs, and this would also match the background of the digit bitmaps.

Do you mean on the texture ?

---------- Post added at 03:35 PM ---------- Previous post was at 03:17 PM ----------

checked in new A8top.dds with black background for the joint angles.
 
The new A8 texture looks good.

---------- Post added at 12:38 PM ---------- Previous post was at 12:16 PM ----------

I just had a look at the ET texture problem, and I seem to be getting the scorched texture all the time, even before the SRBs separate.
 
Any updates on the ET scorched texture bug investigation?
 
I'm not sure the function to change the ET texture was ever being called. Try the current version and see if it works now.

---------- Post added at 10:42 PM ---------- Previous post was at 03:06 PM ----------

Urwumpe: How do you want to handle rotary switches? In particular, I'm wondering whether to use multiple discsignals for output, with only one signal being set, or to use a single signal, with the voltage varying depending on the switch position.

---------- Post added at 11:42 PM ---------- Previous post was at 10:42 PM ----------

I've checked in test code for the LED displays. At the moment, the displays show the angles for the shoulder yaw, shoulder pitch and elbow pitch. I've also modified digits.bmp to show +, - and . symbols.
 
A8 LEDs work fine here. Although the rotary switches doesn't work, is this intentional?
 

Urwumpe: How do you want to handle rotary switches? In particular, I'm wondering whether to use multiple discsignals for output, with only one signal being set, or to use a single signal, with the voltage varying depending on the switch position.

I wanted to do three classes for implementing them (Wanted to do this actually this weekend). A basic class for implementing animation and user interface code. And two special classes for defining the connections:


  • RotaryMuxSwitch - Acts as multiplexer: many input signals, one output signal. Will be used for example in Panel F9.
  • RotaryDemuxSwitch - Acts as demultiplexer: One input signal, many outputs (up to 12, if I see the VC correctly). This one is the kind of rotary switch, you will see most often in the VC, according to the RMS telemetry (One 16 bit word in the telemetry is one rotary switch, with only one bit set depending on position).
Have this system in my brain for some months now, after reading the telemetry listing of the RMS.
 
Would it be possible to put a line in the scenario, to load the texture you want into the orbiter.msh ?
 
Would it be possible to put a line in the scenario, to load the texture you want into the orbiter.msh ?

Usually, I would say yes, but I am currently careful regarding such predictions. Switching liveries for containers works for me, doing the same with SSU failed.
 
It would then make it possible, to load any Orbiter texture to SSU.
 
It would then make it possible, to load any Orbiter texture to SSU.

Yeah. which would increase realism a lot. But I can't tell you yet why the same code which works for the TEU2001 project, did not work for SSU.
 
Yeah. which would increase realism a lot. But I can't tell you yet why the same code which works for the TEU2001 project, did not work for SSU.
Maybe it is the same problem that caused the scorched ET texture not to work?
 
Is the ET texture swap working now ?
 
I wanted to do three classes for implementing them (Wanted to do this actually this weekend). A basic class for implementing animation and user interface code. And two special classes for defining the connections:


  • RotaryMuxSwitch - Acts as multiplexer: many input signals, one output signal. Will be used for example in Panel F9.
  • RotaryDemuxSwitch - Acts as demultiplexer: One input signal, many outputs (up to 12, if I see the VC correctly). This one is the kind of rotary switch, you will see most often in the VC, according to the RMS telemetry (One 16 bit word in the telemetry is one rotary switch, with only one bit set depending on position).
Have this system in my brain for some months now, after reading the telemetry listing of the RMS.
By input, do you mean the switch position, or something else?
 
By input, do you mean the switch position, or something else?

No, I mean the discrete line(s). In the real shuttle, one type of switch could do both special cases I have here, but here, we have the discretes to be practically one-way streets, for the sake of being less ugly in programming.

Mux would take many input lines, and turn them into a single output. The output "voltage" is equal to the "voltage" of the selected input line.

Demux would take just one input line (or none) and turn it into many outputs. The selected output would be like the input, the other outputs would be zero (grounded)
 
So, making a orbiter texture swap would also be possible... :)
It is. I believe SC found that the ET tex swap code wasn't as I suspected not being called and therefore it didn't work. So, just make sure that the code is being called and it probably will work.
 
Status
Not open for further replies.
Back
Top