[Flightgear-devel] Re: [Terragear-devel] WGS84 offset
Hamish wrote: You might try re-projecting your data with PROJ.4's cs2cs program from www.remotesensing.org (although that site seems to be down right now), GDAL, /or a GIS like GRASS. ftp://ftp.ihg.uni-duisburg.de/GIS/PostGIS/proj-4.4.8.tar.gz 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
RE: [Flightgear-devel] Re: [Terragear-devel] WGS84 offset
Martin Spott writes: Hamish wrote: You might try re-projecting your data with PROJ.4's cs2cs program from www.remotesensing.org (although that site seems to be down right now), GDAL, /or a GIS like GRASS. ftp://ftp.ihg.uni-duisburg.de/GIS/PostGIS/proj-4.4.8.tar.gz proj is what you want to use for 'point' projections but if you are trying to reproject a raster you would be happier using something designed to project rasters I suggest you try gdalwarp which uses the proj4 library as does Grass for that matter GDAL, Proj4 and many other tools available @ http://maptools.org/ FYI RemoteSensing.org is in the process of an IP change and is offline temporarily while the switch is being made. HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Terragear-devel] WGS84 offset
David Megginson wrote: [...] Airports should be pretty accurate, though there are still some problems. The GSHHS shoreline data for inland bodies of water is pretty bad: it is more than 1km off in the Great Lakes for Canada and the U.S. (so waterfront airports are either floating out in the lake or far inland), but the other hand, vmap0, while less detailed, is pretty-much bang-on. However, Norm has pointed out that vmap0 can be way off on the *ocean* coastline data, while GSHHS is usually accurate. Does this mean to get the best out of the available sources you need SRTM data for the elevation and land cover, VMAP0 for inland water (lakes and rivers) and GSHHS for the ocean shoreline ? Anything else ? Merging these sources sounds like a 'funny' game 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
[Flightgear-devel] [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
I get regularly hangs in FGTileLoader::LoaderThread. fgfs doesn't update the screen then and plays the same monotonous sounds. Even after waiting for some minutes fgfs doesn't recover. When I interrupt it in gdb and ask for the bt, I get this: (gdb) bt #0 0x4005ab94 in __pthread_sigsuspend () from /lib/i686/libpthread.so.0 #1 0x4005a9d8 in __pthread_wait_for_restart_signal () from /lib/i686/libpthread.so.0 #2 0x40056e90 in [EMAIL PROTECTED] () from /lib/i686/libpthread.so.0 #3 0x082d18ac in SGPthreadCond::wait(SGMutex) (this=0x8ed3d0c, [EMAIL PROTECTED]) at SGThread.hxx:326 #4 0x082d1a64 in SGBlockingQueueFGTileEntry*::pop() (this=0x8ed3cc8) at SGQueue.hxx:215 #5 0x082d14db in FGTileLoader::LoaderThread::run() (this=0x8ed3d98) at FGTileLoader.cxx:172 #6 0x083d9e22 in start_handler (arg=0x8ed3d98) at SGThread.cxx:23 #7 0x40057f60 in pthread_start_thread () from /lib/i686/libpthread.so.0 #8 0x400580fe in pthread_start_thread_event () from /lib/i686/libpthread.so.0 #9 0x4063b327 in clone () from /lib/i686/libc.so.6 It isn't reproducible, but seems to happen more often with the c172p and never with the bo105 (for whatever reason). I'll try to add some clever debug messages, but being an absolute thread newbie I can't guarantee for success. ;-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Terragear-devel] WGS84 offset
Martin Spott wrote: Does this mean to get the best out of the available sources you need SRTM data for the elevation and land cover, VMAP0 for inland water (lakes and rivers) and GSHHS for the ocean shoreline ? Anything else ? Merging these sources sounds like a 'funny' game Funny in the sarcastic way. This is actually an extremely difficult problem, because vmap0 and GSHHS have some overlap, and eventually, they have to join up: for example, at a certain point the Hudson River stops being part of the ocean shoreline and starts being inland water--it would be a very bad thing if the river stopped, jumped 500m to the east, then started again. vmap0 is not internally consistent anyway, but things get even worse when you try to combine vmap0 roads and railroads with GSHHS coastlines: you'll find roads that are supposed to hug the coast jumping out into the middle of a lake or ocean even more often. What we really need to do, as Norm has often suggested, is load all of this data into a single GIS with a nice graphical interface and start working on reconciling it: for example, we can pick the best coastline between GSHHS, vmap0, and vmap1 (where available), use the higher-resolution US road data combined with the lower-resolution vmap0 road data for the rest of the world, tweak roads to go around airports and follow coastlines, etc. etc. That's obviously a big job, and it probably shouldn't be limited to FlightGear. I think that there are already the equivalent of open source GIS projects working on this kind of thing, but I don't know how far they've come in practical terms. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Jon Stockill wrote: I've not had chance to look at the runways file yet, but are the taxiways automatically generated if none are available in the file? It seems there's a generic parallel taxiways with exit points at both ends and the centre added to all the runways. If it's automatic, I'll ignore it, if it's been added to the runways file then I can provide a few corrections. It's automatic, but it is done by Robin for airports that don't have specific taxiways as he builds the data file. The terrain seems far better than the scenery I've been generating - and is presumably from the same source data - this may be due to the chopping of long polys - I'm compiling a current terragear checkout now to see if that's what makes the difference - if not I'll be after your settings for terrafit/arrayfit :-) Make sure the tools aren't finding a lower res data set before the higher res set ... The code that places the windsocks seems to occasionally leave them floating a few feet off the ground, although most seem fine. Is the code used for placing them only suitable for use within the airfield boundary, or could it be used for placing static objects too? Right now it just places them in airport environments ... the floating wind socks are on my todo list to fix ... Amazing effort Curt - this makes the old scenery look positively prehistoric. Thanks, I've got most of the northern hemisphere done now and am starting on the southern hemisphere. 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
Re: [Flightgear-devel] [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
Melchior FRANZ wrote: I get regularly hangs in FGTileLoader::LoaderThread. fgfs doesn't update the screen then and plays the same monotonous sounds. Even after waiting for some minutes fgfs doesn't recover. When I interrupt it in gdb and ask for the bt, The only time when I know this happens is with the real-weather-fetch option enabled and the METAR site is unreachable. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: It's automatic, but it is done by Robin for airports that don't have specific taxiways as he builds the data file. OK, so it'll be overwritten as updates are committed. Make sure the tools aren't finding a lower res data set before the higher res set ... Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. Right now it just places them in airport environments ... the floating wind socks are on my todo list to fix ... I managed to track it down in genapts eventually - it seems to use the airfield surface it generates, so I guess it wouldn't be easy to generalise for placing scenery objects. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
Erik Hofman wrote: Melchior FRANZ wrote: I get regularly hangs in FGTileLoader::LoaderThread. fgfs doesn't update the screen then and plays the same monotonous sounds. Even after waiting for some minutes fgfs doesn't recover. When I interrupt it in gdb and ask for the bt, The only time when I know this happens is with the real-weather-fetch option enabled and the METAR site is unreachable. I've seen pauses of a few seconds, then the weather updates and everything starts moving again. Is it time for a weather thread? -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
* Erik Hofman -- Tuesday 01 June 2004 18:17: Melchior FRANZ wrote: I get regularly hangs in FGTileLoader::LoaderThread. fgfs doesn't update the screen then and plays the same monotonous sounds. Even after waiting for some minutes fgfs doesn't recover. When I interrupt it in gdb and ask for the bt, The only time when I know this happens is with the real-weather-fetch option enabled and the METAR site is unreachable. Not in my case, because I've had that feature turned off for a week. (Didn't want to annoy noaa.gov too much, because I restarted fgfs very often for bo adjustments.) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
* Jon Stockill -- Tuesday 01 June 2004 18:50: I've seen pauses of a few seconds, then the weather updates and everything starts moving again. Is it time for a weather thread? Yes, it's time for a weather thread. That's why we have one since ages. (see Environment/environment_ctrl.cxx :-) m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [BUG] fgfs hangs forever in FGTileLoader::LoaderThread
Melchior FRANZ wrote: * Jon Stockill -- Tuesday 01 June 2004 18:50: I've seen pauses of a few seconds, then the weather updates and everything starts moving again. Is it time for a weather thread? Yes, it's time for a weather thread. That's why we have one since ages. (see Environment/environment_ctrl.cxx :-) I forget the details, but I don't think the initial call to the noaa is done inside the thread so you still can have possibly long pauses if the site is down or no data is available for the stations in your immediate vicinity. 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
Re: [Flightgear-devel] Next scenery rebuild.
Jon Stockill wrote: Make sure the tools aren't finding a lower res data set before the higher res set ... Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set - SRTM data doesn't cover the entire earth ... They never flew past +/- 6x degrees latitude (where x is a number I don't recall ... greater than 0 but less than 9.) - SRTM isn't released yet for australia. I'd think that most poeple could chuck the lower res data for which they have good SRTM coverage though ... I managed to track it down in genapts eventually - it seems to use the airfield surface it generates, so I guess it wouldn't be easy to generalise for placing scenery objects. Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. 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
Re: [Flightgear-devel] Next scenery rebuild.
Roger Andreassen wrote: Sorry to barge in, I have to strange ones: ENDU and ENNK. Has the above mention something to do with these? A big part of the problem with these is that the underlying DEM data is probably not very good for these areas. There is a lot of elevation change in the terrain data over the surface of the airport and that is hard to deal with cleanly. Also, mix in that we flatten oceans and do a bit of massaging of river elevations to try to avoid them running up and down hills. This sometimes mixes badly if a river or stream incorrectly runs through the airport area due to lack of precision in the stream data. I'd like to handle these cases better in the future, but it will take some work and some thought. Again, I'm being selfish by keeping it domestic: I miss Bodø and Svalbard (Longyearbyen), ENBD and ENSB respectively. Is an airport gone in Robin's database does it mean there's no chance to output the scenery? If these are incorrectly missing in his database (especially if they previouisly existed) then please email Robin. He should be due for another data release soon, although I don't know how his own schedule or time constraints are these days. If it's in early stages I'd like to air ideas as they pop up. Thanks for the time and effort put into this, just *wow*. Feel free, ideas are easy. I can always ignore the one's I don't like. :-) Does anyone know how this compares to MS Flightsim's scenery? I know that for the Norwegian fjords they have to build stairs near mountains, that means in the bottom of a fjord the sealevel was at 300 ft in the old days (gone days). I know FlighGear is different but just how different, to a non-geek like me. :-) We force oceans to be zero elevation and make the surrounding scenery fit. This usually works pretty well with few artifacts. For what it's worth, the new high quality 3-arcsec SRTM data covers the southern part of norway, but not the northern part. I'm not sure where the cut off is, but there was a limit in how far north the shuttle orbit took them. 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
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. That's why I didn't want to do it at load time, but at generation time - maybe generate the scenery, then have a master list of object positions and model names which can then be added to the appropriate stg files. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Jon Stockill wrote: Curtis L. Olson wrote: Right, there are some difficult issues for placing objects at scenery load time that would need to be addressed. I've got a couple ideas, but I haven't had a chance to start playing with them. That's why I didn't want to do it at load time, but at generation time - maybe generate the scenery, then have a master list of object positions and model names which can then be added to the appropriate stg files. Here's something I think would be handy: Build some offline tool that could load a couple thousand (lat, lon) pairs, then return a list of flightgear scenery elevations for all those points. It would have to traverse the input list of points and load the corresponding scenery tiles and do the ground intersection. Probably some attention should be paid to minimizing tile loads. I haven't sat down to do something like this, but I could get some mileage out of such a tool if it existed. It still would be really nice though to be able to place objects at ground level at load time too. 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
Re: [Flightgear-devel] Next scenery rebuild.
Josh Babcock wrote: I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set While 2 and 3 sound like very good points, does it make more sense for 1 to use the high res data but process it so that the end result is small? That way you could still exceed the lower resolution for really bumpy parts of the world, and still have great big polys for the majority of the world, which is basically flat. In other words, you can always reduce a data set, but usually you can't increase it. Also, though I haven't worked with TerraGear, I suspect that for a given size of desired output it would produce higher quality scenery as the size of the input data set grows. Is this the case? I ask this not as a criticism, but because I'm curious. You make a good point. I think in the end the answer of which data sets to use (or which data sets could potentially be used) depends on the priorities of the scenery builder and their target application. 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
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Is there any reason to keep the old data around now? If it's not used by anything I'll free some space up. I could think of a couple reasons, but they may not apply to you ... - one day we might want a low res/light weight scenery set We could still build that from the higher-resolution set by sampling. - SRTM data doesn't cover the entire earth ... They never flew past +/- 6x degrees latitude (where x is a number I don't recall ... greater than 0 but less than 9.) - SRTM isn't released yet for australia. Here are the details: http://www2.jpl.nasa.gov/srtm/coverage.html These are good reasons, but they suggest keeping around the older DEM stuff only where SRTM isn't available. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL question
David Luff wrote: On a related note, I believe you had problems with hearing the ATIS voice due to low volume previously. Do you still have this problem post-OpenAL, or can you hear it OK now? I cannot hear the voice at all now, unfortunately. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL question
Curtis L. Olson wrote: It sounds ok to me here on my sound blaster live hardware. Can you hear the morse code beeps, marker beacons, or other sounds ok? Do some aircraft sound ok, or do all of them sound this way? The ident codes sound strange also (high-pitched and slow). All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Here's something I think would be handy: Build some offline tool that could load a couple thousand (lat, lon) pairs, then return a list of flightgear scenery elevations for all those points. It would have to traverse the input list of points and load the corresponding scenery tiles and do the ground intersection. Probably some attention should be paid to minimizing tile loads. That's pretty much what I had in mind - something like calc-tile.pl, but with the ability to retrieve the scenery and find the ground elevation. Unfortunately I'm a sysadmin who likes playing with geodata, not a programmer. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: SNIP It still would be really nice though to be able to place objects at ground level at load time too. Regards, Curt. When this happens, it would be nice to see some cycles dedicated to the problem of slope. A ranch house looks pretty silly hanging out on a 30 deg slope with its foundation exposed. On the other hand, I have seen many buildings in the real world that have ground entrances on floors that are 2, 3 or even 4 floors apart vertically. This would require special building models divided into sets as well as data assigned to each model regarding how it should be oriented on the slope. I'm not sure how this applies to the great guyed antennas up on the hill by KSFO, but they also exhibit a similar problem. It is also worth thinking about this if anyone ever decides to models a set of generic bridges that can be automatically placed. tangent Speaking of which, imagine the following. First, a DB with all the known antenna locations and heights in it. For giggles, let's generate a data set of bridges from our scenery data, and if it's available, dump some pre-existing data-set of water towers in there. Make some sweepingly broad generalizations about what these objects would look like based on their country of residence and assign those values as a base case. Now build a web interface that lets joe FGFS pilot and expert on his home town go browse and add an entry to any of those objects classifying it as looking like this or that type of bridge/tower/tank in that general color scheme. Joe pilot can also, on the honor system, specify a score of how sure he is about the data he is supplying (guess/pretty sure/it's in my back yard). Advertise it. Build a few dozen simple models of various generic types in said color schemes. Now take all that data and feed it into some process to place the right (ie highest scored) generic object at the right set of coords. A little bit of coding, a DB, a web site and some distributed observation and the FG world becomes a much better approximation of the real one. Of course, it would take a while to reap the benefits, but if it is set up with an eye for longevity it will just become more and more valuable as more people add data. /tangent Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Next scenery rebuild.
Josh Babcock wrote: Curtis L. Olson wrote: Jon Stockill wrote: Curtis L. Olson wrote: SNIP It still would be really nice though to be able to place objects at ground level at load time too. Regards, Curt. When this happens, it would be nice to see some cycles dedicated to the problem of slope. A ranch house looks pretty silly hanging out on a 30 deg slope with its foundation exposed. On the other hand, I have seen many buildings in the real world that have ground entrances on floors that are 2, 3 or even 4 floors apart vertically. This would require special building models divided into sets as well as data assigned to each model regarding how it should be oriented on the slope. I'm not sure how this applies to the great guyed antennas up on the hill by KSFO, but they also exhibit a similar problem. It is also worth thinking about this if anyone ever decides to models a set of generic bridges that can be automatically placed. tangent Speaking of which, imagine the following. First, a DB with all the known antenna locations and heights in it. For giggles, let's generate a data set of bridges from our scenery data, and if it's available, dump some pre-existing data-set of water towers in there. Make some sweepingly broad generalizations about what these objects would look like based on their country of residence and assign those values as a base case. Now build a web interface that lets joe FGFS pilot and expert on his home town go browse and add an entry to any of those objects classifying it as looking like this or that type of bridge/tower/tank in that general color scheme. Joe pilot can also, on the honor system, specify a score of how sure he is about the data he is supplying (guess/pretty sure/it's in my back yard). Advertise it. Build a few dozen simple models of various generic types in said color schemes. Now take all that data and feed it into some process to place the right (ie highest scored) generic object at the right set of coords. A little bit of coding, a DB, a web site and some distributed observation and the FG world becomes a much better approximation of the real one. Of course, it would take a while to reap the benefits, but if it is set up with an eye for longevity it will just become more and more valuable as more people add data. /tangent You'll find plenty of suitable data in VMAP0. I've tried adding power lines to scenery (well, the pylons, not the wires, although I suspect modeling those would keep the helicopter pilots on their toes) and it really does make a difference - makes navigation easier for a start - you can just follow the pylons all the way to the power station. Adding these things currently involves an awful lot of work though. FGSD provides one solution, but seems to like to segfault on my local scenery, so it's not really an option here. I'm perfectly happy to generate this kind of data - I'd just like to know it's going to be some use before I start. -- Jon Stockill [EMAIL PROTECTED] ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Next scenery rebuild.
* Jon Stockill -- Tuesday 01 June 2004 21:25: I've tried adding power lines to scenery (well, the pylons, not the wires, although I suspect modeling those would keep the helicopter pilots on their toes) [...] Bah! Wire cutters are on my TODO list. :-P m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spoiler control
On Monday 31 May 2004 17:13, Andy Ross wrote: Lee Elliott wrote: The problem with using spoilers for roll control in YASim is that because the spoiler range is clamped to 0 to +1, when you 'split' the input for differential control it only works on one side of the a/c - through the 0 to +1 range - to get it to work on the other side it needs a -1 to 0 range but it can't do it, or at least it couldn't when I last tried. That was on the YF-23, and I was trying to use the flaps differentially, instead of the spoilers, but I think the same thing applies (the YF-23 used the ailerons and flaps in opposition for speed-braking and could deploy them on one side only for manuevering). I'm not sure I understand the problem here. Control mappings are allowed to cover any arbitrary output range, with clamping. If you specify a src0/src1 that doesn't cover the whole input range, values below/above the range you specify will be clamped to the appropriate dst0/dst1 value. Can you post what you were trying to use? Andy I no longer have the files where I was trying to do it so I just quickly tried binding the aileron control input to the flaps and got a different result to what I was expecting. As I remember it, when I tried to do this before the left (I think) flap would operate as normal through it's +ve range but not through the -ve range i.e. it wouldn't rotate up, and the right flap wouldn't move at all - this was with split=true on the control-input. When I just tried it now, both flaps moved through the full -ve to +ve range, but both moved in the same direction and the split tag seemed to be ignored. I'm confused now:) LeeE ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
