Re: [Flightgear-devel] release discussion
On 15.04.2011 01:22, Martin Spott wrote: > Note that there are a couple of updates/additions (and removals) to the > Base Package which have, as far a I can tell, not yet been migrated to > the release branch. At least the stuff Jon Stockill and I have > committed to the Models/ subdirectory is affected. Ok, not sure what has changed there, but is it important enough to be migrated to 2.2? I know it's tempting to make all the new features available right now (I'd like to see my new TCAS in the release, we've had 2 JSBSim updates, new HLA support, tank properties, joystick reloading, of course many many really nice Aircraft updates...). But they are not release-blocking. Last 2.2.0 fixes were applied on February 19th. I'll have a look at the commits on next/master since then. Anyone else aware of missing and release-blocking commits apart from the Models subdirectory? 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] release discussion
ThorstenB wrote: > On 15.04.2011 01:22, Martin Spott wrote: >> Note that there are a couple of updates/additions (and removals) to the >> Base Package which have, as far a I can tell, not yet been migrated to >> the release branch. At least the stuff Jon Stockill and I have >> committed to the Models/ subdirectory is affected. > > Ok, not sure what has changed there, but is it important enough to be > migrated to 2.2? Definitely. The changes to the Base Package _I_ was having in mind are the addition of a couple of new shared models (which are in active use with the World Scenery), updates/improvements/bug-fixes to old models and replacement of RGB textures by PNG's. Nothing complicated, but certainly worth putting into the release. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- 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] Simple atmospheric scattering shader for skydome
On Fri, 15 Apr 2011 08:41:42 +0200, Erik wrote in message <1302849702.1655.1.camel@Raptor>: > On Fri, 2011-04-15 at 00:16 +0200, Christian Schmitt wrote: > > I can only agee with Vivian here: lets get this change into GIT, so > > that it doesn't get lost as so many others in the past. The shader > > is not perfect yet, but that should not hurt, as it is disabled as > > a default. Those who want to test and improve it are free to do so. > > Let me add that it's good to have people who work on things like > > shaders (we need every single one of them). > > I'm not opposed to adding the shaders but I want a good look at the > code to make sure that current functionality is not lost with the > patch before it gets committed. > > Erik ..and, we better find out what's going on with the shader artifacts on ATI cards, if FG-2.2 is anything like FG-git, it is _not_ ready. -- ..med vennlig hilsen = with Kind Regards from Arnt Karlsen ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. -- 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
Am 14.04.2011 21:39, schrieb Torsten Dreyer: > Isn't that what SGReferenced objects were made for? Automatic deletion? > Minimal but slight more complex example [...] yes, this works as expected -- as long as one uses SGSharedPtr. The componentForge map uses standard pointers at the moment, so it doesn't work here. However, I have no idea how SGSharedPtr can be used in combination with functor, static map > > componentForge; doesn't even compile. 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? Best regards, Andreas -- 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] Simple atmospheric scattering shader for skydome
On 15 Apr 2011, at 08:41, Erik Hofman wrote: > On Fri, 2011-04-15 at 00:16 +0200, Christian Schmitt wrote: >> I can only agee with Vivian here: lets get this change into GIT, so that it >> doesn't get lost as so many others in the past. The shader is not perfect >> yet, but that should not hurt, as it is disabled as a default. Those who >> want to test and improve it are free to do so. >> Let me add that it's good to have people who work on things like shaders (we >> need every single one of them). > > I'm not opposed to adding the shaders but I want a good look at the code > to make sure that current functionality is not lost with the patch > before it gets committed. > Like, Christian and Vivian stated earlier, I would also hate to see a patch getting lost, especially when it contains promise. This is why I originally suggested committing it. I would suggest that (even though it may not be production-ready yet), we commit the patch on the condition that; 1) the shader in question is disabled by default, and 2) in its disabled state doesn't have an adverse impact . Thoughts / Ideas? Cheers, Durk -- 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] Simple atmospheric scattering shader for skydome
On Fri, 2011-04-15 at 11:22 +0200, Durk Talsma wrote: > Like, Christian and Vivian stated earlier, I would also hate to see a patch > getting lost, especially when it contains promise. This is why I originally > suggested committing it. > > I would suggest that (even though it may not be production-ready yet), we > commit the patch on the condition that; 1) the shader in question is disabled > by default, and 2) in its disabled state doesn't have an adverse impact . > > Thoughts / Ideas? Let me take a look at it this weekend and I'll commit it then. Erik -- 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] Simple atmospheric scattering shader for skydome
Hi. Nice to see my shader brought up some discussion :) First, Vivian, I tried to see your screenshots, but the link wasn't working (server down or something?) so I cannot comment them right now. And I didn't mean the bug with sun reflection on the water being misplaced from the real shader, but sometimes it seems like the sunset effect on the (non shader) skydome is someting like 90 degrees to the left. I'm not sure if it always was like that or did I change something or am I just seeing things. It looks like the brightest spot of the horizon is not where the sun is, but to the left. If someone can confirm (with old version & my version if possible), would be much appreciated. Second, Erik, I tried not to change the old behaviour but I needed to move some code around to get better precision in the skydom model. I hope everything works like it did with the non shader version, I didn't quite understand all the equations but the code should not change those. Only behaviour that I did change is the clear color in FG from fog color to black. I don't see anything changing near the ground, but the effect near space is better :) Other topics, mie and rayleigh coefficients are exposed, but maybe I shuold expose the wavelength dependency too, because that is what affects the sky color the most. The idea is that some code in FG/SG would write the proper coefficients depending on weather conditions to make different looking skies. I also uploaded the python code I used for evaluating the shader and calculating the scale coefficients etc. It is here: http://users.tkk.fi/~lapelto2/fgfs/scatter/scatter.py I can also write a wiki article on the subject should it be necessary. In the future, I'd like to see this shader as a post processing effect applied over all rendered objects so we would get a consistent look and feel everywhere. And also, I didn't think about getting this to the next release, it's too late for that. But maybe to the one after that, so we have time to test things first. Wbr, Zan -- Lauri Peltonen -- 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] YASim issues
On Thursday, April 14, 2011 21:40:10 Gary Neely wrote: > Adrian, > > Great catch on the fuel and glideslope issues. You're right-- despite > parsing the fuel attributes and supplying defaults if necessary, it > has the defaults hard-coded right in the Airplane::compile block. It > seems to consider the user-supplied values for aircraft mass, but not > elsewhere. Makes me feel dumb that I'd not noticed this before. I hope > this one makes it in the new build! > > -Gary > Well, I'm glad it helps. The patch should not affect the solution too much in most cases, I've checked this myself. Syd, about the fuselage contact points: they are internally represented as a gear object, only without the compression stuff and with hardcoded values for static and dynamic friction. I think using fake gears directly would give a little better tweaking precision, wouldn't it? Cheers, Adrian -- 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] Simple atmospheric scattering shader forskydome
Durk wrote > > On 15 Apr 2011, at 08:41, Erik Hofman wrote: > > > On Fri, 2011-04-15 at 00:16 +0200, Christian Schmitt wrote: > >> I can only agee with Vivian here: lets get this change into GIT, so > that it > >> doesn't get lost as so many others in the past. The shader is not > perfect > >> yet, but that should not hurt, as it is disabled as a default. Those > who > >> want to test and improve it are free to do so. > >> Let me add that it's good to have people who work on things like > shaders (we > >> need every single one of them). > > > > I'm not opposed to adding the shaders but I want a good look at the code > > to make sure that current functionality is not lost with the patch > > before it gets committed. > > > > Like, Christian and Vivian stated earlier, I would also hate to see a > patch getting lost, especially when it contains promise. This is why I > originally suggested committing it. > > I would suggest that (even though it may not be production-ready yet), we > commit the patch on the condition that; 1) the shader in question is > disabled by default, and 2) in its disabled state doesn't have an adverse > impact . > > Thoughts / Ideas? > I'm just putting together a data commit to do just that. But it will still need the Fg/SG patches 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] download_and_compile.sh script link
Hi Arnt, >> > >> http://geoffair.org/tmp/makefg > ..idea for makefg-1.3.0: WEUSESYSTEMPLIB=1, WEUSESYSTEMOSG=1 Already thought of, and done ;=)) For all the recent versions there are options - PLIBPATH= OSGPATH= Which should do what you ask, but I have NEVER installed PLIB nor OSG into a 'standard' system path, so have never tried these options in that case, but they should work... That is why the only relevant thing I get is 'openal' when I run things like - "for i in openal plib openscene simgear \ flightgear ; do dpkg -l |grep $i ;done |fmt -tu " I have used, and tested them when I do _NOT_ want to download and build yet another of these 2, thus when building in say ~/fg/fg14, I can reuse say my builds in ~/fg/fg12/install/[plib|osgvers]... And likewise there are options - BOOSTPATH= BOOSTLIBS= to point to where BOOST is either installed or 'staged' (not built or installed)... And a very, _VERY_ important one these days :- FGDATADIR= to _NOT_ re-clone this massive block multiple times ;=)) time and space... However, at present you have to do MANUAL updates of such sources if the path is outside the 'root' build... and I think it will stay that way... As you may have learned, once a build completes successfully, some 'configuration' information is written to ~/bin/makefg-.conf file, so you do _NOT_ have to remember to re-input such paths when it is run again, again, and again... Of course, with care you can manually adjust this 'conf' file... but it is easy to mess up the simple parsing that is done... so not particularly recommended ;=() And that is why there is a option NO_CONF, to tell the script to ignore any 'configuration' file information, when you want to really 'change' the setup drastically... Lots of options ;=)) over 80-90 at last count... Regards, Geoff. -- 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] YASim issues
> Syd, about the fuselage contact points: they are internally > represented as a gear object, only without the compression stuff > and with hardcoded values for static and dynamic friction. I think > using fake gears directly would give a little better tweaking > precision, wouldn't it? > > Cheers, > Adrian Possibly , I think you've probably looked deeper into the code than i have there . Thought I'd bring up the idea in case it hadn't been tried . I,ve also tried to trigger that gear up crash but haven't been able too , (with my aerostar) , it does a belly landing and the crash property remains unset Cheers -- 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] YASim issues
Hi Syd, As Oliver Thurau (ot-666) found out, many fuselage sections will decrease framerates. That's why it is better to have fuselage section only when necessary. Heiko > Von: syd adams > Betreff: Re: [Flightgear-devel] YASim issues > An: "FlightGear developers discussions" > > Datum: Freitag, 15. April, 2011 16:36 Uhr > > Syd, about the fuselage contact > points: they are internally > > represented as a gear object, only without the > compression stuff > > and with hardcoded values for static and dynamic > friction. I think > > using fake gears directly would give a little better > tweaking > > precision, wouldn't it? > > > > Cheers, > > Adrian > > Possibly , I think you've probably looked deeper into the > code than i > have there . Thought I'd bring up the idea in case it > hadn't been > tried . > I,ve also tried to trigger that gear up crash but haven't > been able > too , (with my aerostar) , it does a belly landing and the > crash > property remains unset > Cheers > > -- > 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 > -- 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] YASim issues
> Possibly , I think you've probably looked deeper into the code than i > have there . Thought I'd bring up the idea in case it hadn't been > tried . > I,ve also tried to trigger that gear up crash but haven't been able > too , (with my aerostar) , it does a belly landing and the crash > property remains unset > Cheers > Indeed, I think it's impossible to trigger the crash with the aerostar, because the distance between the gear positions and the lowest contact points is smaller than 1 meter. Would you please try with the IAR80? Adrian -- 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] YASim issues
On Friday 15 April 2011 17:36:12 syd adams wrote: > > Syd, about the fuselage contact points: they are internally > > represented as a gear object, only without the compression stuff > > and with hardcoded values for static and dynamic friction. I think > > using fake gears directly would give a little better tweaking > > precision, wouldn't it? > > > > Cheers, > > Adrian > > Possibly , I think you've probably looked deeper into the code than i > have there . Thought I'd bring up the idea in case it hadn't been > tried . > I,ve also tried to trigger that gear up crash but haven't been able > too , (with my aerostar) , it does a belly landing and the crash > property remains unset > Cheers > To trigger it you'd have to use a plane with "tall" gear struts, as the iar80. It will trigger the crash as you're barely touching the ground with the prop (it might not even touch the ground and still trigger it if you're not perfectly level). Even with a fake gear under the belly, to prevent yasim triggering the crash property, it needs to be set pretty low, and as such the plane seems to float ~1-2ft off the ground. (propeller hast enable-hot set to false) Take a look at this: http://ompldr.org/vOGEyaQ (Forgot to put the crashed property up there too :( ) -- 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] Heads up: AI/ATC interactions
Hi, On Wednesday, April 13, 2011 11:52:30 Durk Talsma wrote: > Oh, and just hitting the "send" button a little too early, I had wanted to > add that Martin Spott pointed me that the possibilities of using the new > HLA layer for this purpose. I'm currently not familiar with HLA myself to > comment on that though, so I'm just passing this on. Ack. That is actually my next thing to try. Currently my time went into a hla/rti that is actually easy to use. Something that in the easiest case is not even noticable that it runs below. So there is some work left on that topic. It took me longer than expected. Actually my personal factor of about 2 for underestimating programming effort showed up again :) Major benefits would be to move the AI code out of the main loop - may be even into a seperate process/thread. Also runnig one instance of tha AI traffic for installations like we used to have at the linux tag booth would be a major advantage there. So, yes, building up something here ... Greetings Mathias -- 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] YASim issues
One small ,narrow fuselage piece inside and at the bottom of the main fuselage doesnt make a difference here, you don't need a lot . And they don't seem to trigger a crash like gear does. On Fri, Apr 15, 2011 at 8:46 AM, Heiko Schulz wrote: > Hi Syd, > > As Oliver Thurau (ot-666) found out, many fuselage sections will decrease > framerates. > > That's why it is better to have fuselage section only when necessary. > > Heiko > >> Von: syd adams >> Betreff: Re: [Flightgear-devel] YASim issues >> An: "FlightGear developers discussions" >> >> Datum: Freitag, 15. April, 2011 16:36 Uhr >> > Syd, about the fuselage contact >> points: they are internally >> > represented as a gear object, only without the >> compression stuff >> > and with hardcoded values for static and dynamic >> friction. I think >> > using fake gears directly would give a little better >> tweaking >> > precision, wouldn't it? >> > >> > Cheers, >> > Adrian >> >> Possibly , I think you've probably looked deeper into the >> code than i >> have there . Thought I'd bring up the idea in case it >> hadn't been >> tried . >> I,ve also tried to trigger that gear up crash but haven't >> been able >> too , (with my aerostar) , it does a belly landing and the >> crash >> property remains unset >> Cheers >> >> -- >> 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 >> > > -- > 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 > -- 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] Heads up: AI/ATC interactions
Hi, On Thursday, April 14, 2011 06:07:18 cas...@mminternet.com wrote: > Agree with the first part about hacking, but disagree with the second idea > of "cost" > > HLA is a follow-on to DIS and SimNet developed by DARPA and would require > either an extensive rewrite of FG to be HLA (Stanag 4603) > compliant or a wrapper function, In addition, there is a thing called > Run-Time Infrastructure (RTI) that handles the federates interfaces [...] > Maybe something along the lines of an "HLA-lite". From Durk's suggestion, > and the excerpt above it sounds like the multiplayer server might function > in the manner of an RTI for a limited set of object model types ( unless > we want to include submarines, tanks, bad guys, etc, etc... ;-) ) What you cited above is something that an RTI should implement in the end to be maximum scalable. But, you can implement an rti with just fewer of these options working. Much more than the above, the spatial indices implemented in the rti regions will be a huge benefit, since you will only recieve the messages that are relevant near the region of your interrest. Also the way an rti provides time management and time stamped messages, is benefitial. This enables hard syncronized hla federates, exchanging data at relatively high rates with the least possible communication latency. Regarding the ongoing threading discussion and the amount of cores an avarage cpu has today, an rti will provide a way to implement components of the simulation in a single threaded way, living in its own process. This can be done while still having a deterministic and tight coupling with other federates simulating in the same federation. This kind of coupling is required for example for a good simulation of glider towing for example. > However, a quick search indicates there is an open source HLA on > sourceforge License is Apache License V2.0, no idea how that compare to > GPL or LGPL, but might be worth a look-see. Whatever, it is going to take > time and effort (cost) to make FG compliant amd/or turn the multi-player > server into an RTI clone or "play-alike". And perhaps it would add a bit > of formalism to the FG development track. :-) There is also one, at http://developer.berlios.de/projects/openrti/ Which is subject to envolve. But appart from that, the API is standardized by an IEEE standard and used with commertial simulation systems as well. Simgear also already has some rti abstraction library that should help to implement hla federates. Flightgear git already has an alternative multiplayer implementation in place that uses hla. But that is only thought as a proof of concept. The next step is probably to provide a seperate hla federate that runs the ai traffic and feeds that into an rti federation. All I did here started using the above hla implementation. So this one already works for this kind of stuff. So, there is already something in place, and I think that its definitely worth keeping that in mind. Greetings Mathias -- 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] YASim issues
Still trying to take off ;) .Very nicely done model ...but a bit too much detail for my laptop ...I get 10 fps where I'm used to getting 30-40 . On Fri, Apr 15, 2011 at 8:54 AM, Adrian Musceac wrote: > >> Possibly , I think you've probably looked deeper into the code than i >> have there . Thought I'd bring up the idea in case it hadn't been >> tried . >> I,ve also tried to trigger that gear up crash but haven't been able >> too , (with my aerostar) , it does a belly landing and the crash >> property remains unset >> Cheers >> > > Indeed, I think it's impossible to trigger the crash with the aerostar, > because the distance between the gear positions and the lowest contact points > is smaller than 1 meter. Would you please try with the IAR80? > > Adrian > > -- > 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 > -- 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
Re: [Flightgear-devel] YASim issues
On Friday 15 April 2011 21:07:12 syd adams wrote: > Still trying to take off ;) .Very nicely done model ...but a bit too > much detail for my laptop ...I get 10 fps where I'm used to getting > 30-40 . > No need to take off :), just raise the gear with the engine running (otherways it doesn't raise :) )while on gound. -- 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] YASim issues
On Friday, April 15, 2011 20:43:45 syd adams wrote: > One small ,narrow fuselage piece inside and at the bottom of the main > fuselage doesnt make a difference here, you don't need a lot . And > they don't seem to trigger a crash like gear does. > The gear only triggers a crash when its absolute height above ground level is -1. This happens because gear position doesn't change when retracted (obviously it would be quite hard to calculate its position during the extension phase, because every airplane might have a different way to extend and retract). There is no force computed and applied to the model when the gear is retracted, however the collision check still happens and if you have a long enough gear strut it will go below -1 AGL when flying low or crash landing. It should be pretty easy to replicate this with the IAR80, I haven't tried with other aircraft. Adrian -- 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] YASim issues
Ok success. It does rest slightly off the ground at the nose ... i removed the fake gear and all the mstab objects (clever use of mstab , by the way :)) , and still the same results... I have to admit I've never noticed this behavior before. On Fri, Apr 15, 2011 at 1:17 PM, Adrian Musceac wrote: > On Friday, April 15, 2011 20:43:45 syd adams wrote: >> One small ,narrow fuselage piece inside and at the bottom of the main >> fuselage doesnt make a difference here, you don't need a lot . And >> they don't seem to trigger a crash like gear does. >> > > The gear only triggers a crash when its absolute height above ground level is > -1. This happens because gear position doesn't change when retracted > (obviously it would be quite hard to calculate its position during the > extension phase, because every airplane might have a different way to extend > and retract). > There is no force computed and applied to the model when the gear is > retracted, however the collision check still happens and if you have a long > enough gear strut it will go below -1 AGL when flying low or crash landing. > It should be pretty easy to replicate this with the IAR80, I haven't tried > with other aircraft. > > Adrian > > -- > 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 > -- 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 22:52, Csaba Halász wrote: > On Wed, Apr 13, 2011 at 9:16 PM, ThorstenB wrote: >> 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? > > Yes, pretty sure. I fly FG during the monthly TGA events, and it was > never even half as bad as this time. Except for the one massive leak > you fixed, but luckily I didn't try to run that version during an > event :) I looked into OSG's cache behaviour when running FlightGear. Worked as expected though: I see the objects being dropped once they are no longer referenced and have expired. However, I saw the same issue which my memory debugger had reported before: some scenery elements, mainly related to MP aircraft, don't (always) get deleted. Indeed, these elements stick in the OSG cache now. But they stick since their reference count proves that they are still referenced elsewhere - so the cache holds on to them. It wouldn't help to drop referenced objects from the cache - they wouldn't be deleted anyway. So, yes, there's a leak related to MP aircraft - but the cause seems to be independent of the OSG cache. I'll be doing some more tests though. I've also pushed an update to clear the entire OSG cache when reloading scenery (see menu "Debug" => "Reload Scenery"). If memory consumption explodes, try triggering a scenery reload to wipe the cache. I doubt this would reduce memory though - but maybe there's a surprise. Csaba, which OSG version are you running anyway? 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] release discussion
2011/4/15 ThorstenB : > > Ok, not sure what has changed there, but is it important enough to be > migrated to 2.2? I know it's tempting to make all the new features > available right now (I'd like to see my new TCAS in the release, we've > had 2 JSBSim updates, new HLA support, tank properties, joystick > reloading, of course many many really nice Aircraft updates...). But > they are not release-blocking. > > Last 2.2.0 fixes were applied on February 19th. I'll have a look at the > commits on next/master since then. Anyone else aware of missing and > release-blocking commits apart from the Models subdirectory? > > cheers, > Thorsten > Hi Thorsten, 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. Bertrand. -- 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] props protocol problem
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.
In props.cxx, replace:
if (command == "ls") {
with:
if((command == "ls")||(command == "lsx")){
and add:
if (command == "lsx"){
push( getTerminator() );
}
at the end of the branch.
--
__Pascal Bourguignon__ http://www.informatimago.com/
A bad day in () is better than a good day in {}.
--
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
