Re: [Flightgear-devel] joystick support broken
Dave Perry wrote: I just updated plib, SimGear, fgfs, and the base package from cvs. Both js_demo and fgfs dont identify my CH Flight Sim Yoke and my Pro Pedals, both USB. js_demo shows just for the name of both. jstest identifies both correctly. PLIB got a significant update to the JS code these days, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] A method for getting funds...
Giles Robertson wrote: My own take on funding for FlightGear is that funding FGFS itself may be difficult, but we might well be able to get corporate funding for developing SimGear as a simulation kernel. Flight Simulators don't appeal to a huge sector of the market; but an architecture on which you can build any simulation you want sounds much more attractive and useful. The likely return on a wider project could be much greater than that simply on a flight simulator. I think this is a better approach, convince all the (research) projects to donate a tiny amount of their research budget back to FlightGear, being it code additions, hardware to run the site, or financial ones. Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mouse frozen after running fullscreen
David Megginson wrote: Erik Hofman wrote: I think that the fix will be simply to force the mouse pointer to be visible before exiting FlightGear. This is in CVS now. Could you please test it? That solves the problem completely. Thank you very much, Erik. Great! It wasn't too difficult, since you already told what to do :-) Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Docs/InstallGuide/html
Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Docs/InstallGuide/html In directory baron:/tmp/cvs-serv7474/InstallGuide/html Modified Files: getstartch2.html Log Message: Reffer to /usr/locla/share/FlightGear now. You'd better mail such changes to me or at least post them on the devel-list. I thought I did that, didn't I? Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: Martin Spott wrote: Erik Hofman wrote: Update of /var/cvs/FlightGear-0.9/data/Docs/InstallGuide/html In directory baron:/tmp/cvs-serv7474/InstallGuide/html Modified Files: getstartch2.html Log Message: Reffer to /usr/locla/share/FlightGear now. You'd better mail such changes to me or at least post them on the devel-list. I thought I did that, didn't I? At least I didn't realize ;-) BTW, I didn't find your change in the current CVS checout of the base package. Could you tell me the lines you changed ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott wrote: BTW, I didn't find your change in the current CVS checout of the base package. Could you tell me the lines you changed ? The *base* package? I don't think anything changed there (I searched for /usr/local/lib in all the documents, and if it didn't show up I didn't change anything). Is the documentation still maintained by someone? Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Beacons
Frederic Bouvier wrote: The beacon tower modeled is here : http://www.flightgear.org/~curt/Photos/KANE/ Hey, do they really do VFR navigation with rotating _light_ beacons ? Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Erik Hofman wrote: Martin Spott wrote: BTW, I didn't find your change in the current CVS checout of the base package. Could you tell me the lines you changed ? The *base* package? I assume the location of the HTML file you changed is somewhere down in the base package. Changes in the 'docs/'-tree used not to show up on the 'cvslogs' list - at least not _my_ changes Is the documentation still maintained by someone? I try my best - although my time is limited and usuallythe changes in FlightGear, that have substantial effect on the manual, come faster than I manage to follow Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [Flightgear-cvslogs]
Martin Spott writes: Erik Hofman wrote: Martin Spott wrote: BTW, I didn't find your change in the current CVS checout of the base package. Could you tell me the lines you changed ? The *base* package? I assume the location of the HTML file you changed is somewhere down in the base package. Changes in the 'docs/'-tree used not to show up on the 'cvslogs' list - at least not _my_ changes I think this is the change in question http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Docs/InstallGuide/html/getstartch2.html.diff?r1=1.3r2=1.4cvsroot=Flight Gear-0.9sortby=date This URL should be useful for those tracking changes to the Docs http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Docs/InstallGuide/html/?cvsroot=FlightGear-0.9 HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs]
Norman Vine wrote: I think this is the change in question http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Docs/InstallGuide/html/getstartch2.html.diff?r1=1.3r2=1.4cvsroot=FlightGear-0.9sortby=date Hey, _this_ is really neat a tool ! Thanks for the link, it enabled me to find the appropriate text passage in the sources, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? I don't know how this scenery loading message/pause was implimented, but ... FlightGear can't load add-on 3d models (like the SFO buildings and bridges) inside the threaded scenery loader because the plib model loader functions are not thread safe in conjunction with opengl. So, FlightGear maintains a queue of models that need to be loaded and then loads them one per frame to interleave the work with rendering. This is extremely inefficient if we are waiting to load all the models. We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
Erik Hofman wrote: Hi, I was wondering, do others feel that the changes in the last week or so justify a new release (0.9.5-1)? I have the feeling that it does. I realize Curtis is busy for the next two weeks so it has to wait some more, but if this is desired I will hold off any drastic changes to the code until after the release. What do you all think? Erik What specific changes are you refering to? Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Curtis L. Olson wrote: Erik Hofman wrote: I noticed that the fact that scenery loading is faster when pressing 'v' is caused by the fact that FlightGear doesn't bother rendering the scene in the mean time. Maybe it would be a good idea to set /sim/rendering/draw-otw to false just after the message box is displayed, and setting it back to true after scenery loading has finished? I don't know how this scenery loading message/pause was implimented, but ... FlightGear can't load add-on 3d models (like the SFO buildings and bridges) inside the threaded scenery loader because the plib model loader functions are not thread safe in conjunction with opengl. So, FlightGear maintains a queue of models that need to be loaded and then loads them one per frame to interleave the work with rendering. This is extremely inefficient if we are waiting to load all the models. We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. I tried that, but it appeared that the queue is also filled at frame rate. So the queue can be quickly flushed but it will be filled as soon as we will render the first few frames. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
Erik Hofman [EMAIL PROTECTED] writes: I was wondering, do others feel that the changes in the last week or so justify a new release (0.9.5-1)? If you are going to make a new release, just don't name it 0.9.5-1, please. That would create lots of confusion for both users and distribution packagers. The reason is that the dash character is used to separate packaging version from upstream version in Linux distribution packages. At least that's how it's in Debian and I think rpm-based distros use the same scheme, don't know about other distros. For example, the current flightgear's version in Debian unstable is 0.9.4-1. http://packages.debian.org/unstable/games/flightgear In my opinion, you could call the new release just 0.9.6. It's not like the numbers would run out anytime soon :) That is, if you use the same numbering scheme as Linux kernel (after 0.9.9 release comes 0.9.10). Thank you for a great simulator! I will order my copy of Stick and Rudder soon and start learning flying. -- Kalle Valo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
Curtis L. Olson wrote: Erik Hofman wrote: Hi, I was wondering, do others feel that the changes in the last week or so justify a new release (0.9.5-1)? I have the feeling that it does. I realize Curtis is busy for the next two weeks so it has to wait some more, but if this is desired I will hold off any drastic changes to the code until after the release. What do you all think? Erik What specific changes are you refering to? Fixes for the Scenery Loading dialog that now loads much faster on low end hardware because it is frame rate independent (thanks to Frederic). Lots of small fixes (joystick configurations, Nasal fuel handling for the Spitfire and fixing the mouse freeze after exit problem). To name a few. Overall, the code as it is now feels a lot more comfortable compared to the previous release. We could take some time and fix some more problems, but I didn't announce the previous release for IRIX because it didn't feel right. Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
Kalle Valo wrote: Erik Hofman [EMAIL PROTECTED] writes: I was wondering, do others feel that the changes in the last week or so justify a new release (0.9.5-1)? If you are going to make a new release, just don't name it 0.9.5-1, please. That would create lots of confusion for both users and distribution packagers. Good point, I realized that after posting the message. I don't think 0.9.6 would be a good idea, but 0.9.5b could be used (as this scheme is already in use for the Windows binary). Erik -- Searching for a 60 to 100 passenger Jetliner? http://www.rekkof.nl/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear 0.9.5-1
* Erik Hofman -- Monday 16 August 2004 22:05: Curtis L. Olson wrote: What specific changes are you refering to? [...] Nasal fuel handling for the Spitfire For all YASim aircrafts with more than one tank, actually. Not that this alone would justify an new release. :-) Overall, the code as it is now feels a lot more comfortable compared to the previous release. We could take some time and fix some more problems, but I didn't announce the previous release for IRIX because it didn't feel right. Here's another problem: $ fgfs --aircraft=c172-610x-jsbsim makes fgfs abort, because this redirects to ../c172r/c172r-jsbsim-base.xml, which tries to include c172r-base.xml. But this file is searched in c172/, not in c172r (where it could be found). m. Vivian: I've responded to your message from today, but I'm not sure if you'll ever get it. My last four came back! I'll post to the list in a few hours if this fails, too. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear 0.9.5-1
On Mon, 16 Aug 2004 22:08:42 +0200 Erik Hofman [EMAIL PROTECTED] wrote: Kalle Valo wrote: If you are going to make a new release, just don't name it 0.9.5-1, please. That would create lots of confusion for both users and distribution packagers. Good point, I realized that after posting the message. I don't think 0.9.6 would be a good idea, but 0.9.5b could be used (as this scheme is already in use for the Windows binary). Debian is one of the distros that use numbers after the - for local changes to an upstream version, packaging changes, etc. Lots of other Debian packages have a or b or whatever added to the upstream version number without a problem. So I agree that this should work fine. -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear pgpSjjddt1m5p.pgp Description: PGP signature ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mouse frozen after running fullscreen
Erik Hofman said: David Megginson wrote: Erik Hofman wrote: I think that the fix will be simply to force the mouse pointer to be visible before exiting FlightGear. This is in CVS now. Could you please test it? That solves the problem completely. Thank you very much, Erik. Great! It wasn't too difficult, since you already told what to do :-) What happens on a kill/int/segfault? Can it be changed to something like a single pixel or some other unobtrusive thing instead? Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 'Nother Newbie.
folks: i just joined your mailing list. and i've probably jumped into the wrong one. (and i'm about to start rambling, so if you're impatient, delete this now...) i am looking for some pointers on hardware interface. after running the FlightGear sim on my box, i'd say it's a pretty mature product at this point, and i'm not sure my C++ is well-oiled enough to make a contribution. i started looking at flight gear hoping that there would be a way to get at system internals from outside the box so that i could build my own simulated radio stack and hook it up. after searching the web site, i came to the conclusion that the developers mailing list was a close as i was going to get to discovering internals without downloading the CVS tree and reading sorce code for 6 months. can anyone tell me if there is already a part of your project devoted to this, or if you think it's even worth trying? i don't want to drive your project members crazy reading email from someone who has an interest that your (really cool by the way) project doesn't support, or plan to. thanks for listening, martin pardee __ Do you Yahoo!? Yahoo! Mail - 50x more storage than other providers! http://promotions.yahoo.com/new_mail ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery Loading
Curtis L. Olson said: I don't know how this scenery loading message/pause was implimented, but ... The most recent changes from Fred work great. I made the original fix in order to correct the problems doing in air starts near KSFO before the release, without thinking about the frame rate issue. All it did was suspend FDM updates, so despite the observation that there was a delay, scenery was loading at the same rate it always did. snip We should modify the code to simply load all the models in the queue (i.e. flush it) at startup, rather than doing one-per-frame and hacking around that with turn draw-otw=false. IMO that would be a *much* better solution. This sounds pretty much like what the latest patch does. It just holds the splash screen up until the queues are flushed, rather than rendering the whole scene with a popup dialog. (The splash will also reappear during teleports). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 'Nother Newbie.
martin pardee wrote: folks: i just joined your mailing list. and i've probably jumped into the wrong one. (and i'm about to start rambling, so if you're impatient, delete this now...) i am looking for some pointers on hardware interface. after running the FlightGear sim on my box, i'd say it's a pretty mature product at this point, and i'm not sure my C++ is well-oiled enough to make a contribution. i started looking at flight gear hoping that there would be a way to get at system internals from outside the box so that i could build my own simulated radio stack and hook it up. after searching the web site, i came to the conclusion that the developers mailing list was a close as i was going to get to discovering internals without downloading the CVS tree and reading sorce code for 6 months. can anyone tell me if there is already a part of your project devoted to this, or if you think it's even worth trying? i don't want to drive your project members crazy reading email from someone who has an interest that your (really cool by the way) project doesn't support, or plan to. As I understand it, you'd like to build a hardware radio stack and interface it to FG. There are a couple of ways you could attack this. 1. Add a module (i.e. some code) inside FG that runs every frame. Your code would read all your hardware switches through whatever mechanism you have devised and update the FG internals. It would also send things like frequencies (probably cooked up in the best flavor for your hardware) so that the radio stack can display the frequencies. 2. You could go for total separation and create an external application that talks directly to your hardware. That application could then communicate with FG via the telnet interface to read the necessary FG property values to update your hardware display, and write the switch/knob values back to FG as input to it's radio models. There are probably a variety of other ways you could get this done, but these two approaches are the ones that jump to the front of my list. The first approach would require a bit more digging into the FG internals, the 2nd approach could have potentially sluggish performance. The telnet interface is the ultimate in flexibility, but is not anywhere close to high bandwidth. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
