Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Gerard ROBIN ha scritto: http://www.geocities.com/robitabu/fgfs_pa/fgsd_palermo.html Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. That's right. But I don't like it very much. I'm just to lazy to compile all that stuff (FGFS + FGSD + Related libs) under Linux. It is a long time ago i wondered to make sceneries of France in Provence. You will need some time :-) But it pays. Roberto ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FDM freeze
(2) I don't allow multiloop to become higher than, currently, 80.
diff -u -p -r1.20 flight.cxx
--- flight.cxx 22 Nov 2004 10:10:33 - 1.20
+++ flight.cxx 26 May 2005 05:07:44 -
@@ -83,7 +83,13 @@ FGInterface::_calc_multiloop (double dt)
// ... ok, two times the roundoff to have enough room.
int multiloop = int(floor(ml * (1.0 + 2.0*DBL_EPSILON)));
remainder = (ml - multiloop) / hz;
- return (multiloop * speedup);
+
+ int result = multiloop * speedup;
+ if (result 80) {
+ fprintf(stderr, \033[31;1m_calc_multiloop=%d\033[m\n, result);
+ return 80;
+ }
+ return result;
}
I tried your fix above and it didn't work for me :(
Here's a fix that I just tried and it works for me. In JSBSim.cxx, line about
number 423, I just commented out the return statement, so the FDM can
continue no matter what happens with the ground cache.
if (!cache_ok) {
SG_LOG(SG_FLIGHT, SG_WARN,
FGInterface is beeing called without scenery below the
aircraft!);
//return;
}
No more freezes now :)
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
* Dave Culp -- Thursday 26 May 2005 09:00: (2) I don't allow multiloop to become higher than, currently, 80. I tried your fix above and it didn't work for me :( Oh. I had only observed the problem with YASim aircraft so far, and there it helped. But there's no reason why it wouldn't happen with JSBSim, and it doesn't surprise me that one needs a different fix for it. Here's a fix that I just tried and it works for me. In JSBSim.cxx, line about number 423, I just commented out the return statement, [...] No more freezes now :) So we need both workarounds for now!? MATHAS! :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FDM freeze
Hi,
On Donnerstag 26 Mai 2005 09:00, Dave Culp wrote:
I tried your fix above and it didn't work for me :(
Yes, because Melchiors beacon stuff is different from that one you describe.
Especially, if AI aircraft keep on moving it sounds like something different.
I have thought about that and wanted to send a test patch to somebody with
that problems at sunday, but by internet connection stopped working at that
evening
For everybody experiencing these freezes with 'no ground below aircraft'.
Could you try the patch I have attached below?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/FDM/groundcache.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/groundcache.cxx,v
retrieving revision 1.6
diff -u -r1.6 groundcache.cxx
--- src/FDM/groundcache.cxx 29 Apr 2005 14:38:24 - 1.6
+++ src/FDM/groundcache.cxx 26 May 2005 07:23:48 -
@@ -25,6 +25,7 @@
#include plib/sg.h
+#include simgear/sg_inlines.h
#include simgear/constants.h
#include simgear/debug/logstream.hxx
#include simgear/math/sg_geodesy.hxx
@@ -37,6 +38,131 @@
#include flight.hxx
#include groundcache.hxx
+// #define method1
+#define method2
+
+#if defined(method1)
+static inline bool fgPointInTriangle(sgVec3 point, sgVec3 tri[3])
+{
+ sgVec3 trip[3];
+ sgSubVec3(trip[0], tri[0], point);
+ sgSubVec3(trip[1], tri[1], point);
+ sgSubVec3(trip[2], tri[2], point);
+ sgVec3 s[3];
+ sgVectorProductVec3(s[0], trip[0], trip[1]);
+ sgVectorProductVec3(s[1], trip[1], trip[2]);
+ sgVectorProductVec3(s[2], trip[2], trip[0]);
+
+ if (sgScalarProductVec3(s[0], s[1]) -FLT_EPSILON)
+return false;
+ if (sgScalarProductVec3(s[1], s[2]) -FLT_EPSILON)
+return false;
+
+ return true;
+}
+#elif defined(method2)
+static inline bool fgPointInTriangle( sgVec3 point, sgVec3 tri[3] )
+{
+sgVec3 dif;
+
+// Some tolerance in meters we accept a point to be outside of the triangle
+// and still return that it is inside.
+SGfloat eps = 10*FLT_EPSILON;
+SGfloat min, max;
+// punt if outside bouding cube
+SG_MIN_MAX3 ( min, max, tri[0][0], tri[1][0], tri[2][0] );
+if( (point[0] min - eps) || (point[0] max + eps) )
+return false;
+dif[0] = max - min;
+
+SG_MIN_MAX3 ( min, max, tri[0][1], tri[1][1], tri[2][1] );
+if( (point[1] min - eps) || (point[1] max + eps) )
+return false;
+dif[1] = max - min;
+
+SG_MIN_MAX3 ( min, max, tri[0][2], tri[1][2], tri[2][2] );
+if( (point[2] min - eps) || (point[2] max + eps) )
+return false;
+dif[2] = max - min;
+
+// drop the smallest dimension so we only have to work in 2d.
+SGfloat min_dim = SG_MIN3 (dif[0], dif[1], dif[2]);
+SGfloat x1, y1, x2, y2, x3, y3, rx, ry;
+if ( fabs(min_dim-dif[0]) = FLT_EPSILON ) {
+// x is the smallest dimension
+x1 = point[1];
+y1 = point[2];
+x2 = tri[0][1];
+y2 = tri[0][2];
+x3 = tri[1][1];
+y3 = tri[1][2];
+rx = tri[2][1];
+ry = tri[2][2];
+} else if ( fabs(min_dim-dif[1]) = FLT_EPSILON ) {
+// y is the smallest dimension
+x1 = point[0];
+y1 = point[2];
+x2 = tri[0][0];
+y2 = tri[0][2];
+x3 = tri[1][0];
+y3 = tri[1][2];
+rx = tri[2][0];
+ry = tri[2][2];
+} else if ( fabs(min_dim-dif[2]) = FLT_EPSILON ) {
+// z is the smallest dimension
+x1 = point[0];
+y1 = point[1];
+x2 = tri[0][0];
+y2 = tri[0][1];
+x3 = tri[1][0];
+y3 = tri[1][1];
+rx = tri[2][0];
+ry = tri[2][1];
+} else {
+// all dimensions are really small so lets call it close
+// enough and return a successful match
+return true;
+}
+
+// check if intersection point is on the same side of p1 - p2 as p3
+SGfloat tmp = (y2 - y3);
+SGfloat tmpn = (x2 - x3);
+int side1 = SG_SIGN (tmp * (rx - x3) + (y3 - ry) * tmpn);
+int side2 = SG_SIGN (tmp * (x1 - x3) + (y3 - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 1 check\n);
+return false;
+}
+
+// check if intersection point is on correct side of p2 - p3 as p1
+tmp = (y3 - ry);
+tmpn = (x3 - rx);
+side1 = SG_SIGN (tmp * (x2 - rx) + (ry - y2) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 2 check\n);
+return false;
+}
+
+// check if intersection point is on correct side of p1 - p3 as p2
+tmp = (y2 - ry);
+tmpn = (x2 - rx);
+side1 = SG_SIGN (tmp * (x3 - rx) + (ry - y3) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
+if ( side1 != side2 ) {
+// printf(failed side 3 check\n);
+return false;
+}
+
+return true;
+}
+#else
+static inline bool
Re: [Flightgear-devel] Re: FDM freeze
Hi, On Donnerstag 26 Mai 2005 09:20, Melchior FRANZ wrote: So we need both workarounds for now!? MATHAS! :-) Sorry for that long time ... I lost my internet connection at sunday evening. The guys from the telephone company found out that there is significant noise in the cable (?, that is what he told me!). I now found out that unpluging my telephone helps my adsl connection to be reliably up again ... Ok, now many mails to read ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] working with the property tree
bass pumped wrote: I need to learn how to work with the property tree in flightgear. Could someone refer me to material that might be helpful? This isn't much information. What exactly do you want to do with the property tree, or are you just looking for a short description? You could start by taking a look at README.introduction, README.IO and README.properties in the Docs directory of the base package. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery size constraints
Harald JOHNSEN wrote: Alberico, James F wrote: Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. Hi Jim, It good to see some big names showing up on the list. This might give the project a boost to get to the next level. What I think I've learned so far from debugging: 1.) The FGFS FGBinObj reads with no errors. 2.) The access violation occurs during leaf generation. 3.) The breakage occurs shortly after the texture coordinate index exceeds the max value of a short (32767) and goes negative. 4.) The symbols (e.g., tris_tc) that carry the read-in indices are of type int 5.) Examination of the TerraGear bin writes, and the FGFS reads reveal the indices are stored as short types. 6.) So, my conclusion is the scenery of the 1-arcsec tile is limited to 32767 nodes. (or maybe polygons?) And, TerraGear will truncate any index above that when writing to the binary file. I'm a newbie to TerraGear/FGFS details, so please correct me if I'm wrong about any of this. At this point Curtis is the one who is most involved in these things. He is attending the MathWorks International Aerospace and Defense Conference 2005 and will be back tomorrow. It might be best to send him a private copy of your mail also. I would appreciate any comments on what mess might result from any attempt to store/read ints, rather than shorts, to expand the scenery resolution. From a performance standpoint, the capacity of the short type may far exceed anything practical at the present time. Comments on that aspect are welcome, too. I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. Curtis already mentioned he wanted to change the layout of the tiles which probably breaks backward compatibility. So if it would be necessary this change could be adopted as well. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrain elevation at a given position
Hi, On Montag 23 Mai 2005 10:52, BONNEVILLE David wrote: How could I get the terrain elevation at a given lat/lon at runtime ? Could you point me to the right way ? That depends on what you need. In src/Scenery/hitlist.* there are the fgCurrentElev(...) functions which could be used to get a list of intersection points of the scenery with the line from the given position towards the earths center. You can see in src/Scenery/tilemgr.cxx in the function FGTileMgr::updateCurrentElevAtPos(...) how this could be used to compute a single altitude value. Alternatively, you can use that ground cache in src/FDM/groundcache* to get such scenery altitude. You first have to build that cache for a given position with prepare_ground_cache. Then you can query for the altitude by get_agl. The basic difference is that the fgCurrentElev function walks the whole scenery each time you ask for an altitude. The ground cache functions build up a small flat subset of the scenery into an own small scenegraph. If you need miltiple terrain altitude values at close but different points in the scene the ground cache will be better. If you need only a single altitude or values far from each other you need to use fgCurrentElev. Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Norman Vine wrote: http://baron.flightgear.org/pipermail/flightgear-devel/2003-September/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. I've had this in the back of my mind ever since you brought it up, but not many people (including XML experts) seem to like binary XML. I'm still undecided about it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
-Original Message- Erik Hofman Norman Vine wrote: http://baron.flightgear.org/pipermail/flightgear-devel/2003-Se ptember/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. I've had this in the back of my mind ever since you brought it up, but not many people (including XML experts) seem to like binary XML. I'm still undecided about it. Erik Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. This could be transparent to the user (they simply edit the ASCII version), it simply causes the startup time to be longer the next time around, but if no changes are made then there is no time penalty. Richard This e-mail has been scanned for Bede Scientific Instruments for all viruses by Star Internet. The service is powered by MessageLabs. For more information on a proactive anti-virus service working around the clock, around the globe, visit: http://www.star.net.uk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CH pedals
Hi, i've recently discovered this url: http://sourceforge.net/mailarchive/message.php?msg_id=1389791 in which is explaned what the problem is with the CH product pro pedals. Now I've compiled the pedals in joydev.c and hid-core.c and can see the hid-core.c: hid_init_reports usb_set_idle()=-911 in dmesg, but still the joystick isn't recognised with js_demo. I've copied the entire dmesg output, since I can't really tell what is relevant and what isn't. First lsmod, I need to load every module you see here. it doesn't work if i don't [EMAIL PROTECTED] operat]# lsmod Module Size Used by ehci-hcd 25732 0 (unused) joydev 6060 0 hid22404 0 (unused) input 5312 0 (autoclean) [joydev hid] nvidia 3859036 6 rtnet 53768 0 rtai_rtdm 12900 0 [rtnet] rtai_shm7368 0 rtai_fifos 17672 0 rtai_sched_up 48241 0 [rtnet rtai_rtdm] rtai 39616 2 [rtnet rtai_rtdm rtai_shm rtai_fifos rtai_sched_up] 3c59x 29552 1 usb-uhci 26668 0 (unused) usbcore83616 1 [ehci-hcd hid usb-uhci] you can see it still doesn't work.what am i doing wrong? I'm already trying everything for 2 weeks greetings Luuk van Hal [EMAIL PROTECTED] operat]# js_demo Joystick test program. ~~ Joystick 0: CH PRODUCTS CH THROTTLE QUADRANT Joystick 1: CH PRODUCTS CH FLIGHT SIM YOKE USB Joystick 2 not detected Joystick 3 not detected Joystick 4 not detected Joystick 5 not detected Joystick 6 not detected Joystick 7 not detected +JS.0--+JS.1--+ | Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 | Btns Ax:0 Ax:1 Ax:2 Ax:3 Ax:4 Ax:5 Ax:6 | +--+--+ | -1.0 -1.0 -1.0 -1.0 -1.0 -1.0 .. | -0.1 -0.2 +1.0 +1.0 +1.0 +0.0 +0.0 . | [EMAIL PROTECTED] operat]# dmesg A PERIODIC TIMER * *** LINUX TICK AT 100 (HZ) *** *** CALIBRATED CPU FREQUENCY 3192095000 (HZ) *** *** CALIBRATED TIMER-INTERRUPT-TO-SCHEDULER LATENCY 2688 (ns) *** *** CALIBRATED ONE SHOT SETUP TIME 2010 (ns) *** RTDM Version 0.5.0 *** RTnet 0.7.0 - built on Jul 28 2004 15:05:34 *** RTnet: initialising real-time networking RTnet: stack-mgr started RTDM: registered protocol device 2:2 RTDM: registered protocol device 17:2 8139too-rt Fast Ethernet driver 0.9.24-rt0.2 PCI: Found IRQ 11 for device 01:00.0 PCI: Sharing IRQ 11 with 00:1d.0 PCI: Sharing IRQ 11 with 00:1d.3 NVRM: loading NVIDIA Linux x86 NVIDIA Kernel Module 1.0-7174 Tue Mar 22 06:44:39 PST 2005 meminit hack PCI: Found IRQ 5 for device 02:03.0 PCI: Sharing IRQ 5 with 00:1d.1 spurious 8259A interrupt: IRQ7. usb.c: registered new driver hiddev usb.c: registered new driver hid hid-core.c: v1.8.1 Andreas Gal, Vojtech Pavlik [EMAIL PROTECTED] hid-core.c: USB HID support drivers PCI: Found IRQ 9 for device 00:1d.7 PCI: Setting latency timer of device 00:1d.7 to 64 ehci_hcd 00:1d.7: Intel Corp. 82801EB USB2 ehci_hcd 00:1d.7: irq 9, pci mem e1e15000 usb.c: new USB bus registered, assigned bus number 5 ehci_hcd 00:1d.7: ehci_start hcs_params 0x104208 dbg=1 cc=4 pcc=2 ordered !ppc ports=8 ehci_hcd 00:1d.7: ehci_start hcc_params 6871 thresh 7 uframes 1024 64 bit addr ehci_hcd 00:1d.7: capability 10001 at 68 ehci_hcd 00:1d.7: BIOS handoff succeeded ehci_hcd 00:1d.7: reset command 080012 (park)=0 ithresh=8 Periodic period=1024 Reset HALT ehci_hcd 00:1d.7: enabled 64bit PCI DMA PCI: cache line size of 128 is not supported by device 00:1d.7 ehci_hcd 00:1d.7: init command 010001 (park)=0 ithresh=1 period=1024 RUN ehci_hcd 00:1d.7: USB 2.0 enabled, EHCI 1.00, driver 2003-Jun-19/2.4 hcd.c: 00:1d.7 root hub device address 1 hub.c: port 1, portstatus 100, change 1, 12 Mb/s hub.c: port 1 connection change hub.c: port 1, portstatus 100, change 1, 12 Mb/s hub.c: port 2, portstatus 100, change 0, 12 Mb/s usb.c: kmalloc IF cfd9af00, numif 1 usb.c: new device strings: Mfr=3, Product=2, SerialNumber=1 usb.c: USB device number 1 default language ID 0x0 Manufacturer: Linux 2.4.24-rthal5 ehci_hcd Product: Intel Corp. 82801EB USB2 SerialNumber: 00:1d.7 hub.c: USB hub found hub.c: 8 ports detected hub.c: standalone hub hub.c: ganged power switching hub.c: individual port over-current protection hub.c: Single TT hub.c: TT requires at most 8 FS bit times hub.c: Port indicators are not supported hub.c: power on to power good time: 0ms hub.c: hub controller current requirement: 0mA hub.c: port removable status: hub.c: local power source is good hub.c: no over-current condition exists hub.c: enabling power on all ports usb.c: hub driver claimed interface cfd9af00 usb.c: kusbd: /sbin/hotplug add 1 ehci_hcd 00:1d.7: GetStatus port 1 status 001803 POWER sig=j CSC CONNECT
Re: [Flightgear-devel] Colditz Glider MkII
On Wed, 2005-05-25 at 17:57, Martin Spott wrote: BTW, I don't remember if these URL's have already been mentioned: http://www.pbs.org/wgbh/nova/naziprison/glider.html http://www.colditz-4c.com/glider-l.jpe I think they were mentioned before. I had already seen them as part of my researches before starting the FDM, but some readers may not, so thanks for the links anyway. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Le jeudi 26 mai 2005 09:35 +0100, Richard Bytheway a crit : -Original Message- Erik Hofman Norman Vine wrote: http://baron.flightgear.org/pipermail/flightgear-devel/2003-Se ptember/021434.html I don't see the XML files as being any different then any other source file and source code needs to be compiled. I've had this in the back of my mind ever since you brought it up, but not many people (including XML experts) seem to like binary XML. I'm still undecided about it. Erik Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. This could be transparent to the user (they simply edit the ASCII version), it simply causes the startup time to be longer the next time around, but if no changes are made then there is no time penalty. Richard This goes to an answer and an advantage for the PLAYERS. Which is not in my sense the fundamental idea we have of FGFS. I am a LINUX user i like the open access to everything. Ten years ago when i ought to use and work on windows i did not like that closed system, and was happy when LINUX went up. May be, presents windows users don't know that existing advantage. Don't go back to the DARK SIDE. Any way if a day that functionality is implemented, it must be an option. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote: Try adding --log-level=info for a possible hint, ./fgfs --lat=87 --long=28 --altitude=3 --log-level=info That's an old, well known bug. If you position fgfs exactly on the tile boundaries (*integer* lon/lat), the intersection code somehow falls through between the tiles. Try this: $ ./fgfs --lat=87.001 --long=28.001 --altitude=3 I wouldn't be surprised if someone fixed that bug within ... the next twenty years? ;-) Is fixed now in current cvs ... Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 12:01:
On Dienstag 03 Mai 2005 14:17, Melchior FRANZ wrote:
Try adding --log-level=info for a possible hint,
./fgfs --lat=87 --long=28 --altitude=3 --log-level=info
That's an old, well known bug. If you position fgfs exactly on the tile
boundaries (*integer* lon/lat), the intersection code somehow falls through
between the tiles. Try this:
$ ./fgfs --lat=87.001 --long=28.001 --altitude=3
I wouldn't be surprised if someone fixed that bug within ... the next
twenty years? ;-)
Is fixed now in current cvs ...
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m accordingly. It simply lets the old
elevation in the property system. Annoying for scripts that read out
elevation. (I work around that by adding 0.0001 now in [1]). :-(
m.
[1] http://members.aon.at/mfranz/flightgear/getelev
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m accordingly. It simply lets the old
elevation in the property system. Annoying for scripts that read out
elevation. (I work around that by adding 0.0001 now in [1]). :-(
From what you tell, this might be fixed with the change to hitlist.cxx from
today morning.
Have you retried with this recent version?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 12:29:
On Donnerstag 26 Mai 2005 12:21, Melchior FRANZ wrote:
Unfortunately, a similar bug showed up recently for *bucket* boundaries.
If you set /position/{latitude,longitude}-deg to a bucket boundary, fgfs
refuses to set /position/elevation-m accordingly.
From what you tell, this might be fixed with the change to hitlist.cxx from
today morning.
Have you retried with this recent version?
Hey! I update compile in the same minute a new cvs-log commit message comes in
if I'm at my computer. Yes, this happens with CVS/HEAD as of *now* (Thu May 26
12:36:12 CEST 2005). I had tried it as soon as I saw the fix because I had
*hoped*
that it would fix it.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FDM freeze
Just out of curiosity I removed the three tall scenery objects I had placed at Sembach, then flew around there for 30 minutes with no more ground cache errors. I think the problem comes from overflying the edge of a tall scenery object. Just a guess. Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Richard Bytheway wrote: Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. This is a very interesting approach that you present here - and probably the only one that doesn't destruct the whole idea of having human-adaptable configuration files. In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
On Donnerstag 26 Mai 2005 12:37, Melchior FRANZ wrote: Hey! I update compile in the same minute a new cvs-log commit message comes in if I'm at my computer. Yes, this happens with CVS/HEAD as of *now* (Thu May 26 12:36:12 CEST 2005). I had tried it as soon as I saw the fix because I had *hoped* that it would fix it. :) Sorry ... Can you send me a location where it does not work? I have something in my tree which could help, if the problem is at the point I expecte it to be ... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
Dave Culp wrote: Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. Here's a screenshot of the freeze: http://home.comcast.net/~davidculp2/fdm_freeze.jpg You should not do these manouvres with such an old aircraft ;-) I _might_ know a similar szenario. I thought I'd post a description last week but I held it back - until now. The effect _I_ see is that the FDM does _not_ feeze _immediately_ but instead it slows down at a very high rate and I get at least one or two more state changes. I'm able to reproduce the effect under the following circumstances: 1.) Choose the A-10fl, 2.) take off at EKOD, 3.) switch to some outside view, 4.) activate the autopilot to altitude-hold and select 800 ft, 5.) put EKSB as the first item on the list of waypoints, 6.) put EDXF as the second item on the list of waypoints. The aircraft heads towards EKSB at a constant altitude of approx. 950 (!?!?) ft. After arriving overhead EKSB the aircraft _should_ turn right to head for EDXF. The last picture I see is in the moment of having the aircraft right overhead EKSB, then I encounter a delay of about 15 sec. and the next frame I get shows the aircraft in the mid of the turn towards EDXF. With a bit of luck I get another frame about 20 sec. later. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Martin Spott writes: Richard Bytheway wrote: Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. This is a very interesting approach that you present here - and probably the only one that doesn't destruct the whole idea of having human-adaptable configuration files. In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Dropping the ASCII XML files from the distribution is jsut as likely and no less user friendly then dropping the source code files from the distribution. Just use the source Luke :-) That said this is an excellent idea. But I think that unlike C++ source binary XML 'decompiles' into ASCII easily :-) Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: Re: [Jsbsim-devel] FDM freeze due to ground cache]
Hi, On Donnerstag 26 Mai 2005 13:17, Gerard ROBIN wrote: I was in fact the first to ask for: Why that message and that Freeze ? This message is because of the fact that this is the case. Even if you can see ground there is a posibility that in floating point arithmetics the test for that can fail. Also there could be a serious problem in this area. And why that freeze: It is somehow paranoid but it shows that there is something wrong. This could either be a roundoff problem, which should be handled in some way or it could be some other problem which should be handled in a different way. As long as it is not clear to me what is going on here. I am searching for that reason ... I wonder, and i ask is it in relationship with an other problem which makes the flight uncontrolled and the CPU out of capacity ? ( that is CPU speed independent, low or high speed machine same problem ==I have several working machines ) I mean : Probably during tile loading and or dynamics sceneries, the system try to answer to: that loading, the control of the aircraft the dynamic display of everything. Because we are supposed to be in real time, one function decision, goes probably against an other function decision, correct it and so on . the system becomes unstable going into a devil loop. In short: you are talking about race conditions. I don't think that this is a race condition since scenery loading is done in a seperate thread, but hanging that scenery into the scenegraph is done in the render thread which also does the FDM computations. I get less than one fps display. So if you can recover, you are talking about a completly different problem. To me , under linux i can observe the cpu loading.It becomes crazy with hight variations, without any hope of stability again. Sorry, under Linux I have always 100% cpu usage when running flightgear ... I save the situation with the activation of Pause during a very short delay, and again the system become stable coming up in an 'heaven' situation. See above. Could we conclude with that question: Does management of sequence and priority of modules activations in a complex situation could be the cause of theses problems ? (Strange accelerations with... FDM freeze.. I don't understand what you mean. Sorry. Greetings Mathias -- Mathias Frhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Martin Spott -- Thursday 26 May 2005 13:07: In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Seconded. And then: it's *not* XML parsing that slows the startup process down so much! It's parsing two simple gzipped ASCII lists that are directly taken from X-Plane. Blowing them up to XML and then compiling them to a binary XML is pure nonsense. I'd rather go for the cache a binary representation in $FG_HOME that is re-generated whenever necessary method. Fears that this means less openness are completely unfounded and unreasonable. That's nothing else than having a binary representation in memory. The open format is still the only source of it, and every changed bit therein will take effect at the next start. But then again, the 35 seconds that I have to wait now don't kill me. :-} m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Wed, 25 May 2005 23:01:52 +0200 Frederic Bouvier wrote: No kidding, you are the first to show a convincing scenery enhancement without using photo-scenery. Generic textures are not dead ;-) At one point, I used fgsd to do what I thought was some nice work in the Washington, D.C. area as preparatory to laying out ground structures I had done or was going to do. The course of the Potomac River is about 500m from its correct location in the FG scenery as is, so I fixed that, changed material settings for various ground triangles, made some inlet areas that didn't exist in the FG scenery, etc. It looked nice, I thought. And KDCA no longer sat on a table that hovered out in the middle of nowhere like it previously did (and does now). Then a new version of the FG scenery came out, and one of its big advantages was a fix to a bug which occasionally produced sharp steps in ground elevation where the ground should slope more smoothly. This was significant because this bug had made the main runway at KDCA unusable because of a sharp step in the middle. I went with the new scenery, getting full access to the runway; but I lost the terrain changes I'd done with fgsd in the process. I haven't re-done them since, out of fear that I'd either have to throw them out again with the next FG scenery set, OR would keep them and at the very least have odd artifacts around the tile edges where one transitions from old scenery tile to the new stuff (and of course miss out on any improvements to the scenery generation algorithms that would have impacted the tile(s) in question). I think fgsd is cool, and I really enjoy playing with it; but if I had the infinite amount of free time all of us wish we had, I'd work on TerraGear drawing its info from some kind of GIS, and implementing some way (in fgsd and/or other tools) to update that info, so that fixes to the terrain could propagate upstream and be included in future scenery builds, removing the need to fix the terrain over and over and over. I know, I know, we've all talked about this before, and pretty much everyone thinks its a good idea, and no one has the time. I really really wish I did. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgporAeJM6Gm2.pgp Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Melchior FRANZ -- Thursday 26 May 2005 14:00: cache a binary representation in $FG_HOME [...] Or better even in /var/tmp/. BTW: this method isn't such a Great Idea[TM], as someone implied (and it wasn't Richard, who certainly knows that). It's rather the usual way to do things like these. sendmail does it (you have to compile the ascii files yourself), KDE does it: every config file is ASCII in good old MICROS~1 *.ini format; but behind the scenes, they are collected and compiled into a binary database by kbuildsycoca[1]. Most KDE users probably don't know that, and that's how it should be. The *rc files are still open. Nobody cares for the cached binary blob. And not many know it's internal format, although it's, of course, documented. m. [1] KDE: build system configuration cache :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear startup time
* Gerard ROBIN -- Thursday 26 May 2005 14:12: Le jeudi 26 mai 2005 à 14:00 +0200, Melchior FRANZ a écrit : * Martin Spott -- Thursday 26 May 2005 13:07: Seconded. And then: [...] Thanks Mathias And thanks Gerard for thanking Mathias as a response to my message. m. :-} ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Norman Vine wrote: Martin Spott writes: This is a very interesting approach that you present here - and probably the only one that doesn't destruct the whole idea of having human-adaptable configuration files. In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Dropping the ASCII XML files from the distribution is jsut as likely and no less user friendly then dropping the source code files from the distribution. I totally disagree. The C/C++ source code is solely for building the executable binaries. For some serious reasons the runtime configuration has been swapped out to an XML framework to enable _everyone_, including Joe Average User to adjust their local copy of FlightGear to their very special 'needs'. The distinct separation of the user-configurable part into a human readable format is one of the major achievements in the development of FlightGear over the past years. Do you really want to turn the clock back ? BTW, as nice as CWXML might be, it adds yet another library dependency to FlightGear - one of the major reason, why the use of Metakit had been abandoned in the past. Just use the source Luke :-) Yes, I do right on the track to figure how much effort it would be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC as compiler on _every_ supported Unix platform. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
On Thu, 26 May 2005 11:37:13 + (UTC), Martin wrote in message [EMAIL PROTECTED]: Dave Culp wrote: Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. Here's a screenshot of the freeze: http://home.comcast.net/~davidculp2/fdm_freeze.jpg You should not do these manouvres with such an old aircraft ;-) I _might_ know a similar szenario. I thought I'd post a description last week but I held it back - until now. The effect _I_ see is that the FDM does _not_ feeze _immediately_ but instead it slows down at a very high rate and I get at least one or two more state changes. I'm able to reproduce the effect under the following circumstances: 1.) Choose the A-10fl, 2.) take off at EKOD, 3.) switch to some outside view, 4.) activate the autopilot to altitude-hold and select 800 ft, 5.) put EKSB as the first item on the list of waypoints, 6.) put EDXF as the second item on the list of waypoints. The aircraft heads towards EKSB at a constant altitude of approx. 950 (!?!?) ft. After arriving overhead EKSB the aircraft _should_ turn right to head for EDXF. The last picture I see is in the moment of having the aircraft right overhead EKSB, then I encounter a delay of about 15 sec. and the next frame I get shows the aircraft in the mid of the turn towards EDXF. With a bit of luck I get another frame about 20 sec. later. ..what happens if you slow the simulation by 15-20 times the clock time? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Le jeudi 26 mai 2005 14:12 +0200, Gerard ROBIN a crit : Le jeudi 26 mai 2005 14:00 +0200, Melchior FRANZ a crit : * Martin Spott -- Thursday 26 May 2005 13:07: In my eyes _dropping_ ASCII XML files from the distribution should considered to be a no-go, Seconded. And then: it's *not* XML parsing that slows the startup process down so much! It's parsing two simple gzipped ASCII lists that are directly taken from X-Plane. Blowing them up to XML and then compiling them to a binary XML is pure nonsense. I'd rather go for the cache a binary representation in $FG_HOME that is re-generated whenever necessary method. Fears that this means less openness are completely unfounded and unreasonable. That's nothing else than having a binary representation in memory. The open format is still the only source of it, and every changed bit therein will take effect at the next start. But then again, the 35 seconds that I have to wait now don't kill me. :-} m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Thanks Mathias Gerard I was meaning == Thanks Melchior ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
Arnt Karlsen wrote: ..what happens if you slow the simulation by 15-20 times the clock time? Slowing down might not be reasonable as I'm currently getting frame rates in the 15-20 fps region Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
Hi,
On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote:
BTW: the scenery doesn't show anything unusual and suspicious. Not even the
familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works
flawlessly.
Hmm, that did not for me ...
But with the attached patch it did, at least for me ... ?!!
I have something in my tree which could help, if the problem is at the
point I expecte it to be ...
Cool. (It's not that I'm unwilling to find the bug myself. It just got in
my way when I was working on something else, and I didn't want to get
distracted by that. A workaround was preferable at that time.)
Does this attached patch help for you?
Greetings
Mathias
--
Mathias Fröhlich, email: [EMAIL PROTECTED]
Index: src/Scenery/hitlist.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Scenery/hitlist.cxx,v
retrieving revision 1.11
diff -u -r1.11 hitlist.cxx
--- src/Scenery/hitlist.cxx 26 May 2005 08:13:06 - 1.11
+++ src/Scenery/hitlist.cxx 26 May 2005 13:45:38 -
@@ -124,20 +124,23 @@
{
sgdVec3 dif;
+// Some tolerance in meters we accept a point to be outside of the triangle
+// and still return that it is inside.
+SGDfloat eps = 1e-4;
SGDfloat min, max;
// punt if outside bouding cube
SG_MIN_MAX3 ( min, max, tri[0][0], tri[1][0], tri[2][0] );
-if( (point[0] min) || (point[0] max) )
+if( (point[0] min - eps) || (point[0] max + eps) )
return false;
dif[0] = max - min;
SG_MIN_MAX3 ( min, max, tri[0][1], tri[1][1], tri[2][1] );
-if( (point[1] min) || (point[1] max) )
+if( (point[1] min - eps) || (point[1] max + eps) )
return false;
dif[1] = max - min;
SG_MIN_MAX3 ( min, max, tri[0][2], tri[1][2], tri[2][2] );
-if( (point[2] min) || (point[2] max) )
+if( (point[2] min - eps) || (point[2] max + eps) )
return false;
dif[2] = max - min;
@@ -181,27 +184,30 @@
}
// check if intersection point is on the same side of p1 - p2 as p3
-SGDfloat tmp = (y2 - y3) / (x2 - x3);
-int side1 = SG_SIGN (tmp * (rx - x3) + y3 - ry);
-int side2 = SG_SIGN (tmp * (x1 - x3) + y3 - y1);
+SGDfloat tmp = (y2 - y3);
+SGDfloat tmpn = (x2 - x3);
+int side1 = SG_SIGN (tmp * (rx - x3) + (y3 - ry) * tmpn);
+int side2 = SG_SIGN (tmp * (x1 - x3) + (y3 - side1*eps - y1) * tmpn);
if ( side1 != side2 ) {
// printf(failed side 1 check\n);
return false;
}
// check if intersection point is on correct side of p2 - p3 as p1
-tmp = (y3 - ry) / (x3 - rx);
-side1 = SG_SIGN (tmp * (x2 - rx) + ry - y2);
-side2 = SG_SIGN (tmp * (x1 - rx) + ry - y1);
+tmp = (y3 - ry);
+tmpn = (x3 - rx);
+side1 = SG_SIGN (tmp * (x2 - rx) + (ry - y2) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
if ( side1 != side2 ) {
// printf(failed side 2 check\n);
return false;
}
// check if intersection point is on correct side of p1 - p3 as p2
-tmp = (y2 - ry) / (x2 - rx);
-side1 = SG_SIGN (tmp * (x3 - rx) + ry - y3);
-side2 = SG_SIGN (tmp * (x1 - rx) + ry - y1);
+tmp = (y2 - ry);
+tmpn = (x2 - rx);
+side1 = SG_SIGN (tmp * (x3 - rx) + (ry - y3) * tmpn);
+side2 = SG_SIGN (tmp * (x1 - rx) + (ry - side1*eps - y1) * tmpn);
if ( side1 != side2 ) {
// printf(failed side 3 check\n);
return false;
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Speed of CVS version and flying in the Himalayas
* Mathias Fröhlich -- Thursday 26 May 2005 15:50: On Donnerstag 26 Mai 2005 15:10, Melchior FRANZ wrote: BTW: the scenery doesn't show anything unusual and suspicious. Not even the familiar crack line. And starting fgfs with --lon=16.5 --lat=48.5833 works flawlessly. Hmm, that did not for me ... But with the attached patch it did, at least for me ... ?!! Dang. You got me. I lied. I hadn't used the correct coords when I tried that (whereas all other tests were correct!). :-) Right. This hangs completely. I haven't seen that before. No wonder that the telnet method doesn't deliver a useful elevation. I have something in my tree which could help, if the problem is at the point I expecte it to be ... Cool. (It's not that I'm unwilling to find the bug myself. It just got in my way when I was working on something else, and I didn't want to get distracted by that. A workaround was preferable at that time.) Does this attached patch help for you? And, yes. This solves the ugly hang. But I do still not get a correct elevation! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mountainous areas
I have been trying to build some scenery over some pretty mountainous areas in California (w117n35) using SRTM 1 arcsec data. I end up with some very strange looking scenery with HUGE cliffs. I wanted to compare the FG base scenery from the downloads but when I tried to unpack the data ended up with the following error: Under cygwin: gunzip w120n30.tgz | tar xvf - w120n30/ w120n30/w116n30/ w120n30/w116n30/1056256.btg.gz w120n30/w116n30/1056256.stg w120n30/w116n30/1056258.btg.gz tar: Skipping to next header tar: Archive contains obsolescent base-64 headers gunzip: stdin: invalid compressed data --format violated ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: RE: [Flightgear-devel] Scenery size constraints
Erik Hofman wrote: Harald JOHNSEN wrote: Alberico, James F wrote: Hi, I have been tracking down the cause of an FGFS access violation that occurs when attempting to use 1-arcsec scenery data for a tile generated in TerraGear to have 4 nodes. Granted, this may be extremely ambitious from a performance standpoint, and may prove to be completely infeasible. However, I am very interested in knowing the current limits and pushing hard on them. Hi Jim, It good to see some big names showing up on the list. This might give the project a boost to get to the next level. You certainly mean Harald, not me, unless you are commenting on the ugly format of my name here. :-) What I think I've learned so far from debugging: ... ... At this point Curtis is the one who is most involved in these things. He is attending the MathWorks International Aerospace and Defense Conference 2005 and will be back tomorrow. It might be best to send him a private copy of your mail also. That's a good idea. Thanks. Harald JOHNSEN wrote: I think that the only side effect will be that your new binary will be incompatible with current scenario files, perhaps that changing short to unsigned short could be enought. Erik Hofman wrote: Curtis already mentioned he wanted to change the layout of the tiles which probably breaks backward compatibility. So if it would be necessary this change could be adopted as well. Thanks, Harald and Erik. An unsigned short for that item would help me for my specific purpose. Curt and others can determine which direction to take the project. A key question will be whether 65k or even 32k nodes far exceeds any reasonable performance expectations for the foreseeable future. Jim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Scenery size constraints
* Alberico, James F -- Thursday 26 May 2005 16:42: Erik Hofman wrote: Harald JOHNSEN wrote: Alberico, James F wrote: Hi Jim, It good to see some big names showing up on the list. This might give the project a boost to get to the next level. You certainly mean Harald, not me, unless you are commenting on the ugly format of my name here. :-) I'm sure he meant boeing.com (hey, Stacie was first!). Now with Boeing and Sikorsky on board, where is EADS/Airbus? Come on! We know you are here! And Fokker!? And *cough* Diamond *cough* ... ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Frederic Bouvier wrote: BTW : Martin contributed an IRIX build Well, this was made possible by _your_ switch from GTS to GCAL - I never managed to build GTS on IRIX Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
Dave Culp wrote: Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. My guess is this is a crash due to weird collision detection in the ground or gear code. The last I checked, JSBSim and YASim had the same silently-freeze-on-crash behavior. We should probably come up with some kind of standard way for the FDM to signal to the rest of the simulator that it has detected a collision and stopped. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
Richard Bytheway wrote: Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. Sorry, but that sounds dumb. Wouldn't it be a better idea to try to figure out why it is slow in the first place before making all our configuration files non-editable? We really don't have that much XML to parse at startup; if it's really a performance limitation, then it's because we're doing something slow with our XML parsing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Wednesday 25 May 2005 23:31, Frederic Bouvier wrote: Gerard ROBIN a crit : Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred What about offering static binary builds of FGSD for linux with everything included? This might increase the package size but is very easy to use. Best Regards, Oliver C. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FDM freeze
Le jeudi 26 mai 2005 09:15 -0700, Andy Ross a crit : Dave Culp wrote: Lately I've been flying around German terrain and have been getting an FDM freeze at seemingly random occasions after flying for ten minutes or so. My guess is this is a crash due to weird collision detection in the ground or gear code. The last I checked, JSBSim and YASim had the same silently-freeze-on-crash behavior. We should probably come up with some kind of standard way for the FDM to signal to the rest of the simulator that it has detected a collision and stopped. Andy don't forget the message error : FGInterface is beeing called without scenery below the aircraft Which not the case with a crash. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Oliver C. wrote: What about offering static binary builds of FGSD for linux with everything included? I'll go and get one until weekend, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] JSBSim/FGTable.cpp exception
I was getting a access exception in FGTable.cpp line at line 267. I belive I have tracked it down to values not being initialized in the constructor for the 3D tables. Fix: Index: FGTable.cpp===RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/FGTable.cpp,vretrieving revision 1.6diff -r1.6 FGTable.cpp69a70 lastRowIndex=lastColumnIndex=2; I will cross post this with the FG devel and JSBSim devel lists. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 04:32 pm, Andy Ross wrote: Would it be possible to have a compiled form stroed on disk, which is automatically regenerated on startup of FGFS based on rules similar to make. If the ASCII version is newer than the compiled version, rebuild the compiled version. Sorry, but that sounds dumb. Wouldn't it be a better idea to try to figure out why it is slow in the first place before making all our configuration files non-editable? How so? Python does it by compiling a new *.pyc everytime there is a change to the associated *.py file. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Scenery size constraints
Melchior FRANZ wrote: * Alberico, James F -- Thursday 26 May 2005 16:42: You certainly mean Harald, not me, unless you are commenting on the ugly format of my name here. :-) I'm sure he meant boeing.com (hey, Stacie was first!). Now with Boeing and Yep. Sikorsky on board, where is EADS/Airbus? Come on! We know you are here! And Fokker!? And *cough* Diamond *cough* ... ;-) Fokker? I'm working on that. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear startup time
On May 26, 2005 01:43 pm, Ampere K. Hardraade wrote: How so? Python does it by compiling a new *.pyc everytime there is a change to the associated *.py file. Ampere Beside, you don't compile Flightgear everytime you run it. You compile Flightgear when there is a change in the source. Compiling scripts on a as-needed basis would be similar, if not the same. Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 02:50, Geoff Reidy wrote: Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] working with the property tree
On 5/26/05, Erik Hofman [EMAIL PROTECTED] wrote: bass pumped wrote: I need to learn how to work with the property tree in flightgear. Could someone refer me to material that might be helpful? This isn't much information. What exactly do you want to do with the property tree, or are you just looking for a short description? You could start by taking a look at README.introduction, README.IO and README.properties in the Docs directory of the base package. Erik Been reading that. What I need to do is to create a separate area in the property tree to map user inputs and send the relevant ones (and the current state vector of the aircraft) out for processing to a different computer. The other computer would then return two modified inputs, which along with the remaining user inputs, would have to be again mapped in an appropriate manner to be sent into flightgear for processing. Any ideas on how I could do this? Thanks! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Martin Spott wrote: I'll go and get one until weekend, Aaah, don't bet on that. I managed to built all prerequisites but now I get an internal compiler error when compiling FGSD sources - and I don't have a different platform/compiler available :-/ Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Le jeudi 26 mai 2005 18:56 +, Martin Spott a crit : Martin Spott wrote: I'll go and get one until weekend, Aaah, don't bet on that. I managed to built all prerequisites but now I get an internal compiler error when compiling FGSD sources - and I don't have a different platform/compiler available :-/ Martin. So i do: I tried again and again, I have send a message to fgsd-devel mailing list about compilation errors. Waiting for an answer if anybody on that side knows Linux. -- Gerard -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
On Thursday 26 May 2005 19:56, Lee Elliott wrote: On Thursday 26 May 2005 02:50, Geoff Reidy wrote: Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
On Thursday 26 May 2005 19:56, Martin Spott wrote: Aaah, don't bet on that. I managed to built all prerequisites but now I get an internal compiler error when compiling FGSD sources - and I don't have a different platform/compiler available :-/ This stopped me too. After fiddling with it for ages, I finally gave in and read the README. Quoted directly... First, the bad news : g++ v3.3.x is unable to compile fgsd correctly. It produces internal Compiler Errors Bah. Whoever reads these things first, anyway? :-) I also tried the win32 version under WINE which works without crashing, but is unusable due to some problem with the ordering of layers in the interface, the green background covers everything. AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
AJ MacLeod (email lists) wrote: This stopped me too. After fiddling with it for ages, I finally gave in and read the README. Quoted directly... First, the bad news : g++ v3.3.x is unable to compile fgsd correctly. It produces internal Compiler Errors Bah. Whoever reads these things first, anyway? :-) Well, I did - for the CGAL part, but I didn't remember the GCC stuff because my first attempt was with a MIPSpro compiler on IRIX, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. LeeE As far as i remember 6629 does not compile on Linux greater than 2.9. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Potential startup speed fix
Vivian Meazza wrote:
Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for
a brew a coffee - and that's on a pretty powerful machine.
Time from execution to fade in of the cockpit display is about 10
seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this
down.
One issue that had been discovered earlier is that an AI-related patch
to the the airport loading code in February causes the startup routine
to try to load a rwyuse.xml and parking.xml file in every one of 24597
potential directories under $FG_ROOT/Aiports/AI.
Attached is a patch that pre-reads the directory contents ahead of
time (currently that is a list of length zero) to avoid having to hit
the kernel (twice!) for every airport.
Under Linux, this doesn't provide much speedup. But Windows (and
especially the cygwin libraries) has a somewhat less robust I/O system
in the face of many tiny operations. Hopefully it will help there.
Can someone on each of cygwin, mingw and/or MSVC try this out and see
if it helps?
Unfortunately, because there is no actual parking/runway AI data in
the base package, much of this is currently dead code that cannot be
tested. I can't promise I didn't break anything, because I have no
way of knowing whether it worked in the first place. :)
Andy
Index: src/Airports/simple.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Airports/simple.hxx,v
retrieving revision 1.12
diff -u -r1.12 simple.hxx
--- src/Airports/simple.hxx 10 Feb 2005 09:01:51 - 1.12
+++ src/Airports/simple.hxx 26 May 2005 20:47:33 -
@@ -42,10 +42,12 @@
#include STL_STRING
#include map
+#include set
#include vector
SG_USING_STD(string);
SG_USING_STD(map);
+SG_USING_STD(set);
SG_USING_STD(vector);
typedef vectorstring stringVec;
@@ -306,11 +308,12 @@
airport_map airports_by_id;
airport_list airports_array;
+set string ai_dirs;
public:
// Constructor (new)
-FGAirportList() {}
+FGAirportList();
// Destructor
~FGAirportList();
Index: src/Airports/simple.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Airports/simple.cxx,v
retrieving revision 1.17
diff -u -r1.17 simple.cxx
--- src/Airports/simple.cxx 25 Feb 2005 19:41:53 - 1.17
+++ src/Airports/simple.cxx 26 May 2005 20:47:33 -
@@ -1149,6 +1149,26 @@
* FGAirportList
*/
+// Populates a list of subdirectories of $FG_ROOT/Airports/AI so that
+// the add() method doesn't have to try opening 2 XML files in each of
+// thousands of non-existent directories. FIXME: should probably add
+// code to free this list after parsing of apt.dat is finished;
+// non-issue at the moment, however, as there are no AI subdirectories
+// in the base package.
+FGAirportList::FGAirportList()
+{
+ulDir* d;
+ulDirEnt* dent;
+SGPath aid( globals-get_fg_root() );
+aid.append( /Airports/AI );
+if((d = ulOpenDir(aid.c_str())) == NULL)
+return;
+while((dent = ulReadDir(d)) != NULL) {
+cerr Dent: dent-d_name; // DEBUG
+ai_dirs.insert(dent-d_name);
+}
+ulCloseDir(d);
+}
// add an entry to the list
void FGAirportList::add( const string id, const double longitude,
@@ -1172,7 +1192,8 @@
rwyPrefPath.append( /Airports/AI/ );
rwyPrefPath.append(id);
rwyPrefPath.append(rwyuse.xml);
-if (parkpath.exists())
+if (ai_dirs.find(parkpath.str()) != ai_dirs.end()
+ parkpath.exists())
{
try {
readXML(parkpath.str(),a);
@@ -1181,7 +1202,8 @@
//cerr unable to read parkpath.str() endl;
}
}
-if (rwyPrefPath.exists())
+if (ai_dirs.find(rwyPrefPath.str()) != ai_dirs.end()
+ rwyPrefPath.exists())
{
try {
readXML(rwyPrefPath.str(), rwyPrefs);
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Andy Ross wrote : Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? It halves the airport and nav loading time ( 9 - 5 s ) so the total loading time goes from 23s to 19s on my Athlon64 3400+ This is compiled with MSVC 7.1 -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
Andy Ross Vivian Meazza wrote: Only a minute eh? Under Cygwin cvs takes nearly 5 minutes - time for a brew a coffee - and that's on a pretty powerful machine. Time from execution to fade in of the cockpit display is about 10 seconds on my laptop (1.8GHz Athlon64). I started trying to hunt this down. One issue that had been discovered earlier is that an AI-related patch to the the airport loading code in February causes the startup routine to try to load a rwyuse.xml and parking.xml file in every one of 24597 potential directories under $FG_ROOT/Aiports/AI. Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) I'll test it in Cygwin tomorrow: I don't have time tonight. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Anyone likes helping with italian scenery?
Oliver C. a crit : On Wednesday 25 May 2005 23:31, Frederic Bouvier wrote: Gerard ROBIN a crit : Wonderfull. You where using FGSD, does it mean you are working on windows. because on the linux side i could never make a compilation of that program. It is a long time ago i wondered to make sceneries of France in Provence. It is tricky but doable. Look at the release notes of version 0.3.0 on sourceforge ( click on the version in the file page ) BTW : Martin contributed an IRIX build -Fred What about offering static binary builds of FGSD for linux with everything included? This might increase the package size but is very easy to use. I found that there are more dynamic libraries under Linux than under Windows, and that they are distribution dependant. If you can compile something statically, I am ready to put it on sourceforge for download. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mountainous areas
Did you download this file in binary mode ? The basic windows ftp client is in ascii when started and corrupt binary files with line endings conversion. -Fred Corrubia, Stacie K wrote : I have been trying to build some scenery over some pretty mountainous areas in California (w117n35) using SRTM 1 arcsec data. I end up with some very strange looking scenery with HUGE cliffs. I wanted to compare the FG base scenery from the downloads but when I tried to unpack the data ended up with the following error: Under cygwin: gunzip w120n30.tgz | tar xvf - w120n30/ w120n30/w116n30/ w120n30/w116n30/1056256.btg.gz w120n30/w116n30/1056256.stg w120n30/w116n30/1056258.btg.gz tar: Skipping to next header tar: Archive contains obsolescent base-64 headers gunzip: stdin: invalid compressed data --format violated ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: On Thursday 26 May 2005 19:56, Lee Elliott wrote: On Thursday 26 May 2005 02:50, Geoff Reidy wrote: Lee Elliott wrote: I'm having a strange problem that may be linked to this. Now when I start at KSFO, looking forward, I'm getting 1fps. Same with the heli chase views. If I switch to the tower it's the same until I start zooming in. At around 15 deg fov the frame rate jumps up to around 25-30 fps. Switch back to the chase view and it's back down to 1 fps. Incidentally, the a/c I'm checking with has slowly revolving props so I can see the changes in frame rate very clearly. Anyway, back to the chase view and rotate the view around using shift and the num-pad. Shift-9 is fine - 20 fps, shift-6 1 fps, shift-3 20 fps. From 2 through to 8 are all 1 fps. Try KJFK. Here only one view gives problems (can't remember exactly which one now though). It's also apparent while using the mouse to change the view. Back to KSFO, tower view and try a take off - 20 fps. Try chase view and 1 fps until just after the last of the white blocks on the runway (sorry, don't know their proper name) when it jumps to 20 fps. It'll also happen while I'm flying - I flew out over downtown SFO and was heading back to KSFO at 20 fps but then it dropped back down to 1fps. I'm guessing that it's due to a scenery or random object problem, as it also happened at KJFK where there're no custom scenery objects, but I can't identify what it can be. Any ideas anyone? FG is pretty unusable for me atm. FWIW, glxgears gives 3900 fps here. LeeE I get this problem also with any of the Nvidia Linux 7xxx drivers. Other programs like torcs still run fine, only fgfs seems to be affected. I used to get 30 to 40 fps at KSFO. If I look down at the cockpit (still at KSFO) or up at the sky or I look to the right more than about 15 degrees or to the left at about 90 degrees it runs at normal speed. Look straight ahead and I get about 1 frame every five seconds. Same result at KEMT. Have looked through the nvidia forums but haven't seen anyone complain of problems like this. Geoff Thanks for that Geoff. I've already got a couple of older drivers and I believe that all the old drivers can still be downloaded from the archive at nVidia. I'll give it a go here and report back. LeeE I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. LeeE 2.6.11 and also can't build the older drivers, as I since found out :( Just updated from 2.6.9 where only = 6629 worked properly with fgfs. Debian unstable. Geoff ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Strange acceleration issues with 9.8---possibly
* Geoff Reidy -- Thursday 26 May 2005 23:36: 2.6.11 and also can't build the older drivers, as I since found out :( Just updated from 2.6.9 where only = 6629 worked properly with fgfs. Debian unstable. I compile and use 6629 with Linux 2.6.11.7 without problems. You only need to patch the driver source with an official nvidia patch: http://www.nvnews.net/vbulletin/showthread.php?t=46676 Later nvidia drivers (7???) were unstable and completely useless for me. m. PS: please, no fullquotes! Only quote what you are directly referring to. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Strange acceleration issues with 9.8---possibly
Lee Elliott wrote: I have three version here 7174, 7167 6629. Both of the 7nnn exhibit the same problem and 6629 won't compile here. Drat! Which kernel version are you using? I'm on 2.6.11 here. Check the forum - there's a patch on there for 6629 with 2.6.11. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Crash detection (was FDM freeze)
We should probably come up
with some kind of standard way for the FDM to signal to the rest of
the simulator that it has detected a collision and stopped.
I agree it's time for crash detection and handling. I just added a basic
version to my OV-10 sim (can't have public users wallowing around
underground, wondering what to do now :) One decision to make is what the
handler should do once a crash is detected. I have it calling the reinit
code in order to reset the sim to the starting position (below), while others
may prefer to have the sim close after a crash, or perhaps display a
crash-splash screen and/or console warning.
// force a sim reset if crashed (altitude AGL 0)
if (get_Altitude_AGL() 0.0) {
SGPropertyNode* node = fgGetNode(/sim/presets, true);
globals-get_commands()-execute(old-reinit-dialog, node);
}
The above went in JSBSim.cxx because I couldn't figure out where to put it so
that all FDM's could have the same crash detector/handler.
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash detection (was FDM freeze)
Dave Culp wrote: One decision to make is what the handler should do once a crash is detected. I have it calling the reinit code in order to reset the sim to the starting position (below), while others may prefer to have the sim close after a crash, or perhaps display a crash-splash screen and/or console warning. YASim currently sets a /sim/crashed property. Melchior's bo105 stuff uses this as an animation input, but you could also write a Nasal script or whatnot to poll for changes. If you want to do push-mode handling with an FGCommand and make it settable by the user, you can have the command call (or be) a Nasal script that can be assigned by the user (e.g. globals.crashHandler = myFunction). Or have it indirect through another FGCommand binding found in the property tree, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 3D view goes away by itself
I have a cockpit view system set up for the OV-10 sim that uses a 2D forward
view and 3D side views (screenshot :
http://home.comcast.net/~davidculp2/2D_3D_views.jpg
It's controlled by some nasal scripts I bound to the arrow keys. Here are the
up(forward) and left bindings:
key n=356
nameLeft arrow/name
descLook left./desc
binding
commandnasal/command
script
node = props.globals.getNode(/sim/current-view);
if(node.getChild(view-number).getValue() == 0) {
setprop(/sim/current-view/heading-offset-deg,
getprop(/sim/view/config/left-direction-deg));
node.getChild(internal).setBoolValue(1);
node.getChild(x-offset-m).setDoubleValue(0.0);
node.getChild(y-offset-m).setDoubleValue(1.1);
node.getChild(z-offset-m).setDoubleValue(-1.25);
node.getChild(pitch-offset-deg).setDoubleValue(0.0);
}
/script
/binding
/key
key n=357
nameUp arrow/name
descLook forward./desc
binding
commandnasal/command
script
node = props.globals.getNode(/sim/current-view);
if(node.getChild(view-number).getValue() == 0) {
setprop(/sim/current-view/heading-offset-deg,
getprop(/sim/view/config/front-direction-deg));
node.getChild(internal).setBoolValue(0);
node.getChild(x-offset-m).setDoubleValue(0.0);
node.getChild(y-offset-m).setDoubleValue(0.0);
node.getChild(z-offset-m).setDoubleValue(0.0);
node.getChild(pitch-offset-deg).setDoubleValue(-10.0);
}
/script
/binding
/key
It works fine on the ground, but about 10 seconds after takeoff the 3D side
views of the aircraft's engine/wing go away and never come back. I check
through the property browser and all the values look unchanged. It seems
like the internal boolean value must have changed, but the property browser
does not indicate a change (even after a refresh of course).
Any idea what causes the view to change by itself after takeoff?
Thanks,
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Strange acceleration issues with 9.8---possibly
Melchior FRANZ wrote: I compile and use 6629 with Linux 2.6.11.7 without problems. You only need to patch the driver source with an official nvidia patch: http://www.nvnews.net/vbulletin/showthread.php?t=46676 Thanks, will give that a go. PS: please, no fullquotes! Only quote what you are directly referring to. Sorry bout that! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Crash detection (was FDM freeze)
If you want to do push-mode handling with an FGCommand and make it settable by the user, you can have the command call (or be) a Nasal script that can be assigned by the user (e.g. globals.crashHandler = myFunction). Or have it indirect through another FGCommand binding found in the property tree, etc... Which reminds me, I'm using the command old-reinit-dialog in my crash handler, but I can't find where this is defined. It's not in FGCommand, so I assume it's a nasal script? I'm not sure what node should be provided as the second parameter. I'm using /sim/presets, is that what's expected? I like the idea of a global crash handler script, but I don't know enough about nasal to write one. How would it be called from within the code? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: FlightGear startup time
Martin Spott writes: Norman Vine wrote: Just use the source Luke :-) Yes, I do right on the track to figure how much effort it would be to 'port' CWXML to IRIX/MIPSpro. Apparently they rely on having GCC as compiler on _every_ supported Unix platform. You mean gcc isn't supported on IRIX ?? Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] More startup speed work
Here's another startup speed patch (against plib this time) for
windows users to try.
The plib loader for the RGB texture format wants to do piecewise I/O
on the file. It will repeatedly seek to the beginning of a scan line
in the image, then read, then seek, etc... Because of the color
separation in the image format, this adds up to *thousands* of I/O
syscalls per texture.
Even worse, (under linux at least, although it's likely that all
platforms have similar behavior) the C library's fread()
implementation (1) buffers I/O by trying to read a 4k page at a time,
and (2) flushes this buffer when you do a seek. So the reader ends up
reading many parts of the file several times (about a 3x overhead on
the file I looked at).
So attached is a patch against the plib loader that reads the whole
file as a single chunk. In combination with the airport data fix,
this has reduced the number of system calls during startup by about
90%. Hopefully this will help the cygwin users out there.
Under linux, again, this doesn't change much. I see at best about a
6% increase over the code in CVS. Linux syscalls are very fast. :)
A final note: who else knows that there are *two* parsers for the RGB
image file format linked into the FlightGear binary? One is this one
from plib; the other is in SimGear, and is used (as far as I can see)
only for the splash screen texture. They appear to be descended from
the same code; is there any reason we shouldn't remove the one in
SimGear?
Anyway, let me know if this produces any appreciable speedup under
windows, and we can start the, ahem, bureacratic process of getting
this into plib. :)
Andy
Index: src/ssg/ssgLoadSGI.cxx
===
RCS file: /cvsroot/plib/plib/src/ssg/ssgLoadSGI.cxx,v
retrieving revision 1.17
diff -u -r1.17 ssgLoadSGI.cxx
--- src/ssg/ssgLoadSGI.cxx 14 Mar 2004 11:26:56 - 1.17
+++ src/ssg/ssgLoadSGI.cxx 27 May 2005 00:42:21 -
@@ -60,7 +60,19 @@
int isSwapped;
unsigned char *rle_temp;
bool loadSGI_bool;
+ char *image_buf;
+ int seek_pos;
+ // This code was originally written to do piecewise I/O on the input
+ // file, but the number of syscalls involved caused performance
+ // problems in FlightGear on windows. These functions mimic the
+ // original fseek/fread interface but do the actual work from a
+ // single buffer.
+ void doSeek(int pos) { seek_pos = pos; }
+ void doRead(void* buf, int sz) {
+memcpy(buf, image_buf+seek_pos, sz);
+seek_pos += sz;
+ }
ssgSGIHeader () ;
ssgSGIHeader(const char *fname, ssgTextureInfo* info );
@@ -159,14 +171,14 @@
unsigned char ssgSGIHeader::readByte ()
{
unsigned char x ;
- fread ( x, sizeof(unsigned char), 1, image_fd ) ;
+ doRead ( x, sizeof(unsigned char) );
return x ;
}
unsigned short ssgSGIHeader::readShort ()
{
unsigned short x ;
- fread ( x, sizeof(unsigned short), 1, image_fd ) ;
+ doRead ( x, sizeof(unsigned short) );
swab_short ( x ) ;
return x ;
}
@@ -174,7 +186,7 @@
unsigned int ssgSGIHeader::readInt ()
{
unsigned int x ;
- fread ( x, sizeof(unsigned int), 1, image_fd ) ;
+ doRead ( x, sizeof(unsigned int) );
swab_int ( x ) ;
return x ;
}
@@ -185,7 +197,7 @@
if ( y = ysize ) y = ysize - 1 ;
if ( z = zsize ) z = zsize - 1 ;
- fseek ( image_fd, start [ z * ysize + y ], SEEK_SET ) ;
+ doSeek ( start [ z * ysize + y ] ) ;
if ( type == SGI_IMG_RLE )
{
@@ -193,7 +205,7 @@
unsigned char *bufp = buf ;
int length = leng [ z * ysize + y ];
-fread ( rle_temp, 1, length, image_fd ) ;
+doRead ( rle_temp, length );
unsigned char pixel, count ;
@@ -221,7 +233,8 @@
}
}
else
-fread ( buf, 1, xsize, image_fd ) ;
+//fread ( buf, 1, xsize, image_fd ) ;
+doRead ( buf, xsize ) ;
}
@@ -256,6 +269,8 @@
leng = NULL ;
rle_temp = NULL ;
image_fd = NULL ;
+ image_buf = 0;
+ seek_pos = 0;
}
ssgSGIHeader::ssgSGIHeader ( const char *fname, ssgTextureInfo* info )
@@ -264,6 +279,8 @@
start = NULL ;
leng = NULL ;
+ image_buf = 0;
+ seek_pos = 0;
bool success=openFile(fname);
@@ -374,6 +391,8 @@
if (image_fd != NULL)
fclose(image_fd);
+
+ delete[] image_buf;
}
@@ -451,12 +470,19 @@
return false ;
}
+ fseek(image_fd, 0, SEEK_END);
+ unsigned int sz = ftell(image_fd);
+ fseek(image_fd, 0, SEEK_SET);
+ image_buf = new char[sz];
+ if(fread(image_buf, 1, sz, image_fd) != sz)
+return false;
+
sgihdr - readHeader () ;
if ( sgihdr - type == SGI_IMG_RLE )
{
-fread ( sgihdr-start, sizeof (unsigned int), sgihdr-tablen, image_fd ) ;
-fread ( sgihdr-leng , sizeof (int), sgihdr-tablen, image_fd ) ;
+doRead ( sgihdr-start, sizeof (unsigned int) * sgihdr-tablen ) ;
+doRead ( sgihdr-leng , sizeof (int) * sgihdr-tablen ) ;
swab_int_array ( (int *) sgihdr-start, sgihdr-tablen ) ;
swab_int_array
RE: [Flightgear-devel] More startup speed work
Andy Ross writes: Here's another startup speed patch (against plib this time) for windows users to try. Nice one Andy :-) Anyway, let me know if this produces any appreciable speedup under windows, and we can start the, ahem, bureacratic process of getting this into plib. :) submit the patch I will see that it gets applied Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D view goes away by itself
Hmmm. I have something similar that works, but I don't see the important
difference. I copied/modifed stepView() to be a stepCockpitView().
It does an explicit
setprop(/sim/current-view/view-number, 0);
which I believe forces a copyToCurrent() and an update(),
but I'm not sure if that is the reason it works.
The internal flag is set for each defined view in the constructor and the
view manager
copies the flag from the currently used view in copyToCurrent(). Is there
any chance the
node.getChild(view-number).getValue() == 0 is lying, .e.g.
returning a zero when it cannot find a value?
For reference, here is what I use and it seems to work:
In view.nas
##
# Handler. Step to the next in cockpit view.
#
# This assumes the cockpit is view 0
stepCockpitView = func {
# switch to cockpit view
setprop(/sim/current-view/view-number, 0);
# determine the current cockpit view number
curr = getprop(/sim/view/cockpit-view-number);
cviews = props.globals.getNode(/sim/view).getChildren(cockpit-view);
curr = curr + arg[0];
if (curr 0){ curr = size(cviews) - 1; }
elsif(curr = size(cviews)) { curr = 0; }
setprop(/sim/current-view/goal-heading-offset-deg,
cviews[curr].getNode(heading).getValue());
setprop(/sim/view/cockpit-view-number, curr);
# And pop up a nice reminder
gui.popupTip( cviews[curr].getNode(name).getValue());
}
In preferences.xml
view
nameInteranl View/name
typelookfrom/type
internal type=booltrue/internal
config
from-model type=booltrue/from-model
from-model-idx type=int0/from-model-idx
ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m
default-field-of-view-deg
type=double55.0/default-field-of-view-deg
default-pitch-deg type=double0/default-pitch-deg
default-heading-deg type=double0/default-heading-deg
front-direction-deg type=double0/front-direction-deg
front-left-direction-deg type=double45/front-left-direction-deg
left-direction-deg type=double90/left-direction-deg
back-left-direction-deg type=double135/back-left-direction-deg
back-direction-deg type=double180/back-direction-deg
back-right-direction-deg type=double225/back-right-direction-deg
right-direction-deg type=double270/right-direction-deg
front-right-direction-deg
type=double315/front-right-direction-deg
x-offset-m type=double0/x-offset-m
y-offset-m type=double0.8/y-offset-m
z-offset-m type=double2.0/z-offset-m
/config
cockpit-view-number type=int0/cockpit-view-number
cockpit-number-views type=int4/cockpit-number-views
cockpit-view
nameFront/name
heading type=double0/heading
/cockpit-view
cockpit-view
nameFront Right/name
heading type=double315/heading
/cockpit-view
cockpit-view
nameRear/name
heading type=double180/heading
/cockpit-view
cockpit-view
nameFront Left/name
heading type=double45/heading
/cockpit-view
/view
In keyboard.xml
key n=86
nameV/name
descScroll through cockpit views./desc
binding
commandnasal/command
scriptview.stepCockpitView(1)/script
/binding
/key
- Original Message -
From: Dave Culp [EMAIL PROTECTED]
To: FlightGear developers discussions flightgear-devel@flightgear.org
Sent: Thursday, May 26, 2005 4:19 PM
Subject: [Flightgear-devel] 3D view goes away by itself
[ snip ]
It works fine on the ground, but about 10 seconds after takeoff the 3D
side
views of the aircraft's engine/wing go away and never come back. I check
through the property browser and all the values look unchanged. It seems
like the internal boolean value must have changed, but the property
browser
does not indicate a change (even after a refresh of course).
Any idea what causes the view to change by itself after takeoff?
Thanks,
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Strange acceleration issues with 9.8---possibly
Melchior FRANZ wrote: I compile and use 6629 with Linux 2.6.11.7 without problems. You only need to patch the driver source with an official nvidia patch: http://www.nvnews.net/vbulletin/showthread.php?t=46676 OK that's fixed my issues, thanks Melchior! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D view goes away by itself
Hmmm,
After a few feet of altitude, FG changes the default near clip plane to
be further away from the viewer. The 3d aircraft models are drawn with
different view parameters so this shouldn't be a problem ... but maybe
somehow your 3d model geometry isn't getting configured so it get's
drawn at the right time in the pipeline as is getting clipped?
Curt.
Dave Culp wrote:
I have a cockpit view system set up for the OV-10 sim that uses a 2D forward
view and 3D side views (screenshot :
http://home.comcast.net/~davidculp2/2D_3D_views.jpg
It's controlled by some nasal scripts I bound to the arrow keys. Here are the
up(forward) and left bindings:
key n=356
nameLeft arrow/name
descLook left./desc
binding
commandnasal/command
script
node = props.globals.getNode(/sim/current-view);
if(node.getChild(view-number).getValue() == 0) {
setprop(/sim/current-view/heading-offset-deg,
getprop(/sim/view/config/left-direction-deg));
node.getChild(internal).setBoolValue(1);
node.getChild(x-offset-m).setDoubleValue(0.0);
node.getChild(y-offset-m).setDoubleValue(1.1);
node.getChild(z-offset-m).setDoubleValue(-1.25);
node.getChild(pitch-offset-deg).setDoubleValue(0.0);
}
/script
/binding
/key
key n=357
nameUp arrow/name
descLook forward./desc
binding
commandnasal/command
script
node = props.globals.getNode(/sim/current-view);
if(node.getChild(view-number).getValue() == 0) {
setprop(/sim/current-view/heading-offset-deg,
getprop(/sim/view/config/front-direction-deg));
node.getChild(internal).setBoolValue(0);
node.getChild(x-offset-m).setDoubleValue(0.0);
node.getChild(y-offset-m).setDoubleValue(0.0);
node.getChild(z-offset-m).setDoubleValue(0.0);
node.getChild(pitch-offset-deg).setDoubleValue(-10.0);
}
/script
/binding
/key
It works fine on the ground, but about 10 seconds after takeoff the 3D side
views of the aircraft's engine/wing go away and never come back. I check
through the property browser and all the values look unchanged. It seems
like the internal boolean value must have changed, but the property browser
does not indicate a change (even after a refresh of course).
Any idea what causes the view to change by itself after takeoff?
Thanks,
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
--
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@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Potential startup speed fix
Hi Andy, Thanks for looking into this. I had started working on a patch, but didn't have a chance to finish it. (See AI weirdness thread earlier this month). I do have a limited number parking and rwyuse files, so I'll test it tonight. As for the parking/runway files: I've started adding some ground network node editing support to Taxidraw, so once that works, people should be able to start decorating their favorite airport Real Soon Now (TM). Cheers, Durk On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Unfortunately, because there is no actual parking/runway AI data in the base package, much of this is currently dead code that cannot be tested. I can't promise I didn't break anything, because I have no way of knowing whether it worked in the first place. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Potential startup speed fix
On Thursday 26 May 2005 22:48, Andy Ross wrote: Attached is a patch that pre-reads the directory contents ahead of time (currently that is a list of length zero) to avoid having to hit the kernel (twice!) for every airport. Under Linux, this doesn't provide much speedup. But Windows (and especially the cygwin libraries) has a somewhat less robust I/O system in the face of many tiny operations. Hopefully it will help there. Can someone on each of cygwin, mingw and/or MSVC try this out and see if it helps? Hmm could you please whare with us what isn't 'robust' about the Cygwin file system. It is slow compared to the Linux or Native Win32 file system in that it has to go thru an extra translation layer inorder to get Unix behaviour under Win32 but . implying that Cygwin file operayions are not robust borders on pure fud Cheers Norman ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
