[Flightgear-devel] noshadow prefix now really deprecated!
The first shadow implementation allowed to prefix object names with noshadow to exclude them from shadow generation. This was considered a bad idea from the beginning, as a name is a name and shouldn't contain instructions. That's why this method was deprecated very early, and a noshadow animation was written as the recommended way. The upcoming release will still support the prefix, but the next (shadow supporting) release after that will not. So this release cycle should be used for the migration of those aircraft which still use the prefix. I added an error message that's output whenever an object with a noshadow prefix is found by the shadow occluder. Sorry for the inconvenience. :-) m. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
Am Montag, den 03.12.2007, 00:29 +0100 schrieb STenyaK (Bruno Gonzalez): Ok, thanks. I've thinked a bit more about this whole idea and, since i was planning to code Motorsport as a library instead of as a standalon executable, maybe Motorsport can be used from FlightGear, instead of being coded inside it. It looks like FG already uses several different physics engines depending on the planes (am i right?), so it would be a matter of adding another one for land vehicles. How does that sound? This sounds good to me, I would really appreciate a car FDM. Especially, if it can interact with the aircraft (towing or pushback, or even load cars into aircraft). Your project would benefit from the worldwide scenery (e.g for the Rallye Paris Dakar) and multiplayer capability. On 12/1/07, Detlef Faber [EMAIL PROTECTED] wrote: Am Samstag, den 01.12.2007, 18:39 +0100 schrieb STenyaK (Bruno Gonzalez): I'm unable to find the Jeep or any other car that were mentioned.. haven't searched much though. Try this: http://sol2500.net/flightgear/jeep.zip It should work with 0.9.10, but you will not have different ground properties like the FlightGear CVS version has. Quick question: by ground reactions you mean collision detection and response? Are there no plane-to-plane collisions currently, only basic plane-to-ground? And is the ground a generic trimesh or a heightmap? On 12/1/07, Jon S. Berndt [EMAIL PROTECTED] wrote: GWMobile wrote: Just to help you. X-plane simulates springs and tires and has an open interface. People have built cars for x-plane. The roads suck though. I think it would be great if fgear did this too. Ground reactions have been a hot topic for a while. It sounds like Andy has got something really nice for YASim, and I hope to get time to look at that code at some point very soon. Obviously, people look at simulations differently, and there are a lot of sims out there that serve different purposes. To the dismay of some here, we haven't paid so much attention to ground reactions with JSBSim. First and foremost is because I don't have the time I once did. Second, it's because my own focus is more on the GNC aspects, and overall sim architecture, as well as other things. At some point, I hope to revisit the ground reactions code. Jon - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
On lun 3 décembre 2007, Melchior Franz wrote: Update of /var/cvs/SimGear-0.3/SimGear/simgear/scene/model In directory baron:/tmp/cvs-serv27750 Modified Files: Tag: PRE_OSG_PLIB_20061029 shadowvolume.cxx Log Message: let use of deprecated noshadow prefix cause error message Will that message remain permanently, ? to save time, would be nice. We could avoid to modify the .ac model and the .xml file. We only need to check that the shadow is processed with the with typenoshadow/type animation, if we want shadow. Cheers Gérard http://pagesperso-orange.fr/GRTux/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] noshadow prefix now really deprecated!
On lun 3 décembre 2007, Melchior FRANZ wrote: For those who want to avoid the message already now, here's a list of models still using the noshadow prefix. Note that some objects use a noshadow *postfix*. This doesn't cause error messages, but it will also not discard shadows. Never has. ./A-10/Models/A10-004-015l2.ac ./A-6E/Models/A-6E.ac ./Albatross/Models/pdisk.ac ./Buccaneer/Models/buccaneer.acpostfix ./DH-89/Models/transparent.ac ./F-86/Models/transparent.ac ./F4U/Models/blaze.ac ./F4U/Models/pdisk.ac ./F4U/Models/transparent.ac ./F80C/Models/Instruments/Gunsight/gunsight.ac ./F80C/Models/f80.ac ./Hunter/Models/hunter-ga11.ac partly postfix ./Hurricane/Models/hurricane-new.ac ./Hurricane/Models/hurricane-ver-25.ac ./Lightning/Models/exhaust.ac ./OV10/Models/CDF/OV10.ac ./OV10/Models/NASA/OV10_NATO.ac ./OV10/Models/USAFE/Instruments/Gunsight/gunsight.ac ./OV10/Models/USAFE/OV10_NATO.ac ./SR71-BlackBird/Instruments/Models/ai-bb.ac ./SR71-BlackBird/Models/SR-71A-Blackbird.acpostfix ./SR71-BlackBird/Models/SR-71B-Blackbird.acpostfix ./SR71-BlackBird/Models/SR71-Cockpit-avant.ac postfix ./SeaVixen/Models/MB-Mk4.acpostfix ./Sikorsky-S58/Models/s58.ac ./Spitfire/Models/seafireIIIc.ac ./Spitfire/Models/spitfireIIa.ac ./an2/Model/an2_r.ac ./beaufighter/Models/blaze.ac ./beaufighter/Models/pdisk.ac ./beaufighter/Models/transparent.ac ./bf109/Models/blaze.ac ./bf109/Models/blaze2.ac ./bf109/Models/pdisk.ac ./bf109/Models/transparent.ac ./fw190/Models/blaze.ac ./fw190/Models/fw190a8.ac ./fw190/Models/pdisk.ac ./fw190/Models/transparent.ac ./jeep/Models/roof.ac ./jeep/Models/transparent.ac ./ju52/Models/ju52.ac ./mosquito/Models/pdisk.ac ./mosquito/Models/transparent.ac ./pa24-250/Models/propDisc/fastprop.ac ./seahawk/Models/SeaHawk-FGA6-WV859.ac partly postfix ./seahawk/Models/exhausts.ac ./spitfireIX/Models/pdisk.ac ./spitfireIX/Models/transparent.ac ./vulcanb2/Models/exhaust.ac m. Thanks, i guess we can keep these deprecated object-name. We only have to check that the shadow animation is there with typenoshadow/type (if we want shadow) I know i have old models with noshadow prefix, which should not be a problem (i hope) because shadow is processed elsewhere within the model, with typenoshadow/type animation. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
On 12/3/07, Detlef Faber [EMAIL PROTECTED] wrote: Am Montag, den 03.12.2007, 00:29 +0100 schrieb STenyaK (Bruno Gonzalez): It looks like FG already uses several different physics engines depending on the planes (am i right?), so it would be a matter of adding another one for land vehicles. This sounds good to me, I would really appreciate a car FDM. Especially, if it can interact with the aircraft (towing or pushback, or even load cars into aircraft). I'm not sure what FDM means, couldnt' find a good explanation. It looks like it's what i call a physics engine. Are there any existing examples of several FDMs interacting with each other? Planes colliding with other planes, or their turbulences affecting the other, etc.? An FDM that uses Motorsport physics could be easily created, but the interaction between several FDMs is another issue... Your project would benefit from the worldwide scenery (e.g for the Rallye Paris Dakar) and multiplayer capability. I'm still not sure if that kind of features would be included in the Motorsport core, or provided by a third party program (such as FG), we're still in the design stages of the project. -- Saludos, Bruno González ___ Msn/Jabber: stenyak AT gmail.com ICQ: 153709484 http://www.stenyak.com - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
On Monday 03 December 2007 12:04:36 gerard robin wrote: Will that message remain permanently, ? to save time, would be nice. We could avoid to modify the .ac model and the .xml file. I would agree that to prevent unnecessary pain for modellers (and to optimise their free time to allow them to keep adding nice stuff to FG ;-) perhaps once the aforementioned noshadow by object naming feature has been removed, the error message could be removed too? The Lightning will generate the error, but falsely (there's already a proper noshadow animation, it never relied on the object names for that.) Cheers, AJ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
On lun 3 décembre 2007, Melchior FRANZ wrote: * gerard robin -- Monday 03 December 2007: On lun 3 décembre 2007, Melchior Franz wrote: Log Message: let use of deprecated noshadow prefix cause error message Will that message remain permanently, ? Only in the next (plib based) release. Not in fg/osg. But I might degrade it to SG_WARN right before the release. This depends on how many developers drop the deprecated prefix until then. The problem with SG_WARN is that, unfortunately, not enough people see it, which defeats its purpose. We have yet to clean up the logging system and recommend that developers always use at least --log-level=warn. m. Yes SG_WARN, would be the best, that message isn't it for FG developer , who could want a help, to keep their models compatible ? The users don't care about it, they only want the best :) Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
* gerard robin -- Monday 03 December 2007: On lun 3 décembre 2007, Melchior Franz wrote: Log Message: let use of deprecated noshadow prefix cause error message Will that message remain permanently, ? Only in the next (plib based) release. Not in fg/osg. But I might degrade it to SG_WARN right before the release. This depends on how many developers drop the deprecated prefix until then. The problem with SG_WARN is that, unfortunately, not enough people see it, which defeats its purpose. We have yet to clean up the logging system and recommend that developers always use at least --log-level=warn. m. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
* gerard robin -- Monday 03 December 2007: Yes SG_WARN, would be the best, that message isn't it for FG developer , who could want a help, to keep their models compatible ? Err ... but if I see that right, there's only one file concerned in your case: ./SR71-BlackBird/Instruments/Models/ai-bb.ac You could have fixed *and* committed the file in the time that it took to write three emails about the painful procedure. ;-) m. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [Simgear-cvslogs] CVS: SimGear/simgear/scene/model shadowvolume.cxx, 1.12.2.1, 1.12.2.2
On lun 3 décembre 2007, Melchior FRANZ wrote: * gerard robin -- Monday 03 December 2007: Yes SG_WARN, would be the best, that message isn't it for FG developer , who could want a help, to keep their models compatible ? Err ... but if I see that right, there's only one file concerned in your case: ./SR71-BlackBird/Instruments/Models/ai-bb.ac You could have fixed *and* committed the file in the time that it took to write three emails about the painful procedure. ;-) m. Yes, within cvs today, but you don't know the contents of the models which are in my hangar, and will come up (a day) within cvs . :) :) :) AND, i am not, fortunately, alone, probably others developers could be interested. Cheers -- Gérard http://pagesperso-orange.fr/GRTux/ - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
On Dec 3, 2007 6:23 AM, STenyaK (Bruno Gonzalez) wrote: I'm not sure what FDM means, couldnt' find a good explanation. FDM is the acronym we use for flight dynamics model. Conceptually, a physics engine engine covers much of the same ground. If I were to get really nitpicky, perhaps I could say that the flight dynamics model contains a physics engine + additional speciallized code to model the dynamics of flight. It looks like it's what i call a physics engine. Are there any existing examples of several FDMs interacting with each other? Planes colliding with other planes, or their turbulences affecting the other, etc.? So far in the flightgear project we have not addressed aircraft/vehicles affecting each other. Our philosophy is that we are modeling a friendly airspace so collisions with other aircraft should never ... at least for those that take their simming seriously and start somewhere other than the default location. It would be interesting to model turbulence affects from one aircraft/vehicle onto another, but to do this in a generic and physically correct way, might be far beyond the scope of what we can accomplish with finite compute power. Maybe we could build in some interesting heuristics/hacks though that could be fun. In the world of aviation we have wake turbulence, formation flying (and air to air refueling, aero towing, etc.) An FDM that uses Motorsport physics could be easily created, but the interaction between several FDMs is another issue... The FlightGear FDM interface was originally designed so it is relatively straight forward to drop in another physics engine. (sorry to mix terms there.) :-) I'm still not sure if that kind of features would be included in the Motorsport core, or provided by a third party program (such as FG), we're still in the design stages of the project. I've always thought it would be fun to wind through an interesting mountain region for a hundred miles or so of realistic roadway with real terrain, etc. The driving sims I've seen have either stuck with specific race tracks or very small areas with lots of detail, or larger areas with very sparse detail. Algorithmically it would be possible to create large areas with pretty nice detail. I've been dabbling in some of that recently, but it's really hard stuff. Intersections are hard to deal with, the complexity and polygon count of detailed roadways are hard to handle, and creating realistic surfaces from noisy SRTM data is also a difficult thing to do. But there are some tantalizing ideas that wouldn't be all that hard. If you added some attributes to your road data base, you could start dropping in things like mile markers, street lights, other regularly spaced signs, mail boxes, guard rails, jerzey barrier. My problem is that I have way more good ideas than I have time. Well at least I think they are good ideas. :-) Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ Unique text: 2f585eeea02e2c79d7b1d8c4963bae2d - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
On 12/03/2007 08:32 AM, Curtis Olson wrote: An FDM that uses Motorsport physics could be easily created, but the interaction between several FDMs is another issue... Consider the PBY Catalina or other amphibian: -- When it's in the air, it's an aircraft. -- When it's on the water, it's a boat. -- When it's on land, it's a vehicle. I don't recommend it, but these could be treated as three separate problems, with three separate dynamics models ... but what we really need is a unified dynamics model that can handle all three cases in a consistent way. Obviously air loads *and* tire loads are important for cars. Ditto for aircraft on the ground. Obviously you need to model the air *and* the water for sailboats. And while an amphibian is crawling out of the water onto land, it is in all three worlds at once. I don't much care what you call it. -- On this list heretofore, it has usually been called the flight dynamics model (FDM). -- In the world of boats, it is called the fluid dynamics model (again FDM). -- As soon as we have tires on pavement, those names are no longer apt. -- You can also have a structural dynamics model. Alternatives include plain old Dynamics Model (DM or DyMo) or of course Physics Engine (PhEng). Beware that there is a huge legacy here; there are nearly ten thousand mentions of the term FDM in the flightgear file tree, so even though the term isn't apt, it is going to remain with us for quite a while. In the interests of backward compatibility, it might be simplest to declare that FDM stands for Fine Dynamics Model (as in RTFM == Read the Fine Manual), and declare that the ideal FDM should include air, water, tires, and mechanical interactions. Going forward, Physics Engine' is as good a name as any, and is consistent with usage in the rest of the modeling community. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying/Contributing with a wheeled vehicle simulator
On 12/3/07, Curtis Olson [EMAIL PROTECTED] wrote: On Dec 3, 2007 6:23 AM, STenyaK (Bruno Gonzalez) wrote: I'm not sure what FDM means, couldnt' find a good explanation. FDM is the acronym we use for flight dynamics model. Conceptually, a physics engine engine covers much of the same ground. If I were to get really nitpicky, perhaps I could say that the flight dynamics model contains a physics engine + additional speciallized code to model the dynamics of flight. Ok, it's what i thought. Personally, i call physics engine to everything that models real world physics, no matter if they have to deal with air, water, terrain, outter space or whatever. But I'm not interested in the naming each community gives to it, just in its meaning :-) So far in the flightgear project we have not addressed aircraft/vehicles affecting each other. Our philosophy is that we are modeling a friendly airspace so collisions with other aircraft should never ... at least for those that take their simming seriously and start somewhere other than the default location. It would be interesting to model turbulence affects from one aircraft/vehicle onto another, but to do this in a generic and physically correct way, might be far beyond the scope of what we can accomplish with finite compute power. Maybe we could build in some interesting heuristics/hacks though that could be fun. In the world of aviation we have wake turbulence, formation flying (and air to air refueling, aero towing, etc.) In the world of racesims, car-to-car collisions are pretty important and common, as is car-to-track collision (both driving surface, walls, tire piles, sand, cones, etc). I'm not a physics expert, in fact i'm crap at maths and physics (compared to many people), so it's not my intention to even try to merge 2 physics engines together, when i can barely create one of them myself :-) By merging, i mean the mentioned idea of allowing a car to tow a plane, each of which would have its own FDM. My intention is to provide a good framework where knowledgeable people can contribute code to. That has been the case of several university students, one of which added drivetrain physics to the old version of Motorsport. Another one coded genetic-evolutive AI that drived around tracks. Also i've been approached by people working for the DARPA Challenge, in order to use Motorsport for the last urban challenge project. I'm good at computers and programming, so that's what i try to contribute with. For example, P2P distribution of contents, streaming of gEarth or WorldWind or FlightGear terrain data... Well, the kind of things that i know how to code. The FlightGear FDM interface was originally designed so it is relatively straight forward to drop in another physics engine. (sorry to mix terms there.) :-) Good, since the Motorsport remake is also planned to be easy to drop into other games/programs/simulators. I've always thought it would be fun to wind through an interesting mountain region for a hundred miles or so of realistic roadway with real terrain, etc. The driving sims I've seen have either stuck with specific race tracks or very small areas with lots of detail, or larger areas with very sparse detail. Algorithmically it would be possible to create large areas with pretty nice detail. I've been dabbling in some of that recently, but it's really hard stuff. Intersections are hard to deal with, the complexity and polygon count of detailed roadways are hard to handle, and creating realistic surfaces from noisy SRTM data is also a difficult thing to do. But there are some tantalizing ideas that wouldn't be all that hard. If you added some attributes to your road data base, you could start dropping in things like mile markers, street lights, other regularly spaced signs, mail boxes, guard rails, jerzey barrier. My problem is that I have way more good ideas than I have time. Well at least I think they are good ideas. :-) The problem is that heaps of detail are needed in order to make it enjoyable or realistic. The air is reasonably constant, so if i'm not mistaken, there's not much need to model differences in pressures or temperatures or things like that. Plus you have 6 degrees of freedom to play with. In the case of cars, you're limited to following a road (with the occasional jumps, which are interesting if taking gyroscopic effects into account), and so the driving surface needs good detail or it'll be boring to drive. Potholes, camber, different leves of adherence in different places, materials, weather conditions, temperatures, etc. I've also thought about automatic generation of roads (i implemented a 4D-Stunts track loader in the old Motorsport as a first approach), but there's still a long way to go before any result is good enough. I'll only concentrate on allowing data streaming for now, procedural roads will still wait for some years (unless someone steps in and codes it sooner, of course).
Re: [Flightgear-devel] Fi-156 Storch
On jeu 2 août 2007, Ron Jensen wrote: Been working on the stork, so I updated my safety copy. - Added a rattling chain sound to the flap movement. - Started detailing nose area There's some quicky screen caps here, too: http://www.jentronics.com/fgfs/storch-001.jpg http://www.jentronics.com/fgfs/storch-002.jpg http://www.jentronics.com/fgfs/storch-003.jpg http://www.jentronics.com/fgfs/storch-004.jpg http://www.jentronics.com/fgfs/storch-005.jpg Todo list: - Finish nose/engine area - Greebles for exterior (rudder/elevator hinges etc.) - Texture map - More greebles for exterior (flap/aileron hinges) - Struts and braces - Exterior lighting - Cockpit framing - Switch box for lights etc - Clean up some instruments (notably fuel management) -- Make tank selector actually do something! - Throttle/Mixture lever Ron http://www.jentronics.com/fgfs/Storch.tgz Hello, Is it any explanation we don't have it in CVS ? Regards -- Gérard http://pagesperso-orange.fr/GRTux/ Less i work, better i go - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] dual head problem
Hi all I tryed to run flightgear cvs-OSG using two displays, running two X instances (different resolution) and when I start flightgear in a terminal on the second display, it always start on the fist one. The 0.9.10 version worked fine for this. is this a bug or there's something to do before compiling? debian SID, amd2800+, geforce 6200 jano. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] dual head problem
Hi, did you run configure with--enable-osgviewer ? JW jean pellotier wrote: Hi all I tryed to run flightgear cvs-OSG using two displays, running two X instances (different resolution) and when I start flightgear in a terminal on the second display, it always start on the fist one. The 0.9.10 version worked fine for this. is this a bug or there's something to do before compiling? debian SID, amd2800+, geforce 6200 jano. - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] A new keyboard layout.
Hi All, I would propose keyboard layout be a selectable option, standard, left-hand, right-hand and custom. The choice would be user selectable. --keyboard=standard, --keyboard=left-hand, --keyboard=right-hand --keyboard=name-of-custom-keyboard The standard keyboard would be the keyboard now used by FlightGear. Over time this keyboard would be diminished and removed from FlightGear. The left-hand keyboard would be for people that fly with a joystick, mouse or other input device with their right hand and keyboard with their left hand. Assign keys used for flying to the left handed keys, flaps, gear, view functions, thing like that. Assign other functions to the right handed keys, carrier catapult functions, opening and closing canopies, ect. Leave a few of the left handed keys unassigned for user by aircraft modelers. As an example if the t/T keys were unassigned tilt rotor aircraft could use t/T for tilting the rotors and glider towing aircraft could use t/T to attach and release the tow line. The right-hand keyboard would be the mirror image of the left-hand keyboard for people that use a joystick with the left hand and keyboard with the right hand. Possible uses of custom keyboards, ATC, Flight Instructor, people that adapt FlightGear for other uses. --keyboard=ATC, --keyboard=instructor --keyboard=submarine The left-hand and right-hand keyboards would be maintained by FlightGear developers. Custom keyboards would be maintained by the people interested in using them. Best Regards, Paul B - Get easy, one-click access to your favorites. Make Yahoo! your homepage.- SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Fi-156 Storch
On Mon, 2007-12-03 at 19:09 +0100, gerard robin wrote: On jeu 2 août 2007, Ron Jensen wrote: Been working on the stork, so I updated my safety copy. - Added a rattling chain sound to the flap movement. - Started detailing nose area There's some quicky screen caps here, too: http://www.jentronics.com/fgfs/storch-001.jpg http://www.jentronics.com/fgfs/storch-002.jpg http://www.jentronics.com/fgfs/storch-003.jpg http://www.jentronics.com/fgfs/storch-004.jpg http://www.jentronics.com/fgfs/storch-005.jpg Todo list: - Finish nose/engine area - Greebles for exterior (rudder/elevator hinges etc.) - Texture map - More greebles for exterior (flap/aileron hinges) - Struts and braces - Exterior lighting - Cockpit framing - Switch box for lights etc - Clean up some instruments (notably fuel management) -- Make tank selector actually do something! - Throttle/Mixture lever Ron http://www.jentronics.com/fgfs/Storch.tgz Hello, Is it any explanation we don't have it in CVS ? Regards I haven't made much time lately for this project... If someone with write access would like to put this aircraft into CVS, they have my permission. I'm been meaning to have it put in... Ron Jensen - SF.Net email is sponsored by: The Future of Linux Business White Paper from Novell. From the desktop to the data center, Linux is going mainstream. Let it simplify your IT future. http://altfarm.mediaplex.com/ad/ck/8857-50307-18918-4 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] X-52 Pro joystick configuration
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 I have made a joystick config for Saitek X52 Pro: the axis numbers and button numbers differ from the normal X52. This is an early version, I expect it to change as I find what is useful and what isn't. If someone want to put it in CVS, the file is attached. Regards, AnMaster -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) iD8DBQFHVQWdWmK6ng/aMNkRCsP8AKC1MOvJNtEvUfphX8ABtF47eVsY9wCgoljQ tynBvGtatKqQ/8cJaFOhmtE= =SDTP -END PGP SIGNATURE- ?xml version=1.0? !-- Based on X52.xml and Aviator.xml Modified by Arvid Norlander; 2007-12-03 This file is released under the GPL license. -- !-- Common Axis/Buttons + Roll/Pitch/Throttle/Rudder: As There are + Top stick hat: Airelon / Elevator trim + Bottom stick hat:View directions (Increase/Decrease visibility Zoom In/Out when shifted) + Throttle foreside hat: Up/down: View cycles (Shift: flaps up/down). Left/right: Rudder trim + Throttle slider: Boost Control (if available) + Tirgger: Apply all brakes + Fire button: Toggle parking brake + Stick button A:Gear up (Shift: gear down) + Stick button B:HUD master switch + Stick button C:Reset view (hackish) (shift: Toggle speedbrake) + Pinkie button: Shift switch + Throttle button D: Right brake + Throttle button E: Left brake + Throttle button i: PTT (Push to talk, for fgcom) + Throttle mouse button: Start Selected Engine(s) + T1/T2: Hook up/down (Increase/Decrease spoilers when shifted) + T3/T4: Increase/Decrease slats + T5/T6: Increase/Decrease Speedbrake (Increase/Decrease magneto when shifted) Mode 1: Propeller Aircraft + Top rotary dial: Mixture + Bottom rotary dial: Prop Advance + Throttle mouse button: Start Selected Engine(s) Mode 2: Jet Aircraft + Top rotary dial: Carb Heat Mode 3: Not implemented yet Linux Axis Numbers (no idea about window/mac ones, and they are not same as plain X52 axis numbers on linux at least): 0 Roll (positive == right) 1 Pitch (positive == down/back/nose-up) 2 Throttle (positive == back/down/idle) 3 Bottom rotary dial on the throttle (positive == CW) 4 Top rotary dial on the throttle (positive == CCW) 5 Rocker switch (rudder control) on the throttle (positive == right) 6 Slider on the throttle (positive == forward) 7 Lower right hat horizontal axis (positive == right) 8 Lower right hat vertical axis (positive == down (Mac positive is UP)) 9 Mouse Y (positive = up) 10Mouse X (positive = right) Button Numbers (Probably identical b/w Linux/Windows/Mac): 0 Trigger (half pressed) 1 Stick top Fire switch 2 Stick top A switch 3 Stick top B switch 4 Stick top C switch 5 Stick pinkie switch 6 Throttle D switch 7 Throttle E switch 8 T1 9 T2 10 T3 11 T4 12 T5 13 T6 15 Throttle mouse switch 16 Throttle forefinger wheel scroll down 17 Throttle forefinger wheel scroll up 18 Throttle forefinger wheel click 19 Upper left hat in up position 20 Upper left hat in right position 21 Upper left hat in down position 22 Upper left hat in left position 23 Throttle forefinger hat in up/back position 24 Throttle forefinger hat in right position 25 Throttle forefinger hat in down/forward position 26 Throttle forefinger hat in left position 27 Mode 1 28 Mode 2 29 Mode 3 30 Throttle i switch 31 Function wheel (below MFD) click (don't use, it is for timer) 32 START/STOP (don't use, for features in joystick itself) 33 RESET (don't use, for features in joystick itself) 34 Function wheel (below MFD) up 35 Function wheel (below MFD) down 36 MFD-select wheel below MFD up 37 MFD-select wheel below MFD down 38 MFD-select wheel below MFD click $Id: $ -- PropertyList nameSaitek X52 Pro Flight Control System/name nameSaitek Saitek X52 Pro Flight Control System/name !-- No idea if there are more names for it, mine matches the last entry here. -- !-- Custom section for storing some properties, based on Aviator.xml -- data modifier type=boolfalse/modifier mode type=int0/mode /data nasal script ![CDATA[ var self = cmdarg().getParent(); var data = self.getNode(data); var modifier = data.getNode(modifier); var mode = data.getNode(mode); ]] /script /nasal axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/flight/aileron/property squared type=booltrue/squared /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/flight/elevator/property factor type=double-1.0/factor squared type=booltrue/squared /binding /axis !-- Axis 2 is assigned for Rudder on Mac OS X -- axis n=5 descRudder/desc
