Re: [Flightgear-devel] New problem with submodels
On Wednesday 19 March 2008 11:05, Vivian Meazza wrote: Lee wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LeeE Sent: 13 March 2008 14:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New problem with submodels On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...] In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. I just went to try this and found that I'm already supplying --enable-ai-models on the command line:( Sorry - I should have checked there as well. I just use bash history to call up my FG start command and thought I only had stuff that I change regularly included in it. OK - I've found the bug - the submodels are aligning to a non-existent external force, because I failed to initialise the value, trivial to fix. That's the good news. The bad news is that this fix has got mixed up here with Till Busch's excellent scenery etc. paging patch (which I recommended highly, and for which more testers are needed), and which is mixed up with an extensive improvement to the air-to-ground radar. I hope you can bear with us until we get it all sorted. Meanwhile, the terrain warning stuff has finally reached cvs-head. While I was about it, I added a more realistic rad alt (the terrain warning radar tilted through 90 degrees). An example of the use of these are to be found in the Buccaneer. I hope that you can make some use of this lot. Hang on - it will get better. Vivian P.S. it all works here - I thought you would like to know that :-) Many thanks for looking into it and even more for finding the cause:) NP re waiting for it to be fixed - the trajectory markers aren't essential - just useful. Re the ground radar/terain warning stuff: I noticed it going through on cvs-logs - is this a development of the ai ballistic sub-model based solution? I've been busy with the YF-23 update (and a hypothetical drone version) so I haven't had a chance to look into and play with it yet. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New problem with submodels
Lee wrote Sent: 19 March 2008 11:43 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New problem with submodels On Wednesday 19 March 2008 11:05, Vivian Meazza wrote: Lee wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of LeeE Sent: 13 March 2008 14:06 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New problem with submodels On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...] In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. I just went to try this and found that I'm already supplying --enable-ai-models on the command line:( Sorry - I should have checked there as well. I just use bash history to call up my FG start command and thought I only had stuff that I change regularly included in it. OK - I've found the bug - the submodels are aligning to a non-existent external force, because I failed to initialise the value, trivial to fix. That's the good news. The bad news is that this fix has got mixed up here with Till Busch's excellent scenery etc. paging patch (which I recommended highly, and for which more testers are needed), and which is mixed up with an extensive improvement to the air-to-ground radar. I hope you can bear with us until we get it all sorted. Meanwhile, the terrain warning stuff has finally reached cvs-head. While I was about it, I added a more realistic rad alt (the terrain warning radar tilted through 90 degrees). An example of the use of these are to be found in the Buccaneer. I hope that you can make some use of this lot. Hang on - it will get better. Vivian P.S. it all works here - I thought you would like to know that :-) Many thanks for looking into it and even more for finding the cause:) NP re waiting for it to be fixed - the trajectory markers aren't essential - just useful. Re the ground radar/terain warning stuff: I noticed it going through on cvs-logs - is this a development of the ai ballistic sub-model based solution? I've been busy with the YF-23 update (and a hypothetical drone version) so I haven't had a chance to look into and play with it yet. No - this is an extension of the weather radar. I've based in pretty closely on the Blue Parrot radar in the Bucc, but all the parameters are settable. The 'radar' has a simulated beam width, scan period, and is stabilised in roll (like the real one). There are a couple of compromises - the horizon is the visual, not radar horizon, and only terrain is detected, not models on the terrain. This latter is due to problems with the node masks, which we are trying to fix, the former - I'm thinking about :-). The rad alt also simulates the one in the Bucc - it too has a beam width, and is fixed in pitch, roll, and heading. Thus errors are introduced if the ac is rolled too far. Otherwise it shares the same problems as the Terrain Warning radar (as I said - it's just the terrain warning radar turned though 90 degrees). Provided you don't go mad with beam width and scan rates this is all pretty
Re: [Flightgear-devel] New problem with submodels
Lee, Sent: 13 March 2008 01:58 On Wednesday 12 March 2008 08:26, Vivian Meazza wrote: LeeE wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 11 March 2008 23:19 To: FlightGear developers discussions Subject: [Flightgear-devel] New problem with submodels Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New problem with submodels
On Thursday 13 March 2008 08:12, Vivian Meazza wrote: [snip...] In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE You need --enable-ai-models. Without this you will see AIBallistic stuff, but they won't move correctly. I think there _is_ bug, but not quite the one you describe. If you could just try again with the correct settings, and let me know what you observe. V. I just went to try this and found that I'm already supplying --enable-ai-models on the command line:( Sorry - I should have checked there as well. I just use bash history to call up my FG start command and thought I only had stuff that I change regularly included in it. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New problem with submodels
LeeE wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 11 March 2008 23:19 To: FlightGear developers discussions Subject: [Flightgear-devel] New problem with submodels Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New problem with submodels
On Wednesday 12 March 2008 08:26, Vivian Meazza wrote: LeeE wrote -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sent: 11 March 2008 23:19 To: FlightGear developers discussions Subject: [Flightgear-devel] New problem with submodels Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? In theory nothing has been changed in submodels in a long time, and aero-stabilised remains a bool. However I have been making changes in AIBallistic, so the problem probably lies there, and I'm investigating. I can sort of reproduce your bug, but here all the submodels behave in the same way. If they don't then it is possible that you haven't enabled AI Models. Vivian Hmm... I have --prop:sim/ai-traffic/enabled=true --prop:sim/ai-traffic/level=3 and --disable-random-objects in my .fgfsrc but they are the only AI related things I specifically set, and disabling the random objects is probably irrelevant here. Actually, I haven't updated from FG cvs since mid February, so this problem dates from before then. I'm also pretty sure the problem wasn't apparent around early/mid December 2008 because I remember using trajectory markers while I was working on the TFA stuff for the BAC-TSR2 and I sent the resulting update to Curt on 2008-12-17. After some more testing last night, I have to revise the ratio of affected instances to ones that show the problem - far more instances _are_ affected than work correctly. I'd now guess that somewhere around nine out of ten instances are showing this strange behaviour, but there still doesn't appear to be a discernible pattern. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New problem with submodels
Hi, For a long time now I've been using ballistic submodels for trajectory markers. When using the trajectory markers, a simple inverted 'T' two line object is created at the aircraft position once per second, aligned with the aircraft roll and pitch axis. The submodels have no weight, 0 buoyancy and are unaffected by wind, so once created they remain in place and provide a representation of the aircraft's flight trajectory. I just tried using them, having not used them for a while, and found that about half of the submodel instances are rolling over and spinning around. The problem seems to be random and about 50-50, with no obvious pattern between instances that behave properly and those that rotate and spin. As they're all created from the same config I'm at a bit of a loss as to how to fix it. I noticed that the README.submodels doc doesn't include a definition for the aero-stabilised tag but it is used in one of the examples. I've always used this tag as a bool i.e. 'true/false', like the wind tag, but in the examples the aero-stablised value is '0' whereas the wind tag values are either 'true' or 'false'. Is '0' used in aero-stabilised to represent a bool or is it now a numeric value? LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
