Re: [Flightgear-devel] BUG report: MP chat on screen messages broken in harrier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Csaba Halasz wrote: On Jan 5, 2008 11:46 AM, AnMaster [EMAIL PROTECTED] wrote: Nasal runtime error: No such member: trim at /home/anmaster/src/flightgear/data/Nasal/screen.nas, line 99 This happens with both osg and plib branches, and it only happens in harrier. Apparently another case of missing var keyword. Try attached patch. This patch works for me. Can you get it committed? Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHgK07WmK6ng/aMNkRCs+DAKCkLcu+/IHwO5fOhi4fT981oT4F1QCgx1X3 UpYLZkBhN7bXBGIrLp6/QAE= =DmRx -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Dave, same here. But it is ok, if I start with 4:3 window and maximize it when fg runs (my normal start procedure). Maik dave perry schrieb am 06.01.2008 05:08: Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Abort with OSG and using --config=a logging facility XML file
Hi, I can't get logging facilitty work with 3 days old SG and FG. Very annoying :-( Alexis - here is the XML: logging log enabledtrue/enabled filenamesteering.csv/filename interval-ms1000/interval-ms delimiter,/delimiter entry enabledtrue/enabled titleRudder/title property/controls/rudder/property /entry /log /logging - here is the backtrace in gdb: [EMAIL PROTECTED]:~/fgfs/A-10-docs/logs$ gdb fgfs GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) run --config=commandes.xml Starting program: /usr/local/bin/fgfs --config=commandes.xml [Thread debugging using libthread_db enabled] [New Thread -1231849760 (LWP 28781)] Uncaught Exception: you should see a meaningful error message here, but your GLUT (or SDL) library was apparently compiled and/or linked without exception support. Please complain to its provider! Program received signal SIGABRT, Aborted. [Switching to Thread -1231849760 (LWP 28781)] 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7307875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7309201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x08065097 in fg_terminate () at bootstrap.cxx:154 #4 0xb74eaf65 in ?? () from /usr/lib/libstdc++.so.6 #5 0xb74eafa2 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0xb74eb0ca in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0x085c4327 in PropsVisitor::startElement (this=0xbf9a9404, name=0x8842970 logging, [EMAIL PROTECTED]) at props_io.cxx:157 #8 0x085dc78f in start_element (userData=0xbf9a9404, name=0x8842970 logging, atts=0x8842458) at easyxml.cxx:180 #9 0x085e143e in doContent (parser=0x8842280, startTagLevel=0, enc=0x864c460, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., end=0xbf9a5352 a\bM\213a\b?S\232???\200\b\224S\232?0?\200\b?S\232?1^\\\b?S\232?, nextPtr=0xbf9a5198) at xmlparse.c:1263 #10 0x085e20a3 in prologProcessor (parser=0x8842280, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., end=0xbf9a5352 a\bM\213a\b?S\232???\200\b\224S\232?0?\200\b?S\232?1^\\\b?S\232?, nextPtr=0xbf9a5198) at xmlparse.c:2031 #11 0x085df3ea in XML_Parse (parser=0x8842280, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., len=250, isFinal=0) at xmlparse.c:780 #12 0x085dcc25 in readXML ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at easyxml.cxx:237 #13 0x085dd6d2 in readXML ([EMAIL PROTECTED], [EMAIL PROTECTED]) at easyxml.cxx:270 #14 0x085c323f in readProperties ([EMAIL PROTECTED], start_node=0x8745d28, default_mode=0) at props_io.cxx:357 #15 0x08097bc4 in fgOptConfig (arg=0x884a12c commandes.xml) at options.cxx:1060 #16 0x0809c350 in parse_option ([EMAIL PROTECTED]) at options.cxx:1529 #17 0x0809d016 in fgParseArgs (argc=2, argv=0xbf9a9904) at options.cxx:1571 #18 0x08082d44 in do_options (argc=2, argv=0xbf9a9904) at fg_init.cxx:516 #19 0x080860e2 in fgInitConfig (argc=2, argv=0xbf9a9904) at fg_init.cxx:688 #20 0x08067c99 in fgMainInit (argc=2, argv=0xbf9a9904) at main.cxx:1036 #21 0x080650f1 in main (argc=Cannot access memory at address 0x706d ) at bootstrap.cxx:220 (gdb) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Abort with OSG and using --config=a logging facility XML file [FIXED]
alexis bory wrote: Hi, I can't get logging facilitty work with 3 days old SG and FG. Very annoying :-( Alexis Adding a PropertyList level in the XML fixes the bug. I'll correct the example in data/Docs/README.logging Sorry for the noise Alexis - here is the XML: logging log enabledtrue/enabled filenamesteering.csv/filename interval-ms1000/interval-ms delimiter,/delimiter entry enabledtrue/enabled titleRudder/title property/controls/rudder/property /entry /log /logging - here is the backtrace in gdb: [EMAIL PROTECTED]:~/fgfs/A-10-docs/logs$ gdb fgfs GNU gdb 6.6-debian Copyright (C) 2006 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i486-linux-gnu... Using host libthread_db library /lib/tls/i686/cmov/libthread_db.so.1. (gdb) run --config=commandes.xml Starting program: /usr/local/bin/fgfs --config=commandes.xml [Thread debugging using libthread_db enabled] [New Thread -1231849760 (LWP 28781)] Uncaught Exception: you should see a meaningful error message here, but your GLUT (or SDL) library was apparently compiled and/or linked without exception support. Please complain to its provider! Program received signal SIGABRT, Aborted. [Switching to Thread -1231849760 (LWP 28781)] 0xe410 in __kernel_vsyscall () (gdb) bt #0 0xe410 in __kernel_vsyscall () #1 0xb7307875 in raise () from /lib/tls/i686/cmov/libc.so.6 #2 0xb7309201 in abort () from /lib/tls/i686/cmov/libc.so.6 #3 0x08065097 in fg_terminate () at bootstrap.cxx:154 #4 0xb74eaf65 in ?? () from /usr/lib/libstdc++.so.6 #5 0xb74eafa2 in std::terminate () from /usr/lib/libstdc++.so.6 #6 0xb74eb0ca in __cxa_throw () from /usr/lib/libstdc++.so.6 #7 0x085c4327 in PropsVisitor::startElement (this=0xbf9a9404, name=0x8842970 logging, [EMAIL PROTECTED]) at props_io.cxx:157 #8 0x085dc78f in start_element (userData=0xbf9a9404, name=0x8842970 logging, atts=0x8842458) at easyxml.cxx:180 #9 0x085e143e in doContent (parser=0x8842280, startTagLevel=0, enc=0x864c460, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., end=0xbf9a5352 a\bM\213a\b?S\232???\200\b\224S\232?0?\200\b?S\232?1^\\\b?S\232?, nextPtr=0xbf9a5198) at xmlparse.c:1263 #10 0x085e20a3 in prologProcessor (parser=0x8842280, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., end=0xbf9a5352 a\bM\213a\b?S\232???\200\b\224S\232?0?\200\b?S\232?1^\\\b?S\232?, nextPtr=0xbf9a5198) at xmlparse.c:2031 #11 0x085df3ea in XML_Parse (parser=0x8842280, s=0xbf9a5258 logging\nlog\nenabledtrue/enabled\nfilenamesteering.csv/filename\ninterval-ms1000/interval-ms\ndelimiter,/delimiter\nentry\nenabledtrue/enabled\ntitleRudder/title\nproperty/cont..., len=250, isFinal=0) at xmlparse.c:780 #12 0x085dcc25 in readXML ([EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at easyxml.cxx:237 #13 0x085dd6d2 in readXML ([EMAIL PROTECTED], [EMAIL PROTECTED]) at easyxml.cxx:270 #14 0x085c323f in readProperties ([EMAIL PROTECTED], start_node=0x8745d28, default_mode=0) at props_io.cxx:357 #15 0x08097bc4 in fgOptConfig (arg=0x884a12c commandes.xml) at options.cxx:1060 #16 0x0809c350 in parse_option ([EMAIL PROTECTED]) at options.cxx:1529 #17 0x0809d016 in fgParseArgs (argc=2, argv=0xbf9a9904) at options.cxx:1571 #18 0x08082d44 in do_options (argc=2, argv=0xbf9a9904) at fg_init.cxx:516 #19 0x080860e2 in fgInitConfig (argc=2, argv=0xbf9a9904) at fg_init.cxx:688 #20 0x08067c99 in fgMainInit (argc=2, argv=0xbf9a9904) at main.cxx:1036 #21 0x080650f1 in main (argc=Cannot access memory at address 0x706d ) at bootstrap.cxx:220 (gdb) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net
Re: [Flightgear-devel] Random Objects OSG patch
Stuart Buchanan wrote: --- Stuart Buchanan wrote: --- Stuart Buchanan wrote: I've uploaded a new patch which includes this feature, along with some changes that Andy and Csaba suggested on IRC to http://www.nanjika.co.uk/flightgear/random.tar.gz. Further updates available at the above location: - Improved quad trees (256 leaves rather than 4) with LoD to improve performance. Works well with the 3-D tree patch. - Better use of pseudo-random numbers - previously some objects were co-located because they used the same MT seed. Whoops. I've checked this work in, with a change to use an independent quad tree builder class. Thanks very much for the contribution; it's good to have another OSG hacker in the house. I did some cleanup to the code, notably changing various osg::Matrix objects to be stack allocated instead of heap allocated. There remains a fairly serious performance problem with this code, most visible if you pan to the south at KSFO: culling time explodes. The extra polygons themselves aren't the problem, so I suspect that the LOD nodes on each object are expensive. I have in mind another approach that I'd like you (Stuart) to take a look at: at each of quad tree leaves, have one LOD node with ranges corresponding to the different ranges of the objects in that node. Then, add the object (that part *below* its own LOD node) to each LOD range in which it is visible. This might suggest a different way of returning random models from the materials library. Hit me up on IRC if you want some help on the details. Tim - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] fgrun future
Hello, I am in the process of internationalizing fgrun. Here is an example screenshot with a french localization : http://frbouvi.free.fr/flightsim/fgrun-i18n.jpg I had to resize the window to make room to longer localized string but now we have a lot of room to add new options that are currently only available in the advanced section. So I would like to start an informal poll on what is the most judicious to put on this page. Thanks for your input. -Fred PS: there is a template file to translate here : http://fgrun.svn.sourceforge.net/viewvc/fgrun/trunk/fgrun/po/fgrun.pot?view=markup If there are wannabe translators here they can start to exercise their skill ;-) The french ( unfinished ) translation can serve as an example : http://fgrun.svn.sourceforge.net/viewvc/fgrun/trunk/fgrun/po/fr.po?view=markup -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS HEAD locks up when a 787 joins mp
Arvid Norlander wrote: Hash: SHA512 It seems like OSG-based FlightGear locks up or slows down to less than 1 FPS if a 787 joins over mp near you. For example, today I was flying concorde, had just landed and was taxing to KSFO terminal and a 787 joined: Chat [*FGMS*] NJ7983 is now online, using Chat [*FGMS*] Aircraft/787/Models/787ANA.xml FGFS then locked up for about 20 seconds, or so, by then the MP connection had timed out: Chat [*FGMS*] Welcome to pigeond.net Chat [*FGMS*] using protocol version v1.1This server is tracked. Then it instantly locked up again, and after 20 more seconds, reconnected and so on. I looked for an AI model for 787, and found an XML file that just loads the full model. I'd suggest using a simplified model for the AI model, that should help against these lockups. As it is now, any 787 joining mp prevents any osg user flying nearby. Csaba reported he had a similar problem with 787 recently (just very very low fps, not total lockup). For the reference I got a nVidia GeForce 7600 with the drivers 100.14.19. Regards, Arvid Norlander I have made an improved AI version of my 787 model. You can download it at http://www.filefactory.com/file/7a04ae/ It has fewer files and smaller textures. Josh - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi Christian! Christian Buchner wrote: I found another slight discrepancy when converting back each tile's geodetic center coordinate to a bucket - this function might be slightly buggy: In a few cases it returns a different bucket number than given by the original file name of the tile. I can work around this problem, but I wonder if other parts of FlightGear might be affected by this bug. I was just about to write a bug report about the same thing when I found and reread your mail. I came across this problem with the current scenery rebuild. Interestingy the first run went without mostly no problem, but the second run - initiated as Curt was missing some settlements - brought up many failing tiles in the pole regions, due to faulty tile indices used for location of shared edge elevation data. I investigated further and there might be a connection to the missing poles problem Torsten reported some time ago. The set_bucket()-function will calculate different tile numbers for the poles - even though the pole (180W,89N to 180E,90N) should be one tile - depending on whether you are on the western or the eastern hemisphere. This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). Also the westmost tile on the tiles between 88 and 89 deg latitude is 8 degrees wide according to sg_bucket_span(), but starts at -180, which is not divisible by 8. This means that e.g. 176W, 88.5N is both on a tile starting at 180W and at 174W. I was able to correct most of the inconsistencies without regression (tested using random testing and 1.000.000 testcases, but verifiable formally as well, I think), and I even introduced special-case handling for the 180W-tile at 88-89 deg latitude. Regression here means that for the positions tested both the old and the new code report the same tile index. The part for the poles (above 89 deg latitude) cannot be fixed without regression, as depending on the longitude (western or eastern) the old code reports different tile numbers, while it should not. This might affect several applications, among them reading of scenery and placement of objects, due to the differing tile numbers. This is grid system has been in existence since at least September 2002, as this is the date when the CVS for SimGear 0.3 started. We will not get rid of that problem without lots of special case handling or some flag day after which the old tile numbers will not be valid anymore. Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
On Sun, 2008-01-06 at 16:22 +0100, Frederic Bouvier wrote: Hello, I am in the process of internationalizing fgrun. Here is an example screenshot with a french localization : http://frbouvi.free.fr/flightsim/fgrun-i18n.jpg I had to resize the window to make room to longer localized string but now we have a lot of room to add new options that are currently only available in the advanced section. So I would like to start an informal poll on what is the most judicious to put on this page. Thanks for your input. -Fred A checkbox for : --prop:/controls/gear/brake-parking --prop:/sim/traffic-manager/enabled --prop:/sim/current-view/dynamic-view --prop:/sim/sound/atc-chatter and/or perhaps the Avionics properties, nav freqs, com freqs, etc. Thanks, Ron - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
Ron Jensen wrote: On Sun, 2008-01-06 at 16:22 +0100, Frederic Bouvier wrote: Hello, I am in the process of internationalizing fgrun. Here is an example screenshot with a french localization : http://frbouvi.free.fr/flightsim/fgrun-i18n.jpg I had to resize the window to make room to longer localized string but now we have a lot of room to add new options that are currently only available in the advanced section. So I would like to start an informal poll on what is the most judicious to put on this page. Thanks for your input. -Fred A checkbox for : --prop:/controls/gear/brake-parking --prop:/sim/traffic-manager/enabled --prop:/sim/current-view/dynamic-view --prop:/sim/sound/atc-chatter and/or perhaps the Avionics properties, nav freqs, com freqs, etc. Thanks, Ron FGCOM :) Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
alexis bory a écrit : I had to resize the window to make room to longer localized string but now we have a lot of room to add new options that are currently only available in the advanced section. So I would like to start an informal poll on what is the most judicious to put on this page. Thanks for your input. FGCOM :) Please elaborate. What are the options needed to pass to fgfs ? -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat tower altitude question (possible bug?) - patch
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Curtis Olson wrote: On Jan 5, 2008 8:56 PM, Csaba Halasz wrote: Hi! I have changed Tiago's patch somewhat, it now iterates over all the ground layers. Debug output looks like this for KSFO: Found tower ground layer at 124.323ft, material unnamed Found tower ground layer at 114.536ft, material unnamed Found tower ground layer at 82.3405ft, material unnamed Found tower ground layer at 42.9577ft, material unnamed Found tower ground layer at 5.36808ft, material pc_tiedown Setting tower viewpoint altitude 112.368 I was hoping to find a layer like Grass or Ground somewhere, but no. So for now, the code picks the lowest layer, which might not work if the tower is sunk into the ground as other objects frequently are. I tested LHBP and that worked (even had grass material). Also attached is a patch to apt.dat (gunzip, patch, gzip) that updates KSFO and KNID tower viewpoint based on the scenery. I am not sure we can trust the tower position in apt.dat, since the elevation values are frequently obvious nonsense (500 for KSFO and 0 for KNID). Please comment. Isn't the airport altitude also reported in the same file? We should be able to set the tower altitude in MSL to apt_alt + tower_alt. It seems like extreme overkill to actually query the ground elevation. Regards, Curt. However the airport altitude seldom matches the scenery. While this is a pitty, what would users notice most: * Tower view is calculated from scenery, so it any tower building placed on the terrain in scenery. * Tower view is calculated from entry in apt.dat that is likely not the same as the scenery, tower view may end up above tower, or below tower (or even below ground) Since the elevation values are way off as Jester mentioned, I think basing it on scenery is best. However the airport altitude should probably be corrected as well. Regards, Arvid Norlander -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHgR7MWmK6ng/aMNkRCmwbAKCMcQkz/TfFnpewXCpz5hRZWRTREQCgq2OP 3onRKErElVkjd4uN7Krk/zU= =2dgW -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
Frederic Bouvier wrote: alexis bory a écrit : I had to resize the window to make room to longer localized string but now we have a lot of room to add new options that are currently only available in the advanced section. So I would like to start an informal poll on what is the most judicious to put on this page. Thanks for your input. FGCOM :) Please elaborate. What are the options needed to pass to fgfs ? here the option I pass to FlightGear so it can drive fgcom : --generic=socket,out,10,192.168.1.3,16661,udp,fgcom Alexis - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] view options
Hi Dave, I checked again, if I start with a 4:3 resolution the gages remain round when maximizing to 1680*1050 by clicking the square in the upper right corner. I am running win xp, compiled on msvc-express. The same, if I start with --resolution=800x600. If I start with --resolution=1680x1050 the gages are not round, but the property browser seem to show the same values in sim/current-view. Maik dave perry schrieb am 06.01.2008 16:55: Hi Maik, If I use the command line to launch with the default 800x600 window and then use the gnome window maximize (i.e. click the square in upper right corner of the window), I get the distorted-aspect-ratio image filling the screen. I am running Fedora 7 with nvidia graphics, gnome window manager. What is your environment? -Dave Maik Justus wrote: Hi Dave, same here. But it is ok, if I start with 4:3 window and maximize it when fg runs (my normal start procedure). Maik dave perry schrieb am 06.01.2008 05:08: Maik Justus wrote: Hi, Maik Justus schrieb am 26.12.2007 20:38: Hi Syd, what's about an algorithm, which checks the ratio of the screen and sets fow to 55 for 4:3 screens and 70 for 16:9 screens? (55 / 70 = (4/3) / (16/9) ) Maik P.S.: for non-physicists: (55 / 73,333 = (4/3) / (16/9) ) Meanwhile I have a new computer wit 16:9 screen and the same problem. I've modified the calculation in viewer.cxx as mentioned above. Syd, please check, if this would work for you. Then we can think about, how to implement that in a clean way (maybe we need an FG_SCALING_HEIGHT case?). The patch is for the osg-branch, but it works with the plib branch, too (maybe some lines offset). Hi Maik, I have had a 16:9 flat pannel for some time. For the first time in several months, I built fgfs for osg from fresh svn and fresh cvs. What I noticed right away that has changed is that osg fgfs does not handle the --geometry=1680x1050 correctly anymore. The height of the image is too small for the width. The gages are not round. The plib branch still handles this correctly. Are you seeing what I am seeing or have I missed a patch? When I adjusted the width of the window until round objects are round and then measure the aspect ratio of the adjusted window, the aspect ratio is 4/3. Here is what comparing the plib to the osg response to changing the value of /sim/current-view/aspect-ratio-multiplier tells me: In plib, it adjusts the displayed aspect ratio. I can get the same distortion in plib fgfs as in osg fgfs by changing this value to ~1.2 instead of 1. But if I try to fix the view in osg fgfs by adjusting this value from 1 to 0.8333, all it does is scale the distorted image. i.e. it is adjusting the effective fov, not the aspect ratio. - Dave Perry - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
Hi again! Ralf Gerlich wrote: This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). The problem only occurs for latitudes north of 83N or south of 83S western longitudes. Only here the longitudinal span of buckets is above 1.0 and always divisible by 2, so that the center of a bucket always lies on an integral longitude. This leads to the fabs(diff)SG_EPSILON condition in newbucket.cxx:109 to evaluate to true and therefore activates the wrong calculation. Casting to (int) always rounds towards zero, which in this case leads to the base longitude being shifted eastwards by one span. In case of latitudes north of 89N or south of 89S non-western longitudes (=0) will lead to a base longitude of 0, while western longitudes will lead to a base longitude of -180. This means that the single tiles surrounding the polar caps (width 360 degree, height 1/8 degree) essentially have different tile numbers depending on whether one is coming from an eastern or a western latitude. This might also explain the missing northpole-problem reported by Torsten Dreyer some time ago. Another possibility would be that Curt's last build failed in a similar way as ours did and there are not northpole tiles ;-) Cheers, Ralf - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat tower altitude question (possible bug?) - patch
On Sunday 06 January 2008 18:32, AnMaster wrote: Curtis Olson wrote: On Jan 5, 2008 8:56 PM, Csaba Halasz wrote: Hi! I have changed Tiago's patch somewhat, it now iterates over all the ground layers. Debug output looks like this for KSFO: Found tower ground layer at 124.323ft, material unnamed Found tower ground layer at 114.536ft, material unnamed Found tower ground layer at 82.3405ft, material unnamed Found tower ground layer at 42.9577ft, material unnamed Found tower ground layer at 5.36808ft, material pc_tiedown Setting tower viewpoint altitude 112.368 I was hoping to find a layer like Grass or Ground somewhere, but no. So for now, the code picks the lowest layer, which might not work if the tower is sunk into the ground as other objects frequently are. I tested LHBP and that worked (even had grass material). Also attached is a patch to apt.dat (gunzip, patch, gzip) that updates KSFO and KNID tower viewpoint based on the scenery. I am not sure we can trust the tower position in apt.dat, since the elevation values are frequently obvious nonsense (500 for KSFO and 0 for KNID). Please comment. Isn't the airport altitude also reported in the same file? We should be able to set the tower altitude in MSL to apt_alt + tower_alt. It seems like extreme overkill to actually query the ground elevation. Regards, Curt. However the airport altitude seldom matches the scenery. While this is a pitty, what would users notice most: * Tower view is calculated from scenery, so it any tower building placed on the terrain in scenery. * Tower view is calculated from entry in apt.dat that is likely not the same as the scenery, tower view may end up above tower, or below tower (or even below ground) Since the elevation values are way off as Jester mentioned, I think basing it on scenery is best. However the airport altitude should probably be corrected as well. Regards, Arvid Norlander I think a lot of this problem might be down to the resolution of the underlying SRTM data. Even using 5 point interpolation, which would be very time consuming to generate, you'd probably only get accurate results half the time and if you extended that to a two-dimensional interpolation it would probably still only bring it down to ~10% accuracy for any intermediate point. To summarise: the curve between any two points can go anywhere, so between the points you're best off not fiddling with it too much and accepting the intermediate errors. Of course, it might be nothing to do with that at all:) LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problems found in world scenery and SGBucket class
On Sunday 06 January 2008 21:05, Ralf Gerlich wrote: Hi again! Ralf Gerlich wrote: This has to do mostly with the special cases introduced for rounding (regarding SG_EPSILON) and for covering the difference between (int) cast rounding towards zero and the desired behaviour more similar to a floor(). The problem only occurs for latitudes north of 83N or south of 83S western longitudes. Only here the longitudinal span of buckets is above 1.0 and always divisible by 2, so that the center of a bucket always lies on an integral longitude. This leads to the fabs(diff)SG_EPSILON condition in newbucket.cxx:109 to evaluate to true and therefore activates the wrong calculation. Casting to (int) always rounds towards zero, which in this case leads to the base longitude being shifted eastwards by one span. In case of latitudes north of 89N or south of 89S non-western longitudes (=0) will lead to a base longitude of 0, while western longitudes will lead to a base longitude of -180. This means that the single tiles surrounding the polar caps (width 360 degree, height 1/8 degree) essentially have different tile numbers depending on whether one is coming from an eastern or a western latitude. This might also explain the missing northpole-problem reported by Torsten Dreyer some time ago. Another possibility would be that Curt's last build failed in a similar way as ours did and there are not northpole tiles ;-) Cheers, Ralf I think I mentioned earlier, but first problem - there's no SRTM data for the poles. Second problem is that calculations that assume a quad (trapezoidal) area fail at the poles because they have to deal with a tri area and not a quad area. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Friday 04 January 2008 19:59, LeeE wrote: Hi all, I just noticed I was getting a Nasal error with a YASim aircraft I was working on that had only three fuel tanks. The error is: Nasal runtime error: props.setDoubleValue() with non-number at /usr/local/share/FlightGear/Nasal/props.nas, line 26 called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 93 called from: /usr/local/share/FlightGear/Nasal/fuel.nas, line 125 I also got the same error when I tried an aircraft that has only one fuel tank. I don't think that the problem is actually with the Nasal scripts but with something else that creates four incomplete fuel tank nodes by default at start-up. If there are 4 fuel tank elements in the YASim config the last tank's details are left incomplete and I think that this is what the Nasal script is borking on. With a zero capacity dummy tank in the YASim config the problem doesn't occur. I had a quick look in options.xml preferences.xml, aw well as my .fgfsrc but didn't find anything - can't think of anywhere else to look:( LeeE I thought I'd re-post this as no-one seems to have noticed it and it seems like quite a big problem to me. I also started testing the FG aircraft that have 3 fuel tanks defined and found the same problem with the following aircraft before I decided that there wasn't any point in testing all of them: 737-300 747 a24-yasim (A24-Viking) A320 a4 A6M2 ... Out of the candidates I tested only the a4f, which appears to be based on the a4, didn't have the problem - I haven't looked into this discrepancy yet. That isn't even all of the 'A's though and one of them, the A320, is a JSBSim aircraft. With these aircraft it's not possible to change the initial fuel loads via the menu and there are no values in the tree for the /consumables/fuel/total-* nodes. Can anyone else confirm this problem on the OSG cvs branch? LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] two issues (bugs?) with fresh osg, Simgear, flightgear
Hi all, I have not had a working osg build since late September when I installed F7. Yesterday, I did fresh check outs of osg, simgear, and flightgear source and data. I now have two problems that are not there with V1.0, or the plib cvs branch. 1. Wrong ASPECT RATIO on non 4:3 monitors I have a 1680x1050 TFT monitor. Works great with V1.0 and the plib branch. But the aspect ratio is distorted with osg. This issue has been seen by others. Miak indicates that with osg and XP setting the geometry to 1680x1050 results in this distortion. But if he starts with a 4:3 resolution and then maximizes the window, he gets no distortion. Not so on my F7 system. One other related observation. The affect of changing the /sim/current-view/aspect-ratio-multiplier is different in osg compared to V1.0. With the plib version, changing this from 1 really adjusts the aspect ratio. With osg, adjusting this property just scales the view similar to adjusting fov. 2. Some aircraft-defined keyboard toggles work only once in osg branch Examples: pa24-250-set.xml and the pa28-161 both use the keys !, @, #, $, %, ^, (, and ). With older osg builds and current V1.0 and plib builds these work. With yesterdays osg build, most of these only work the first time. I tried other AC and some of their toggles also only worked the first time. Casaba indicated (IRC) with an older osg build, these toggles work repeatedly. By the way, the pannel hot spots use the same nasal functions to do the toggle and they all still toggle repeatedly. I have tried both osg 2.2 and osg cvs with the same results on both issues. Are others with current svn and cvs osg builds seeing these issues? -Dave P. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
On Jan 6, 2008 1:13 PM, Vivian Meazza [EMAIL PROTECTED] wrote: I'm going to be a lone voice here Fred, I like it just the way it is :-) My view is we want to keep the main page really really simple. This is what new users are going to see for the first time and we don't want to blow them away with 500 different options. I think we need to fight the urge to put more stuff on the first page (if nothing else maybe take some stuff away) ... but make the options available on the advanced page ... or maybe make some subpages to organize the most used options for each particular category. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgrun future
I strongly agree. The first page needs to be clear and simple and without flash and non html garbage. One simple impressive front page thing is an encapsulated youtube or other video that shows great video of flight gear in action. THAT makes people see what the flight sim is all about and it takes no more space than a single still photo and does NOT choke browsers. On Sun, 6 Jan 2008 9:42 pm, Curtis Olson wrote: On Jan 6, 2008 1:13 PM, Vivian Meazza [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] wrote: I'm going to be a lone voice here Fred, I like it just the way it is :-) My view is we want to keep the main page really really simple. This is what new users are going to see for the first time and we don't want to blow them away with 500 different options. I think we need to fight the urge to put more stuff on the first page (if nothing else maybe take some stuff away) ... but make the options available on the advanced page ... or maybe make some subpages to organize the most used options for each particular category. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ [http://baron.flightgear.org/~curt/] www.GlobalBoiling.com for daily images about hurricanes, globalwarming and the melting poles. www.ElectricQuakes.com daily solar and earthquake images. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2005. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
