Re: [Flightgear-devel] releases +- bugs
On 12/01/2009 11:38 AM, John Denker wrote: > On 12/01/2009 11:19 AM, Heiko Schulz wrote: > > >> To your note: So the c172p has now: >> > -struts animation > > The reported bug >http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-x1768 > concerns the nutcracker, which as of 1 Dec 2009 looks quite > weird because it doesn't fold; it just gets shoved rigidly > up into the cowling. > > > > I just submitted a patch that animates the c172p nose gear "nutcracker" so it folds as the strut is compressed. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] bug with taxiway signs
I have spotted one more problem with the signs, namely the backsides change color from gray to black depending on distance or FoV. Here two screenshots for reference: http://imagebin.ca/view/LyWfNs3D.html vs. http://imagebin.ca/view/tpoBEKd.html Anybody else seeing this? -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [GIT] misc fixes
Hi all, I have two minor fixes to offer: 1) fix the airport sign problem and add a little robustness: http://gitorious.org/~jester/fg/jesters-sg-clone/commit/34f1d5cda72e754e8f992e06c3f1ba66ffee9ab3 Thanks to Jacob for reporting. 2) fix a crash in SGSoundMgr::stop() due to invalid iterator usage: http://gitorious.org/~jester/fg/jesters-sg-clone/commit/12604fb231631252b13af1338020926e2ca1a605 Thanks to Vivian for reporting. Note: I still have segfault at exit due to at least two apparent problems: a) SGPropertyNode::untie() trying to copy back values from already deleted strings b) invalid reads during destruction of the layer_states variable in cloud.cxx -- Cheers, Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Instruments-3d/zkv500 MainScreens.nas, 1.7, 1.8 TaskScreens.nas, 1.3, 1.4 TurnpointScreens.nas, 1.5, 1.6
Hi James, I'm sure this is not a problem with the gps code but only with the zkv500 code, because it manages itself the route (it has its own route manager), so the gps code just can't use "leg" as it doesn't know the entry point of the leg. I'm working on it, transferring the route management to the gps code. I hope to get a full working zkv500 gps in the next week. I've got an suggestion for the gps code: a command "nearest-coord" (or better name) which would give nearest navaid for arbitrary coordinates, given by scratch/longitude-deg and scratch/latitude-deg. It will allow to implement a simple navaid-to-navaid flight-plan in a FG session. I tried already months ago, but I can't get it to work properly. best regards seb ps: thanks to Alexis to have committed this patch. James Turner a écrit : > On 8 Dec 2009, at 20:18, Alexis Bory wrote: > >> - Sebastien Marque: Turnpoint is managed using "OBS mode", the route is >> still managed by zkv500's Nasal, only "obs" mode is available >> (seehttp://wiki.flightgear.org/index.php/GPS_internals). It should be "leg >> mode" but I can't get it to work as I expect to. > > Sebastien: You could try asking me, instead of working around problems that I > can (and will!) fix. > > James > > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel > -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/Instruments-3d/zkv500 MainScreens.nas, 1.7, 1.8 TaskScreens.nas, 1.3, 1.4 TurnpointScreens.nas, 1.5, 1.6
On 8 Dec 2009, at 20:18, Alexis Bory wrote: > - Sebastien Marque: Turnpoint is managed using "OBS mode", the route is still > managed by zkv500's Nasal, only "obs" mode is available > (seehttp://wiki.flightgear.org/index.php/GPS_internals). It should be "leg > mode" but I can't get it to work as I expect to. Sebastien: You could try asking me, instead of working around problems that I can (and will!) fix. James -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Alan Teeder wrote: > Eric > This may be of some use. > > I am getting the debug message:- > > "HEAP[fgfs.exe]: Invalid Address specified to RtlValidateHeap( 02F4, > 2EEE0028 ) > Windows has triggered a breakpoint in fgfs.exe." > > _data which free_data is working on is > 2EEE0048."~yslcYOF>:74457http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Eric This may be of some use. I am getting the debug message:- "HEAP[fgfs.exe]: Invalid Address specified to RtlValidateHeap( 02F4, 2EEE0028 ) Windows has triggered a breakpoint in fgfs.exe." _data which free_data is working on is 2EEE0048."~yslcYOF>:74457 Sent: Tuesday, December 08, 2009 1:12 PM To: "FlightGear developers discussions" Subject: Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx > Alan Teeder wrote: > >> I suppose the good news is that I am able to duplicate the fault on the >> XP >> machine (which normally runs without fault) simply by using debug >> runtime.. > > I'm not sure that's good news.. > Are both systems the same (64-bit or 32-bit)? > > Erik > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Alan Teeder wrote: > Eric > > Yes, both are 32 bit with identical Visual C++ 2008 (VC09) and Flightgear > library setups. OpenALand Alut are from the Creative site. The Vista laptop > is Intel dual core, the XP box is an ancient Athlon. Ok at least that excludes the possibility of a buffer overflow due to 64-bits. Erik -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] bug with taxiway signs
On Tue, Dec 8, 2009 at 12:55 PM, Jacob Burbach wrote: > > For example, excuse the crude ascii drawings if you will ;) > > Taxiing up Bravo towards Alpha and Juliet (KLVK) with 1.9.1 you will > see these signs...correct. > | <-- A[B] | > [ <-- J[B] | > > But in cvs letters for Alpha and Bravo will be missing, and you will > see these signsnot so correct. > | <--[B] | > | <--[B] | > > > This effects all signs, at all airports I tried, release or terrasync scenery Thanks for the detailed report. Short answer: Torsten has broken it in rev 1.23 of apt_signs.cxx :) Longer answer: we need to keep the previous material and reuse it for subsequent glyphs that don't specify a new material. Thus, the material/effects variables should be put back at the top, but initialized to 0. -- Csaba/Jester -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Eric Yes, both are 32 bit with identical Visual C++ 2008 (VC09) and Flightgear library setups. OpenALand Alut are from the Creative site. The Vista laptop is Intel dual core, the XP box is an ancient Athlon. By good news I mean that in Debug mode it is not a fault that exists only on my Vista laptop and therefore should be possible to replicate on any other XP/Vista box. Debugging is slow at the moment as there are currently over 5 lines of "First-chance exception at 0x7c812afb in fgfs.exe: Microsoft C++ exception: FP_Inactive at memory location 0x0012f682.." to process before this routine is called. Alan -- From: "Erik Hofman" Sent: Tuesday, December 08, 2009 1:12 PM To: "FlightGear developers discussions" Subject: Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx > Alan Teeder wrote: > >> I suppose the good news is that I am able to duplicate the fault on the >> XP >> machine (which normally runs without fault) simply by using debug >> runtime.. > > I'm not sure that's good news.. > Are both systems the same (64-bit or 32-bit)? > > Erik > > -- > Return on Information: > Google Enterprise Search pays you back > Get the facts. > http://p.sf.net/sfu/google-dev2dev > ___ > Flightgear-devel mailing list > Flightgear-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adjusting the Adjust View Distance
Switch to mouse look view, push the middle mouse button and drag to adjust view left, right, up, and down. Press control + middle mouse button and drag to adjust view forwards and backwards. I find that's much easier for fine adjustments. Once your done adjusting you can find the current view settings in "/sim/current-view", which you can then transplant to the aircrafts set file to make permanent. The large range in the adjust view dialog is useful for big changes, like getting many tower view above ground for example. :) cheers! --Jacob (aka Tuxklok aka N1292P) -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Alan Teeder wrote: > I suppose the good news is that I am able to duplicate the fault on the XP > machine (which normally runs without fault) simply by using debug runtime.. I'm not sure that's good news.. Are both systems the same (64-bit or 32-bit)? Erik -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
Eric
With the current CVS on my XP machine (the one that runs) I have been trying
to debug this problem. Here is the progress to date.
I have edited "free_data" as so to allow facilitate breakpoint setting
void free_data()
{
if ( _data )
free( _data );
_data = NULL;
}
and then set a breakpoint at the "if" statement.
If I single step (F11) at the first occurrence of the breakpoint it fails as
it enters "free( _data)"
My guess is that space is not allocated for the rumble.wav data.
Sadly I am retired now and it is several years since I last debugged a
program. Even then as a Fortran man my C++ skills were somewhat lacking an
things like pointers to pointers got my poor brain confused.
I suppose the good news is that I am able to duplicate the fault on the XP
machine (which normally runs without fault) simply by using debug runtime..
Hope this is some help.
Alan
--
From: "Erik Hofman"
Sent: Monday, December 07, 2009 1:37 PM
To: "FlightGear developers discussions"
Subject: Re: [Flightgear-devel] Debug Assertion Failed in Sample_opneal.hxx
> Alan Teeder wrote:
>> Eric
>>
>> An aircraft that I am developing caused Flightgear to crash on the Vista
>> box, but not on the XP one.
>> This I traced to some bad coding in my JSBsim aero file:-
>>
>>
>>
>> fcs/elevator-pos-deg
>>
>>
>>
>>
>>
>>
>>
>> It was an empty table generated by Datcom+ which I had not got around to
>> filling in.
>> The XP machine, which I use most of the time does not hiccup at this.
>>
>> Flightgear on the Vista laptop also crashes with something that appears
>> to
>> be related to the sound patches, AND also every time that I exit.
>>
>> The XP box sees none of these problems.
>>
>>>From this I now believe that the problem is that the Vista laptop is less
>> tolerant of run-time errors than the XP box.
>>
>> As far as Sample_openal.hxx is concerned all I can guess from my debug
>> sessions at is that there is some kind of a problem at the time that
>> "Rumble.wav" is used and it is even possible that the problem is at the
>> XML
>> code level.
>
> It's not getting easier to track down. Although maybe it indicates an
> uninitialized variable or something like that.
>
> It might even be allocated memory that is reserved at an unrelated piece
> of code but that overwrites the section that gets freed by the
> soundmanager.
>
> Erik
>
> --
> Join us December 9, 2009 for the Red Hat Virtual Experience,
> a free event focused on virtualization and cloud computing.
> Attend in-depth sessions from your desk. Your couch. Anywhere.
> http://p.sf.net/sfu/redhat-sfdev2dev
> ___
> Flightgear-devel mailing list
> Flightgear-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Return on Information:
Google Enterprise Search pays you back
Get the facts.
http://p.sf.net/sfu/google-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Adjusting the Adjust View Distance
seconded Alan From: UltraZexe Zexeonyo Sent: Tuesday, December 08, 2009 11:31 AM To: flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] Adjusting the Adjust View Distance Hi all, I'm very new to this and so forgive me for my abrupt and mailing. I was referred to this devel-list by Gijs as it may interest some of you. Adjusting the 'Adjust View Distance' I have a little different taste than others especially when it comes to the Point of View (POV) of the cockpit. Where most pilots like to fly with a POV of 70- 80, I like to use 120. However, there is one problem with this, using a POV @ 120 causes the cockpit to look very very far away, making it almost impossible to see the instruments, unless of course you zoom it back up to a POV of 80. But you can fly using a POV @ 120 with no problem by adjusting the 'Adjust View Distance' from the 'View' menu. Simply click the dial on the 'Forward/backward' and stop where you like. For some planes, this works very well, for others, it's a disaster. The issue: The Adjust View Distance dial is over-sensitive, if I want a view distance of '0', i would click on '0' but because it's so sensitive, I always over-shoot the '0' mark and always hit '1.0m' or '-0.9m'. The difference in view is dramatic and can be a major flying issue. The solution: The problem is that the dial has a minimum of (-100) to a maximum of (100). The range of it is too large. We need to change the range to a smaller workable range, a good minimum and maximum is (-5m) to (5m). You could change it to (-1m) to (1m) if you wanted to. Where to change these variables? Go to Flightgear/data/GUI/dialog/pilot_offset. In the minimum and maximum field type in the new numbers, (-5m) and (5m) for Left and right, Up and Down, and Forward and Backwards. Save and quit. If you want the Adjust View Distance even more specific, decrease the range, so a good range would be (-1m) to (1m). So, if the cockpit is too close or too far, but you don't want to change the POV, using the adjust view distance is a good way to solve the problem. Just make sure that the Adjust View Distance range is calibrated to your likings. I use (-1m) to (1m) to get the distance just right. If you have any questions feel free to contact me via email. -Zexe Windows LiveT Hotmail is faster and more secure than ever. Learn more. -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] bug with taxiway signs
I don't know if this is known, but I don't remember seeing reference of it. With 1.9.1, using release scenery or terrasync, signs are drawn correctly. With cvs, also with terrasync or release scenery, signs are missing letters, making them not so useful. To see the problem start up at KLVK(for example, but effects all airports), in 1.9.1 and taxi around, then do the same in cvs, the problem should be clear. For example, excuse the crude ascii drawings if you will ;) Taxiing up Bravo towards Alpha and Juliet (KLVK) with 1.9.1 you will see these signs...correct. | <-- A[B] | [ <-- J[B] | But in cvs letters for Alpha and Bravo will be missing, and you will see these signsnot so correct. | <--[B] | | <--[B] | This effects all signs, at all airports I tried, release or terrasync scenery cheers! --Jacob -- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Adjusting the Adjust View Distance
Hi all, I'm very new to this and so forgive me for my abrupt and mailing. I was referred to this devel-list by Gijs as it may interest some of you. Adjusting the 'Adjust View Distance'I have a little different taste than others especially when it comes to the Point of View (POV) of the cockpit. Where most pilots like to fly with a POV of 70- 80, I like to use 120. However, there is one problem with this, using a POV @ 120 causes the cockpit to look very very far away, making it almost impossible to see the instruments, unless of course you zoom it back up to a POV of 80. But you can fly using a POV @ 120 with no problem by adjusting the 'Adjust View Distance' from the 'View' menu. Simply click the dial on the 'Forward/backward' and stop where you like. For some planes, this works very well, for others, it's a disaster.The issue: The Adjust View Distance dial is over-sensitive, if I want a view distance of '0', i would click on '0' but because it's so sensitive, I always over-shoot the '0' mark and always hit '1.0m' or '-0.9m'. The difference in view is dramatic and can be a major flying issue.The solution: The problem is that the dial has a minimum of (-100) to a maximum of (100). The range of it is too large. We need to change the range to a smaller workable range, a good minimum and maximum is (-5m) to (5m). You could change it to (-1m) to (1m) if you wanted to. Where to change these variables? Go to Flightgear/data/GUI/dialog/pilot_offset. In the minimum and maximum field type in the new numbers, (-5m) and (5m) for Left and right, Up and Down, and Forward and Backwards. Save and quit. If you want the Adjust View Distance even more specific, decrease the range, so a good range would be (-1m) to (1m).So, if the cockpit is too close or too far, but you don't want to change the POV, using the adjust view distance is a good way to solve the problem. Just make sure that the Adjust View Distance range is calibrated to your likings. I use (-1m) to (1m) to get the distance just right.If you have any questions feel free to contact me via email.-Zexe _ Windows Live Hotmail is faster and more secure than ever. http://www.microsoft.com/windows/windowslive/hotmail_bl1/hotmail_bl1.aspx?ocid=PID23879::T:WLMTAGL:ON:WL:en-ww:WM_IMHM_1:092009-- Return on Information: Google Enterprise Search pays you back Get the facts. http://p.sf.net/sfu/google-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
