Re: [Flightgear-devel] (no subject)
On 08/05/2013 03:45 AM, Михаил Сойтанен wrote: > I will send data about Russian VOR's to Robin, because > I have found, that variations are outdated. That's good ... but it would be even better to figure out how to get /systematic/ updates from reliable sources, now and in the future. Is there perhaps a Russian government web site that has this information? Also note that in addition to VOR alignment data, there is a need for other types of navaids and other details, including frequencies, ident codes, et cetera ... as well as the addition and deletion of entire navaids. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] (no subject)
On 08/05/2013 01:38 AM, Михаил Сойтанен wrote: > In nav.dat file VORs have slave variation. As > I understand, slave variation of VOR depends on magnetic variation at he > location. Does Flightgear use this slave variation, or it computes magnetic > variation "on the fly"? > Do we need to track magnetic variation change every year and manually edit > nav.dat for it? Executive summary: VOR alignment in nav.dat should reflect the VOR alignment as reported in the Airport/Facility Directory ... which is generally *not* the same as the actual local magnetic variation. I would expect Robin's xplane data files to track this properly in most cases, since they are routinely rebuilt from official data. = In the real world, VOR alignment is controlled by whomever owns and operates the VOR. It gets changed only on special occasions. There are three things to consider: a) The path through space of the actual electromagnetic VOR radials; b) The airways as plotted on the charts, typically defined in terms of VOR radials; c) The actual local magnetic variation. For obvious reasons, there needs to be very little discrepancy between (a) and (b). The discrepancy between (c) and (a), or between (c) and (b), is much less tightly controlled. Back in the days before GPS, pilots typically would not notice a discrepancy of this kind, even if it was rather large. If you decide to go looking for such discrepancies, they are easy enough to find, by finding the VOR's alignment (i.e. nominal magnetic variation) as documented in the Airport/Facility Directory and cross-checking it against the current local magnetic variation. As a less-precise version of the same idea, you can look at the orientation of the charted compass rose and compare it against the local magnetic variation. Nowadays, however, it is fairly easy for pilots to detect such a discrepancy, even if they weren't looking for it, by cross-checking a VOR radial against the GPS bearing-to-station. This is a predictable source of confusion for pilots working toward their instrument rating. Changing VOR alignment requires revising the charts, so they don't do it more often than necessary. FAA standards say they are "supposed" to re-align VORs to keep them within 1 degree of the actual magnetic variation, but this effort is chronically underfunded and it is easy to find VORs that are mis-aligned by more than a degree, sometimes quite a bit more. Bottom line: The VOR alignment in nav.dat should track the VOR alignment as documented in the A/FD. It should not track the actual local magnetic variation. -- Get your SQL database under version control now! Version control is standard for application code, but databases havent caught up. So what steps can you take to put your SQL databases under version control? Why should you start doing it? Read more to find out. http://pubads.g.doubleclick.net/gampad/clk?id=49501711&iu=/4140/ostg.clktrk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git help request
On 08/09/2012 07:45 AM, Curtis Olson wrote: > It looks like every time you rebase you have to reapply the same set of > patches over top the target branch. Not true in general. I've never had a problem like that. > So even if I figure out a way through > it once, I'll have to repeat the same conconction of craziness each time I > rebase. Ditto. > It complains about whitespace errors, then falls back to a 3-way merge, > then reports conflicts with all the files in the 2 old directories, If whitespace were the only problem, you could make the problem go away using --no-verify. Also, as others have suggested, when in doubt, doing "git status" is always a good idea. > I think I'm going to create a new branch, untar my changes on top, > lose all my history and forget about it. Creating new branches is cheap and often an excellent idea, especially if you are uncertain about something and want to experiment. > untar my changes on top, > lose all my history and forget about it. It's not possible to be sure exactly what the problem is without further information, but it seems likely that there is a simpler way to get a similar result without losing history, namely: git rebase -Xours or git rebase -s 'recursive -Xours' You can read the manpage and/or google for more information about what these options do. I believe these options require git version 1.7.3 or later. If you need to install a newer git, that's easy and well worthwhile. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
Here's another fun way of mapping airspace: You can get sectional charts in the form of .tif files from: http://www.aeronav.faa.gov/index.asp?xml=aeronav/applications/VFR/chartlist_sect You can then read them into QGIS ... and then overlay them with whatever other information you want, perhaps from apt.dat and nav.dat and/or elsewhere. (Reading the same .tif file into GRASS doesn't work. GRASS tries and fails, with no error or warning messages. The resulting map has no pixels at all, according to d.histogram. So this is another reason to use QGIS.) On 09/21/2011 06:10 PM, J. Holden wrote: > Admittedly I work with GRASS solely on the text-based side - rarely > if ever touching the GUI Roger that. I, too, rely almost exclusively on the command-line interface to GRASS. I occasionally use the GUI to give me hints about what CLI commands I need to use. The stuff I need to do involves so many GRASS commands that I could not possibly remember them all, let alone do them reliably, so I use a script. > I hope I didn't misinterpret what you're writing, and hopefully that > was of some help. You definitely understood the questions (even though I now realize the questions were not entirely clear) ... and you have been very helpful. > 3. You CAN do raster reprojection on the fly. However, your results > won't be anywhere near as "clean" as a vector reprojection as a > result of the different format type. Also, there are some rules - I > believe the projection has to be in the current region of the > location you're reprojecting to, and also the resolution must be > sufficient in order to handle the map. Well, YMMV but I can't get the instance I'm running to do raster reprojection. It tries and fails. I have an example where there are two rasters in the same location, with slightly different projections, plus some vector data. If I switch projections in my "project" workspace, one raster or the other goes to all-white. The "zoom to layer" button zooms to the right place, but the image is still all-white. The vector data stays where it belongs, so that is working. This is a low priority for me, because I am content to reproject all rasters to a common SRS using gdalwarp. That does everything I need it to do. > 1) it's probably easiest to continue to use d.his and > then display the resulting map using the GRASS plugin - QGIS doesn't > really have many (if any?) raster tools, while GRASS was created > primarily to deal with raster features (and added vectors later). That sounds good, but I haven't figured out how to get a map /out/ of d.his. I think of d.his as a display function, not a map-calculation function. I don't know how to find the "resulting map" produced by d.his, not in any useful form anyway. And here is a possibly-related question: what colormap are the Sectional Aeronautical Charts using, and how do I specify it? They show up in QGIS in beautiful natural color. In particular, in QGIS, if I change the colormap on one of those charts, there does not appear to be any way to change it back to the beautiful original colormap. I assume there is some clever colormap that the QGIS backend knows about but the GUI does not. I mention this because I reckon I could solve several interesting problems by using this colormap, using r.mapcalc if necessary to format the pixels. This includes the "drape" operation, which produces very nice-looking results by taking the hue from one layer and the intensity from another. Or maybe somebody can write a r.calc.drape module. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On 09/20/2011 07:08 PM, J. Holden wrote: > This is somewhat off-topic to FlightGear, so I apologize - but I > respond to John Denker: Having looked over what you are trying to do, > I strongly recommend using QGIS with the GRASS plugin. > > Very rarely do I use any of GRASS' built-in visualization programs - > and very rarely do I use any of QGIS' built-in geospatial functions - > but QGIS is the best program I've found to visualize GRASS data at > the moment (with the possible, rare, exception of NVIZ). > > In fact, I believe the whole GRASS d.mon was rewritten as of GRASS 7 > and now works differently (and hopefully better). I think most of the > GRASS display functions were very, very old. Yes, that helps. Thanks for the clue. One nice thing about GRASS is that it is very modular. In particular its backend computational features are independent of its frontend visualization features. The QGIS frontend graphics are orders of magnitude faster than the GRASS frontend graphics. Also QGIS has a feature called "recompute CRS on the fly" that simplifies a lot of things. It's nice to see a little bit of sanity in the world. Here are some questions you might be able to help me with, if you would be so kind. Off-list answers would be fine, although I suspect I'm not the only person who is interested: 1) GRASS has a "drape" feature implemented by d.his that sets the intensity from one raster and the hue from from another, which is a very nice way of combining slope information and elevation information into one image. It's not obvious how to achieve the "drape" effect in QGIS ... with or without involving GRASS. What's the trick? 2) GRASS has a "catlist" feature implemented by d.rast that makes it easy to display only a certain range of values, e.g. everything from 3000 feet on up. This is particularly slick in conjunction with item (1) above. I can always do this with r.mapcalc, but I was wondering if there might be a convenient way to do it on-the-fly. 3) I suspect that doing reprojections on the the fly only works for vector data. I tried it with raster data, expecting to see either a resulting image or an error message, but saw neither. Is there something I'm missing? 4) When defining a colormap, there does not appear to be any way of controlling transparency on a level-by-level basis. Am I overlooking something, or is this an actual limitation? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Mapping Airspace
On 09/19/2011 04:07 PM, HB-GRAL wrote: > To improve our map resources with further data I started an experiment > with free available airspace data. Actually this is far from being a > good map and finished design, it is just a start to implement > (unofficial!) airspace information: > http://maptest.fgx.ch/navaid.html > > I need probably some advice from real pilots around here for what is > useful to map for FlightGear airspace, and how this should be displayed. > I think I am aware of regular ICAO graphics definitions etc. But I dont > want to design well known (and also free available) maps, I just want to > develop a design as a "overview" and some really necessary items i.e. > for learning the basics or whatelse. There is no RFC for what I am doing > here, I am just playing around with data and an new Mapnik Server and > ask for discussion and contribution. > > (Notice, my new signature since I send this links to the list and > elsewhere: Please do not use any of this material for real navigation! > NEVER. Do only use this to help developing and improving the design of > my maps ;-). A few remarks: 1) Real pilots are concerned about airspace, but they are also concerned about terrain and obstructions. Also weather and winds aloft. You don't want to follow the example of Cory Lidle and his instructor. Their flight path was compressed by airspace and they ended up flying into the side of a high-rise apartment building. Violating the airspace would have been a better choice. 2) It is good to provide disclaimers, and people should take those seriously. However: 2a) Pilots are trained to cross-check everything, and never rely on a single source of information. 2b) People *are* going to use whatever maps they can get their hands on -- in conjunction with other information -- to help with real-world flight planning and training. For example, I commonly use FlightGear to familiarize myself with the IFR approach procedures and other details before flying into an unfamiliar airport. Of course I crosscheck the apt.dat description of the airport against satellite photos et cetera. Discrepancies abound, as previously described. 3) Interactive computerized maps offer some treeemendous advantages. For one thing, the ability to turn layers on and off is very powerful. The total amount of detail that is /sometimes/ useful is more than can be shown on any one map. Here's a rough scenario, aka "use case": 1) Turn on airport names (not just 4-letter identifiers) because I have not memorized every identifier in the world. 2) Sketch a rough route. 3) Turn off the names, to declutter the map. 4) Turn on navaids, intersections, and fixes, so as to facilitate defining the route in terms that can be used on an ATC flight plan. 5) Turn off everything but the route and the terrain, to see what sort of obstructions there are. 6) Apply safety margins required by regulations. Apply additional personal margins. 7) Revise the route to get around the worst of the obstructions. 8) Cross-check against the VFR sectional, IFR enroute chart, et cetera. 9) Go back to step 4 and iterate. 10) Turn on weather and winds aloft. *) et cetera. Note that I have a tool that not only highlights the route centerline, but also the /corridor/ extending some distance on either side. For example, a half-width of 4 nm is relevant to FAR 91.177. http://www.av8n.com/fly/grass-intro.htm#fig-colored-fix-pass These tools are painfully difficult to use. The only thing that would be worse would be not having them. Flight planning is relatively easy if you stick to IFR airways, but sometimes in mountainous regions (e.g. Alaska among many others) this can lead to insanely high MEAs (minimum enroute altitudes). As soon as you start planning an off-airways flight, trying to do it just by penciling in lines on a chart is exceedingly laborious and error-prone. So, you have to decide what you want to do. You could go for a map that is merely pretty to look at ... or you could go for a map that is actually useful. One more thing: You don't want to go too far with the disclaimers. Lives are at stake, and /not/ providing information can be just as much of a problem as providing not-quite-perfect information. CFIT i.e. controlled flight into terrain makes a large contribution to the fatal accident rate. Sometimes a contributing factor is compression between airspace or weather above and terrain below ... but sometimes it just comes down to bad planning and really bad luck. Providing something that helps with this would be a Good Thing. Again: It doesn't have to be perfect. Note that the FAA provides (via contractors) a service that will prepare a computerized flight plan for you. There are scenarios where you can file such a flight plan, get cleared "As Filed", and fly it as cleared ... and fly right into the side of a mountain. Hence the need for cr
Re: [Flightgear-devel] various databases +- ground truth ; was: Openstreetmap ...
On 09/16/2011 04:47 AM, HB-GRAL wrote: > I provide a ESRI Shapefile on my server of the airports of > ourairports.com database > http://maptest.fgx.ch/data/ourairports.zip > > There is a column "type", and some airports have value "closed". All > this data is in public domain, if someone wants to play around with it > or want to check something. Thanks, that's interesting. For some purposes, the ESRI files may or not be the most useful or transparent representation; for some purposes it may be more useful to look at http://www.ourairports.com/data/airports.csv http://www.ourairports.com/data/runways.csv http://www.ourairports.com/data/airport-frequencies.csv and other files as described at http://www.ourairports.com/data/ The data from ourairports is in some ways more sophisticated than from apt.dat. For example, it gives the elevation of *each end* of each runway, rather than simply field elevation. In some parts of the world this is valuable information for pilots. AFAICT the ourairports data could be used to provide useful information for airports that are missing from apt.dat ... maybe not ideal but way better than nothing. Somebody could write a script to do the translation ... or we could just read the ourairports files directly. OTOH apt.dat has taxiway information for some airports, whereas I don't know of any such information at ourairports.com. If I have overlooked something, please let me know. FWIW I have a prog that reads apt.dat and writes kml, which can then be imported into your favorite GIS such as GRASS or google-earth. The idea is to make it easy to compare apt.dat to the ground truth. I haven't taught it how to read ourairports databases, but that wouldn't be hard. Here is another way in which the ourairports database can be put to very good use: It provides ISO region codes -- which apt.dat does not. These codes provide the basis for a very good way of predicting which runway numbers will have a leading zero. Compared to guessing "always leading zero" or "never leading zero" this reduces the error rate by at least two orders of magnitude. Doing a join on the two databases is easy. As for the reliability, comparing ourairports to apt.dat on fields that they both provide, it appears we have a Venn diagram with all five possibilities: -- Airports where they are both correct. -- Airports where apt.dat is right and ourairports is wrong. -- Vice versa. -- Airports where they are both wrong in different ways. -- Last but not best, airports where they are both wrong in the same way, so we don't learn anything by cross-checking. For example, there are some airports that were wiped out and replaced with condos many years ago, but still show up in both databases. FWIW here are the fields in some of the ourairports files: Airports: "id","ident","type","name","latitude_deg","longitude_deg","elevation_ft","continent","iso_country","iso_region","municipality","scheduled_service","gps_code","iata_code","local_code","home_link","wikipedia_link","keywords" Runways: "id","airport_ref","airport_ident","length_ft","width_ft","surface","lighted","closed","le_ident","le_latitude_deg","le_longitude_deg","le_elevation_ft","le_head ing_degT","le_displaced_threshold_ft","he_ident","he_latitude_deg","he_longitude_deg","he_elevation_ft","he_heading_degT","he_displaced_threshold_ft", Frequencies: "id","airport_ref","airport_ident","type","description","frequency_mhz" -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
On 09/15/2011 05:15 PM, Martin Fenelon wrote: > I like to think that the positional errors of many (most non US?) > aerodromes are due to mistakes made when changing from one datum to > another. Well, that's not what I think, based on looking at the data. The very first non-US example I looked at was ES03 "Hova" for which the apt.dat position is off by hundreds of meters, to the southeast. Nearby we have ESVF "Frolunda" for which the apt.dat location is off in another direction, and the relationship of its two runways to each other is wrong. It is hard to see how a change in datum could have a different effect on two nearby airports ... and there is just no way it could have a different effect on two runways at the same airport. There aren't that many different datums to play with. > Errors in runway orientation at unmodifed airfields (with > default layouts) appear to be caused by confusion between magnetic and > true bearings, with magnetic being used as true. Uhh, in apt.dat the runway heading for ES03 is off by more than 35 degrees. The local magnetic deviation is more like 4 degrees. Bottom line: Many of the apt.dat entries are just wrong. You don't need any ultra-sophisticated geodetic expertise to understand what is going on. The entries are just wrong. If you want something to be accurate to a few centimeters, or even a few meters, then some expertise is required, but that's not what we're talking about here. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Openstreetmap vs. G**gl
On 09/15/2011 03:08 PM, HB-GRAL wrote: > No, it looks like the mapping with apt.dat data is inaccurate, at least > outside the United States. The following repeats an email I sent quite a while ago, which somehow seems to have gotten lost: On 09/10/2011 03:54 PM, HB-GRAL wrote: > I am just curious why FlightGear and OSM have the same "accurate" > position, and Google map shows another one. > > I am sure, there are different problems, but some enlightenment will be > greatly appreciated here. Many of the entries in apt.dat are wrong. Large errors are particularly prevalent in the entries for small airports that don't have instrument approaches. In some cases google maps makes the same mistakes. I haven't checked whether openstreetmap makes the same mistakes. If so, the obvious explanation is that all three have copied from each other, or from the same defective upstream source. When I say entries in apt.dat are wrong, I am not comparing against one database of features against another, but rather comparing it against satellite photography and shuttle radar terrain mapping ... which are known to be quite accurate. Indeed the accuracy of the imaging is confirmed by the fact that *some* of the apt.dat entries are spot-on, especially for the major airports. On 09/12/2011 12:56 AM, Alan Teeder wrote: >> Point positions of aeronautical navaids and airfields have mostly been well >> surveyed and their positions should therefore be accurate. Well, maybe they "should" be accurate, but in fact many of the entries in apt.dat are not. Some of the errors are quite large. For example, the location of CO80 "USAF ACADEMY BULLSEYE AUX AIRSTRIP" is off by several hundred meters. As another example, the runway heading for 57AZ "La Cholla Airpark" is wrong by more that 20 degrees. Furthermore, the location and runway heading are wrong for 2B3 "PARLIN FLD". If you want a more-or-less endless supply of errors, look at even smaller, private, and/or unpaved airfields. The database also contains a goodly number of entries for airports that ceased to exist many years ago. These errors have got nothing to do with metaphysical questions about the meaning of "where it is". The entries are just wrong. They've been wrong all along. In most cases version 850 has the same errors as version 810. The metaphysical issues are much, much smaller. As it says at ftp://itrf.ensg.ign.fr/pub/itrf/WGS84.TXT >>> In general the ITRS (and its realizations ITRFyy) are identical >>> to WGS84 at one meter level. Similarly, there are still some people who still use NAD83, which is not unreasonable. It agrees with WGS84 within one or two meters in North America ... and the offsets are well known. The apt.dat errors are hge compared to any such offsets. = I have a tool that reads apt.dat and writes kml. Thereupon the kml can be imported into a GIS system such as GRASS or google-earth. This making it easy to compare apt.dat with the satellite and shuttle images. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA http://p.sf.net/sfu/rim-devcon-copy2 ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] JSBSIm, aeromatic, crosswind taxiiing, et cetera
On 06/19/2011 06:46 AM, Jon S. Berndt wrote: > Maybe I've gone wrong somewhere here, but something similar might work. > Also, in situations like a flat spin or tail slide this probably falls > apart! Let's postpone discussion of exotic flight conditions such as flat spins and tail slides. There are much more prosaic situations that need to be addressed. Let's start by getting the aircraft to behave properly when a) _taxiing_ with a crosswind and/or tailwind, and b) _landing_ and _taking off_ with a crosswind and/or tailwind, These seem like basic and fundamental features. As far as I can tell, none of the existing FG aircraft that use the JSBSim FDM behave properly under these conditions. (FWIW the Pitts and the Comanche use YASim). The value of these features can hardly be exaggerated. For example, according to page 4-3 of the POH the "maximum demonstrated crosswind" for a C-172 is 15 knots. It is important for pilots to know what happens if they use soft-field takeoff procedure with a 15-knot crosswind. We do not want them to discover this the hard way, in a real airplane. It would be extremely valuable to have a simulator that faithfully models the real behavior. Et cetera. For more perspective and motivation, see appendix below. Returning to the technical issues: AFAICT the most fundamental issues are not "JSBSim" issues strictly speaking, but rather aeromatic issues. The aeromatic output I have seen is 100% predicated on the assumption of small alpha and small beta. The entire strategy of the aeromatic- based aircraft.xml file is predicated on this. For example: -- The idea that there would be "lift due to alpha" and then some "delta lift due to flap extension" is absurd. Near the stall, extending the flaps (at constant pitch attitude, and constant direction of flight) will make a /negative/ contribution to the lift in the real airplane. -- Forsooth, the whole idea of "lift due to alpha" is absurd, since the lift of the real airplane depends in a nonlinear way on alpha _and beta_. Specifically, for an unswept wing we expect the lift of the wing to go to zero when beta is 90 degrees. Few if any of the existing FG aircraft model this beta-dependence. A faithful model of this would require a major reorganization of the aircraft.xml file AFAICT. Small changes will not suffice. That leads to an other rather fundamental issue: Let's talk about lift. Lift is a vector. It is defined to be perpendicular to the wind, and perpendicular to the Y axis. Axes are defined here: http://www.av8n.com/how/htm/motion.html#fig-axes Specifically, if W is the relative wind velocity (directed toward the airplane, not toward the wind-source) then lift is in the direction W × Y. The component of lift along the W × Y direction is positive, for not-too-large positive alpha. -- Minor point: This can be confusing to non-experts there is a tailwind, since W × Y is downward in that case. -- This is undefined when there is a direct crosswind, since in that case W × Y is zero and does not define a direction. For an unswept wing it doesn't matter, since the magnitude of the lift of the wing is zero ... but for a swept wing this is an utterly nontrivial issue. Remark: Here is an item that is *not* on the list of fundamental issues. I mention it just for perspective. The last time I checked, in all the aeromatic aircraft, the lookup tables for coefficient-of-lift versus alpha were defined over a severely limited domain of alpha values. This is not a fundamental issue, because it is so straightforward to fix. It will of course need to be fixed, but it will be nowhere near sufficient. Constructive suggestion: According to the JSBSim manual, the "wind axis system" (LIFT, DRAG, and SIDElift) is not the only choice; the body axis system (X, Y, and Z) is also supported. Alas, the last time I checked, precisely none of the FG aircraft used the XYZ axis system in their JSBSim configuration (aircraft.xml). I suggest that the first step toward getting an aircraft to behave properly during crosswind taxiing would be to convert to the XYZ axis system. I am quite aware that this conversion requires a large investment per aircraft. However, AFAICT the investment will pay for itself very soon. I for one am not interested in re-arranging the deck chairs on the Titanic, and I am not interested in making minor tweaks on an aircraft.xml file that is mathematically unsound. Another constructive suggestion: While we are reorganizing the aircraft.xml file, we should get rid of the notion of "lift due to alpha" et cetera. I suggest a more faithful model would work with things like "force due to wing" and "force due to elevator". As a first step, compatible with the existing approach, we can treat the wing as a whole. Then, later, as a second step we can model the wing in four parts: port outboard (with aileron), port inboard
Re: [Flightgear-devel] Coordinate conventions
On 03/03/2011 02:16 PM, cas...@mminternet.com wrote: > What are the coordinate conventions used for eye position offsets in 2.0? > > standard right-hand rule or something else? Messing with the camera > offsets and not getting the results expected. OTOH, the documentation on > the subject is VERY old (circa 2002!). Is it still valid? What little I know about it is documented here: http://www.av8n.com/physics/coords.htm See also http://www.jsbsim.org/JSBSimReferenceManual.pdf There are multiple coordinate systems in use, and lots of converting back and forth. -- What You Don't Know About Data Connectivity CAN Hurt You This paper provides an overview of data connectivity, details its effect on application quality, and explores various alternative solutions. http://p.sf.net/sfu/progress-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Sinking feeling - c172 on gravel runway
On 02/10/2011 08:15 AM, Geoff McLane wrote: > Also, it does not happen EVERY time, in each of 3 > machines, 3 OSes... but when I get the situation, it seems > very repeatable... Is there any chance this depends on having a _tailwind_ or something like that? Crosswinds and tailwinds can cause some mighty peculiar behavior: http://code.google.com/p/flightgear-bugs/issues/detail?id=250 -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] "bug" is a three-letter word
It's spelled "ATI" On 01/27/2011 08:01 PM, Csaba Halász wrote: > I am now running the shiny new 11.1 fglrx driver on my integrated HD4200. > The 737-100 has some silly landing lights, but other than that, it looks > normal. I just how upgraded to the 11-1 fglrx driver. Still no runway lights. I would have posted a remark on the bug tracker http://code.google.com/p/flightgear-bugs/issues/detail?id=232 but that doesn't seem to be working at the moment. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Carrier Altitude
On 01/25/2011 12:14 PM, Curtis Olson wrote: > How about having carriers do a terrain height check and follow the polygon > curvature of the FlightGear world? Call it a feature. The real ocean has swells. They make carrier flight operations considerably more interesting. -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New airport textures
On 01/20/2011 07:14 PM, Ryan M wrote: > For the past week I have been working on improved airport taxiway and > grass textures. They've gotten positive feedback on the forums but Gijs > suggested I post about them on the core mailing list for a fair > discussion. > > Here are some screenshots of the textures in-sim: > http://i54.tinypic.com/29povms.jpg > > http://i56.tinypic.com/14tmrp.jpg The screenshots look very nice. If you want to have a serious discussion, perhaps you could start the ball rolling by saying a few words about: *) What sort of approach / strategy / algorithm was used to generate these images? *) What do you see as the advantages and disadvantages of this approach? *) Have you solved (or avoided) the various potential problems listed by Curt (01/18/2011 09:26 AM)? *) Does this do something sensible with the "runway polygon" information introduced into the "new" (2008) apt.dat? Thanks! -- Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! Finally, a world-class log management solution at an even better price-free! Download using promo code Free_Logger_4_Dev2Dev. Offer expires February 28th, so secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsight-sfd2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] modern X-Plane airport format; Was: Magnetic North
Do we know how X-Plane itself deals with the "runway polygons"? The very existence of such things in the apt.dat file suggests that "some" sort of solution is possible. Perhaps some experimenting with a X-Plane and a hacked-up copy of apt.dat would tell the tale. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Magnetic North
On 01/16/2011 02:23 PM, Martin Spott wrote: > John Denker wrote: > >> FG is still using airport data that hasn't been updated since 2008. > > Depends on your particular definition of "FG". To be precise, the file > at: > > http://mapserver.flightgear.org/apt.dat.gz [1] > > contains 213 airfield updates (currently) which have been merged over > the time That leads to a few follow-up questions: a) What *do* we mean by FG? Perhaps we should ask: What do the folks in the user community think FG is? What fraction of the users are using the file [1] mentioned above, as opposed to the version that sits in the fgdata tree? b) Is that version strictly more up-to-date than the fgdata version? If so, wouldn't it be a good idea to upgrade the fgdata version? c) Doesn't 213 seem like a small number compared to the thousands of updates that have been applied to Robin's apt.dat since FG forked it in 2008? -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Magnetic North
On 01/16/2011 01:25 PM, Barry Fawthrop wrote: > There was a news article on Magnetic North Change > and How KTPA had to change from 90 to 80 > > Are these changes being effected into FlightGear ??? No. FG is still using airport data that hasn't been updated since 2008. More than a few things have changed since 2008. -- Protect Your Site and Customers from Malware Attacks Learn about various malware tactics and how to avoid them. Understand malware threats, the impact they can have on your business, and how you can protect your company and customers by using code signing. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Scenemodels ground elevation update
On 01/10/2011 08:26 AM, Curtis Olson wrote: > often, important tall objects > have a known absolute height ... like a radio tower in an FAA database. For > these objects it would be better to keep them at a fixed absolute height > rather than float them up or down with different revisions of the terrain. This feature is a Good Thing and is well worth preserving. > Originally when I populated the world with all the FAA database objects I > had the absolute heights in an external database and used that to compute > the placement in the .stg files. Is the original data still available? Is more-current data available? As always, it is nicer to track the authoritative data, rather than forking it. -- Gaining the trust of online customers is vital for the success of any company that requires sensitive data to be transmitted over the Web. Learn how to best implement a security strategy that keeps consumers' information secure and instills the confidence they need to proceed with transactions. http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS upgrades
On 01/04/2011 05:51 PM, Dave L wrote: > I've reverted to the previous behaviour for that property, which means that > inches are used globally by default, and if the user sets that property then > millibars are used everywhere except US and Canada. I realise that that > means that the incorrect units are used in most countries by default, > whereas your code used the correct units in most countries by default, but > as far as I can tell FG's altimeter setting dialog and most (all?) of the > knollsman windows only have inches, regardless of worldwide location of the > airplane, so I didn't want to upset the current behaviour so close to a > release. I agree with all that. I apologize for not thinking enough about the compatibility issues. > I'll put it back after the release anyway, to encourage > millibar/hectapascal support :-) How about this for an idea: We define a new property /sim/atc/use-inhg to exist alongside /sim/atc/use-millibars with the following specification: -- You always get the "native" format for your locale. -- You always get the format called for by the properties mentioned above. -- If this means you get *both* the altimeter setting (inHg) *and* the QNH (millibars), so be it. That's a feature. I further suggest that if we make /sim/atc/use-inhg true by default, at least for now, then we can code it this way before the release. There is an upside and no downside. The idea of having ATIS speak *both* formats (when requested) means instrument designers are _able_ to switch without being _required_ to switch, which is the way I like to do things. Or ... does somebody have a better suggestion? -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] git for dummies
On 01/04/2011 10:20 AM, Curtis Olson wrote: > I'm in a situation now where I have local > mods that "git diff" does not report and I'm not sure how to deal with that. > How can I find the differences between my local repository and the master > ... especially those changes that I haven't committed or pushed yet? 1) Try this: git stash pop It should undo the effect of the previous git stash. See below for more on this. 2) I generally don't bother with git stash. 3) Constructive suggestion: Never edit stuff on a branch that is tracking a remote. As a common example, if the local "master" branch is tracking a remote "master" branch, and if you are sitting on the "master" branch, do this git checkout mystuff or if necessary git checkout -b mystuff before editing anything. 4) Constructive suggestion: In the all-too-common situation where you forget what branch you are on and edit stuff on the wrong branch, do this: checkout -m mystuff That will take the edits and merge them into where they belong. In my experience, this is wy better than stashing. 5) I have a fancy "pre-commit hook" that prevents me from accidentally committing something to a branch that shouldn't be modified. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS upgrades
I just now pushed a couple more ATIS upgrades to http://gitorious.org/~jsd/fg/sport-model/commits/atis One of them will, alas, require rebuilding the voice snippet data. http://www.av8n.com/festival/ Mostly this is to improve the "internationalization". -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] further enhanced active-runway selection
I just pushed one more commit to http://gitorious.org/~jsd/fg/sport-model/commits/navaid-repairs This provides IMHO a pleasing combination of simplicity, versatility, consistency, and verisimilitude. The main new feature is to allow the active runway to be chosen to have a crosswind or tailwind. >From the README file: This describes the effect of /environment/runway-wind-skew. Setting this variable affects the choice of runway. This is relevant in three ways: -- It affects the selection of the runway for placement of the aircraft during initialization, assuming an airport has been specified but no specific runway has been specified. (This affects the code in two places, in fg_init.cxx and main.cxx.) -- It affects what ATIS says is the runway-in-use. -- It affects which end of a reversible ILS will be active. The specific effect works like this: Suppose the wind at the airport is coming from the direction WWW, and suppose the value of runway-wind-skew is RWS. Then we /pretend/ the wind is coming from WWW+RWS and choose the runway accordingly. A value of RWS that is positive (but less than 180) mean the runway will be to the right of the actual wind WWW, which increases the chance that you will have a crosswind from your left when using the chosen runway. Assuming there is some nonzero wind, and the wind doesn't shift: ++ Setting RWS=90 guarantees a crosswind component from the left. ++ Setting RWS=-90 guarantees a crosswind component from the right. ++ Setting RWS=180 guarantees a tailwind component. Some examples: Suppose the airport provides runways 4/22 and 16/34, all of which are similar in length and width. Suppose the actual wind is coming straight out of the north. *) RWS greater than -80 and less than 10 Runway 34, crosswind from the right *) RWS greater than 10 and less than 100 Runway 4, crosswind from the left *) RWS greater than 100 and less than 190 Runway 16, crosswind from the left *) RWS greater than -170 and less than -80 Runway 22, crosswind from the right -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATIS upgrades
Hi -- On 01/02/2011 06:37 PM, you wrote: > Can I just clarify whether you are happy to have your scripts committed to > flightgear/utils in addition to being available from your website? Yes, happy. Public domain, not GPL. > If so, I'll add them ASAP. Thanks! -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ATIS upgrades (was: New release)
On 01/02/2011 09:21 AM, Stuart Buchanan wrote: > - "Romeo" is being pronounced "Romo". Might be a typo in the transcript? It's not a typo, just lousy pronunciation by the synthesizer (festival). Note that if you are worried about typos, you can check for yourself by looking at the property tree http://localhost:5400/instrumentation/comm > http://code.google.com/p/flightgear-bugs/issues/detail?id=241 Some small fixes to the code are at http://gitorious.org/~jsd/fg/sport-model/commits/atis On the data side of things, upgraded .vce and .wav files are at http://www.av8n.com/festival/ > Finally, would it be worth checking the script into flightgear/utils ? In order for things to be truly open, i.e. open in spirit and open in practice (not just GPLed in some legalistic sense), I support making the scripts available. The various scripts for building and testing the ATIS/voice stuff can be found at http://www.av8n.com/festival/ Note that there is a voice.pl script that allows you to test a lot of stuff with relative convenience and flexibility; you don't even need to fire up FG. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] thanks, Tim
> Comment #8 on issue 110 by timoore33: Pick animation do not hilight > transparent objects any more > http://code.google.com/p/flightgear-bugs/issues/detail?id=110 > > fixed with simgear c934b47f2e94fcefb719b9b6186abc4fd8562670 Wow. That helps a lot. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Re-enabling ATCDCL
On 12/27/2010 03:59 PM, Dave L wrote: > The ATIS/AWOS and nearby ATC frequency dialog are all useful, Yes! > and would be a > major regression if not working for the release. Yes indeed! > I can't see any downside to removing the conditional compilation completely > now, but I'll leave it 24 hours to let anyone object. FWIW I have been using the non-default --enable-atcdcl option for a lot more than 24 hours, and I have no objections to making this the default. There are a couple of trivial patches to make compiler warnings go away ... and a few almost-trivial enhancements at http://gitorious.org/~jsd/fg/sport-model/commits/atis ... which has been recently rebased, so it should apply cleanly to the current "next" branch. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ATIS, AWOS, synthesis, runway -in-use, et cetera
On 12/23/2010 04:58 PM, Dave L wrote: > If you can email me the words and script that would be great. It took quite > a long time to index all the words when I did the original recording - this > should be a lot quicker. I put up a little care package at http://www.av8n.com/festival/ The scripts are not very Muggle-friendly ... but they're a lot easier than recording a few thousand snippets by hand. Hint: ATIS_ONLY=yes FG_ROOT=whatever ./list-airports | ./words_per_line > atis.list FG_ROOT=whatever ./atis-lex >> atis.list ./synth.pl atis.list default.vce default.wav ./voice.pl - # to test it Hint: ./synth.pl -h Hint: I recently pushed some more upgrades to http://gitorious.org/~jsd/fg/sport-model/commits/atis This is way better than nothing, and is needed in the short run, but in the medium-long run a reliable realtime synthesis system is needed. = While we are on the subject, it would be great if somebody would figure out how to integrate all the ATC stuff with the multiplayer stuff, so that everybody on the same frequency would hear the same transmissions. As I see it, if there are N players, there need to be N+1 processes, namely one for each player plus one for the "ambiance". The ambiance includes not just things controllers say but also ATIS/AWOS, pilot controlled lighting, etc. etc. etc. It would be super-cool to have one player turn on the pilot controlled lighting and then have *all* the players see the lights come on. ATIS and runway lighting are also tied up with the more general concept of runway-in-use, which interacts with reversible ILS. Right now FG allows simultaneous approaches to both ends of a reversible ILS, which is just ludicrous from the radio-physics viewpoint as well as the pilot's operational viewpoint. The patch to do something sensible with reversible ILSs has been available for a couple of years. !00% of the pilots who have commented on it consider it an improvement. http://gitorious.org/~jsd/fg/sport-model/commits/navaid-repairs/ -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Text-to-Speech system, was: New release
On 12/24/2010 01:53 PM, Mirko Stanisak wrote: > I've used Flite to generate voices in ATC simulations (so that you can listen > to the commands between simulated pilots and controllers). It worked quite > well, the speech was understandable quite well, even if it sounded very > artificial. On the other hand, one could certain do a better voice for ATC as > the vocabulary is very limited in this case. The voice quality of flite is a) good enough for ATIS/AWOS (which in real life are often synthesized and artificial-sounding), and b) better than anything that is likely to be achieved anytime soon using the current code that pastes together snippets, and c) infinitely better than what is in the git repo at the moment, which is no ATIS at all. Also: The cpu workload of flite is pleasantly small. On my machine it takes something like 60 milliseconds to render a typical ATIS message. Furthermore -- if properly implemented -- this could be done in a separate thread, so that in a modern multi-cpu machine no time at all would be taken away from the main simulation. To say the same thing another way: I have an investment in the existing snippet-based system, but I would be well pleased to see it replaced by something better. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On 12/23/2010 05:33 AM, Dave L wrote: > At the moment, the spoken ATIS makes little sense anyway since the > phaseology was corrected a while ago but the extra words were not > recorded. Well, actually the needed words are available. Long ago I wrote a script to run the words through the festival synthesizer, all in a batch, to produce the .wav data and .vce index. To work properly, atis.cxx needs not only the standard ATIS phraseology but also the /names/ of the ATIS/AWOS sites (usually but not necessarily airports). If you include the names of all US airports, the .vce file has more than 2300 entries and the .wav file is more than 30 megabytes. One begins to wonder whether some of the place-names should be loaded on a tile-by-tile basis (like scenery) rather than in one big chunk. > Maybe if you have a text-to-speech system set up it works properly, > but I assume most people downloading the new release will not have > that setup by default. Agreed. Getting TTS to work "live" (as opposed to batch) is way more trouble than ordinary users are willing to put up with. > I am hoping to record the extra words next week during the holiday I can send you the words and/or the script I used to synthesize them. > and port the ATIS over to Durk's new ATC/AI system. That would be a Good Thing. Right now ATC/trafficcontrol.cxx contains about 1000 lines of code, whereas ATC/atis.cxx contains only 1 line of code (and no real functionality). There is a set of users for which the priorities are reversed, in the sense that ATIS/AWOS is 1000 times more important than anything trafficcontrol.cxx is going to say. As you know, there are no currency requirements for listening to ATCT controllers ... whereas there are important currency requirements for instrument approaches, and (with or without a Tower) it is hard to shoot the approach without ATIS information such as weather, altimeter, approach-in-use, et cetera. == Constructive suggestion: If you're going to port something, you might as well start from http://gitorious.org/~jsd/fg/sport-model/commits/atis It contains some minor fixes (to get rid of warnings etc.) and also splits the vocabulary words into a file of their own, to make it easier on the guy who === AFAICT ./configure --enable-atcdcl has never done anything useful. If it is enabled, the code is compiled and linked in ... but not called. That means that in current versions of FGFS, the ATIS feature is really quite broken (not just disabled). Some sort of fix (or port) would be a significant improvement. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
It may not be an entirely good idea to release a FlightGear version without any usable ATIS. It appears that ATC/atis.cxx is a stub. It contains only one line of code. Meanwhile there is ye olde ATCDCL/atis.cxx, which contains code but is "deprecated" and is not compiled in the standard configuration. -- Learn how Oracle Real Application Clusters (RAC) One Node allows customers to consolidate database storage, standardize their database environment, and, should the need arise, upgrade to a full multi-node Oracle RAC database without downtime or disruption http://p.sf.net/sfu/oracle-sfdevnl ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] message: Warning: TangentSpaceGenerator: unknown primitive mode 9 why?
On 12/20/2010 05:42 AM, henri orange wrote: > At FG load, i get a lot of these warning messages: > > TangentSpaceGenerator: unknown primitive mode 9 > > Is it just me ? is there any possibility to avoid it ? It's not just you. There are at least two or three bugs involved here. 1) It is a bug that one part of OSG would generate a primitive mode that cannot be handled by other parts of OSG. Indeed, a comparison of .../include/osg/PrimitiveSet with .../src/osgUtil/TangentSpaceGenerator.cpp suggests that there are several primitive modes that could be generated but not handled. With very slightly cleverer coding, the OSG folks could have detected this situation at compile time, and could have fixed it a long time ago. 2) It is a bug in OSG that the error message is remarkably uninformative. The message doesn't say what caused the problem. It doesn't say how serious the problem is, or what might be the consequences of ignoring the problem. It gives no clue how to avoid the problem ... unless you want to download the source and reverse-engineer a large, complex, and virtually uncommented software system. In particular, the message is presumably provoked by some object in the scene, but the message gives no clue as to what the identity of the offending object. 3) It's not clear to me whether this can be considered a bug in FG, or whether changing FG so as to avoid provoking the OSG bug would be worth the trouble. Changing FG would be a royal pain, because of item (2) above. On 04/22/2010 03:12 PM, Tim Moore wrote: >> It would be best to get the polygons out of the loaded geometry. The >> INDEX_MESH optimizer that was recently added to OSG will do this. How recently was it added? How soon will it fix the problem? Installing the latest OSG SVN does not appear to be sufficient to fix the problem. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] flightgear ./configure apr-1-config
On 07/23/2010 05:12 AM, Csaba Halász wrote: >>> ./configure: line 10540: apr-1-config: command not found >>> ./configure: line 10541: apr-1-config: command not found > That configure test is broken. I agree. It has been broken for a long time ... since well before the previous release. The fix is available at http://gitorious.org/~jsd/fg/sport-model/commits/minor in particular http://gitorious.org/~jsd/fg/sport-model/commit/fd10a6803f36c383cb9acf4882cbdd0c1a880d20 I recently rebased it so it applies to the current "next" branch. -- Lotusphere 2011 Register now for Lotusphere 2011 and learn how to connect the dots, take your collaborative environment to the next level, and enter the era of Social Business. http://p.sf.net/sfu/lotusphere-d2d ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] mpmap ILS data
On 04/07/2010 07:06 PM, Peter Brown wrote: > Perhaps this has been brought up before, but I see that the ILS > "beam" data for each airport on the mpmap is derived from the runway > alignment (as verified in taxidraw). That sounds like a problem. > This doesn't allow for magnetic > deviation, and therefore all the course headings are incorrect. That is the wrong way to think about the problem. This is basically a geodesy problem. It should be worked using true headings, true lat/lon, et cetera. The question of magnetic variation should never come up in this context. > I have not looked at the 850 airport format, but is there a way in > any of the apt.dat or nav data to specify ILS approach data > accurately? The navaid data is accurate. The 830 and 850 formats are equivalently accurate. > Or is this a question for Pigeon, to see about using a > different data list? There is no need for that. The existing nav.dat data is plenty good enough. The existing FGFS code handles this correctly, except in the case of "reversible ILS" installations. Perhaps mpmap could just clone this code. Also, the code to handle reversible ILSs in a reasonable way exists in the sport model. It has been available for many months, as previously discussed. Let me know if you are interested. Or take a look at http://gitorious.org/~jsd/fg/sport-model/commits/sport This is an issue for more than 20% of all ILS installations in the US and UK ... and more than 10% worldwide. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] link problem on new 64 bit system
On 04/03/2010 10:21 AM, dave perry wrote: > I get the following error compiling fgfs. > > /usr/bin/ld: cannot find -lopenal > > But /usr/lib64/libopenal.so.0 => libopenal.so.1 => libopenal.so.1.11.753. Note that "libopenal.so" (with no suffix) is not listed. > My .bashrc has the line > export > LD_LIBRARY_PATH=/usr/lib:/usr/lib64:/usr/local/lib:/usr/local/lib64:/usr/local/lib/osgPlugins > > so I don't see why ld is not finding -lopenal? As a test (and, probably, a workaround) try installing a symlink with the name "libopenal.so". This of course leaves two unanswered questions: 1) Why is libopenal.so missing from the out-of-the-box system? 2) Why was its absence not detected during the autoconfigure step? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug: nav[12] selected radial
On 03/20/2010 03:09 PM, David Megginson wrote: > There's a bug in the /instrumentation/nav/radials/selected-deg > property: the code mistakenly assumes that the selected radial is in > true degrees, but isn't a bearing -- it's just a number. You could > design a VOR where radial 180 was north of the VOR, if you wanted to > (though usually it's close to a bearing in *magnetic* degrees). The > bug affects the --nav1 and --nav2 option in particular, since > > --nav1=340:114.6 > > will no longer start FlightGear with the Nav1 indicator dialed to the > 340 radial, unless the local magnetic variation happens to be 0. At > CYRO, for example, the actual radial ends up being closer to 326, > which is counterintuitive. Nav radios and indicators know nothing > about magnetic variation. I am unable to reproduce this issue in the default c172p. I just did an in-flight VOR receiver check, using standard pilot procedures in accordance with FAR 91.171. I went to SUTRO intersection, dialed up the 287 radial of the SFO VOR, and verified that the needle was (a) properly centered and (b) properly sensitive to OBS changes. I used: --fix=STINS --nav1=287:115.8 --nav2=287:115.8 and I verified that the OBS cards did in fact get set to 287. > We used to have this right in FlightGear, but it's gotten messed up > over the last 3-4 years. There was a bug reported under the Subject: [Flightgear-devel] Setting OBS on command line/.fgfsrc a couple of weeks ago ... but it only affected nav1 IIRC. And it had nothing to do with magnetic variation IIRC. There are some creepy bugs associated with navradio.cxx and with command-line processing ... but this magnetic variation issue is not easily reproducible chez moi. This is with freshly pulled and compiled sources from a few minutes ago. The issue was equally non-observed using sources from two weeks ago. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] News from FlightProSim!
First, a parable: The local supermarket sells shiitake mushrooms for $5.00 per ounce. About a mile down the road there is an ethnic market that sells the same kind of mushrooms for $5.00 per *pound*. You might have been told in high school that this kind of thing can never happen in an efficient market. Well ... it turns out that the mushroom market is not efficient. You might say wow, that's a huge markup. I agree, it's a huge markup. On the other hand, huge markups are perfectly legal. There is nothing anybody can do about it, except maybe to shop around. Other examples abound. Year after year, people buy "breakfast cereal" despite the amazingly high markup. In early 1976, a Mattel vice president compared a game I had written to a Pet Rock. He meant it as the highest compliment, referring to something that millions of people would gladly buy, even though there was obviously a high markup. http://en.wikipedia.org/wiki/Pet_Rock On 03/17/2010 08:07 AM, Patrice Poly wrote: > I think what this person(s) do here is *almost* legal. I am not a lawyer, and I will not opine as to whether any particular thing is legal, but we certainly must consider the hypothesis that what FPS is doing is legal. It's a plausible hypothesis. Is FPS making money off of GPL software? Yes ... but that is expressly permitted by the GPL subject to some not-very-onerous conditions. We can insist that FPS strictly uphold the conditions, but that will not stop FPS from doing the things that list members find most distasteful. Is FPS charging a huge markup? Yes, definitely ... but there is nothing illegal about that. Some of the suggestions offered in this forum for trying to prevent that would violate the letter and spirit of the GPL. Loosely speaking, the point of the GPL is to prevent people -- including us -- from modifying GPL software so as to make it non-GPL. Is FPS guilty of plagiarism? Yes, definitely ... but this is not illegal, either. It is IMHO morally reprehensible, but it is permitted by the GPL. In another context, if you want to disallow plagiarism, you should use a Creative Commons / attribution license or some such. The GPL was designed by and for people who thought the anti-plagiarism provisions of the BSD license were too much trouble. In the context of FG, short of starting over and rewriting FG from scratch, I cannot imagine any way of "porting" FG to a more- restrictive license. == So, what *can* be done? For starters, in this situation as in so many others, sunlight is an excellent disinfectant. If the FPS guy is touting his wares in any open forum, you can speak up in that forum, early and often, so that buyers know where to go for the cheapest and most up-to-date FG versions. Don't get mad, just get the facts out. You can even go so far as to write articles for the various PC simulator magazines. This includes articles announcing the latest version of FG ... and also perhaps articles doing a review, comparing price and features, of the various offerings. I reckon somebody who increases the price without increasing the features would not fare well in such a comparison. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] lamp-post appearance depends on camera tilt angle
1) I closed the bug-tracker issue concerning the taxiway signs. That's all good. 2) Alas there are other scenery elements that still exhibit an improper dependence on camera tilt angle. Example: http://www.av8n.com/fly/fgfs/img48/pole-dark.png in contrast to http://www.av8n.com/fly/fgfs/img48/pole-red-white.png In particular, look at the lamp post just to the right of the tan building, directly above the aircraft compass. Its appearance changes dramatically as a function of camera tilt angle. Note that I have gone to some trouble to control for variables that might _properly_ affect the appearance. The illumination is not changing, and the point-of-view location is not changing. Only the camera tilt angle is changing in the example screenshots cited above. Object appearance should not depend on this. I don't have any first-hand understanding of what's going on, but it is easy to hypothesize that the lamp-posts are afflicted by the same disease the afflicted the taxiway signs. Or not. In any case, this is a definite opportunity for improvement, since the unstable appearance is quite noticeable to pilots who are just taxiing along, minding their own business. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On 03/12/2010 05:13 PM, Tim Moore wrote: >> 262383395d78565 OK! Sign backs are all nice and gray now. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On 03/12/2010 04:10 PM, Tim Moore wrote: > There shouldn't be any black or white > sign backs in the most recent code. Please say what commits constitute the appropriately recent code, so I don't need to grovel through the logs ... or at least so that I know what I'm looking for when I grovel through the logs. Is the "most recent code" available on gitorious? Which branch? Or do I need to grovel through the cvs repo too? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On 03/12/2010 12:05 PM, Tim Moore wrote: >> I flew over there in the ufo and saw gray sign backs there... FWIW, if I limit the flight to the default screensize and default field of view, I find it difficult to reproduce this bug. On the other hand, if I expand the screen to HDTV size and/or zoom in quite a bit, the bug is easily reproducible. Tangentially related question: Should the screen's x-size and y-size be exposed in the property tree somewhere? I looked in the obvious places and grepped for the obvious names without success. I reckon it would only be a couple of lines of code to add the appropriate listeners. Perhaps somebody who is more familiar than I am with the graphics system could stick this in... -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On 03/12/2010 06:54 AM, Tim Moore wrote: > I've checked in a fix for the sign-back problem. The airport sign code is > not fast graphics code and needs another look, but for the moment it works. 1) Thanks, the signs are much improved. 2) The problem is not entirely gone. The window for observing the bug is much smaller, but not zero. The symptom is the same: depending on camera tilt angle, the backside of certain signs switches from black to white. http://www.av8n.com/fly/fgfs/img48/taxi-c-at-r-black.png http://www.av8n.com/fly/fgfs/img48/taxi-c-at-r-white.png A cursory survey suggests that *all* the signs alongside taxiway charlie are affected one way or another. Some backsides are almost always black; others are almost always non-black. === Theoretical question: As I understand it, what's going on is: >> The mesh representing the back of a sign is not complete; graphics state >> from other parts of the scenery are leaking into it. Is there some way to check for this at runtime? Is there some calculation that could be done that would detect leakage, or detect meshes that might lead to leakage? Such a check might make debugging easier. Obviously debugging these signs is nontrivial ... and I suspect the signs are not the only items that are vulnerable to bugs of this ilk. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] scenery appearance depends on camera tilt angle
On 03/11/2010 03:15 PM, Tim Moore wrote: > The mesh representing the back of a sign is not complete; graphics state > from other parts of the scenery are leaking into it. The particular effect > depends on the global draw order, which does change as your viewing angle > changes. Thanks for the rapid and informative explanation. > What color are the sign backs supposed to be? Unless the back of the sign has something to say, it's nondescript gray or black. Here are some examples: http://cdn-www.airliners.net/aviation-photos/photos/4/4/9/0777944.jpg However, double-sided signs are common. Every one of the signs in this diagram is double-sided: http://www.aopa.org/images/asf/pubs/sa07/p4-9.gif For the next level of detail on this, see the parent page: http://www.aopa.org/asf/publications/taxi/taxi_signage.html Here's one that is partially blank/black because whatever it says on the other side is longer: http://farm1.static.flickr.com/171/456566291_270613d348.jpg -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scenery appearance depends on camera tilt angle
What steps will reproduce the problem? --lat=37.637855 --lon=-122.414915 --altitude=656 --heading=113 --fdm=ufo aircraft is stopped. zero airspeed, zero rate of turn, etc. The choice of aircraft doesn't seem to matter; this is 100% reproducible chez moi using the default c172p, the pa24-250, et cetera. Zoom in the view; FoV 15.5 will do; 12.5 is better; 7.7 is even better, if you have good control of the pitch/tilt and view angle. Change the view angle, either by pitching the entire aircraft or by simply tilting the pilot's view angle relative to the aircraft. What is the expected output? Scenery should not change. The ray from each object to the camera image plane should stay the same, except to move to a different point in the image plane, when the camera is tilted. What do you see instead? For some tilt angles, the taxiway signs alongside taxiway charlie are dark, while at other title angles they are lit. http://www.av8n.com/fly/fgfs/img48/taxi-signs-off.png http://www.av8n.com/fly/fgfs/img48/taxi-signs-on.png I cannot imagine what could be causing this. == The same phenomenon is seen during normal flight, but is harder to reproduce and document. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] [PATCH] jsclient and jsserver 64 bit support and 6 axes
On 03/10/2010 01:47 AM, Torsten Dreyer wrote: > I did not commit the 6-axes fix for the following reason: > If we change the protocol anyway, why not do it right an support the maximum > number of axes from plib (currently 16)? The following idea is better: > I'd suggest sending the number of axes in the first 32bit word followed by a > 32bit word for each used axes. "Doing it right" means supporting an _arbitrary_ number of axes, not 6 or 16. Also an arbitrary number of buttons. Just because plib is currently limited to 16 does not mean FG should make the same mistake. Over the years FG has become progressively less vulnerable to the limitations of plib. It is easy to foresee a day when all plib dependencies have been removed from FG. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] network IO issues
I observe the following. Lots of irrelevant stuff snipped: Setup: fgfs --httpd=5400 & lynx -source -head http://localhost:5400/sim/intl/locale/strings/ Result: Making HTTP connection to localhost:5400 Alert!: Unexpected network read error; connection aborted. WARNING: netBufferChannel: output buffer overflow! = This is 100% reproducible chez moi. I looked at the code, and this result is entirely predictable, given that the page that should have been returned is larger than the buffer the plib wants it to fit in. There seems to be a deep-seated problem in the "design" of plib. I don't see any way of fixing this without making substantial changes in multiple places. Hypotheses that should be considered include a) rewriting httpd.cxx to use SGIOChannel::readline, or b) switching to something new, such as boost::asio tcp::acceptor Hypotheses that should IMHO not be seriously considered include: x) using the Berkeley sockets directly -- notoriously non-portable y) fussing with plib. This would be a lot of work, and would be a dead end anyway. Any day that you can remove a plib dependency is a good day. The boost stuff seems a bit clumsy, but it should be portable, and it is cleaner than the simgear readline (which is what FGMetar uses) which is in turn much much cleaner than the plib stuff. == The question of asynchronous IO and thread safety must be dealt with. FGMetar starts a thread of its own, so it can deal with network IO without blocking the main loop of FG. I don't entirely understand what plib does, but whatever it is, it doesn't work right. On 02/08/2010 09:18 AM, Erik Hofman wrote: >> FlightGear is not thread safe, simply because it uses OpenGL. Parts of >> it can work with threads though, and some already do. The question for today is: Is reading and writing the property tree one of the safe parts? Is a process that does nothing except read and write the tree always/sometimes/never thread safe? I can imagine getting into trouble if somebody sets a listener on some property, and then calls opengl from the listener, whereby writing to the property tree becomes thread-unsafe. Or are all the listener callbacks somehow carefully serialized? There are lots of ways of serializing the network traffic, but it would be a shame to do that if not necessary. If the property tree is thread safe, that makes everything simpler and better. == Bottom line: Does anybody know the right way to make this work? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Setting OBS on command line/.fgfsrc
On 03/03/2010 06:13 AM, Alasdair wrote:
> I am using FG cvs and have recently noticed that commands such as:
> fgfs --prop:/instrumentation/nav/radials/selected-deg=63
> no longer have any effect.
>
> --prop:/instrumentation/nav/frequencies/selected-mhz=108.90
> works fine.
I observe the same bug here. Only nav[0] is affected.
It's a bug in gps.cxx. Or maybe multiple bugs.
Why the gps.cxx code has a compiled-in reference to
/instrumentation/nav[0]/radials/selected-deg is a
mystery to me.
Why the gps.cxx code thinks it can reach over and set
the OBS on a KI-209 or similar indicator head is a
mystery to me.
Why the gps.cxx code runs at all in aircraft that don't
have a gps receiver installed is also a mystery to me.
The following workaround is something Mr. Spock would
describe as "crude but effective":
diff --git a/src/Instrumentation/gps.cxx b/src/Instrumentation/gps.cxx
index 2f7455b..9bca740 100644
--- a/src/Instrumentation/gps.cxx
+++ b/src/Instrumentation/gps.cxx
@@ -250,6 +250,7 @@ GPS::Config::getExternalCourse() const
void
GPS::Config::setExternalCourse(double aCourseDeg)
{
+ return;
if (!_extCourseSource) {
return;
}
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Recording and playback
On 03/02/2010 12:39 PM, luca nastro wrote: > I need an information. > The recording and playback generates a file flight.out, I assume you used a command similar to --generic=file,out,20,flight.out,playback If this assumption is not correct, please ask a more specific question. > what are the values of the columns of this file? The format is controlled by Protocol/playback.xml under the "FGDATA" directory on your system. There is a glimmer of documentation on the recording/playback system in Docs/README.IO > I make charts about a session of flight. Be warned that there are multiple bugs in the recording/playback system, including FG code, simgear code, and FG data. Some of the bugs have been found and fixed. Others have not. The code fixes that exist are available from http://gitorious.org/~jsd/fg/sport-simgear/commits/sport and http://gitorious.org/~jsd/fg/sport-model/commits/sport The data tree is not hosted on gitorious; the easiest place to get the patch to playback.xml is from this list, under the heading multiple --generic record/playback errors -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 03/02/2010 01:08 AM, Tim Moore wrote: > Furthermore, I can't parse the "suspend development" comment. It is coming > from some alternate reality of git usage. We are definitely talking about two different realities. > First off, I did identify the > commit id where you made changes to use getline: d5e6aa6235f7. That's a commit to the "FG source tree". Until that hex number was mentioned, I thought we were talking about the code over in the simgear tree. > There aren't > any more yet. You could have just told me that! You could have asked! If "not any more yet" is the answer, I still don't know what the question is (or was). > At the start of this very thread > you sent us the commit id of a change you wished to share and have committed > to the sources. In the specific case of getline changes to flightgear, you > have so far only made one commit which uses getline. How hard is it to send > us that? It's not hard. If you want me to send it, all you have to do is ask. But I'm pretty sure that's not what you want ... and I still don't know what you do want. I don't routinely send patches to this list, for multiple reasons. One reason is the fact that most list-members are not interested in the details. I assume anybody who wants the details will ask ... or look at the git-logs ... or whatever. Another reason is the fact that at the time of the first announcement it is quite impossible to know what further developments will take place. As of today I can answer a specific question by saying "not any more yet" or some such, but it is impossible in principle to answer such questions in advance. Also, when I am told "the code looks OK" followed by suggestions for further developments, it is hard for me to translate that into a question that could be answered by saying "not any more yet" or into a wish that could be granted by emailing a patch. > If you're saying that you might make several commits > in implementing a change and can't identify a specific commit that contains > it, then you need to reconsider how you're working in light of git workflow. That's not even remotely what I'm saying. I know how to make git branches. I grow a lot more branches than I push to gitorious. I suspect you do too. > I'm not going to look at the global state of your repo at a > point in time and tease out the changes related to some feature you'd like > merged. I understand that. Really I do. Now, it's your turn. You need to understand that I cannot continually rebase eleventeen different bits of work so that "X" is sitting on top of the tree, on the off-chance that somebody will want to look at "X" today ... without any way for me to know what "X" is. If you want cooperation, all you need to do is ask. For example, if you want me to put "X" into a special branch and push it somewhere, let me know what "X" is and I'll see what I can do. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 03/01/2010 04:13 PM, Tim Moore wrote: > I'm looking at io/sg_file.cxx in the sport branch. I see the old > implementation of readline inside an > "execrable_readline" #ifdef. I don't see any other implementation of > readline. > Perhaps my question would go away if I fetched your sport flightgear repo > too; You could fetch it into a branch of whatever you're already using. Gitorious makes this easy and efficient. > since I don't have a commit id for the patch where you presumably > changed "readline" to "getline", I haven't. In such a branch, you could do this: git log --oneline --author=jsd sg_file.cxx It will tell you all three commit-ids. There is no need to "grovel through logs". There will in general not be any such thing as "the" commit-id because I cannot suspend development while waiting for somebody to get interested in this-or-that bit of work I did. The track record indicates that most of the FG code I write eventually gets incorporated into the "official" repository, but it is delayed months or years. > But it seems to me that you > could easily implement the old "execrable" readline interface in terms of > your spiffy getline and save yourself the trouble of changing "readline" > calls to "getline." I don't see an easy way of reimplementing readline _per se_ in terms of ::getline or SGFile::getline. The semantics are too different, especially for small buffers; getline might hang in cases where readline would not, and dealing with that would be more work than I'm being paid to do. It is probably true that any code that uses readline would be improved by switching to the getline semantics, but again, finding all uses of readline, understanding them, and switching them over is more work than I'm being paid to do. Don't let the perfect be the enemy of the good. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 03/01/2010 03:56 PM, Tim Moore wrote: > getline looks fine. :-) > Instead of getting steamed about readline, why not > implement it in terms of getline? I did. If this is really a question, please clarify the question. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] A Question about External FDM and different viewpoints
On 02/25/2010 02:26 PM, Grimes, John R Mr CTR USAF AFMC AFRL/RWGG wrote:
> I am currently running FlightGear 2.0.0 (snagged from the ibiblio ftp
> site) that I compiled on my Ubuntu 9.10 64 bit system. Compiled up no
> problem, but I have noticed that when I attempt to setup a master/slave
> scenario that I get some odd artifacts on slave display. The scene on
> the slave looks as if the position of the aircraft is lagged behind, and
> then it suddenly tries to jump to the correct location.
It's a bug. Actually at least five bugs.
> These artifacts
> don't seem to appear in cockpit view or tower view, but they make all
> the other views almost unusable.
Yes.
> I have checked the developers lists,
> and I have seen people mention problems similar to this, but nobody
> seems to have a good solution.
I assume you found the threads on
--[Flightgear-devel] multiple --generic record/playback errors
--[Flightgear-devel] null-FDM and UFO-FDM instrument outages
Note that the "external" FDM is a synonym for "null" FDM.
> It could be a double precision problem,
There are at leaast two such double precision / float / roundoff
bugs, although perhaps only one is biting you at the moment since
you are using the "udp" protocol. So far I have
-- patched the "playback" protocol,
-- patched io/sg_file.cxx,
-- patched generic.cxx, and
-- patched some of the aircraft's nasal files...
... which solves some of the shudder and jitter problems but not all,
especially not in the non-cockpit views.
http://gitorious.org/~jsd/fg/sport-model/commits/sport
http://gitorious.org/~jsd/fg/sport-simgear/commits/sport
> or it could be the FG is propagating the view forward by a certain
> amount of time and correcting the view when a new frame of data comes
> in.
Something like that wouldn't surprise me.
> Here is the master system's command line I am using.
Thanks for the detailed, professional bug report
=
If you want to pursue it, please go ahead. You won't be
duplicating any effort of mine, because I'm kinda busy at the
moment. I doubt I will have large amounts of time to devote
to this set of bugs in the next week or so ... but feel free
to ask questions.
Suggestion: A majority of the jitter / shudder in non-cockpit
views is readily observable with the ascii "playback" protocol,
not just with the binary "udp" protocol. And I got as far as
fixing gs_file.cxx so that it can read from a named pipe (FIFO)
which I reckon might make the debugging faster and easier.
Suggestion: Scrutinize the console log for Nasal error messages.
If you see something about "nil used in numeric context" then
some .nas file somewhere is referencing a variable that is not
being set by the FDM. Bear in mind that this is treated as a
serious error, and defeats all the functionality in that .nas
file. Such things are easy to fix; in particular, for the
default c172p, the following patch helps a lot:
diff --git a/Aircraft/c172p/Nasal/action-sim.nas
b/Aircraft/c172p/Nasal/action-sim.nas
index 7e79f51..d5defe3 100644
--- a/Aircraft/c172p/Nasal/action-sim.nas
+++ b/Aircraft/c172p/Nasal/action-sim.nas
@@ -26,6 +26,11 @@ var panelLights =
props.globals.getNode("controls/lighting/panel-norm", 1);
var dhN_ft = props.globals.getNode("gear/gear[0]/compression-ft", 1);
var dhR_ft = props.globals.getNode("gear/gear[2]/compression-ft", 1);
var dhL_ft = props.globals.getNode("gear/gear[1]/compression-ft", 1);
+
+dhN_ft.setDoubleValue(dhN_ft.getValue() or 0);
+dhR_ft.setDoubleValue(dhR_ft.getValue() or 0);
+dhL_ft.setDoubleValue(dhL_ft.getValue() or 0);
+
var propGear0 = props.globals.getNode("gear/gear[0]", 1);
var propGear1 = props.globals.getNode("gear/gear[1]", 1);
var propGear2 = props.globals.getNode("gear/gear[2]", 1);
... or you could patch the protocol to set a fuller set of
variables ... or both.
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 02/15/2010 03:19 AM, Tim Moore in part wrote: > readline() is pretty gross; The best way to remove the grossness is to extirpate readline and replace it with something that has a nicer interface ... such as returning a std::string. I wrote a getline function to do this. Much cleaner. No need for 16kbyte buffers all over the place. (*) The patch can be found in the usual place: http://gitorious.org/~jsd/fg/sport-simgear/commits/sport Over on the FG side, this requires some minor upgrades: http://gitorious.org/~jsd/fg/sport-model/commits/sport I tried asking for suggestions and/or review off-list, but it appears that mail to timoor...@gmail.com never goes through. Is it a list-mail address only? *) Note: Also, I have dreams of implementing a non-blocking version of this some day ... something that would have been a nightmare given the readline-style interface. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] variant FDM
On 02/21/2010 01:25 PM, Stuart Buchanan wrote: > I think you may be looking at an out-of-date version of > the getstart manual. I don't think so. "cvs up" says my copy is already up to date. The log includes updates through 28 Jan 2010. The passages I quoted earlier were quoted from this version. In order to compile getstart.pdf from sources required 16 patches, and even after that it compiles with 96 errors and 32 warnings, but it does compile and I do look at it. > A while ago I went through and re-documented the command-line > options. Yes, thanks for that. > for the --fdm option, we now have the following text: > > "Select the core flight model. Options are jsb, larcsim, yasim, > magic, balloon, external, pipe, ada, null. This option can normally > be ignored, as the -aircraft option will set the FDM correctly." > > I think that is sufficient for most users. That is unlikely to be sufficient for any user who wants to actually _use_ those options. Just because something is allowed by the command-line syntax checker doesn't mean it actually works. Most of the FDM sub-options don't actually work, and were probably never intended to work. The users would be better off if we either a) change the code to conform to the documentation, which seems unlikely, or b) change the documentation to conform to what the code actually does. === I checked what happens when the aforementioned FDMs are applied to the default c172p: ada = aircraft, as initialized, is sunk into the ground up to the top of the cowling; none of the primary flight controls work. balloon = not expected to be very useful; in fact the aircraft, as initialized, is sunk into the ground completely, and none of the primary flight controls work. external = synonym for null jsb = the default, so the option is a no-op larcsim = segfault magic = works the way its author intended. Not as useful as fdm=ufo null = works, useful, especially after I patched the FDM code and patched the aircraft configuration and patched the playback protocol. pipe = binary protocol; semantics not documented in getstart.pdf or anywhere in Docs/* yasim = error exit: "Unexpected tag 'fdm_config' found in YASim aircraft description" "Program exited with code 01." -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/20/2010 07:01 AM, I wrote: > -- Replaying /engines/engine[0]/rpm has no effect ... even though > setting the same property via the property browser has the > expected effect: causing the engine to spin at the specified > rate. ... > It's one thing to say more properties need to be set ... but > when the properties are being set and the instruments still > don't work, I have no idea how to get them to work. > > If the FDM should do more ... what more should it do? Progress report: I found out one important thing that the FDM (or the playback mechanism) should be doing: calling listeners! In particular, I attached a listener to /engines/engine[0]/rpm. *) Setting this property via the property browser causes the listener to be called, and everything is hunky-dory. *) During ordinary non-playback JSBSim operation, the listener apparently gets called after every FDM iteration, as it should. *) During playback, the listener does not get called by the FDM. This needs to get fixed. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/20/2010 02:23 AM, Erik Hofman wrote: > Well, The Null-FDM does what is say, nothing. It's expected that an > external application fill in the gaps. I did once create a support FDM > for ACMS (black-box) data but I don't think it touches anything but > position and velocity data. > I guess that to get the cockpit fully working in playback a new support > FDM has to be written that fills in the missing gaps. That's all true. For instance, the playback.xml protocol should not bother to replay the state of the starter, since the process whereby the starter starts the engine is under control of the FDM, and the null FDM doesn't do this at all. It works better for the protocol to just replay the engine RPM. Similarly if you want the rate-of-turn needle to work, the protocol should replay /instrumentation/turn-indicator/indicated-turn-rate However ... that doesn't solve the mystery. I have already made those changes to my copy of playback.xml, and things are still messed up: -- The rate-of-turn needle flickers between correct (replayed) rate and zero. (This may be related to the longstanding flicker/shudder problems with external views during playback.) -- Replaying /engines/engine[0]/rpm has no effect ... even though setting the same property via the property browser has the expected effect: causing the engine to spin at the specified rate. -- As previously mentioned, the LOC and GS needles are frozen, even though the properties used by the animations in vor.xml are being set. It's one thing to say more properties need to be set ... but when the properties are being set and the instruments still don't work, I have no idea how to get them to work. If the FDM should do more ... what more should it do? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] null-FDM and UFO-FDM instrument outages
On 02/19/2010 05:59 PM, S Andreason wrote: > I ran into the same problem with using generic instruments when > developing the bluebird over 2 years ago. Some instruments rely on > properties that are only updated by the FDM, and the ufo doesn't. That's valuable information. Can you be more specific? > So I wrote my own nasal to fill in those gaps, and/or I made my own > instruments by modifying a line or two from the generic version. Can you be more specific? What nasal are we talking about? Which instruments? > In another case, the instrument(s) look to the property > systems/electrical/outputs > and so does not work because the ufo does not have an electrical bus. :) That's an interesting hypothesis. However, I see nothing in vor.xml to support this hypothesis. There are lots of aircraft with no electrical bus. I would consider it a bug in the instrument for it to demand an electrical bus and not implement a reasonable default. This should be easy to fix. Which instruments are you referring to? > Another property the ufo fdm does not update is > altitude-agl > > etc. etc. Can you be more specific? I'm pretty sure the LOC and GS needles don't depend on altitude-agl. As far as I can tell, the only variables the OBS head depends on are being set. That's why I put up a screen shot including a property browser window. > So you can't change the FDM and expect everything that rely on > a specific FDM, to keep working. I'm pretty sure I don't expect that. See my note on the subject from a couple of hours ago. However, given that the null fdm is documented to work (according to README.io and according to getstart.pdf) I think we should discuss it when it doesn't work, especially given that it comes so very close to working. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] null-FDM and UFO-FDM instrument outages
Here's a mystery for you: Please take a look at http://www.av8n.com/fly/fgfs/img48/null-fdm-instruments.png Most of the instruments are working, but the rate-of-turn indicator and the Nav 1 CDI/GS needles are frozen. You can see from the property browser that the Nav receiver is properly tuned up and is trying to drive the needles. This is observed during playback using the null FDM. The same sort of frozen instruments are observed using the UFO FDM. The mystery gets deeper because I also observed that clicking on the OBS setting knob does successfully rotate the OBS card on Nav 1. I have debugged this as far as I can. I'm stuck. I don't have any good hypotheses as to why some instruments are working while some parts of other instruments are not working. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] variant FDM
I recently discovered that it is possible to fly the C172p (and presumably lots of other aircraft) using --fdm=ufo. This has the potential to be very useful, for instance if you want to pose the aircraft for pictures, and for navaid "flight check" missions. This really ought to be documented. Conversely the getstart manual ought to document the fact that in most other cases, a given aircraft cannot be switched from one FDM to another. The manual says the FDM is "to be chosen at runtime" but most combinations don't work, and most users will give up before they discover any non-default working combinations. See also next message. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Proposed new set of splash screens
On 02/19/2010 01:48 AM, Erik Hofman wrote: > I've created a new set of splash screens based on the images Durk > created about two weeks ago. > Does anyone have any objections to committing them or does anybody have > other possible splash screens to choose from? > > http://home.telfort.nl/sp004798/emh/Splash1.png > http://home.telfort.nl/sp004798/emh/Splash2.png > http://home.telfort.nl/sp004798/emh/Splash3.png > http://home.telfort.nl/sp004798/emh/Splash4.png > http://home.telfort.nl/sp004798/emh/Splash5.png 1) This is important. It is always nice to make a good first impression. The splash screen is the first thing a new user sees. 2) The composition of the pictures is nice and artistic. 3) The resolution is not sufficient to survive zooming to fit a large HD screen. Jaggies appear in the image. The jaggies are particularly noticeable along sharp edges, such as the leading edge of aircraft, and on the lettering. Obvious options include -- Shipping hi-res and low-res versions of each image. -- Shipping some images hi-res and other images low-res. -- Shipping only hi-res images and scaling them down "on the fly" when running on a screen with fewer pixels. -- Over a *small* range of sizes, don't zoom at all, but rather show a less-than-fullscreen image in the middle of the screen, surrounded by tasteful wallpaper. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] http://wiki.flightgear.org/robots.txt
On 02/18/2010 04:07 AM, Rob / EViLSLuT wrote: > Is the syntax of the robots.txt correct? Could be wrong. Well, technically, it should say "Googlebot" instead of just "Google". But this is such a common mistake that Googlebot answers to the name Google, and no harm is done. > To my knowledge this is what google likes, > > User-agent: * > Disallow: / > > User-agent: Googlebot > Allow: / That's not the recommended form. According to http://www.robotstxt.org/robotstxt.html there is no "Allow:" directive. Certainly there is no advantage to saying "Allow: /" ... and no disadvantage to using the canonical form "Disallow: " which disallows nothing. There are situations where an "Allow:" directive would be helpful, but this is not one of them. Also, due to differences in opinion as to the interpretation of the robots.txt non-standard, it is a bit unpredictable whether bots will respond to the "first match" or "best match" ... so it is good practice to put more-specific directives ahead of less-specific ones. In particular, the "*" wildcard should be last, as it is currently on the site. In any case, the larger point remains: There are plenty of perfectly reasonable, desirable bots that are being excluded by the current file. Conversely there are plenty of truly horrible bots that will never be excluded by any robots.txt file. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] http://wiki.flightgear.org/robots.txt
On 02/17/2010 04:54 PM, Jon Stockill wrote: > Presumably because there are some truly awful bots out there, and google > at least is known to be well behaved. But the truly awful bots don't look at robots.txt. In fact one of the easiest ways to catch rogue bots is to disallow a small part of the site and then blacklist anybody who goes there. -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] http://wiki.flightgear.org/robots.txt
http://wiki.flightgear.org/robots.txt User-agent: Google Disallow: User-agent: * Disallow: / #User-agent: Slurp #Crawl-delay: 5 #Disallow: = Really? A collective, open-source project that doesn't allow anybody other than google to index the documentation? Is there a reason for this? -- Download Intel® Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On Mon, Feb 15, 2010 at 5:43 PM, I wrote: >> 2) It would be even less of a problem to do the following >> the specified number of times: >> -- detect the EoF >> -- close the file >> -- reopen the file and start reading again. >> >> This has the advantage that it works the same as lseek >> for regular disk files, and works a whole lot better >> for FIFO files. >> >> It also removes the need for the "sleep" and simplifies >> the scenario in item (1) above. On 02/15/2010 10:36 AM, Tim Moore wrote: > That would work too. This is done. The patches for this can be found at http://gitorious.org/~jsd/fg/sport-simgear/commits/sport Note that libsgio.a now uses boost to provide thread-safe user-friendly error messages. This requires a couple of changes to Makefile.am files over on the FG side. The patches for this are available separately: http://gitorious.org/~jsd/fg/sport-model/commits/sport === Bottom line: I believe this fixes all the long-standing bugs in SGFile::readline ... and implements the entire feature set, including repeat. I have not checked the corresponding code in other files such as sg_socket.cxx. I would not be surprised to learn that there exist other bugs similar to the longstanding sg_file.cxx bugs. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/12/2010 01:34 AM, I wrote: > I haven't yet made the corresponding > fixes to the FG side of things. Well, I finally got around to it. The patch can be found in the usual place: http://gitorious.org/~jsd/fg/sport-model/commits/sport The commit message says: Fix bug: substrings in LDFLAGS Fix bug: substrings in CPPFLAGS Fix bug: now check libraries (not just headers) for plib. Fix it so that configuration works (mostly) as easily on 64-bit machines as on 32-bit machines, even for users who have compiled OSG from source and need to specify --with-osg=/some/dir. Check for working CXX compiler. More informative error messages. Spelling. Slightly more informative logging. More parallel to SimGear version. == I also ported some of the better ideas from the FG side back to the SG side: http://gitorious.org/~jsd/fg/sport-simgear/commits/sport = For today, the headline is that I've finally got it to the point where I can do "make distclean ; make" for SG and FG and the whole thing compiles without so much as a warning ... and without requiring 64-bit users to say any weird incantations over the compile scripts. The same procedures that have always worked on 32-bit machines now work on 64-bit machines, AFAICT. There are still major weaknesses in the configure/build system. Some things that never worked right (on 32-bit machines or otherwise) still don't work. I will discuss those in a separate thread. And I'll wait a while before discussing them, so nobody will get confused about which bug is which. There sure was a big nest of bugs in acinclude.m4. It's funny how when those get fixed, the issues that some people tried to call "a bug between keyboard and chair" and "an unfortunate mistake" aren't problems anymore. And there's much less need for new, arcane documentation. As soon as these fixes get committed, I will consider the 64-bit configuration snafu a closed issue. Things are definitely moving in the right direction. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/16/2010 01:45 PM, John Denker wrote: OK, I think we can put this sub-issue to bed. I fixed it so that compiling and installing simgear no longer requires the OSG or OpenThreads runtime libraries. The *.h header files are still required. This turned out to be easier than I thought it would be. It took hours, not days. The patch can be found at: http://gitorious.org/~jsd/fg/sport-simgear/commits/sport = I still haven't fixed any of the issues over on the FG side of things, and this little patch actually makes that *more* necessary. *Somebody* needs to be doing the OSG checks. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Web Site
On 02/16/2010 11:27 AM, Curtis Olson wrote: > Here's one possible idea. Why not whip together a replacement front page > and maybe a sample sub-page, put it in a temporary location, and we can take > a look. That's a great idea. Taking the next step along that road, it would be nice to bring up an alpha-test version of the entire FG web site. We are currently alpha-testing the executables and the data tree; why not alpha-test the web site? There are dozens, maybe hundreds of changes that need to be made, to make the web site conform to the 2.0.0 release. Specific suggestion: as a starting point, how about copying the whole tree to a subdirectory such as http://www.flightgear.org/2.0.0/ and then updating the files on that branch one by one. Also cvs.flightgear.org needs some TLC. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/08/2010 08:34 AM, Geoff McLane wrote: > you seem to be yelling something. On 02/16/2010 11:47 AM, Geoff McLane wrote: > It seems WHATEVER the reason is, IF it involves > a SimGear AC_CHECK_LIB() then _REMOVE_ the > AC_CHECK_LIB() from SG configure.ac ;=)) > > There is no reason to check 'libraries' on a > 'library' build, point blank! SG is a set of > libraries, and need have _NO_ library checks > to build them! -- Using exclamation points does not make incorrect statements more correct. -- Using all caps does not make incorrect statements more correct. -- Using underlined all caps seems to be going a bit far. -- Accusing other people of yelling is, ummm, inconsistent to say the least. Try setting a good example. We need to distinguish *) what the actual dependencies of simgear are *) what the dependencies should be *) what dependencies are checked by ./configure As previously explained more than once, the fact is, at the moment, several parts of simgear do depend on OpenThreads. It is therefore entirely appropriate for ./configure to check for this, so that if needed, an informative error message can be given to the user. Several people have suggested re-arranging simgear to remove this dependency. If somebody wants to do that, great, please go ahead. After the actual dependency is removed, then it would be appropriate to remove the dependency-check from ./configure. Then and not sooner. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/15/2010 11:53 AM, Geoff McLane wrote:
> Just did a full SG cvs update, and this
> acinclude.m4 patch _BREAKS_ the SG build for me!
OK. It's a bug.
Thanks for testing.
Here's the patch. Please try again.
The reason for fussing with SG first is simple: this
is where Joe User is going to get into trouble. It
doesn't matter how good the FG configuration is if
Joe cannot get to that stage. And trust me, SG
will not build if it cannot find the OpenThreads
libraries, which are bundled in with OSG these days,
and located in lib64/ by default.
A lot of stuff I do makes more sense if you look
at it from the Joe User point of view.
I will fix up the FG side of things eventually.
commit 5764d1b7da5cb25947f6ada47aa45fe6b2272cec
Author: John Denker
Date: Mon Feb 15 14:50:29 2010 -0700
Fix sneaky bug: 'mylibdir' variable getting trampled.
diff --git a/acinclude.m4 b/acinclude.m4
index 889cbf4..0059bbf 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -113,14 +113,14 @@ for subexdir in $subexdirs ; do
dnl On 64-bit machines, if lib64/ exists and is not identical to lib/
dnl then it should be listed here, listed ahead of lib/.
mylibdir64="${exdir}/lib64${subexdir}"
-mylibdir="${exdir}/lib${subexdir}"
+mylibdir32="${exdir}/lib${subexdir}"
if test "x86_64" = $(uname -m) \
- -a ! ${mylibdir64} -ef ${mylibdir} ; then
+ -a ! ${mylibdir64} -ef ${mylibdir32} ; then
wi_EXTRA_LDIR($mylibdir64)
fi
-wi_EXTRA_LDIR($mylibdir)
+wi_EXTRA_LDIR($mylibdir32)
progdir="${exdir}/bin${subexdir}"
wi_EXTRA_PDIR($progdir)
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] sub-option documentation : repeat
On 02/15/2010 09:22 AM, Tim Moore wrote: > a useful command-line option. The "repeat" sub-option would be even more useful if it were more widely known. It is not mentioned in --help --verbose and not mentioned in getstart.pdf. It would be nice if somebody would a) At least mention README.IO in getstart.pdf and also in --help --verbose. b) Also perhaps expand the discussion of --generic in getstart.pdf to include the full range of sub-options, perhaps by incorporating the relevant passage from README.IO. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 02/15/2010 09:22 AM, Tim Moore wrote: >> Hint: The sleep statement ensures that the reader (fgfs) >> will not see an EoF at the point where one cat of bytes >> ends and the next begins. > I'd probably do without the "sleep" and write while true; do cat bytes; > done >/tmp/pipe.flog & instead. 1) That doesn't work at the moment (but see below!). The problem is that when the first cat completes, the reader (fgfs) gets and EoF, and that's the end of the show. > It's good that you've removed the lseek from the usual path through > readline. :-) > But, as I said, your patch breaks a useful command-line option. It > would be no big deal to insert an lseek to the beginning of the file in your > new readline; if the file descriptor doesn't support lseek, then no harm > done. 2) It would be even less of a problem to do the following the specified number of times: -- detect the EoF -- close the file -- reopen the file and start reading again. This has the advantage that it works the same as lseek for regular disk files, and works a whole lot better for FIFO files. It also removes the need for the "sleep" and simplifies scenario in item (1) above. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] SGFile::readline
On 02/15/2010 03:19 AM, Tim Moore wrote: > Some of > the grossness is due to a hack which lets a file be treated as an infinitely > repeating stream of bytes, very convenient for demos at SIGGRAPH. Your patch > breaks that hack. I won't argue too strongly that the hack belongs in > SGFile, but I want to have some story for replacing it, possibly in > FGGeneric::process(), before we blow it away. Please try this story: mkfifo /tmp/pipe.flog sleep 100 > /tmp/pipe.flog & while true ; do cat bytes > /tmp/pipe.flog ; done & fgfs --generic=file,in,$rate,/tmp/pipe.flog,$protocol Now that readline does not do seeks, it can read named pipes (FIFOs) just fine, and this opens up all sorts of non-hackish way of solving the SIGGRAPH problem ... and a host of previously-unsolved problems as well. For example, it allows you to switch from one stream of bytes to another without restarting fgfs. Seems like a win/win to me. If this story is not good enough, please clarify the question. Hint: The sleep statement ensures that the reader (fgfs) will not see an EoF at the point where one cat of bytes ends and the next begins. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SGFile::readline
The following commit message should be self-explanatory: commit 224ce694fa8ba7dede0e413b81e5dd52e5e65f15 Author: John Denker Date: Thu Feb 11 21:13:19 2010 -0700 Problem was: readline writes out-of-bounds, corrupts memory. Problem was: readline seeks on files that don't support seek. Problem was: readline fails to detect seek errors, returns garbage. Problem was: readline wildly inefficient, re-reading same data again and again. Add utility to test for read/write bugs. Replace readline with a version that is more compact, more maintainable, more extensible, more correct, more efficient, and able to read from named FIFOs and other things that don't seek. For details (476 lines worth) see: http://www.av8n.com/fly/fgfs/readline.patch == The code in sg_file.cxx appears to run parallel to code in other places such as sg_socket.cxx I wouldn't be surprised if the other places needed fixing, too ... but I haven't looked. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Modifying OSG lib checks in FG configure.ac
On 02/12/2010 10:00 AM, Geoff McLane wrote:
>
> RE: README.OSG UPDATE
>
> I have now beefed up the FG README.OSG
> information
>
> I think I have tried to cover everything,
> very carefully!
Thank you for your constructive contributions to the
configuration system, both in terms of debugging the
code and debugging the documentation. I know this is
both tricky and laborious.
As a rule, whenever I see a piece of code that requires
a long stretch of tricky documentation, I have to
suspect that it would be easier and better to upgrade
the code than to upgrade the documentation.
In this case it appears that adding about five lines
of code to acinclude.m4 will remove the need for at
least five paragraphs of documentation. It turns
out to be quite possible to each the configuration
system to search lib64.
I think I've got it to the point where somebody
who wants to compile OSG from source can do so on
a 64-bit machine using the same simple procedures
that have always worked on 32-bit machines. In
simple cases specifying --with-osg=/some/dir will
now suffice.
The attached patch applies on top of the big patch
I submitted about 12 hours ago.
The attached patch contains only a few lines of
"interesting" code. The patch looks bigger than
that because I tried to normalize some of the
indentation and other trivial issues.
commit 237265e977cf775c5adbff813517381a2d4abe3c
Author: John Denker
Date: Fri Feb 12 13:20:13 2010 -0700
Fix it so that configuration works (mostly) as easily on
64-bit machines as on 32-bit machines, even for users who
have compiled OSG from source and need to specify --with-osg=/some/dir.
Also minor cleanup of the source.
Also minor improvements to the logging.
diff --git a/acinclude.m4 b/acinclude.m4
index 851e120..0d645d9 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -23,6 +23,8 @@ if test -r $incdir ; then
fi
echo " + added -I$incdir" 1>&AS_MESSAGE_LOG_FD
fi
+else
+echo " + IDIR is not accessible: '$myincdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -49,6 +51,8 @@ if test -r $mylibdir ; then
fi
echo " + added -L$mylibdir" 1>&AS_MESSAGE_LOG_FD
fi
+else
+echo " + LDIR is not accessible: '$mylibdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -71,6 +75,8 @@ if test -r $progdir ; then
echo " + appended $progdir to \$PATH"
1>&AS_MESSAGE_LOG_FD
;;
esac
+else
+ echo " + PDIR is not accessible: '$progdir'" 1>&AS_MESSAGE_LOG_FD
fi
])
dnl
@@ -94,23 +100,32 @@ if test "$subexdirs" = "" ; then
subexdirs="-"
fi
for subexdir in $subexdirs ; do
-if test "$subexdir" = "-" ; then
- subexdir=""
-else
- subexdir="/$subexdir"
-fi
-for exdir in $exdirs ; do
- if test "$exdir" != "/usr" || test "$subexdir" != ""; then
- incdir="${exdir}/include${subexdir}"
- wi_EXTRA_IDIR($incdir)
+if test "$subexdir" = "-" ; then
+subexdir=""
+else
+subexdir="/$subexdir"
+fi
+for exdir in $exdirs ; do
+if test "$exdir" != "/usr" || test "$subexdir" != ""; then
+incdir="${exdir}/include${subexdir}"
+wi_EXTRA_IDIR($incdir)
+
+dnl On 64-bit machines, if lib64/ exists and is not identical to lib/
+dnl then it should be listed here, listed ahead of lib/.
+mylibdir64="${exdir}/lib64${subexdir}"
+mylibdir="${exdir}/lib${subexdir}"
+
+if test "x86_64" = $(uname -m) \
+ -a ! ${mylibdir64} -ef ${mylibdir} ; then
+wi_EXTRA_LDIR($mylibdir64)
+fi
- mylibdir="${exdir}/lib${subexdir}"
- wi_EXTRA_LDIR($mylibdir)
+wi_EXTRA_LDIR($mylibdir)
- progdir="${exdir}/bin${subexdir}"
- wi_EXTRA_PDIR($progdir)
- fi
-done
+progdir="${exdir}/bin${subexdir}"
+wi_EXTRA_PDIR($progdir)
+fi
+done
done
])
dnl
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/09/2010 03:08 AM, Erik Hofman wrote:
> I've updated configure of both FlightGear and SimGear to bail out if the
> OpenScenegraph libraries are not found.
Thanks! That is a significant improvement.
That helped directly ... and also helped indirectly,
by giving me a valuable clue about how to fix some
of the other bugs in the autoconfiguration setup.
The commit message should be self-explanatory.
This deals with the SG side of things, which is
where Joe User will usually first encounter
problems. I haven't yet made the corresponding
fixes to the FG side of things.
commit 4eb51bb90f4e8c2ca9842ad248b5e0eb57e400f7
Author: John Denker
Date: Fri Feb 12 01:25:25 2010 -0700
Fix bug: substrings in LDFLAGS
Fix bug: substrings in CPPFLAGS
Fix bug: now check libraries (not just headers) for plib.
More informative error messages.
Spelling.
Slightly more informative logging.
diff --git a/acinclude.m4 b/acinclude.m4
index 9e46179..851e120 100644
--- a/acinclude.m4
+++ b/acinclude.m4
@@ -6,19 +6,23 @@ dnl
AC_DEFUN([wi_EXTRA_IDIR], [
incdir="$1"
if test -r $incdir ; then
- case "$CPPFLAGS" in
- *-I${incdir}*)
- # echo " + already had $incdir" 1>&6
- ;;
- *)
- if test "$CPPFLAGS" = "" ; then
- CPPFLAGS="-I$incdir"
- else
- CPPFLAGS="$CPPFLAGS -I$incdir"
- fi
- echo " + found $incdir" 1>&6
- ;;
- esac
+already=""
+for CPPflag in $CPPFLAGS ; do
+ if test "_$CPPflag" = "_-I${incdir}" ; then
+already=yes
+break
+fi
+done
+if test -n "$already" ; then
+echo " + already had -I$incdir" 1>&AS_MESSAGE_LOG_FD
+else
+if test "$CPPFLAGS" = "" ; then
+CPPFLAGS="-I$incdir"
+else
+CPPFLAGS="$CPPFLAGS -I$incdir"
+fi
+echo " + added -I$incdir" 1>&AS_MESSAGE_LOG_FD
+fi
fi
])
dnl
@@ -28,19 +32,23 @@ dnl
AC_DEFUN([wi_EXTRA_LDIR], [
mylibdir="$1"
if test -r $mylibdir ; then
- case "$LDFLAGS" in
- *-L${mylibdir}*)
- # echo " + already had $mylibdir" 1>&6
- ;;
- *)
- if test "$LDFLAGS" = "" ; then
- LDFLAGS="-L$mylibdir"
- else
- LDFLAGS="$LDFLAGS -L$mylibdir"
- fi
- echo " + found $mylibdir" 1>&6
- ;;
- esac
+already=""
+for LDflag in $LDFLAGS ; do
+ if test "_$LDflag" = "_-L${mylibdir}" ; then
+already=yes
+break
+fi
+done
+if test -n "$already" ; then
+echo " + already had -L$mylibdir" 1>&AS_MESSAGE_LOG_FD
+else
+if test "$LDFLAGS" = "" ; then
+LDFLAGS="-L$mylibdir"
+else
+LDFLAGS="$LDFLAGS -L$mylibdir"
+fi
+echo " + added -L$mylibdir" 1>&AS_MESSAGE_LOG_FD
+fi
fi
])
dnl
@@ -50,12 +58,9 @@ dnl
AC_DEFUN([wi_EXTRA_PDIR], [
progdir="$1"
if test -r $progdir ; then
- case "$PATH" in
- *:${progdir}*)
- # echo " + already had $progdir" 1>&6
- ;;
- *${progdir}:*)
- # echo " + already had $progdir" 1>&6
+ case ":$PATH:" in
+ *:${progdir}:*)
+ echo " + already had $progdir in \$PATH"
1>&AS_MESSAGE_LOG_FD
;;
*)
if test "$PATH" = "" ; then
@@ -63,7 +68,7 @@ if test -r $progdir ; then
else
PATH="$PATH:$progdir"
fi
- echo " + found $progdir" 1>&6
+ echo " + appended $progdir to \$PATH"
1>&AS_MESSAGE_LOG_FD
;;
esac
fi
diff --git a/configure.ac b/configure.ac
index 710a42f..38ae49f 100644
--- a/configure.ac
+++ b/configure.ac
@@ -437,11 +437,18 @@ esac
AM_CONDITIONAL(HAVE_FRAMEWORK_PLIB, test "x$ac_cv_framework_PLIB" != "x")
AC_CHECK_HEADER(plib/ul.h)
-if tes
Re: [Flightgear-devel] Shader issue on ATI cards
On 02/11/2010 04:14 PM, jean pellotier wrote: > a temporary fix is to remove the "gl_FrontMaterial.ambient" part in 3 > files, Wow! Direct hit! > here's the diff: That makes a huge improvement. I'm running with shader-effects turned on now, for the first time in months. Thanks! -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal/*.nas ... order of loading, #include <...>, require(...)
On 02/11/2010 04:11 PM, Csaba Halász wrote:
> On Thu, Feb 11, 2010 at 10:59 PM, John Denker wrote:
>> On my machine I observe that the various scripts in
>> the Nasal/ directory get loaded in some hard-to-predict
>> order.
>>
>> That means that if you write a script called foo.nas,
>> it's hard to know whether it will get processed before
>> or after math.nas and/or props.nas.
>>
>> So the question is, what to do if foo.nas wants to make
>> use of the features provided by the other scripts?
>>
>> I know about the trick of using settimer(stuff, 0).
>
> The usual trick is to attach a listener to /sim/signals/nasal-dir-initialized.
That is similar to the settimer trick. Either one will
bisect the problem. That is, if you have simple pairwise
interactions, you can split each pair and thereby control
the ordering. But what if the interactions are more
complicated, e.g. a depends on b which depends on c which
depends on d?
How hard would it be to handle the general case? There
are standard techniques ...
> Also, you can load nasal modules dynamically, such as:
>
> if (!contains(globals, "MPCarriersNW")) {
> io.load_nasal(getprop("/sim/fg-root") ~
> "/Aircraft/MPCarrier/Systems/mp-network.nas",
> "MPCarriersNW");
That's a powerful procedure, but it only works _after_
io.nas has been loaded ... so AFAICT it doesn't really
answer the question I was asking.
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Nasal/*.nas ... order of loading, #include <...>, require(...)
On my machine I observe that the various scripts in the Nasal/ directory get loaded in some hard-to-predict order. That means that if you write a script called foo.nas, it's hard to know whether it will get processed before or after math.nas and/or props.nas. So the question is, what to do if foo.nas wants to make use of the features provided by the other scripts? I know about the trick of using settimer(stuff, 0). But what if we wanted to use math functions in the code that actually runs at the time the scripts are loaded? In particular, does nasal have any sort of "#include" directive (as in c++) or "require" or "use" directive (as in perl)? If so, is it documented somewhere? If not, has anybody thought about how to implement it? -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Shader issue on ATI cards
On 02/11/2010 01:41 AM, Stuart Buchanan wrote: > A number of people with ATI cards are having problems with the > default shaders on the current windows v2.0.0 RC: I'm not surprised. The "weird dark pall" has been #1 on my list of FG bugs for months. The bug is known to be shader-related. The bug is quite serious; the sim is unbearable to look at with shader-effects turned on. I have observed this equally with Debian Squeeze and Ubuntu Karmic. > Does anyone on the -dev list have an ATI card that is working (or > not) with the shader options? I have a Radeon HD 4870 with 1GB of 256-bit GDDR5. It uses the RV770 chipset. I've run a sampling of tests from the phoronix test suite and never noticed any problems. FG is the only application that suffers from either the pathetically low frame rate or the shader-related pall. > Are you seeing any error messages in the console at all? No messages. > Usually if there is a shader issue, then some error messages are displayed > there. > However the colour problems you are seeing are quite strange. Strange indeed. The details of the pall seem to depend on time of day (angle of sun?). The pall depends very stronly on direction of view. For some directions, the pall is not noticeable, but panning the view a tiny amount brings the pall back in full force. === As a tangentially-unrelated remark: no matter whether shader-effects are turned on or not, I observe that the /sim/rendering/random-vegetation property has no effect. Is it obsolete? What is/was it supposed to do? -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 01:14 PM, Curtis Olson wrote: > Right, I wouldn't consider playback.xml to be the most well conceived > generic protocol configuration file, ... Is there some other protocol file that should be used instead? None of the other Protocol/*.xml files seem particularly suited to the record/playback task. Or am I overlooking something? -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 01:14 PM, Curtis Olson wrote:
> lon/lat are being written out as a float. This should be switched to
> double. The format specifier is %f but it might be better to specify a
> fixed number of decimal places appropriate for the required visual
> precision. I don't have my calculator handy, but maybe try 8 or 10 decimal
> places (%.8f)
OK! Thanks for the clue. Two patches attached.
At the next level of detail:
-- I think that needs to be %.8lf with an "L"
-- The code in generic.cxx needed repair
That makes the cockpit view muuuch better. Cockpit
view is usable now.
=
Now for the not-so-good news.
The chase views are still messed up.
Do we think the cause will be another float versus
double issue? I checked the s in playback.xml
and didn't find any obvious problem children beyond
latitude and longitude. What am I missing?
commit 21f8a5cb05b7f3cc054e1821380c2dcc2322add8
Author: John Denker
Date: Tue Feb 9 15:17:30 2010 -0700
latitude and longitude need to be handled as DOUBLE precision
diff --git a/Protocol/playback.xml b/Protocol/playback.xml
index 1b4b3ab..ff09489 100644
--- a/Protocol/playback.xml
+++ b/Protocol/playback.xml
@@ -341,15 +341,15 @@
latitude-deg
-float
-%f
+double
+%.10lf
/position/latitude-deg
longitude-deg
-float
-%f
+double
+%.10lf
/position/longitude-deg
@@ -837,13 +837,13 @@
latitude-deg
-float
+double
/position/latitude-deg
longitude-deg
-float
+double
/position/longitude-deg
commit 3fc163be23aa69f1fe7fecb0c3e8a7f6e236c431
Author: John Denker
Date: Tue Feb 9 15:12:19 2010 -0700
Improve handling of type DOUBLE in generic i/o protocol.
diff --git a/src/Network/generic.cxx b/src/Network/generic.cxx
index a91f783..31b007a 100644
--- a/src/Network/generic.cxx
+++ b/src/Network/generic.cxx
@@ -240,8 +240,8 @@ bool FGGeneric::gen_message_ascii() {
case FG_DOUBLE:
val = _out_message[i].offset +
-_out_message[i].prop->getFloatValue() * _out_message[i].factor;
-snprintf(tmp, 255, _out_message[i].format.c_str(), (float)val);
+_out_message[i].prop->getDoubleValue() *
_out_message[i].factor;
+snprintf(tmp, 255, _out_message[i].format.c_str(), (double)val);
break;
default: // SG_STRING
--
SOLARIS 10 is the OS for Data Centers - provides features such as DTrace,
Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW
http://p.sf.net/sfu/solaris-dev2dev
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] multiple --generic record/playback errors
On 02/09/2010 12:43 PM, Curtis Olson wrote: > The first thought that comes to mind is to double check the precision > (significant digits) of the data you are writing out. If you are writing > out heading for instance with 0 or 1 decimal digits or position with 4 > decimal digits, that could account for this sort of thing. Well, if so, it is a bug in the "record" part of the record/playback system. All I did was --generic=file,out,20,flight-16756.flog,playback in accordance with the instructions on page 79 of getstart.pdf The other three bugs I reported are pretty clearly playback bugs, but I logged the "shudder" problem as a bug in the "record/playback system" precisely because I have not yet figured out how much of the problem is associated with the record part and how much is associated with the playback part. Here are a few lines from the start of the .flog file. Maybe you can tell us whether the precision of representation is part of the problem: 0.00,0.027000,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393280,-.00,0.00,0.424000,117.92,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,-32.00,0.00,0.00,0.00,0.00,0.00 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002851,-0.022103,2.858213,117.899147,0.00,0.00,-0.040693,0.21,0.000850,0.007724,0.019386,-0.002601,-0.024386,0.000784,-0.000850,0.00,0.00,0.00,0.00,1.606968,0.012416,-32.186577,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002861,-0.254527,2.863728,117.890442,0.00,0.00,-0.000928,0.23,0.24,-0.020869,0.015593,-0.025827,-0.003966,-0.001286,-0.24,0.00,0.00,0.00,0.00,1.610066,0.142982,-32.186104,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002876,-0.256716,2.865460,117.891769,0.00,0.00,-0.000438,0.26,0.13,-0.024178,0.016417,-0.029108,-0.003181,-0.001458,-0.13,0.00,0.00,0.00,0.00,1.611039,0.144212,-32.186050,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,37.628723,-122.393288,6.002889,-0.257374,2.867039,117.893646,0.00,0.00,-0.000528,0.29,0.17,-0.026744,0.017575,-0.031892,-0.003013,-0.001593,-0.17,0.00,0.00,0.00,0.00,1.611926,0.144581,-32.186005,-0.003875,0.00,0.024371,0.024371,-0.142830 -0.002625,0.027000,-0.003876,0.00,-0.142857,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,3.00,0.00,0.00,0.00,0.00,0.00,0.00,0.00,1.00,1.00,1.00,1.00,1.00,1.00,256717856,256717856,256717856,256717856,256717856,256717856,256717856,256717856,25
[Flightgear-devel] multiple --generic record/playback errors
Has anybody used the --generic record/playback feature recently? It seems to have some very noticeable bugs: When using the --generic record/playback feature, I observe numerous view-related problems: * Helicopter view: the size of the aircraft throbs at a high rate, getting bigger and smaller many times per second. This makes this view unusable. * Chase view: similar throbbing. This makes this view unusable. * Chase view without yaw: the azimuthal direction of view shudders, shifting left and right by a large amount many times per second. Both the aircraft and the scenery shudder. This makes this view unusable. * Cockpit view: small but distracting weird changes in heading, especially at low speed, as when taxiing. -- When using the --generic record/playback feature, the engine starter does not engage when the “s” key is pressed. FWIW I was able to start the engine by using the property browser, setting its running property and then giving it some rpm. - When using the --generic record/playback feature, the hud is visible in the helicopter view, the chase views, and the tower views, which looks quite silly. When using the --generic record/playback feature, when playback reaches end of file, it prints on the console at a high rate an endless stream of errors: Error reading data. Error reading data. Error reading data. Error reading data. Error reading data. -- SOLARIS 10 is the OS for Data Centers - provides features such as DTrace, Predictive Self Healing and Award Winning ZFS. Get Solaris 10 NOW http://p.sf.net/sfu/solaris-dev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scenery bug: KSQL stray building
At KSQL there is reproducibly a building sitting partially on a taxiway and even extending onto the runway a little bit. http://www.av8n.com/fly/fgfs/img48/ksql-building-on-rwy.png -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/08/2010 10:58 AM, Geoff McLane wrote: > But John, what IS the _BUG_ you refer to? Thank you for asking. > Your bug list page only points out osgFX > library could not be found. This is NOT a BUG!!! > Definitely a user OSG installation problem, but > _NOT_ a SG/FG BUG! Are you asking me or telling me? > If you had read the screen during the > ./configure ... step you would have seen > something like :- > Checking for osgGetVersion in -losg: no > That 'no' is a 'clear indication' of trouble > pending... I'm telling you, again, that statement is completely false. No such indication, clear or otherwise, is observed chez moi when reproducing the bug I am talking about. A detailed typescript of the configuration step can be found at http://www.av8n.com/fly/fgfs/bad-configure.logg The log file written by ./configure itself is at: http://www.av8n.com/fly/fgfs/config.log The corresponding typescript of the make step is at: http://www.av8n.com/fly/fgfs/bad-make.logg Unless grep is lying to me, no failed check for osg can be seen during the configuration step. grep -i osg bad-configure.logg + ./configure --with-osg=/games/orig/usr --with-plib=/games/orig/usr --prefix=/games/orig/usr osg prefix is /games/orig/usr checking osg/Version usability... yes checking osg/Version presence... yes checking for osg/Version... yes > And after the fact, in the config.log, like - > ... > configure:13918: checking for osgGetVersion in -losg > configure:13953: g++ -o conftest -g ... blah blah... > configure:13959: $? = 0 > configure:13977: result: no Again, completely untrue. grep -i osg config.log $ ./configure --with-osg=/games/orig/usr --with-plib=/games/orig/usr --prefix=/games/orig/usr configure:8397: checking osg/Version usability configure:8397: checking osg/Version presence configure:8397: checking for osg/Version ac_cv_header_osg_Version=yes HAVE_FRAMEWORK_OSG_FALSE='' HAVE_FRAMEWORK_OSG_TRUE='#' osg_FRAMEWORKS='' > That "result: 'no'" is a 'clear indication' that a > libosg, containing an exported function osgGetVersion, > can NOT be found, using the 'standard' and -L/paths/... > given to g++, ... Still completely false. >> But that seems beside the point. The configure >> script _DID_ tell you it could _NOT_ find the >> OSG libraries - you just ignore it. You did not >> heed its clear indication that you were headed >> into trouble... This is getting kinda repetitious. They say a word to the wise suffices. There's more I could say, but I'll stop here. Maybe I have overlooked something ... but IMHO whatever it is, Joe User is likely to overlook it also. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/08/2010 08:34 AM, Geoff McLane wrote: > But that seems beside the point. The configure > script _DID_ tell you it could _NOT_ find the > OSG libraries - you just ignore it. You did not > heed its clear indication that you were headed > into trouble... That statement is completely false. There was no indication from ./configure that there was any impending trouble. The first and only sign of trouble was when the "make" step failed in a surprising way. > Here we are TRYING hard to help you, and > you seem to be yelling something. Before your > long rant I was going to say --- I spoke softly for a long time and was ignored. When people announce that the bug is "closed", based on completely false assumptions, I feel I should explain why the assumptions are false. When the number of false assumptions becomes large, the explanation becomes lengthy. I also point out, again, that I am not asking anybody to "help" me. I have workarounds for this bug. Have had for years. I am just trying to help Joe User. I was slapped for pointing this out previously, but it remains true. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] scheduling and threading
First, a specific question: Is there any reason why, when the simulator is paused, the http property browser should be stalled? I would have expected the network interface to be completely asynchronous. This is an important question, because one of the big reasons for pausing the simulator is for looking at the properties. A similar question applies to the jpg-httpd imaging system. Is there any reason why that should not be asynchronous? Indeed it would be nice if the JPEG stuff ran in its own thread. Some people have very powerful multi- processor systems, and it's embarrassing for the display to freeze every time a snapshot is taken. In particular, imagine a student/instructor situation, where the instructor has his own screen and keyboard. The instructor wants to take a snapshot for postflight discussion. The student really doesn't like it when the sim freezes in the middle of a maneuver. The non-http image snapshot system (the "F3" key) has issues, too. I observe that it freezes the system so badly that the airplane makes "engine restarting" noises after every snapshot. More generally: Have there been any design decisions made as to what functions should continue to work during pause, and which should not? Obviously flight dynamics should be paused ... but I notice that during pause I can still wiggle the joystick and see the yoke respond, and I can switch views using the v / V / ^V keys, and I can tilt/pan/zoom the view at least at first ... but on the other hand, when I wiggle the yoke the flight control surface do not respond, and after a few seconds I lose the ability to tilt and pan the view. Zoom continues to work. I observe that I can use the pop-up menus including the property browser during pause, but I cannot use the http property browser. Can somebody explain how this is supposed to work? Even more generally: To what extent is FG thread-safe? At one extreme, is this merely an aspiration for the distant future? At the other extreme, is this an established fact and requirement? Are there perhaps bits that are known to be thread-safe, and can be threaded, so long as we stay away from the naughty bits? Is the answer different for MSVC versus Linux? -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
One thing I'd like to clarify: I wish people wouldn't be so quick to assume that Joe User is a non-programmer and/or an idiot. I never said that, and I never meant to imply that. Let's suppose Joe has a PhD in biochemistry, and has written 100,000 lines of code in the last few years. There are *lots* of scenarios where Joe and other non-idiots might want to compile OSG from source. -- For starters, Joe might have access but *not* root access to a super-high-end graphics system. -- Maybe Joe has root access but doesn't want to use it for this purpose, for security reasons. -- Maybe Joe wants to install multiple versions, for comparison purposes. -- Maybe Joe's distro provides a slightly elderly version of OSG, not advanced enough for use with FG, and Joe doesn't want to upgrade his entire software base just so he can try out some game. One of the things I like about Linux is that it allows users to do things without requiring every user to be superuser. I emphasize yet again that messing with ld.so.conf is nowhere near being a solution (let alone a documented solution, much less an out-of-the-box solution) in use-case scenarios of this sort. The inappropriateness of messing with ld.so.conf is particularly obvious in scenarios where there are multiple installed versions. In such scenarios, appropriate solutions include passing LD_LIBRARY_PATH in the environment at runtime, or passing "rpath" options to the linker at link-time. I remain quite aware that there are ways of getting things to work in Joe's scenarios -- quite a few ways actually -- but they all involve doing something that the average biochemist will find non-obvious. The LIB_POSTFIX flag, for example, is a fine idea, but it is not mentioned anywhere in the OSG *or* FG documentation so far as I can tell. The claim that Joe User can install OSG and FG from source "out of the box" is untenable. === The claim that I wrongly specified putting OSG into lib64 is entirely baseless. None of my configuration options specify anything of the sort. The configuration flags specify a higher-level directory; OSG creates the lib64 directory all by itself. This is the OSG default behavior. More generally, I must disagree with the claims that the problems arise because OSG has been installed in a "wrong" place. The crux of the argument is that ./configure has two phases, one where it finds stuff to make sure all needed components have been installed, and another where it emits makefiles. Common sense suggests that the first phase and the second phase should play by the same rules. In particular, the first phase of ./configure operates by compiling tiny test programs. I'm still waiting for somebody to explain why the ./configure script knows how to compile these test programs just fine, but doesn't know how to compile SG and FG. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] property browsing
Hi --
I made multiple improvements to the http property browser.
-- much easier to navigate up the tree
-- clearer indication of property type
-- possible to re-examine property that has just been set
See
http://gitorious.org/~jsd/fg/sport-model/commits/sport
=
Some minor mysteries I encountered while testing the property browser:
*) What is the difference between /rendering and /sim/rendering?
Is there any available guidance about which should be used
for what?
*) What is /models ?
*) What is /orientation/yaw-deg ?
Is it supposed to be related to heading, or to slip angle, or
*) It appears VEC3D and VEC4D property types are defined, but
-- they are not fully supported
-- there are no examples of them in the main property tree
("globals")
-- there is some code in simgear/scene/material/mat.cxx and
./Effect.cxx that does a few things with them.
-- There is no nasal support at all.
Is that about right? Are there plans to promote these types
to fully-supported status?
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] triplicate code
Do we really need three pieces of code that try to do the
same thing?
simgear/props/props_io.cxx: static const char * getTypeName
(simgear::props::Type type)
src/Network/props.cxx: static string getValueTypeString(const
SGPropertyNode *node)
src/GUI/property_list.cxx: static string getValueTypeString( const
SGPropertyNode *node )
==
commit 92b369deb2654351ce4e385a773ccbe01113ce14
Author: John Denker
Date: Sun Feb 7 02:37:55 2010 -0700
Export the code that translates the _type_ of a property node
to a human-readable string.
diff --git a/simgear/props/props_io.cxx b/simgear/props/props_io.cxx
index 48244c7..214d73f 100644
--- a/simgear/props/props_io.cxx
+++ b/simgear/props/props_io.cxx
@@ -410,9 +410,10 @@ void readProperties (const char *buf, const int size,
#define INDENT_STEP 2
/**
- * Return the type name.
+ * Convert the _type_ of a property node
+ * to a human-readable string.
*/
-static const char *
+const char *
getTypeName (simgear::props::Type type)
{
using namespace simgear;
diff --git a/simgear/props/props_io.hxx b/simgear/props/props_io.hxx
index b619c04..22c0cfb 100644
--- a/simgear/props/props_io.hxx
+++ b/simgear/props/props_io.hxx
@@ -68,6 +68,13 @@ void writeProperties (const std::string &file,
bool copyProperties (const SGPropertyNode *in, SGPropertyNode *out);
+/**
+ * Convert the _type_ of a property node
+ * to a human-readable string.
+ */
+const char *
+getTypeName (simgear::props::Type type);
+
#endif // __PROPS_IO_HXX
// end of props_io.hxx
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurator plebis
On 02/06/2010 08:06 AM, Erik Hofman wrote: >> That does not fix the main problem. It does not fix >> the bug that I am reporting. > > The problem you reported is that the linker can't locate the library. > If it's location is defined in ld.so.conf (and after running ldconfig) > it can. No, that is not the bug I am reporting. Beware that the word "linker" is ambiguous. ld is different from ld.so. More precisely, /usr/bin/ld is different from /lib/libdl.so* ... different program, different purpose, different specifications. For example, I can change the behavior of ld.so by setting the LD_LIBRARY_PATH. That cannot and should not affect ld. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/06/2010 07:54 AM, Csaba Halász wrote: > On 64 bit systems /lib64 should really be a symlink to /lib (similarly > for /usr/lib64) as that is the native architecture. > I say copy the stuff from lib64 to lib and create the symlink. That is one way of doing it. By my count there are at least four different workarounds for the configuration snafu: -- LIB_POSTFIX during OSG compilation -- moving or copying the OSG libraries -- symlink -- LDFLAGS during SG and FG compilation/linkage The fact that workarounds exist for this bug seems to be rather strong evidence that the bug exists. The claim that everything just works "out of the box" is untenable. One option would be to document one or more of these workarounds. A better option would be to fix things like acinclude.m4 so that workarounds are no longer necessary, so that things really do work "out of the box". -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurator plebis
On 02/06/2010 02:32 AM, Erik Hofman wrote: > As I see it this might actually be a problem for the Linux vendor. They > should have added /usr/lib64 to /etc/ld.so.conf That does not fix the main problem. It does not fix the bug that I am reporting. ld.so.conf is meaningful at runtime. The problem is that the program never gets to runtime, because "make" fails at link-time. Also ./configure is documented to allow the libraries to be in places other than /usr/anything. It says the configuration is correct, but then emits buggy makefiles. > Another thing that has bugged me about osg though is that is places it's > plugins in /usr/(local/)lib/osgPlugins- > This is very hard to catch in a configure script and is only solved by > adding that directory to ld.so.conf Messing with the system-wide /etc/ld.so.conf is not the "only" way of dealing with the libraries at runtime. In particular, it should be -- and is -- possible to compile, link, and run FG without having root access to the machine. See also important note below. Chez moi it suffices to add CXXFLAGS="$CXXFLAGS -Wl,-rpath=$parent/usr/lib64" to the environment of every ./configure invocation. Another way would be to use LD_LIBRARY_PATH in the runtime environment. This is all fine *provided* the user can get past the buggy "./configure ; make" step. In any case, these runtime problems (and solutions) are irrelevant to the bug I am reporting. == Note: It is actually very important for me, and for other people I support, to have various versions of the libraries installed in various places other than default, global, system locations such as /usr/lib/. One reason is that I often need to run multiple different versions of FG. -- I need to run the _sport model_. Experience shows that most of the features of the sport model eventually get incorporated into the main line ... but it often takes months or years for this to happen. -- I need to run the stock version whenever I want to report a bug, to guard against the extremely remote possibility that there are bugs in the sport version that are not in the stock version. On 02/06/2010 04:15 AM, Jon Stockill wrote: >> Curtis Olson wrote: >>> I don't doubt that there could be some lib vs. lib64 inconsistencies, >>> but FilghtGear builds right out of the box for me on 64bit Fedora 12 ... >>> no hitches at all that I recall and it has done so for quite some time. >> >> Same for me on slackware64. Does that include downloading OSG from the OSG site and compiling it according to the instructions, on a machine where the "distro-package" version of OSG has not been installed? It would be odd if people were required to compile FG from source but forbidden to compile OSG from source. I would remind people that for much of the time in recent years, the required-for-FG version of OSG has been ahead of the distro-package version. So being able to compile OSG from OSG source (not distro source) is not a trivial or wacky idea. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configurator plebis
On 02/05/2010 06:43 PM, Curtis Olson wrote: > This simply isn't the case as I have observed it. Everything compiles out > of the box here. I have access to two 64 bit Linux machines. I run Fedora > if that makes a difference. OSG, FlightGear, Simgear, plib go together > without expert magic using the default configure paths. We could work to > try to figure out what the difference is between your experience and others > who have also been successful with 64 bit machines. There's probably a > difference in methodology, or paths or something. Or we could stand on our > soapboxes and make grand proclamations. I was hoping we were doing the > former. I did share my "configure" options. And I have shared mine. > Please understand I'm not > trying to claim you are doing something stupid which it appears is how you > interpreted my message. I was hoping to drill down to what we were doing > that was different. I'd prefer to make configure script changes with a full > understanding of the issues rather than hacking and slashing everything up > ... especially in consideration that the current configure scripts do work > on 64bit machines for a lot of people. Did you try downloading the OSG 2.8.2 source from http://www.openscenegraph.org/projects/osg/wiki/Downloads and compiling it, as mentioned in the use-case example I posted? All evidence suggests that this is the sticking point. AFAICT all the major distributions install OSG in .../lib/. That presumably applies to source RPMs as well as binaries. In contrast, downloading it from openscengraph.org and compiling it, without any undocumented expert incantations, installs it in .../lib64/ -- unless they have changed something very recently without telling anybody. If you're going to do the experiment, you need to temporarily de-install the distro's version, or otherwise take pains to make sure it doesn't muddy the waters. If this is not sufficient understanding, please re-ask the question. The note from Martin Spott on 02/05/2010 03:33 PM indicates that he understands the issues. >> -D LIB_POSTFIX="" Actually I suspect that should have said -DLIB_POSTFIX:STRING="" since OSG is using cmake these days. Another workaround -- the one I actually prefer -- is to let OSG live under .../lib64/ but add LDFLAGS="$LDFLAGS -L$parent/usr/lib64" \ LDFLAGS="$LDFLAGS -L$parent/usr/lib" \ ./configure to the SG and FG ./configure invocations. Both of these workarounds fall into the category of undocumented expert incantations. Neither is a good substitute for actually fixing the autoconf setup. = Please consider this line of argument: Whenever the OSG libraries are truly missing or truly misplaced, the FG ./configure script behaves as it should. It prints a user-friendly error message You *must* have the OpenSceneGraph support library installed on your system to build this version of SimGear! and then exists without writing any makefiles. It is interesting that when OSG is installed under lib64/, ./configure can find the libraries long enough to decide *not* to throw any errors. I take this as quite strong evidence that the OSG libraries are not missing and are not misplaced. Alas, ./configure blissfully proceeds to write makefiles that cannot find those libraries. This is a bug. The bug is not hard to reproduce. The bug is almost certainly a problem for anybody who compiles OSG from source downloaded from the OSG site. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] configurator plebis
Let summarize a few obvious points: 1) Everybody who is participating in this conversation is doing so in order to help ordinary non-expert users. None of use will directly benefit from any cleanup in the autoconfiguration scripts. Everybody on this list is an expert. We all figured out years ago how to configure, compile, and link FG. We do not need to explain to each other how to do it. As a related point, the whole effort toward making a new "release" depends on people who want to help ordinary non-expert users. Almost everybody on this list could happily use the development version forever. 2) Consider the following use-case scenario. Think about it from the viewpoint of Joe Schmoe, somebody who does not have as much skill or as much luck as the people on this list. -- Joe has a fairly standard 64-bit Linux box. -- Joe configures, compiles, and installs OSG from source, "straight out of the box" according to the directions. So far so good. -- Joe configures, compiles, and installs plib "straight out of the box" according to the directions. So far so good. -- Joe configures simgear "straight out of the box" according to the instructions. The ./configure script says the configuration is correct. However the configuration is not correct. The makefiles generated by ./configure produce link errors. This is a bug. This is so obviously a bug that I am embarrassed to discuss it. Yes, you can get FG to compile "out of the box" if you compile OSG using a completely undocumented non-obvious option. This is entirely true but it entirely misses the point. On the other side of the same coin, you can configure OSG "out of the box" if you are willing to configure FG with completely undocumented non-obvious options. This, too, is entirely true but entirely misses the point. Instead the point should be that Joe Schmoe is going to have a bad experience. When the simgear "make" fails at a late step, Joe is going to have little idea what went wrong, and less idea how to fix it. The fact that *I* know how to fix it is not the point. The fact that ten other people on this list know how to fix it is not the point. The ./configure script is supposed to check that all the right libraries are found. If they are not found it is supposed to print an informative, user-friendly message. If they are found, it is supposed to remember where they were found and then build a makefile that knows about them. The current ./configure script does not meet specifications. This is a bug. It is not a problem for me, but it is a problem for Joe. 3) See item 1. The only reason we are having this conversation is because we want to be unselfish. We want to make things better for Joe. 4) There's a lot more I could say about this, but I'll stop here for now. If anybody has further questions, please ask. === If you are wondering about the Subject line: http://en.wikipedia.org/wiki/Tribunus_plebis -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/05/2010 03:17 PM, Curtis Olson wrote: > Do you have details of the configure or make error you are seeing posted > somewhere? Yes. Please take a look at http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit As it says there: make[1]: Entering directory `/mnt/games/orig/fgs/tests' g++ -DHAVE_CONFIG_H -I. -I../src/Include -I/games/orig/usr/include -I/usr/local/include -g -O2 -I/games/orig/usr -D_REENTRANT -MT est-epsilon.o -MD -MP -MF .deps/est-epsilon.Tpo -c -o est-epsilon.o est-epsilon.cxx mv -f .deps/est-epsilon.Tpo .deps/est-epsilon.Po g++ -g -O2 -I/games/orig/usr -D_REENTRANT -L/games/orig/usr/lib -L/usr/X11R6/lib -L/usr/local/lib -o est-epsilon est-epsilon.o -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm -losgFX -lglut -lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -lrt -ldl -lm /usr/bin/ld: cannot find -losgFX collect2: ld returned 1 exit status The problem is not confined to the tests/ directory. If I let the make continue, there will be numerous errors. Basically every "ld" step fails. Additional root-cause analysis can be found on the aforementioned web page. If you need more details than that, please let me know. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configuration snafu
On 02/05/2010 02:38 PM, Curtis Olson wrote: > I don't doubt that there could be some lib vs. lib64 inconsistencies, but > FilghtGear builds right out of the box for me on 64bit Fedora 12 ... no > hitches at all that I recall and it has done so for quite some time. Chez moi plib and simgear install into lib/ while osg installs into lib64/ How do you get around that? How do recommend I get around that? Obviously there are ways, but the only ways I know are complicated and devious ... not exactly out-of-the-box. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] severe erosion of the terrain
On 02/05/2010 11:26 AM, leee wrote: > Are those clouds on the horizon or is it distant scenery? Scenery. Mountainous terrain. Clearly recognizable as such. No clouds anywhere: METAR 012345Z 0KT 99SM CLR 15/M01 A2992 > If it's > scenery then funnily enough, back in Feb2008, I reported a bug > where exactly the opposite seemed to be happening i.e. the scenery > was ok up to a radius of about 12nm around the aircraft but was > invisible beyond that. Was that ever reproducible? Was a fix ever devised? Has anybody tried to reproduce the erosion issue? It remains 100% reproducible chez moi. -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] [patch] Write pid into property tree and optionally into a file.
Two closely-related new features:
property: /sim/pid
option: --pid=/pathto/some/file.pid
Having the pid available is useful for many purposes,
including sending a signal for debugging.
Somebody should please check that this works under MSVC.
It looks to me like pretty standard c++ but it's still
good to check.
commit cc188f7499c03417b1d4a3cb296702ba7b4d67fa
Author: John Denker
Date: Fri Feb 5 10:12:15 2010 -0700
Write pid into property tree and optionally into a file.
diff --git a/src/Main/main.cxx b/src/Main/main.cxx
index d5ac553..38202e4 100644
--- a/src/Main/main.cxx
+++ b/src/Main/main.cxx
@@ -885,6 +885,7 @@ bool fgMainInit( int argc, char **argv ) {
upper_case_property("/sim/presets/runway");
upper_case_property("/sim/tower/airport-id");
upper_case_property("/autopilot/route-manager/input");
+fgSetInt ("/sim/pid", getpid() );
// Scan the config file(s) and command line options to see if
// fg_root was specified (ignore all other options for now)
diff --git a/src/Main/options.cxx b/src/Main/options.cxx
index 3b4354f..9eb41b5 100644
--- a/src/Main/options.cxx
+++ b/src/Main/options.cxx
@@ -39,6 +39,7 @@
#include // strcmp()
#include
+#include /* ofstream */
#include
#include
@@ -1234,7 +1235,20 @@ fgOptFgviewer(const char* arg)
return FG_OPTIONS_OK;
}
-
+static int
+fgOptPid(const char* arg)
+{
+pid_t pid = getpid();
+ofstream out;
+out.open(arg, ofstream::out);
+out << pid << endl;
+out.close();
+if (!out.good()) {
+ SG_LOG(SG_GENERAL, SG_ALERT,
+ "Unable to write pid (" << pid
+ << ") to file '" << arg << "'");
+}
+}
static map fgOptionMap;
@@ -1449,6 +1463,7 @@ struct OptionDesc {
{"version", false, OPTION_FUNC, "", false, "",
fgOptVersion },
{"enable-fpe", false, OPTION_FUNC, "", false, "",
fgOptFpe},
{"fgviewer",false, OPTION_FUNC, "", false, "",
fgOptFgviewer},
+{"pid", true, OPTION_FUNC, "", false, "",
fgOptPid },
{0}
};
--
The Planet: dedicated and managed hosting, cloud storage, colocation
Stay online with enterprise data centers and the best network in the business
Choose flexible plans and management services without long-term contracts
Personal 24x7 support from experience hosting pros just a phone call away.
http://p.sf.net/sfu/theplanet-com
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] configuration snafu
I'm glad to see people are cleaning up the autoconf stuff. Here's yet another area that needs some TLC: There appears to be little or no chance that the autoconf system will do the right thing on 64-bit machines. I'm hoping this will be easy for some autoconf guru to fix. I would imagine there are well-known standard techniques for coping with lib/lib64 issues. This is currently item #45 on this list of bugs: http://www.av8n.com/fly/fgfs/htm/bug-list.htm#bug-64bit -- The Planet: dedicated and managed hosting, cloud storage, colocation Stay online with enterprise data centers and the best network in the business Choose flexible plans and management services without long-term contracts Personal 24x7 support from experience hosting pros just a phone call away. http://p.sf.net/sfu/theplanet-com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
