SSU Development thread (4.0 to 5.0) [DEVELOPMENT HALTED DUE TIME REQUIREMENTS!]

[DaveS]

I thought I would start this thread to centralize all the VC update discussions and I'll to do by quoting GLS's MDU reply from the main development thread:

So I started the "MFD revolution" in the Orbiter2016 branch (should we create a SSU 4.0 to 5.0 thread for this?) by making a very very simple MFD for the Centaur vessel to display the info up to now shown in the HUD. It uses the 'T' key so it will not work with the keyboard as it collides with CRTMFD, but as when this is all done the CRTMFD will not be accessible from the Centaur (or anywhere else), this conflict will solve itself.
In the future we can have all kinds of pretty drawings in there, but for now I think just the numbers works fine.
IUS is next, and then the CRTMFD which will have to be done in parts: move the MFD into the vessel, change to sketchpad, add D3D9 goodies, move the subsystem displays into the MDU class (not in this particular order).

Is there anything mesh-wise that needs to change for best possible performance with the new MDUs?

 

[Urwumpe]

Is there anything mesh-wise that needs to change for best possible performance with the new MDUs?

Not sure, we could of course for example improve the event timers and MET clocks, which are really consuming a lot of FPS.

 

[DaveS]

Not sure, we could of course for example improve the event timers and MET clocks, which are really consuming a lot of FPS.

In what way do they need to improved? Don't they already use the same technique as the new TBs?

 

[Urwumpe]

In what way do they need to improved? Don't they already use the same technique as the new TBs?

AFAIR not yet, but they should. Same for the RCS/OMS propellant indicators.

 

[DaveS]

AFAIR not yet, but they should. Same for the RCS/OMS propellant indicators.

OK. Anything else while I'm at it?

 

[Urwumpe]

OK. Anything else while I'm at it?

Not sure, would need to check it...for example the warning lights. I think it is already using the new standard.

Technically, we don't need any blitting operation in SSU except the CRTs and even there it is only temporary needed.

What I would like to suggest is separating SSU development directory and the Orbiter directory used for testing and libraries, using a deploy script to make sure that we also test according to the files we are going to include in a release. I have a test of this here on my PC for another project and it works fine with 2010 and 2016.

 

[GLS]

