
Cheers,
Sam.
polly wrote in Tue Apr 17, 2012 1:58 pm:" needs commenting" in the sense that text comments in the .nas code must be preceded with a 'comment' symbol.
I can't find an 'fbw-stable' branch but the changes above seem to have been made to fbw-devel on Saturday causing segfaults in that branch.
The logic behind having the trimmable stabilizer continually resetting to zero is completely beyond me, if the THS is to stay at zero then why have it movable ? In normal flight, if the THS is always hunting to zero, what trims the craft ? I posted the relevant parts from pprune earlier, the story I've picked up from the many threads there dealing with the subject make sense to me.
zakalawe wrote:Oh, and the Bravo now contains a lovely (non-Airbus) example of using the NavDisplay texture to show traffic, the route-path, and nearby data.
zakalawe wrote in Wed Apr 25, 2012 10:16 am:Scott and I are doing a ton of work to extend the core C++ data classes into Nasal, so that the internal view of the world is available to Nasal and can be manipulated.
zakalawe wrote in Wed Apr 25, 2012 10:16 am:omega, can you explain a bit about how the FMGC and CDU are structured internally? Scott and I are doing a ton of work to extend the core C++ data classes into Nasal, so that the internal view of the world is available to Nasal and can be manipulated. Especially things like loading / saving routes, setting speeds and altitudes on waypoints, and assigning procedures / runways during POS-INIT and flight.
I guess you're working on something that is pure Nasal at this point, does it interact with the route-manager at all, or simply ignore it?
Oh, and the Bravo now contains a lovely (non-Airbus) example of using the NavDisplay texture to show traffic, the route-path, and nearby data.
omega95 wrote in Thu Apr 26, 2012 9:17 am:Well, I am using the route manager to hold the active route.... (switches between F-PLN and SEC F-PLN) but then stuff like speed management etc. are done separately. It'd be pretty cool if the route manager lets you input and keep altitudes and speeds separate from the WP id, as whenever I change the altitude-ft prop for a wp and open the route manager, it resets to -9999. Atm, to use the FMGC properly without glitches, I can't open the route manager dialog. To fix these, I'd probably have to create a separate route manager sorta thing with nasal or the current Hard Coded RM could be improved to manage the routes. As for terminal procedures, I DON'T use the route manager. You have an F-PLN Discontinuity where you're using TPs (which you can select from respective LATeral REVision pages on the mCDU) and these wps, alts and speeds are managed separate from the RM.
And for the route manager, another idea would be to be able to choose how many different routes you can have in it. (For eg. here, you have the primary and secondary flight-plans. Atm, the FMGC copies the active flight-plan (managed separately) into the active route where you can edit it and then when you change to the other plan, it saves your changes into the plan.) It'd be better to be able to have the Route Manager to manage all of them instead of using nasal for it, wouldn't it?
Hooray wrote in Wed Apr 25, 2012 4:07 pm:A while aog, I talked to Scott, our idea was to document the required steps and add a write-up to the wiki, so that others may have a look and use this for reference.
Hooray wrote in Wed Apr 25, 2012 4:07 pm:Looking through the Nasal work that you and Scott have done recently, I was planning to add the specifics of exposing objects via Nasal ghosts to the Nasal docs: http://wiki.flightgear.org/Howto:Extending_Nasal
That's something which isn't currently too well documented - apparently, most people aren't really aware of this option, or they don't know how to do this properly. And even Stuart's cloud interface was not implemented as a Nasal extension function (or even a ghost), but as an fgcommand().
The bottom line being, most of your recent work on improving the Nasal interface happened to include a sizable number of useful general purpose helpers, which could easily (and probably should) be used by others.
Hooray wrote in Wed Apr 25, 2012 4:07 pm:Regarding the fgcommands() you are planning to phase out: It's probably worth keeping in mind that those are trivially accessible from XML space (command bindings), but also as telnet commands.
omega95 wrote in Thu Apr 26, 2012 2:15 pm:2. For some reason, after we reach a waypoint, the Route Manager seems to de-activate. I could fix that by making my own route-manager (WP Transitions like the holding pattern on hte 787) but then this problem shouldn't be happening, so I think we should rather try to fix this.
omega95 wrote in Thu Apr 26, 2012 2:15 pm:3. FG SegFaulted THRICE! and I had to restart the flight. It shouldn't have anything to do with nasal, should it?
zakalawe wrote in Thu Apr 26, 2012 4:02 pm:Please don't make your own route-manager. The route-manager deactivates when the last waypoint is reached. Can you point me at the code you have which touches the route-manager? Though the API is going to improve really soon
zakalawe wrote in Thu Apr 26, 2012 4:02 pm:Depends when you last updated from Git - I introduced some crashes some days ago, and then in the last two days there were fixed.
Users browsing this forum: Applebot [Bot], V12, YandexBot [Bot] and 4 guests