Space Shuttle Ultra development thread

From looking at the ExtMFD code, it shouldn't be too hard. All we really need as a class derived from ExternMFD.
The main thing we need to do is call GetDisplaySurface() on the MFD and copy the display into the VC mesh group. The easiest way to do this might be to assign each mesh group an individual texture and update this texture directly. The problem with this method is that we'll probably need duplicate textures for each MFD, which will really increase the download size. Does anyone know how Orbiter draws the MFDs?
 
bottom left is 0,0 bottom right is 1,1. I think, don't quote me on that.
 
But we would have to do a large deal of the MFD stuff ourself. That is the risk.
By this you mean drawing the MFD directly onto the display surface using GDI? I must admit I am a little confused as to how this is different from what you were proposing back in post 807.
 
By this you mean drawing the MFD directly onto the display surface using GDI? I must admit I am a little confused as to how this is different from what you were proposing back in post 807.

No, on the MDU texture. Yes, it is different, but it makes it still possible to use other MFDs... a tiny improvement. Also, as the displays can be kept as MFD, you could still display them in generic cockpit mode.
 
The ExternMFD class provides a SURFHANDLE to a surface containing the MFD display. We need to copy this surface onto the VC area where the MFD is displayed.
 
Just uploaded the HydAct files with the disc ports for the ATVC.... hope someone has the guts to make the Hyd...:suicide:

Urwumpe, I'm still waiting on your functs for the transparent simulation on MPS/SSME.
 
New parachute for SSU, just have to get an alpha channel working on the texture.
Can someone give me some info to set up the Nvidia .dds converter ?
 

Attachments

  • STS_125.jpg
    STS_125.jpg
    54 KB · Views: 607
New parachute for SSU, just have to get an alpha channel working on the texture.
Can someone give me some info to set up the Nvidia .dds converter ?
Just use DXTBMP(http://www.mnwright.btinternet.co.uk/programs/dxtbmp.htm) or use the Orbiter SDK included DXTEX utility.

You know how to create an alpha mask works right? Then it would more simple to just use DXTEX and name the alpha mask texture like this: normaltexnamehere_a.bmp. That will make DXTEX load the alpha mask automatically when you open your normal texture file. Then just compress it to DXT-3 or DXT-5 as those two formats handle alpha masks and then just save it like you normally would do with any other texture.
 
Thanks Dave, here a video.

 
Nice! Could you maybe reduce the swiveling of the chute a bit? It seems to be a bit on the extreme side to me.
 
Nice! Could you maybe reduce the swiveling of the chute a bit? It seems to be a bit on the extreme side to me.

Yes, but it already looks awesome. Maybe down to 70% of what it is now, also the frequency seems to be a tiny bit too high (maybe 15% less).
 
Thanks guys,
I think it may be abit too big also, maybe 10% smaller.
 
Checked in a new orbiter mesh with some fixes:
-Corrected number of handrails on the aft PLB bulkhead
-Corrected aft PLB cam positions and updated the animation code to reflect this
-New texture for the wings and payload bay doors
-Corrected some texture errors on the wing flipper panels and inboard elevons.
No changes to meshgroup order, that is fully intact.
 
I'm trying to let the Atlantis class call particular functions at fixed intervals (i.e. every second).

I think the best way of doing this is to create a class containing a function pointer. Once a given period has elapsed, the function will be called. We can use a vector of instances of this class to schedule function calls at fixed intervals. Comments?
 
I'm trying to let the Atlantis class call particular functions at fixed intervals (i.e. every second).

I think the best way of doing this is to create a class containing a function pointer. Once a given period has elapsed, the function will be called. We can use a vector of instances of this class to schedule function calls at fixed intervals. Comments?

If it is going to be for the GPC or Engine Controller, better put this into the class and away from the main vessel class, I don't know an other place where we need such fixed intervals.

Also, I would use a structure, which contains:

  • Sim/Real Time of next call
  • pointer to interface
I know this pattern from other projects and it is usually more accurate as just counting passed time centrally. You just compare the stored time of each function with the reference time and when higher, call the function and add x to the time for the next call.
 
At the moment I need this for the AttControl function, part of the Atlantis class (but really a GPC function; we just don't have a GPC class yet). For the moment it's probably best to implement this in the main GPC function.
 
At the moment I need this for the AttControl function, part of the Atlantis class (but really a GPC function; we just don't have a GPC class yet). For the moment it's probably best to implement this in the main GPC function.

Well, we could also move the GPC function into a class now, when it is still small, and slowly remodel it to support multiple GPCs etc...
 
Refinement of the SSU chute. Now, who wants to do the hard part. ;)

 
*puts self into cryogenic state, wired up to internet for awakening when next version is released*
 
Well, we could also move the GPC function into a class now, when it is still small, and slowly remodel it to support multiple GPCs etc...
I can move the existing GPC functions to a GNC class in the dps namespace. We can add PL and SM classes once we start implementing those functions.
 
Back
Top