I was thinking about when we get the panels all separated and fix all the little problems that exist in the vc, we should also upgrade all the (remaining) talkbacks, lights and LEDs to the "UV-system".
I remember seeing some images of the new Orbiter version in which the vc panels on the default Atlantis had a back light. We could at least get the new panels ready for that when they are separated, so in the future that can be done "easily". A thing that stopped me from already upgrading some lights is that in the real vehicle, the light intensity is controllable. I don't know if/how that is possible to do in the new Orbiter, but if it is possible we should at least plan for it.
About the current 7-disp LED lights, a vc component will have to be crafted for them to "automate" displaying stuff (I still haven't sat down to fully think it ), and the mesh groups that already exist will have to be resized as I think they are overlapping each other.

 

[Urwumpe]

I was thinking about when we get the panels all separated and fix all the little problems that exist in the vc, we should also upgrade all the (remaining) talkbacks, lights and LEDs to the "UV-system".
I remember seeing some images of the new Orbiter version in which the vc panels on the default Atlantis had a back light. We could at least get the new panels ready for that when they are separated, so in the future that can be done "easily". A thing that stopped me from already upgrading some lights is that in the real vehicle, the light intensity is controllable. I don't know if/how that is possible to do in the new Orbiter, but if it is possible we should at least plan for it.

I already researched this feature, but on the DG in Orbiter beta, it used an undocumented mesh flag. If I would know how this all works, I would implement it on SSU as well. But right now, I can't guarantee it to work.

 

[GLS]

About the MDU screens, currently they are 2 parts ("main" display and menu)... I don't really see the point in that, and anyway we need to manually the menu completly if we are to do it like the real think.

Another thing that I don't think is going to be easy, is making the vc structure (no panels) such that we can then have the correct overhead panel configuration on Columbia. They were a bit different due to the ejection panels.

 

[Urwumpe]

About the MDU screens, currently they are 2 parts ("main" display and menu)... I don't really see the point in that, and anyway we need to manually the menu completly if we are to do it like the real think.

Another thing that I don't think is going to be easy, is making the vc structure (no panels) such that we can then have the correct overhead panel configuration on Columbia. They were a bit different due to the ejection panels.

Its a legacy of the MFD implementation of Orbiter, for supporting standard orbiter MFDs. Not needed if we do away with generic MFDs.

 

[GLS]

I already researched this feature, but on the DG in Orbiter beta, it used an undocumented mesh flag. If I would know how this all works, I would implement it on SSU as well. But right now, I can't guarantee it to work.

If we need time to "learn" things, then I say we wait on the vc upgrade, and when we're ready we do it in one go. There are plenty of other things to do in the meantime.

 

[Urwumpe]

If we need time to "learn" things, then I say we wait on the vc upgrade, and when we're ready we do it in one go. There are plenty of other things to do in the meantime.

Sorry, I have to disagree. There is no reason right now to do it all in one large step. We can afford smaller steps and we should do so. Should we need dramatic changes to the mesh for panel lighting, we should do so. But right now, it looks like we don't have to worry, the DG meshes in the beta are not showing magic.

 

[GLS]

Its a legacy of the MFD implementation of Orbiter, for supporting standard orbiter MFDs. Not needed if we do away with generic MFDs.

I haven't thought about how it will work with just one texture, but I think it has to be done somehow. Right now in the MFD world, we can get a better CRTMFD without "making many waves", by changing to sketchpad and by making it SSU-specific. The single texture thing should be done with the vc panel upgrade.

---------- Post added at 12:12 AM ---------- Previous post was at 12:09 AM ----------

Sorry, I have to disagree. There is no reason right now to do it all in one large step. We can afford smaller steps and we should do so. Should we need dramatic changes to the mesh for panel lighting, we should do so. But right now, it looks like we don't have to worry, the DG meshes in the beta are not showing magic.

Like I said, I don't know the specifics of that "new technology" and if we can use it or not. If we can use it, and since we are going to be touching pretty much every texture in the vc, I think it's a waist of time to do that process twice.

 

[Urwumpe]

Like I said, I don't know the specifics of that "new technology" and if we can use it or not. If we can use it, and since we are going to be touching pretty much every texture in the vc, I think it's a waist of time to do that process twice.

Sure, but we also inflate the risks. Without some kind of automatic quality assurance, I would not recommend trying something like that. Better keep the steps as big as we can test them.

 

[DaveS]

The VC needs updating just to fit the current orbiter mesh. Currently the the aft flight deck doesn't line up properly with the orbiter. These screenshots shows it well.

 

[GLS]

Sure, but we also inflate the risks. Without some kind of automatic quality assurance, I would not recommend trying something like that. Better keep the steps as big as we can test them.

It will have to be done in a branch anyway, as once we start it will not work until all the panels are finished, so I don't think it increases risks of ending up with something that doesn't work.
We don't need to do the back lighting right away, but if that is possible, let's plan for it and leave that door unlocked. As for the variable intensity on the annunciator lights/LEDs, as we need them to work now, (again, if it's possible to do) we could get that intensity control to work when the lights are upgraded.

---------- Post added at 12:48 AM ---------- Previous post was at 12:38 AM ----------

The VC needs updating just to fit the current orbiter mesh. Currently the the aft flight deck doesn't line up properly with the orbiter. These screenshots shows it well.

Yes it needs. I'm just saying that as we need to fix that and other things there, we could save some time in texture editing, mesh editing, code editing, coordinate correction, and do it in one go. I see little point in resizing the vc, updating all the switch coordinates and then sometime later having to rework it all again to separate the panels, or to add lights or something else. :2cents:

 

[DaveS]

So which way should be the path forward? The panel separation isn't compatible with keeping the current VC intact with only minor fixes.

 

[GLS]

So which way should be the path forward? The panel separation isn't compatible with keeping the current VC intact with only minor fixes.

IMO, here is the TODO list:
>> resize vc
>> separate panels (and allow OV-102 cockpit to be simulated)
>> fix some wrong switch types, buttons, covers, positions, etc
>> update remaining talkbacks
>> update lights (and if there's a way to do it, allow variable intensity immediatly or in the future)
>> (if there's a way to do it) prepare panels for future back light work (maybe also with variable intensity)

The last 2 points might require some research (and maybe standalone testing) to be done. I still haven't looked at how that works, or would work, so I can't tell much other than let's try and not have to redo things in a few months.
But if the rest of the project feels like this has to be done ASAP, even at the risk of in the future needing to redo all the textures to have the variable lights and/or back lights, who am I to say no.

---------- Post added 06-13-16 at 02:31 AM ---------- Previous post was 06-12-16 at 01:15 PM ----------

I just committed the CRTMFD change to a SSU specific MFD. There's a bug that I can't fix that causes the CRTMFD name not to show in the menu buttons, although it still shows in the display and the button still works as normal. I'm not creating a ticket yet as I want to check this in the default Atlantis and make sure it isn't an Orbiter issue, because I didn't change anything else except the registration.

Before I start with the sketchpad update I'll do some changes to the way things are saved, that am fairly confident will fix all the issues with saving the display/menu state.

BTW: the VS2013 will need to be updated to deal with the deletion of the CRTMFD project in the OrbitersimBeta branch.

 

[Urwumpe]

Could we maybe resolve the VC2013/2015 duplication issues by porting to CMake? I have started learning it for the C server component at work, it automatically detects the Visual C++ version installed and generates project and solution files for the version, as well as building the files.

Makes a good appearance so far, much better than the native code plugin of gradle, which complains a lot and pretty confusing about external dependencies.

 

[GLS]

Could we maybe resolve the VC2013/2015 duplication issues by porting to CMake? I have started learning it for the C server component at work, it automatically detects the Visual C++ version installed and generates project and solution files for the version, as well as building the files.

Makes a good appearance so far, much better than the native code plugin of gradle, which complains a lot and pretty confusing about external dependencies.

Does it work for vs2010? And does it work without me touching makefiles compbash? :lol: