Gijs wrote in Fri Mar 13, 2009 3:42 pm:Hi guys,
finally managed to fix the in_mode issue. Turned out this code was incorrect (not returning 0 when the set-mode was not in modes):changed it to:
- Code: Select all
in_mode:func(switch, modes) foreach(var m; modes) {
if (me.get_switch(switch)==m) return 1;
else continue;
print("not in checked mode");
return 0;
},
- Code: Select all
in_mode:func(switch, modes) {
foreach(var m; modes)
if (me.get_switch(switch)==m) return 1;
return 0;
},
@Hyde, I fixed both your issues, before you reported them. We were using track, but below 80kt, we should use heading, because one cannot calculate a track when you're not really moving
@Hooray, altitudes are now shown for the waypoints. The VSD thing is nice, but it's low on my priority list. There's still lots of basic functionality missing that I'd like to have before 3.0. And then there's also the PFD that needs to be done...
Next to the above mentioned fixes I have a couple of new features. I'll push an update later today.
Feature requests/bugs:
- ND framework
- every layer should have a z-index parameter.
- update_on should support non-efis properties (like /autopilot/route-manager/activate).
- Canvas
- setColor should, when applied to a group, set the color of all group members.
- setText/sprintf does not accept the degree symbol (or maybe I've tried the wrong symbol number?)
Cheers,
Gijs
Philosopher wrote:Just a quick response, I don't think osgText actually handles non-ascii, e.g. see this commit by Clément: https://gitorious.org/fg/fgdata/commit/ ... 9df4fb1827Gijs wrote in Fri Mar 13, 2009 3:42 pm:We were using track, but below 80kt, we should use heading, because one cannot calculate a track when you're not really moving
Sounds like we need.... more controllers here! The point of a controller (at least for this specific case), is that it can be a neutral arbitrator and decide which properties we need to use and when. I'm working to see if we can get a better framework here...
- thanks for fixing the in_mode bug, should have probably looked more carefully
- track vs heading: this part is currently all done through "behavior hashes" in the ND code, so straightforward to change actually - the ND code doesn't use MapStructure here (yet), so having more controllers/support for them does not immediately help us, until all used layers are indeed ported an adopted by the ND code.
- I was originally planning on moving those huge hashes to some form of PropertyList-XML file, to allow aircraft developers to easily implement their own NDs, but I'll better wait for this until we have at least half a dozen aircraft using the framework, to see what will be needed design-wise.
- The VSD part, I'm just planning on preparing support for it, i.e. having "sub-displays" (clipped rectangles) as part of the ND, and stuff like that - overall, a "vertical situation display" can be pretty cool, and it's cool and novel features that end up being adopted by aircraft developers more quickly - in its current form, the ND code is also still "competing" with the original (hardcoded) NavDisplay code: http://wiki.flightgear.org/Navigation_display
- I still need to check how many a/c have adopted the hardcoded system - if there are many, as in >=10, I would *consider* writing a parser for the old config format, that returns a canvas-driven NavDisplay instead.
- feature requests NavDisplay: should be a no-brainer once MapStructure is adopted
- update_on() and non-EFIS properties - should be simple, too - instead of having a vector with properties, you would use a hash with keys that determine if it's an EFIS property or a "global" one.
- regarding Canvas feature requests, better post them publicly, i.e. in the Canvas forum - I don't think we've been including TheTom in the ND/MapStructure discussions that's been taking place so far.
PS: Thanks for adding altitude labels to the waypoints!