Re: [Flightgear-devel] atlas global tarball
It occurred to me to take a look at the underlying simgear/screen library. The associated self-test binary TestRenderTexture is failing too so this isn't an Atlas oddity. The RenderTexture.cxx implementation is correctly detecting a 1.2 GLX ... and then calling 1.3 features anyway. Odd. On Sun, Nov 22, 2009 at 6:58 PM, Alex Perry alex.pe...@pamurray.com wrote: Having compiled Atlas so I can regenerate a few maps on my laptop, it complains that it needs a GLX 1.3 feature and my X server only supports 1.2 ... so this side project will have to wait until I've got another machine handy. On Sun, Nov 22, 2009 at 3:53 AM, Victhor Foster victhor.fos...@gmail.com wrote: Is your computer too slow to generate them? There's an option in Map that speeds up the process, I think it's --headless-mode. Does someone happen to have a tarball with all the atlas generated map images handy? -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Doppler effect
Hi, I've implemented a check for implementations that need a Doppler effect adjustment to be able to hear them but there might be implementations that sound exaggerated now. If so, please specify which ones and I'll update the check procedure. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SenecaII - indicated heading in ki228
Hello Torsten, animation Hi Pawel, thanks for the report! I chose your second option to fix that bug. The standard property /instrumentation/heading-indicator/indicated-heading-deg is now set by the kg102 implementation. Thanks for fast response. I also found something strange about rotate animation with conditions which is used in ki227/ki228 implementation. Steps to reproduce prepare 0a. ./run_fgfs.sh --aircraft=SenecaII 0b. set property /instrumentation/adf/model to something other than 'ki228' 0c. close flighgear (menu-file/quit) - this saves the adf model prefs 1. ./run_fgfs.sh --aircraft=SenecaII - this puts you in ksfo, default configuration 2. slave the gyro and wait until stabilizes 3. set rotation of adf to something easily distinguishable like 90deg (straight east) 4. /instrumentation/adf/rotation-deg is now equal 90 and compass card of ADF shows direction straight east 5. set /instrumentation/adf/model=ki228 6. now the rotation of compass card should be equal to HSI, read from /instrumentation/heading-indicator/indicated-heading-deg (equal to ~284) but it is not. It's equal to 284+90 - 14deg 7. set /instrumentation/adf/rotation-deg=120 - the ADF card is still at 14deg 8. set /instrumentation/adf/model=ki227 9. now ADF card has heading 44deg It looks like the rotate animation remembers all properties it took data from and adds them. If one section of rotate is turned off by a condition its previous value is retained somewhere in FG internals and used anyway. It just updates its internal value to current value of property when condition is enabled. I don't know if it is the proper behavior. Although there is a note on wiki that states Each animation must be associated with exactly one property from the main FlightGear property tree (remember that the properties in the wrapper file are not part of the main tree), using property to provide the property name. But if the properties could be switched on-line it would make possible for example to park the ki228 vor needle to some default position when vor station is out of range (I don't really know if the real instrument behaves in this way, but judging from ADF power-off behavior I think it should). Best regards, Pawel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AI flights with same arrival and departure
The schedule code doesn't like AI flights with same arrival and departure, it produces some NaNs for them. There are a bunch of such flights in AI/Traffic/R/RNAF.xml. I don't see any support for them in the code so I added a little check like this: http://gitorious.org/~jester/fg/jesters-clone/commit/c6a18a540da4705c802849a7ac956af2508f45b4 Big thanks to dihedral on IRC for finding this problem. -- Csaba/Jester -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI flights with same arrival and departure
Hi Csaba, The schedule code doesn't like AI flights with same arrival and departure, it produces some NaNs for them. There are a bunch of such flights in AI/Traffic/R/RNAF.xml. I don't see any support for them It was me who created that traffic file. I was unaware that we did not support those flights, as it worked fine on a couple of computers (well, most of the time. Apart from some errors that appear every now and then)... Cheers, Gijs _ 25GB gratis online harde schijf http://skydrive.live.com-- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple instances of given ai aircraft
Hi, On Tuesday 17 November 2009 11:08:57 pm Alex Romosan wrote: Gijs de Rooy gijsr...@hotmail.com writes: What I see on your pictures and know from my own encounters with such aircraft is that they do not fly, as in flying an airplane. They just hover above the ground. if that's the case (and it seems to be because i looked and the airplane velocities and they were all 0) then it would make sense to draw the airplane only 30 mins before the scheduled departure date since it will eliminate all these conflicts (as i tried to do in my patch). unfortunately i still haven't seen any of those planes take off. First of all, I'm sorry for not responding any sooner. I'd wished to reply a little earlier, but the busy days ain't over yet. ... Indeed what you are observing here is indeed not a result of the multiple call signs, but a result of the new elevation calculation code. Parked aircraft are typically placed at unique locations, however, whenever an airport doesn't have sufficient parking space left, the remaining aircraft will be placed at a default location (currently, the airport's center point). This used to work resonably well, but now that AI aircraft are also included in the elevation calculations, each time an aircraft checks for the current ground elevation, it gets placed on top of highest one above. Because ground elevation checks are done intermittently, each aircraft is placed on top of the others in a semi random way, leading to the olleke bolleke staggered climbing that Gijs referred to. Since all these aircraft at US airports currently only have one destination (EHAM), your best chances of seeing them move would be late afternoon, early evening. Because there's only one destination, there's also only one (or a very limited number) of departure(s) every day. Cheers, Durk -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/scene/material Effect.hxx, 1.8,
Tim Moore wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene/material In directory baron.flightgear.org:/tmp/cvs-serv25138/simgear/scene/material Modified Files: Effect.hxx Log Message: Drop required Boost version from 1.37 to 1.34 Use boost/tr1 to bring in std::tr1::unordered_map instead of the Boost version. Author: Tim Moore timo...@redhat.com Index: Effect.hxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/material/Effect.hxx,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Effect.hxx 22 Nov 2009 00:00:01 - 1.8 +++ Effect.hxx 22 Nov 2009 22:23:01 - 1.9 @@ -19,8 +19,9 @@ #include vector #include string +#include boost/tr1/unordered_map.hpp According to my understanding, in order to use the standard C++ header, this line should read: #include tr1/unordered_map Am I wrong ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: source/simgear/scene/material Effect.hxx, 1.8,
On 11/23/2009 10:54 PM, Martin Spott wrote: Tim Moore wrote: Update of /var/cvs/SimGear-0.3/source/simgear/scene/material In directory baron.flightgear.org:/tmp/cvs-serv25138/simgear/scene/material Modified Files: Effect.hxx Log Message: Drop required Boost version from 1.37 to 1.34 Use boost/tr1 to bring in std::tr1::unordered_map instead of the Boost version. Author: Tim Moore timo...@redhat.com Index: Effect.hxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/scene/material/Effect.hxx,v retrieving revision 1.8 retrieving revision 1.9 diff -u -r1.8 -r1.9 --- Effect.hxx 22 Nov 2009 00:00:01 - 1.8 +++ Effect.hxx 22 Nov 2009 22:23:01 - 1.9 @@ -19,8 +19,9 @@ #include vector #include string +#include boost/tr1/unordered_map.hpp According to my understanding, in order to use the standard C++ header, this line should read: #include tr1/unordered_map Am I wrong ? No, but boost/tr1 uses the classes and functions from std::tr1 if available; otherwise it substitutes its own. As TR1 is not implemented everywhere, and most of TR1 was based on Boost code anyway, it works out well. However, it turns out that boost/tr1/unordered_map.hpp isn't in Boost 1.34, so it looks like it's back to 1.37. Tim -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Flightgear-cvslogs] CVS: data/Aircraft/c172p
On Thu, 19 Nov 2009 16:55:42 + (GMT) Heiko Schulz aeitsch...@yahoo.de wrote: One other issue I see with the 3d model and the textures. The way the cuts in the textures is done, one has nearly vertical surfaces on each side near the bottom edge of the windshield. This results in severe stretching of the textures on each side below the windshield. This is fairly obvious and needs to be corrected. This again involves a lot of work. Does the team think we need to fix this for the liveries before the next release as this is the default ac? That would mean a complete new mapping of this part and that the textures and liveries. You woulden't notice it, if there woulden't be ambient shadow- it could be maybe done with simple edtiting the liveries. Ahoy guys, I am still working sometimes on the D-ECJB livery and also recognised this glitch. And it is possible to make it 'invisible' by editing the livery. See screenshot, picture [1]. However, I am not sure if this is the right way to solve this issue. I am planning to draw details like the sheeding below the windshield, like the one on picture [2], and I am not sure if this will be easy with the current mapping. To look at the future, I am not sure if there is any c172p painting out there which will make the way into FG *and* uses this part of the aircraft, but if so, drawing this would be quite hard. OTHO, redoing all the existing liveries will take some effort. Well, this was 'just to say' and if the decision is just editing the liveries I'll adapt this to the other liveries and send them to Heiko(?). [1] http://fgfs.beggabaur.de/daten/c172p_mapping.jpg [2] http://ntxac.inside.net/ntxac/N55299/N55299_17.JPG ciao PS: replace [some|all] of the I am not sure by a better phrase on your own. ;-) -- Alex D-HUND f...@beggabaur.de -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
