Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: ThorstenB Sent: Thursday, November 15, 2012 7:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Thortsen Here is my system.fgsrc file and then the log output.~ My TSR2, if you need it, is at g...@gitorious.org:fg-ajt/tsr2.git. The final Nasal error (nil used in numeric context) only occurs when I use the new version of simgear/misc/sg_path.cxx. Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. In each case the property /sim/fg-aircraft is that specified by --fg-aircraft=, except that the trailing \ is discarded. I ran flightgear with the command: C:\FlightGear\install\msvc100\bin\fgfs.exe fgfsrun.txt 21 system.fgsrc:- --fg-root=C:/FlightGear/fgdata --fg-scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\flightgear --fg-aircraft=C:\FlightGear\MyAircraft --airport=EGNO --aircraft=TSR2 --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --prop:/sim/traffic-manager/enabled=0 --geometry=1024x768 --visibility-miles=30 --bpp=32 --log-level=alert --timeofday=noon --enable-rembrandt Log file: No GAIN specified (default: 1.0) loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26 Switches.nas Annunciator.nas controls.nas timers.nas electrical.nas Engine-Start-Stop.nas TSR2 undercarriage.nas settimer(gearLights, 0); navradiodisplay.nas g-meter.nas ice-warn.nas Init properties.nas startup.nas dropview.nas TSR2-moving-map.nas TSR2 autopilot.nas TSR2 contrail.nas TSR2 liveries.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied (unauthorized access) Nasal runtime error: non-objects have no members at C:/FlightGear/fgdata/Nasal/gui.nas, line 479 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450 called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4 dialogs.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7 TSR2 canvas HUD.nas loading scenario 'nimitz_demo' map init-props moving map loaded Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14 icewarn I hope that this helps debug the problem. Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure,
[Flightgear-devel] Some shader work updates
I don't know if anyone is interested in what precisely I've been up to of late, but I do know that I get frequently asked why the reflection (bump, you name it) effect isn't yet working in atmospheric light scattering, so this is sort of an answer to that. Well, I also sort of wanted to write that up, to illustrate what kind of problems shader code produces. I'm guessing Fred Co. know that rather well... So. it all started with me being unhappy with some visuals of clouds in sunset conditions, and I decided I have to use some data. I spent a few hours measuring (rgb) values of a time series of sunset photographs I had recently taken, in addition I measured light and shadow contrasts from a variety of other sunset pictures. This gave me the clue to at least one source of my unhappiness - unlike implemented in the FG default rendering scheme from where my current light curves are basically taken, ambient light never gets red. Regardless of the rgb value of an illuminated cloud, all shaded parts fall into a very narrow range of blue-grey hue with varying intensity. That's good news as such, because having to compute just the intensity saves two expensive light computations in the shader. So the project was to update the ambient light to a more plausible value everywhere. In computer science textbooks, one does things like Emilian suggested once here, writes a general light and fog scheme which is referenced by all effects and just updates it. Unfortunately, in reality... let's see. I have a scheme which does light correctly for the terrain. This is based on computing light based on the relative location of a vertex to the terminator (the light/shadow line drawn by the sun), and I can compute light and fogging for all positions. I can't simply take the scheme over to the skydome, because the skydome has no 'real' geometry like the terrain. A skydome vertex may return me some position, but that is not a *real* position which would actually tell me how light and fog are there. Instead, the light and fog scheme needs to be adapted to the pseudo-geometry of the skydome where angles more meaningful than distances. I've once tried to take over the scheme to cloud rendering. That, unfortunately, results in very nice still images of beautifully fogged and illuminated clouds at a rate of 1 fps or so. It's way too slow to treat the clouds in a light/fog scheme that works for the terrain. So - clouds need some much faster suitable approximation. For instance, clouds don't even see the ambient light channel - they're just shaded at the bottom/back. So the trick is to make the color of that shade match the ambient light. And that means that shade of clouds isn't just an intensity multiplier, it corresponds to a hue/saturation trafo to the ambient light color. The terrain scheme doesn't work for the water sine shader either, because... that doesn't probe separate ambient light either but is based on the specular light channel. So to get ambient light here, the specular light needs to be post-processed to match up with the ambient light elsewhere if the water is in shade. Unfortunately, as I discovered, a hue/sat rotation becomes numerically unstable if the input color is solid black (as the specular light at midnight is set to be) - so I got this amazing effect where suddenly the water was brightly blue-green illuminated around pitch black islands (I know there's glowing algae bloom in some locations - we can do this...). Some extra code needs to be inserted to prevent this from happening. The default terrain scheme doesn't work for trees either... The reason is rather subtle - in low light, fog is not a device to make the horizon match up, but it becomes largely the object you render. Looking against a hill with the sun behind, you will notice that the hill is dark. We tend to thing that this is because there's only ambient light, so naturally it's dark, but that's in many cases a minor correction to the actual effect, which is that the hill shades the fog between it and the eye, and hence you see the hill through shaded fog, thus it is dark. Regardless of what you do with ambinent and diffuse light, unless the visibility is extremely high, the hill does not appear dark if you do not shade the fog. Of course we can't actually render volumetric shadows in fog, so... we fake it by making the fog color in a semi-clever way dependent on the dot product of light direction and terrain normal, which looks plausible enough. But we don't know the terrain slope for tree rendering, the slope of the tree model is way too steep, so we don't really want to have that effect for trees which don't shade fog appreciably in reality, and thus some additional cleverness is needed. For the urban effect, the default terrain scheme doesn't work either (you probably guessed this at this point, right) - the reason is that the urban effect before atmospheric light uses up too many
Re: [Flightgear-devel] FSWeekend 2012...
On Thu, 15 Nov 2012 21:44:59 +0100, Gijs wrote in message dub002-w526f44a3616768d066e468d3...@phx.gbl: Anyone got a Kinect or two? This would make a nice attention-grabber (controlling an aircraft by moving your bare hands in space) :-) http://threegearsystems.blogspot.nl/2012/11/flightgear-demo.html ..enjoy the legal side: ;o) http://uk.gamespot.com/news/microsoft-denies-kinect-hack-claims-6283696 http://www.zdnet.com/blog/open-source/microsoft-surrenders-on-linux-kinect-hack/7769 ..the tech side: http://www.linuxjournal.com/content/kinect-linux http://openkinect.org/wiki/Main_Page http://www.freenect.com/ http://www.kinecthacks.com/kinect-linux-multitouch-screen/ http://www.youtube.com/watch?v=llNSQ2u2rT4feature=related ..alternatives independent of Kinect: http://www.youtube.com/watch?v=1GhNXHCQGsMfeature=related http://www.youtube.com/watch?v=NCtYdUEMotgfeature=related http://www.youtube.com/watch?v=91tYEgpmN4Mfeature=related http://www.youtube.com/watch?v=Ni9nAm-Thswfeature=related ..further hacks... ;o) http://www.youtube.com/watch?v=aiNX-vpDhMofeature=related http://www.youtube.com/watch?v=Sw4RvwhQ73Efeature=related http://www.youtube.com/watch?v=cVCghLfdzsYfeature=related -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Canvas/C++ bindings: Simgera compilation fails with MSVC
Another heads up. Alan commit 392ba18ff7295f2622ae3a052049c76e9d760e26 Author: Thomas Geymayer Date: Thu Nov 15 21:17:33 2012 +0100 Canvas/C++ bindings: automatically detect dynamic type of polymorphic exposed classes MSVC output:- 5 cppbind_test.cxx 5c:\flightgear\simgear\simgear\nasal\cppbind\Ghost.hxx(282): error C2276: '' : illegal operation on bound member function expression 5 c:\flightgear\simgear\simgear\nasal\cppbind\Ghost.hxx(323) : see reference to function template instantiation 'nasal::GhostT nasal::GhostT::basesnasal::GhostBase(void)' being compiled 5 with 5 [ 5 T=Derived 5 ] 5 C:\FlightGear\simgear\simgear\nasal\cppbind\cppbind_test.cxx(93) : see reference to function template instantiation 'nasal::GhostT nasal::GhostT::basesBase(void)' being compiled 5 with 5 [ 5 T=Derived 5 ]-- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Alan wrote: -Original Message- From: ThorstenB Sent: Thursday, November 15, 2012 7:09 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Apparently the path checker somehow mismatches the given file path and the fg-aircraft path. This is obviously caused by the conversion of the path to an absolute path - but it's strange since absolute paths should certainly work (and they are what should normally be given on the command-line in the first place, so the conversion should not really have changed anything, except for those who were using relative paths - but those weren't even working before). We either need someone running Windows to debug this. Alternatively, please provide the exact values of the * fg-aircraft command-line parameter (--fg-aircraft=...) * The value of the /sim/fg-aircraft property (see property tree) * The exact path given in the error message (loadxml: reading '...' denied) Make sure to copy the paths exactly as shown - even tiny differences (such as / vs \, or an appended extra slash may make a difference). cheers, Thorsten -- Thortsen Here is my system.fgsrc file and then the log output.~ My TSR2, if you need it, is at g...@gitorious.org:fg-ajt/tsr2.git. The final Nasal error (nil used in numeric context) only occurs when I use the new version of simgear/misc/sg_path.cxx. Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. In each case the property /sim/fg-aircraft is that specified by --fg-aircraft=, except that the trailing \ is discarded. I ran flightgear with the command: C:\FlightGear\install\msvc100\bin\fgfs.exe fgfsrun.txt 21 system.fgsrc:- --fg-root=C:/FlightGear/fgdata --fg- scenery=C:\FlightGear\MyScenery;C:\FlightGear\Terrasync;C:\FlightGear\fli ghtgear --fg-aircraft=C:\FlightGear\MyAircraft --airport=EGNO --aircraft=TSR2 --control=joystick --enable-random-objects --enable-horizon-effect --enable-enhanced-lighting --enable-ai-models --enable-real-weather-fetch --enable-clouds3d --prop:/sim/frame-rate-throttle-hz=60 --prop:/sim/traffic-manager/enabled=0 --geometry=1024x768 --visibility-miles=30 --bpp=32 --log-level=alert --timeofday=noon --enable-rembrandt Log file: No GAIN specified (default: 1.0) loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/config.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-main.nas, line 26 Switches.nas Annunciator.nas controls.nas timers.nas electrical.nas Engine-Start-Stop.nas TSR2 undercarriage.nas settimer(gearLights, 0); navradiodisplay.nas g-meter.nas ice-warn.nas Init properties.nas startup.nas dropview.nas TSR2-moving-map.nas TSR2 autopilot.nas TSR2 contrail.nas TSR2 liveries.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Models/Liveries/BlackTest.xml' denied (unauthorized access) Nasal runtime error: non-objects have no members at C:/FlightGear/fgdata/Nasal/gui.nas, line 479 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 460 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 450 called from: C:/FlightGear/fgdata/Nasal/aircraft.nas, line 519 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/liveries.nas, line 4 dialogs.nas loadxml: reading 'C:/FlightGear/MyAircraft/TSR2/Dialogs/TSR2-autopilot-dlg.xml' denied (unauthorized access) Nasal runtime error: Dialog class: XML dialog must have name at C:/FlightGear/fgdata/Nasal/gui.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/gui.nas, line 334 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: container index not scalar at C:/FlightGear/fgdata/Nasal/gui.nas, line 336 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-dialogs.nas, line 7 TSR2 canvas HUD.nas loading scenario 'nimitz_demo' map init-props moving map loaded Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 276 called from: C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-canvas-HUD.nas, line 354 called from: C:/FlightGear/fgdata/Nasal/globals.nas, line 100 Nasal runtime error: nil used in numeric context at C:/FlightGear/MyAircraft/TSR2/Nasal/TSR2-g-meter.nas, line 14 icewarn I hope that this helps debug the problem. I was going to check on my version of FG/SG pulled today with MCVC10 but it failed with:
[Flightgear-devel] Next FlightGear release (Feb. 17 2013)
Hi, in just about one month from now we are entering another round of the release process, starting with the four weeks feature freeze period. This is probably a good time to check in all the great and fancy new features that still hide in your local branches. I'd also like to see JSBSim synced before December, 17th. How should we call our new baby? Is it 3.0.0 or is it 2.10.0? This is a carry-over from our last release and gets answered along with: Is Rembrandt production ready? I'd also like to use the remaining four weeks to walk through the Lessons Learned section of our Release Plan (http://wiki.flightgear.org/index.php/Release_Plan#Lessons_learned) Somebody was kind enough to add a few points worth thinking about: 1. A lack of stress testing. We have a four weeks testing period with release binaries publically available, so I am not sure how to improve that. Do we need more testers? Do we need more time? 2. Lack of graceful feature scaling. Is this really something we can solve in the release process? 3. Change of the NOAA METAR url Also, this is more a bug or feature request than an issue with the release process 4. broken OSX downloads Yes - we need to improve the OSX builds. Does Jenkins provide stable binaries or do we still need a manual build provided by James or Tat? 5. Irritation caused by code signing Probably same as 4.? 6. GLSL errors Probably just a special case of 1. 7. Missing files in the Windows build Probably just a special case of 1. 8. Write the changelog ASAP Yes - That can easily start right now. As it is just a simple wiki page, please contribute to http://wiki.flightgear.org/Changelog_3.0.0 9. Lifting the code freeze for certain new features. As a clarification: We do not enter a code freeze but a feature freeze. Code changes are welcome after December 17th as long as it is guaranteed (not just unlikely) that they do not introduce any side effects and become a release blocker. It is the sole responsibility of the commiter to decide if that is the case or not. Every new feature that didn't make it into the respository by the deadline may probably easily wait for another four weeks to get commited. Remember: most aircraft are not affected by the feature freeze and aircraft developers quickly adopt and use new features as they become available. 10. Updating the wiki w.r.t. hardware recommendations Yes - this is a task for everybody. Last, but not least: Will we be able to create release binaries for our three major platforms automatically and probably release candidates for them on a regular schedule (e.g. once a week) from the same code base using the same pre-release version number? Thanks for reading that awfully long post ;-) Torsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Canvas/C++ bindings: Simgera compilation fails with MSVC
Am 2012-11-16 14:12, schrieb Alan Teeder: Another heads up. Thanks. Fixed. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 2012-11-16 14:39, schrieb Vivian Meazza: It has also failed to build in Jenkins with the same error. When someone gets around to fixing it I'll try to test again. Just as an aside, would it be possible to test for developers to test their inputs BEFORE they get pushed into Gitorious? I always test my code before pushing anything to gitorious. The problem is that I have not always access to a computer running Windows and Visual Studio so sometimes I have just to rely on the output of Jenkins. Especially the last commits made heavy use of templates where VS seems to be very buggy. If something doesn't work I normally fix it within a few hours, so sorry for any inconveniences if you happen to checkout before I've been able to push a fix. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Canvas/C++ bindings: Simgera compilation fails with MSVC
Now compiles and runs OK. Thanks Alan -Original Message- From: Thomas Geymayer Sent: Friday, November 16, 2012 3:01 PM To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Canvas/C++ bindings: Simgera compilation fails with MSVC Am 2012-11-16 14:12, schrieb Alan Teeder: Another heads up. Thanks. Fixed. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Next FlightGear release (Feb. 17 2013)
On Fri, 16 Nov 2012 15:27:52 +0100, Torsten wrote in message 50a64d68.80...@t3r.de: in just about one month from now we are entering another round of the release process, starting with the four weeks feature freeze period. This is probably a good time to check in all the great and fancy new features that still hide in your local branches. I'd also like to see JSBSim synced before December, 17th. ..this is too late for e.g. commercial actors who might wanna stick a FG-3.0.0 dvd on their Christmas magazines, looong lead times. How should we call our new baby? Is it 3.0.0 or is it 2.10.0? ..if we want to adjust to other peoples long lead times, cases can be made for delaying 2.10 into March (Because it's not ready) or for 2.12 around Easter and 2.14 next Soptember to celebrate my election into parliament or whatever. Just an idea. ;o) This is a carry-over from our last release and gets answered along with: Is Rembrandt production ready? ..this would be a 3.0.0 trigger. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...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. -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Tracking BitTorrent fgdata-update02.bundle download
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, there is now a second (incremental) update bundle available: http://www.flightgear.org/forums/viewtopic.php?f=17t=17268 The tracker itself can be found here: http://mxchange.org:23456/ This is for people where git causes to much connection losses and forces them to restart the whole download as git doesn't support resume. Regards, Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCmmNgACgkQty+BhcbHvXiYKgCgxBcrtY/LC1TNUKj71ueF3CLO h6wAoKeSWKboWOMAs0Go4NehIL0QTwxj =yqsu -END PGP SIGNATURE- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 10:13, schrieb Alan Teeder:
Changing --fg-aircraft=C:\FlightGear\MyAircraft
to --fg-aircraft=C:\FlightGear\MyAircraft\ ,
or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect.
Pull latest fgdata and see if it has any effect.
Is it possible that things were only working before, when the path given
for --fg-aircraft used / instead of the usual Windows \ path
separator? There was something goofed up in Nasal/io.nas, which suggests
this should have been the case.
If it's still not working, replace your fgdata/Nasal/io.nas with the
attached version, run fgfs, reproduce the issue and send the log output
to me (default log settings are enough).
cheers,
Thorsten
# Reads and returns a complete file as a string
var readfile = func(file) {
if ((var st = stat(file)) == nil)
die(Cannot stat file: ~ file);
var sz = st[7];
var buf = bits.buf(sz);
read(open(file), buf, sz);
return buf;
}
# Loads Nasal file into namespace and executes it. The namespace
# (module name) is taken from the optional second argument, or
# derived from the Nasal file's name.
#
# Usage: io.load_nasal(filename [, modulename]);
#
# Example:
#
# io.load_nasal(getprop(/sim/fg-root) ~ /Local/test.nas);
# io.load_nasal(/tmp/foo.nas, test);
#
var load_nasal = func(file, module = nil) {
if (module == nil)
module = split(., split(/, file)[-1])[0];
printlog(info, loading , file, into namespace , module);
if (!contains(globals, module))
globals[module] = {};
elsif (typeof(globals[module]) != hash)
die(io.load_nasal(): namespace ' ~ module ~ ' already in use, but
not a hash);
var code = call(func compile(readfile(file), file), nil, var err = []);
if (size(err)) {
(func nil)(); # FIXME hack around
Nasal bug
if (substr(err[0], 0, 12) == Parse error:) { # hack around Nasal
feature
var e = split( at line , err[0]);
if (size(e) == 2)
err[0] = string.join(, [e[0], \n at , file, , line ,
e[1], \n ]);
}
for (var i = 1; (var c = caller(i)) != nil; i += 1)
err ~= subvec(c, 2, 2);
debug.printerror(err);
return 0;
}
call(bind(code, globals), nil, nil, globals[module], err);
debug.printerror(err);
return !size(err);
}
# Load XML file in FlightGear's native PropertyList format.
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_properties(filename [, props.Node or property-path]);
#
# Examples:
#
# var target = props.globals.getNode(/sim/model);
# io.read_properties(/tmp/foo.xml, target);
#
# var data = io.read_properties(/tmp/foo.xml, /sim/model);
# var data = io.read_properties(/tmp/foo.xml);
#
var read_properties = func(path, target = nil) {
var args = props.Node.new({ filename: path });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Load XML file in FlightGear's native PropertyList format.
# file will be located in the airport-scenery directories according to
# ICAO and filename, i,e in Airports/I/C/A/ICAO.filename.xml
# If the second, optional target parameter is set, then the properties
# are loaded to this node in the global property tree. Otherwise they
# are returned as a separate props.Node tree. Returns the data as a
# props.Node on success or nil on error.
#
# Usage: io.read_airport_properties(icao, filename [, props.Node or
property-path]);
#
# Examples:
#
# var data = io.read_properties(KSFO, rwyuse);
#
var read_airport_properties = func(icao, fname, target = nil) {
var args = props.Node.new({ filename: fname, icao:icao });
if (target == nil) {
var ret = args.getNode(data, 1);
} elsif (isa(target, props.Node)) {
args.getNode(targetnode, 1).setValue(target.getPath());
var ret = target;
} else {
args.getNode(targetnode, 1).setValue(target);
var ret = props.globals.getNode(target, 1);
}
return fgcommand(loadxml, args) ? ret : nil;
}
# Write XML file in FlightGear's native PropertyList format.
# Returns the filename on success or nil on error. If the source
# is a props.Node that refers to a node in the main tree, then
# the data are directly written from the tree, yielding a more
# accurate result. Otherwise the data need to be copied first,
# which may slightly change node types (FLOAT becomes DOUBLE etc.)
#
# Usage: io.write_properties(filename,
Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: ThorstenB Sent: Friday, November 16, 2012 8:18 PM To: FlightGear developers discussions Subject: Re: [Flightgear-devel] Bug 479 has come back Am 16.11.2012 10:13, schrieb Alan Teeder: Changing --fg-aircraft=C:\FlightGear\MyAircraft to --fg-aircraft=C:\FlightGear\MyAircraft\ , or to --fg-aircraft=C:/FlightGear/MyAircraft has no effect. Pull latest fgdata and see if it has any effect. Is it possible that things were only working before, when the path given for --fg-aircraft used / instead of the usual Windows \ path separator? There was something goofed up in Nasal/io.nas, which suggests this should have been the case. If it's still not working, replace your fgdata/Nasal/io.nas with the attached version, run fgfs, reproduce the issue and send the log output to me (default log settings are enough). cheers, Thorsten Thorsten It all works out of the (git) box now. I have not tried the io.nas that you attached to your post, but can do if you wish. Thanks Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Am 16.11.2012 22:28, schrieb Alan Teeder: It all works out of the (git) box now. I have not tried the io.nas that you attached to your post, but can do if you wish. No need to, if it's working now. I believe we've fixed another old and ugly bug here, requiring Windows users to use Unix-style paths for some command-line parameters to make Nasal access work (namely for --fg-aircraft and --fg-scenery). The realpath patch only extended the existing issue - since realpath converts Unix-style paths back to proper Windows-style paths - so now the issue also caught those using Unix-style paths as a work-around so far. Thanks, Thorsten -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
Tom wrote: -Original Message- From: Thomas Geymayer [mailto:tom...@gmail.com] Sent: 16 November 2012 15:07 To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] Bug 479 has come back Am 2012-11-16 14:39, schrieb Vivian Meazza: It has also failed to build in Jenkins with the same error. When someone gets around to fixing it I'll try to test again. Just as an aside, would it be possible to test for developers to test their inputs BEFORE they get pushed into Gitorious? I always test my code before pushing anything to gitorious. The problem is that I have not always access to a computer running Windows and Visual Studio so sometimes I have just to rely on the output of Jenkins. Especially the last commits made heavy use of templates where VS seems to be very buggy. If something doesn't work I normally fix it within a few hours, so sorry for any inconveniences if you happen to checkout before I've been able to push a fix. Tom Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 11/16/2012 11:48 PM, Vivian Meazza wrote: Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian Some revisions ago, the A380 was fine, now some buttons in overhead panel are incorrectly shown. Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCmw0kACgkQty+BhcbHvXjCnACfWJeosrhR4FFboHybJdN9vf1I PeMAoLEb4jt+Si4+ZE+CQPrPjVyoClsj =MUCZ -END PGP SIGNATURE- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug 479 has come back
-Original Message- From: Vivian Meazza Sent: Friday, November 16, 2012 10:48 PM To: 'FlightGear developers discussions' Subject: Re: [Flightgear-devel] Bug 479 has come back Always happy to help with testing - although probably not fixing work-arounds for MSVC10 shortcomings. All built here now - and all seems to be working as it should with my models anyway - is there any particular aircraft which is causing problems? Vivian Vivian This only affected aircraft outside the fgdata/aircraft path e.g. /fgdata/myaircraft/foobird. Even then (AFAIK) it only affected dialogues and livery schemes on windows boxes, so it would not have been apparent to many users/developers. It did get me on all of those counts ;-( Alan -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Crash on exit
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi all, I got this crash: http://pastie.org/5389947 I think line 18 is most interesting: corrupted double-linked list Regards, Roland -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAlCmxmAACgkQty+BhcbHvXi9nACdE0dTQHIPXwwnzPoznbufociS YZoAnA5n5+ryTFcBR0WLzCeReuvTLfiW =haNQ -END PGP SIGNATURE- -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-commitlogs] FlightGear branch, next, updated. fe1222a90dd809560e787ce09391d5cf97bbe6fe
Am 2012-11-15 14:01, schrieb James Turner: Maybe they already exist, but some wiki docs on using the perf tools (optionally!) might be interesting; Now they exist: http://wiki.flightgear.org/Built-in_Profiler it's not something I have time to look at right now, but I already saw some discussion about it a few months ago. Yes. Hooray has suggested adding the profiling commands while speeding up the airport selection dialog. Tom -- Thomas Geymayer www.tomprogs.at / C-Forum und Tutorial: www.proggen.org Student of Computer Science @ Graz University of Technology --- Austria -- Monitor your physical, virtual and cloud infrastructure from a single web console. Get in-depth insight into apps, servers, databases, vmware, SAP, cloud infrastructure, etc. Download 30-day Free Trial. Pricing starts from $795 for 25 servers or applications! http://p.sf.net/sfu/zoho_dev2dev_nov ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
