Re: [Flightgear-devel] Who turned the sun off?
On 07.05.2011 10:20, Alan Teeder wrote: Ever since the atmospheric scatter patches went in I have had black sky, instead of blue. If I turn on material shaders, then there is a small area of blue close to the horizon, but that is the best I an achieve. The attached is from my TSR2 cockpit with shaders off. Which OSG revision? Saw the same effect when I experimented with latest OSG trunk last week. Sky turned black when attempting to render fog. Since there were also other issues (text display and clouds not working) I reverted back to OSG 2.9.9. Not seeing any issues now. cheers, Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
On 18.04.2011 23:13, Maik Justus wrote: By the way: I would prefer to use the old default values for the gear solver. The spring constants of a gear should not be a function of the approach fuel settings. Maybe some gears would need some tuning with the patch otherwise. The _approachWeight = _emptyWeight + totalFuel*_approachFuel; should be moved behind the gear solver call. What's the status here, do we want to change this? Would anyone provide a patch? cheers, Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] crash sort of related to sound on exit
On 03.05.2011 19:42, Curtis Olson wrote: The code seems pretty definite that it would execute here, so it's odd that you are getting NULL there ... unless the sgmgr-find() call is returning null for you? Or if like you say, somehow our source trees have diverged. But I do think I'm 100% current with git. Ha. I hadn't pulled the latest GIT update for wind-moving-clouds yet. fgclouds-init() was never called in earlier GIT versions, so indeed sampleGroup was always NULL so far. That changed with the recent FG 3D cloud update - hence the sampleGroup issue appeared. So, it's good you've found/fixed this. cheers, Thorsten -- WhatsUp Gold - Download Free Network Management Software The most intuitive, comprehensive, and cost-effective network management toolset available today. Delivers lowest initial acquisition cost and overall TCO of any competing solution. http://p.sf.net/sfu/whatsupgold-sd ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim issues
On 18.04.2011 14:51, Adrian Musceac wrote: On Monday, April 18, 2011 01:09:56 Heiko Schulz wrote: I had a fix locally but with the patch fixing the YASim issue I have now to begin again. I see the problem in the airfoil, but a change to this means that I have to change a lot of other parameters as well to keep the behavior 100% correct. Means a lot of tuning I took a quick look inside the FDM file. Unless your version is significantly different than mine, this patch should not affect the behaviour. There is no mention of cruise glide angle or approach and cruise fuel levels inside the file. The defaults provided inside FGFDM.cpp are the same as those that were previously hardcoded in Airplane.cpp. Maybe the problem is not at all related to this change? And you also checked that approach glide angle isn't used? Otherwise, the new default cruise angle (0.0) might not match the original approach angle setting... Anyway, we've committed the patch since it was assumed to not cause major differences. These bugs have been there since the beginning of YASim - so for 10+ years. If it's confirmed that the patch actually caused major differences, then we should improve the patch. We could restore the old buggy behaviour by default and only use the new correct FDM configuration behaviour for new FDMs, e.g. add a switch, such as a new FDM parameter or YASim FDM version number in the xml file to enable the bugfix. Heiko, and anyone else: if you think there is a major change, then directly compare the FDM behaviour with and without the patch - and let us know if there was trouble. And that's the relevant patch: http://www.gitorious.org/fg/flightgear/commit/7f5a0e35184677c21f1eafdfbe6438eb644cdbff cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On 16.04.2011 21:16, Anders Gidenstam wrote: If I'm not mistaken the particles issue has been around since we got particles, so it is apparently not that bad (leak and race condition) in practice. Ok, thanks! I've create a bug issue as a reminder, in case someone else noticed the issue some day. http://code.google.com/p/flightgear-bugs/issues/detail?id=305 Not sure, but I guess the issues with Effect objects is probably worse than with particles. There's a larger number of Effect objects - and each is connected to a texture (.rgb/.png images) - which may occupy a lot of memory. Just by starting at KSFO, loads of KSFO terminal textures - and textures of 15 different MP aircraft immediately stick in memory... Yes, the big textures will eat memory fast. Particle systems usually use small textures (the effect of the accumulation of particle system updaters is noticeable with wildfire, though - but you'd need a lot of MP aircraft passing through to generate anywhere near those numbers of particle systems). The effect/texture mystery is also solved - alas - explained. There is a global cache in simgear/makeEffect.cxx (effectMap), and it has no condition to ever drop anything. So, created effects always stay in memory until shutdown - hence also their textures. If that's used for scenery/MP aircraft a lot, it _might_ accumulate a lot of memory. Tim might know more about this :). cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] XML formating Was: [Flightgear-commitlogs] FlightGear Base Package branch, master
Mixing spaces and tabs is really ugly - I think cleaning up such a mess is good. Many people like tabs, but disadvantage is that everyone uses a different tab settings. Most editors I know use 4 or 8 spaces/tab as the default. But since it's different for everyone, I personally prefer spaces - at least for collaborative projects. Guaranteed to be working for everyone and looks the same with every editor. cheers, Thorsten On Sat, Apr 16, 2011 at 2:24 PM, Heiko Schulz aeitsch...@yahoo.de wrote: Well, at least it explains for me the many whitespace errors when updating my datas To be honest, I'm not happy about this. And I never had probelms to read the files. Fred wrote Is it wise to reformat preferences.xml with a tab length set to 2 ? Well, it's better than the current mess of spaces and tabs. At least we can now read it. *You* can read it with your own MSVC preferences Yes, I know that very well. But I hate a mess - it looks unprofessional. I'd fix up the rest of the mess given half a chance. Vivian -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
Hi,
had another look at memory consumption. The FG multiplayer (=AI)
aircraft classes seem fine - they are created/removed as expected. But
there are problems with some of our OSG-based simgear classes: they
are never removed at run-time - hence memory is eaten up.
Problems start at simgear::Effect. Their parent objects
(simgear::EffectGeode) are still removed when the related model
disappears from the scene graph. But simgear::Effect objects stick in
memory, until exiting FG. Their reference counter shows that there
must be (forgotten) references to each of them somewhere (but they are
no longer members of the scene graph). Attached is a simple patch
logging Effect constructor/destructor calls. Shows that not a single
Effect::~Effect destructor is called at run-time - though we
continuously create new objects. Effect objects own 2D textures
(images), techniques, etc - so they have considerable memory impact.
Any suggestions on how to trace the cause?
New Effect objects are created when new MP aircraft join or new
scenery areas are loaded. So, no surprise there are issues with large
MP events/long distance flights.
Another observation: I started an MP session at KSFO (lots of MP
aircraft), then warped to the middle of nowhere (no MP aircraft).
After about 30min I dumped the scene graph. Surprisingly, loads of
osg::particles were still *in* the scene graph, referring to aircraft
specific smoke and contrail textures. I would have expected them to be
dropped from the scene graph after some time - or when we move to a
very distant position. Maybe there's another issue.
For me, this is all independent from enabling/disabling the OSG cache.
But maybe it's worse now, since we have more advanced aircraft, making
more use of effects and particles. And I guess the pretty local
weather clouds also make use of these.
cheers,
Thorsten
diff --git a/simgear/scene/material/Effect.cxx b/simgear/scene/material/Effect.cxx
index 6517bd2..314d131 100644
--- a/simgear/scene/material/Effect.cxx
+++ b/simgear/scene/material/Effect.cxx
@@ -83,15 +83,19 @@ using namespace osgUtil;
using namespace effect;
+static unsigned long EffectCount=0;
+
Effect::Effect()
: _cache(0), _isRealized(false)
{
+printf(%4lu Effect::Effect()\n,++EffectCount);
}
Effect::Effect(const Effect rhs, const CopyOp copyop)
: root(rhs.root), parametersProp(rhs.parametersProp), _cache(0),
_isRealized(rhs._isRealized)
{
+printf(%4lu Effect::Effect(..)\n,++EffectCount);
typedef vectorref_ptrTechnique TechniqueList;
for (TechniqueList::const_iterator itr = rhs.techniques.begin(),
end = rhs.techniques.end();
@@ -149,6 +153,7 @@ void Effect::releaseGLObjects(osg::State* state) const
Effect::~Effect()
{
+printf(%4lu Effect::~Effect(..)\n,--EffectCount);
delete _cache;
}
--
Benefiting from Server Virtualization: Beyond Initial Workload
Consolidation -- Increasing the use of server virtualization is a top
priority.Virtualization can reduce costs, simplify management, and improve
application availability and disaster protection. Learn more about boosting
the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] release discussion
On 15.04.2011 22:22, Bertrand Coconnier wrote: Yes, a bug fix has been committed to fix instant replay with JSBSim aircraft (bug #294) https://gitorious.org/fg/flightgear/commit/11320e6b008eb85b8dff66a137f671743cc04580 I think it should be applied to 2.2.0 as well. Ok, thanks Betrand! That would also be on the list. But we should decide first if and when we're going to have a release (well, do we want one at all? :) ). No use to spend more time on the branch, if we're not going to use it. cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] props protocol problem
On 16.04.2011 02:06, Pascal J. Bourguignon wrote: The props data protocol ls command has a problem: there's no way to determine that its output is complete (unless we use a timer, which would mean that all ls commands would suspend the client for the time out duration). I'm proposing to add a lsx command, similar to ls, but that will terminate its output with an empty line. Hi Pascal, before we duplicate commands: couldn't you detect output completion by reading until the prompt? When output is complete, the server prints a linefeed (\n) and a / (followed by an optional property path and ). Should be easy to parse. Ok, the prompt is only printed in PROMPT mode (obviously). There is no prompt in RAW mode. But then it might be better to add another output mode, i.e. a mode similar to RAW which completes _every_ existing command with a specific character sequence, such as an additional linefeed. Adding another command (lsx) wouldn't cost much - but then we should also add new versions of all other commands (getx, dumpx, runx, ...) for the same reason. So, a different output mode seems a better solution? Or also possible: just add a new option to configure the prompt in PROMPT mode. So everyone can configure this to his needs. To see what I mean, try export PS1=FOO\nBAR\n in your linux console - or set prompt=#FOOBAR# in your Win-DOS box. Might be a better solution if you added something similar to props.cxx. Any other thoughts? cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On 16.04.2011 16:24, Anders Gidenstam wrote: On Sat, 16 Apr 2011, Anders Gidenstam wrote: Hmm.. I should have added that I looked at this in early September last year so it is not fresh in my memory. IIRC the current code already does the fundamentaly unsafe operation of adding items to a STL vector (in the loader thread) while concurrent traversals of the same vector are possible (by various parts of OSG rendering). That is NOT SAFE but a lot less risky than deleting from an STL vector with concurrent traversal (consider the most likely internal representation of a STL vector to see why). Ok, thanks a lot Anders for these hints! I'll open a tracker issue for the particle issue - so we won't forget these details. Can you estimate on how bad this issue could get? Does it only mean a minor memory leak - or could it get really bad over time (maybe eat some gigabytes in a 6 hour TGA shift? :) ). Not sure, but I guess the issues with Effect objects is probably worse than with particles. There's a larger number of Effect objects - and each is connected to a texture (.rgb/.png images) - which may occupy a lot of memory. Just by starting at KSFO, loads of KSFO terminal textures - and textures of 15 different MP aircraft immediately stick in memory... cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Valgrind logs
On 15.04.2011 11:11, Andreas Gaeb wrote: The input value lists seems to fulfil both conditions (SGSharedPtr pointing to SGReferenced), so in theory, automatic deletion should work here. Still, valgrind complains. Could the problem here be related to calling the componentForge functor? Remember that SGReferenced does reference counting. In theory, the root cause could be completely elsewhere in the code, if there were other references to the same InputValue. If only a single of these references wasn't removed, then the actual InputValue object is never deleted (and let's hope there are no cyclic references anywhere...). cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] release discussion (was: Simple atmospheric scattering shader)
On 14.04.2011 18:22, Curtis Olson wrote: Yeah, we should get back to that. What is the current status? I have spend a lot of time doing the prepatory work for an eventual release during my holiday, but apparently no release has happened during my absence. Are there still any showstoppers? I seem to recall James mentioned the a couple issues remained, but I don't recall ever hearing specifically what those issues where. He has been buried by real life lately so he hasn't had the chance to jump in much lately. I haven't heard much from Tim either. The remaining issues James was working on were concerning the automatic build process. He was close to finishing and make Hudson provide _complete_ (that is including _basic_ fgdata) installers for Mac/Windows. There were remaining issues due to the huge size of the installers though - since data gets copied over the network. And then he got buried under a pile of RL work for a while. The 2.2 release itself was branched in January (first sg+fg and a few weeks later also fgdata). And I think we've fixed all the show stoppers for the 2.2 branch. We've had a few more fixes on the next branch since, but these mainly affected new code issues, which were not yet part of 2.2. I think the release branch got a fair amount of testing - and is very stable (feels much more stable than 2.0 to me, if I may say :) ). So, as far as I'm concerned, if we can manually provide Mac/Windows installers, we could just tag and release now (come on, let's have a new release to show off at LinuxTag! :) ). The 2.2 branch may look a little outdated to git/next users by now. But I'd still stick with releasing the existing branch as 2.2. We've already committed lot's of new code to next since, so that would take more work/time to be ready. And we can still have another release (2.3/2.4) in a few months - and don't need to wait for another year again... cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On 13.04.2011 13:46, Frederic Bouvier wrote: To reduce memory footprint caused by model caching, I added this code to the begining of the main function of fgrun : osgDB::Registry* registry = osgDB::Registry::instance(); registry-setExpiryDelay( 0. ); I suspect we can control the amount of caching the same way in FG The default expiration delay is 10 seconds. Any texture/image/... which isn't referenced any longer should automatically be purged after 10 seconds. Reducing it to 0 shouldn't help too much - just save 10 seconds worth of memory. But it would void performance benefits when stuff get's dropped and then reloaded immediately, e.g. you do a sim reset or the MP connection has a brief drop-out (I sometimes see MP models disappear and reappear after a few seconds). The real problem should be elsewhere: * either the whole OSG caching system just doesn't work at all, i.e. it never purges unreferenced and expired data (I somehow doubt this). * we somehow haven't implemented the caching thing correctly (no idea what we could be missing) * or it's all our fault, our leak alone - more or less unrelated to caching. I think the latter is (still) the case. I already posted some weeks ago that I was seeing loads of leaked objects. I managed to fix a few things at the time http://www.gitorious.org/fg/simgear/commit/44f27b23d0209d2ee9f508c43def5636564bb302 http://www.gitorious.org/fg/flightgear/commit/4761a3cdcf04771819b3a8de9d018fca20c90ca6 http://www.gitorious.org/fg/flightgear/commit/8962477cfa10850cb459d7de754c9a435cc91293 but that wasn't all of it by far. Still looked leaky as a sieve to me :| and mainly affected MP models, clouds (global weather based) and SG animation stuff - and thousands of properties connected to these. The longer FG was running (or the more players joined and left) the more objects were leaked. And that was long before we enabled the OSG cache. I never ran FG for 6 hours with clouds MP enabled though. But are we sure that the OSG cache itself really made a major difference now? The thing is that we do have a lot of automatic pointers (objects with reference counting) in our code. It's all our classes based on OSG and all the SGShared... properties/classes. It's very tricky to find out if everything is working as expected here, since it's hard to tell when something should be removed. A simple mistake somewhere (like a non-virtual destructor in a base class), a single object which doesn't get disconnected - and a huge object tree connected to it never get's removed. It'd certainly be worth to investigate further and fix more leaks - but debugging these issues is painful and requires a long and tricky hunt. Any help would be appreciated... cheers, Thorsten -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Joystick axis issues
Hi, I'm having joystick issues: on start-up, all axis are in left-most/lower-most position (reporting -1). Only once I have moved each axis for the first time, do I get valid positions. Hardly noticeable with most planes, since -1 means throttle is idle - so full left-rudder/pushed-aileron has no effect. But starting the UFO is annoying, as it's spinning around all three axis at full speed by default - until I have moved all joysticks. Wasn't like this maybe a month or two ago. And I have tested different joysticks. Anyone else seeing this? Test: start the UFO, keep away from joysticks, see what happens... I have a local patch which fixes things for me - but I may be fixing local/system issues here. cheers, Thorsten -- Benefiting from Server Virtualization: Beyond Initial Workload Consolidation -- Increasing the use of server virtualization is a top priority.Virtualization can reduce costs, simplify management, and improve application availability and disaster protection. Learn more about boosting the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] download_and_compile.sh script link
On 11.04.2011 17:29, Francesco Angelo Brisa wrote: well ,I will make some experiments on 2.9.10 if it finds out to compile easly and to be quite stable, I will make it the default behaviour, with 2.8.3 as stable option. When we last discussed this (February), 2.9.9 was reported to be stable with FlightGear on all three platforms (Linux/Mac/Windows) with fg/next - no issues were reported since. But meanwhile we've updated FlightGear to also support the latest OSG interface (= 2.9.10). Concerning the OSGText issue, there is also a bug tracker entry on this: http://code.google.com/p/flightgear-bugs/issues/detail?id=268 We don't know if OSG 2.9.10 is also affected - or only = 2.9.11. Would be good if someone could verify. While, as you point out, using OSG-2.8.3 stable will ALWAYS works, and I know OSG-2.9.9 also works, recent posts indicate OSG-trunk will _ALSO_ compile, but I have yet to fully personally 'verify' this... But perhaps this should be a user 'option' to the script... Well, OSG-trunk compiles - today. If an option to use OSG-trunk is really necessary (is it?), then please hide it well enough so that normal users won't find it. :) cheers, Thorsten -- Forrester Wave Report - Recovery time is now measured in hours and minutes not days. Key insights are discussed in the 2010 Forrester Wave Report as part of an in-depth evaluation of disaster recovery service providers. Forrester found the best-in-class provider in terms of services and vision. Read this report now! http://p.sf.net/sfu/ibm-webcastpromo ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..simgear(?) link error, undefined references to SGPagedLOD
On 10.04.2011 13:29, Geoff McLane wrote: As far as I am aware we can _NOT_ presently use later that OSG-2.9.9 ;=(( Yes, we can. But 2.8.3 + 2.9.9 are used by the automatic download compile script, since these versions are known to work fine. And as we noticed, we have a lot of people running the FG git version right now, not all of them are actually FG developers or even familiar with building their own binaries (which is why the build script is there in the first place). So, it's good to have something that's stable and known to work for them. On a general note, I would ask are there any thoughts to modify simgear to use later, or even the trunk versions of OSG? It always takes some days to adapt sg/fg to OSG changes, but right now, it compiles just fine, as the Hudson builds show: http://flightgear.simpits.org:8080/job/Simgear-with-OSG-svn/ I wouldn't recommend using OSG trunk to any normally advanced flightgear git user. Those who need it know what to do - and won't be using the convenience downloadcompile script anyway. cheers, Thorsten -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ..simgear(?) link error, undefined references to SGPagedLOD
On 10.04.2011 15:02, Geoff McLane wrote: On Sun, 2011-04-10 at 14:34 +0200, ThorstenB wrote: As far as I am aware we can _NOT_ presently use later that OSG-2.9.9 ;=(( Yes, we can. Huh? Then WHY does Arnt have a LINK problem with OSG-2.9.11? I don't know. The error Arndt is seeing is a _linker_ error - not a compile error. Csaba has already given the reason in his earlier email: mismatching OSG header and library files (messed up local installation). Another possibility is an incomplete build after changing the OSG version (run make clean in sg/fg). In any case, that's not our fault. If sg/fg wasn't adapted to the OSG version, you would get a _compile_ error - not a linker one. Yes, I know it can take 'some days', and no criticism is intended, but 2.9.10, the first after 2.9.9 was released 3rd December, 2010, and others 2.9.11, etc later... maybe you meant 'some MONTHS' ;=)) No. Both Brisa's and my script use 2.8.3 or 2.9.9, but have a switch for 'trunk', and would code for later if workable... No. After getting lots of reports and complaints due to OSG-trunk issues, we changed the Brisa's script to stop using OSG trunk: http://www.gitorious.org/fg/fgmeta/blobs/master/download_and_compile.sh When you suggest Hudson is using OSG-svn - If _NOT_ trunk then exactly which version of OSG-svn is used by Hudson? OSG trunk = OSG svn. It's compiling (and linking) fine. cheers, Thorsten -- Xperia(TM) PLAY It's a major breakthrough. An authentic gaming smartphone on the nation's most reliable network. And it wants your games. http://p.sf.net/sfu/verizon-sfdev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG caching (was: Texture cache)
Maybe someone could do some tests when changing the setting (SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to CACHE_ALL (then recompile/install sg+fg). Would be interesting to know how this changed loading times, run-time fps and memory consumption. After 30 minutes more of testing: It also works in practice. I have seen no averse side effects, and the performance drop from loading new clouds is now almost completely gone - the framerate drops I still see are mainly associated with terrain sampling. The actual rendering performance is, as far as I can see, not changed, i.e. once everything is there, it is there. But all in all this makes things way smoother. It should be most pronounced on single CPU machines. I've also been using CACHE_ALL since then - not seeing any problems. But I haven't checked memory consumption. So, what's the status about the OSG caching options, should we enable these? Tim? cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG caching
On 03.04.2011 16:18, Torsten Dreyer wrote: Me, too. I had a few coredumps with the 4-nvidia-cards, 8 monitors (multithreading=automatic) setup since I had that enabled. I was not able to backtrace and blame it to the CACHING-Option, however. So this might just be a random correlation. In fact I haven't seen any crash for a very long time now (yay!). But I'm not using multi-threading, as that never worked for me. FG starts, but the scenery doesn't look right: the surface is all black and many models are only visible partially. Does this work for everyone else - maybe depends on newer OSG versions (2.9.x)? How about checking a /sim/rendering/cache property at startup? Good idea. I'll be adding this and enable it by default. Let's see if we get any user reports... (of course I'm thinking about the usual thank-you-messages from people being extremely happy with the improvements :) ). cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
Roberto, though on the wire I send precisely 7 digit numbers: 3 digits followed by a dot and 3 decimal digits); As you describe correctly, you're transmitting strings (= series of ASCII characters). typeint/type For an input protocol this is the _target_ type. With int your _string_ is parsed and converted to an _integer_. No fractions. Keep sending strings representing integers (no dot . characters in the string) but specify the _target_ typedouble/type, using offset/factors as described by Torsten. FlightGear will then parse your string, convert it to double precision floating point, and apply factors and offset. Make sure you're using FlightGear 2.2-pre-release or the current GIT version to achieve double precision. FG2.0/1,9.x only supported single precision with the generic protocol, so there was no difference between float and double. This is the commit which made double precision work for the generic protocol, and it was not part of FG2.0 yet: http://www.gitorious.org/fg/flightgear/commit/d0f6f748ed7a2ad34159e18d352e4df6c11e2cde cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal submodules / folders and optional loading
Hi, I've pushed an improvement to our Nasal script loading process. Should help with some of the issues we recently discussed. 1. Nasal scripts can now be grouped into submodules stored in separate folders (fgdata/Nasal/MyModule/*.nas). This has several advantages: - Better structure. Things like multiplayer, local weather, ... are no longer mixed-up in a single directory. - Better sequence. The Nasal scripts within a directory are loaded in random order. As soon as a script relied on other (basic) scripts, you had to delay initialization, to be sure all dependencies are available. The new subfolders are loaded after the base directory, and all the basic scripts remain in the Nasal root directory. So, submodules can now rely on all the basic stuff (like props.nas, math.nas, debug.nas, gui.nas, ...) to be already present, and don't need to delay anything with timers/listeners - at least not just to resolve dependencies. 2. The submodules are also visible in the property tree below /nasal. There are properties showing which modules are available and which are loaded. There's also a persistent enable-flag for each module, so loading specific modules can be optional now. We could add a generic GUI to enable/disable specific addons. Loading can also be controlled automatically. I've tested loading the multiplayer scripts depending on whether the multiplayer feature is actually enabled. Specific GUIs are also possible of course (such as a loading switch in the local weather GUI). Currently all module loading is done in the start-up phase. But we could easily add listeners to the modules' enable-flags though, so that they can be loaded any time - even if they were disabled during start-up (without restarting fgfs). Not loading unnecessary Nasal scripts has performance advantages (see our lengthy 1Hz stutter / garbage collector discussion). Of course, performance improvements would be even higher in the first place, when more bulky/complex things were implemented in... well, I guess that point was pretty clear now... This is the relevant commit: http://www.gitorious.org/fg/flightgear/commit/298f832d4313cdba882ca5a398efdbc7a3599789 Comments welcome. If there are no objections, I'll update fgdata/Nasal shortly, moving some initial modules to separate folders. I've tested this locally with the multiplayer, local weather, wildfire and ATC chatter scripts. cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Efficient Nasal coding (was: Stuttering at 1 Hz rate)
On 30.03.2011 08:31, thorsten.i.r...@jyu.fi wrote:
How do arrays and objects count? If an object counts as one reference,
then it's very efficient to use I guess - if every key in the hash counts
as one, then certainly less so.
Right. I believe arrays and hashs may both be implemented efficiently - so
may count as one Nasal object only. But I haven't looked into the details of
the Nasal engine itself - I just checked the discussed performance issues
and briefly looked at the garbage collector. I'm sure Andy would know all
the tricks and details, of how efficient specific constructs are :).
Can loops pile up garbage checks only for elements referenced
(theoretically) within the loop (regardless if they are actually
executed), or do they trigger the whole possible pile of Nasal to be
searched? So if someone fixes a badly written script which runs every
frame although it really doesn't need to - will that affect the load
generated by that particular script, or will it have a more general
effect?
Garbage collection is a global thing and cannot be restricted to a local
context. It always requires a complete search. Even if usless handlers are
executing, eventually their repeated execution will also trigger the garbage
collector, which then needs to recurse through all references. The load
(delay) caused by the garbage collector will hit a random Nasal line, which
happened to be running out of certain resources. Again, Andy would
probably know the details of what exactly the conditions for triggering the
garbage collector are, and what kind of operations consume these resources -
so make the g/c happen more often.
However, I have attached a simple patch which I used to generate the
statistics. So, if you're interested in optimizing the performance of your
module, apply this locally and see how the numbers and the g/c frequency are
influenced by specific changes. You'll see how many unique objects were
found, how many references had to be searched (which is what consumes most
of the time, since every reference has to be traversed), and of course
when/how often the garbage collector runs.
cheers,
Thorsten
diff --git a/simgear/nasal/gc.c b/simgear/nasal/gc.c
--- a/simgear/nasal/gc.c
+++ b/simgear/nasal/gc.c
@@ -1,9 +1,16 @@
+#define NASAL_GC_STATISTICS
+
#include nasal.h
#include data.h
#include code.h
#define MIN_BLOCK_SIZE 32
+#ifdef NASAL_GC_STATISTICS
+static int g_ObjectCount = 0;
+static int g_RefCount = 0;
+#endif
+
static void reap(struct naPool* p);
static void mark(naRef r);
@@ -37,6 +44,11 @@ static void garbageCollect()
{
int i;
struct Context* c;
+#ifdef NASAL_GC_STATISTICS
+g_ObjectCount = 0;
+g_RefCount = 0;
+#endif
+
globals-allocCount = 0;
c = globals-allContexts;
while(c) {
@@ -74,6 +86,11 @@ static void garbageCollect()
globals-deadBlocks = naAlloc(sizeof(void*) * globals-deadsz);
}
globals-needGC = 0;
+
+#ifdef NASAL_GC_STATISTICS
+printf( Nasal garbage collection statistics: objects: %u, references: %u\n,
+g_ObjectCount,g_RefCount);
+#endif
}
void naModLock()
@@ -226,11 +243,21 @@ static void mark(naRef r)
{
int i;
+#ifdef NASAL_GC_STATISTICS
+// count every traversed reference
+g_RefCount++;
+#endif
+
if(IS_NUM(r) || IS_NIL(r))
return;
if(PTR(r).obj-mark == 1)
return;
+
+#ifdef NASAL_GC_STATISTICS
+// count unique objects
+g_ObjectCount++;
+#endif
PTR(r).obj-mark = 1;
switch(PTR(r).obj-type) {
--
Create and publish websites with WebMatrix
Use the most popular FREE web apps or write code yourself;
WebMatrix provides all the features you need to develop and
publish your website. http://p.sf.net/sfu/ms-webmatrix-sf
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Replay system
On Fri, Apr 1, 2011 at 12:34 AM, Curtis Olson curtol...@gmail.com wrote: So, it might be a good idea to record all properties in an interval of a few seconds only, while only recording properties that have actually changed with every frame. That should allow to drastically reduce the amount of recorded data - and allow much longer high resolution memory recordings. And you could still fast-forward within the buffer, since you'll have a complete set of properties every now and then. It's a simple but effective compression method which is used in many areas. Pluses and minus to every approach ... determining if a property has changed by enough of a threshold amount to log the change would be extra work and could also complicate the playback, so that would have to be balanced against the potential pay off. When you get away from a fixed record format, then you need a way to identify/tag each data value along with a corresponding time stamp, so you have to give some of the space savings back ... and I would imagine to do this efficiently (space and time) could lead to some pretty complicated errr sophisticated logging code. I'm not saying that's bad, but this is a pretty complicated proposal I think when you start digging into the details. In fact, frames of tagged values is the same method we're already using in encoding data for multiplayer transmission. Though that module could also do with some improvements (*yikes* it's currently packing each 8bit string character into a 32bit value for transmission). Also, it doesn't reduce traffic by detecting unchanged values yet (UDP transmissions loose some data, so that's more tricky here, though also not impossible). Yes, the tags are additional overhead. But I'm quite convinced that this schemes outweighs the disadvantage - if we used this to encode changing values only. I checked our current recording data structure: it has a huge size of 1160 bytes for every frame. Also, the fixed structure needs to reserve space for the maximum number of wheels/engines/tanks etc - so even if an a/c has fewer tanks/.., it still uses up the space. And it doesn't work for aircraft which somehow exceed the default (btw, I saw a maximum of 4 tanks and 3 wheels is configured, so that is why there are gear replay issues with 4 or 5-gear aircraft, like the Concorde...). And looking at many of the recorded properties, I think many of them indeed will hardly ever change from frame to frame, so this 1K structure could probably be reduced significantly - despite extra tagging bytes. Thinking about it, it should also be possible to join some of the multiplayer and replay code. The replay system could use the existing encoder of the multiplay manager to generate the data packets - but then record them locally instead of transmitting them via UDP. During replay, these packets could then also be decoded by existing multiplayer code. Might be worth a thought, if someone wanted to dig in this area. cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Generic Protocol Input - Float weirdness
Every standby-mhz value Arduino is sending has been previously formatted so that it has at most three decimals, something like that: 139.775 or 129.675. Problem is FGFS shows /instrumentation/comm/frequencies/standby-mhz as 139.7749939 or 129.6750031. There's something wrong with that and I have no idea what it is. It looks like FGFS is receiving 139.775 and stores it as 139.7749939 (some float rounding up) ... but why? Suggestions? It's an issue with the finite precision of floating point variables. Everyone is suprised when first seeing this. Only values which happen to be a sum of binary fractions (e.g. 1/2 + 1/4 + 1/8) can be represented accurately. Everything else, even simple _decimal_ values such as 0.1 or 0.775 cannot be represented exactly in _binary_. Usually this doesn't matter, since when you print a value to screen - or to a string buffer, you'll limit the precision. Something like 0.7749998175 will be printed as 0.775 if you limit to 3 digits. Obviously the property browser doesn't limit to 3 digits, but shows more, hence you see a difference. See here: http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems Also, the properties use double floating points (64bit). You're protocol uses float (32bit) - so you loose some precision, which makes the effect slightly worse. cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Replay system
On 31.03.2011 17:01, Robert wrote: Hi everyone, I'd like to share some thoughts with you on how we can improve the replay system. Right now only the last minute is recorded at full precision. After that minute we get a precision of 1 fps. And after 10 minutes we get a precision of 1 frame per 10 seconds (please correct me. this number may be wrong). FIRST SOLUTION: Streaming the replay data to the hard disc drive always at full precision. Streaming data to disc would be nice - but should be optional and not be enabled by default. It would also be nice to have an option to save a recorded instant replay buffer (when you haven't enabled the stream-to-disc feature earlier). I can't comment on the different interpolation methods. But what would also help is to change the recording scheme: Currently the valuesof a fixed set of properties is recorded at each frame. However, most properties rarely change. Only the a/c position and speed properties tend to change in every frame. Properties like gear position and control surfaces are almost constant (from frame to frame). So, it might be a good idea to record all properties in an interval of a few seconds only, while only recording properties that have actually changed with every frame. That should allow to drastically reduce the amount of recorded data - and allow much longer high resolution memory recordings. And you could still fast-forward within the buffer, since you'll have a complete set of properties every now and then. It's a simple but effective compression method which is used in many areas. It would also be nice to support recording of custom properties. We already have a similar solution for multiplayer mode. If the replay system recorded the same properties configured in the aircraft-set.xml (the generic int/float/string properties), it would mean a nice improvement. It would also have other advantages, such as allowing simple tests of an aircraft's multiplayer configuration. p.s. I also thought that it woud be nice if the nearest tower would be automatically computed in replays (as it is done in x-plane), so you don't have to enter the airport code every time. Indeed. That feature would also be nice for normal flight. I never understood why the tower view sticks to the initial airport. Switching to the departure airport's tower view doesn't make much sense after a long distance flight. A general use nearest tower option would be nice. I don't think anyone is working in these areas right now. So if you are (or anyone else is) interested on working on these, let us know. cheers, Thorsten -- Create and publish websites with WebMatrix Use the most popular FREE web apps or write code yourself; WebMatrix provides all the features you need to develop and publish your website. http://p.sf.net/sfu/ms-webmatrix-sf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fuel: Nasal errors
On 27.03.2011 13:48, HB-GRAL wrote: I get an error in /Nasal/fuel.nas with current fgdata git: Time to update fg/next. You're probably missing this commit: http://www.gitorious.org/fg/flightgear/commit/0114fd962e7450b080e580fe67414ca43cd99bd7 cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Hi,
here's a few more comments/hints/warnings on Nasal and simulation
performance in general.
First of all: it's not meant _against_ anybody. It's great to have a
tiny scripting engine in FG. It's great to have an option for custom
extensions. And we're certainly seeing very nice examples (absolutely
including ThorstenIR's local weather, since he brought that up).
I'm just making a point here that the Nasal engine does have
performance issues, which we should be aware of and care about.
When evaluating simulation performance, don't get fooled by the frame
rate. What's really important to us is the worst case frame latency.
Even if the system is producing a huge average of 100 frames per
second, it can still look absolutely crappy, if only a single frame
took more than 20-30ms, since that's immediately visible to the human
eye (note to self: add a worst case latency indicator). So, we're
building a real-time system here, and 20-30ms is our timing
constraint.
Nasal needs to run a garbage collection every now and then. This means
an extra delay, and may become noticeable, if it causes a frame to
violate the timing constraint. _When_ and _where_ in the Nasal code
the g/c triggers, is almost random, so you cannot attribute the g/c
delay to the point where it happened.
The effect depends on two properties: (1) how long does it take, and
(2) how often does it happen. These issues are triggered by different
properties of the code. If we can keep the delay below the limit,
everything is perfect. If we cannot, than we should at least reduce
its frequency. One stutter per minute may be acceptable. Once every
second looks absolutely intolerable (though you may still get a funky
100fps indication!).
1. The length of the delay depends on the number of references the
garbage collector needs to traverse: variables (data), but also
functions, which are just like variables in Nasal, e.g.
var myVariable = 42;
var myFunction = func()...
It doesn't depend on the size of a particular function or basic
variable though. The garbage collector needs to look and follow every
single reference to find out what's still in use. The delay is
proportional to the number of elements which were
loaded/initialized/created in Nasal. It hardly depends on the
length/complexity/frequency of Nasal computation though, since the
average number of references usually won't change too much.
I have instrumented the Nasal g/c to show the number of references
caused by generic Nasal scripts and by different aircraft (subtracting
the references caused by generic scripts) with current GIT:
39128 all generic stuff (i.e. fgdata/Nasal...)
3475 UFO
4788 c172p
6007 SenecaII
8283 B777-200ER
19270 F14
86122 Concorde
So, for most aircraft, the a/c specific Nasal is negligible. Time
consumed by garbage collection almost depends on generic stuff alone
(40K of references traversed in each run). Only some complex aircraft
significantly influence the g/c performance themselves, e.g. the
Concorde. It's ok if advanced models require advanced CPUs. But it's
not so nice with generic stuff, since it affects everyone and every
aircraft.
Currently, we load all fgdata/Nasal/*.nas at startup. Whether the code
is ever used or not, or a particular feature is disabled, doesn't
matter much. It's loaded and initialized, increases the number of
references, thus delays the g/c.
For the test above, I had _disabled_ multiplayer/wildfire/target
tracking/local weather/redout. The numbers hardly change when enabling
features though.
Since the local weather topic was mentioned: yes, it's large, but only
responsible for about 11K of references, so about 1/4 of current
generic Nasal stuff (when disabled).
2) The g/c frequency mainly depends on how much stuff is done in
Nasal, including the number of timers and the timer frequencies. So,
in contrast to (1), this very much depends on enabled features, and
strongly on specific aircraft (see Robert's email on frequency).
I also added instrumentation here to see how our generic stuff is
doing. There's several timers which run at full frame rate, even when
the related feature is disabled:
fgdata/Nasal/mp_broadcast.nas:146
fgdata/Nasal/redout.nas:93
fgdata/Nasal/wildfire.nas:506
fgdata/Nasal/track_target.nas:194
Even when they're almost doing nothing, it'd still help if they were
stopped or at least slowed down, when the related feature was
disabled. They affect garbage collection since a lot of (useless)
contexts are created and need to be cleared at some point - hence
triggering the g/c more often than necessary.
Typically many of our Nasal timer handlers look like this:
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
}
settimer(myTimer, 0.0); // run again in next update loop
}
This would already improve things (20-100 times fewer contexts being
created/removed):
myTimer = func() {
if (getprop(/foo/feature/enabled))
{
...
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 26.03.2011 06:27, Robert wrote: However, the garbage collector does a complete scan of all Nasal objects to detect and remove unreachable elements. So, the more Nasal data elements we have, the worse the jitter gets. Large Nasal data structures will eventually break every CPU. And since it's done in the context of normal Nasal calls, and not in a separate background thread, it directly affects the duration of our main update loop - hence frame rate. Not so nice. Hmm. Other script languages rely on reference counting for garbage collection, which means much more stable performance. Python does that for example. But, well... GSoC anyone? ;-) Python support would be a great feature I think. Well, yes. But changing current scripts would be a huge, huge project. And it'd would require much more maintenance than our tiny Nasal engine. It's a better option to improve the existing garbage collector (i.e. use reference counting, improve its speed, or make it happen less often). But that would also be a very complex change in a very sensitive area of our sources. What I am thinking about is a possibility to convert Nasal scripts to C or C++ and compile them as shared objects (.so .dll). Then we could load them dynamically at fgfs runtime. So in the end we get raw C/C++ performance to our modules. Is this possible or am I dreaming of something impossible here? Mainly dreaming. Such things may look simple at first. Easy to convert a simple hello world. But it's very complex when supporting all the features of an interpreted script language. And the funny thing is: you'd still need to worry about automatic garbage collection and count references (though that'd be a lesser issue compared to many others then). So, time wake up... For the time being, we'll have to live with this. We should just be aware, that introducing too complex data structures and too heavy/complex computations in Nasal isn't a good idea. Even when their average execution time looks ok, they will eventually trigger noticeable frame rate jitters. The larger the data structures get, the longer the jitter. The more heavy the computation gets, the more often the garbage collector has to run, the more often the jitter happens... So, it's still good to implement heavy stuff and common instruments in our FG core (C++), and use Nasal mainly for aircraft-specific animations etc. Though that may not be the direction our project is heading to right now... cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 26.03.2011 10:03, Tim Moore wrote: Reference counting doesn't provide a strong performance advantage over conventional garbage collection, and a reference-counting scheme can take an unbounded amount of time. Reference counting schemes that do have real-time or bounded behavior are very complicated. Well, the issue with scanning for unreachable objects is that it scales with the number of data elements in memory. Even when you aren't touching the data structures, they still affect performance. Reference counting itself doesn't guarantee real-time behavior, since removing any reference may result in deleting large data structures. But it's much more predictable and can be influence in the code. When certain code doesn't touch anything large, then it isn't affected. There are real-time systems which have successfully integrated a Python engine because of this. Though it doesn't guarantee hard real-time by the book, it still works very, very well, and only require few limitations (i.e. you have to avoid cyclic data structures, or accept that they are leaking). I don't know much about our Nasal implementation, but I suspect that the garbage collector could be changed to trace only a portion of Nasal's heap at each invocation, at the risk of increased memory use. Hm, not sure. The garbage collector uses mark sweep. It locks out any concurrent Nasal execution, marks all reachable elements, then removes everything unreachable, finally unlocks the engine. The expensive bit is the marking of all elements. It's hard to split such a task. You could abort the operation, but then later have to start all over again, to be sure that you've really traced all references. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 24.03.2011 14:33, Robert wrote: Timing summary fornasal. - mean time: 0.04 ms. - min time : 0.00 ms. - max time : 2.05 ms. - stddev : 0.24 ms. I don't think we have to dig into nasal code like Franz suggested (please correct me if I'm wrong) because as you can see there is no significant amount of time spent in comparison to this: Timing summary for events. - mean time: 1.09 ms. - min time : 0.30 ms. - max time : 37.14 ms. - stddev : 4.24 ms. Robert, you should still look at Nasal. The event manager handles timers, and that's almost exclusively used by Nasal. Almost all the Nasal code runs in timers (except for property listeners). So read events as the total execution time for Nasal (timers). The timing data shown for the subsystem nasal only refers to the execution time of Nasal internal house keeping (i.e. some garbage collection), but not to the execution of actual Nasal code. Indeed misleading. The events subsystem is also showing a jitter on my machine (but not as bad). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 24.03.2011 23:54, Robert wrote: As you can see Nasal scripts aren't used at all. No, there are several generic Nasal scripts loaded independently of any aircraft configuration files. I checked my system and saw timers from the mp_broadcast.nas (which is also active when MP is disabled), wildfire.nas and several others. You also need to disable all scripts in fgdata/Nasal to get rid of all Nasal timers. Also, I had a brief look at exactly which Nasal timers caused a jitter. And the winner is... ... well, any. Any Nasal timer, even if it's almost empty, will every now and then consume a much larger amount of time than normal. Seems to be a general issue with the Nasal execution engine: could be triggered by Nasal's garbage collector, which every now and then needs to do extra work - and runs within the context of a normal Nasal call. It could also be a result of Nasal's critical sections: other threads may acquire a temporary lock to alter Nasal data structures - which may block the execution of Nasal timers at certain points. Hmm... Best practices for debugging a multi-threaded program anyone? :) Concerning the frequency of the jitter: I guess it isn't related to the FDM at all. It's probably just a result of Nasal complexity. The more Nasal code is running, the more often/likely garbage collection / blocking may occur. Frame rate may also influce it: many Nasal timers run at delay 0 (in every update loop). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture cache
On 22.03.2011 23:54, Tim Moore wrote: 5, maybe worst: osg plugins which load 3d models seem to load textures directly and store them... somewhere. So no caching, if two models use the same texture it gets always loaded, no matter what. This should not be true in general; the images should be cached and the texture objects should be too, unless some parameter is animated so the texture can not be shared. Now, I notice that cacheing is turned off for a class of models that includes AI models and may include models created through Nasal (simgear/scene/model/SGPagedLOD.hxx, line 53); I don't know what the rationale is for that and that may be the cause of the current problems. The particular line disabling the OSG cache has been there from the very first commit (3 years ago to the day). So there is a chance, it was never really considered - or there was an issue with OSG library itself at the time. On my machine it seems ok to enable the cache - everything looks normal with FG. Maybe someone could do some tests when changing the setting (SGPagedLOD.hxx:56) from CACHE_NONE to CACHE_IMAGES or even to CACHE_ALL (then recompile/install sg+fg). Would be interesting to know how this changed loading times, run-time fps and memory consumption. Just make very sure to use a well controlled environment for any performance tests (especially no live weather...). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
Hi, I've pushed an update to sg/fg/fgdata which enables a (so far well hidden) feature of our subsystem manager to capture timing statistics. It''s now configurable at run-time. Use Debug - Toggle Subsystem Statistics to enable/disable. It prints min/max/average and std-deviation for each of FG's subsystems to the console. The statistics interval is configurable via /sim/timing-statistics/interval-s Since there are a lot of submodules in FG (most of them are very friendly and don't consume much time), you can restrict the output to modules exceeding a certain minimum execution time - or a certain jitter (hey!). Use /sim/timing-statistics/min-time-ms and /sim/timing-statistics/jitter-ms to configure the filters (in milliseconds, obviously). Should help finding performance and jitter issues if they were caused by one of our internal subsystems. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 23.03.2011 23:42, Csaba Halász wrote: I have found that feature earlier:) Also I have actually removed some subsystems, but to no avail. Let's see if somebody can produce other results. Yes, let's see what people come up with :). I actually see one submodule which produces some jitter. But I'm not a squealer. And my new machine is *very* fast... :) cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
On 23.03.2011 23:22, Bertrand Coconnier wrote: Attached is a patch that fixes this bug (#294 in the bug tracker). As far as I could test, it restores the functionality of the instant replay while keeping the restart feature (CTRL+SHIFT+ESC) functional. Furthermore I have implemented the 2 methods suspend() and resume() in JSBSim.cxx so that the FDM is actually suspended during the replay. However this bug fix is not really elegant because the original code is not so elegant itself (see explanations above). Thanks a lot Bertrand! Using the suspend/resume feature of the subsystem still is elegant, I think. During replay, we really don't want the FDM to do anything - preferably it shouldn't even notice that anything has changed at all. So, suspending the FDM and disabling its callbacks is a good idea. At least easier than disconnecting/reconnecting the property callbacks. It fixes all the issues I have seen and replay works fine now - so I pushed it to git. But are the JSBSim.* files officially maintained in the JSBSim repo (so the patch also needs to be proposed over there) - or are these files owned by FG now? cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] OSG version (was Auto-hiding the cursor)
On 22.03.2011 00:08, HB-GRAL wrote: I just noticed though, that a number of wiki pages again returned to recommend the use of latest OSG-svn*sigh*. I don't know why people keep recommending that... Because it is valid;-) Maybe not trunk, thats always dangerous, but 2.9.9 seems to work for OSX. Ok, thanks for clearing that up. Glad that 2.9.9 works fine after all then. With latest OSG-svn I was specifically referring to the latest sources from the OSG subversion trunk - which shouldn't be the standard for any FG git user (unless you really, really know what you're doing). cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Stuttering at 1 Hz rate
On 22.03.2011 05:24, Robert wrote: Ingame (insim) I notice a small stutter that happens once every second. Did anybody of you guys notice the same thing? What can we do about it? I thought it might be something like a timed task. (reading from hard disc + malloc)? Please, could someone tell me where I can find this function in the source files? I don't see this issue here. Are you sure this isn't caused by another software on your machine? Some background service (indexing, virus scanner)? I don't think you'd be successful just by looking at the code. You could test if the effect happens with different planes, i.e. try the ufo. If it depends on the plane, try disabling specific instruments (modify the XML files), until you found the instrument causing the effect. Also check the plane's specific Nasal code: try to disable timer related tasks there, and see if this changes the effect. cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Instant replay and JSBSim aircraft
Hi, not sure if anyone else had a chance to test the instant replay with JSBSim aircraft - but it indeed seems like a general issue to me. It's triggered by JSBSim doing a trim operation once playback has finished - which produces an output like this (with the F16 in this case): Trim Results: Altitude AGL: 15 wdot: -1.83e+08 Tolerance: 1e-03 Failed Pitch Angle:-19 qdot: 9.33e+07 Tolerance: 1e-04 Failed Trim Statistics: Total Iterations: 61 Sub-iterations: wdot: 0 average: 0 successful: 0 stability: 3.5272 qdot: 0 average: 0 successful: 0 stability: 3 Run Count: 1201 Soon afterwards, the entire sim locks up since the FDM numerics go wild. I can avoid this issue by suppressing the re-trim when replay has finished (by forcing needTrim = false; in the code). All works well for me then - but it completely kills the needTrim feature in JSBSim, which was probably implemented for a reason... The trim is triggered since the FDM still has its property listeners connected during replay - so it thinks the aircraft position changes, which sets the FDM's needTrim flag. Might be a good idea to disconnect the FDM property ties during a replay - but JSBSim currently doesn't allow to reconnect the ties (bind method is not implemented). And the basic problem here probably is just that something with re-trimming an aircraft doesn't work properly. Any ideas on what could go wrong when the FDM tries to trim an already trimmed aircraft? cheers, Thorsten On Sun, Mar 20, 2011 at 12:48 PM, ThorstenB bre...@gmail.com wrote: I'm seeing an issue with the instant replay feature which seems to affect JSBSim aircraft. The actual replay works, but once replay is finished, the sim locks up or goes wild when trying to resume normal flight. Looks to me as if the FDM was somehow messed up by the replay. The FDM's update is suspended during replay - but I suspect there may be an issue with the tied properties, which still allow the FDM to see the replayed movements. YASim aircraft seem to be fine though. -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Quiet
Quiet?? Who said quiet? :-) -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] OSG version (was Auto-hiding the cursor)
On 21.03.2011 21:04, HB-GRAL wrote: Just to report: It’s a OSG 2.9.9 issue on OSX, was going back to 2.9.7 and all works fine. Also the keyboard input. (I am a victim of the wiki too now :-P , I wrote myself months ago 2.9.7 is needed and someone changed requirement for OSX 10.6 to OSG 2.9.9. Don’t know the reason for this, but beside that, I guess the nightlies based on 2.9.9 are also not working correctly ?) htgear-devel Until some weeks ago, there was a standard recommendation in the wiki to use latest OSG-svn when running FG git (actually in several places in the wiki). But using the bleeding edge OSG sources causes issues, since OSG development is pretty active and they have frequent changes. There is no way we could keep up/test those changes on weekly/daily/hourly notice. And sometimes OSG itself is also introducing new bugs in their code (like this probably: http://code.google.com/p/flightgear-bugs/issues/detail?id=268). Recently we've seen many people reporting issues due to unstable OSG - both, in the tracker and on the mailing list. Also, we found that any normally advanced FG git user doesn't even need to run the very latest OSG sources. Those very few who actually need it (i.e. in order to adapt FlightGear), know anyway what to do (hey Tim! :) ). So, after some discussion we decided to recommend the latest _stable_ OSG release by default (which still is OSG2.8.3). And for those, who really want to be a guinea pig and test the OSG-developer versions, we found that 2.9.9 was the latest (at the time) which was working with Linux/Mac/Windows (reported by several people on irc including Tim/James, I think). That's why the wiki was changed (default: 2.8.3, and 2.9.9 for keen developers). And it was me updating the OSG wiki page: http://wiki.flightgear.org/index.php/OSG Personally, I prefer to stick with OSG stable (2.8.3) - which works great for me. There are still enough issues in FG git itself to worry about... ;-) I just noticed though, that a number of wiki pages again returned to recommend the use of latest OSG-svn *sigh*. I don't know why people keep recommending that... cheers, Thorsten -- Enable your software for Intel(R) Active Management Technology to meet the growing manageability and security demands of your customers. Businesses are taking advantage of Intel(R) vPro (TM) technology - will your software be a part of the solution? Download the Intel(R) Manageability Checker today! http://p.sf.net/sfu/intel-dev2devmar ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Instant replay and JSBSim aircraft
Hi all, I'm seeing an issue with the instant replay feature which seems to affect JSBSim aircraft. The actual replay works, but once replay is finished, the sim locks up or goes wild when trying to resume normal flight. Looks to me as if the FDM was somehow messed up by the replay. The FDM's update is suspended during replay - but I suspect there may be an issue with the tied properties, which still allow the FDM to see the replayed movements. YASim aircraft seem to be fine though. But maybe that's a local problem here only, since no one else reported this yet. Would be nice if s.o. could double-check... I've tested this with the 747 and F16 - using latest GIT. cheers, Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] File sizes in fgdata, clean up needed?
On 18.03.2011 17:50, HB-GRAL wrote: Today I checked the current fgdata/Aircraft folder for sizes. It’s about 4,3 GB here. Nice. Some of this files are .gz already, when I .gz the rest I get another 100 MB, or in other words I get two MiG-15 or another p51d. Nice statistics! Maybe this motivates some of us to be a bit more considerate before committing something to the repo. However, remember that dropping any file from the repository wouldn't help at all now: a git repository never shrinks - it can only grow... It's an especially bad idea to drop files and resubmit a smaller/compressed version in a futile attempt to shrink the repository. git contains a complete history of every file. If you dropped files and resubmitted a smaller version, the local fgdata directories may at first appear smaller - but if you checked the total size (that is including the hidden .git folders) you'll see that the total size was actually increased... And another warning: the complete history issue also affects personal git branches on gitorious. So, if an a/c designer adds 19 versions of an image file to his private branch and then placed a merge request to fgdata/master - then the merge will actually copy the history of all 19 file versions to the master branch - even the history of files which were already dropped on the private branch. So, in such cases it's a good idea to not actually git merge the complete personal branch to our master - but to simply take a copy of the latest version of the a/c files and to submit them to master using a fresh commit (I think that's what our fgdata-merge-committers do anyway - at least I hope so...). Or maybe any git expert knew if there was a git-merge-without-history command? Indeed, fgdata/master is becoming way too big though. But we can only solve this by splitting our current repository - and then push the different parts to fresh git repositories. Splitting fgdata was planned anyway. The new --fg-aircraft options was the first step to make this possible. I'm just not sure what the status of splitting fgdata is though... cheers, Thorsten -- Colocation vs. Managed Hosting A question and answer guide to determining the best fit for your organization - today and in the future. http://p.sf.net/sfu/internap-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Serial Connection is broken in Windows binary
On 07.03.2011 22:49, Roberto Inzerillo wrote: I'm getting results with Arduino and FGFS, at least in a Linux environment, that's good. But I will just shortly mention there's something broken in the Windows binaries. You mentioned using \n as a line separator in an earlier email. One common source of trouble when moving between Windows and Linux (or Mac) are line feed issues. Maybe the fgfs parser is confused by the encoding it gets from your port/driver. Windows uses CR LF (\r\n) as a line feed, Linux/Mac uses LF only (\n). A serial port can be configured to convert the line feed encoding, i.e. Linux may convert CR LF to LF, a Windows driver may do the opposite. I remember configuring (disabling) this auto-conversion property for a serial port years ago - when I used python for an RS232 interface on Windows and Linux. fgfs probably expects \n only - even when running on Windows. Just an idea. Other than that: I have no idea... ;-) cheers, Thorsten -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture efficiency
On 03.03.2011 09:47, thorsten.i.r...@jyu.fi wrote: The total time to load a configuration is really proportional to (number of objects) x (texture size of a single object) So maybe the textures aren't really shared. What's worse - and slightly related: I ran a memory analysis some weeks ago, to identify true memory leaks (that is memory leaks triggered at source code locations which over time increase indefinitely). I found that the MP aircraft and clouds are a major cause for FG memory leaks. The more MP aircraft were loaded and unloaded (obviously not properly unloaded though), and the more clouds were displayed (and also not properly unloaded), the higher the number of leaking memory elements gets (and the higher FG's memory consumption gets). Another huge memory leak is caused by properties. The leaking properties may be a result of the other leaks though (they might still be referenced by leaked clouds or MP aircraft models), though there could also be a separate issue. I only checked the number of memory elements - so not sure which leaks will actually hurt memory consumption the most. But at least it was pretty obvious that we have some bad issues in these areas. I'm currently busy with other stuff. But checking on what's going wrong with loading/unloading clouds and MP models may be worth a closer look. cheers, Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Texture efficiency
On 03.03.2011 20:51, Torsten Dreyer wrote: I'm currently busy with other stuff. But checking on what's going wrong with loading/unloading clouds and MP models may be worth a closer look. There was a fix for a MP memory leak approx. two weeks ago: http://gitorious.org/fg/flightgear/commit/8962477cfa10850cb459d7de754c9a435cc91293 Hi Torsten, ha!! Yes, I'm getting older, maybe I'm already starting to forget things? :-) But no, this patch only fixed a leak I found in the MP communication module. The analysis showed more leaks - but unfortunately I couldn't see any obvious fixes for these. There are remaining leaks related to the actual model objects (e.g. objects from OSG derived classes) for clouds and MP planes. Maybe something with the osg reference counting doesn't work there as expected... cheers, Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Telnet lag?
On 27.02.2011 15:48, Geoff McLane wrote: On Sun, 2011-02-27 at 14:06 +0100, Roberto Inzerillo wrote: Well, it works ... but the telnet connection is very slow and that slows down every intercation, it makes it far less than realtime I quickly added some 'timing' to my telnet access, through a perl script, and find :- 39 accesses took 15.57 secs, av 0.4 secs per access... Hi, a look at the sources shows that a fixed polling interval is used for telnet - default is 5Hz. So it cannot process more than 5 commands per second. That's why it's slow. There's better methods of implementing socket communication instead of polling, but I haven't looked into the module and don't know why this was chosen. The polling interval is configurable though - so you can speed it up. Use: fgfs . --telnet=medium,direction,HZ,localhost,PORT,style Use HZ to select the polling frequency (e.g. 100) and PORT for the telnet port (e.g. ). The other parameters are unused (it seems) when using the telnet protocol. Probably there for historic reasons (?). Maybe Curt knows. Remember you have to specify 6 parameters separated by a , - otherwise you cannot configure the polling frequency. So call something like fgfs . --telnet=foo,bar,100,foo,,bar cheers, Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Logos and licensing
On 27.02.2011 21:18, Gene Buckle wrote:
I for one, do NOT welcome our new Vichy FlightGear Overlords. Zey hav
vays of makingink you comply.
Until you mouth-breathing back-biters understand the concept of no harm,
no foul, I don't want to have a thing to do with you.
*« Bravo, vous avez gagné 1 point Godwin.*
Vous pouvez aller le découper au burin
sur votre écran... »
/ __) () () () () () (__ \
|_| |_|
_ __ __
| |/ | _ __ ___ (_)_ __ | |_ | |
| || | | '_ \ / _ \| | '_ \| __|| |
|_|| | | |_) | (_) | | | | | |_ |_|
_ |_| | .__/ \___/|_|_| |_|\__| _
| | |_| | |
| | | |
|_| _ _ |_|
_ / ___| ___ __| |_ _(_)_ __ _
| | | | _ / _ \ / _` \ \ /\ / / | '_ \| |
| | | |_| | (_) | (_| |\ V V /| | | | | | |
|_|\|\___/ \__,_| \_/\_/ |_|_| |_| |_|
__
| |__ __| |
\) () () () () () (/
So, we haven't solved the issues with trademark law - but at least
fulfilled Godwin's law. Congratulations.
Another discussion on this list turning ugly/personal/offending eventually.
--
Free Software Download: Index, Search Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] New instrument: TCAS
Hi, I just pushed a new instrument to next: we now have a TCAS device. It's a new module providing aural alerts for conflicting traffic. It's also able to drive TCAS displays, since aircrafts' threat-levels are exposed to the property tree. The existing wxradar instrument is updated accordingly, and now has an option to display traffic in TCAS-style (colorful diamonds/circles showing the traffic's threat-level). The TCAS is implemented in the FG core and requires minimal performance - so should be fine even at busy airports. And it works with AI and multiplayer traffic. As expected, AI pilots are well-trained, so they always respect TCAS advisories: when you get a climb! climb! alert in your cockpit, you'll also see conflicting AI planes dive to safety (or vice versa). And since you're a responsible pilot, I trust you'll also know what to do... :) There's more info on its features and installation in the wiki: http://wiki.flightgear.org/index.php/TCAS I've tried to stick as close as possible - well... reasonable :) - to the TCAS II standard. The traffic detector shouldn't be too far off. However, I've simplified the advisory code a bit. A TCAS II only provides vertical advisories (so it's either up or down...), but there's still a long list of variations and exceptions in the standard. Also, determining/predicting an optimal evasive movement for conflicting aircraft isn't always easy. Well, should be good enough for most situations as it is now. I might still add a few more advisories later - as well as improve the MP support. The TCAS and new display is already installed on the 777 now. And the cockpit is also extended with an ATC/TCAS panel (more switches!) - huge thanks to Syd Adams for another nice modeling job! A good area for test flying the TCAS is EHAM - with lots of AI traffic. Give the AI pilots a hard time by interfering with their nicely aligned approach sequence. The default TCAS voice samples in fgdata are temporary stubs only (artificial voice). Hopefully we can replace them by more realistic sound samples soon. But you can also provide custom voice samples for an aircraft (which is also possible for the GPWS now, see GPWS in the wiki). Hope the new instrument works for everyone (well, Hudson compiled it!). And hopefully this won't trigger a new multi-player sport (proximity flying to trigger TCAS alerts) - otherwise just use the ignore pilot buttons. Fly safe! cheers, Thorsten -- Free Software Download: Index, Search Analyze Logs and other IT data in Real-Time with Splunk. Collect, index and harness all the fast moving IT data generated by your applications, servers and devices whether physical, virtual or in the cloud. Deliver compliance at lower cost and gain new business insights. http://p.sf.net/sfu/splunk-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs on Android source request
On 20.02.2011 15:40, Curtis Olson wrote: I know there is one android/flightgear app that serves as a remote control for flying FlightGear via your android phone--perhaps that is what you found? It uses the network interface which provides good separation of application licensing. Yes no. It's an app particularly marketed as a flightsim for Android - named FlightGear. Pictures promoting the app show the infamous ProFl*Sim package. It also has a link to the profl*sim website (e.g. FlightGear dot us). So, it's another activity of the ProFl*Sim scammers. They certainly haven't ported FG to Android, so it's either a complete hoax - or they indeed try to sell the Android remote control (pretending it to be a full flightsim). My guess is the latter (since it saves them work of creating a hoax application first). This site offered the FlightGear (ProFl*Sim) package for Android until a few hours ago: http://de.appbrain.com/app/flightgear/com.flightgear Now it just says This app is unfortunately no longer available on the Android market.. Ha... Partially it's still visible in google's cache: http://webcache.googleusercontent.com/search?q=cache:9zRzOnUzIVsJ:https://market.android.com/details%3Fid%3Dcom.perfectflight+android+flightgear cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs on Android source request
On 20.02.2011 16:18, George Patterson wrote: This site offered the FlightGear (ProFl*Sim) package for Android until a few hours ago: http://de.appbrain.com/app/flightgear/com.flightgear Anything like this one? http://www.appbrain.com/app/alni-flightgear-control/org.alni.android.fgfs.control No, Alni is the good guy :). He's the original author of the remote control: http://www.flightgear.org/forums/viewtopic.php?f=18t=10761 Also, Alni's offer is for free - and doesn't pretend to be a full flightsim... cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] fgfs on Android source request
On 20.02.2011 17:27, Michael Sgier wrote: let me know if anyone can buy it and show the source. I really was surprisedi never would have given this guy such programming knowledge. In fact i'd want to look at that but am currently stuck at native c++ glut via Android's NDK. Probably it would need to use the glut android port. Forget it. They haven't ported anything. It's a hoax. The user comment that Curt found said it all. The app merely takes you to their website - so you can buy another scam product. You don't want the source code of such a trivial app. cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Simgear and OSG out of sync?
On 15.02.2011 13:41, Tim Moore wrote: I've checked in fixes for this change in osgDB:DatabasePager to the SimGear and FlightGear next and releases/2.2.0 branches. Still doesn't compile with OSG = 2.8.5. We also need the patch that Bertrand sent yesterday, i.e. the #ifdef logic for the _readerWriterOptions attribute is still incorrect (inverted): diff --git a/simgear/scene/model/SGPagedLOD.hxx b/simgear/scene/model/SGPagedLOD.hxx index a9e55d9..4e25931 100644 --- a/simgear/scene/model/SGPagedLOD.hxx +++ b/simgear/scene/model/SGPagedLOD.hxx @@ -72,7 +72,7 @@ public: protected: virtual ~SGPagedLOD(); -#if SG_PAGEDLOD_HAS_OPTIONS +#if !SG_PAGEDLOD_HAS_OPTIONS osg::ref_ptrosgDB::ReaderWriter::Options _readerWriterOptions; #endif }; = Fixes the compile for any OSG version without SG_PAGEDLOD_HAS_OPTIONS support. By the way, I committed the changes to releases/2.2.0 and then merged that branch into next. This is the way fixes should move between the two branches. Please don't commit a fix to next and then cherry-pick it to the release branch. It is very messy to have the same change committed on several different branches. Hmm. On the other hand this means applying all (experimental) patches to the stable release/2.2 branch first. I'm not a git expert, but generally I like the opposite approach of applying patches to a project's experimental (master / next / ... ) branch first. And only after the patch proved to be ok and stable for everyone, eventually move it to the stable release branch. Reduces the risk of (temporarily) breaking a release branch (like we did now :) ). cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN
On Thu, Feb 10, 2011 at 8:05 PM, Andreas Gaeb a.g...@web.de wrote:
Hi Henri,
I think I found the error, it was in JSBSim's FGForce class. I've
proposed a fix on the JSBSim-devel mailing list.
Best regards,
Andreas
Hi Andreas,
had a look at the patch you suggested on the JSBSim list
(http://sourceforge.net/mailarchive/attachment.php?list_name=jsbsim-develmessage_id=4D5436B3.10606%40web.decounter=1).
However, I looking at the code it seems calling these InitMatrix in
the FGForce constructor shouldn't be necessary. The FGMatrix33
constructor in fact does initialize the matrix to 0 (see
FGMatrix33.cpp, i.e.
FGMatrix33::FGMatrix33(void)
{
data[0] = data[1] = data[2] = data[3] = data[4] = data[5] =
data[6] = data[7] = data[8] = 0.0;
}
. And the FGForce constructor will automatically call all its members'
constructors.
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal getprop: property /accelerations[0]/pilot[0]/z-accel-fps_sec[0] is NaN
Hi Andreas,
had a look at the patch you suggested on the JSBSim list
(http://sourceforge.net/mailarchive/attachment.php?list_name=jsbsim-develmessage_id=4D5436B3.10606%40web.decounter=1).
However, I looking at the code it seems calling these InitMatrix in
the FGForce constructor shouldn't be necessary. The FGMatrix33
constructor in fact does initialize the matrix to 0 (see
FGMatrix33.cpp, i.e.
FGMatrix33::FGMatrix33(void)
{
data[0] = data[1] = data[2] = data[3] = data[4] = data[5] =
data[6] = data[7] = data[8] = 0.0;
}
. And the FGForce constructor will automatically call all its members'
constructors.
... Oops, wasn't finished typing... :)
Anyway, you maybe you can double-check if that patch really changed
anything concerning initialization. If it really did, then I suspect
there must be something else going terribly wrong (memory
corruption?), which could explain why the FGMatrix33 constructors
weren't executed properly.
cheers,
Thorsten
--
The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE:
Pinpoint memory and threading errors before they happen.
Find and fix more than 250 security defects in the development cycle.
Locate bottlenecks in serial and parallel code that limit performance.
http://p.sf.net/sfu/intel-dev2devfeb
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Scenery: airport tower positions
Hi, there are two fixes concerning the tower positions at EDLL and EGLL in the bug tracker (see attached files EDDL.twr.xml and EGLL.twr.xml). Can someone update the scenery / TerraSync database with these files please - and take care of these issues: http://code.google.com/p/flightgear-bugs/issues/detail?id=54 http://code.google.com/p/flightgear-bugs/issues/detail?id=77 cheers, Thorsten ?xml version=1.0? PropertyList tower twr lon6.773192/lon lat51.280364/lat elev-m127.04/elev-m /twr /tower /PropertyList ?xml version=1.0? PropertyList tower twr lon-0.465513/lon lat51.471877/lat elev-m85.34/elev-m /twr /tower /PropertyList -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenery: airport tower positions
On 13.02.2011 14:59, Martin Spott wrote: Will check. Last time I looked at the proposed change for EDDL it seemed to me that the requested 'fix' was inappropriate because the tower positions was correct. Therefore I'm a bit cautions when people submit Scenery-related bug-reports and declare their own reports as Accepted at the same time, without review from any other person ;-) Ok, thanks Martin! You're right, the original position mentioned in the tracker wasn't quite correct. But the current FG tower position is still wrong. However, it's just the view position which needs to be adapted - the visible tower model is already placed correctly. I checked the coordinates with Google Earth (not sure that counts as a proof though :) ). The position in the files attached in the tracker match the Google positions (which in the case of EDDL match the model position). EGLL is still missing a visible tower model. Anyone interested in taking care of England's main airport? cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Use of included xml files from Instruments-3d/* from an aircraft located outside of $FG_ROOT
On 14.02.2011 07:58, Hal V. Engel wrote: When working on this from an aircraft that is not located in $FG_ROOT (IE. my clone of fg-data using fg-aircraft=my fgdata clone/my aircraft) I was getting file not found errors. At first I though that perhaps I had a typo or something similar in my code but after looking things over very carefully I couldn't find the problem. So as a test I modified the aircraft-set.xml for the same aircraft in $FG_ROOT and tested with it and it didn't have the problem. I did some more testing and found if I run the aircraft from my development copy of fgdata it works but only if the xml file I am including in the aircraft-set.xml file is located in the same tree as the aircraft. So it does not find it in the $FG_ROOT directories like it should based on how the fg-aircraft stuff has been explained. Is this a bug or I am not understanding how this should work? It should work - and does for me. But remember the fg-aircraft option does not support multiple fgdata clones. Neither should you give it the path to a specific aircraft directory. You need to provide a directory path, which contains one or multiple aircraft sub-directories. It should look like this: --fg-aircraft=/home/foo/bar/MyAircraftRepository and /home/foo/bar/MyAircraftRepository should contain directories like /home/foo/bar/MyAircraftRepository/747-400 /home/foo/bar/MyAircraftRepository/P51-D /home/foo/bar/MyAircraftRepository/AH-1 ... Otherwise, post some more details on what your command-line and the directory structure of the separate aircraft repo looks like. And yes, as discussed on the list before, the fg-aircraft option requires better checks and error messages, since more people have had trouble with providing the correct directory structure (especially since incorrect structures seem to work at first - but then really don't). cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] sound via simgear
On 11.02.2011 16:41, Curtis Olson wrote: In addition in an external fly-by you could hear the sound moving from one speaker to the other which was really cool. Now that I think about it we may have lost that positional capability in the fly by so I don't know if positioning the sound inside the cockpit is working any more either? It should work. We do have a bug report that the Doppler-effect isn't working on some systems (maybe depending on hardware devices). But no one has mentioned a problem with the 3D sound yet. And it works for me. However, it does depend on a/c designers: cockpits are more fun, if different sound sources are actually located at different positions - rather than using the same audio position for each effect (copypaste). cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Testing FG 2.2.0
On 08.02.2011 20:40, Torsten Dreyer wrote: No sweat - 2.2.0 is not affected. This is because of the TankProperties I'll try to come up with a solution but that might not be before the weekend. And, always seeing the positive side, this might be a great opportunity to have more people testing the current 2.2.0 branch. We're preparing for the release - and since GIT/next has already moved ahead, it is no longer a valid test case for 2.2.0. Switching branches is easy and quick - of course, thanks to GIT :). To create a new local 2.2.0 branch (needed for simgear and flightgear): git checkout -b releases/2.2.0 origin/releases/2.2.0 You can then switch between the next and 2.2.0 branches by: git checkout next and git checkout releases/2.2.0 Remember to keep each branch updated using git pull. Finally, rebuild normally (e.g. make make install for simgear and flightgear). Yes, there's also an advanced method using separate, cloned repositories - if you want to be able to run both versions without the need of switching and recompiling. See the flightgear-devel archives... cheers, Thorsten -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
Hi Betrand, thanks for your patch. Only one comment on your patch though... On Sun, Feb 6, 2011 at 1:08 PM, Bertrand Coconnier bcoco...@gmail.com wrote: * I would rather make tied_properties a list of SGPropertyNode* rather than a list of strings (same as above : internal JSBSim stuff) I don't really like the use of simple pointers here, as property objects sometimes are being worked on/merged/deleted. I remember debugging several issues where modules obtained direct pointers to properties and then kept using these though the original object was already deleted/merged/recreated in other parts of FG. Results in ugly heap issues... This may not be an issue here (right now), but if we don't want to use the path name (strings) as a reference, we should probably rather use a SGSharedPtrSGPropertyNode instead - i.e. the SGPropertyNode_ptr typedef. This guarantees that the reference is still valid when trying to untie the property later on. cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On 06.02.2011 15:07, Jon S. Berndt wrote: That works. Sort of. But it's trying to patch JSBSim.cxx which we no longer have in JSBSim standalone. Patch looks good and is pushed to FlightGear/next now (so our JSBSim.cxx is also updated now). Thanks Betrand! PS: I've made several reset tests, all look good now. Also, no side-effects with the previous patches were reported, so I'm also pushing the patches to FG/2.2 now (trying to remember the entire patch sequence... :) ). cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
Hi, probably spotted the cause for the reported reset crash: it's the same as already reported before - targeted by this earlier patch: http://www.gitorious.org/fg/flightgear/commit/287cc74965e11ff3888117a9d9b88ed2bdbb9252 This patch unties all JSBSim properties prior to reset. However, it's not quite sufficient and misses some JSBSim properties. Problem is that JSBSim can also tie properties outside the /fdm/jsbsim branch - using property paths which can be configured in aircraft-specific configuration files. For example, the configuration of the 747 (in Systems/failures.xml) causes JSBSim to bind the following additional properties: /accelerations/pilot-gdamped /controls/fuel/fuel-to-remain /sim/model/pushback/target-speed-fps /autopilot/autobrake/left-brake-output /autopilot/autobrake/right-brake-output These properties aren't untied by the earlier patch - so still result in trouble. I'm currently testing a different patch for the same issue: instead of untieing all properties below the /fdm/jsbsim (only), I added a list to JSBSim's FGPropertyManagager, so it keeps track of all the properties it has actually bound. It can then use this list to untie all its properties - no mattere where these are located in the property tree. This patch seems to fix the issue for me. I'll do a few more tests and (hopefully :) ) propose this a new patch... cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On 05.02.2011 16:21, ThorstenB wrote: I'm currently testing a different patch for the same issue: instead of untieing all properties below the /fdm/jsbsim (only), I added a list to JSBSim's FGPropertyManagager, so it keeps track of all the properties it has actually bound. It can then use this list to untie all its properties - no mattere where these are located in the property tree. New patch pushed to flightgear/next: http://www.gitorious.org/fg/flightgear/commit/ad8d46ba648263630b8777c53f852b75cad7ecdd This will be overwritten by the next JSBSim update, however it's a short-term fix and candidate for our pending 2.2 release. So, please test if you still see reset issues with JSBSim aircraft. If we find it's an improvement (maybe/hopefully the final fix for this issue), then we'll be pushing this to the 2.2 branch also. But remember, none of the reset fixes is part of the 2.2 branch just yet. The long term fix needs to be part of the JSBSim repository of course. Jon, Erik: please check if you want to use this patch or have some other solution to the problem. cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] JSBSIM Aircraft Crash at Reset
On 05.02.2011 18:54, henri orange wrote: , I get an error at build screen-dump.cxx:(.text+0x276): undefined reference to `osg::Referenced::signalObserversAndDelete(bool, bool) const' /usr/local/lib/libsgmisc.a(PathOptions.o): In function `simgear::makeOptionsFromPath(SGPath const)': You're having some local problem with mismatching osg header files and libraries. Probably compiled against osg 2.8.3 or 2.9.11 include files - and tried to link against 2.9.10 libraries (or vice versa). Or maybe the osg libraries are missing altogether. You were using FG commit 133cfbfa7f4ec62ddc97bd93d4a50fec81b52362 before (previous email). There were only two git updates since then - none affected any osg interface, neither any makefile. cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for fix animation in Fokker-50 AI model
On 03.02.2011 10:54, Alexey Varjat wrote: It's pure animation fix: - Gears and lock bars (up and down just after take off/before landing) - ruder - ailerons - elevators - flaps - propellers (0 rpm while stands for both engines, low rpm for one engine and stopped blades for second one during taxing (speed=15 kts, high rpm for both engines speed 16kts) In GIT now. Thanks Alexey! cheers, Thorsten -- The modern datacenter depends on network connectivity to access resources and provide services. The best practices for maximizing a physical server's connectivity to a physical network are well understood - see how these rules translate into the virtual world? http://p.sf.net/sfu/oracle-sfdevnlfb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Patch for fix animation in Fokker-50 AI model
On 30.01.2011 14:01, Alexey Varjat wrote: Please find attached patch for fix animation in existing Fokker-50 AI model (fgdata/AI/Aircraft/Fokker-50/*xml). Thanks Alexey, looks good to me: the AI Fokker 50s now have their gear extended when on ground (much better than seeing them hovering along...). Could you post one or two lines on what else the patch fixes/changes? cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Helicopter view Panning ?
On 01.02.2011 13:09, henri orange wrote: Hello devel members, Is it just me ? With git today, i have lost the panning feature with Helicopter view. My fault. Checked the wrong axes when I fixed an issue with tower- and chase-view panning. Fixed in latest GIT. Thanks for the report. cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Cmake with MSVC10
On 31.01.2011 20:19, Alan Teeder wrote: With current Simger GIT and OSG SVN I am seeing this. https://sourceforge.net/mailarchive/forum.php?thread_name=20110123021352.679925de%40celsius.localforum_name=flightgear-devel So, OSG 2.8.3 (stable release), OSG 2.9.10 (latest dev release), or OSG SVN (bleeding edge) up to rev11995. cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fix for bugs #47 and #184
On 30.01.2011 14:55, Bertrand Coconnier wrote: Please find attached a patch that fixes bugs #47 and #184. It restores functionality of command line arguments --vc, --roll-deg, --pitch-deg, etc. Note also that this patch has also a positive side effect : it restores functionality of the 'airspeed (kt)' cell of the 'Position Aircraft in air' dialog box. Though in most cases, the engines are not started, and the aircraft is just thrown into the air with correct altitude/attitude/airspeed/etc. I have only tested it for JSBSim models. So further tests might be needed. Great, would be awesome to have this part of FDM integration fixed! I'll do a few tests and then push to next. Everyone else please test and report new issues (JSBSim and YASim). If nothing new is reported, we should also patch the 2.2.0 branch. Thanks Bertrand! cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On 24.01.2011 22:49, James Turner wrote: Perhaps another approach would be to do out-of-source builds. I think automake/conf should support that, although it's been a while since I've tried it. Cmake is very good at out-of-source builds :) Hmm. The out-of-source builds alone don't really help with switching branches. Changing branches back and forth still results in all differing sources getting new timestamps. So the next make triggers a rebuild of all affected sources/objects anyway. make isn't smart enough to notice that the older object files were generated from (older) sources, which had identical content to the current (newer) sources. So it's all the same if you maintained one or two sets of objects. You'll also need to keep git from touching any _sources_, so maintain two sets of matching sources and their objects. Using two completely separate repos helps - or the magic feature to create two separate source checkouts from one repository, which James mentioned. Could some git guru (git-goroo? ;) ) enlighten me, on how I can create two checkouts from one repo? That would actually be very useful - especially now that fgdata is branched. I don't want to pull another fgdata repo... and I don't feel brave enough to switch fgdata branches, since its release branch is already stripped (= switching affects thousands of files...). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
On Sun, Jan 23, 2011 at 9:13 PM, Andreas Gaeb wrote: ok, I found the cause for this one. FGPropagate's members LocalTerrainRadius, SeaLevelRadius and VehicleRadius are not initialized in the constructor but only later in InitModel(). FGInitialCondition Andreas, thanks a lot for debugging this! Any help with investigating such issues is very welcome! We had already invested quite a bit of effort into resolving this issue (and other related tricky problems have only recently been fixed by James - and since there were obviously several different causes, all resulting in the same kind of exceptions, we now know why this thing proved to be so difficult). If these patches finally fix the infamous NaN on reset bug, then that's really, really great for the upcoming release. And everyone else: please test report any further issues happening upon reset. http://code.google.com/p/flightgear-bugs/issues/detail?id=222 cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MSVC and C99
On Mon, Jan 24, 2011 at 8:43 PM, Olaf Flebbe wrote: MSVC implements proper initialization of static variables. http://msdn.microsoft.com/en-us/library/0x80hh2d%28v=VS.90%29.aspx If you do not explicitly initialize a global static variable, it is initialized to 0 by default, and every member that has pointer type is assigned a null pointer. Ok, thanks. So, yes, MSVC officially doesn't support C99, it isn't even fully C90 compliant, but still, MS was obviously reasonable enough to at least comply with some of the very basic rules (Hmmm, why does this actually surprise me about MS? :) ). But now that we all know about the initialization rules we should quickly forget these again - as we all agreed - and keep using explicit initializers anyway. Better style. Easier readable. Always works. ;) cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git work flow question
On Mon, Jan 24, 2011 at 9:01 PM, Curtis Olson wrote: If I do a build of the next branch, then switch to the releases/2.2.0 branch, I still inherit all the build object files from the other branch. So then I have to do a complete make clean; make for simgear and flightgear each time I want to jump from one branch to the other I don't have a GIT answer to your question - but I'm surprised you need to make clean. Switching branches results in all changed/switched source files getting fresh timestamps - so the normal make dependency rules trigger a rebuild for the affected objects. And unless the branches diverge too much, it should be much quicker than a full rebuild. I'm curious though if there was a better GIT workflow (you're never finished with learning about GIT...). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
On Sun, Jan 23, 2011 at 12:51 PM, Andreas Gaeb wrote: IIRC, gcc has a default initialization routine that sets new variables to zero unless they are explicitly initialized like int a=1; Yes, but that's only the case for global and static variables. The start-up code initializes the memory section for all global/static variables to zero (the bss section). However, this does _not_ apply to dynamic memory - hence, it doesn't work with dynamically created objects (as the JSBSim instance in our case). Sometimes, heap memory _may_ be zero at the beginning of a program - but there is no way one could rely on this. So, member variables should be initialized manually in the constructor. If the initial value in this example is not zero, it has to be stored in the executable, increasing its size. When initializing to zero, the zero is not stored in the executable, it seems. Right, linkers move non-zero global/static variables into a different memory section than zero/uninitialized vars. So they only need to store a binary image for the section of non-zero global variables - and just add code to initialize the bss section to zero. - in the prologue of the main function, the stack is initialized to zero (this even seems not to be the case when using -O3...) - gcc default initialization means putting the variable on the stack which is assumed to be zero because of the above - after a reset, new instances will not be created in fresh stack memory, but in sections that were freed when deleting the old instances - these sections were indeed freed but not zeroed - the new instances contain pieces of the leftovers of the previous instances No, the JSBSim object is created on the heap memory - not on the stack. Only local variables (including local static objects) are on the stack. Heap isn't initialized, neither stack. So member variables have random values - unless explicitly set. Most compilers provide warnings for uninitialized local variables (on the stack), but unfortunately I don't know any compiler (yet) producing warning for uninitialized member variables. Definitely a good idea! Uninitialized members easily cause random (=very ugly) problems - and such issues are a pain to debug. I'm strongly in favour of initializing all variables/members in the constructor. And especially so in a case like this, where few objects are created: even if initializing a certain member wouldn't be necessary, it doesn't cost us much except a few bytes of code - but no run-time performance at all. Though I'd also be in favor of this, it might be quite a lot of code to be added. Maybe it is an alternative to begin every constructor with something like memset(this, 0, sizeof(this)) Oh, please no! :) A few extra code lines don't matter - just add these please. Even if there were 100 member variable initializers. Such a memset would be highly compiler-/platform dependant - and we cannot allow this. Also, the memset would destroy other data such as the object's vtable, which is initialized by default (and stores the pointers to the object's virtual methods). And it's better to rely on the compiler being smart: if you add 100 initializers for member variables to be zero, it's possible that the compiler does something similar to a memset (but without destroying other data). So, even performance doesn't matter. I was looking for something explaining when it is safe to rely on gcc's default initialization, if ever. Details on the difference between the member initialization list and assignments in the constructor code might also be helpful. See above: never rely on initialization of member variables. Otherwise dynamic objects won't work. btw, all of the above is specific to gcc. Have the NaN issues been observed with other compilers? Windows/MSVC should have the same problem. cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
On Sun, Jan 23, 2011 at 3:44 PM, Geoff McLane wrote:
And I am not so sure MSVC even zeros static variables,
unless specifically set to NULL/0, unlike as suggested
for gcc, thus say :-
static char * cp;
void func() {
if (cp == NULL)
cp = malloc(val);
can also be a problem...
Are you sure? Initialization of global variables is required by the C99
standard - and I think was already part of C90 (ANSI C).
Ok, few compilers are fully compliant - especially not C99, but all
compilers I know at least comply with this rule (admittedly, I know nothing
about MSVC... :)) ).
C99 says
[...]
If an object that has static storage duration is not initialized explicitly,
then:
— if it has pointer type, it is initialized to a null pointer;
— if it has arithmetic type, it is initialized to (positive or unsigned)
zero;
— if it is an aggregate, every member is initialized (recursively) according
to these rules;
— if it is a union, the first named member is initialized (recursively)
according to these
rules.
I mainly use gcc and a number of weird compilers for embedded systems -
which all comply with this rule.
But you're right, personally I also prefer to explicitly initialize all
variables (i.e. int foo=0; instead of int foo;) since it's more clear,
better style and it doesn't cause issues when a global variable needs to be
moved into a local context.
It'd still be interesting to know if MSVC really doesn't comply with the
rule above - this could certainly be a source for several MSVC-specific FG
issues (just guessing here...).
cheers,
Thorsten
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
On Sun, Jan 23, 2011 at 4:57 PM, Jon S. Berndt wrote: I'd like to find a way to reinitialize an instance of JSBSim in FlightGear without having to destruct it and reinstantiate it. A couple of years ago I changed the construction process and separated out a reset/reinitialization feature to permit a sim to be reset, bypassing the loading of aircraft models. That saved a lot of time. I think that process should be looked at for resetting JSBSim in FlightGear, too. Of course, you can provide a reset method, which removes the need to create a fresh instance whenever the sim is reset. But then again, you could also call the same reset method in the constructor - and the members would also be initialized for fresh objects - still allowing the current scheme. So it doesn't change much for the initialization of variables - it still needs to be ensured that no uninitialized variables are used - and that no values from a previous simulator life (= last update loop before reset) are used in the first update loop after the sim's reset, since the reset may have changed absolutely anything (location/winds/pressures/temperatures/...). But yes, a reset method would give more flexibility and maybe help with other issues (such as the property tie/untieing) - which is yet another discussion... :) Well, to return to something more practical after all this theoretical talk about initialization and compilers (alsways fun on a rainy/foggy/chilly afternoon *brr* :) ) could you Jon, or another JSBSim expert please double check the particular issue that Andreas spotted concerning last_hook_tip / last_hook_root ? It indeed looks as if these weren't initialized but their values possibly used in calculations of the first few update loops. Not quite easy to spot though. And anyone else interested in FDMs and their FlightGear integration: there is more to do! Just check the bug tracker for FDM issues: http://code.google.com/p/flightgear-bugs/issues/list?q=FDM Mainly issues concerning FDM start-up (i.e. feeding initial values for speed/pitch/roll/... into the FDMs doesn't work properly). Most affect YASim, some JSBSim or both. cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] current git FG OSG bulds on latest debian lenny
On Sat, Jan 22, 2011 at 2:47 PM, Harry Campigli wrote: If so what is the best version of OSG to install as I have seen numous posts here and on forums pertaining to changes of OSG of late?. The OSG 2.9.x are developer releases. I think 2.9.11 isn't even released yet, so that's the bleeding edge of OSG sources from SVN - which currently cannot be used with FG (some pushed an incompatible interface to the OSG SVN repo a short while ago). Unless you really intend to mess with new OSG features, it's probably best to go for the latest _stable_ OSG release (currently 2.8.3). Otherwise go for an official developer release (i.e. 2.9.10). cheers, Thorsten -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] NaNs when resetting JSBSim
On Sat, Jan 22, 2011 at 10:36 PM, Andreas Gaeb wrote:
I've been looking a bit into the NaN issues. A way to produce them on my
system is to reset JSBSim aircraft, although it happens only about every
fifth time on average, and there are at least two different places in
the code where the NaN finally surfaces, both of which are not the root
cause. For the analysis, I used gdb to run the git version with
--enable-fpe.
Excellent! It's a really annoying and persisting problem - though several
related issues were already fixed. Would be great to finally rid this issue
(it's bug #222 http://code.google.com/p/flightgear-bugs/issues/detail?id=222
).
For one of the locations (FPE caught in SGIntersect.hxx:754) I could
trace the problem down to JSBSim.cxx. The data members are only
initialized to zero the first time an instance of FGJSBSim is created.
Uh, ugly! Why (and where?) are these members only initialized when the first
instance is created? Or are they never initialized and it's just because
memory often happens to be 0 when the first instance is created?
The minimal solution for this one is to explicitly set to zero those
data members which will be used later without explicit initialization,
in this case last_hook_tip[] and last_hook_root[], see attached patch.
Though it probably wouldn't hurt to initialize all members.
Definitely a good idea! Uninitialized members easily cause random (=very
ugly) problems - and such issues are a pain to debug. I'm strongly in favour
of initializing all variables/members in the constructor. And especially so
in a case like this, where few objects are created: even if initializing a
certain member wouldn't be necessary, it doesn't cost us much except a few
bytes of code - but no run-time performance at all.
So this is about what I found out until now, I'll try to keep looking
further into this. Can anybody point me to some documentation about how
initialization of class members is supposed to happen the right way?
Not quite sure what you mean with the right way. Would be good to
initialize all members in the constructor - with sensible data. I personally
prefer proper C++ initializers (where possible), since it's a lot easier
to spot if and which members are initialized, i.e. something like:
MyClass() :
_member1(NULL),
_member2(-1),
..
{
...
}
Thanks for looking into this issue!
cheers,
Thorsten
--
Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
Finally, a world-class log management solution at an even better price-free!
Download using promo code Free_Logger_4_Dev2Dev. Offer expires
February 28th, so secure your free ArcSight Logger TODAY!
http://p.sf.net/sfu/arcsight-sfd2d___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --fg-aircraft and multiplayer..aircraft not found?
On Thu, Jan 20, 2011 at 4:56 AM, Jacob Burbach wrote: Was just playing around a bit on MP and noticed that aircraft located in directories specified with --fg-aircraft do not seem to get picked up by multiplayer. The pilot list shows them as aircraft not installed in the pilots list, and you just get the good old yellow glider. Once I copied or linked the aircraft in question to $FG_ROOT/Aircraft or $FG_ROOT/AI/Aircraft, they are then found. Anyone else notice this...is it a feature, a bug, or just some mistake on my end somewhere? It didn't work with MP initially - but that was fixed months ago. I'd been using this with MP a quite a lot afterwards. And I guess you're using a recent build, so it should work, though I haven't tested it in recent weeks. There is a missing feature with the $FG_ROOT/AI/Aircraft: the AI/Aircraft models have to be in FGDATA - these don't work with --fg-aircraft yet, only the main models do. Also, only a single --fg-aircraft command-line argument is supported. If it's still not working for you, then which OS are you running (you have a proper filesystem supporting directory links, so probably not Windows ;) ), what's the exact command-line and also how does the directory structure in your --fg-aircraft directory look, i.e. are you using an Aircraft subdirectory? cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] --fg-aircraft and multiplayer..aircraft not found?
On Thu, Jan 20, 2011 at 6:22 PM, Jacob Burbach wrote: Oh...but previously we had discussion (December?) in regards to IO permissions 'not' working if you used an Aircraft directory directly and had to use only a directory 'containing' an Aircraft directory. This must be a fairly recent change then I guess? I'm not aware of any IO permission discussions. But I'm also _not_ using an Aircraft subdirectory. It's been like this for a while now (at least since I started using it last September). Fix for multi-player aircraft was pushed in November. Try if it works for you after removing the subdirectory. Indeed, the directory structures are a bit confusing - a directory check/error messages would help here. cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM support?
On Wed, Jan 19, 2011 at 10:41 PM, jack.w wrote: Looking over the wiki page and info. Is Sb747 and AVC limited to MS windows based machines? Or is there a Linux version as well? Is source available? Only the sources of Reed's FlightGear interface (SquawkGear) is available, but not those of SquakBox (SB747) aren't - due to licensing issues with VATSIM. At least the author says he has promised VATSIM not to disclose the sources. What's worse, SB747 is no longer maintained. It works for now as it is, but has several drawbacks: apart from not being open source, it annoyingly always reports a 747 aircraft to VATSIM. So even if you flew an Airbus or a small Cessna on FlightGear - you'll show up as a 747 on VATSIM. And yes, SB747 is Windows only. People running normal Linux or some obscure platform (such as Macs :-b ) need to run the Windows software in a virtual machine - or use Wine. Both works. Yes, it'd be great if there was an open source FG adapter to VATSIM - it could also be a single utility then and a lot easier to install. But I guess that's not going to happen too soon. cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Heads up: bugfix with some impact (probably)
On Mon, Jan 17, 2011 at 8:07 PM, Torsten Dreyer wrote: Hi all, I just pushed a bugfix to SGMisc::normalizePeriodic(min,max,value). The method allways returned zero for values less than min instead of normalizing these values into the given period. Excellent catch! As so often: when complex things work, then simple things fail (such as a max/min range check)... I think this should also go into the 2.2.0 branch - if I only knew how to... I think so, too. Try this for simgear: # create local 2.2.0 branch git branch releases/2.2.0 origin/releases/2.2.0 # switch branch git checkout releases/2.2.0 # merge current next into 2.2.0 release (ok right _now_, since there are no simgear commits _yet_ # which mustn't go to the release - otherwise pickapply patch manually) git merge next # push local branch to remote branch... git push g...@gitorious.org:fg/simgear.git releases/2.2.0:releases/2.2.0 # back to next (don't forget! :) ) git checkout next It should work. However, admittedly I have slightly messed up my first attempt to push to the FG/2.2.0 branch yesterday. So maybe I shouldn't start teaching GIT today... :) cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] VATSIM support?
On Sat, Jan 15, 2011 at 4:39 PM, jack.w wrote: Is this a feature in the latest git version? There have been discussions over the years on hooking into the IVAO and VATSIM communities. Was not aware that the connection had been made. Giving a talk in March at UC Davis on using FlightGear in my full scale 747 sim and Linux. Would like to include a few words on this feature. Could someone point me to the relevant code or any writeups or discussions on the topic This is not a feature of FlightGear itself, but a separate utility/setup that makes the connection (via SquawkGear and SquawkBox - the latter provides the actual (and approved) VATSIM interface). I've also tested it - and, yes, indeed it works. To get started: http://wiki.flightgear.org/index.php/SquawkGear cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] AI traffic performance update
On Tue, Jan 11, 2011 at 8:33 PM, Vivian Meazza wrote: I haven’t seen an problems so far, although I’m not sure why my aircraft was instantiated at one end of the runway, while the whole of KLM was taking off from the other. Perhaps we have a mismatch in the runway selection code, but that would have nothing to do with this update. Not quite sure about the sim itself, but I believe the sim isn't waiting for valid METAR before selecting the start-up runway (or it has a timeout and doesn't always wait long enough). AI traffic always waits for valid METAR, no matter how long it takes, to avoid an immediate change of active runway. I guess that's why the sim and AI traffic sometimes select the different runways - and why the AI traffic is instantiated with some delay after start-up. Could be solved by waiting for METAR before selecting the sim's runway - which may mean a longer start-up delay though... I would call this a good update. Good :). cheers, Thorsten -Original Message- *From:* [mailto:bre...@gmail.com] *Sent:* 10 January 2011 20:55 *To:* FlightGear developers discussions *Subject:* [Flightgear-devel] AI traffic performance update Hi, I've pushed a tiny update for AI traffic to flightgear/next. It improves performance at airports with busy AI traffic by avoiding repeated elevation/scenery checks for stationary aircraft. On my system this means a considerable frame rate improvement at EHAM (many AI aircraft parked at a gate). The improvement takes effect a short while after you started or got close to an airport. Once the parked AI aircraft have positioned and checked the scenery elevation, frame rate should improve. As a side effect, the update also changes (but doesn't fix) the behaviour of a bug (#221) concerning multiple aircraft occupying the same parking position: such models no longer climb upwards to infinity, but just remain idle and stacked on-top of each ( Bremer Town Musician's stylehttp://en.wikipedia.org/wiki/Town_Musicians_of_Bremen:) ). A bit better than before. Unfortunately Durk isn't available for review. So let me know if you noticed any new problems related to stationary AI aircraft. Likewise if you see improved performance. If there are no new issues and it turns out to be an improvement for more people, we might add this to the release branch too. Otherwise we'll need to wait for Durk's AI expert advice. cheers, Thorsten -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B
I successfully flew the TU154b now at KSFO, LOWI and EDDF - but experienced no NaNs and no crash (neither did the sim, nor the plane - I'm especially proud of the latter :) ). But yes, I needed to use the chicken's auto start to get anything working at all. Absolutely amazing cockpit, incredible detail, incredible number of switches... Anyone else seeing these issues? cheers, Thorsten On Mon, Jan 10, 2011 at 5:18 AM, Jacob Burbach jmburb...@gmail.com wrote: Probably best to just post on his Tu154 thread on the forum, pretty sure he monitors that. http://flightgear.org/forums/viewtopic.php?f=4t=4925 On Sun, Jan 9, 2011 at 12:10 PM, ThorstenB bre...@gmail.com wrote: I'm not seeing any NaN issues with the TU154b. Hmm, could be on my end, you never know. Did you try a few times, at some different airports though? I can load a couple times out of a dozen, but mostly just crashes out with NAN stuff. I frequent LOWI, EDDF, LIMC, LSZS, etc...and have trouble at those as recently as a few hours ago. I will do more testing soon, need to make sure (again) build is clean and also do a new debug build. Though I'm not able to start it - well, not within 10 minutes at least. :) If your using newest version or svn then just press the 's' key and then wait until it is finished. ;) There is a minor issue with incorrect property name though. I've attached a patch. Anyone in contact with the TU154b designers? There's no email in the README. Maybe s.o. can forward the patch. Probably best to just post in the Tu154 thread on the forum, pretty sure Yurik keeps an eye on that. http://flightgear.org/forums/viewtopic.php?f=4t=4925 cheers -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] AI traffic performance update
Hi, I've pushed a tiny update for AI traffic to flightgear/next. It improves performance at airports with busy AI traffic by avoiding repeated elevation/scenery checks for stationary aircraft. On my system this means a considerable frame rate improvement at EHAM (many AI aircraft parked at a gate). The improvement takes effect a short while after you started or got close to an airport. Once the parked AI aircraft have positioned and checked the scenery elevation, frame rate should improve. As a side effect, the update also changes (but doesn't fix) the behaviour of a bug (#221) concerning multiple aircraft occupying the same parking position: such models no longer climb upwards to infinity, but just remain idle and stacked on-top of each ( Bremer Town Musician's stylehttp://en.wikipedia.org/wiki/Town_Musicians_of_Bremen:) ). A bit better than before. Unfortunately Durk isn't available for review. So let me know if you noticed any new problems related to stationary AI aircraft. Likewise if you see improved performance. If there are no new issues and it turns out to be an improvement for more people, we might add this to the release branch too. Otherwise we'll need to wait for Durk's AI expert advice. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Latest git results in massive NAN errors with Tu154B
I'm not seeing any NaN issues with the TU154b. Though I'm not able to
start it - well, not within 10 minutes at least. :)
There is a minor issue with incorrect property name though. I've
attached a patch.
Anyone in contact with the TU154b designers? There's no email in the
README. Maybe s.o. can forward the patch.
cheers,
Thorsten
--- a/TU154B/engines.nas 2009-05-14 21:11:09.0 +0200
+++ b/TU154B/engines.nas 2011-01-09 17:42:10.0 +0100
@@ -86,7 +86,7 @@
var eng_1_handler = func{
settimer( eng_1_handler, ENGINE_UPDATE_PERIOD );
-if( getprop( engines/engine[0]/egt_degf ) == nil ) return;
+if( getprop( engines/engine[0]/egt-degf ) == nil ) return;
if( getprop( controls/engines/engine[0]/cutoff ) == nil ) return;
if( getprop( engines/engine[0]/n2 ) == nil ) return;
var pwr = getprop(tu154/systems/electrical/buses/DC27-bus-L/volts);
@@ -96,7 +96,7 @@
# EGT delivery to fdm property tree
setprop( fdm/jsbsim/propulsion/engine[0]/egt-degc,
- getprop( engines/engine[0]/egt_degf ) * 0.55 - 17 );
+ getprop( engines/engine[0]/egt-degf ) * 0.55 - 17 );
if( getprop( tu154/switches/startpanel-cold ) == nil ) return;
@@ -134,7 +134,7 @@
if( getprop( engines/engine[1]/n2 ) == nil ) return;
# EGT delivery to fdm property tree
setprop( fdm/jsbsim/propulsion/engine[1]/egt-degc,
- getprop( engines/engine[1]/egt_degf ) * 0.55 - 17 );
+ getprop( engines/engine[1]/egt-degf ) * 0.55 - 17 );
if( getprop( tu154/switches/startpanel-cold ) == nil ) return;
var pwr = getprop(tu154/systems/electrical/buses/DC27-bus-L/volts);
@@ -168,7 +168,7 @@
if( getprop( engines/engine[2]/n2 ) == nil ) return;
# EGT delivery to fdm property tree
setprop( fdm/jsbsim/propulsion/engine[2]/egt-degc,
- getprop( engines/engine[2]/egt_degf ) * 0.55 - 17 );
+ getprop( engines/engine[2]/egt-degf ) * 0.55 - 17 );
if( getprop( tu154/switches/startpanel-cold ) == nil ) return;
var pwr = getprop(tu154/systems/electrical/buses/DC27-bus-L/volts);
--
Gaining the trust of online customers is vital for the success of any company
that requires sensitive data to be transmitted over the Web. Learn how to
best implement a security strategy that keeps consumers' information secure
and instills the confidence they need to proceed with transactions.
http://p.sf.net/sfu/oracle-sfdevnl ___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.2.0 Release branches
On Sat, Jan 8, 2011 at 8:44 PM, Roland Haeder wrote: I have an FPE to report and a small fix (I already mentioned the FPE in IRC chat). The fix is included, with some white-space cleanup. The FPE patch is a duplicate, since Curt has already committed a similar fix for this FPE on December 20th: http://www.gitorious.org/fg/flightgear/commit/f8015bf54f5439a9fa70661ac31a10ef8c81f58f I guess you just need to pull latest GIT. I'm pushing the other changes with additional include files now. Thanks! cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] 2.2.0 Release branches
On Sat, Jan 8, 2011 at 10:39 PM, Roland Haeder wrote: Thanks for including the missing include lines. Jester gave me them in IRC so please credit him. :) Too late! Sorry Jester, well done anyway :). cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Fri, Jan 7, 2011 at 6:58 PM, Curtis Olson wrote: I make a small test edit to a file (src/GUI/MapWidget.cxx). I run git checkout next to return to the pristine unchanged branch that tracks the head on gitorious --- but here is the output: $ git checkout next M src/GUI/MapWidget.cxx Switched to branch 'next' $ git branch maint mychanges * next next is the current branch, but the change I made in the mychanges branch to MapWidget.cxx is still visible. What am I missing? Why is a change that I made in one branch being shown in a different branch? The change you made is _not_ in any branch yet. It's just a local change in your filesystem. git doesn't automatically add any changes to a branch. Maybe you just edited the file for a temporary test. Or you find out the change doesn't work at all and want to revert it immediately. You need to explicitly add any change to a branch - otherwise the change isn't in git. So, only when you run git add MapWidget.cxx; git commit is your modified file added to the current branch. Running git checkout somebranch won't touch modified files in your filesystem. I actually really like this feature: you can make local changes and then quickly change branches to see how the changes work with different branches. When you're happy, you switch to the branch you want to commit it to and finally add and commit the change to git. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On Fri, Jan 7, 2011 at 7:48 PM, Curtis Olson wrote: So what happens if I'm messing around with my WildCrazyIdea-I-WantToTry branch over lunch, and suddenly I get a phone call and have to jump back to doing something serious with FlightGear and need to quickly switch back to my RealWork branch. Do I have to commit my CrazyIdea branch changes --- no matter what intermediate state of weirdness they are in --- before I can switch back to the RealWork branch? If you want git to take care of switching these files, then yes, you'll need to commit them to some branch. I'm not familiar with this stashing option. What I'd do is either commit the changes to the current branch - or, in case the changes are just too experimental and I really don't want to modify the current branch, I just create a new branch git checkout crazyidea. The new branch is identical to the former current branch then. So I can just addcommit the experimental changes to the new crazyidea branch and then switch back to the former working branch - or to some other stable branch... And you can always remove the crazyidea branch again - if the idea turns out not to be so good after all, or you just wanted something temporary. cheers, Thorsten -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] map question
The F14 disables the first menu item from the 5th menu ext_stores.nas = setprop(sim/menubar/default/menu[5]/item[0]/enabled, 0); Not sure which menu item originally was at this location. Quite bad. Harded coded hacks like this just always break... ;) cheers, Thorsten On Thu, Dec 30, 2010 at 6:26 PM, Curtis Olson curtol...@gmail.com wrote: On Thu, Dec 30, 2010 at 11:18 AM, James Turner wrote: On 30 Dec 2010, at 16:01, Curtis Olson wrote: I see the built in flightgear map dialog is activated in the 777-200ER, but disabled (grayed out) for the F-14b. I can't find the mechanism or place where this is set. How can i control the availability of the map dialog? That's weird - I wrote the dialog, and originally added it to the 'Autopilot' menu - next to the route manager. When the menubar was recently cleaned up, it was moved tot he 'Equipment' menu - which I wholeheartedly agree with, since the Autopilot menu is disabled on the C172, for example. As far as I know, the menu item is 'just' a regular entry in the Equipment menu, so I would guess the f14 would be disabling it - but that seems quite unlikely too. We should probably find out if it's deliberate or accidental. I've been grepping for Map, map, dialog and haven't turned up anything yet that seems to connect. Any suggestions what keywords I should even be grepping for? I haven't been able to find any promising references in the f-14b tree. Thanks, Curt. -- Curtis Olson: http://www.atiak.com - http://aem.umn.edu/~uav/ http://www.flightgear.org - http://www.flightgear.org/blogs/category/curt/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] map question
Oh, this actually shows a larger problem. Obviously it isn't too uncommon for aircraft to disable or override specific menu items - mainly affects menu items for the radio stack and autopilot. Unfortunately all of this is done using fixed menu item positions - e.g. 5th menu, 3rd item... So any change of the menu item ordering currently breaks lots of planes. And obviously the recent menubar overhaul has done just that. We'll need to adapt all the aircraft using such hacks to the changed menu structure. And might need to think about a better solution to avoid future problems of this kind. I did a quick grep to find potentially affected aircraft (couldn't verify if their menus are all broken now, but that's the ones overriding or disabling specific menu items using fixed positions): 717 737-300 737NG600 737NG700 737NG800 737NG900 747-400 757-200 777-200 A320-family A380 Aerostar-700 b1900d Citation-Bravo CitationX CRJ-200 CRJ-900 f16 f-14b fokker100 MiG-15 VMX22-Osprey = All the aircraft above override the radio and/or autopilot dialogs. Except for the MiG15, which just disables one dialog (like the f14). So, what do we do? Adapt all the aircraft above - or revert the menu item ordering? cheers, Thorsten On Thu, Dec 30, 2010 at 6:37 PM, ThorstenB bre...@gmail.com wrote: The F14 disables the first menu item from the 5th menu ext_stores.nas = setprop(sim/menubar/default/menu[5]/item[0]/enabled, 0); Not sure which menu item originally was at this location. Quite bad. Harded coded hacks like this just always break... ;) cheers, Thorsten -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] map question
On Thu, Dec 30, 2010 at 10:47 PM, Citronnier - Alexis Bory wrote: Yes, it was intended to disable the stock Fuel and Payload menu. I'll adapt the code to follow the new ordering. It should be in git very soon. On Thu, Dec 30, 2010 at 10:52 PM, Scott Hamilton wrote: Actually this might not be so bad, as I think your grep may have returned some false positives. The A380, 747-400 and 737NG800 only add an aircraft specific menu and add Pushback to the Equipment menu, they don't disable any existing menu items. However giving menu items an alias name or unique id is still worth doing, and a way to check if an alias is present before adding new items would be nice as well. Please wait before committing any related changes! There is also a bug report to track this problem: http://code.google.com/p/flightgear-bugs/issues/detail?id=231 I still vote for keeping the original menu ordering in the Equipment menu for the upcomming release, otherwise we have another incompatibility - and a very unnecessary one. It's very simple to avoid this issue for this release (keep fuelpayload/radio/autopilot menu items in original position). And it may still affect more planes (those not in GIT). Also, currently we have no clean solution for this issue. So any change now would require adapting the aircraft now, and then again for the next release. I think it's better to keep the original ordering for now, then provide a proper solution (i.e. option to override/disable menu items via symbolic names) for the next release. Aircraft then only need to be changed once. cheers, Thorsten -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FPE while in-flight
On Mon, Dec 20, 2010 at 9:12 AM, Roland Haeder wrote: I got another FPE with GIT version while in-flight with the A380 (recent updates of fgdata). I flew with auto-pilot turned on from EDDL to EHAM and suddenly the FPE happens: I had a look into some of these FPEs. However, there's tons of places where FG runs into such problems. May be caused by incorrect/incomplete FDM configurations (e.g. affects specific aircraft only), due to computation on unused/uninitialized data (e.g. since a feature is disabled but the associated computation is still executed), due to plain programming bugs - or even used deliberately (...we don't need a division-by-zero check here since FPEs are disabled anyway...). And it affects the FG core - but also aircraft specific Nasal scripts. So, unfortunately, divisons-by-zero, processing with infinity or NaN (not-a-number) values isn't really uncommon for FG. And since the FG default is to ignore any FPE (i.e. not to use the --enable-fpe option), few people care (I guess). Personally I don't like ignoring such exceptions, since it often hides real programming errors. So, yes, I think it'd be great if someone had a look into these issues, finds all the bad computations and fixes them. However, since everyone (?) else in FlightGear keeps FPEs disabled, it may turn out to be a Sisyphean task to rid _all_ such occurrences... cheers, Thorsten -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On 11.12.2010 09:16, Durk Talsma wrote: Firstly, what is the next version number going to be. My initial thought would be 2.1.0, but it also makes sense to call if 2.2.0 (thanks for the suggestion, James), so that we can reserve 2.1.0. for bugfixes on the current version, or at least move toward a versioning system like that (i.e. the next series could be 2.2.0 for stable, and 2.3.0. for development). +1! A scheme which covers stable/unstable (GIT) versions seems a very good idea. Many people are using the GIT version, so it'd be good to have a specific version for such builds. But bugfixes should only affect the third version number then, i.e. a bugfix for the 2.0 stable should be 2.0.1. It sill makes sense to move to 2.2.0 now - stable release versions should be even. Seconly, do we want to maintain our current aircraft selection, or do we want to include a (partially) updated selection from our git repository, or -alternatively- do we want to strip the entire selection down to just single aircraft, and make the others downloadable from our main website. I know that James turner is working towards an infrastructure that should enable this, but I'm not sure whether we are already comfortable enough to just use one single aircraft. The new system allowing multiple aircraft dirs works great. However, it seems not too many people have used it so far. And at some point after the release, we wanted to split FGDATA into several smaller repositories (I know Tim has already been working on this), so we'd be introducing a new system for 2.3 (GIT) / 2.4 (future stable) anyway. So it might be better to stick with the current system for this release and not have another unnecessary intermediate. And we'd get a lot of GIT users testing the new directory and distribution system with 2.3.0 - so that would be rock stable for 2.4. cheers, Thorsten -- Oracle to DB2 Conversion Guide: Learn learn about native support for PL/SQL, new data types, scalar functions, improved concurrency, built-in packages, OCI, SQL*Plus, data movement tools, best practices and more. http://p.sf.net/sfu/oracle-sfdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FPE in yasim::Atmosphere::calcStdDensity
On Wed, Dec 8, 2010 at 11:14 PM, Roland Haeder wrote: I use the following call to start FGFS: -- fgfs... ... --aircraft=aircrane --enable-fpe Thanks, that actually always reproduces it. And the temperature at EDDL can now really be at 0 deg. Celsius because of winter time. :) Yep, looked like a mix-up of Kelvin vs Celsius at first. But that's not the problem. It doesn't depend on season or environmental temperature. The specific calculation failing doesn't even use the actual temperature. So the aircrane always crashes when using --enable-fpe. The trigger is a missing configuration setting in the FDM description. The YASim FDM seems to rely on a valid cruise and an approach configuration. Several things are not properly initialized unless both configurations are present in the XML file. The aircrane only provides an approach configuration. This results in stupid default values being used, so it eventually starts calculating with a temperature of 0 Kelvin (where the classic laws of aerodynamics, gas and pressure seem to fail...). Adding the following configuration to aircrane.xml fixes this issue: cruise speed=84 alt=0 control-setting axis=/controls/engines/engine[0]/throttle value=1.0/ /cruise That's a configuration I copied from a different helicopter. Maybe helijah/Heiko can comment on the correct FDM settings for the aircrane. The underlying problem with YASim should also be fixed. Not nice when missing config settings result in the FDM going wild. In fact, this could explain a number of issues why specific YASim aircraft run into infamous NaN problems (few people use --enable-fpe to abort on floating point exceptions, so divisions by zero result in Not-a-Number results). There maybe more config options (and aircraft) where YASim goes mad when settings are missing... cheers, Thorsten -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FPE in yasim::Atmosphere::calcStdDensity
On Thu, Dec 9, 2010 at 1:12 AM, Heiko Schulz wrote: Not really, as I or helijah is not the author of the aircrane-fdm. Oh sorry, didn't want to credit the wrong person! :) (maybe a copypaste problem since you're credited in the readme). But Maik Justus, the author of it, told me once ( and it is described in the data/docs/ReadMe.yasim as well, I think) that the approach-speed and cruise-speed is ignored for helicopters. It is only important for the gear-behaviour. How, you can read here: http://code.google.com/p/flightgear-bugs/issues/detail?id=155sort=-id I'm not an FDM expert. Maybe the speed has no meaning. But right now, YASim uses the given cruise altitude. And when the cruise section is missing, YASim doesn't initialize any cruise settings - including the cruise temperature _cruiseT. And since its (stupid) default is 0 (Kelvin) this triggers the exception (Airplane::solveHelicopter calls Atmosphere::calcStdDensity(_cruiseP, _cruiseT)) ) cheers, Thorsten -- This SF Dev2Dev email is sponsored by: WikiLeaks The End of the Free Internet http://p.sf.net/sfu/therealnews-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPWS-implementation on the 733 failed- can someone help?
On Tue, Nov 30, 2010 at 2:14 PM, Heiko Schulz wrote: Thorsten B has done a huge amount of work on the GPWS in the past few months, my impression is that with the latest Git code, it's working better than at any point in its history - with the caveat, assuming you have configured it correctly! James We just followed ThorstenB's wiki tutorial for implementing the GPWS... And that's our question: it seems something changed, but not in the wiki. And we are just asking for help to get it working again Yes, I kind of adopted the GPWS. And there haven't been any recent changes, so the wiki description should still be correct (unless there was a mistake from the beginning...). Have you tested the GPWS with the latest 777-200 (in GIT since Sunday)? It's definitely working there. If it wasn't working for you, then we need to look at some FG problem (like the recent sound or directory access issues). If the 777 GPWS is working for you, then it's related to aircraft configuration. I'll be testing and looking at the 733. And those interested in a full-blown GPWS integration could check the 777-200 now. It has a new gpws Nasal wrapper to provide functionality like flap-, gear- and G/S-override buttons. It also shows how to allow lower flap settings for landing (by default, the GPWS requires full flap extension), connection of the master warning light, and how to connect the PFD, i.e. to display the PULL UP TCW (time critical warning). Admittedly, the GPWS in FlightGear is a bit complicated. The main reason is that the original author chose to simulate an actual hardware device (a specific type made by Honeywell). All inputs and outputs match the real counterpart - even the binary encoding of digital I/O. And yes, the configuration parameters (category-1...) are also identical to the real device. It just doesn't get any more realistic than this. But while this may make integration/configuration a bit more complicated than usual, I still think his work is really great. And remember about FlightGear: it's not a game - it's a real sim! :) cheers, Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPWS-implementation on the 733 failed- can someone help?
On Tue, Nov 30, 2010 at 7:54 PM, Heiko Schulz wrote: I had a look into, even ported the related subsystems over to the 733, but no success. Scott (working on the A380) noticed the same with the wiki-tutorial and the GPWS. Interesting to know and maybe a hint: A380 and 733 are both JSBsim. Right, that is related to the problem. Depending on configuration the GPWS relies on a specific altitude source which is only available for YASim right now. You could switch the category-8 parameter to 3 (instead of 2) - and the GPWS will work with JSBSim and other FDMs. However, please wait before pushing any ac changes, since this solution isn't good enough. The point here is that the GPWS needs a pretty accurate altimeter source for main-gear-above-ground-level, otherwise the important final callouts 20.10 make no sense. Since there is no such FDM source (except for YASim) we'll need to hook it to the radio altimeter instrument - which isn't available as a GPWS default source yet. I'll be changing and testing something here - and hopefully push something later this week (also a Wiki update, if required). Thanks for the report! And to reiterate: everyone, please report if you notice something wasn't working. Just add something to the tracker. Yes, reports there are monitored and bugs fixed (eventually) - even if some issues cannot be fixed on the same day :). cheers, Thorsten -- Increase Visibility of Your 3D Game App Earn a Chance To Win $500! Tap into the largest installed PC base get more eyes on your game by optimizing for Intel(R) Graphics Technology. Get started today with the Intel(R) Software Partner Program. Five $500 cash prizes are up for grabs. http://p.sf.net/sfu/intelisp-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
