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

[Urwumpe]

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

well, partially. I am sure I can make the makefiles pretty carefree by defining code conventions, but even if that does not work all the time (like by having a new compilation unit), it isn't that hard to use, the only stuff that is interesting is "What goes in for making that come out".

And finally - it has a minimal GUI for running CMake. :lol:

Not sure if 2010 is among the supported platforms, I remember seeing 2013 as minimum platform. We could still define the compiler flags for 2010 ourselves if it does not work automatically.

 

[GLS]

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.

Seems like this is an Orbiter issue with the new vessel-specific MFDs, so I created a bug report.

 

[DaveS]

Nearly done with the new separate F6 panel. Here's a first screenshot:

---------- Post added at 05:21 PM ---------- Previous post was at 03:19 PM ----------

One question: What should I do once the new F6 panel is done? The reason why I started with F6 is that it should allow for testing of everything (2-position switches, 3-position switches, TBs, PBs, PBIs, rotary switch, MDUs and switch cover) without breaking too much. Once things are stable, then the rest of the VC can follow.

 

[Urwumpe]

Best test would be by switching to a branch, I would say. You can then either remove the old F6 from the VC mesh or we only add the new panels and ignore the old VC mesh completely.

Alternative without using a SVN branch would using "branch by abstraction". We define a class that implements the current VC implementation (including event handling), put the new meshes into a subfolder of the SSU meshes folder ("vc"?) and then create a second class, that uses a common interface with the old VC implementation, but implements only the new F6 panel. Switching between the two versions would then be possible by configuration file.

I would prefer the second version, because it allows switching the VC versions quickly for comparison. Also such an approach allows CI/CD better, should I ever get to create a Windows Jenkins server.

 

[DaveS]

Here's the latest version, featuring the proper lever switch for FLT CNTLR PWR. So this addresses issue#79.

 

[GLS]

I say we branch from the beta branch, remove the current vc mesh and disable all the current panel code. Load the new "base structure" mesh (deal with the different Columbia vc shape here), and then start adding panels one-by-one while adding all the new goodies correct switches/TBs/lights/single screen MDU/etc. Once it's done merge back to the beta branch.
Right now I can't really assist on this as I still have to do the MFD sketchpad update (I feel it's going to hurt :uhh. Currently I'm starting the updates to the scenarios following the fixes to the CRTMFD displays going bonkers and other issues it had. I don't know how long the sketchpad thing will take, but after that I'm go for the vc panel work.
In the meantime, any target for when SSU 4.0 should come out?

---------- Post added at 08:09 PM ---------- Previous post was at 06:13 PM ----------

Just committed the MDU/CRTMFD update that fixes the issues with displays changing on their own. The MDUs should now retain the display even after switching vessels or changing positions really fast in the vc. Right now, only 4 scenarios were updated to the "new system" that uses the never before used "@OBJECT" entry, but the rest will follow... I uploaded now so other people can start testing right away instead of having to wait until I finished the slow process of updating the scenarios.

 

[GLS]

The first finished display using sketchpad. It needs some tuning of the text positions and font, which makes want to get the DEU font done before proceeding with the rest, but I don't think we can load a specific font...

 

[Urwumpe]

The first finished display using sketchpad. It needs some tuning of the text positions and font, which makes want to get the DEU font done before proceeding with the rest, but I don't think we can load a specific font...

Not a custom DEU font. But we could do it maybe with the new features in Sketchpad for drawing the ADI ball - we just create a template mesh for the text with each character being a separate quad with its own texture coordinates in a DEU_font.dds texture...

 

[GLS]

Not a custom DEU font. But we could do it maybe with the new features in Sketchpad for drawing the ADI ball - we just create a template mesh for the text with each character being a separate quad with its own texture coordinates in a DEU_font.dds texture...

Somewhat down the road then.
Running D3D9, the display isn't as good as I hoped... a "0-height" rectangle shows as 2 pixels tall :facepalm:. I have to see if I can can get this looking the same way both in MOGE and D3D9.

 

[DaveS]

Any decision on how we're proceeding with the MDUs? Are we sticking with the current version or are we moving away from the legacy Orbiter MFD interface? This affects how I need to model the MDUs in the new F6 panel.

 

[Urwumpe]

Any decision on how we're proceeding with the MDUs? Are we sticking with the current version or are we moving away from the legacy Orbiter MFD interface? This affects how I need to model the MDUs in the new F6 panel.

Well, the beta got some new features especially for us, so using them makes sense at least politically. Also I am not sure we can fully replace all orbiter functions with ExtMFD and our MDUs.

I would say, we should couple getting rid of the legacy MFD support with adding a minimal Mission Control functionality.

 

[GLS]

With the new Orbiter and the changes I did yesterday, I'm happy with the MFD system. The only thing that IMO needs changing is the menu area. The button texture should go and those lines drawn "manually", to have the precision needed to draw the MDU port stuff in the corner. If we need to merge the menu and display textures/meshes I don't know. With one area it might be easier to draw things, but I don't know how the MFD buttons would work...

 

[DaveS]

What os the resolution of the Sketchpad MDUs? Now that we have the chance, I think that we should go to 512x512 in order to clean up things and make them look less cluttered.

 

[Urwumpe]

What os the resolution of the Sketchpad MDUs? Now that we have the chance, I think that we should go to 512x512 in order to clean up things and make them look less cluttered.

Look what is possible in Orbiter beta already:

 

[DaveS]

Look what is possible in Orbiter beta already:

Does that apply to our implementation though? I can't test it as any time I enter the VC, Orbiter CTDs immediately. Nothing in either the Orbiter log or D3D9Client log. Version is rev 55 of Orbiter 2016 and 23.10 of D3D9Client.

 

[GLS]

To change the resolution we must decide a few things first (like I said a while back in some post). Should we only do one resolution or support 2 or 3? And if we're to support more than one, how is it doing to be done?

 

[Urwumpe]

Does that apply to our implementation though? I can't test it as any time I enter the VC, Orbiter CTDs immediately. Nothing in either the Orbiter log or D3D9Client log. Version is rev 55 of Orbiter 2016 and 23.10 of D3D9Client.

Are you on the beta branch of SSU?

I can't assist you about Orbiter beta issues right now, I am still working on the trunk here for SSU and only use beta for experimenting with new technologies with the Black Dart project right now.

 

[GLS]

Does that apply to our implementation though? I can't test it as any time I enter the VC, Orbiter CTDs immediately. Nothing in either the Orbiter log or D3D9Client log. Version is rev 55 of Orbiter 2016 and 23.10 of D3D9Client.

CTD?! I tried 512 on both MOGE and D3D9 and no CTD here...

 

[DaveS]

CTD?! I tried 512 on both MOGE and D3D9 and no CTD here...

I tried going back 256x256 with no luck. I've rebuilt the latest SSUBeta sources and nothing changed.

 

[GLS]

I tried going back 256x256 with no luck. I've rebuilt the latest SSUBeta sources and nothing changed.

Are you running the versioned scenarios? MOGE and/or D3D9? Release or debug build? Does the revision before the current one work?