Space Shuttle Ultra development thread

A blank panel for the A8 panel would be easy, but would it interfer with the animations not having all the switch groups ?

I will investigate which methods we have for not having the animations. Deadfacing the event call backs will be one possibility.

EDIT:
EC05-0166-17.jpg


Could this be useful for improving the landing gear visual?
 
Who is doing the landing gear?

I started doing the nose gear, but I gave up trying to animate it. I still have the Gmax file, but I guess the scale has changed since then. If anyone wants it, they can msg me.

 
Who is doing the landing gear?

I started doing the nose gear, but I gave up trying to animate it. I still have the Gmax file, but I guess the scale has changed since then. If anyone wants it, they can msg me.

Did you render this with perspective? the length of the triangle part looks a bit extreme.
 
Did you render this with perspective? the length of the triangle part looks a bit extreme.

It is perspective, but at a narrow FOW. The triangle on the nose gear IS quite long. It's mounted much 'flatter' then the main gear struts.
05pd0748.jpg
 
Speaking of animations, did anyone get the Baydoor hinges to work ?
 
Speaking of animations, did anyone get the Baydoor hinges to work ?
Yes. They're fully operational and active as a part of the door opening/closing sequence.
 
Wish I could see that. :(

If you mean the mechanism to open the doors - this has not been included yet. I had a test of the push rods done, but the following animations had not been calculated yet.

EDIT: On the circuit breaker shape: I have found this photo so far, looks like nasaimages.org is a bit slashdotted.

http://nasaimages.org/luna/servlet/detail/nasaNAS~9~9~61053~164900:

From this image and others, I produced this rough drawing of the CB shape. Any protests?
 

Attachments

  • Circuitbreaker.png
    Circuitbreaker.png
    24.1 KB · Views: 614
Last edited:
I've fixed the PanelA8 switches and added a meshres_vc_a8.h file for the PanelA8 mesh. This file has to be included in the Atlantis project. I still haven't animated the switch covers yet.

EDIT: Should there be a separate scenario file entry to display PanelA8 or should it use the RMS entry?
 
I've fixed the PanelA8 switches and added a meshres_vc_a8.h file for the PanelA8 mesh. This file has to be included in the Atlantis project. I still haven't animated the switch covers yet.

I will add a generic switch guard class to the object oriented panel code soon, I just write some information about the MTU functionality into the DPS definition file, which I researched inside one of the ICD files.

Will make the MTU a few levels more realistic, as we can now internally use the same time frame format, as the real shuttle (IRIG-B, pulse coded serial data with 100 pulses/s).

so... roadmap for today (actually I wanted to go swimming, but looks like I will swim in code):


  • Define time bus class. Allow GMT, MET (in IRIG-B format) or generic square pulses at different pulse rates (10 Hz, 100 Hz, 1000 Hz, 1024 Hz, 4608 Hz required).
  • Define input port class for subsystems and panel objects. Functions:
    • Count pulses in current time step
    • Buffer IRIG-B frame
    • Count pulses since beginning of frame
    • Return pulse rate
  • Change MTU interface - no special output port needed as only one MTU inside Shuttle:
    • Set IRIG-B buffer
    • Emit pulses.
  • Implement forward event timer as panel object and connect panel object to switches, wheels and 1000 Hz square pulse bus of the MTU.
  • Implement MET/GMT clock as panel object. connect to single switch and the MTU IRIG-B buses.
 
I'm going off the grid for a few days, so I'll just post the Gmax file of the nose gear here.
View attachment Nose012.zip

If you cant find any use for it, I won't bother with the main gear. :lol:

See ya in a few days. :cheers:
 
I have checked in a fix for the ODS vertical offset issue. Now it sits properly in the payload bay.
 
I'll work on the CB's abit more, I can add the white area to the bottom of the CB so it will be in the "open" for default. I'll also update the ODS panel CB's to that of the L4 panel.
 
I'll work on the CB's abit more, I can add the white area to the bottom of the CB so it will be in the "open" for default. I'll also update the ODS panel CB's to that of the L4 panel.

Thank you, I can make a reacting CB object for the panels in no time, but connecting it between two bus systems will be a bit more complex...as I still have no good idea on the how.
 
Quick question: the funct Realise (in the subsystems) is still not active?
I'm asking because over the weekend I wanted to do some *hot-fire* testing (aka FRF:speakcool:) on some changes and I noticed that the engines weren't being created...:( . So then I created the engines my self (actually just one...) and noticed that it always read 0.964something and when I called SetThrusterLevel the thing CTDed me!!!:compbash:

Also, some weeks ago I made another FRF and the (new) SSMEs had some conflicts with the gox vents, the code that was setting the vent level was also setting the (new) SSMEs level.... don't know how but it did.

BTW: I don't need anything right now, it's just a heads up. I still have a lot to do... the FRFs can wait!
 
Yes, the engines are currently just in transparent testing - running parallel to the existing engine code. As it is still not able to replace all capabilities of the existing code, I decided to include it like that. When the ATVC code is there and we can route the existing GPC commands to it, we can make comparative testing and finally switch simply over to your code - and back if something goes wrong during runtime which we can mitigate.

The creation of the engines inside Realize() will have to change. I know it was my idea, but I more and more notice, that the responsibility for all directly Orbiter related resources belong to the Atlantis class - meshes, propellant resources, attachments, docking ports, light beacons and thrusters.

As such, I think the better way to implement the SSMEs for you will be:
The Atlantis class creates them and makes them available for the SSME objects over a public interface. When they are not available(for example during initial creation, but also later for testing), the functions give you a error condition which means you are operating in transparent mode.

You can still use the functions as usual in transparent mode, but they will not have effect.
 
Dennis, would you like me to move the CBs into the panel, in the closed position, so they can be made to pop out ?
 
Dennis, would you like me to move the CBs into the panel, in the closed position, so they can be made to pop out ?

I think the open position would be more natural for us, as this is the inactive state of the circuit breakers.
 
Back
Top