Re: [Flightgear-devel] Runtime selection of sound device
The Apple OpenAL implementation is open source, btw. http://developer.apple.com/audio/openal.html#anchor3 On Mon, Nov 30, 2009 at 9:51 AM, Erik Hofman e...@ehofman.com wrote: James Turner wrote: Nice work! And the preference / settings changes too - I know this is painful work, but it's long overdue and will really help make using FG more pleasant for lots of people. Thanks, It's not yet perfect but already usable as it is. Incidentally, I am currently cursing Apple's OpenAL implementation, it only supports the default input and output devices - despite 'supporting' the enumeration extension. I have a patch to iaxclient (as used by fgcom) to allow input and output device selection for the openAL backend, but it's completely pointless on Mac, without patches to OpenAL itself :( That's sad. Erik -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Ditto here on windows vista 64 using OpenAL SDK (for this build). The wind noise has changed texture, as if it was heavily saturated, while it use to be a nice wind sound. I guess maybe volume is too high on it. And that can be tweaked I guess through the xml file. It really doesn't sound the same as my Oct 2nd build, all things being equal (same data) We're not quite back where we were in sound quality, but at least sounds seems to be all working now. Haven't done a debug build yet, will advise if it still crashes. Sound is a bit sensitive to camera movement right now, from a quick hearing test :) Quick note : the volume slider is pretty much useless at the moment, maybe to a change in the volume attenuation scale ? It only has effect in the leftmost part of the slider (so low end of volume) , maybe the last 1/8th of the slide, and then brutally diminishes sound. Before that, no discernible difference in volume. That said, again thanks for the hard work Erik (and everyone else) Cheers, Nic On Thu, Oct 29, 2009 at 1:17 PM, Alan Teeder ajtee...@v-twin.org.uk wrote: It compiles and sounds are back! That was quick. Well done Alan -Original Message- From: Erik Hofman [mailto:e...@ehofman.com] Sent: 29 October 2009 17:07 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] New Sound system committed Ron Jensen wrote: Hi Erik, Sound seems to work O.K. today for me. Except when I tune atis I get: voice synth: word '(many lines of stuff...)' not found source and listener distance greater than 20km! source and listener distance greater than 20km! And no ATIS sound... I assume its supposed to give sound even if all the samples aren't found? As far as I know it should indeed. Here is the status update of the code: * positioning: needs fixing * orientation and sound direction: should be correct. * velocity vector (and hence Doppler): should be correct. But let me tell you; this evening I'll calibrate that the sound-not-playing bug is finally fixed. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Little mistake : The wind sound, which wasn't audible before, is now vastly over the sound of the rumble, which I had mistakenly thought was the wind (it makes for a better wind on wings sound, from this point of hearing approximately between my ears) The wind sample we use is indeed very saturated, and was drowned by the rumble sample before. Do you have an overview of how differently are the sounds .xml configs interpreted vs the previous sound implementation ? What has changed in that regard, if anything, and would you by any chance know why there could be such a huge difference ? Because same sound config, wildly different results. Thanks in advance for your insights. So never mind : sound quality might well be as good at it ever was (or even better), sorry for that, didn't mean to muddle things up. Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Anybody got sounds working properly on *windows* (ATIS and aircraft sounds working at the same time ?) If yes, what is your setup, not just openAL wise, but do you also build OSG, and if yes, with what options ? Share as much as possible of your setup, if current CVS works for you, please. I think we might have some initialization issues coupled to timing issues, as the same exe just had functioning ATIS on one run, and on the next, with the same command line (not using fgrun for this) except log level set to debug instead of info, ATIS wasn't working anymore. In both cases, no aircraft sounds at all. And the big problems started with rearrangement of the sound manager initialisation in the init routines, iirc. My october 2nd release build has fully working positional audio for aircraft sounds, working ATIS, etc. That might point to timing issues, no ? I would be very surprised it's an OpenAL implementation/runtime problem as I've tried every possible permutation of runtime, software device used, and ways to build FGFS, including using OpenAL soft instead of the SDK or Fredb's setup, and while changing runtimes (and rebooting) has no effect on the games I have installed that use OpenAL for positional sound, it hasn't made FGFS work properly. Erik, if you have hints on what part of the code you'd like to step through in the debugger here, I'd appreciate said pointers, rather than trying to root out a bug whose location I'm all but sure about :) Cheers and thanks for your cooperation all, Nic On Wed, Oct 28, 2009 at 10:33 AM, Erik Hofman e...@ehofman.com wrote: Csaba Halász wrote: Starting at EGLL with the default c172p, I notice: 1) the engine sound is louder in cockpit than in external view 2) tuning to ATIS 123.9 I get the source and listener distance greater than 50km! message (twice) 3) tuning away from ATIS frequency does not stop ATIS sound The fixes for these problems have been committed to CVS now. beware: outside view orientation is still wring since the view manager behaves differently for inside-aircraft views and for look-at-aircraft views. That said, the velocity (and hence Doppler) should be fixed now and in cockpit view should be working properly also (apart from a small offset bug that pops up every now and then causing the sound to 'wobble' around). Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Forgot to mention it's still crashing in Debug mode due to a corrupt heap (according to the debugger, this is the likely culprit) on the SGSoundSample::free_data() call, you guessed it, on the same spot as a couple weeks back : rumble.wav. No changes in behaviour in DEBUG mode even with all the recent changes. Which could also point to other misbehaved code, maybe even outside the sound code. I simply don't know. Cheers, Nic On Wed, Oct 28, 2009 at 4:29 PM, Nicolas Quijano nquij...@gmail.com wrote: Anybody got sounds working properly on *windows* (ATIS and aircraft sounds working at the same time ?) If yes, what is your setup, not just openAL wise, but do you also build OSG, and if yes, with what options ? Share as much as possible of your setup, if current CVS works for you, please. I think we might have some initialization issues coupled to timing issues, as the same exe just had functioning ATIS on one run, and on the next, with the same command line (not using fgrun for this) except log level set to debug instead of info, ATIS wasn't working anymore. In both cases, no aircraft sounds at all. And the big problems started with rearrangement of the sound manager initialisation in the init routines, iirc. My october 2nd release build has fully working positional audio for aircraft sounds, working ATIS, etc. That might point to timing issues, no ? I would be very surprised it's an OpenAL implementation/runtime problem as I've tried every possible permutation of runtime, software device used, and ways to build FGFS, including using OpenAL soft instead of the SDK or Fredb's setup, and while changing runtimes (and rebooting) has no effect on the games I have installed that use OpenAL for positional sound, it hasn't made FGFS work properly. Erik, if you have hints on what part of the code you'd like to step through in the debugger here, I'd appreciate said pointers, rather than trying to root out a bug whose location I'm all but sure about :) Cheers and thanks for your cooperation all, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS: source/src/Main bootstrap.cxx, 1.40, 1.41 fg_init.cxx, 1.239, 1.240 main.cxx, 1.301, 1.302 splash.cxx, 1.32, 1.33
I'm flabbergasted : disregarding the GPL to protect the GPL ? How novel.. Really, really misguided, and it showcases a prevalent undercurrent with some of our members, who think the GPL means something else than it really does : when something is done that doesn't sit right with their vision of the GPL, they sneakily delete content from cvs (been done before with aircraft functionality, leaving them broken in my local copy without warning) No one has a say in how GPLed software or data is used as long as it's in compliance with the license, no matter how distasteful it might be to one's sense of propriety. Trying to get around that, is a breach of the GPL, period. Funny when the same people who do this kind of stuff, also think the GPL is just fine for data, code, etc. as long as people abide by their vision of the GPL. There is no personal vision involved : it's a license, and quite clear to boot as license goes. You either comply or you don't. This is not complying. Please roll that back, if the original author won't. Thank you, Nic On Sat, Oct 24, 2009 at 7:13 AM, Erik Hofman e...@ehofman.com wrote: Bertrand Coconnier wrote: Hi all, I am bit taken aback by this commit. Is it really where the Flight Gear community wants to go ? As far as I understand the GPL, it is legal to rename an application as long as the renamed application is still under GPL. So what is this commit intended for ? Furthermore, do you honestly think that such a simple trick has any chance to work ? And most importantly, under what authority are we allowed to claim that a renamed copy of Flight Gear is an Invalid version ? To be honest, I don't like it very much either. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: [Flightgear-cvslogs] CVS: source/src/Main
Erh, he just has to take out said code, and his customers will not be the wiser, since they won't see the message. He does read the list after all. As Bertrand said, it's not going to achieve the desired result, not at all. And it's trying to work around the GPL, by doing something different if you don't respect someone's wishes on naming/re-branding. That's an usage restriction, or close enough, that we're starting to split hairs many times over. If you want to go along a similar route, why not have the help menu go to the flightgear.org website, rather than a local copy of the manual ? Then you can control the content on said webpage and tell people about the bad folks at FPS. But doing sneaky stuff that will affect people who might have legitimate reasons to rename FGFS without breaching the GPL just to counter one offender seems, well, simply misguided. Cheers, Nic On Sat, Oct 24, 2009 at 10:14 AM, Martin Spott martin.sp...@mgras.netwrote: Bertrand Coconnier wrote: I am bit taken aback by this commit. Is it really where the Flight Gear community wants to go ? These people at Flight Pro Sim are deliberately trying to decieve the FlightGear devlopment 'crew' (just think of their ridiculous attempt of calming the waves by offering this $250 reward, _after_ they got 'trapped') as well as their own customers. Therefore I think it's acceptable to shed some light onto the story by telling the truth to the respective buyers. IMHO this commit is pointless and I am concerned that it may be the first step of many towards restriction of use. As far as I can tell this step is pretty well in compilance with the GPLv2, the license that covers most of FlightGear. So where do you spot a restriction ? Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
typo in ATCDCL/AIPlane.cxx : at line 198, sizte_t len; should be size_t len; Cheers, Nic On Sat, Oct 24, 2009 at 2:43 PM, syd adams adams@gmail.com wrote: I did a new cvs checkout of flightgear and simgear, and I now have sound again ... Althought a separate problem popped up , trying to compile FG crashed until I recompiled simgear with jpeg factory support. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Build with Fredb's setup, using the OpenAL Soft provided device on windows vista 64, I get multiple working sound. Of course, no distance attenuation, as you mentioned. Had to def out the the code mentioned in previous mail, because there is another bug in there that prevents building : SGSoundSample* simple = new SGSoundSample(buf, len, 8000 ); (line 201 in ATCDCL/AIPlane.cxx) expects a void ** and buf is a void * Will try an OpenAL SDK build later on, but that should work too. Thanks for the continuous hard work Erik, Looking forward to having distance attenuation and doppler effects back in full force, Cheers, Nic On Sat, Oct 24, 2009 at 3:29 PM, Nicolas Quijano nquij...@gmail.com wrote: typo in ATCDCL/AIPlane.cxx : at line 198, sizte_t len; should be size_t len; Cheers, Nic On Sat, Oct 24, 2009 at 2:43 PM, syd adams adams@gmail.com wrote: I did a new cvs checkout of flightgear and simgear, and I now have sound again ... Althought a separate problem popped up , trying to compile FG crashed until I recompiled simgear with jpeg factory support. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
AIPlane doesn't build here, a problem with conversion from a unsigned char* to the std::auto pointer thingy here : new SGSoundSample((unsigned char*)buf.c_str(), buf.length(), 8000 ); at line 204 Didn't get Alan's errors in SG 'though, even though I use the same compiler as him. Weird. On Mon, Oct 19, 2009 at 11:02 AM, dave perry skida...@mindspring.comwrote: James Sleeman wrote: On 20/10/09 00:07, James Sleeman wrote: On 19/10/09 23:42, Erik Hofman wrote: Ok I think I've ironed out most of the bugs. I hope also the one that James reported but I don't hold my breath for it just yet. So far so good, compiles and runs, and produces sound. Will try a short flight and see if any problems crop up. Seems to be working ok, a bit, umm, stuttery, sort of, particularly background wind, seemed to switch left-right a bit, but those problems might just be me, maybe even just an illusion. With an update this morning from cvs, I still only hear ATC and that with frequency distortion. Did I miss a required library change? I have openal-0.0.9-0.15.20060204cvs.fc9.i386 and freealut-1.1.0-6.fc9.i386 with fc10. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Still no proper sound, and I think (can't make an informed judgement, no expert on threading) we have some serious timing issues on init and startup, and not just on windows (people have reported the same kind of stuff on Linux) Deadlock in MP, have to kill fgfs with today's build (with code commented out of AIPlane to build, but I don't use AI Traffic anyway. Would love not to have to load all the AI routes and stuff when it's disabled) No sound in single player, longer delay than usual before sim starts. Might do some debugging later on, no time right now. Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
In Debug : Still crashing on rumble.wav, still on SGSoundSample::free data : delete _data.release() is the culprit, albeit no problems in generating the al buffer for rumble.wav, etc. That's when the sample does the test if it's a file or not, and then deletes it in SGSoundManager::requestBuffer. Before the crash : Btw, the ATCMgr is initialized before the sound manager, and the ATCVoice is trying to do its thing with _working obviously set to false. Not sure that's the case in release, as ATIS is managed by this, right, and couldn't get it to shut up as I mentioned previously (changing frequencies didn't do anything, it would keep giving me the audio loop) It's also trying to resume the sound manager later on during init (in setFreeze (false), still before the latter is initialized. this sets _active to true, before the sound manager has been initialized (it exists, obviously, but init has not been called yet) Hope this helps, Nic On Mon, Oct 19, 2009 at 12:27 PM, Alan Teeder ajtee...@v-twin.org.ukwrote: Did another CVS update after reading this post and get same result as Nicolas Alan -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Erik, you should have committed the whole patch, as you broke building under that system, which uses a bare bones alut (which is why some of us have moved to the OpenAL SDK, plus I use it in other projects locally, which use the standard no AL folder setup...) So right now, it doesn't build on windows at all out of the box, with fredb's setup or the official OpenAL SDK. Fred's third party lib setup includes an outdated OpenAL sdk and re-distributable, and a version of alut that doesn't include alutGetErrorString, and Olaf's patch addressed that, if I recall correctly. That alut version basically can only do the loading of sound files, period. No error checking, etc. So do we want to keep supporting that setup at the exclusion of all other possible ones because it follows the specification ? Not sure that the spec says that headers have to be in AL( I couldn't find any mention of that in the 1.1 spec, and Apple doesn't follow it either, so I very much doubt the spec cover this. ), and it implies supporting an incomplete, pre version 1 alut. I don't see why a WIN32 (we define WIN32, doesn't have to be _WIN32) is such an anathema, seeing as there is one for Apple already. To make things more robust, we should be following the way the official SDK works on Windows, and the solution for Fredb's third party lib is to take out the headers from the AL folder and dump them in the include folder. Won't solve their problem with missing alut symbols, 'though As Geoff said, the real standard on windows, is no AL folder for the headers. If a mistake lasts 5 years, it's not a standard, it's a long lasting mistake :) I just want things to work, without having to constantly change my header setup. On Sun, Oct 18, 2009 at 9:07 AM, Erik Hofman e...@ehofman.com wrote: Vivian Meazza wrote: Patched soundmgr_openal.cxx/hxx and sample_group.hxx with +#elif defined(_WIN32) +# include al.h or +#elif defined(_WIN32) +# include al.h +# include alc.h +# include AL/alut.h Olaf pointed out to me that this wasn't necessary for more than 5 yearss and indeed AL/* is the recommended place for the header files by specification. So I'll revert this to section to the way it was before. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Erik, I know, I erased my local changes, seeing you had changed it for alGetError, but didn't notice the call to alutGetErrorString just below it when I did my merge :) I did this to build (under fredb's third party lib, going to do a build with the regular openAL sdk after) #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 msg.append(alutGetErrorString(error)); #endif Thanks for all the hard work, didn't quite finish my previous email before pressing send. Cheers, Nic On Sun, Oct 18, 2009 at 2:24 PM, Erik Hofman e...@ehofman.com wrote: Nicolas Quijano wrote: Hi Erik, you should have committed the whole patch, as you broke building under that system, which uses a bare bones alut (which is why some of us have moved to the OpenAL SDK, plus I use it in other projects locally, which use the standard no AL folder setup...) So right now, it doesn't build on windows at all out of the box, with fredb's setup or the official OpenAL SDK. What's the error you are getting? I changed from using alutGetError to alGetError Which the old implementation did so it should work. Erik -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hey Erik, since you're not sleeping yet, I think you wanted to commit alGetError, not alGetErrorString. the error on exit would seem to be related to buffer release (Invalid Operation) Also, I see you replaced delete[], by delete in the sound sample destructor. Shouldn't we just be setting to NULL, and not delete, leaving it to the original creator of the data, since the original allocation is done somewhere else ? e.g _data never allocates, just points to data allocated somewhere else. The allocator should be the one deallocating, to make sure we don't have dangling pointers. ATIS won't shut up now, so sound is kinda working, was able to hear engine start and ATIS at the same time, but not two aircraft sounds at the same time. In debug a couple days back, I had sound working normally, so that points to what Geoff was saying about having some garbage in release, whether in DEBUG it's all a controlled environment. Cheers, get some sleep, Nic On Sun, Oct 18, 2009 at 2:53 PM, Erik Hofman e...@ehofman.com wrote: Nicolas Quijano wrote: #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 msg.append(alutGetErrorString(error)); #endif Shoot, that should also have been alGetError instead. It's fixed, thanks. Erik (now i need some sleep) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Damn, typoed. Meant, you want alGetString(error), not alGetErrorString(error). On Sun, Oct 18, 2009 at 3:55 PM, Nicolas Quijano nquij...@gmail.com wrote: Hey Erik, since you're not sleeping yet, I think you wanted to commit alGetError, not alGetErrorString. the error on exit would seem to be related to buffer release (Invalid Operation) Also, I see you replaced delete[], by delete in the sound sample destructor. Shouldn't we just be setting to NULL, and not delete, leaving it to the original creator of the data, since the original allocation is done somewhere else ? e.g _data never allocates, just points to data allocated somewhere else. The allocator should be the one deallocating, to make sure we don't have dangling pointers. ATIS won't shut up now, so sound is kinda working, was able to hear engine start and ATIS at the same time, but not two aircraft sounds at the same time. In debug a couple days back, I had sound working normally, so that points to what Geoff was saying about having some garbage in release, whether in DEBUG it's all a controlled environment. Cheers, get some sleep, Nic On Sun, Oct 18, 2009 at 2:53 PM, Erik Hofman e...@ehofman.com wrote: Nicolas Quijano wrote: #if defined(ALUT_API_MAJOR_VERSION) ALUT_API_MAJOR_VERSION = 1 msg.append(alutGetErrorString(error)); #endif Shoot, that should also have been alGetError instead. It's fixed, thanks. Erik (now i need some sleep) -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
(Most of this written last night before bed)
Hi all, commenting out code in the destructor won't help, as the problem is
being set-up much earlier, while FGFS is still in the initialization stages
(dt == 0) : in debug, there is a fatal assert on SGSoundSample::freedata,
being called by SGSoundMgr::requestBuffer, line 429), itself being called
from SGSampleGroup::update (line 104), rumble.wav, ultimately going back up
the call chain to fgOSMainLoop.
I suspect the exit bug in Release is when it starts freeing stuff that's not
there to be freed. I say suspect 'cause I can't get there in Debug, as it
fails before finishing complete initialization.
the alutinit++ stuff is wrong : alutinit is at 2 at the time the destructor
checks it, thus never calling alutExit (not that it matters, alutInit does
nothing but set a flag variable in the variant we use)
there is one incrementation too much in there, and since it can only be
initialized once, why track a number ?
I believe SoundManager::load might be where it's all happening, or starting
to happen.
You do use a weird param setup, assigning unitialized values from pointers
to stack variables then passing the address of the stack variables as
params, only to write them back in the pointers at the end :)
It returns garbage on trying to load the ATC voice, maybe because there is
no valid AL context as the (internal) message error says, before the catch
code gets rid of it. Doesn't assert there 'though, churns on until it gets
to rumble.wav.
Why is SoundManager::load a static member function ? it's never called that
way, and always as a member function, so why ? (not major, but bad form)
Also, if (_data != NULL) { delete[] _data; _data = NULL; } in free_data() in
sample_openal.hxx is the offending party (in debug). I believe delete[] is
the problem, _data not explicitly being an array (and not using new in any
shape or form)
Will look more into it, but if more people, not just on windows, could take
some time to run the new sound system in debug, we might root out a few bugs
in it while we're at it.
Could you guys build in debug and run it through and see what you come up
with ?
I'm sure Erik could use the help.
Hope this helps, will investigate further,
Cheers,
Nic
On Tue, Oct 13, 2009 at 4:05 AM, Erik Hofman e...@ehofman.com wrote:
Vivian Meazza wrote:
Nope, that doesn't fix it - still get crash on exit. But I no longer get
sound stopping when I change window size at runtime.
You might want to comment out some code in SGSoundMgr::~SGSoundMGr to
see what exactly might cause it.
Erik
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Be Kind.
Remember, everyone is fighting a hard battle.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] infinite loop in FGEngine.cpp
Hi Scott,
More than one fuel tank with fuel in it at startup ?
If that's the case, you want to set priorities, with lower being the first
tanks to empty.
it's done with priority tags in the tank definition in the jsb config
file.
Or set all tanks but one to 0 content and then fill them up after start up.
That should fix the loop for the time being,
Cheers,
Nic
On Wed, Oct 14, 2009 at 8:56 AM, Scott Hamilton
scott.hamil...@popplanet.biz wrote:
I've noticed that a lot of JSBsim files got updated just the other day,
and today was the first time I've had
a chance to try it out.
I'm working on the A380 which does use JSBsim, and during the engine
start everything freezes just after
the starter is turned false, the ignition is true and the cutoff is
turned false. This is around N2 = 27%
Fortunately I had compiled everything with debug, so a quick look in gdb
reveals at stacktrace (on interrupt signal)
#0 0x0068aeb8 in JSBSim::FGTank::Drain (this=0xc4829a0,
used=1.0180511166896056e-315) at FGTank.cpp:196
#1 0x0066640f in JSBSim::FGEngine::ConsumeFuel (this=0xc47d4c0) at
FGEngine.cpp:212
#2 0x006945aa in JSBSim::FGTurbine::Start (this=0xc47d4c0) at
FGTurbine.cpp:290
#3 0x00699d61 in JSBSim::FGTurbine::Calculate (this=0xc47d4c0) at
FGTurbine.cpp:155
#4 0x006069c4 in JSBSim::FGPropulsion::Run (this=0xbdf8550) at
FGPropulsion.cpp:147
#5 0x005670bc in JSBSim::FGFDMExec::Run (this=0xc573220) at
FGFDMExec.cpp:362
#6 0x0055949d in FGJSBsim::update (this=0xc413fb0,
dt=0.041664) at JSBSim.cxx:487
#7 0x00435ec8 in fgUpdateTimeDepCalcs () at main.cxx:159
#8 0x004371df in fgMainLoop () at main.cxx:449
#9 0x0049e1ac in fgOSMainLoop () at fg_os_osgviewer.cxx:172
#10 0x00433e07 in fgMainInit (argc=9, argv=0x7fffda58) at
main.cxx:900
#11 0x004332e1 in main (argc=9, argv=0x7fffda58) at
bootstrap.cxx:228
196 double FGTank::Drain(double used)
197 {
198 double remaining = Contents - used;
199
200 if (remaining = 0) { // Reduce contents by amount used.
201
202 Contents -= used;
203 PctFull = 100.0*Contents/Capacity;
204
the value for 'used' is 0 (which doesn't seem right)
the values for 'Contents' and 'remaining' are 0 (they are correct values)
'Drain' is called for each tank
It seems this loop in FGEngine.cpp is executed repeatedly with no way out;
183 while (FuelToBurn 0.0) {
184
185 // Count how many fuel tanks with the current priority level
have fuel.
186 // If none, then try next lower priority. Build the feed
list.
187 while ((TanksWithFuel == 0.0) (CurrentPriority =
Propulsion-GetNumTanks())) {
188 for (i=0; iPropulsion-GetNumTanks(); i++)
{
189 Tank =
Propulsion-GetTank(i);
190 if (Tank-GetType() == FGTank::ttFUEL)
{
191 if ((Tank-GetContents() 0.0) ((unsigned
int)Tank-GetPriority() == CurrentPriority)) {
192 ++TanksWithFuel;
193 FeedList.push_back(i);
194}
195 } else {
196cerr No oxidizer tanks should be used for this
engine type. endl;
197 }
198 }
199 if (TanksWithFuel == 0.0) CurrentPriority++;
200 }
201
202 // No fuel found at any priority!
203 if (TanksWithFuel == 0.0) {
204 Starved = true;
205 return;
206 }
207
208 // Remove equal amount of fuel from each feed tank.
209 FuelNeeded = FuelToBurn/TanksWithFuel;
210 for (i=0; iFeedList.size(); i++) {
211 Tank = Propulsion-GetTank(FeedList[i]);
212 Tank-Drain(FuelNeeded);
213 FuelToBurn -= FuelNeeded;
214 }
215
216 // check if we were not able to burn all the fuel we needed to
at this priority level
217 if (FuelToBurn 0.001) {
The value of FuelToBurn is = 1.4821969375237396e-323
The value of CurrentPriority = 1 and never changes.
once I step past line 217, it goes back to line 183 and never seems to
stop.
I'm not a C++ coder, and not much of a gdb debugger, but I hope that helps
enough if someone else is seeing similar problems.
Scott.
--
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
--
Be Kind.
Remember, everyone is fighting a
Re: [Flightgear-devel] [Jsbsim-devel] infinite loop in FGEngine.cpp
I believe the problem is that the new fuel tank priority code doesn't deal correctly (yet) with the case of multiple non-empty tanks at startup, throwing it into an infinite loop. As I said, not quite clearly, on the fgfs list, you have to set priorities, with lower numbers going first, and higher number last (simple as adding priorityn/priority tags to the tank definitions, with n the priority, as an integer). This allows, for example, to model emptying wing tanks before the central one, without any fancy configuration or coding : set the priority of the wing tanks to 1, and the internal fuel tank to 2. Aircraft with multiple tanks, but only one with fuel in it at startup will not exhibit the problem as the code will use the one with fuel in it. Hope that's clearer, Cheers, Nic On Wed, Oct 14, 2009 at 9:34 AM, gerard robin ghma...@gmail.com wrote: On mercredi 14 octobre 2009, Anders Gidenstam wrote: On Wed, 14 Oct 2009, Scott Hamilton wrote: I've noticed that a lot of JSBsim files got updated just the other day, and today was the first time I've had a chance to try it out. I'm working on the A380 which does use JSBsim, and during the engine start everything freezes just after the starter is turned false, the ignition is true and the cutoff is turned false. This is around N2 = 27% Fortunately I had compiled everything with debug, so a quick look in gdb reveals at stacktrace (on interrupt signal) Good catch! I've also (with high probability) run into this using ZLT-NT, but prefered to blame it on the sound subsystem :) and didn't have time to investigate it further. Strangely enough it doesn't happen with all aircraft - I have flown other JSBSim aircraft after the update. ZLT-NT has an electric motor among the engines, does the A380 also have something like that? I crosspost this to JSBSim-devel. Cheers, Anders With some of my models, i had the same freeze during start , i solved it with = give the priority value to the Tanks according to the last Dave update. I don't know if there is any relationship with your problem, anyhow mine was solved :) Cheers -- Gérard J'ai décidé d'être heureux parce que c'est bon pour la santé. Voltaire -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Jsbsim-devel mailing list jsbsim-de...@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/jsbsim-devel ___ The JSBSim Flight Dynamics Model project http://www.JSBSim.org ___ -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sound system committed
Hi Erik (sorry Erik ;)) Bit of background : I used to use Vivian setup when I first starting building my own exe a while back (OpenAL SDK 1.1 + freealut 1.0.1) and sound worked. I switched to Fredb's third party libs a few months back, sound worked. Now, I can build a working exe with my old/Vivian's setup, but get no working sound (and no errors) but I do have the crash on exit. I believe it's because we're trying to release the alcDevice and alcContext a second time by calling AlutExit., after doing it manually in the stop method of the soundmanager. Anyone has sound on Vista64, with VC9, with latest CVS and OpenAL SDK 1.1 + freealut 1.0.1 ? Before anyone mentions hardware problems, I only have a generic software device since Vista never had support for hardware 3d positional audio in hardware through DirectSound, it was dropped before release. There never was generic hardware positional audio support in Vista. So only the Generic Software device available to OpenAL, thus cannot be that my default device is a malfunctioning hw wrapper (we pass null to the device selection code, so we get the default one, whatever it is) And OpenAL works fine here, many other apps using the exact same dll, so I'm at a bit of a loss at the moment to root that one out. Will look further into it as time permits, but would love to hear if anyone has to this setup working under Vista64, especially as it use to work (yes, I've gotten rid of AL part of the 3rd party stuff to avoid it being referenced, to make sure the SDK is used. I've triple checked everything) Cheers, and thanks again Erik for working on the sound system. Nic On Sun, Oct 11, 2009 at 10:04 AM, Geoff McLane ubu...@geoffair.info wrote: On Sun, 2009-10-11 at 15:49 +0200, Erik Hofman wrote: Geoff McLane wrote: I hope this makes it into CVS sometime soon... Was his soon enough? ;-) Erik So slick and quick... thanks... Geoff. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] FG crashes when changing visibility
Hi Alex, a 100 cliks is way too low, visual horizon at 3 feet is much higher than 100 km, and users with the horsepower might want to set it to what it is in real life : the visual horizon at 3 feet to sea level is over 350 km, close to 360. http://radarproblems.com/calculators/horizon.htm If we don't have it exposed in preferences.xml, having a user accessible and settable limit for visibility would do the trick rather than an arbitrary value that will not cater to all cases. Cheers, Nic On Mon, Oct 12, 2009 at 1:18 PM, Alex Buzin buzin6...@hotmail.com wrote: Hi, I was noticed that FG hangs and than crashes if pressing z key. If visibility value is not controlled by user, it can be occasionally **increased to a huge value (1000 km). In this case TileLoader is trying to load hundreds of tiles. At the beginning I was expected a number of tiles to be limited by the size of TileCache (100), but I was mistaken. Size of TileCache is growing in routine FGTileMgr::schedule_needed( ... ) to make space for all tiles. On my PC when /environment/visibility-m 500-1000km memory usage grows from 300M up to 3G an this leads to crash. Can somebody limit the value in property /environment/visibility-m or the value of variable vis in FGTileMgr::schedule_needed( ... ). The maximum value of 100km will be acceptable IMHO. With respect, Alex -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [patch] Selectable ignore for MP chat
Hi Anders, thank you very much !! ( I knew I was forgetting someone for T-shirt award suggestions) This is a feature I've grown to love and live by, as I like to fly near KSFO :) Many thanks, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
on Windows, it's the environment variable %APPDATA% which maps to what Vivian said on 2k and XP. On Vista (and 7 I think), it maps to user/appdata/roaming/flightgear.org On Thu, Oct 8, 2009 at 3:30 AM, Vivian Meazza vivian.mea...@lineone.netwrote: -Original Message- From: Jacob Burbach [mailto:jmburb...@gmail.com] Sent: 08 October 2009 04:08 To: FlightGear developers discussions Subject: [Flightgear-devel] Fwd: fg-home on windows and mac In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. In Windows? I'm not sure exactly what you are asking, or indeed why! FG puts its user stuff here: C:\Documents and Settings\username\Application Data\flightgear.org But you can put the FG exec and data anywhere you like. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fwd: fg-home on windows and mac
Of course, I made a mistake it's users/user_name/appdata/roaming/ flightgear.org %APPDATA% is what you want to use in scripts, etc. Cheers, Nic On Thu, Oct 8, 2009 at 10:54 AM, Nicolas Quijano nquij...@gmail.com wrote: on Windows, it's the environment variable %APPDATA% which maps to what Vivian said on 2k and XP. On Vista (and 7 I think), it maps to user/appdata/roaming/flightgear.org On Thu, Oct 8, 2009 at 3:30 AM, Vivian Meazza vivian.mea...@lineone.netwrote: -Original Message- From: Jacob Burbach [mailto:jmburb...@gmail.com] Sent: 08 October 2009 04:08 To: FlightGear developers discussions Subject: [Flightgear-devel] Fwd: fg-home on windows and mac In Linux the users flightgear directory is at /home/username/.fgfs. As I don't have a windows pc and haven't yet tried flightgear on my mac, I wonder if someone can enlighten me to the path for the users directory on those systems. In Windows? I'm not sure exactly what you are asking, or indeed why! FG puts its user stuff here: C:\Documents and Settings\username\Application Data\flightgear.org But you can put the FG exec and data anywhere you like. Vivian -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] shader menu proposal
Did you update the Effects folder ? It's necessary for the changes to work Cheers, Nic On Thu, Oct 8, 2009 at 8:12 PM, Victhor Foster victhor.fos...@gmail.comwrote: The new shader dialog looks good, but it doesn't want to enable the water shader. And I think it's not turning on the crop shaders as well. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hey all, I also added time.h on my side, in an #ifdef, since it's somehow already included nix side :) That said, why not simply assign 0 to the two time_t rather than a function call ? Then, it's only a matter of dealing with difftime. Don't we already have time (and timing ?) abstracted facilities though SG ? Shouldn't we first use that, or add the necessary abstracted functionality there ? Also, if we have two consistent time_t, why not simply subtract one from the other, ABS it, and voila you have the time difference ? Or am I missing something regarding usage of difftime ? Cheers, Nic On Wed, Oct 7, 2009 at 5:39 AM, James Turner zakal...@mac.com wrote: On 7 Oct 2009, at 10:32, Alan Teeder wrote: James The “this” fault is fixed. Thanks. To cure the time and difftime under Windows all that is needed is to include time.h That's what I'd hoped, thanks for confirming. I would still prefer to use something more robust than the C-library functions, so I'm investigating that, but obviously it's more important to get Windows building again. Regards, James -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerry(R) Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9 - 12, 2009. Register now! http://p.sf.net/sfu/devconference___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] GPS / route-manager landing
Hi all, this doesn't build on windows, it can't find the time symbol referenced at line 229 and 233 in route_mgr.cxx. Missing header ? Also, there is a reference to std::strncasecmp in positioned.cxx around line 820, which is also not available in windows (at least, not here). Since it's dealing with c strings, I've added locally an #ifdef WIN32 check which uses_stricmp instead in this case. Don't know how you want to deal with this, Cheers, Nic On Mon, Oct 5, 2009 at 3:59 AM, James Turner zakal...@mac.com wrote: On 5 Oct 2009, at 08:33, Dave wrote: That all sounds like good stuff. I'll try and migrate the KLN89 towards using it and depreciating the dclgps stuff - that should give it some testing. Sounds good to me. I've been going through the KLN89 manual, and there's definitely some more subtle options that will require extra features / flags (off the top of my head, resuming LEG mode from OBS mode, and the ability to DTO without recentering the d-bar). Many things should be achievable with a bit of Nasal glue, obviously I've tried to make simple building block functionality as much as I can. If you think an API or design is poor, or missing a feature, let me know and I'm happy to add it - I'd far rather get the core code sensible, than have each GPS device work around the same bug! In terms of API examples, I will be committing a new GPS dialog, which shows off most of the new features, and will also allow the GPS to be used in aircraft without real hardware, if we want that. I'm also going to create a wiki page for the GPS, to document what it can (and can't do). Regards, James -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Problematic forum discussion on an MP event
Hi lee, funny enough I mostly agree. But I'm sorry, it's really easy to ignore you because like some of the fanbois of the event, you're resorting to demeaning language to speak of those who don't agree with you, showing exactly the intolerance you're decrying. At least, you're not resorting to racial epithets, which you would know happened if you had read the thread, as well as it was the original intent of the event's organiser to re-enact the atom bombings (he thinks there are no bombings possible in FGFS, showing how hard he's tried to research the topic, thus why it was changed to a dogfighting event...) Get your facts straight, if you're going to comment, as you're basing your opinion on non straight facts :) Cheers, Nic On Fri, Sep 18, 2009 at 11:28 AM, leee l...@spatial.plus.com wrote: The most depressing thing about this thread is that it highlights the fact that many people seem to think that the best way to deal with unpleasant events in history is to mythologise and make them sacred and untouchable, and then to try to force other people to comply with their personal views. First of all, Tat has presented this event as a recreation of the A-bomb raids, which is factually incorrect. Tat even says in his post on the forum I haven't read all posts in this thread... but that ignorance hasn't stopped him from going off on an irrelevant tangent over something that isn't even happening. Harsh words? Yes indeed, but I have no patience or sympathy for anyone who wants to force their will on other people, especially when they've got their facts wrong, or simply choose to misrepresent them. It's bad enough that politicians get away with it. In any case though, even if the raid was to be an enactment of one of the A-bomb raids, is forbidding people to do it the best way to deal with the issue? Should enactments of unpalatable events in history made into thought-crimes? There's certainly no real crime being committed here, is there? The fact is, events like the A-bombing of Hiroshima and Nagasaki actually occurred, along with numerous other raids where the majority of casualties were civilian, such as the firebombing of Tokyo (which is believed to have actually killed more people than either of the A-bomb raids), Dresden and Hamburg, together with the raids on Coventry Sheffield, not forgetting to mention the Blitz on London or the attacks on the Ruhr Dams. So no, mythologising these unpalatable events is not the best way to come to terms with them. To understand how such terrible events came to occur requires that the events be inspected down to their finest details and it's only when you completely understand what happened that you stand a chance of ensuring that it doesn't happen again. Saying that people should treat these events as something sacred and that re-enacting them or studying them is somehow offensive just ensures ignorance, which is no way to tackle the future. This issue really has nothing to do with FlightGear. FlightGear is all about flight, and to a large degree about the development of flight, both in the past and for the future, and the fact is that much of the development in flight has its origins in the military. Just as we can't truly understand the past that has brought us to the present without correctly understanding _all_ of the past, FlightGear cannot properly deal with the subject of flight if it tries to ignore the military factor. If there's really a problem, it's actually more to do with people who can't differentiate between understanding something and advocating it, and this can already be shown to have fostered ignorance. For example, as pointed out in the forum thread, the Swastika has been made illegal in several countries and this has lead to the widely held belief that the Swastika symbol relates purely to the Nazi regime. It does, in fact, date from the Neolithic period and was originally thought of as a symbol of good luck. Making the Swastika illegal has certainly not achieved the aim of stopping its use by the right-wing movements that were targeted by the law but instead has just resulted in the widespread ignorance of its real place in history, along with making it impossible to make historically accurate representations of anything that carried the symbol (unless it is for scholarly use). What has been advanced by achieving this? Yes, I am very annoyed at all this. It is precisely this type of neurotic denial of reality that has lead to many of the world's problems today. Pandering to this neurosis is not going to make things any better and it will only be by _really_ understanding things and coming to terms with them that we will stand any chance of preventing them from occurring again. LeeE -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event
Re: [Flightgear-devel] gitorious repositories for FlightGear and SimGear
binary data != binary code. Binary data is ALL the images files included in aircraft, possibly some models format supported by OSG (like .ive), all sound files, that sort of thing. CVS is notoriously bad at handling these files, and very inefficient at doing so. I believe that's what Erik meant. Cheers, Nic On Fri, Sep 18, 2009 at 1:07 PM, Alex Perry alex.pe...@pamurray.com wrote: On Fri, Sep 18, 2009 at 9:51 AM, Erik Hofman e...@ehofman.com wrote: One thing I have been wondering since this discussion started; Google seems to have found a nice way to add small diffs for binary data[1]. Maybe they have incorporated that into their repository? If they have, it won't help us. We're not distributing blobs of x86 machine code. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] pilot list...
Still a problem, with or without the MP ignore chat. (tested under both conditions) We intermittently now get chat messages from people thousands of kilometres away and duplicated messages with the callsign changed : for example, some_nic says : nice barrel roll, then some_other_nic a few seconds later will magically repeat what was just said, absolutely identical, punctuation and typos included :) It kinda makes text based ATC a nightmare, as it looks random to the user busy with flying. Log on messages are also a bit on the fritz : you can see this happens with individuals log-on messages being spoken by other nics : afaik, only someguy uses Phhtt but I saw among others, syd sign on with that message ;) Or just a few minutes ago, while I was getting ready to launch from Nimitz, a guy in Europe in a F-18 was asking for partners to fly to the Balkans, and I thought he was nuts to want to fly from KSFO to Montenegro, and couldn't see him on my zoomed mpmap. Of course not : zoomed out and he was in Europe, near his intended destination. Common occurrence in the last couple weeks. Probably the last in line bug affecting the pilot list and chat in a weird way. Cheers, Nic On Sun, Aug 30, 2009 at 5:19 PM, Rob Shearman, Jr. rmsj...@yahoo.comwrote: I've mentioned the problem here before, but as far as I know, no one has pinned it down, because all of the Win32 builds from June forward exhibit this behavior. Thanks for looking into it! -R. Robert M. Shearman, Jr. Transit Operations Supervisor, University of Maryland Department of Transportation also known as rm...@umd.edu -- *From:* syd adams adams@gmail.com *To:* flightgear-dev flightgear-devel@lists.sourceforge.net *Sent:* Sunday, August 30, 2009 1:24:13 AM *Subject:* [Flightgear-devel] pilot list... While attempting to hunt down a chat message problem , (no messages displayed from certain players), I found that the pilot list is always 1 player short , and the model view skips that player. They all appear in ai/models , but num-players is always show 1 less player. I've been sifting through the multiplay.nas , but thought I'd mention it here in case someone has already looked at the problem . cheers -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Come build with us! The BlackBerryreg; Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Solid MP Models
Rest of the world ? That's not good if you mean it literally : no more carrier landings, no more field landings, no more landing on building tops... Surely, you don't mean the rest of the world, do you ? Instead of enabling/disabling it in code, why the resistance at giving us a property to turn it on or off ? That would be the best of both world and doesn't requite the end user to tinker with code, which shouldn't be necessary to lever the power of FGFS. I was going to write today as to where this was in code, so I could at least configure it for myself. Thanks in advance for pointing me in the right direction, Cheers, Nic 2009/9/10 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Sunday 06 September 2009 21:42:36 Ron Jensen wrote: Sometime recently MP Models silently became solid. IMHO, this is a horrid state. Aircraft now crash when new aircraft appear at the same spawn site. To say I am upset about this feature is an understatement. I feel I am no longer able to use the public multi-player servers. I think that in general you should not be able to just fly through other aircraft. You cannot do so in real life. But for the multiplayer case I see that we either need a much more complex logic to startup at positions where no other participant is. Which is something I do not want today evening. Thinking about race conditions ... Or we just disable collisions for the MP aircraft. The AI ones should stay I think. I believe that Durk makes sure that the AI Aircraft will wait if the simulated aircraft is somewhere around. I have disabled the MP Aircrafts collisions with the rest of the world. Greetings Mathias -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Solid MP Models
Never mind, found the actual codeline, where the mask is set. Cheers, Nic On Thu, Sep 10, 2009 at 2:13 PM, Nicolas Quijano nquij...@gmail.com wrote: Rest of the world ? That's not good if you mean it literally : no more carrier landings, no more field landings, no more landing on building tops... Surely, you don't mean the rest of the world, do you ? Instead of enabling/disabling it in code, why the resistance at giving us a property to turn it on or off ? That would be the best of both world and doesn't requite the end user to tinker with code, which shouldn't be necessary to lever the power of FGFS. I was going to write today as to where this was in code, so I could at least configure it for myself. Thanks in advance for pointing me in the right direction, Cheers, Nic 2009/9/10 Mathias Fröhlich mathias.froehl...@gmx.net Hi, On Sunday 06 September 2009 21:42:36 Ron Jensen wrote: Sometime recently MP Models silently became solid. IMHO, this is a horrid state. Aircraft now crash when new aircraft appear at the same spawn site. To say I am upset about this feature is an understatement. I feel I am no longer able to use the public multi-player servers. I think that in general you should not be able to just fly through other aircraft. You cannot do so in real life. But for the multiplayer case I see that we either need a much more complex logic to startup at positions where no other participant is. Which is something I do not want today evening. Thinking about race conditions ... Or we just disable collisions for the MP aircraft. The AI ones should stay I think. I believe that Durk makes sure that the AI Aircraft will wait if the simulated aircraft is somewhere around. I have disabled the MP Aircrafts collisions with the rest of the world. Greetings Mathias -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] strtof doesn't exist on windows
So in generic.cxx, at line 381, I suggest using *strtod* instead, since the value is cast to float anyway on the next line. I gather this change (separate case for float and double) is the fix for choppy replays ? Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Little Ground Vehicle patch (for Vivian)
Hi Vivian, testing your new groundvehicle class for AI scenarios in the context of a train of tanks and another of jeeps, I stumbled into their wandering in the air. The solution is two-fold : one, specify a starting altitude through the altitude tag in the groundvehicle's entry in the ai scenario, even though we're using a flightplan (maybe I could have just re-ordered things around to we don't do GetPitch et al. before popping the first waypoint, but this was simple ;)) This ensures we don't have zero as elevation in the initial calculations after applying my patch. What my patch does is to stop using an arbitrary 1m lookup for the geode checks, but rather use the current elevation in meter, to avoid finding anything else, including buildings, or other models, which was gradually building up to an error amounting to the whole train floating above ground. Been testing it in the very hilly terrain in between La Honda and the Stanford Accelerator center, at the upper edge of Palo Alto. They conform to the terrain way better after the patch, and setting an initial altitude. I'll leave it up to you to see if the patch has any applicability in your further work with the AIGroundVehicle class, but I wanted to point out the hovering higher and higher as time goes by behaviour and provide a solution :) Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. AIGroundVehicle.cxx.patch Description: Binary data -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Little Ground Vehicle patch (for Vivian)
Hmm, needs further work... Now, they've taken a liking to going under the terrain, damn Will get back with further findings once I've dug deeper (pun intended) Cheers, Nic On Wed, Sep 9, 2009 at 8:05 PM, Nicolas Quijano nquij...@gmail.com wrote: Hi Vivian, testing your new groundvehicle class for AI scenarios in the context of a train of tanks and another of jeeps, I stumbled into their wandering in the air. -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shaders (Mac, nVidia 7300GT, latest CVS)
Strange colors on windows with ATI GPU, but here dominating color is red in the crop shader. I slightly modified the effects file and rendering gui to be able to enable them one at a time. both landmass and crop suffer from that, and it's triggered by camera movement. Unrelated comments : Might want to look in at disabling fixed function lighting when doing per pixel lighting, and tweak blending and alpha settings, first to avoid wasting gpu cycles on unneeded settings, like lighting when doing per pixel. but also to prevent side effects from fixed function state. Also, I was once told that stuff like a = b = c should be avoided : there is absolutely no guarantee it will be processed correctly, or in the order you think it would. GLSL is definitely not C :) Seems to work, but it's a dangerous slope if you want portability to rely on C side effects in GLSL. Common and oft repeated wisdom is if you develop on nvidia, you debug on ATI (or 3Dlabs) and if it runs there, it should run everywhere : nvidia seems to be the laxest of the GLSL spec interpretations (they all divert from the spec where they feel like it, except maybe 3dlabs who, well, created the specs) Comments inside code lines are forbidden by the specs (stuff like some_code /*comment*/; is not compliant, but some_code; /*comment*/ is) : either by itself on a line, or after all code on a line, after the; Water shader does work beautifully, albeit the geometry seams are very visible. I seem to recall that wasn't the case with the first version committed, I'll have to re-check. Thanks for all the hard work, Cheers, Nic On Mon, Aug 31, 2009 at 4:42 AM, till busch b...@bux.at wrote: hi james, this is not at all how it should look like. i believe that either something is wrong with lighting values in gl_FrontLightModelProduct / gl_LightSource[0] or smoothstep() does not work correctly on your system. i'm working on improving the shaders. i'll try to make a shader without smoothstep for you to check. the problem could also be mac-specific? did someone else notice strange colors with the shaders on os x? cheers, - till mes https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Textures not loaded when running my compiled flightgear
That's because you were missing the Effects and Shaders folders : doesn't know about terrain texturing anymore without them :) Cheers, Nic On Mon, Aug 31, 2009 at 8:30 AM, Bruno Sanches bcsanc...@gmail.com wrote: Did you build FlightGear/CVS or 1.9.1? If you built the development version you also need to check out the matching version of the data directory, the data for 1.9.1 will not work with a current FlightGear/CVS binary. Thats the CVS version, I am still downloading the data from the CVS (a lot of data to download) and was trying to run my compiled version using version 1.9.1 data. I will try it again when the data download finishes. Thank you! Bruno Sanches -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed
Look in the setfile for an aircraft (the ***-set.xml file), there will be an aero tag that indicates which FDM engine it's using. Cheers, Nic On Thu, Aug 27, 2009 at 11:18 AM, Randall Green randall.gr...@wright.eduwrote: Anders, Thanks for the email. Yes, it crashes right after it says JSBSim startup beginning How do I know if an aircraft uses YASim?? I'm using CVS FlightGear which has folders: src\FDM\JSBSim\. That means JSBSim is CVS, right? Thanks, Randy Green - Original Message - From: Anders Gidenstam anders-...@gidenstam.org Date: Wednesday, August 26, 2009 3:50 pm Subject: Re: [Flightgear-devel] Running FGFS 1st time - Initializing Subsystems then Debug Assertion Failed To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net On Wed, 26 Aug 2009, Randall Green wrote: I get the splash screen of the Cesna, but after it says Initializing Subsystems I get Debug Assertion Failed! File: f:\dd\vctools\crt_bld\self_x86\crt\src\isctype.c Line 56 Expression (unsigned)(c+1),=256 When I request to debug it takes me to string_utilities.h line 86. Try an aircraft that uses YASim for comparison. There is a string_utilities.h in JSBSim and the version in FlightGear has a few bugs that have been fixed in JSBSim/CVS. One of them is at line 86 so this could very well be the problem. You could also try copying the file from JSBSim/CVS and rebuild. http://jsbsim.cvs.sourceforge.net/viewvc/jsbsim/JSBSim/src/input_output/string_utilities.h?view=log Cheers, Anders -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Compiling CVS FlightGear - is Subversion really necessary?
It actually (pre) fetches scenery on the fly, based on your position. You don't actually need terrasync to run FGFS, and you can download the scenery by hand if you'd rather. It's very convenient to be able to select a departure airport, hit the prefetch button in fgrun, wait a couple minutes at worse, and fly off in an unexplored area. But you're right, it's not necessary per se to FGFS usage. Cheers, Nic On Tue, Aug 25, 2009 at 10:59 AM, Randall Green randall.gr...@wright.eduwrote: Martin, I only want to use FlightGear for the flight dynamics. I intend on sending the X, Y Z, Heading, Pitch and Roll to another computer (with an RS-232 link) that has a new kind of Primary Flight Display with a Tunnel In The Sky that the test subject will see. I will actually have the computer's monitor to the Flight Gear computer switched off. Do I really need to have Terrasync loading any textures? I assume that is what it does. Thanks, Randy Green - Original Message - From: Martin Spott martin.sp...@mgras.net Date: Monday, August 24, 2009 4:03 pm Subject: Re: [Flightgear-devel] Compiling CVS FlightGear - is Subversion To: flightgear-devel@lists.sourceforge.net Randall Green wrote: Is Subversion really necessary to compile terrasync? Yes, obviously, because TerraSync is downloading from an SVN repository, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! - - - - Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dhc2 beaver mods
Yep, tried to signal that error on the cvs annoucement list, don't know if the moderator let it through or not. You can do a diff on the previous version to copy back all the instruments as temporary stopgap measure :) On Sat, Aug 8, 2009 at 11:42 AM, Jacob Burbach jmburb...@gmail.com wrote: Looks good , Ive commited your work, but changed the wheel rotation to use my nasal tire-rpm and spin down script. Thanks for the nice work . Thanks syd. Your wheel spin code looks great, the spin down on take off is nice touch. Will the wheel spin work over multiplayer, or could it be made to do so without too much trouble? Would be neat. I'll leave the mp-osi alone until I know what direction we're going with that.Might be better to change the replay code if we're going to remove that property. I'll just modify my local copy to use mp-osi until it is sorted, no worries. I think the whole replay thing needs an overhaul anyway. There seems to be a missing file in cvs right now. I get `Failed to load file: Aircraft/dhc2/Models/panel1.xml', and my panel is completely empty. :D cheers! -- Jacob (aka Tuxklok) -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44, 1.45 props.hxx, 1.32, 1.33
That seems to have done the trick : edit props.hxx, not .cxx to use SGMath.hxx and defining #NOMINMAX at project level seems to work. More testing later, got to run. Thanks to Vivian and Tim for taking time to sort it out, Cheers, Nic On Mon, Jul 20, 2009 at 8:50 AM, Vivian Meazza vivian.mea...@lineone.netwrote: Alan, simgear-config.h cannot be used in SGMisc.cxx because it is called from fg as well as sg. SGMisc will not compile without NOMINMAX , so you need it in your pre-processor definitions. Unless you have a better way … The error you report is the very one that replacing the SGMathFwd.hxx include with the SGMath.hxx include is meant to fix. I have just checked SG CVS Head and AFAIKS it still has the SGMathFwd.hxx include. I have discussed this with Tim, and he doesn’t want to change it for now while he looks for a work around. Vivian -Original Message- *From:* Alan Teeder [mailto:ajtee...@v-twin.org.uk] *Sent:* 20 July 2009 13:13 *To:* vivian.mea...@lineone.net; 'FlightGear developers discussions' *Subject:* Re: [Flightgear-devel][Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44,1.45 props.hxx, 1.32, 1.33 Vivian Thanks, the number of errors has reduced, but I still see the attached for every file that includes props.hxx Also CVS now has the SGMath.hxx include, and NOMINMAX is already defined in simgear_config.h-msvc71 and hence in simgear_config.h, so I think that it is not needed in pre-processor defines. Alan -- *From:* Vivian Meazza [mailto:vivian.mea...@lineone.net] *Sent:* 20 July 2009 00:16 *To:* vivian.mea...@lineone.net; 'FlightGear developers discussions' *Subject:* Re: [Flightgear-devel][Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44,1.45 props.hxx, 1.32, 1.33 And I forgot – you need to change #include simgear/math/SGMathFwd.hxx to #include simgear/math/SGMath.hxx in props.cxx -Original Message- *From:* Vivian Meazza [mailto:vivian.mea...@lineone.net] *Sent:* 19 July 2009 23:47 *To:* 'FlightGear developers discussions' *Subject:* Re: [Flightgear-devel][Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44,1.45 props.hxx, 1.32, 1.33 Alan, Tim’s fixes are now in CVS although not quite finished: you might have to add NOMINMAX to your pre-processor definitions. I’d be interested to hear how you get on. Vivian -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44, 1.45 props.hxx, 1.32, 1.33
cl.exe which compiles C and C++ has nothing in common with the CLR compiler (.NET). Unrelated issues, and what Curtis said : a bit of perspective, gcc is NOT 100% compliant either. The issue has to do with standards compliance and C++ idioms, not MS business strategy Funny how any sense of perspective is thrown out the window with the opportunity to rag on MS... Sheesh !! P.S : if warnings prevented building, no one would be flying today or tomorrow :) yeah, you're talking about backwards compatibility but obviously don't have a clue : you can use old standard unsafe versions of the routines if you want to, program will run fine on all versions of windows... On Sun, Jul 19, 2009 at 11:27 AM, Alan Teeder ajtee...@v-twin.org.ukwrote: It is one thing to bring out a new software tool, in this case a compiler, that enables the use of new technologies (.NET for example), but to completely disregard the principles of backwards compatibility, forcing software to be extensively re-written, is another. -- -- Be Kind. Remember, everyone is fighting a hard battle. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44, 1.45 props.hxx, 1.32, 1.33
Sorry about calling you clueless, btw, I mistakenly thought your post was from the same person who linked to the propaganda bullshit site on MS : I'm no fan of MS, but I'm tired of falsehoods being used to critique them. Especially as all those examples were null or so badly distorted to be absolutely pointless. Not a flame war :) Incidentallly, I've been also failing miserably at fixing this : my code rustiness shows badly in this instance :) Cheers, Nic On Sun, Jul 19, 2009 at 12:35 PM, Alan Teeder ajtee...@v-twin.org.ukwrote: Sorry folks, I seem to have started a flame war. This is not the right place. Alan -- *From:* Nicolas Quijano [mailto:nquij...@gmail.com] *Sent:* 19 July 2009 17:23 *To:* FlightGear developers discussions *Subject:* Re: [Flightgear-devel][Simgear-cvslogs]CVS:source/simgear/propsprops.cxx, 1.44,1.45 props.hxx, 1.32, 1.33 cl.exe which compiles C and C++ has nothing in common with the CLR compiler (.NET). Unrelated issues, and what Curtis said : a bit of perspective, gcc is NOT 100% compliant either. The issue has to do with standards compliance and C++ idioms, not MS business strategy Funny how any sense of perspective is thrown out the window with the opportunity to rag on MS... Sheesh !! P.S : if warnings prevented building, no one would be flying today or tomorrow :) yeah, you're talking about backwards compatibility but obviously don't have a clue : you can use old standard unsafe versions of the routines if you want to, program will run fine on all versions of windows... On Sun, Jul 19, 2009 at 11:27 AM, Alan Teeder ajtee...@v-twin.org.uk wrote: It is one thing to bring out a new software tool, in this case a compiler, that enables the use of new technologies (.NET for example), but to completely disregard the principles of backwards compatibility, forcing software to be extensively re-written, is another. -- -- Be Kind. Remember, everyone is fighting a hard battle. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Sim Gear Debug build fails under Win32 (patch for RenderTexture.cpp included)
Hi all, can't build in debug atm on Doze, as a recent change in simgear/screen/RenderTexture.cpp breaks non X11 builds because of non isolated GLX code. The attributes code should have been wrapped (tsk tsk 8p) This is a bandaid, as it does NOT implement the equivalent functionality on win32 (or non-x11 MacOS X builds) I've simply added an #ifndef _WIN32 bracket to the GLX code. Not having access to a Mac or PC running MacOS X, I didn't do anything to ensure it builds there. Thanks to whomever takes care of this, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. RenderTexture.cpp.patch Description: Binary data -- Enter the BlackBerry Developer Challenge This is your chance to win up to $100,000 in prizes! For a limited time, vendors submitting new applications to BlackBerry App World(TM) will have the opportunity to enter the BlackBerry Developer Challenge. See full prize details at: http://p.sf.net/sfu/Challenge___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Oh, I'm well aware of that (former development professional, not just 3d games. 10 years of it), and it's not a big issue indeed, but nevertheless a cosmetic issue that shouldn't be neglected when possible. So let's forget I even mentioned it happens to cvs users : it happens to stable releases using official aircraft. It's not a showstopper, but seeing as very little effort is necessary to preserve MP visuals across model versions (and that's the extent of backward compatibility I'm talking about, don't anyone go putting words in my mouth). So before more folks chime in saying cvs is unstable, blabblabla, a fact I'm well aware of, let's focus on the fact that it's an universal issue, ranging across flight gear versions, platforms and branches. . This issue has nothing to do with development versions vs release : MP is an heterogenuous network, it's one of its great strengths, let's not go out of our ways to brake visuals consistency. This is basic common sense, but call it barebones userbase pampering if you will ;) I can live with all the glitches and hack my way out of some of them, time allowing, not sure average joe who's an aviation enthusiast and just wants to fly with friends in this particular simulator should have to hack things around. That he can is fabulous. Doesn't mean he has to. Not expecting or demanding anything, just wanted to voice a thought and to remind, as Syd proved it, that the fear of maintenance hell is just that, a fear. And Syd doesn't really care for MP :) That didn't prevent him from coming through, big time. As for external models, I was using that as an example, I certainly don't expect cvs contents to allow for them or correct errors in them... Rather, I was saying that if someone leaves, and is going to break compatibility it might be courteous to change the names of the aircraft, as in the folder name (and thus the paths inside all the xml files) to prevent this kind of problem. Prevention, not medication !!! ;) That should be food for thought, and that was all the whole point of mentioning the whole thing : I don't think it's much to ask that MP visual consistency be taken into account by aircraft authors in the absence of a system that would do it for them : an aircraft using the same folder name is the same aircraft as far as fgfs is concerned, so let's try to avoid situations where *changes in cvs models break MP visuals for stable releases. * Do we want to keep the flexibility of the MP system, or have it degenerate into a version/build discrete system that only shows you the a/c flying the exact same setup as you ? The latter would be a shame. Again, with a lack of a unified or official approach to the problem, all I'm asking is a little thought and not outright dismissal of keeping MP visuals consistent. Point, à la ligne. One last thing : thank you all for your hard work, I appreciate and am enjoying the hell out of it. Cheers, have a nice day, Nic On Sun, Jul 5, 2009 at 11:19 PM, Rob Shearman, Jr. rmsj...@yahoo.comwrote: Nic, It's also worth pointing out (again!) that users of CVS must accept that FG and its associated models are constant works-in-progress. Issues like you describe are easily fixable prior to an official release, but are difficult to manage in the constant state of flux between them. I'm in agreement with Syd that the benefits from changes which simplify an aircraft model's delivery outweigh the relatively small and temporary annoyance that comes with them. Cheers, -R. rm...@umd.edu -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Hi all, there was a fly-in today in New Zealand, and even though a lot of us flew the same plane from the same author, we could only see each other as gliders. Why ? Because in the past couple months, some aircraft used today have undergone model file name changes as well as set file name changes, breaking compatibility for MP visualization purposes with previous versions (and preventing older versions of seeing the new ones also). MP being an heterogeneous environment as far as FGFS versions are concerned, I thought I'd point it out, and that some thought should go into renaming set and model files to avoid this kind of situation. The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) This can be done by having the old set files and model files point to new ones in updated versions, so compat is maintained with older versions, for people flying the new one. Someone who knows the system more intimately can confirm whether it's just the set file, the model file or both that needs to be setup for this to work. Albeit, for people with older version, it seems they'll have to add the same kind of aliases for the new set and model files to see updated versions... I think this is a strong case for NOT needlessly changing set and model file names just to clean up things... Or, if the aircraft now exists in cvs and externally maintained versions, the considerate thing would be to rename the externally maintained version's folder so interested parties can have their cake and eat it : have both versions installed in the case of the Catalina (and other a/c maintained by Gerard which are both in cvs and his hangar). Not sure why this wasn't done for all of Gerard's a/c from the get go, as I seem to recall he changed folder names in at least one instance when he stopped maintaining the CVS versions. Or any other solution agreed upon by the community as how to deal with that particular MP issue. I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Thanks a lot for adding the model files to CVS, I was just done posting my own version of them on the forums :) I meant nothing by culprits, in case that wasn't clear, just as an example of what his us today : I'm a fan of your work on the Beaver and Twin Otter. I had completely forgotten about the Beaver model change, even though I had seen the cvs logs and wondered about it. The catalina, I didn't get around to having a fix around before today and warning people about it. Just wanted to bring this (back) to attention, as not all the userbase will dig deeper if the same aircraft with the same author doesn't work right away in MP ;) It would indeed be nice to hear what the modellers and devs have to say on how this should be tackled. Cheers, Nic On Sun, Jul 5, 2009 at 3:56 PM, syd adams adams@gmail.com wrote: Yes , I'm one of the culprits , and it's not a lack of foresight ,I've done it for a reason. MP is not my biggest concern , I did these aircraft for my own purposes , not entirely with gamers in mind ... but Im glad some like them all the same. These aircraft use one fuselage model now , with gear and other aircraft specific options selected depending on type or name, with cockpit and internals separated to be selected within a certain distance.So there IS no dhc2floats or dhc2wheels. It can be set so the model is visible with older versions ,by adding another animation xml file with those names and adding the neccesary ac model bits ,but in my opinion adds more garbage to the folder. I,ve been updating the dhc-2 for more realistic behavior, (sorry gamers);), so it's nearly ready for another commit, and I can add the old versions , but there's also the option of adding these to the AI/Aircraft .Any idea on which option we should take from the rest of the modellers ? (My problem with that is you end up with two aircraft to maintain, and I tend to forget about the AI version). The specific culprits today are Syd Adams (dhc2, for sure and dhc6 also, I think) and Gerard Robin (PBY-Catalina). There might have been more cases today, and I think we have a few more a/c in cvs who exhibit those symptoms :) I'm sure it was all unintentional and a simple lack of foresight on the consequences such changes might have, but there we have it. Thanks for reading, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] MP notes on breaking compatibility with previous versions of aircrafts....
Sorry, I was going to send you the changes right after posting, should have done it the other way around. But your commits made it all moot, so I removed the archive attachment in my forum post. Thanks for doing something about it with that much speed, Cheers, Nic On Sun, Jul 5, 2009 at 5:37 PM, syd adams adams@gmail.com wrote: I'll fix the dhc-6 , but have to go back through cvs file to remember what the original names were . Im not crazy about people putting different verions of my aircraft on the forum as it kind of makes my work pointless , but it's bound to happen. I think I prefer to do it in the aircraft model folder rather than AI , since it will be easier to remember to remove when no longer needed. Cheers -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Splash Screen alpha bug (and black 3d clouds redux)
Re-sent without pic attachment. On Sun, Jun 28, 2009 at 1:19 PM, Nicolas Quijano nquij...@gmail.com wrote: Hello all, wonder if anyone is seeing this (link at the end), especially on nvidia cards as it would help determine that it's not specific to a driver or particular vendor (ATI GPU here). Basically, aircraft splash screens with alpha in them trigger a texture combine bug (that's a guess) in a repeatable, deterministic fashion. Two solutions, one for users, one for whomever maintains that code : For users, get rid of the embedded alpha : you don't need it in the final product, as it's a splash screen. And you can get the desired effects (often contours, I guess from using a mask layer in gimp or whatever) by merging your layers before exporting to .png, with no need for alpha in the file. The dev solution, the proper one, is to make sure that the splash screen is not used in a texture combine with the 3d cloud textures : that the OGL FSM is set to its canonical state before starting scene rendering after the splash screen. Link to Pic of slash screen bughttp://picasaweb.google.ca/lh/photo/_JxeKpvf4Wbf8TbnX4Eubw?feat=directlink I suspect the black 3d clouds I've mentioned before might be related, as it looks like inverted alpha and only affects one specific cloud type (pichttp://picasaweb.google.ca/lh/photo/B2zLgEeWT9RNFqPqU_RvsA?feat=directlink), as I don't quite think that's the intended effect somehow ;) -- Be Kind. Remember, everyone is fighting a hard battle. -- Be Kind. Remember, everyone is fighting a hard battle. -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
to higher standards than you hold yourself, or both) That's really telling... http://www.lua.org/manual/5.1/ -- version I will use in my experimenting Incidentally, you realize that non programmers find starting at 1 natural, and obviously, I had the same initial reaction to Lua, having learned to code nearly 30 years ago (yep, I was 9) : one grows used to one's truisms. Doesn't mean we shouldn't be flexible ;) I hated array index starting at 1, but since as you already mentioned, they're not really arrays... Nearly every coder has the same reaction. Nasal also needs the debugger and better sandboxing : making a parsing error a fatal exception is not a long term solution... Otherwise C and C++ don't need debuggers either after all, and comp sci students should learn even less assembly than they do now ? It's code or it's not, know what I mean ? Backarsed elitism regarding scripting languages is really, really misplaced. They all need proper development tools when used as such, that's a non brainer. And another reason to lever existing solutions rather than roll your own, which is basically all said. Really, anyone wonder why I didn't want a pissing context : any rational argument can and will be entirely debunked by another rational argument. Nature of the beast. Problem is when you mix in perception and matters of taste in there, which is bound to happen. And no, I'm not surprised Melchior : you have time to play language police, but no time to write docs, right ? documentation: True. Nasal could use some more. Nicolas could spend some of the time that integrating Lua would have taken for writing Nasal documentation. :-) You have to be kidding... These two points were the only clear advantages. What about the rest: faster than nasal (that's an opinion, [...]: Exactly. Just an opinion, with no benchmarks to back it up. And even if it's slightly faster: the Nasal execution time is *not* a bottle-neck in fgfs by any means. I'd love to see your profiling listings, on all supported platforms to that effect :) In my empirical experience, it's the number one cause of stuttering and performance slowdowns (cue in wildfire) I said experience, not evidence :) Just because you say it's not a bottleneck, doesn't mean it's not. Otherwise, you're guilty of the same sin you accused me of : opinion not backed by fact. Thanks in advance for the profiling listings on windows, linux and MacOS X :) And not just one run on each platform, more than one machine and use case per machine, etc. Otherwise, you can't really say they're valid, right ? You know that, right ? C API that allows loading of C/C++ modules through Lua: That's seriously presented as an advantage? It means that we would in no time see fgfs aircraft coming with binary blobs that users are supposed to install, but which they can't explore. That's not only dangerous, it also undermines FlightGear's Open Source character. This misfeature (in our context) alone should be enough to reject Lua! That's a gift for commercial freeloaders, not something that we profit from. If something needs to be fast, then we can code it in C++ right away, and make it available to all aircraft. Document our context, or is it again your veto power rearing its ugly head ? e.g you immediately jump into the possibility of abuse of the facility by commercial freeloaders... Not what I had in mind, neither is the following example (not a fan of the scheme, the idea is alluring indeed) : allowing current commercial exploitiers of FSX or earlier version of the sim to bring their a/c to FGFS, something Curt himself expressed interest in, and whose opinion is worth a lot more than yours for many in this community, under their current scheme of protection through obfuscation (yes, it's useless in most cases, as you know, but they could have that cake if they wanted to). If the project's creator, and afaik, still manager/benign overlord to this day, is interested in growing FGFS through the demise of MSFS, should make you reconsider the words not a game, not a biz. One, the latter is not quite true, since quite a few community members have done and are doing professional, remunerated work with it, maybe even yourself ? user community: Nasal and FlightGear have their own user communities, thanks. Nasal isn't FlightGear only. It's used in other projects as well. And the Lua community wouldn't buy us much either. We wouldn't want that aircraft depend on external Lua modules, which users would have to download from www.luarocks.org or wherever and install them just to fly that aircraft. People contribute to fgfs because they want to, not because they are already familiar with its scripting language, which is easy enough to learn. You don't get it, nothing I can do about it. * Nicolas Quijano -- Wednesday 04 March 2009: I really didn't want to get into that kind of argument (language comparisons, etc) How telling! No, it's called
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
Howdy all, took my sweet time answering, and will not discuss this further on the list. I didn't want to start such a conversation, and consequently only answering now, at the risk of seeing another polemic start : not answering could give the wrong impression :) On Fri, Feb 27, 2009 at 12:40 PM, Brisa Francesco france...@brisa.homelinux.net wrote: just a minor curiosity: what are the advantages of using LUA instead of Nasal ? Cheers Francesco That's something you'll have to figure mostly out for yourself, as I really didn't want to get into that kind of argument (language comparisons, etc) because Lua tends to be come ahead in those when you mention brilliant, small and efficient in the same sentence : lua.org But off the cuff, and without getting into the internals, as I wouldn't (yet) be able to really give Nasal a fair shake : Documentation, debuggers, user community. Plus side effect of having a C API that allows loading of C/C++ modules through Lua (similar to python dlls) : that's a free, runtime usable plug-in system. If you don't see how this could be useful, well, think harder :) And you don't have to buy in the Lua way, there is no such way really, unlike Python and other scripting languages where the proper way to embed is embedding your app in the language and not embedding the language in your app. Lua embeds itself, like you want it to :) It's also brilliant, smaller (runs on cellphones) and faster than nasal (that's an opinion, but I really can't see how anyone says Nasal is fast, at least from my experience so far) I also think that using a roll your own scripting solution was a mistake, and a serious block in the wider adoption of Flight Gear as a developer sandbox (since on this list, we won't pretend it's a general public game, right ? ;)) It made me turn away a couple years back : an end user developer doesn't want to have to read source code to get started. In the game biz, it's never the best solution to roll your own when you can reuse, especially regarding scripting. Adequate solution, sometimes. Reinventing the wheel in a project that already relies so much on third party libraries simply makes no sense from an outsider's perspective, as it takes away precious and spare manpower from the crucial bits of the system And no, nasal is not really crucial, at least not with jsbsim. Why was Nasal chosen in the first place ? Wasn't it to supplement a fledgling FDM module at the time, yasim, that was lagging behind jsbsim and its property system ? Or so I've inferred and been told :) And then it grew from there... And well, as you can see already with FGFS and nasal, users have a way of misusing the tools you give them... Proper documentation is one step in that losing fight, a real debugger another : yes, always a losing fight to prevent user abuse, that doesn't mean nothing has to be done about it... Also, maybe unbeknownst to the authors, Nasal is really reinventing the Lua wheel in many cases :) Syntax has enough similarities that extensions to the Lua VM to execute Nasal as Lua bytecode is in the doable. var becomes local (Lua uses globals by default, local variables are specified by using local) Any left handed value can be hold anything Lua wise in it, be it the built-in types, user types, or light user types (only a pointer to user data accessed through Lua C Api) Oh, and you can compile your bytecode to C and load it as one of the aforementioned plug-ins as a first step of rolling back scripts into the native codebase for performance purposes... And Lua internals are really, really simple and mastered by a good portion of its community. Nasal simply doesn't compete at that level : community of users is far from critical mass, documentation is inexistent, and performance is not a priority, according to the author's own words on Nasal's site. The whole property tree would be accessed through the Lua C api, mapping to the same names inside Lua, and could be protected from writing from Lua, etc. Again, Lua is naturally meant to be a sandbox : it started as a purely configuration file parser and loader, and organically evolved over the last 15 years into a full fledged bytecode VM based language. It also doesn't impose coding styles, is naturally sandboxed. Research it, you'll come away a changed man ;) (kidding, you might not like it, but I'd be surprised anyone seriously researching it wouldn't see some clear advantages to it) This isn't a really hard project, it's just very tedious for the most part : the hair pulling would be from the amount of partial or complete porting of nasal scripts. As others have said, thanks to the property system (thanks jsbsim), there is already an elegant mechanism to interact with the internals of the engine, so adding another scripting language is quite trivial. All things I had considered before mentioning the possibility of Lua. And right after the first official release of OSG version would seem the right time for a major
Re: [Flightgear-devel] Nasal alternatives : possible, of course,
In the interest of clarity, moving to OSG was a good, if not brilliant move (some potential sources of revenue would have it as a requirement as far as open source engines are concerned) It's simply a bit bloated, by default, although I suspect you don't have to ship the parts you don't use at runtime to your users. But it covers many bases and use cases of scene management and rendering, so the bloat is offset by a generic and broad ability to fill one's needs. Just wanted to clarify that I was not saying in any way that moving to OSG was bad. It did leave previous users in its midst. Rather, it's an example of how FGFS has been shown to be able to go through titanic upheavals, a good trait of character :) And switching to OSG wasn't a lot of work for very little return for a sizeable portion of your (former) userbase ? That a lot of features, some obvious, some not, are still not working is not a hit on the ROI in your opinion ? You talk of bloat, but you moved to OSG, the ultimate bloated whale in the world of 3d rendering !! (and that's common knowledge) This is not a judgement on its quality btw, but it's bloated software nonetheless :) --paragraph break should have been inserted here And I won't mention that is has no adequate documentation and no debugger. Period. (-- that's very serious) Oops, sorry I just did ;) The last two lines talk about Nasal. NOT OSG : it's documented and easily debuggable in one's favorite development environment. It also now has, among others, built-in Lua support ;) Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal alternatives : possible, of course, but trivial or hair pulling task ?
Hi all, let me start that my goal here is NOT to start a polemic on the reasons for using nasal vs any other scripting language, or the scripting vs native code, or any such argument :) Thanks for remembering that. That said, being a long time user and proponent of levering scripting in games/sims, and particularly, using Lua, I have a keen interest in any insights garnered over time by current and past fgfs devs. How coupled are Nasal and the scripting glue in FGFS ? Is there a clean break, or if not, can it be refactored without too much pain into something that would allow end dev users to use whatever scripting language they prefer, or have many modules already writen in, etc. If the coupling is not of the hair pulling type, it might be conceivable to integrate another scripting language alongside Nasal for starters, and in time, completely replace it if one is so inclined :) For me, this would be Lua, and I'll be working on integrating it in my local fork, but as I'm just getting down to tinker with FGFS source code, I'm interested in hearing your views on the topic. If there is interest in this beyond my own, I'd rather do it in a collaborative/friendly way that's not one sided, or in other words, I'd rather not rip out Nasal savagely to replace it completely with Lua, without thinking about compatibility down the road. My preferred approach would be to start with cohabitation, rather than coupling Lua to a local fork... What I'm interested in hearing is about the collective and individual experience of working with Nasal at the source code level, the API/communication mechanism between its VM/interpreter and native code, and plenty of other documentation details which do not seem to exist or that I haven't been able to find, and can save a lot of time in coming to grasp with code you haven't written. Thanks in advance for sharing your experiences with Nasal integration, Cheers, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS: data/Aircraft/F-8E-Crusader Crusader-SetBase.xml , 1.23, 1.24
Gerard, you're not getting it : if I want wildfire to spread when I crash a Crusader, you shouldn't have a say in it, period. Let me try to explain it from the user's perspective : a user of both the dev's creation, the simulation, and in this case, your a/c. I'm the one piloting the Crusader, and running Flight Gear on my machine. I do no want you or anyone else to make a sneaky change to a global pref, be it wildfire or anything else. If I don't want wildfire, I'll turn it off in the global prefs (and incidentally, if anyone is counting, it's off ;)) It simply makes no sense for you to change my global prefs in one a/c : how do you know my next session is not wildfire training ? Or that I'm not going to be filming a bunch of firefighters in the simulation ? What's next ? Saving and archiving failures in a an a/c with system wide effects ? If I understand this correctly, that means the next time I start the sim, the fire is off, without any means for me to know so unless I had read about this here : I'm not your typical user, in that I'm also a professional software developer and I'm used to fighting with my computer to get things done, whatever platform I'm using atm. So I'd look for a solution... Imagine how hiding a global prefs like that in a a/c FDM config files is going to make it hard for the average user to know what the hell is going on with his sim : Flight Gear is already very complex, no need to go out of our way to make it hard for people to use it. I really don't care for the wildfire feature at this time, because it doesn't align with my current interests, and I have a problem with uncontrolled eye candy (the game dev with 5 shipped and 10+ cancelled projects talks here), but that's another story, and it has more to do with uncontrolled triangle and texture usage... But that is one of the great things with FGFS : you can still run in MP while flying in your own instance of the world, with its own particular config. It's important to realize that making that kind of change within the a/c has farther ranging effects than you seem to realize. First impressions are often the only impression (don't I know it ;)), and this doesn't help a new user to truly gauge the possibilities of the program if there are plenty of little sneaky settings like that. It makes FGFS look messy to the outsider, and consumed by petty bickering. If it's a problem of language, I'll be happy to write this in my native French :) Cheers, and keep working on the beautiful Crusader, Nic -- Be Kind. Remember, everyone is fighting a hard battle. -- Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA -OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise -Strategies to boost innovation and cut costs with open source participation -Receive a $600 discount off the registration fee with the source code: SFAD http://p.sf.net/sfu/XcvMzF8H___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The use of models from other formats
You probably get that a lot, or I hope you do : Thanks for taking of win32 binaries, it's very much appreciated. Cheers, et un gros merci (assuming you're French) Nic On Sat, Feb 7, 2009 at 1:37 PM, Frederic Bouvier fredfgf...@free.fr wrote: I don't know where this discussion will lead us but anyway, I made a new Windows build with the last OSG 2.8 branch with a working LWO plugin : ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/fgrun+fgfs-osg-win32-cvs-20090207.zip This Wiki page explains how to use it : http://wiki.flightgear.org/index.php/Keeping_FlightGear_(win32)_up_to_date_without_compilinghttp://wiki.flightgear.org/index.php/Keeping_FlightGear_%28win32%29_up_to_date_without_compiling Regards, -Fred -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today- http://p.sf.net/sfu/adobe-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM) software. With Adobe AIR, Ajax developers can use existing skills and code to build responsive, highly engaging applications that combine the power of local resources and data with the reach of the web. Download the Adobe AIR SDK and Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] v1.9 screenshots
Hi all, ex-subscriber back in the fray : it's been years, and my hat off to all involved for the leaps and bounds in bringing FGFS so far from its humble beginnings :) In answer to Curt's request for screenies, I have set up a public web album on my Picassa page where I'll be uploading screenshots, both of eye candy/PR nature and to illustrate problems (might put the latter in a Glitch subfolder, or somesuch) All the screenshots (by default, my uploaded pictures are NOT) will be under the Creative Commons license so feel free to use them :) (remix, commercial use, share alike are the conditions/rights) http://picasaweb.google.ca/noxiousnic/FlightGear Not much yet, but I'll be uploading regularly. Not sure if I'll keep uploading full size images, as they eat up space quite fast. We'll see :) Cheers, and happy flying to all ! Nic On Mon, Jan 26, 2009 at 3:11 PM, syd adams adams@gmail.com wrote: another clue is the C-FGFS on the side of the cessna :) -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Be Kind. Remember, everyone is fighting a hard battle. -- This SF.net email is sponsored by: SourcForge Community SourceForge wants to tell your story. http://p.sf.net/sfu/sf-spreadtheword___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
