I noticed a few problems with the CDU, which seems like it could be a promising cockpit UI for the Route Manager.
instrumentation/cdu/serviceable is false.lightmap effect, and I have been unable to make the keys light up regardless of graphics settings.I have changed the Nasal file to support editing the whole route, added the blanking of input line to Nasal, also converted the main loop to using maketimer() instead of settimer() and fixed the formatting of flap retract height on the takeoff ref screen.
The 3D model now uses model-combined-deferred effect. I had to move the backlight calculation to the Nasal because the modern lightmap effect only supports one property per lightmap, and I have added the missing hotspots. Additionally I have improved the shading by switching to smooth shading and splitting the sharp edges.
Diff:
Diff:
Diff:
Here is the new patch that enables the editing of the whole route.
Also leg distances in "RTE1 LEGS" seem to be moved down by one place. I will try to fix tomorrow.
Actually, done, also fixed wrong indices for the speed on RTE1 LEGS.
Hmm, you might want to check if anything is different on my 737 branch, since that's where I have done most of the CDU work. Especially, all the pages are loaded dynamically, so they can be different for each aircraft.
Is it a branch of fgdata or of the aircraft?
The pages are in the aircraft, but the core CDU changes are all pushed to FGData, I think - will check. Note this is the version in cdu2
Wouldn't it be worth at least maintaining the old one, which is used in a number of aircraft (even though it doesn't work particularly well)? As far as I know, the new one is only, for now, used in the 737-800, and only in the forked version!
Thanks, James, I will try to make as many parts of the interface that I have changed more similar to cdu2 as I can.
Indeed, legoboyvdlp, I think it would make sense to maintain the simplified CDU that directly drives Route Manager, so that the aircraft which have no proper FMC developed yet can have a placeholder and avoid having to use the dialog. Maybe we can disable performance and weight pages until the aircraft developer populates them with the aircraft's data and explicitly enables, instead of relying on internal properties of FDM etc?
Would it be ok if I also fix the shading of the cdu2 3d model and make the brightness knob on both a bit taller?
I migth be confused what new and old mean here. The one in cdu/ is not touched by me, and I don't know which aircraft use it. The one in cdu2/ is my code (but also modified by Gijs), and what's in FGData on next is approximately what is used by the current (fairly advanced) 737NG CDU on my fork.
Seperately it would be good to merge my 737-800 changes back but I don't know if that is actually possible. But that would also mean we had an example of how the CDU Nasal is supposed to integrate between the aircraft and the core files.
I think by "new" Lego meant cdu2.
So far I've only been able to make the backlight work the same as cdu2, it seems that their interfaces are too different, and reconciling them would need a more changes to the old than I was prepared to make. And the more I edit the code the more I see that it would need a major overhaul to approach any realism -- I should probably try to make generic pages for cdu2 instead of trying to expand cdu.
But at least it's mostly bug-free now. ^^
Last edit: Anonymous 2021-08-26
@legoboyvdlp okay, now i understand it's the old one :) So, I don't know which aircraft use it, but I think we can apply this to FGData/next and see how it goes? If everyone agrres, then Michael please go ahead with that.