Re: [Flightgear-devel] tacan
Josh What property can I increment to change the channel on the TACAN? I have a knob on a TACAN instrument that is supposed to either inc/dec the channel, or the x/y selector, depending on the position of another switch. I could do this by introducing another property and some nasal to translate between it and the three existing numeric properties, but this seems like a bit of a kludge. You need to set these properties for the individual channels: /instrumentation/tacan/frequencies/selected-channel[1] /instrumentation/tacan/frequencies/selected-channel[2] /instrumentation/tacan/frequencies/selected-channel[3} /instrumentation/tacan/frequencies/selected-channel[4] Note that channel 1 is [1], not [0] as you might have guessed. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pthreads: FlightGear runtime segfault under Cygwin
Jon S. Berndt wrote: I've run into an error message seeming to fault pthreads for a flightgear segfault: (gdb) run Starting program: /usr/local/bin/fgfs.exe Program received signal SIGSEGV, Segmentation fault. 0x610ae938 in pthread_key_create () from /usr/bin/cygwin1.dll Is there a way to turn off pthreads? What do pthreads buy me under Cygwin? Compiling FlightGear with the option --without-threads should disable pthreads. Although I doubt the problem is the use of pthreads it certainly would make debugging a lot easier. Adding threads will reduce framerate jitter when new scenery (or METAR data) gets loaded). Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
On Sun, 2006-06-18 at 16:44 +0100, Vivian Meazza wrote: Lee Elliott wrote On Saturday 17 June 2006 20:18, Vivian Meazza wrote: Lee On Saturday 17 June 2006 07:34, Melchior FRANZ wrote: * Lee Elliott -- Saturday 17 June 2006 05:02: Is anyone else seeing a memory leak in current cvs? I would be surprised if we had no leaks at all. But in a short test with $ fgfs --aircraft=ufo --airport=kufo ... i didn't see anything like you observed. The memory consumption was quite stable after a few minutes. (This was with ATC turned off.) m. Tried fgfs --aircraft=ufo --airport=kufo and had no problems. Went back to the a/c I was testing and just let it sit there while doing nothing but reduce the sound volume - no problem. I then closed the canopy (nasal), which resulted in a slight increase of fgfs vm utilisation but after waiting for a minute or two it was stable. I then revealed the 2D panel and that's when the vm utilisation for fgfs started to ramp up (I ssh'd in from another m/c and ran top to watch this). I switched back to the ufo and when I revealed the 2D panel (C-172 default) fgfs vm utilisation seemed to start ramping, although a lot more slowly than the a/c I was testing, so it looks as though it may be something to do with the 2D panel, which is a bit strange. As I said, the rate seems quite a bit lower with the ufo - I had to wait about a minute or so before it was apparent that fgfs's vm utilisation was ramping and it was only grabbing an extra mb every 30 seconds or so. Do you see this? I just left the KC135 running airborne - it chewed up VM and finally froze. 2D panel as well. I'm not clear if this is the same phenomenon that you are seeing, or if the 2D panel is significant. Vivian Sounds very much like it - I first noticed under the same conditions. I'll try cvs with Melchior's latest update, but a bit later - I'm of to a birthday now. I have now completed a bit more testing using the Seahawk using cvs-head of this am on Windows XP. With the 3D panel there is no memory leak. When I switch to the 2d panel on the fly, the memory leak starts. When I switch back to 3d, the leak stops. This can be repeated at will. Vivian I can confirm the same thing on AMD64 running Linux (2.6.15 kernel). However, I would need to wait a while to consume the VM on this machine before it crashes due to lack of memory (w/ 2gig of swap). George ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [RFC] HUD
Hi,
... was offline, sorry.
On Saturday 17 June 2006 23:28, Erik Hofman wrote:
You know, I did a quick grep in the source code for fast_ and only found
it to be used in simgear/sound/xmlsound.cxx (namely fast_log10 and
fast_log). Maybe we can get rid of them after all.
In that time, I have tried to fix fastmath.cpp to compile correctly.
My suggestion would be to keep the transcendent functions and correct them to
make them compile correct.
I have also removed the functions that are very most likely slower than the
libm implementations from the header.
Can you/somebody help me please and double check the attached patch if I have
converted them correctly before I check that in?
I have *not* done any tests with this functions against the libm ones. In fact
I do not know what error is acceptable for the fast implementation.
What do you think?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: simgear/math/fastmath.cxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.cxx,v
retrieving revision 1.8
diff -u -r1.8 fastmath.cxx
--- simgear/math/fastmath.cxx 16 Jun 2006 09:29:54 - 1.8
+++ simgear/math/fastmath.cxx 19 Jun 2006 17:03:05 -
@@ -35,20 +35,20 @@
* This function is on avarage 9 times faster than the system exp() function
* and has an error of about 1.5%
*/
-static union {
-double d;
-struct {
+double fast_exp(double val) {
+const double a = 1048576/M_LN2;
+const double b_c = 1072632447; /* 1072693248 - 60801 */
+
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
int i, j;
#else
int j, i;
#endif
-} n;
-} _eco;
-
-double fast_exp(double val) {
-const double a = 1048576/M_LN2;
-const double b_c = 1072632447; /* 1072693248 - 60801 */
+ } n;
+} _eco;
_eco.n.i = (int)(a*val + b_c);
@@ -61,30 +61,30 @@
*/
double fast_exp2( const double val )
{
-int e;
-double ret;
-
-if (val = 0) {
-e = int (val);
-ret = val - (e - 1);
-
+union {
+ double d;
+ struct {
#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int i, j;
#else
-((*(1 + (int *) ret)) = ~(2047 20)) += (e + 1023) 20;
+int j, i;
#endif
+ } n;
+} ret;
+
+if (val = 0) {
+int e = int (val);
+ret.d = val - (e - 1);
+ret.n.i = ~(2047 20);
+ret.n.i += (e + 1023) 20;
} else {
-e = int (val + 1023);
-ret = val - (e - 1024);
-
-#if BYTE_ORDER == BIG_ENDIAN
-((*((int *) ret)) = ~(2047 20)) += e 20;
-#else
-((*(1 + (int *) ret)) = ~(2047 20)) += e 20;
-#endif
+int e = int (val + 1023);
+ret.d = val - (e - 1024);
+ret.n.i = ~(2047 20);
+ret.n.i += e 20;
}
-return ret;
+return ret.d;
}
@@ -96,7 +96,12 @@
float result, tmp;
float mp = 0.346607f;
-result = *(int*)val;
+union {
+float f;
+int i;
+} v;
+v.f = val;
+result = v.i;
result *= 1.0/(123);
result = result - 127;
@@ -115,27 +120,14 @@
result = val + 127 - tmp;
result *= (123);
-*(int*)result = (int)result;
-return result;
-}
-
-
-
-/**
- * While we're on the subject, someone might have use for these as well?
- * Float Shift Left and Float Shift Right. Do what you want with this.
- */
-void fast_BSL(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x+=shiftAmount23;
-
+union {
+float f;
+int i;
+} v;
+v.i = (int)result;
+return v.f;
}
-void fast_BSR(float x, register unsigned long shiftAmount) {
-
- *(unsigned long*)x-=shiftAmount23;
-
-}
/*
@@ -148,20 +140,28 @@
*/
float fast_pow(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
float fast_root(const float f, const int n)
{
-long *lp,l;
-lp=(long*)(f);
-l=*lp;l-=0x3F80l;l=(n-1);l+=0x3F80l;
-*lp=l;
-return f;
+union {
+float f;
+int i;
+} v;
+v.f = f;
+v.i -= 0x3F80l;
+v.i = (n-1);
+v.i += 0x3F80l;
+return v.f;
}
Index: simgear/math/fastmath.hxx
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/math/fastmath.hxx,v
retrieving revision 1.9
diff -u -r1.9 fastmath.hxx
--- simgear/math/fastmath.hxx 17 Jun 2006 16:04:28 - 1.9
+++ simgear/math/fastmath.hxx 19 Jun 2006 17:03:05 -
@@ -45,10 +45,6 @@
float fast_acos(const float val);
float fast_atan(const float val);
-void fast_BSL(float x, register unsigned long
[Flightgear-devel] Cygwin Build of FlightGear
Has anyone successfully built FlightGear under Cygwin using the latest Cygwin environment and the latest plib/simgear/flightgear? I'm wondering if I need to ditch my entire codebase and start from scratch ... Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin Build of FlightGear
Hi Jon! Jon S. Berndt schrieb: Has anyone successfully built FlightGear under Cygwin using the latest Cygwin environment and the latest plib/simgear/flightgear? I'm wondering if I need to ditch my entire codebase and start from scratch ... This was the only way for me to get rid of all these strange errors I reported some days ago. All trials to repair Cygwin were lost time. I had NOT ONLY to delete the folders bin, etc, lib, tmp, usr, var, home (only my tar folder in home survived) BUT ALSO copy the Cygwin setup.exe into another folder!!! When I just created another Local Package Directory and selected it at the special page of the Cygwin setup Cygwin seemed to remember some old values and I had the same trouble as before :-/ So, deleting the Cygwin folders above, creating a new Cygwin setup folder (ie CygSetup060619) did the trick. Don't ask me why :-) AND I built the OpenAL files from scratch (cyg_openAL.tgz) and also plib (plib-1.8.4.tar.gz). SimGear and FlightGear CVS was downloaded fully new. The only error I got with the new build was the MINMAX problem, we now have two different solutions for thanks to our FG friends. After recompiling and updating to the newest CVS FG data all works perfect. This is my poor man's solution - I have no deeper knowledge of Cygwin! Hope this helps you too, Jon :-) Regards Georg HeliFlyer EDDW ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with Sukhoi 26 panel
On Monday 19 June 2006 20:59, flying.toaster wrote: I have a problem with placing hotspots on the control panel of the Su-26 Explanation can be found in the following thread at avsim forums: Thank you for any advice you can provide on the issue Ah, the good old hotspots. These are by far the most horrible part of doing a cockpit for FGFS, really unpleasant and in many places quite illogical. Can we see your hotspots XML file? I suspect you're suffering from the same thing I puzzled over for weeks. Although the hotspots were being drawn where I expected, only some of them were working. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tacan
Vivian Meazza wrote: Josh What property can I increment to change the channel on the TACAN? I have a knob on a TACAN instrument that is supposed to either inc/dec the channel, or the x/y selector, depending on the position of another switch. I could do this by introducing another property and some nasal to translate between it and the three existing numeric properties, but this seems like a bit of a kludge. You need to set these properties for the individual channels: /instrumentation/tacan/frequencies/selected-channel[1] /instrumentation/tacan/frequencies/selected-channel[2] /instrumentation/tacan/frequencies/selected-channel[3} /instrumentation/tacan/frequencies/selected-channel[4] Note that channel 1 is [1], not [0] as you might have guessed. Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel Yeah, but then I have to write nasal code. If the channel is 099X, there is nothing that I can increment to get the right answer. I need to test each digit and decide to increment, or zero and carry. It just seems a little odd, I would have expected one integer to hold the numbers, and one string to hold the X/Y part. Perhaps I will write some nasal code to live in controls.nas that translates between a single number in selected-channel[0] and 1-3. That way the existing behavior will be preserved, and there will also be a number that can be incremented or decremented between 0 and 126. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tacan
Josh Babcock wrote Vivian Meazza wrote: Josh What property can I increment to change the channel on the TACAN? I have a knob on a TACAN instrument that is supposed to either inc/dec the channel, or the x/y selector, depending on the position of another switch. I could do this by introducing another property and some nasal to translate between it and the three existing numeric properties, but this seems like a bit of a kludge. You need to set these properties for the individual channels: /instrumentation/tacan/frequencies/selected-channel[1] /instrumentation/tacan/frequencies/selected-channel[2] /instrumentation/tacan/frequencies/selected-channel[3} /instrumentation/tacan/frequencies/selected-channel[4] Note that channel 1 is [1], not [0] as you might have guessed. Vivian Yeah, but then I have to write nasal code. If the channel is 099X, there is nothing that I can increment to get the right answer. I need to test each digit and decide to increment, or zero and carry. It just seems a little odd, I would have expected one integer to hold the numbers, and one string to hold the X/Y part. Perhaps I will write some nasal code to live in controls.nas that translates between a single number in selected-channel[0] and 1-3. That way the existing behavior will be preserved, and there will also be a number that can be incremented or decremented between 0 and 126. It was designed to work with the menu item in which each column is set independently, and we need a string with which to search the TACAN channel/ frequency pairing database. But I'm not sure what you are trying to. Others have created a TACAN control panel, so there must be a way to do it. If you would explain in a bit more detail ... Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
Melchior FRANZ wrote: We have /position/altitude-agl-ft in the property tree (-0.1946648994 ft). But what the (old) HUD code uses for RadioAltimeter is /position/altitude-ft - /position/ground-elev-ft = 6.202537 Clearly, the 6 ft make more sense than any negative number. What why is altitude-agl-ft wrong? I'd need the 6.202537 in the property tree. How would I call it? /position/correct-altitude-agl-ft, or what? :-} m. /position/altitude-agl-ft = -0.1946648994 /position/altitude-ft = 4527.586407 /position/ground-elev-ft = 4521.38387 Could this have been introduced early on as a hack to compensate for a difference between the wheel contact point and some aircraft reference point higher up on the aircraft structure? It looks pretty suspect to me. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
On Monday 19 June 2006 22:45, Curtis L. Olson wrote: Melchior FRANZ wrote: We have /position/altitude-agl-ft in the property tree (-0.1946648994 ft). But what the (old) HUD code uses for RadioAltimeter is /position/altitude-ft - /position/ground-elev-ft = 6.202537 Clearly, the 6 ft make more sense than any negative number. What why is altitude-agl-ft wrong? I'd need the 6.202537 in the property tree. How would I call it? /position/correct-altitude-agl-ft, or what? :-} m. /position/altitude-agl-ft = -0.1946648994 /position/altitude-ft = 4527.586407 /position/ground-elev-ft = 4521.38387 Could this have been introduced early on as a hack to compensate for a difference between the wheel contact point and some aircraft reference point higher up on the aircraft structure? It looks pretty suspect to me. Which FDM did you try? I know there is a subtle difference between JSBSim and YASim. I agree that these three properties should fit together. I will look into that. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
* Mathias Fröhlich -- Monday 19 June 2006 23:18: Melchior FRANZ wrote: We have /position/altitude-agl-ft in the property tree (-0.1946648994 ft). But what the (old) HUD code uses for RadioAltimeter is /position/altitude-ft - /position/ground-elev-ft = 6.202537 Which FDM did you try? YASim (j3cub in KUFO). m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
On Monday 19 June 2006 23:23, Melchior FRANZ wrote: YASim (j3cub in KUFO). The one I expected :) Try that attached patch. Andy safes an on ground trim routine by just starting an aircraft with zero agl in the sense of 'all gear contact points are exactly zero meters above ground'. Starting from this situation the aircraft just drops into its springs. This kind of agl is also set into the FGInterface agl routine from YASim. If you would ask me, I would like to have it in a consistent way, but may be we should ask Andy about such a change? Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] Index: src/FDM/YASim/YASim.cxx === RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/YASim/YASim.cxx,v retrieving revision 1.34 diff -u -r1.34 YASim.cxx --- src/FDM/YASim/YASim.cxx 1 Mar 2006 22:59:58 - 1.34 +++ src/FDM/YASim/YASim.cxx 19 Jun 2006 21:39:13 - @@ -371,13 +371,13 @@ double lat, lon, alt; sgCartToGeod(s-pos, lat, lon, alt); _set_Geodetic_Position(lat, lon, alt*M2FT); -_update_ground_elev_at_pos(); +double groundlevel_m = get_groundlevel_m(lat, lon, alt); +_set_Runway_altitude(groundlevel_m*SG_METER_TO_FEET); +_set_Altitude_AGL((alt-groundlevel_m)*SG_METER_TO_FEET); // UNUSED //_set_Geocentric_Position(Glue::geod2geocLat(lat), lon, alt*M2FT); -_set_Altitude_AGL(model-getAGL() * M2FT); - // useful conversion matrix float xyz2ned[9]; Glue::xyz2nedMat(lat, lon, xyz2ned); ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] altitude agl
* Mathias Fröhlich -- Monday 19 June 2006 23:41: Try that attached patch. The values are almost correct with it. Just a very minor difference between altitude-agl-ft and the difference of altitude-ft and ground-elev-ft. but may be we should ask Andy about such a change? Definitely. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] tacan
Vivian Meazza wrote: Josh Babcock wrote Vivian Meazza wrote: Josh What property can I increment to change the channel on the TACAN? I have a knob on a TACAN instrument that is supposed to either inc/dec the channel, or the x/y selector, depending on the position of another switch. I could do this by introducing another property and some nasal to translate between it and the three existing numeric properties, but this seems like a bit of a kludge. You need to set these properties for the individual channels: /instrumentation/tacan/frequencies/selected-channel[1] /instrumentation/tacan/frequencies/selected-channel[2] /instrumentation/tacan/frequencies/selected-channel[3} /instrumentation/tacan/frequencies/selected-channel[4] Note that channel 1 is [1], not [0] as you might have guessed. Vivian Yeah, but then I have to write nasal code. If the channel is 099X, there is nothing that I can increment to get the right answer. I need to test each digit and decide to increment, or zero and carry. It just seems a little odd, I would have expected one integer to hold the numbers, and one string to hold the X/Y part. Perhaps I will write some nasal code to live in controls.nas that translates between a single number in selected-channel[0] and 1-3. That way the existing behavior will be preserved, and there will also be a number that can be incremented or decremented between 0 and 126. It was designed to work with the menu item in which each column is set independently, and we need a string with which to search the TACAN channel/ frequency pairing database. But I'm not sure what you are trying to. Others have created a TACAN control panel, so there must be a way to do it. If you would explain in a bit more detail ... Vivian ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel I'm modeling a TACAN instrument that has a dial which can be used to increment/decrement the channel number. I want to set up hotspots for that dial. One increments the channel number, one decrements it. Another dial selects another mode where the first dial switches between X and Y channels. http://jrbabcock.home.comcast.net/flightgear/ch53e/tacan.jpg I'm not saying that I can't do it, I'm just saying that I can't do it without implementing some Nasal. It just seems that changing a channel in this manner is a little to basic of a task for plane designers to have to resort to Nasal for. I think I will just make the Nasal code for controls.nas and bind it to all the channel props with a listener. The other option is to create a controls.changeTacanChannel() that has the logic to be able to increment the channel and set the individual channel digit properties. Now that I think about it, the latter sounds like a better way to do things, as it does not require listeners or duplication of data in extra properties. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin Build of FlightGear
Hi Jon! Jon S. Berndt schrieb: Has anyone successfully built FlightGear under Cygwin using the latest Cygwin environment and the latest plib/simgear/flightgear? I'm wondering if I need to ditch my entire codebase and start from scratch This was the only way for me to get rid of all these strange errors I reported some days ago. All trials to repair Cygwin were lost time. I had NOT ONLY to delete the folders bin, etc, lib, tmp, usr, var, home (only my tar folder in home survived) BUT ALSO copy the Cygwin setup.exe into another folder!!! When I just created another Local Package Directory and selected it at the special page of the Cygwin setup Cygwin seemed to remember some old values and I had the same trouble as before :-/ So, deleting the Cygwin folders above, creating a new Cygwin setup folder (ie CygSetup060619) did the trick. Don't ask me why :-) AND I built the OpenAL files from scratch (cyg_openAL.tgz) and also plib (plib-1.8.4.tar.gz). SimGear and FlightGear CVS was downloaded fully new. Well, I reloaded my cygwin installation in parts, ditched my entire flightgear/plib/simgear installation, and I still get an immediate segfault when I try running flightgear. Very, very frustrating. I hate to do this, but I guess I will next try to completely delete all cygwin directories. This is just so strange. I'd really like to know how many are using cygwin, and if they are also having any trouble. Jon ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
It was suggested on IRC that I might like to do memory leak tests on 098a/Win Meresults; *Start***Finish* Plane: Time:Mem: Time: Mem: PA28-161 12:34NZST 548.4M13:03 558.4M Hunter 13:04NZST 543.4M13:35 552.3M 172-3d 13:45NZST 542.4M14:12 533.7M hope these figures are useful to someone. :-D ene _ Check out the latest video @ http://xtra.co.nz/streaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problem with Sukhoi 26 panel
Sure Here are the main panel file and the definition of the 3D plane that carries it I dunno though if it will be of some help since they are all linked to the same property (the starter) but at different locations Ah, the good old hotspots. These are by far the most horrible part of doing a cockpit for FGFS, really unpleasant and in many places quite illogical. Can we see your hotspots XML file? I suspect you're suffering from the same thing I puzzled over for weeks. Although the hotspots were being drawn where I expected, only some of them were working. Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel ?xml version=1.0? PropertyList !--sensitive areas-- panel namemainPanel/name pathAircraft/Su-26M/Panels/main-panel.xml/path depth-test type=booltrue/depth-test bottom-left x-m1.452/x-m y-m-0.325/y-m z-m 0.048/z-m /bottom-left bottom-right x-m1.452/x-m y-m 0.326/y-m z-m 0.048/z-m /bottom-right top-left x-m1.362/x-m y-m-0.325/y-m z-m 0.528/z-m /top-left !-- bottom-left x-m1.252/x-m y-m-0.325/y-m z-m 0.048/z-m /bottom-left bottom-right x-m1.252/x-m y-m 0.326/y-m z-m 0.048/z-m /bottom-right top-left x-m1.162/x-m y-m-0.325/y-m z-m 0.528/z-m /top-left-- /panel !-- panel namesidePanel/name pathAircraft/Su-26M/Panels/side-panel.xml/path depth-test type=boolfalse/depth-test bottom-left x-m1.615/x-m y-m-0.376/y-m z-m-0.172/z-m /bottom-left bottom-right x-m1.615/x-m y-m0.365/y-m z-m-0.172/z-m /bottom-right top-left x-m1.463/x-m y-m-0.376/y-m z-m 0.362/z-m /top-left /panel -- /PropertyList PropertyList nameSu-26 main panel/name backgroundAircraft/Su-26M/Panels/transparent-bg.rgb/background w1024/w h768/h view-height768/view-height instruments instrument !--include=Instruments/mainActions.xml-- namecontrols/name x0/x y0/y w-base1024/w-base h-base768/h-base actions !-- Radio -- action !-- first action -- descsmall audio frequency decrease/desc button0/button !-- bind it to a mouse button -- x130/x !-- placement relative to instrument center -- y330/y w16/w !-- size of hotspot -- h16/h binding commandproperty-toggle/command propertycontrols/engines/engine/starter/property /binding /action action descEngine starter 2/desc button0/button x230/x y330/y w16/w h16/h binding commandproperty-toggle/command propertycontrols/engines/engine/starter/property /binding /action action descEngine starter/desc button0/button x430/x y330/y w16/w h16/h binding commandproperty-toggle/command property/controls/engines/engine/starter/property /binding /action action desclarge audio frequency increase/desc button1/button x530/x y330/y w16/w h16/h binding commandproperty-toggle/command propertycontrols/engines/engine/starter/property /binding /action !-- breakers -- action desclarge audio frequency increase/desc button0/button x630/x y330/y w16/w h16/h binding commandproperty-toggle/command propertytoto/property /binding /action /actions /instrument /instruments /PropertyList ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Memory leak
I have had lock-ups on longer X-C flights with the pa24-250 recently that could be from a memory leak. So I used the system monitor to check on VM growth. The only 2D pannel used in the pa24-250 is the radio stack. So I tried commenting out various components of the radio stack in the file radio-panel.xml. If I comment all the radio stack in this file, the memory leak is gone. I did not try all combinations, but the leak rate seems to get greater the more radios are not commented out. I do not remeber this occurring even on very long X-C flights when I first submitted the pa24-250. System info FC4 Linux updated with yum update last Saturday Plib, SimGear, fgfs source, and base all updated from CVS on Saturday also. AMD Athlon XP 3200+ with 512 MB RAM Nvidia GeForce 7800 GS OC with 256MB GDDR3 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cygwin Build of FlightGear
when I try running flightgear. Very, very frustrating. I hate to do this, but I guess I will next try to completely delete all cygwin directories. This is just so strange. This was the only solution for me which worked! I'd really like to know how many are using cygwin, and if they are also having any trouble. Together with FlightGear, only a few people. Otherwise we should have more errormessages on the list from unknown people! Jon Good luck! Georg ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
