From: James T. <zak...@ma...> - 2014-03-05 14:50:47
|
Hello, Over the next few days I'm going to start switching over the reset system to use the new code. The following changes will happen, in order: - places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally. - the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path I'm aware of that triggers a reset its the actual menu command / key-shortcut - I don't believe we ever do one as a side-effect of another UI action. If anyone knows of some strange way we trigger a reset, please do let me know) - the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used - Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but I will try to address issues as quickly as possible. Unfortunately each time I make a fix in preferences.xml, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :) I’m not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. Kind regards, James |
From: Alan T. <ajt...@v-...> - 2014-03-05 20:53:16
|
James As of this evening JSBSim trim fails following an in-air reset. (Windows 64 bit, MSVC2010) Alan From: James Turner Sent: Wednesday, March 05, 2014 2:50 PM To: FlightGear developers discussions Subject: [Flightgear-devel] Reset & reposition Hello, Over the next few days I'm going to start switching over the reset system to use the new code. The following changes will happen, in order: - places that only need to re-position will use the new ‘reposition' command, which is a simplified version of the current reset (and will become even simpler over time, but for now the goal is maximum compatibility). This means the 'select airport' and 'position in air' dialogs, principally. - the reset command will be switched to use the new logic, which is slightly slower than the current logic, but much more complete. It's very close to shutting down the simulator and re-starting; in particular Nasal is restarted, and it should be possible in the near future to toggle between Rembrandt and the classic renderer. (The only UI-path I'm aware of that triggers a reset its the actual menu command / key-shortcut - I don't believe we ever do one as a side-effect of another UI action. If anyone knows of some strange way we trigger a reset, please do let me know) - the "save / restore initial state" logic in globals will be removed, since it will no longer ever be used - Many properties which are flagged as 'preserved' or 'userarchive' need to be audited for correctness in the new system. This will be an iterative process, but I will try to address issues as quickly as possible. Unfortunately each time I make a fix in preferences.xml, testers will need to delete their auto-save file. This is the price of living on the bleeding edge :) I’m not expecting any build failures since the code is already in Git, but I would ask that any bug-reports are only made /after/ wiping your autosave XML file. Kind regards, James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2014-03-05 22:34:38
|
On 5 Mar 2014, at 20:26, Alan Teeder <ajt...@v-...> wrote: > As of this evening JSBSim trim fails following an in-air reset. (Windows 64 bit, MSVC2010) > Do you mean a reset or a re-position? My understanding is that JSBsim hasn’t been able to trim in-air for some time (years), that’s why ‘resume flying’ is disabled for the replay system, for JSBsim aircraft. (It would be good to fix this, but it needs JSBsim expertise) Aditionally the re-position code hasn’t changed significantly - it no longer touches the time of day or some ancillary sub-systems (eg ATIS) but the FDM is still restarted as it always has been since the dawn of time. So, please say which aircraft, the exact steps you followed (UI steps, not just ‘adjusted the position'), what happened yesterday, and what happens now. Note you only need to revert my fg-data commit to get back the old behaviour, or just manually revert the UI path you’re following to use the old ‘presets-commit’ command. Kind regards, James |
From: Alan T. <ajt...@v-...> - 2014-03-05 23:00:30
|
James I am using the menu Location->Position Aircraft in Air-> set Altitude and Airspeed to something sensible. With Tuesday’s git this works. With today’s (Wednesday’s) it does not. The aircraft I have tried are my own WIP (gi...@gi...:fg-ajt/tsr2.git), followed by a check with the Lightning. I have two machines, one updated this afternoon and the other left at Tuesday’s state. When the JSBSim trim fails there is a few lines of print out showing the trim status and then the aircraft is launched. The out of trim is quite severe, with the aircraft rolling inverted and/or diving vertically. but normal flight can be recovered by the use of quite large control movements. >From stand-alone JSBSim work I have found that the trim routine is rather temperamental, and requires a reasonable start point. It does not take kindly to uninitialized variables. Alan From: James Turner Sent: Wednesday, March 05, 2014 10:34 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 5 Mar 2014, at 20:26, Alan Teeder <ajt...@v-...> wrote: As of this evening JSBSim trim fails following an in-air reset. (Windows 64 bit, MSVC2010) Do you mean a reset or a re-position? My understanding is that JSBsim hasn’t been able to trim in-air for some time (years), that’s why ‘resume flying’ is disabled for the replay system, for JSBsim aircraft. (It would be good to fix this, but it needs JSBsim expertise) Aditionally the re-position code hasn’t changed significantly - it no longer touches the time of day or some ancillary sub-systems (eg ATIS) but the FDM is still restarted as it always has been since the dawn of time. So, please say which aircraft, the exact steps you followed (UI steps, not just ‘adjusted the position'), what happened yesterday, and what happens now. Note you only need to revert my fg-data commit to get back the old behaviour, or just manually revert the UI path you’re following to use the old ‘presets-commit’ command. Kind regards, James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2014-03-06 14:39:25
|
On 5 Mar 2014, at 23:00, Alan Teeder <ajt...@v-...> wrote: > When the JSBSim trim fails there is a few lines of print out showing the trim status and then the aircraft is launched. The out of trim is quite severe, with the aircraft rolling inverted and/or diving vertically. but normal flight can be recovered by the use of quite large control movements. > > From stand-alone JSBSim work I have found that the trim routine is rather temperamental, and requires a reasonable start point. It does not take kindly to uninitialized variables. > I’ve been testing this with the C172, and ‘quite severe’ is correct, sometimes the aircraft is pointing straight up or down. The problem goes away when I restore the initial property state - but that’s something I’m trying to avoid since it causes other issues and makes ‘reposition’ more like ‘reset’. When I look at the JSBsim output (log-level=info), for any given test I’ve tried, the actual initialised state is the same (Using the old and new code paths). I.e the same values printed after: Initialized JSBSim with: With the new code, I do see ‘worse’ values for the trimming, eg 600 iterations rather than 4 or 5. (in ‘trim statistics’) And the values printed in: Trim Results: are typically larger by one or two orders of magnitude. If anyone else could confirm the above, especially that the initial state logged is plausible (no excessive bank/pitch angles) even when it ‘fails’, that would be useful In all cases, the JSBSim instance is destroyed and re-created, so I believe the only way information can propagate between the instances is properties, and the fact that restoring the initial properties fixes the issue, suggests there is some state in the property tree upsetting the JSBsim startup (either trimming or the first simulated frame). I’ve attempted to narrow down what state that might be, by only restoring pieces of the property tree, but so far without success. Any hints on things to isolate, from those with JSBsim expertise, would be most welcome. Regards, James |
From: James T. <zak...@ma...> - 2014-03-07 08:48:41
|
On 6 Mar 2014, at 14:38, James Turner <zak...@ma...> wrote: > I’ve been testing this with the C172, and ‘quite severe’ is correct, sometimes the aircraft is pointing straight up or down. > > The problem goes away when I restore the initial property state - but that’s something I’m trying to avoid since it causes other issues and makes ‘reposition’ more like ‘reset’. > I pushed a couple of fixes in this area last night. (One is more of a work-around I shall be chasing on the JSBsim side). Please update to latest FG and let me know if the situation is improved at all! Kind regards, James |
From: Alan T. <ajt...@v-...> - 2014-03-07 10:29:47
|
James My initial test (with the Lightning) was good. Many thanks. PS how do you find the time for so much Flightgear work? From: James Turner Sent: Friday, March 07, 2014 8:48 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 6 Mar 2014, at 14:38, James Turner <zak...@ma...> wrote: I’ve been testing this with the C172, and ‘quite severe’ is correct, sometimes the aircraft is pointing straight up or down. The problem goes away when I restore the initial property state - but that’s something I’m trying to avoid since it causes other issues and makes ‘reposition’ more like ‘reset’. I pushed a couple of fixes in this area last night. (One is more of a work-around I shall be chasing on the JSBsim side). Please update to latest FG and let me know if the situation is improved at all! Kind regards, James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Hyde Y. <hy...@hy...> - 2014-03-07 16:36:53
|
James, I'm using in air reposition repeatedly for tweaking ILS things. The first reposition is quite nice. Every setting is kept and going well. But after landing, next in air reposition is not good since previous FDM setting is remained and ship goes berserk. Can you reset FDM or can I reset at application side? Or simply can you add the parameter which requires reset? Regards, Hyde > > I pushed a couple of fixes in this area last night. (One is more of a > work-around I shall be chasing on the JSBsim side). > > Please update to latest FG and let me know if the situation is > improved at all! > > Kind regards, > James > > |
From: James T. <zak...@ma...> - 2014-03-07 16:55:02
|
On 7 Mar 2014, at 16:19, Hyde Yamakawa <hy...@hy...> wrote: > I'm using in air reposition repeatedly for tweaking ILS things. > The first reposition is quite nice. Every setting is kept and going well. > But after landing, next in air reposition is not good since previous FDM setting is remained and ship goes berserk. > Can you reset FDM or can I reset at application side? > Or simply can you add the parameter which requires reset? Hmm, I don’t know what is happening here: - I guess you’re testing the 777 which uses Yasim? - we do reset the entire FDM every time. The issues is what startup state the FDM reads outside ‘/sim/presets’ - it *should* read nothing but sometimes this is not the case. I guess that, like JSBsim, there are some properties somewhere upsetting Yasim, but it is less sensitive. Can you give me some more precise steps to follow, ideally some *quick* steps since to fix the JsbSim issue I had to reposition about 100 times - I don’t really want to fly 100 approaches, even though it would sure improve my technique. Kind regards, James |
From: Hyde Y. <hy...@hy...> - 2014-03-07 19:49:43
|
James, Yes, 777. I took the recorder tapes when issue happens but can not be attached here. I can send you personally or tracker is better? And here's the steps. You can use any airport with ils but specify RJTT for this time. Before start, please pull the latest 777 which is tweaked for new reset and reposition. All altitude is barometric AGL. 1. Start 777-200ER on RJTT-34L. 2. Set flap to 5. 3. Set Position Aircraft in Air Distance:10, Altitude:2500, Airspeed:190 then press OK. 4. Press APP button and set AB to 2 once in air. 5. When GS capture, set flap 15 and IAS to 128. 6. At 2000ft, gear down, speed brake set arm and flap to 20. 7. At 1800ft, flap to 25. 8. At 1600ft, flap to 30. 9. At touch down, do thrust reverse and wait for ship stops. Repeat from step 2. If issue does not happen do from step2 with another airport such as RJAA-34L. Best regards, Hyde (2014年03月07日 11:54), James Turner wrote: > Hmm, I don’t know what is happening here: > > - I guess you’re testing the 777 which uses Yasim? > > - we do reset the entire FDM every time. The issues is what startup > state the FDM reads outside ‘/sim/presets’ - it *should* read nothing > but sometimes this is not the case. > > I guess that, like JSBsim, there are some properties somewhere > upsetting Yasim, but it is less sensitive. Can you give me some more > precise steps to follow, ideally some *quick* steps since to fix the > JsbSim issue I had to reposition about 100 times - I don’t really want > to fly 100 approaches, even though it would sure improve my technique. > > Kind regards, > James > |
From: Hyde Y. <hy...@hy...> - 2014-03-07 21:54:08
|
James, I find the cause. It's my side. When autopilot disengaged after landing, elevator sticks at the heavy nose down position. That causes initial nose down at next reposition. I have to fix this to return back to neutral position when a/p disengage. Sorry for the noise. Reposition works fine. Regards, Hyde (2014年03月07日 14:49), Hyde Yamakawa wrote: > James, > > Yes, 777. > I took the recorder tapes when issue happens but can not be attached here. > I can send you personally or tracker is better? > > And here's the steps. You can use any airport with ils but specify RJTT > for this time. > Before start, please pull the latest 777 which is tweaked for new reset > and reposition. > All altitude is barometric AGL. > > 1. Start 777-200ER on RJTT-34L. > 2. Set flap to 5. > 3. Set Position Aircraft in Air Distance:10, Altitude:2500, Airspeed:190 > then press OK. > 4. Press APP button and set AB to 2 once in air. > 5. When GS capture, set flap 15 and IAS to 128. > 6. At 2000ft, gear down, speed brake set arm and flap to 20. > 7. At 1800ft, flap to 25. > 8. At 1600ft, flap to 30. > 9. At touch down, do thrust reverse and wait for ship stops. > > Repeat from step 2. > If issue does not happen do from step2 with another airport such as > RJAA-34L. > > Best regards, > Hyde > > > (2014年03月07日 11:54), James Turner wrote: >> Hmm, I don’t know what is happening here: >> >> - I guess you’re testing the 777 which uses Yasim? >> >> - we do reset the entire FDM every time. The issues is what startup >> state the FDM reads outside ‘/sim/presets’ - it *should* read nothing >> but sometimes this is not the case. >> >> I guess that, like JSBsim, there are some properties somewhere >> upsetting Yasim, but it is less sensitive. Can you give me some more >> precise steps to follow, ideally some *quick* steps since to fix the >> JsbSim issue I had to reposition about 100 times - I don’t really want >> to fly 100 approaches, even though it would sure improve my technique. >> >> Kind regards, >> James >> > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and the > freedom to use Git, Perforce or both. Make the move to Perforce. > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ********************************** Hyde Yamakawa 308 Brookewood Dr. Peachtree City, GA 30269 Phone (770)632-6461 Cell (404)353-8758 e-mail: hy...@hy... http://www.hyde-tech.com/ ********************************** |
From: Alan T. <ajt...@v-...> - 2014-03-07 21:33:31
|
James I have now tried my WIP and found that I needed to change the way that I added extra variables in the /fdm/jsbsim/fcs property tree. Previously I did this in Nasal: props.globals.getNode("/fdm/jsbsim/fcs/afcs-left-taileron-cmd-deg", 1).setDoubleValue(0); props.globals.getNode("/fdm/jsbsim/fcs/afcs-right-taileron-cmd-deg", 1).setDoubleValue(0); props.globals.getNode("/fdm/jsbsim/fcs/afcs-rudder-cmd-deg", 1).setDoubleValue(0); props.globals.getNode("/fdm/jsbsim/fcs/afcs-throttle-cmd-norm", 1).setDoubleValue(0); Now I have to do this the start of the aerodynamics section of the JSBSim Xml file <aerodynamics> <property>fcs/afcs-left-taileron-cmd-deg</property> <property>fcs/afcs-right-taileron-cmd-deg</property> <property>fcs/afcs-rudder-cmd-deg</property> <property>fcs/afcs-throttle-cmd-norm</property> <axis name="LIFT"> I also set the initial values (all zero in this case) when I re-initialise my autopilot after an in-air reset. It is likely that other aircraft that use user added properties within /fdm/jsbsim/fcs/ tree will need similar changes. Other than that all seems to work as before. Alan From: James Turner Sent: Friday, March 07, 2014 8:48 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 6 Mar 2014, at 14:38, James Turner <zak...@ma...> wrote: I’ve been testing this with the C172, and ‘quite severe’ is correct, sometimes the aircraft is pointing straight up or down. The problem goes away when I restore the initial property state - but that’s something I’m trying to avoid since it causes other issues and makes ‘reposition’ more like ‘reset’. I pushed a couple of fixes in this area last night. (One is more of a work-around I shall be chasing on the JSBsim side). Please update to latest FG and let me know if the situation is improved at all! Kind regards, James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2014-03-08 10:19:28
|
On 7 Mar 2014, at 21:33, Alan Teeder <ajt...@v-...> wrote: > I have now tried my WIP and found that I needed to change the way that I added extra variables in the /fdm/jsbsim/fcs property tree. Previously I did this in Nasal: > props.globals.getNode("/fdm/jsbsim/fcs/afcs-left-taileron-cmd-deg", 1).setDoubleValue(0); > props.globals.getNode("/fdm/jsbsim/fcs/afcs-right-taileron-cmd-deg", 1).setDoubleValue(0); > props.globals.getNode("/fdm/jsbsim/fcs/afcs-rudder-cmd-deg", 1).setDoubleValue(0); > props.globals.getNode("/fdm/jsbsim/fcs/afcs-throttle-cmd-norm", 1).setDoubleValue(0); > > Now I have to do this the start of the aerodynamics section of the JSBSim Xml file > > <aerodynamics> > > <property>fcs/afcs-left-taileron-cmd-deg</property> > <property>fcs/afcs-right-taileron-cmd-deg</property> > <property>fcs/afcs-rudder-cmd-deg</property> > <property>fcs/afcs-throttle-cmd-norm</property> > > <axis name="LIFT"> > > I also set the initial values (all zero in this case) when I re-initialise my autopilot after an in-air reset. > > It is likely that other aircraft that use user added properties within /fdm/jsbsim/fcs/ tree will need similar changes. > Okay, this is unfortunate - it was not my intention to require any aircraft changes. The problem is, there is some state persisting in /fdm which is causing the upsets on re-position. My current solution is to wipe the entire /fdm tree on reposition, so JSBsim starts with clean values. Of course I didn’t realise aircraft developers were prep-ing values inside this area. (Any idea how wide-spread this practice is?) I think the better solution would be to find exactly which /fdmjsbsim properties are causing the upsets, but that will be a much longer process. (BTW, can’t you initialise such properties from your JSBSim config file, instead of using Nasal? Then they would be created with their default values when the FDM starts, which would ‘just work’ on re-position. But, as I said, I was hoping not to require any aircraft changes) Kind regards, James |
From: James T. <zak...@ma...> - 2014-03-08 10:23:30
|
On 8 Mar 2014, at 10:19, James Turner <zak...@ma...> wrote: > (BTW, can’t you initialise such properties from your JSBSim config file, instead of using Nasal? Then they would be created with their default values when the FDM starts, which would ‘just work’ on re-position. But, as I said, I was hoping not to require any aircraft changes) > Eugh, it’s too early in the morning - that is exactly what you ARE doing in your fix. Sorry. James |
From: grtuxhangar t. <hoh...@gm...> - 2014-03-08 14:53:20
|
Hello, James Not sure about the issue but reset prohibit the GUI dialog display here the message on console we are getting: loadxml: reading '/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft/Alouette-III/Inputs/propulsion-control.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have <name> at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 334 called from: /wrklvdevel/FG-GIT/fgdataNasal/gui.nas, line 314 called from: /wrklvdevel/FG-GIT/fgdata/Nasal/globals.nas, line 110 Nasal runtime error: container index not scalar at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 316 called from: /sim/bindings/menu/binding[89], line 3 the denied (unauthorized access) can't be explained, since before reset , we can load and use the dialog box . the path are --fg-root=/wrklvdevel/FG-GIT/fgdata --fg-aircraft=/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft:/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft_FG and path Alouette-III_sc is at /wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft Ahmad On 8 March 2014 11:23, James Turner <zak...@ma...> wrote: > > On 8 Mar 2014, at 10:19, James Turner <zak...@ma...> wrote: > > (BTW, can't you initialise such properties from your JSBSim config file, > instead of using Nasal? Then they would be created with their default > values when the FDM starts, which would 'just work' on re-position. But, as > I said, I was hoping not to require any aircraft changes) > > > Eugh, it's too early in the morning - that is exactly what you ARE doing > in your fix. Sorry. > > James > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: James T. <zak...@ma...> - 2014-03-08 15:44:08
|
On 8 Mar 2014, at 14:53, grtuxhangar team <hoh...@gm...> wrote: > Not sure about the issue but reset prohibit the GUI dialog display > here the message on console we are getting: > > loadxml: reading '/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft/Alouette-III/Inputs/propulsion-control.xml' denied (unauthorized access) > Nasal runtime error: Dialog class: XML dialog must have <name> > at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 334 > called from: /wrklvdevel/FG-GIT/fgdataNasal/gui.nas, line 314 > called from: /wrklvdevel/FG-GIT/fgdata/Nasal/globals.nas, line 110 > Nasal runtime error: container index not scalar > at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 316 > called from: /sim/bindings/menu/binding[89], line 3 > > > the denied (unauthorized access) can't be explained, since before reset , we can load and use the dialog box . > > the path are > --fg-root=/wrklvdevel/FG-GIT/fgdata > --fg-aircraft=/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft:/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft_FG > > and path Alouette-III_sc is at /wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft > Ah, that’s interesting, it looks like Nasal IO security isn’t being reset correctly. (But must be partly working, or Canvas wouldn’t load) I can surely fix this, maybe takes a day or two. Can I reproduce with the Alouette-IIIin fgdata? Kind regards, James |
From: grtuxhangar t. <hoh...@gm...> - 2014-03-08 15:59:55
|
> > I can surely fix this, maybe takes a day or two. Can I reproduce with the > Alouette-IIIin fgdata? > No, since dedicated to FG 3.00 But you can give it a try with our FG devel version Alouette-III <https://gitorious.org/eekpo/devel__alouette-iii/source/faf44921910fc1023ab003463ff3e986f774cccb:> Ahmad On 8 March 2014 16:43, James Turner <zak...@ma...> wrote: > > On 8 Mar 2014, at 14:53, grtuxhangar team <hoh...@gm...> wrote: > > Not sure about the issue but reset prohibit the GUI dialog display > here the message on console we are getting: > > loadxml: reading > '/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft/Alouette-III/Inputs/propulsion-control.xml' > denied (unauthorized access) > Nasal runtime error: Dialog class: XML dialog must have <name> > at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 334 > called from: /wrklvdevel/FG-GIT/fgdataNasal/gui.nas, line 314 > called from: /wrklvdevel/FG-GIT/fgdata/Nasal/globals.nas, line 110 > Nasal runtime error: container index not scalar > at /wrklvdevel/FG-GIT/fgdata/Nasal/gui.nas, line 316 > called from: /sim/bindings/menu/binding[89], line 3 > > > the denied (unauthorized access) can't be explained, since before reset > , we can load and use the dialog box . > > the path are > --fg-root=/wrklvdevel/FG-GIT/fgdata > > --fg-aircraft=/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft:/wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft_FG > > and path Alouette-III_sc is at > /wrklvm/FlightGear/FlightGear_Git/data-aircraft/Aircraft > > > Ah, that's interesting, it looks like Nasal IO security isn't being reset > correctly. (But must be partly working, or Canvas wouldn't load) > > I can surely fix this, maybe takes a day or two. Can I reproduce with the > Alouette-IIIin fgdata? > > Kind regards, > James > > > > ------------------------------------------------------------------------------ > Subversion Kills Productivity. Get off Subversion & Make the Move to > Perforce. > With Perforce, you get hassle-free workflows. Merge that actually works. > Faster operations. Version large binaries. Built-in WAN optimization and > the > freedom to use Git, Perforce or both. Make the move to Perforce. > > http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk > _______________________________________________ > Flightgear-devel mailing list > Fli...@li... > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > > |
From: Thomas G. <to...@gm...> - 2014-03-09 22:25:26
|
Am 2014-03-08 16:43, schrieb James Turner: > Ah, that’s interesting, it looks like Nasal IO security isn’t being > reset correctly. (But must be partly working, or Canvas wouldn’t load) I got the same problem. The cause is that after a reset the fg-aircraft and fg-scenery nodes are not recreated. A simple fix would be to just set the preserve flag on these nodes. What are your plans regarding the PRESERVE flag? You somewhere mentioned that you want to get rid of the save/restore initial state logic. Does that include the PRESERVE flag? Regards, Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org ------------------------------------------------------------------------ Student of Computer Science @ Graz University of Technology ------------------------------- Austria -------------------------------- |
From: Alan T. <ajt...@v-...> - 2014-03-08 22:49:30
|
James My autopilot is dead after an in-air reset. I have cured this by adding fgcommand('reinit', props.Node.new({ subsystem: "xml-autopilot" })); to my nasal reinitialise routine. Re-loading the autopilot manually from the debug menu also works. Alan From: James Turner Sent: Saturday, March 08, 2014 10:23 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 8 Mar 2014, at 10:19, James Turner <zak...@ma...> wrote: (BTW, can’t you initialise such properties from your JSBSim config file, instead of using Nasal? Then they would be created with their default values when the FDM starts, which would ‘just work’ on re-position. But, as I said, I was hoping not to require any aircraft changes) Eugh, it’s too early in the morning - that is exactly what you ARE doing in your fix. Sorry. James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Alan T. <ajt...@v-...> - 2014-03-08 23:04:44
|
P.S. The autopilot was not totally dead, all the autopilot internals and my flight director were still running. However the output was not being passed to my taileron JSBSIM flight controls using the the linkage in my previous post. It may well be OK for the more commonly used configuration where elevator and aileron trim inputs (bound properties ?) are used as the autopilot interface, but I have not tested this. Alan From: Alan Teeder Sent: Saturday, March 08, 2014 10:49 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition James My autopilot is dead after an in-air reset. I have cured this by adding fgcommand('reinit', props.Node.new({ subsystem: "xml-autopilot" })); to my nasal reinitialise routine. Re-loading the autopilot manually from the debug menu also works. Alan From: James Turner Sent: Saturday, March 08, 2014 10:23 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 8 Mar 2014, at 10:19, James Turner <zak...@ma...> wrote: (BTW, can’t you initialise such properties from your JSBSim config file, instead of using Nasal? Then they would be created with their default values when the FDM starts, which would ‘just work’ on re-position. But, as I said, I was hoping not to require any aircraft changes) Eugh, it’s too early in the morning - that is exactly what you ARE doing in your fix. Sorry. James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: Alan T. <ajt...@v-...> - 2014-03-08 23:23:05
|
PPS I should have written “tied properties” instead of “bound properties”. Alan – who made much too much wine last year hic. From: Alan Teeder Sent: Saturday, March 08, 2014 11:04 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition P.S. The autopilot was not totally dead, all the autopilot internals and my flight director were still running. However the output was not being passed to my taileron JSBSIM flight controls using the the linkage in my previous post. It may well be OK for the more commonly used configuration where elevator and aileron trim inputs (bound properties ?) are used as the autopilot interface, but I have not tested this. Alan From: Alan Teeder Sent: Saturday, March 08, 2014 10:49 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition James My autopilot is dead after an in-air reset. I have cured this by adding fgcommand('reinit', props.Node.new({ subsystem: "xml-autopilot" })); to my nasal reinitialise routine. Re-loading the autopilot manually from the debug menu also works. Alan From: James Turner Sent: Saturday, March 08, 2014 10:23 AM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Reset & reposition On 8 Mar 2014, at 10:19, James Turner <zak...@ma...> wrote: (BTW, can’t you initialise such properties from your JSBSim config file, instead of using Nasal? Then they would be created with their default values when the FDM starts, which would ‘just work’ on re-position. But, as I said, I was hoping not to require any aircraft changes) Eugh, it’s too early in the morning - that is exactly what you ARE doing in your fix. Sorry. James -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel -------------------------------------------------------------------------------- ------------------------------------------------------------------------------ Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce. With Perforce, you get hassle-free workflows. Merge that actually works. Faster operations. Version large binaries. Built-in WAN optimization and the freedom to use Git, Perforce or both. Make the move to Perforce. http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk -------------------------------------------------------------------------------- _______________________________________________ Flightgear-devel mailing list Fli...@li... https://lists.sourceforge.net/lists/listinfo/flightgear-devel |
From: James T. <zak...@ma...> - 2014-03-09 10:12:20
|
On 8 Mar 2014, at 22:49, Alan Teeder <ajt...@v-...> wrote: > My autopilot is dead after an in-air reset. > > I have cured this by adding > fgcommand('reinit', props.Node.new({ subsystem: "xml-autopilot" })); > to my nasal reinitialise routine. Hmm, that’s probably related to wiping /fdm as well. I can do this manually from C++, but I am getting the feeling I need to abandon the idea of wiping /fdm, and instead find a more subtle way to avoid JSBsim going crazy. I would avoid making a slew of tweaks to your aircraft unless you are in a hurry - since I hope once the dust settles they won’t be necessary. (Of of course, you can revert them) Kind regards, James |
From: Erik H. <er...@eh...> - 2014-03-09 10:33:46
|
On 03/09/2014 11:11 AM, James Turner wrote: > Hmm, that’s probably related to wiping /fdm as well. > > I can do this manually from C++, but I am getting the feeling I need to > abandon the idea of wiping /fdm, and instead find a more subtle way to > avoid JSBsim going crazy. > > I would avoid making a slew of tweaks to your aircraft unless you are in > a hurry - since I hope once the dust settles they won’t be necessary. > (Of of course, you can revert them) I'm starting to wonder if this isn't a case of skewed data where the FDM ::update function is getting called while the ::init function is working. Is the FDM update function in a thread or called by a timer now? Erik |
From: James T. <zak...@ma...> - 2014-03-09 11:04:09
|
On 9 Mar 2014, at 10:33, Erik Hofman <er...@eh...> wrote: > On 03/09/2014 11:11 AM, James Turner wrote: >> Hmm, that’s probably related to wiping /fdm as well. >> >> I can do this manually from C++, but I am getting the feeling I need to >> abandon the idea of wiping /fdm, and instead find a more subtle way to >> avoid JSBsim going crazy. >> >> I would avoid making a slew of tweaks to your aircraft unless you are in >> a hurry - since I hope once the dust settles they won’t be necessary. >> (Of of course, you can revert them) > > I'm starting to wonder if this isn't a case of skewed data where the FDM > ::update function is getting called while the ::init function is working. > > Is the FDM update function in a thread or called by a timer now? No, the FDM is being entirely shutdown and re-created in this process. (And waiting for a scenery load if required). The problems stem from the fact, I am no longer restoring the whole property tree state - because I am trying to avoid that for a long list of other reasons. We do re-init ‘systems’ and ‘instruments’ (and always have), so re-init-ing the AP rules is reasonable to be fair, but actually the ‘old’ reinit never did that - so previously the XML AP would see the initial values appears suddenly. I am surprised this didn’t cause other issues, but I guess leaving the AP engaged during re-position is risky anyway :) (And the init values are probably mostly zeros..) Another option is, I ditch the *global* property state restore, but accept that the state in /fdm is considered startup state by the FDM, and so save+restore that inside our FDM-wrapper code. That is low-risk and low-effort, so I will try that tonight. Kind regards, James |
From: James T. <zak...@ma...> - 2014-03-09 22:33:52
|
On 9 Mar 2014, at 22:25, Thomas Geymayer <to...@gm...> wrote: > I got the same problem. The cause is that after a reset the fg-aircraft > and fg-scenery nodes are not recreated. A simple fix would be to just > set the preserve flag on these nodes. What are your plans regarding the > PRESERVE flag? You somewhere mentioned that you want to get rid of the > save/restore initial state logic. Does that include the PRESERVE flag? PRESERVED properties are restored after reset. So your proposed fix is likely correct, however I have a plan to make fg-scenery modifiable via reset, so we can adjust scenery paths, perform a reset (and hence, reload scenery) and see changes without restarting the sim. In which case, we want to move the ‘set fg-scenery paths into the property tree' logic to also run on the ‘reset path’, which is likely a trivial change. (This is a good example of the kind of improved feature that is possible thanks to the new reset architecture!) The save/restore initial state logic will die soon (likely tomorrow), PRESERVED properties are the correct way to make state survive a reset, but essentially all existing ones need to be audited for correctness in the new scheme. There’s also the question of whether USERARCHIVE and PRESERVED are in fact the same thing in the new reset-model. Since USERARCHIVE is how we make properties survive sim shutdown + restart, and PRESERVED is how we make properties survive RESET. It feels like these two definitions are almost identical, but I haven’t decided yet if they are truly the same. Kind regards, James |