Re: [Flightgear-devel] Grass Runway Textures
Matthew Law wrote: Speaking of which, would it be possible to change the texture above a certain height AGL? We could have a texture with more detail for low altitudes and a shinier, more gaussian texture for higher altitudes... Just like real grass and short crops. Grass rarely reaches more than one meter AGL :-) Different textures for grass growing at different altitudes AMSL would make some sense, but I think you are talking about changing the material properties of the ground cover according to the aircraft's height AGL ... but that shouldn't make a difference to the shininess or the sharpness of the specular reflection (which is what I am guessing you mean by more gaussian; do I misunderstand?). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: Proposed Changes to Airport Data Files
David Megginson wrote: I'd like to propose the following changes to our current airport data formats: 1. In $FG_ROOT/Airports/basic.dat.gz (the airport-level data file), add two fields containing the ISO 3166 country code and a country-specific region code. Either can be represented by 'U' if unknown. For example, here is the current entry for KSFO: A KSFO 37.618763 -122.37492613 CYN San Francisco Intl Here is a revised entry with the new fields: A KSFO 37.618763 -122.37492613 US CA CYN San Francisco Intl It seems *awfully* redundant given that there is already the Id *and* the geographical location. I have difficulty imagining that a high enough proportion of these will be determined and maintained to make it worthwhile. I do see why you want it though, and agree it would be nice to be able to get a list of airports in my region, by name of region rather than by lat/lon. This change will allow us to create airport dialogues sorted by country and (optionally) state/province/region. Initially, we can just set every one to 'U', or possibly apply some simple heuristics (every four-letter airport identifier starting with 'K' is in the U.S., every four-letter airport identifier starting with 'CY' is in Canada, etc.) 2. In $FG_ROOT/Airports/runways.dat.gz (the runway-level data file), add two new record types, 'W' for windsock and 'C' for control tower. The W record would look like this (where 'S' stands for 'sock' rather than the other thingy, and 'L' stands for 'lighted): R KABC 29.650236 -96.579416 176.00 SL The 'C' record would give the latitude, longitude, and view elevation of the control tower: C KABC 29.651347 -96.580527 315.00 Yep, lovely. Those two look good to me. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] web site updates
David Luff wrote: On 9/30/03 at 4:11 PM Curtis L. Olson wrote: Norman Vine writes: Curtis L. Olson writes: Andrei Barbu has revamped the flightgear web site layout and made quite a few improvements. I have placed the proposed changes here: http://www.flightgear.org/www.andrei/ Cool but all I get from the above link are 404s Both IExplorer and Mozilla You are too slow .. :-) Now you have to go to http://www.flightgear.org/ to see the changes. :-) Minor nit - the internal links within the FAQ are broken - they all need an 'l' added ie .htm#4.1 - .html#4.1 Or preferably they don't mention the file name: just a href=#4.1. The name of it (linked from the main page) should be FAQ not Faq. The logo at the top of the FAQ is not found (wrong relative directory path). Also on the screen shots page. I agree with Norman that there should be something on the front page that says what Flight Gear is, and some general intro to the web site, not just a latest news column. docs.html has its two columns beginning several pixels further down the screen than they do on the other pages. There is a nice clean look to the new site. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] web site updates
Cameron Moore wrote: * [EMAIL PROTECTED] (Curt Olson) [2003.09.30 13:57]: Andrei Barbu has revamped the flightgear web site layout and made quite a few improvements. - No DOCTYPE specification[1] ... [1] http://www.w3.org/QA/2002/04/valid-dtd-list.html Yes - please check that the pages are valid HTML by visiting the World-Wide Web Consortium (W3C)'s HTML Validator at http://validator.w3.org/ - and then fix the problems that it reports until they are valid. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] key bindings - English
Richard Bytheway wrote: That appears to be a US English keyboard, A UK English has and @ transposed, as well as £ where # is on a US keyboard (both called a pound sign though). You might call the hash (or 'gate' or 'number sign') a 'pound sign', but I don't. As far as I know, the only reason people ever started to call it that was because they had the same character code in different character sets, and therefore a hash was often printed where a pound sign was intended. Correct me if I'm wrong. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Meaning of scale (e.g. 1:1000000) in digital data
Norman Vine wrote: vmap0 can be off by ~500 meters and still be considered accurate since it is 1:1,000,000 Every time I see a map scale ratio like 1:100 for digital mapping data, I am confused. For a paper map it means 1 length unit on the map represents 100 length units in real life, but a line segment in digital data has no fixed length: it can be drawn to any arbitrary scale by the display software. I assume there is a convention about what a scale ratio means in digital mapping. Please can someone enlighten me? Then I might be able to understand the first part of that statement (about the accuracy). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] objects lifetime
Matevz Jekovec wrote: I was thinking of the way we could ommit lifetime for our terrain and scenery objects. For e.g. if we get a WTC towers models or some other historical buildings one day, we cannot place them into year 2003. What if every object has a timestamp - an interval from when to when certain object lies in time. For WTC twin towers should be from 1972/1974 to 2001 then. For e.g. our house, from 2000 and on etc. We could also place these timestamps to the terrain vertices, roads, rivers if they have changed over time and even textures for them (this way, the cities in 1800 wouldn't be large as nowadays). e.g. highways in our country have changed the terrain drasticly in last 10 years! Cause another e.g. if we implement a dynamic campaign (war) some day, we could really make a simulation of a historic battle in 1945, using certain units hiding behind certain buildings standing in that time etc. For modelers I don't think this should pose a large problem as they probably know enough about the building they are modeling and their timestamp. For the terrain, this is a bit more complicated though. In practice, when you'd run fgfs only, you would be placed in present, but if you run fgfs --date=19990815, you would be placed in August 1999. Just a brainstorm idea, but what do you think? That's a lovely idea, and doesn't sound too hard to implement. Well, for a first stage of support for this, anything in the scenery would require a scenery re-build which is a bit of a pain but still worth playing with. Second stage of support: run-time selection at program start-up, like with the command-line option --date. That would require some changes (possibly major changes) to the way scenery is handled. Third stage of support: during the simulation, the objects are dynamically built/demolished/altered when the appropriate time comes. Not sure that that third level is necessary, but it would be fun to watch. :-) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] --ceiling option
David Megginson wrote: I've added a new option to set an overcast ceiling quickly on the command line: --ceiling=FT_ASL[:THICKNESS_AGL] ..THICKNESS_FT ? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Julian Foad [EMAIL PROTECTED] said: I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. You would if you were unable to trim because the step sizes were to big and you wanted to trim from the joystick. Yes, OK, but we're going to avoid that by making sure that the update rate is high enough when a slow computer is heavily loaded, and perhaps faster otherwise. I'll re-phrase my objection as: I wouldn't want the trim wheel to spin much faster when looking at the sky than when looking at complex scenery. 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. Only not good enough if you insist that the joystick configs work the same and on all systems without adjustment. Yes, but I think that is a reasonable thing to request if it can be done without breaking your requirement for ultimate smoothness, and it can. For the time being, I am in favour of Melchior's patch, with a fixed update frequency of (say) 100 Hz, or perhaps 120 Hz if the FDMs are fixed at that frequency. That was Erik's patch. Sorry for the misattribution, Eric. What I'd like to do, if this is what everyone wants, I'm having difficulty understanding this part; please bear with me trying to clarify what you mean. is to add a property to the joystick binding structure called interval-sec That defines the repetition interval for a repeating step action? (to be used on the bindings that have low/high defined--axis emulation). If it is defined then use it (or default it to zero). If it is defined then update the specified axis and its two virtual buttons at the specified interval. If it is not defined, then default to the standard system-wide value that we are talking about elsewhere: something like 0.01 s. Yes? That way only the bindings that require such timing (e.g. rudder controls) will be affected. You mean that you would specify interval-sec0.01/interval-sec for the rudder because you want it to move at a fixed rate, but you would leave some other controls to move at a rate that varies with CPU speed and load? If this is because of the insufficient resolution problem, I think we can solve the resolution problem. If we have a problem of the resolution being insufficient because we need to specify a large step size because updates are too slow, then I think we can solve that by making the update rate fast; no longer equal to the frame rate, but fixed at say 100 Hz or the FDM rate. If this is acceptable then I'll work on adding this to the patch. I can see that virtual buttons at the end of an axis have been left out of this patch so far. I would say they should behave in the same way as real buttons, so something needs to be done. But let's see if we can find a common solution. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Melchior FRANZ [EMAIL PROTECTED] said: That would be =all= repeatable bindings then. The change of view direction/elevation simulates head movement. Braking simulates feet movement on pedals. Mixture ... you get the point. Every set of repeatable buttons emulates (analog) human-machine interaction. I cannot imagine why head movement should be ten times as fast on a faster machine. It's still the same pilot. Not all pilots are the same. Some heads are faster than others. That's a completely separate issue. And even though some like to use the mouse for trim wheels, I like the joystick hat. And I like it speedy and high resolution for accurate trimming. Lets just do it with the bindings that are presenting real problems, and stop worrying about slowing down the fast machines so they match the slower machines. I don't agree. I've completed the patch (took less time than writing these last two emails on the subject). All you need to do is specify: interval-sec0.05/interval-sec for the binding in question and you will get a 20 per second repeat rate. It works. If this makes sense to anyone besides myself, I'll submit the patch. It only makes sense to me as a temporary improvement over the status quo. I don't think it makes sense for any repeatable bindings NOT to have a known rate of change (either fixed step size and fixed update frequency, or fixed rate of change with a variable update frequency). But I haven't written code to implement what I'm saying. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Jim Wilson wrote: Julian Foad [EMAIL PROTECTED] said: have the binding specify the amount of change PER SECOND (i.e. the rate of change), and allow the number of steps per second to vary with machine power and load. At each step, the new value is calculated so that the control is moving at the specified rate: value += rate * delta_t. That would make the rate of change well defined, but the smoothness would be better on faster machines. I f Jim wants to control the update frequency he can then do so very easily. But the important thing to do first is to define the rate of change rather than the amount per undefined time step. This is a sounds good. But it is possible that some controls might be better off sacrificing speed for higher resolution step sizes on certain systems (e.g. trim controls). It is possible, but I can't think of any examples. I wouldn't want the trim wheel to run slowly when my computer is heavily loaded. That would just be a nuisance. After all, any computer since the 1980s has enough power to operate these controls with plenty of speed AND smoothness if the software is written appropriately. One way to increase resolution without sacrificing speed is to use acceleration: when you press the key, the control moves slowly to begin with and then speeds up. This is very appropriate for knobs on the instrument panel, because a real-life knob can be turned both slowly-and-accurately and fast. Then again we could pick and chose which controls use the per second method and which use the fixed steps (in other words, support both). We could, but do you really want to use fixed steps at a variable rate for your trim control or for anything else, given alternatives? As I mentioned earlier...controlling the update frequency doesn't seem necessary to me right now. I agree. So the proposals are: 1. Specified step size; undetermined step time. This is what we have now and isn't good enough. 2. Specified step size; fixed step time (e.g. 0.01 second). This actually means that the step size implies the rate of change. 3. Specified rate of change. As far as the binding is concerned, the specified rate in bananas per second is equivalent to the step value in (2) but a factor of 100 bigger; or it could be specified in bananas per centisecond so that the specified value is exactly the same as the step value in (2). As far as the implementation is concerned, we have the freedom to implement it as a fixed-frequency update, or a variable-frequency update. The only differences between (2) and (3) as far as the user is concerned are a possible factor of 100 difference in the value specified in the binding (no big deal) and the fact that step always guarantees that the control moves in whole multiples of the specified step. Is this latter point important? I think it might be relied upon by the radio tuning controls, for example. Therefore (2) is a safer method. Other enhancements like acceleration are independent of this choice and can be added later. Choice of update frequency: A. Fast enough to capture the duration of the button press fairly accurately. About 20 to 40 Hz corresponds to human accuracy in my opinion. B. Smooth enough for control purposes. If a flight control position is updated less frequently than the FDM calculations at running, then the aircraft will shake. Should update at the FDM rate or a multiple of it. C. Smooth enough for visual feedback (where the control being moved is directly visible). Should update at the frame rate or a multiple of it. In order to match the update rate to the FDM rate and/or frame rate, if those can vary, then proposal (3) would be required. For the time being, I am in favour of Melchior's patch, with a fixed update frequency of (say) 100 Hz, or perhaps 120 Hz if the FDMs are fixed at that frequency. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
Melchior FRANZ wrote: What are repeatable buttons used for? - to let a digital input device (regular button, or digital hat switch) emulate an analog device What about keyboard buttons (keys)? Are they not going to work in the same way? Or are they already handled properly (FGFS implementing a fixed repeat rate while a key is held down)? I looked through all joystick config files and here is what repeatable buttons are used for: - set the view direction elevation via hat switch - set rudder elevator aileron trim - set engine boost mixture propeller pitch - set rudder (only in my own joystick file :-) (and brakes, you added) That's a useful list to look at. For instance, none of those things require to move in exact multiples of a specified step size, unlike the radio tuning which might. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: how to fix joystick config files
* Jim Wilson -- Saturday 28 June 2003 23:02: If I remember this patch correctly, the repeat frequency was hard coded. It should be defined in a property, and eventually adjustable in a gui dialog for controllers. Ideally at some point we could adjust sensitivity/repeat per control (individual buttons or axes). But at a minimum that single value should be a property. Melchior FRANZ wrote: So, in a joystick definition like the following ... what do you want the step size (-0.02) be set for? For a 2.8GHz CPU, or for a 266MHz CPU? It will be too small for a slow one, but too much for a fast one. This has to be a cpu clock independent value. I think Jim is assuming that the binding is going to specify a rate of change of value with time (bananas per second) rather than a step amount. This would be sensible, but is NOT what we have at present, and not the way Melchior is thinking about it, hence the misunderstanding. Then (I think) Jim is saying that the frequency at which these values are updated should not be fixed, but should be adjustable by the user, so the user can get better _smoothness_ (but the same rate of change) when the platform is capable of it. Is that right, Jim? But I'm really tired of this topic now and won't ever mention it again (except if people ask, why the joystick definition files that come with fgfs don't work on their computers, of course.) People aren't being deliberately obstructive. It's quite common for a misunderstanding like that to arise on a mailing list. I think what you are proposing is better than the way it is now. However, it should be easy to make it perfect. In your proposal, each binding specifies an amount of change per step, and you fix the number of steps per second (which previously was varying, being faster on faster machines). The objections are that the smoothness of control operation is limited by this fixed step rate. Instead of that, have the binding specify the amount of change PER SECOND (i.e. the rate of change), and allow the number of steps per second to vary with machine power and load. At each step, the new value is calculated so that the control is moving at the specified rate: value += rate * delta_t. That would make the rate of change well defined, but the smoothness would be better on faster machines. I f Jim wants to control the update frequency he can then do so very easily. But the important thing to do first is to define the rate of change rather than the amount per undefined time step. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Rsync access to base package and source?
I haven't updated for a few months and now I see the base and source CVS repositories have moved, although the old ones still seem to be responding (but presumably out of date). As I'm on a dial-up modem, I'm looking for a way to avoid a complete check-out (tens of megabytes - hours or days of download). So is rsync access available, and if so how do I access it? Google(site:flightgear.org rsync) only found old mailing list messages; nothing on the main pages of the web site. Secondly, is it possible (please?) to rsync to a copy that includes CVS/ directories so that after doing that I can then switch back to using cvs update? Thirdly, I notice that the repository name includes the version number (-0.9). So each time a new version is released, you start a new repository and developers have to do a fresh checkout (I don't think a script to convert the CVS metadata would be possible, as the revision numbers would change.) I don't think this is normal; is it intentional? Thanks. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Return of the BPCVS
Arnt Karlsen wrote: On Sun, 02 Feb 2003 19:39:28 -0500, John Check [EMAIL PROTECTED] wrote in message [EMAIL PROTECTED]: Base package cvs is back, now with more cvsweb http://rockfish.net/cgi-bin/cvsweb/ ..imaginary folder like directory icons? ;-) I see this effect too. No image is displayed by a HREF=FlightGear/img SRC=/doc/cvsweb/dir.gif ALT=[DIR] BORDER=0 WIDTH=20 HEIGHT=22/a; just an empty square. Maybe the path /doc/... is wrong or inaccessible. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] PATCH: validation of XML: materials.dtd etc.
I have updated materials.dtd and materials.xml so that they (almost) validate together using xmllint which comes with libxml: xmllint --dtdvalid materials.dtd -noout materials.xml The only bit that doesn't quite work is the params section which is allowed to contain arbitrary element tag names. I have defined its content as type ANY but xmllint complains that the tags in it are not known. Is there a way to define the contents of that element as not to be validated? Do people think that provision of DTDs for other parts (or the whole) of the property system is practical and useful? Anybody started? One important aspect is to make sure they actually get checked. We don't use a validating parser and I don't believe we can easily do so. I propose a Makefile in the base package where make check checks the DTDs and anything else that we can automate. The one attached checks the syntax of all the XML files in the base package and validates materials.xml against its DTD. Run it with: make --keep-going check to get past the errors (-- not allowed in comments) in some aircraft files to see the results for the DTD. I fixed one easy instance of the -- in comment error in an engine configuration file; patch attached. The others are harder to fix. - Julian # Consistency checks for the Flight Gear Base Package XMLLINT = xmllint -noout check: check-xml check-xml: check-xml-syntax check-xml-dtds check-xml-syntax: find . -name '*.xml' | xargs $(XMLLINT) check-xml-dtds: xmllint --dtdvalid materials.dtd -noout materials.xml .PHONY: check check-xml check-xml-syntax check-xml-dtds Index: materials.dtd === RCS file: /home/cvsroot/FlightGear/FlightGear/materials.dtd,v retrieving revision 1.1 diff -u -3 -p -d -r1.1 materials.dtd --- materials.dtd 2001/12/28 22:37:57 1.1 +++ materials.dtd 2003/01/05 23:10:20 @@ -8,10 +8,15 @@ properties in materials.xml. -- !ENTITY % colours r?, g?, b?, a? +!ENTITY % prop-attlist alias CDATA #IMPLIED -!ELEMENT PropertyList (material+) +!ELEMENT PropertyList (params?, material+) +!-- The params section contains arbitrary tag names which will be referred +to by alias attributes. -- +!ELEMENT params ANY !ELEMENT material (name+, texture, wrapu?, wrapv?, mipmap?, xsize?, ysize?, - light-coverage?, ambient?, diffuse?, specular?, emissive?) + light-coverage?, ambient?, diffuse?, specular?, emissive?, + shininess?, object-group*) !ELEMENT name (#PCDATA) !ELEMENT texture (#PCDATA) !ELEMENT wrapu (#PCDATA) @@ -24,6 +29,15 @@ properties in materials.xml. !ELEMENT diffuse (%colours;) !ELEMENT specular (%colours;) !ELEMENT emissive (%colours;) +!ELEMENT shininess (#PCDATA) +!ELEMENT object-group (range-m, object+) +!ELEMENT range-m (#PCDATA) +!ATTLIST range-m %prop-attlist; +!ELEMENT object (path+, coverage-m2, heading-type) +!ELEMENT path (#PCDATA) +!ELEMENT coverage-m2 (#PCDATA) +!ATTLIST coverage-m2 %prop-attlist; +!ELEMENT heading-type (#PCDATA) !ELEMENT r (#PCDATA) !ELEMENT g (#PCDATA) !ELEMENT b (#PCDATA) Index: materials.xml === RCS file: /home/cvsroot/FlightGear/FlightGear/materials.xml,v retrieving revision 1.35 diff -u -3 -p -d -r1.35 materials.xml --- materials.xml 2002/11/26 04:04:32 1.35 +++ materials.xml 2003/01/05 23:10:21 @@ -1,4 +1,5 @@ ?xml version=1.0? +!-- !DOCTYPE PropertyList SYSTEM materials.dtd -- !-- @@ -2614,8 +2615,6 @@ Shared parameters for various materials. xsize500/xsize ysize500/ysize light-coverage2000.0/light-coverage - xsize500/xsize - ysize500/ysize ambient r0.19/r g0.55/g Index: Engine/engIO470M.xml === RCS file: /home/cvsroot/FlightGear/FlightGear/Engine/engIO470M.xml,v retrieving revision 1.1 diff -u -3 -p -d -r1.1 engIO470M.xml --- Engine/engIO470M.xml2002/03/07 06:09:21 1.1 +++ Engine/engIO470M.xml2003/01/05 23:10:32 @@ -10,9 +10,9 @@ MAXTHROTTLE: maximum throttle setting (as before) MINTHROTTLE: minimum throttle setting (as before) -- -!--- +!-- From: http://www.google.com/search?q=cache:FoqW4cX9V6UC:www.skywagonranch.com/TDS/TCDS/E-273.DOC+Continental+O-470-M+spechl=en +-- FG_PISTON NAME=IO470D MINMP 6.5
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Dave Perry wrote: I just updated SimGear, FlightGear source, and base package from cvs. Now when I try to change frequencies, the numbers to the right of the decimal change mod 1, but the 1's, 10's and 100's didgits don't change. Yes, David changed it so that it is more like the real radio; one control (mouse left button) adjusts the sub-MHz part, and another (mouse middle button) adjusts the whole MHz. The left-and-right on the mouse is the opposite way round from the radio display; the logic is that the left button does the small adjustment and the middle button does a big adjustment, as it did before (though you may not have noticed). For those of us with a two-button mouse it's a little awkward; I've configured Xwindows to emulate a middle button when I press both together. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote: Julian Foad writes: I attach a patch which does these, and an update to navcom-radio.xml which specifies resolution appropriately and sets max to 118 or 136 instead of 117.95 or 135.975. Other files will need to be updated similarly; how is this for a start? It seems to work without skipping values. Committed -- thanks. OK -- thanks. I have now fixed up all the other XML files in the base package accordingly. But what have I got myself into? I have introduced special handling of discrete values (by specifying the new tag resolution), but I haven't resolved the inconsistencies between the four cases: - Analogue Clamped: min = x = max (this makes sense) - Analogue Wrapped: min = x max (this makes sense) - Discrete Clamped: not available (why not?) - Discrete Wrapped: min = x max (matches analogue case but is unintuitive) What we have is sensible behaviour for analogue values but not for discrete values. It is silly not to have Discrete Clamped behaviour available. The sensible definition of it, from the meaning of the word maximum, would be min = x = max. But it would also be sensible to be able to switch between wrapped and clamped without changing the value of max. Discrete Wrapped behaviour is now stable in the presence of floating-point error (when resolution is specified to mark it as being a discrete value), and its definition (meaning of max) matches the analogue case which I thought was a good idea. However, the meaning of max here is not the intuitive meaning of the word. I said before that the max value specified should not depend on the (variable) step size, but now we have a fixed resolution which it could depend on. We could specify min=108, max=117.95, resolution=0.05 unambiguously with an intuitive meaning of max. In this example the range finishes just before a round number, and it would be nicer to be able to write something like lessthan118/lessthan instead of max117.95/max. When the range finishes on a round number, such as (say) engine number 1 to 4 inclusive, then we want to write min=1, max=4 and for this to mean 1 to 4 inclusive, regardless of whether it is wrapped or clamped. This leads to: - Analogue Clamped: min = x = max - Analogue Wrapped: min = x max (we could allow or require lessthan instead of max) - Discrete Clamped: min = x = max or min = x lessthan - Discrete Wrapped: min = x = max or min = x lessthan This seems reasonable from a user's point of view, but at the cost of another new tag (lessthan). Is there a simpler way to handle discrete values? We could store the discrete value (e.g. radio frequency) as an integer (e.g. 108000 to 117950 kHz in steps of 50, or channel number 0 to 199). How would we _like_ to specify these? - frequency: min=108000, lessthan=118000, step=50 or 1000 (but doesn't lend itself to an analogue adjuster unless we also specify resolution=50) - channel: type=integer, min=0, lessthan=200 (wrapped or not) - channel: type=integer, min=0, max=199 (wrapped or not) - engine: type=integer, min=1, max=4 (wrapped or not) By storing a channel number rather than an frequency, we can make use of the existing property attribute type=int to provide the snap-to-valid-value behaviour, rather than the resolution tag. But then we have to convert the cahannel number to a frequency for display and for output. This also requires that the property manager handles integers in an appropriate manner, such as rounding to the nearest integer when converting from floating-point representation. So maybe that wouldn't be easier after all. What to do? Implement lessthan? Or don't implement any support for discrete values in the property-adjust commands, but let the radio-specific C++ code take care of it in the getter and setter functions tied to its frequency properties? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template class T
inline void SG_NORMALIZE_RANGE( T val, const T min, const T max ) {
T step = max - min;
while( val = max ) val -= step;
while( val min ) val += step;
};
That's effectively what we have (or had).
A proper version needs to be based on Interval Arithmetic we could just
snag a subset of the scalar functions from an existing package
http://www.ti3.tu-harburg.de/~knueppel/profil/docu/Profil.texinfo_19.html
Er ... we are not trying to do arithmetic on intervals. We are just
incrementing and decrementing a scaler value within an interval.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] main.cxx: glXGetProcAddressARB undeclared,and warnings
Norman Vine wrote: Julian Foad writes: main.cxx: In function `bool fgMainInit(int, char**)': main.cxx:1608: `glXGetProcAddressARB' undeclared (first use this function) Looking at the Mesa headers it seems as if GLX_GLXEXT_PROTOTYPES needs to be defined That works for me, adding it just before the #include, like this: #define GLX_GLXEXT_PROTOTYPES #include GL/glx.h Could someone check this in? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote:
Julian Foad writes:
I don't like to add more configuration and code, I like to pare things
down to the simplest correct implementation. But I think this snap to
valid value behaviour will be necessary.
I might have a go at an implementation. How do you feel about
specifying max using the min = x max rule in all cases?
That may work -- please let me know what you come up with.
OK. I think the best thing to do would be:
Firstly, change back to wrapping modulo the interval, with min = x
max semantics. I believe the previous implementation did that. The
inline function that Norman mentioned also does that.
Secondly, make it snap to the nearest value (min + N*resolution) when a
resolution tag is present, taking special care of floating-point
precision. Or perhaps specify number of divisions in the interval as
an integer, instead of resolution by which I meant a floating-point
size of a division.
I attach a patch which does these, and an update to navcom-radio.xml
which specifies resolution appropriately and sets max to 118 or 136
instead of 117.95 or 135.975. Other files will need to be updated
similarly; how is this for a start? It seems to work without skipping
values.
While working on this file I noticed some potentially serious warnings:
fg_commands.cxx: In function `bool do_property_adjust(const
SGPropertyNode*)':
fg_commands.cxx:435: warning: control reaches end of non-void function
fg_commands.cxx: In function `bool do_property_multiply(const
SGPropertyNode*)':
fg_commands.cxx:465: warning: control reaches end of non-void function
/usr/local/include/simgear/misc/props.hxx: At top level:
fg_commands.cxx:600: warning: `bool do_presets_commit(const
SGPropertyNode*)' defined but not used
And also the functions do_view_next and do_view_prev should probably be
static.
- Julian
Index: fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_commands.cxx,v
retrieving revision 1.13
diff -u -3 -p -d -r1.13 fg_commands.cxx
--- fg_commands.cxx 31 Dec 2002 18:26:06 - 1.13
+++ fg_commands.cxx 3 Jan 2003 23:13:07 -
@@ -11,6 +11,7 @@
#include simgear/debug/logstream.hxx
#include simgear/misc/commands.hxx
#include simgear/misc/props.hxx
+#include simgear/sg_inlines.h
#include Cockpit/panel.hxx
#include Cockpit/panel_io.hxx
@@ -39,22 +40,6 @@ SG_USING_STD(ofstream);
-/**
- * Template function to wrap a value.
- */
-template class T
-static inline void
-do_wrap (T * value, T min, T max)
-{
-if (min = max) { // basic sanity check
-*value = min;
-} else if (*value max) {
-*value = min;
-} else if (*value min) {
-*value = max;
-}
-}
-
static inline SGPropertyNode *
get_prop (const SGPropertyNode * arg)
{
@@ -105,12 +90,21 @@ limit_value (double * value, const SGPro
if (min_node == 0 || max_node == 0)
wrap = false;
-if (wrap) { // wrap
-if (*value min_node-getDoubleValue())
-*value = max_node-getDoubleValue();
-else if (*value max_node-getDoubleValue())
-*value = min_node-getDoubleValue();
-} else {// clamp
+if (wrap) { // wrap such that min = x max
+double min_val = min_node-getDoubleValue();
+double max_val = max_node-getDoubleValue();
+double resolution = arg-getDoubleValue(resolution);
+if (resolution 0.0) {
+// snap to (min + N*resolution), taking special care to handle imprecision
+int n = (int)floor((*value - min_val) / resolution + 0.5);
+int steps = (int)floor((max_val - min_val) / resolution + 0.5);
+SG_NORMALIZE_RANGE(n, 0, steps);
+*value = min_val + resolution * n;
+} else {
+// plain circular wrapping
+SG_NORMALIZE_RANGE(*value, min_val, max_val);
+}
+} else {// clamp such that min = x = max
if ((min_node != 0) (*value min_node-getDoubleValue()))
*value = min_node-getDoubleValue();
else if ((max_node != 0) (*value max_node-getDoubleValue()))
Index: navcom-radio.xml
===
RCS file: /home/cvsroot/FlightGear/FlightGear/Aircraft/Instruments/navcom-radio.xml,v
retrieving revision 1.4
diff -u -3 -p -d -r1.4 navcom-radio.xml
--- navcom-radio.xml2002/12/30 19:48:04 1.4
+++ navcom-radio.xml2003/01/03 23:13:01
@@ -286,7 +286,8 @@ properties' values.
maskdecimal/mask
step-0.05/step
min0.00/min
-max0.95/max
+max1.00/max
+resolution0.05/resolution
wraptrue/wrap
/binding
/action
@@ -304,7 +305,8 @@ properties' values.
maskinteger/mask
step-1/step
min108/min
-max117/max
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
Norman Vine wrote:
Julian Foad writes:
Norman Vine wrote:
This is the poor man's version taken from sg_inlines.h
// normalize a value to lie between min and max
template class T
inline void SG_NORMALIZE_RANGE( T val, const T min, const T max ) {
T step = max - min;
while( val = max ) val -= step;
while( val min ) val += step;
};
That's effectively what we have (or had).
Close but not quite
Do you mean the fact that it brings values into range even if they are
more than one interval size away from the valid interval? That is a
fair comment, not affecting anything at present but nice for stability
(robustness) in the face of unknown future applications.
Or do you mean something else?
and may not solve all of your perceived problems
My main perceived problem was that as floating-point errors accumulated,
~135.0 + ~1.0 will eventually become less than (136 - epsilon) which
would give a wrong radio frequency of 135. instead of wrapping round
to 118.0 or 135.0 or whatever. (136 MHz is not a valid frequency for
the COMM radio.)
The use of (analogue) circular wrapping like SG_NORMALIZE_RANGE provides
does not help prevent accumulated error. But the snap-to-valid-value
logic that I also proposed does.
and you are right about the had :-(
I'm suggesting to put it back ... or actually to use SG_NORMALIZE_RANGE.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
I (Julian Foad) wrote: I attach a patch which does these, ... ... It seems to work without skipping values. Ooh, I hate it when people say it seems to work. It sounds so sloppy. What I meant is I designed it and analysed it very carefully, and then did just a quick test to confirm that it behaves as expected and doesn't have any obvious silly bugs. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
David Megginson wrote: Julian Foad writes: I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. freq. 0 to 140; this should be 118 to 140. But while playing with that I noticed that the wrapping is a bit unpredictable. With (min=118, max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK Pooley's Flight Guide confirms that the range is 108.00 to 117.95 inclusive. But the current implementation that specifies (min=108.00, max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, 108.00, 108.05) skipping 117.95. Yes, it was a mess. I've done some refactoring of the built-in property-adjust and property-multiply commands, and things work better now. I added a 'mask' argument that can take a value decimal to modify only the decimal part or integer to modify only the integer part. That means that the radio tunes more like a real KX-155 (or similar), at least if your panel is using navcom-radio.xml -- the left button adjusts the decimal part and the right button adjusts the integer part. I've also fixed the COM radio frequency range in that file. That's good to hear. Wrapping should also be simpler and more predictable. Ah, well ... It's good to see it factored out into a single place (limit_value). But I don't think it's predictable because floating-point imprecision can still break it (118.025 - 0.025 is sometimes a bit less than 118.000 and therefore becomes 135.975). Also, different kinds of wrap are wanted in different situations: (1) A circular value (e.g. heading, 0 to 360 degrees). The min value is considered to have the same meaning as the max value (both mean North). In this case the old behaviour, addition modulo 360, was correct and appropriate (so that 358 degrees plus a step of 5 becomes 003 degrees), giving a smooth rotation. Floating-point imprecision is not a problem: it doesn't matter whether 359 + 1 becomes 359.9 or wraps to 000.1, because they mean the same thing. In case (1) it is appropriate for the controlled range to be min = x max (not min = x = max), so that the specified min and max values are independent of the adjustment step size. Otherwise you would have to specify max=359 when step=1 but max=355 when step=5, and what when the step isn't known until run time? (2) A range where the bottom and top values do not mean the same. E.g. radio frequency whole MHz, 118 = x 136, which could also be stated as 118 = x = 135 when the step size is 1. It is important that the boundary values are stable in the presence of floating-point imprecision: 117.99 must not wrap to 135.something. The precision limit must be taken into account. In case (2) I can imagine wanting (in different situations) several different wrapping sequences. E.g. on an arbitrary control range of 100 to 200, step size 10: - Circular:190-100-110 / 193-103-113 / 103-193-183 / 110-100-190 - Hit first limit: 190-200-110 / 193-200-110 / 103-100-190 / 110-100-190 - Hit both limits: 190-200-100 / 193-200-100 / 103-100-200 / 110-100-200 - etc. In the case of an analogue value these all have ambiguities or flickering behaviour at their limits and I can think of no realistic requirement for any of them. In the case of a discrete value, I consider that all such sequences could be desirable in some situations, but the circular mode with min = x max covers the present (radio tuning) requirement well and can cover other requirements and is semantically simple. Discrete Values and Precision These definitions work for analogue and discrete values. However, when dealing with a property that takes only discrete values (e.g. the comm. radio frequency, usually at a resolution of 0.025 MHz) one could wish that at every step the value would be rounded off. Indeed, that will probably be necessary to prevent cumulative error from becoming larger than the floating-point precision limit epsilon and thus messing up the wrapping behaviour. One could always round values in the range (min +/- epsilon) to exactly min, and (max +/- epsilon) to exactly max. But that is only effective when the user takes the value to its limits, which might be never, so I don't think that's worth implementing. To avoid accumulating error, and also to round off grossly-wrong values (like 118.02 up to 118.025) would require the resolution to be specified separately: you can't say the value must be a multiple of the step size, because a control is often adjusted in steps of 5 or 10 times its resolution. Do we need to handle grossly-wrong values? Not when adjusting by pre-programmed increments as we do at present, but if we were to drag an analogue adjuster we would probably want it to click into place. Therefore I think that this method (snapping to (min + N*resolution)) will be necessary sooner or later. (The same semantic
Re: [Flightgear-devel] Radio frequency range: min/max/wrap
I (Julian Foad) wrote: and, unless it is tackled, I'm pretty sure floating-point imprecision will result in users sometimes being unable to set an end-point value like 118.000 MHz. Not actually unable to, because they can go back to 135.975 and then forward to 118.000. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] main.cxx: glXGetProcAddressARB undeclared, and warnings
Can anybody help with this error? Anyone care to fix the warnings? Making all in Main In file included from main.cxx:91: ../../src/ATC/ATCmgr.hxx:201: warning: extra qualification `FGATCMgr::' on member `FindInList' ignored main.cxx: In function `void fgRenderFrame()': main.cxx:443: warning: unused variable `const SGPropertyNode*longitude' main.cxx:445: warning: unused variable `const SGPropertyNode*latitude' main.cxx:447: warning: unused variable `const SGPropertyNode*altitude' main.cxx: In function `bool fgMainInit(int, char**)': main.cxx:1608: `glXGetProcAddressARB' undeclared (first use this function) main.cxx:1608: (Each undeclared identifier is reported only once for each function it appears in.) main.cxx: In function `void fgLoadDCS()': main.cxx:1906: warning: unused variable `ssgVertexArray*lights' make[2]: *** [main.o] Error 1 SuSE 8.1, GCC 3.2. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] What's in the job jar?
David Megginson wrote: Cleanup is always, always needed -- ... We are slowly trying to get all of the parts of FlightGear to extend FGSubsystem (defined src/Main/fgfs.hxx) and to simplify the top-level loop in src/Main/main.cxx. That sort of top-level stuff really is best done by the top-level guys and gals who are familiar with the whole project - you, Curt, etc. - in order to encapsulate the subsystems, to enable other people (especially new-comers) to work more easily on any one subsystem. Not that Mike couldn't do some of it, but in general I wouldn't recommend it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 3D model origin proposal
Jon S Berndt wrote: Well, with proper agreement and reference point, we can make this perfect. There's just some communication and cooperation needed for a little while, and I think we are nearly there. Yes. I think several people are unclear about how this will work, and have concerns like If we make the nose the reference point, then the aircraft will appear to wag because the viewer code doesn't know about the offset. That won't happen if we identify a communication problem within the software and fix it properly. The way I see it is: WHAT TO DO: Wherever an aircraft position* is sent from one part of Flight Gear (e.g. an FDM) to another part (e.g. the part that positions the graphical model in the scene graph), we must define exactly what that position means as part of the definition of the interface function or variable or property, AND ALSO modify the data provider if necessary to ensure that it provides that particular position, and modify the receiver if necessary to ensure that it converts the position it is given into the position that it really wants. (Don't worry about the performance cost of two extra 3D transforms per frame.) Example: - We choose first to tackle the aircraft position reported by FDMs to Flight Gear. - We choose the tip of the nose for that particular interface, and write position of tip of nose in a comment by the declaration, or preferably incorporate NoseTip into the name of the function or variable or property. - In this example Jon would leave most of JSBsim as it is, generating the position of the centre of gravity, but he would add a little function to convert position of C of G to position of nose just before publishing the value to Flight Gear. - Someone would modify the function that updates the Flight Gear scene graph so that it puts the model geometry at the right position, by transforming from position of nose to origin of geometry (which will be different for each aircraft geometry model). Similarly, any other parts of Flight Gear that use this data must be checked and modified if necessary. HOW TO DO IT: We need data for the 3D transforms. Jon would need to know the position of the nose relative to the C of G, and he would probably get this in two or three steps: transform from C of G to the aero reference point, which he knows already; and then transform from the aero reference point to the nose. This relative position will have to be added to the JSBsim config files if it cannot be calculated from data already there. On the other side, putting the geometry into the scene graph at the specified position will involve converting from position of nose to origin of geometry; that transform would need to be read from the geometry file or the aircraft config file. Clearly the reference point for an interface should be one that both sides can reasonably understand. It is likely that it will have to be specified (differently) on both sides of the interface: nose relative to aerodynamic origin, and nose relative to geometry origin. It is not practical to get all FDM authors AND all geometry authors to use the same origin natively. By precisely defining an interface and providing the conversion offsets as data in an appropriate place, we can eliminate the errors. There is no need for arbitrary approximations to occur by design of the Flight Gear program architecture, but approximations may still occur due to lack of data. For example, to avoid having to update all config files at once, we might put in the geometry-reading subsystem something like if this geometry file does not specify the position of the nose, then use the average vertical coordinate and the front-most horizontal coordinate. Then move on to another interface, such as the camera/eye position, and go through the same thing. Where do we want the camera or eye to be (or to be looking towards)? Do we have the information that specifies the eye position relative to a known position? If not, it must be added to the aircraft config file (probable for the eye position) or calculated at run time (possible for a camera look-at point). Perhaps Curt or David M could kick-start the process by defining the meaning of one of those interface functions. You can't ask an FDM author to choose the reference point because they are all biased, and none of us lesser mortals would dare submit a patch for such a wide-reaching change. But if we want to share models across different FDMs then this work will have to be done. * Note that wherever I said position or point I should have said coordinate system or set of axes to include orientation as well, because especially the pitch attitude of an aircraft could easily suffer the same kind of ambiguity. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] control reaches end of non-void function
Among many warnings I noticed this in FGPanel::doMouseAction: panel.cxx:583: warning: control reaches end of non-void function - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Voice ATIS
David Luff wrote: I've managed to get canned voice ATIS going. Wow! Brilliant. It really works! It sounds about like I'd expect, too (e.g. the 8 kHz-ness). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Today's new segfault
William Earnest wrote: With the compile problems resolved, still getting a consistent segfault just after Done reading panel instruments. The other Didn't you say earlier that you are using Red Hat's GCC 2.96? Isn't that the broken version? I don't know the details, but I think Red Hat released a broken unofficial GCC 2.96 about a year ago, whereas GCC 2.95 is the official stable version. (Or version 3.2, but that's a big change which probably requires updating other packages to match it.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
David Luff wrote: David Luff writes: Is it likely to work over a 56K modem? Well, it mostly worked. After starting in an area with no scenery, it took a couple of minutes waiting before the appropriate airport came down, and FlightGear could be restarted properly. Flying the C172, terrasync mostly kept up, but in both my tests (one in the bay area, one in the relatively sparser UK) managed to miss one tile. I may be mistaken, but it appears to download a whole 1x1 degree area at once in alphabetical order, and there were times when nothing was coming down, I had a very similar experience. I think the pauses were because the rsync server was busy; one or two local rsync processes were always active, but often seemed to be waiting for data. The local TerraSync would create another immediately when I killed them. I then switched airports, but it did not cancel the current rsync processes so nothing was fetched for the new location until all the outstanding fetches completed (or, in fact, were killed by me). so I think that if the order of the tile download within a 1x1 chunk was optimised to get the closest first, That would be more difficult. In the normal (intended) scenario, when you have already got the current degree chunk, it doesn't matter much in what order it fetches the insides of the chunk ahead, so Curt just asks rsync to get the whole directory. Cancelling outstanding rsync processes would also be considerably more difficult (to do portably). and if downloading was continued almost continuously based on position and heading, then I'm quite sure it could be made to keep up no problem. I think that is what it is trying to do already. Very impressive stuff anyway. Absolutely. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Flightgear-devel digest, Vol 1 #1173 -15 msgs
Jason Grace wrote: Could someone help me compile the stuff once and for all? I've been trying to get it to compile on Cygwin for a year, so I can contribute. You quoted hundreds of lines of a message digest. I don't know if something in it was relevant to your question. If you could provide details of a specific problem, people would be glad to help. We certainly don't want you to be struggling like this, and certainly it can be compiled and run on CygWin. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Getting 'rsync' working through a firewall is pretty difficult. You could try to build 'rsync' with 'socks' support, but even then not every firewall supports 'socks'. So I dare to point at the fact that this utility might be pretty useless for several users. If you are _allowed_ to be playing / using Flight Gear at work, then you can try asking your network administrator to enable rsync protocol. Point out to them that it provides basically the same sort of access (the way they see it, in terms of security, abuse, etc.) as FTP, and if they allow FTP they should allow rsync as well. If you're not allowed, but hope to get away with it via the company email and web facilities provided, well, maybe you need to work for a games company instead. :-) [Note: I'm in this position of having FTP but not rsync at work. But I can't think of a good reason why I should be allowed to run Flight Gear, or any other justification for requesting rsync access.] - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrasync 3rd party util
Lovely stuff! terrasync.cxx needs these to compile on my GCC 3.2 / SuSE system: SG_USING_STD(cout); SG_USING_STD(endl); In the usage example in README.txt it would be nice to suggest a port in the private use range (49152-65535), such as 55000, instead of port 5500 which is allocated to someone's particular protocol. Not that it's likely to cause a problem in practice, but to avoid future trouble. The same applies to the existing FG and Atlas documentation. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Erik Hofman wrote: Julian Foad wrote: No. I am only suggesting changing the default value for the pitch offset, not the way it is used to calculate pitch which is and would still be ... Hmm, okay. If you are sure it works, then I see no objections. It may require a few changes in the exsisting sound configuration files and the documentation shouldprobably be updated to reflect this change. I will first make sure that each pitch in the configuration files has an explicit offset, so that they do not rely on the default. In fact, there is only one without an offset, and it is the A4's whine sound. Did the author realise that the default offset was 1.0? The 747's whine has an offset of 0.1 specified. Does the A4's whine sound right as RPM varies? I suspect that an offset of 0, or close to 0, would be better. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Code
Jon Berndt wrote: Is there a way to determine which methods/attributes in a class are unused by anybody? I'm thinking maybe there's a utility out there somewhere or a link directive. This would assist in code streamlining/cleanup. Other than grep :-) You can browse through lists of references, looking for empty lists, in a source browser like the ones in MS Visual C++ and Source Navigator (formerly by Red Hat, now a SourceForge project). In MSVC you can only browse, as far as I know, but Source Navigator is open-source and uses Perl or Python scripts to do much of its user interface, so it's probably not hard to get it to output the list of unreferenced symbols. Others IDEs like KDevelop list definitions and declarations but not references. Getting the linker to tell you is an interesting idea that I haven't looked into. Perhaps you could do this manually by listing the public symbols in each library first, and then in the linked application, and comparing the two lists. Or perhaps you can make one list of all the exported symbols from the application and its libraries, and another list of all the imported symbols, and compare those. The unix utilities nm and objdump can list symbols in object files and libraries. I haven't come across a utility specifically for doing this, but I'd be interested. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Megginson wrote: Julian Foad writes: Ah, glad you're there. If you're interested and have time to look, my current attempt is at http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff What's the current status of these? They're only ideas in progress, and are not right. Please don't put them in CVS as they are. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Luff wrote: It looks to me like you've got 2 too many curly brackets in doEnginePower, although I could be misunderstanding what you're doing there. Yes, I have got too many. This is the friction that was applied only when starting; I was making it permanent but haven't finished with it. Do you agree that it should be permanently in? Does a constant torque sound about right? That sounds more likely than constant power (which means decreasing torque), to me. Conventional friction would give constant torque; I'm not sure how oil and air viscosity behave, but I'd expect the torque to increase at higher speeds rather than decrease. I don't understand how it could have worked with no resistance implemented. A propeller hardly provides any resistance at low speeds, so I would have thought you would have needed to tweak the developed power down to almost zero at idle. What I am concerned about is the throttle minimum being set to 0.2. ... Ah, thank you for explaining this. I had not understood the mapping onto manifold pressure and the power correlation. It certainly sounds like the power correlation is the thing to un-tweak instead! This puzzled me: the manifold pressure seems to be modelled as (for a given throttle position) independent of speed. When a real engine is running fast and you cut the throttle, the fast air flow will cause a very low manifold pressure which will then rise to its new steady value as the engine slows down. Without this effect, throttle changes will not take effect as quickly as they should and the speed variation with load changes will not be right. Maybe the effect is too small to be important? I might be attempting too much here; I know how car engines work but don't have data to work from (or a lab), and I don't have experience of modelling them either. I will tread carefully and check with you again when I make some more progress. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Sound vol/pitch transforms are like panel x/y/r transforms
Fg_sound.cxx implements a way to control the volume and pitch of a sound specified in an XML config file. The optional steps in the volume control group are (and the pitch group is the same): - A variable value: one of A named property An internal special value (e.g. time since the sound started) - Transformed by a function: one of Inverse Absolute Square root Logarithm - Scaled by a (constant) factor - Clamped to (constant) max and min - Added to a (constant) offset These all have sensible (no-change) defaults (except for anomaly 1 below). This group can be repeated; the results are multiplied together except for the offsets which are all added afterwards. Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. The instrument panel transformations (x-offset, y-offset, rotation) have these optional steps: - A variable value: A named property - Transformed by: An interpolation table - Clamped to (constant) max and min - Scaled by a (constant) factor - Added to a (constant) offset These all have sensible (no-change) defaults. This group cannot be repeated. Hey, it's slightly different! How about we scrap the differences and the anomalies and combine them? To do so, I'd suggest: - Leave the handling of the internal special values in the sound module, or find a way to present them as properties. - Add the Interpolate option to the list of functions (Inverse etc.). - Swap the order of Scaling and Clamping in (probably) the sound module (because there are fewer uses there). - Lose the pitch offset bug and the negative scaling factor hack. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is needed, a general expression evaluator would be better than providing one specific way to combine sub-expressions. For example, I would like to be able to use property values for the things that currently have to be constants. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS gripes
David Luff wrote: On 11/11/02 at 9:38 PM Matthew Law wrote: I've been having problems updating Simgear for a few days. I've tried everything - including moving the lot and starting again but it continually gets stuck at: cvs server: Updating src-libs U src-libs/.cvsignore U src-libs/Makefile.am U src-libs/metakit-2.4.3-33.tar.gz U src-libs/zlib-1.1.4.tar.gz U src-libs/zlib.dsp and goes no further. I have no problems updating the fgfsbase or FlightGear CVS. I don't use compression on CVS (e.g. -z3 etc) as this did seem to cause some unpredictable behaviour in the past. I don't usually have any problems so I just wanted to check with you guys before looking over my box. Given that src-libs/zlib.dsp is the very last file to be updated, and that you don't really need it to be updated anyway if you've already installed zlib, I would think it would be fine simply to hit ctrl-c when it gets stuck at this point and assume that SimGear itself has updated fine. FWIW, I also sometimes see this hang-up behaviour at the end, but so far only when using compression. Yes, I find it's a compression problem too. I have compression set at the default in my ~/.cvsrc so I use cvs -z0 up to update FlightGear (source), SimGear and TerraGear (which are all on the same server and are the only projects with which I have this problem). I used to think it was CygWin-specific but it's just the same on Linux. So, if you're sure -z0 is in effect, I can confirm that hitting Ctrl-C works OK on a cvs update. However, doing a cvs diff blah.diff, Ctrl-C is not good: you lose the end of the diff file. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Sound vol/pitch transforms are like panelx/y/r transforms
Erik Hofman wrote: Julian Foad wrote: ... Anomalies: 1. The pitch offset defaults to 1, but I think that is just a bug. 2. Since the offsets are constant, it is redundant to specify more than one. This arrangement is therefore not ideal, but I'm not sure what would be best. 3. A negative scaling factor is only useful in the first group. This appears to be an unnecessary restriction. (The comment says Hack!) The restriction can easily be removed and the code will be simpler for it. It's not. It is a hack because the behaviour of the part is totally different from the rest. By this hack you would be able to start at the offset level and then scale down according to the property value and the factor. That's why 2. isn't correct either ... Not totally different. Quite similar. Have you looked at the code? The way I read it, a negative value causes the (scaled, clamped, etc.) value to be subtracted from the offset rather than added to it. That is exactly the same as just using a negative scaling factor. The only differences are: - For negative, you want the default offset to be 1; - For positive, you might want the default offset to be 1 or 0 depending on what you are doing! - When the subtraction is done it forgets any value generated by a previous volume group, which means it's only useful in the first group (e.g. the first volume transformation of potentially several volume transformations). OK, I did not notice the need for offset=1 in subtractions. However, this should be the case for volume just the same as for pitch. You don't want the volume to be subtracted from zero either. - Lose the pitch offset bug and the negative scaling factor hack. It's not a bug. A value with a pitch of 0.0 would have a frequency of 0.0 which isn't allowed and can't be heard. It actually should be 1.0! Offset=0 doesn't necessarily mean pitch=0. For example I want pitch=(K * propeller_rpm). When RPM=0 I don't care if pitch=0; I know it doesn't make sense, but volume will be zero too. Maybe the internal sound player algorithm will have to limit the minimum pitch to something other than zero, but that shouldn't stop me from requesting it to be as near as possible to zero. - Decide whether multiple transformation groups are needed, and if so, how they should be combined. I feel that, if more flexibility is They are needed to add an envelope to the sound. It is for example possible to start playing a sound based on a property, and change it's behaviour based on another property (change it's pitch and/or volume). No, we could have that ability with one volume transformation and one pitch transformation per sound. (These are separate from the sound on/off property.) I'm asking whether we need more than one transformation of each type. May I send a patch to fix sound anomalies 1 and 3, anyway? (I always like doing the little easy bits first.) Neh, better not. OK, I agree it's not as simple as I first thought. I'll think more carefully. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Luff wrote: On 11/10/02 at 4:02 AM Julian Foad wrote: Ah yes, starting, I seem to recall a lot of hacking and kludging to get everything to work :-) There's a number of problems currently: ... Have fun :-) Ah, glad you're there. If you're interested and have time to look, my current attempt is at http://www.btinternet.com/~julianfoad/fgfs/JSB_piston_engine.diff http://www.btinternet.com/~julianfoad/fgfs/engine_sound.diff but, as I said, not finished. (Well, it will never be finished. I mean not completely satisfactory as a patch yet.) It removes some of the arbitrary bits - especially the non-linear bits like if RPM N then ... - and makes starting and idling nicer (especially at throttle less than the minimum allowed idle setting - it was fun running it below 500 RPM, on the unstable side of its power curve, after I put the friction always present but before I put the idle adjust constant in there). - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Yasim origin and model offsets
Andy Ross wrote:
Jim Wilson wrote:
Anyway, what I now remember is this: the camera position as configured
for the chase view is always in relation to the FDM location. And in
the case of Yasim that location is always the nose.
Oh, good point. This will create problems for view direction too --
the viewer will expect to rotate around the center of the aircraft
instead of the nose.
But there are other places in the code that make assumptions about the
location of the aircraft, too, and they have different requirements.
...
Or consider an ILS receiver, which really wants to use the location of
the antenna on the 747, not the cockpit, c.g., or center. (I have no
idea where this is, but I suspect it's closer to the tail, so that the
main gear are what travel down the exact glidepath). Maybe we need
separate origin offsets for all of these applications?
For some of them, definitely. The viewer (eye, camera) position for
internal view must be quite precisely positioned, not just at the centre
of the airframe. Also the altitude (AGL) of the wings for modeling
ground effect. Many other things (measuring altitude for display,
position relative to radio beacons, etc.) would be fine using any origin
that is within the airframe.
Actually, wouldn't a sane default for the view code be to *always*
pick a center point for the offset? That is, just pick the center of
a bounding box computed from the model (or the FDM). This will match
more closely to what the user expects in all cases I can think of.
That would be suitable for the external views. The centre of gravity
would also be fine. Use whichever is more conveniently available; there
are already enough origins to choose from so don't calculate another
unless it is necessary.
It seems clear what ought to be done. Whenever a point on the aircraft
is used for some calculation, it should specify exactly what point is
required. The apparent obstacles to doing this are:
+ the required information is not available
+ concern about the run-time cost of additional calculation
+ the effort of thinking about what is required and implementing it
These can be tackled separately. For the first point, write stubs for
the missing information so that it can be easily added later. Instead
of this:
// Calc additional lift due to ground effect.
// Not sure exactly what FDM-getLocation() is supposed to return but it
// is about 1.2m below the C172's wings.
// Need to generalise this for other aircraft.
lift += calcGroundEffect(getTAS(), FDM-getLocation().height + 1.2);
write this:
// Calc additional lift due to ground effect.
lift += calcGroundEffect(getTAS(), getCentreOfLift().height);
Search for other bits of code that might already need the same
information. If there are none, make a stub function at the top of the
file (or somewhere more appropriate if you can):
// Stubs for missing information
vec3 getCentreOfLift() { return FDM-getLocationEmptyCofG() + 1.2 /*
this is for C172 */; }
If there are already one or more uses, share the function.
For the second point, consider the run-time cost it in context. If it
is expensive and the exact position is unimportant, make the stub do
nothing, with a comment saying why.
Surely each aircraft geometry definition should be obliged to specify
the position of the things we are interested in:
+ eye position of an average pilot (for internal view)
+ centre of lift (for ground effect)
+ nose, tail, wing tips (for crash detection, and for placing the model
not overhanging the end of a runway)
+ landing gear when fully extended, and its compression behaviour (for
ground handling)
+ centre of gravity when empty, and location of variable masses (fuel,
people, baggage)
The definition file would specify these things relative to its own
origin. If we cannot or do not wish to require all of these to be
specified, the Flight Gear class that reads the model definitions could
be made to guess reasonable values for the ones that are missing.
These statically specified offsets are all constant relative to the
rigid airframe. At run time, we can provide variable ones as well:
class AircraftGeometry {
// Get location of various points as an offset relative to some
arbitrary origin.
// User doesn't need to know what the arbitrary origin is; only
differences between
// these offsets are meaningful.
vec3 getOffsetPilotEye(); // constant
vec3 getOffsetCentreOfLift(); // constant in simple models; may be
variable
vec3 getOffsetNoseTip(); // constant
vec3 getOffsetLeft/RightWing/Tail/etc.();
vec3 getOffsetNoseGearExtended(); // constant
vec3 getOffsetNoseGearCurrent(); // variable
vec3 getOffsetEmptyCentreOfGravity(); // constant
vec3 getOffsetCurrentCentreOfGravity(); // variable
// and/or
vec3 getOffsetContactPoint(int n);
vec3 getOffsetVariableLoad(int n);
float getMassOfVariableLoad(int n);
// etc. as required.
}
Actually,
[Flightgear-devel] SimGear patches for GCC 3.2: memrchr and typename
I had to remove a declaration of memrchr from simgear/metar/Local.h to
compile under gcc 3.2 (SuSE Linux 8.1). There are lots of semi-standard
functions declared there that probably shouldn't be.
To fix some warnings I added typename into some typedef lines. I am
not sure about the correctness or the portability of these - especially
the typename additions. Can anyone evaluate these?
These were the errors:
c++ -DHAVE_CONFIG_H -I. -I. -I../../simgear -I../..
-I/usr/X11R6/include -O1 -finline-limit-256 -finline-functions -Wall
-pedantic -Wpointer-arith -D_REENTRANT -c -o Charcmp.o `test -f
'Charcmp.cpp' || echo './'`Charcmp.cpp
In file included from Charcmp.cpp:1:
Local.h:1118: declaration of `void* memrchr(const void*, int, unsigned
int)' throws different exceptions
/usr/include/string.h:72: than previous declaration `void* memrchr(const
void*, int, unsigned int) throw ()'
and warnings:
SkyBVTree.hpp:217: warning: `typename SkyBaseBVTreeObject,
BoundingVolume::BV' is implicitly a typename
SkyBVTree.hpp:217: warning: implicit typename is deprecated, please see
the documentation for details
(etc.)
- Julian
Index: simgear/metar/Local.h
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/metar/Local.h,v
retrieving revision 1.1.1.1
diff -u -3 -p -d -r1.1.1.1 Local.h
--- simgear/metar/Local.h 7 Sep 2002 02:58:19 - 1.1.1.1
+++ simgear/metar/Local.h 10 Nov 2002 19:28:47 -
-1115,7 +1115,7 int stregion(int);
int ccregion(char *);
char *rgnname(int);
-void *memrchr(const void *, int, size_t);
+//void *memrchr(const void *, int, size_t);
bool sysmonms(char *, char *, ...);
bool sysmoncl(char *);
Index: simgear/sky/clouds3d/SkyBVTree.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTree.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTree.hpp
--- simgear/sky/clouds3d/SkyBVTree.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTree.hpp 10 Nov 2002 19:28:49 -
-214,9 +214,9 class SkyBVTree : public SkyBaseBVTreeO
{
public:
typedef SkyBaseBVTreeObject, BoundingVolume BaseTree;
- typedef BaseTree::BV BV;
- typedef BaseTree::NodeObject NodeObject;
- typedef BaseTree::Node Node;
+ typedef typename BaseTree::BV BV;
+ typedef typename BaseTree::NodeObject NodeObject;
+ typedef typename BaseTree::Node Node;
void Clear()
{
Index: simgear/sky/clouds3d/SkyBVTreeSplitter.hpp
===
RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/sky/clouds3d/SkyBVTreeSplitter.hpp,v
retrieving revision 1.2
diff -u -3 -p -d -r1.2 SkyBVTreeSplitter.hpp
--- simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 14 Sep 2002 16:03:39 - 1.2
+++ simgear/sky/clouds3d/SkyBVTreeSplitter.hpp 10 Nov 2002 19:28:50 -
-52,7 +52,7 templateclass Object
class SkyBoundingBoxSplitter
{
public:
- typedef SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
+ typedef typename SkyBaseBVTreeObject, SkyMinMaxBox::NodeObject NodeObjectBox;
//typedef SkyBaseBVTreeObject, SkyBoundingSphere::NodeObject
NodeObjectSphere;
#if _MSC_VER == 1200
-183,7 +183,7 class SkyAABBTreeSplitter
{
public:
typedef SkyMinMaxBox BV;
- typedef SkyBaseBVTreeObject, BV::NodeObject NodeObject;
+ typedef typename SkyBaseBVTreeObject, BV::NodeObject NodeObject;
SkyAABBTreeSplitter(const NodeObject* pObjs, unsigned int iNumObjs) :
_splitter(pObjs, iNumObjs) {}
[Flightgear-devel] Keyboard braking power
It seems silly to have the brake key slam on full braking power, if it is to be used on the runway. No wonder the aircraft tend to tip over or burst their tyres. Can I recommend this patch which sets the all brakes strength to 0.5 and the individual left/right to 0.7? Personally I do the same for my joystick configuration, but since we've got so many joystick config files, we really need to separate the joystick configurations from the commands that they control in order to be able to change things like this consistently. - Julian Index: keyboard.xml === RCS file: /home/cvsroot/FlightGear/FlightGear/keyboard.xml,v retrieving revision 1.37 diff -u -3 -p -d -r1.37 keyboard.xml --- keyboard.xml2002/11/07 16:30:39 1.37 +++ keyboard.xml2002/11/10 04:29:52 -276,7 +276,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -303,7 +303,7 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.7/value /binding mod-up binding -678,17 +678,17 calculated by adding 256 to the GLUT key binding commandproperty-assign/command property/controls/brakes[0]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[1]/property - value type=double1.0/value + value type=double0.5/value /binding binding commandproperty-assign/command property/controls/brakes[2]/property - value type=double1.0/value + value type=double0.5/value /binding mod-up descRelease all brakes./desc
Re: [Flightgear-devel] Keyboard braking power
Andy Ross wrote: Julian Foad wrote: It seems silly to have the brake key slam on full braking power, if ... This issue came up about a year ago. There really isn't any good resolution. ... My favorite hack, FWIW, was to have the on/off input affect the braking power slowly -- over a second or two. That way you could ... Yes, you're right. That's quite a nice hack - but I see your point. I'm going through my differences from CVS trying to get rid of them by seeing how many would be wanted in CVS. It looks like this is one local modification that I'll just have to keep or delete. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Radio frequency range: min/max/wrap
I noticed that the radios had nav. freq. range 108.00 to 117.95 but com. freq. 0 to 140; this should be 118 to 140. But while playing with that I noticed that the wrapping is a bit unpredictable. With (min=118, max=140, step=1, wrap=true) adjusting it up and down, it sometimes skips 118 and sometimes skips 140. For the nav. frequencies, my 1991 UK Pooley's Flight Guide confirms that the range is 108.00 to 117.95 inclusive. But the current implementation that specifies (min=108.00, max=117.95, step=0.05, wrap=true) tends to cycle (117.85, 117.90, 108.00, 108.05) skipping 117.95. There is a problem with the way min and max work when wrap is on and discrete steps are being used. Wrap is designed for analogue values to go round in a circle where min and max are regarded as equivalent. On things like our radio frequency controls, it is down to luck (due to floating-point precision) whether (min=118, max=140, step=1) cycles through (139, 140, 119) or (139, 118, 119). Some of the directional instrument controls are specified as (min=0, max=359, wrap=true). These should, I think, all be specified as (min=0, max=360, wrap=true), so that it doesn't skip 359, because in this case the min/max are the end points of an analogue range (not a set of discrete valid values). It doesn't matter whether it reads 360 or 0 for North. So: - Can anyone confirm the min. and max. settable com. frequencies on radios of this general type? I'm fairly convinced now that it must be 118.00 to 139.975 inclusive (or 139.95 on old models with 50 kHz spacing). - Do they wrap from one end of the range to the other? If not, it is easy to model properly. If they do, we need to look more carefully at the way the wrapping handles discrete steps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] data logging
Boslough, Mark B wrote: O.K. I've got a couple of new FDMs. 1) fdm=csv replays a flight from a csv file, running forward or backwards in time while controlling the rate. 2) fdm=skyhook, which lets you fly around as if hanging from a crane (sorta like magic carpet, but you can go backward). Have you tried --fdm=ufo? It can go backwards. Just want to check if you've done something that's already there. Hmm ... I see that it isn't mentioned in the --help. Ooops. But it does exist. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Engine models: start-up and commonality betweenFDMs
David Megginson wrote: I like the idea as well: it would be nice if the engine were its own subsystem and we could mix-and-match engines and FDMs (let's try the J3 cub with 180HP). Unfortunately, the FDM people haven't been too enthusiastic: in particular, JSBSim is supposed to run standalone as well as inside FlightGear, so they need some kind of internal engine model. Well, I suppose it needs someone to show how the two aims can be compatible. But it's not easy; it would require becoming familiar with both implementations and re-arranging the interfaces a bit. While that's the sort of thing I do at work, I'm not yet in a position to do it here. As for the guts of how the engines are modelled ... I first worked on the starting and stopping behaviour of the JSBsim engine. The thermodynamic model of the engine is probably very good but there's lots of yucky stuff there to do with starting etc. I've done some stuff there, and in the sound configuration, but not finished. I'll go into that later. Then I looked at the YASim piston engine to see how that handles starting. Before I try to do anything in there I want to ask about some things (Andy?): 1. PistonEngine::calc says // Calculate manifold pressure as ambient pressure modified for // turbocharging and reduced by the throttle setting. According // to Dave Luff, minimum throttle at sea level corresponds to 6 // manifold pressure. Assume that this means that minimum MP is // always 20% of ambient pressure. (But that's too much idle // power, so use 10% instead!) But we need to produce _zero_ // thrust at that setting, so hold onto the output value // separately. Ick. _mp = pressure * (1 + _boost*(_turbo-1)); // turbocharger float mp = _mp * (0.1f + 0.9f * _throttle); // throttle _mp *= _throttle; What's that bit about the separate output mp? An engine doesn't produce zero thrust at idle, just a low thrust. And manifold pressure isn't supposed to be related to thrust in a simple way, is it? Sorry to peer into a nasty bit. The beauty of Open Source is ... we can see the whole thing, warts and all! :-) 2. At the end of the same function, _egt = corr * (power * 1.1f) / (massFlow * specHeat); if(_egt temp) _egt = temp; When I'm running this at idle, _egt comes out at 80 (kelvin); presumably this should be added to ambient temp (which is 288) rather than clamped to it: _egt = corr * (power * 1.1f) / (massFlow * specHeat); _egt += temp; 3. The engine revs up and slows down very slowly. For example, when I cut the magnetos from 2000 RPM it takes over a minute to run down and stop. There is a negative torque added that should make it stop quickly, and I can't see what's wrong with it (that would have this effect). Actually, as acceleration of the engine is equally slow, perhaps the problem is in the transfer of the torque to the external propulsion system code - perhaps the wrong units? 4. That negative torque: Interpolate it away as we approach cruise RPMs, though, to prevent interaction with the power computations. Ugly. Actually, the only way the variable power is used after that point is to compute the EGT, and that wants to know thermally developed power anyway (i.e. excluding the starter motor contribution and the friction reduction) so that should be fine. I think it would be correct to subtract the torque loss at all speeds - in fact, more loss at higher speeds because of gas flow turbulence etc. By the way, the experimental values here were with j3cub-yasim because c172-yasim gives a solution failure for elevator. I have some local changes, but nothing in YASim or anything that I think could affect it - just in the JSBSim engine, sound handling, joystick, etc. For all this, my original aim was just to get simple things like a realistic cranking speed of about 100 RPM, and some rotation sound while the engine is spinning down after being switched off! - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote:
[about making the panel hot spots visible]
Try the attached patch, which predicates the boxes on the
/sim/panel-hotspots property.
That is excellent! So simple, and in conjunction with David's recent
zoom in/out/normal (+/-/=) bindings, it immediately makes clear what's
going on with the hot spots, and shows up the existing mistakes.
Everyone designing clickable instruments will benefit from this, so I
think your patch should go into CVS permanently.
I was just trying to sort some hot spots out by editing the numbers,
when I remembered that you'd just sent this patch. What a powerful tool
visualisation is!
- Julian
Index: panel.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.hxx,v
retrieving revision 1.2
diff -u -r1.2 panel.hxx
--- panel.hxx 29 Oct 2002 19:44:03 - 1.2
+++ panel.hxx 5 Nov 2002 21:38:59 -
-370,6 +370,7
virtual ~FGPanelInstrument ();
virtual void draw () = 0;
+ virtual void drawHotspots();
virtual void setPosition(int x, int y);
virtual void setSize(int w, int h);
Index: panel.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Cockpit/panel.cxx,v
retrieving revision 1.3
diff -u -r1.3 panel.cxx
--- panel.cxx 29 Oct 2002 19:44:03 - 1.3
+++ panel.cxx 5 Nov 2002 21:38:59 -
-436,6 +436,21
glPopMatrix();
}
+ // Draw yellow hotspots if directed to. This is a panel authoring
+ // feature; not intended to be high performance or to look good.
+ if(fgGetBool(/sim/panel-hotspots)) {
+glPushAttrib(GL_ALL_ATTRIB_BITS);
+glDisable(GL_DEPTH_TEST);
+glDisable(GL_TEXTURE_2D);
+glColor3f(1, 1, 0);
+
+for(int i=0; i_instruments.size(); i++)
+ _instruments[i]-drawHotspots();
+
+glPopAttrib();
+ }
+
+
// restore some original state
glPopAttrib();
glPolygonOffset(0, 0);
-647,6 +662,25
it++) {
delete *it;
*it = 0;
+ }
+}
+
+void
+FGPanelInstrument::drawHotspots()
+{
+ for(int i=0; i_actions.size(); i++) {
+FGPanelAction* a = _actions[i];
+float x1 = getXPos() + a-getX();
+float x2 = x1 + a-getWidth();
+float y1 = getYPos() + a-getY();
+float y2 = y1 + a-getHeight();
+
+glBegin(GL_LINE_LOOP);
+glVertex2f(x1, y1);
+glVertex2f(x1, y2);
+glVertex2f(x2, y2);
+glVertex2f(x2, y1);
+glEnd();
}
}
Re: [Flightgear-devel] Re: ExternalNet FDM
Martin Spott wrote: So the only command line change would be to go from --native=socket,in,30,,5500,udp --fdm=external to --native=socket,in,30,,5500,udp --fdm=null btw, do we have an 'official' port number assignment ? Over the time I read several suggestions by several members over the use of port 5500: --props=socket,bi,5,localhost,5500,tcp --nmea=socket,out,2,localhost,5500,udp --httpd=5500 --native=socket,in,30,,5500,udp --fdm=null [... maybe some more ...] It would be useful at least to postulate a FlightGear assignment - it does not have to meet RFC1340 Martin. Actually I don't think 5500 is a good idea - it is already assigned to someone else: fcp-addr-srvr1 5500/tcp fcp-addr-srvr1 fcp-addr-srvr1 5500/udp fcp-addr-srvr1 # Mark Zeiss [EMAIL PROTECTED] (see http://www.iana.org/assignments/port-numbers). Unless and until we have an assigned number, we should use a number from the Dynamic and/or Private Ports range: 49152 through 65535. So 55000 would be OK! Of course you can use any number you like on a private network (not connected to the Internet, and where you know that the port you choose is not in use by any other protocol) or when you know that the machines sending and receiving are not going to use that other protocol. There is actually a reasonabe chance that an assigned port number would be granted if we requested one. My company recently got one, even though I was expecting we wouldn't be able to justify the need for it. However, I don't think it would be appropriate until the protocol has settled down and been used for a while. So may I suggest changing the suggested number to 55000 in the documents that mention it? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: /controls/engine/ reorg
David Megginson wrote: A while ago, Curt suggested moving from ... and so on, to something more sane: /controls/engine[0]/ /controls/engine[1]/ /controls/engine[2]/ /controls/engine[3]/ Yes, lovely. Excellent. We could even go to /controls/engines/engine[0/ and so on to simplify the /controls/ top level further. No - we have that in some places, but I was thinking recently that it's not the right way to go. I think the only practical purpose is to reduce clutter in the browser; but the property browser could and should do this for us if we want it to. For example, it could display controls/ elevator engine[*] flaps ... and then, when the user clicks on it, expand it to controls/ elevator engine[0] engine[1] engine[2] engine[3] flaps ... or to controls/engine [0] [1] [2] [3] From an abstract point of view, engines/engine[n]/ could more succinctly be arranged as engines/n/ or engine[n]/ and this last seems to be the way the property manager was designed to handle it. Note that engines/engine[n]/ is identical to engines[0]/engine[n]/ which starts to look a bit silly again. Just my opinion. Also, could a similar thing be done with the engine output properties (mainly to drive the guages - RPM, temperature, etc.)? I can't think right now where they are at the moment. I have this vision of enabling the JSBSim piston engine and the Yasim piston engine models to be plug-in-compatible with one another. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Engine models: start-up and commonality between FDMs
I was having a look at the piston engine start-up code. I absolutely love the way it chugs away for a second or two and then coughs into life - the sound effects really make it - but I wanted to make the speeds and stuff more realistic. Looking at the JSBSim engine code, it uses lots of arbitrary speeds and time delays and abrupt transitions from one mode to another. I have some improvements to this. Much of this code in JSBSim is very similar to FDM/IO360.cxx which seems to be only used by LARCsim even though it is not in the LARCsim subdirectory; presumably one was derived from the other. I really don't like duplication; I feel that any work I do on one of them is half wasted if it isn't automatically shared by the other. And then there is Yasim's engine code. Three piston engine models, each specific to its own FDM. So I started thinking about deriving them all from a common PistonEngine interface with the aim of making the engine models interchangeable. Haven't gone anywhere down this road yet, though. Thoughts? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Clickable 3D panel
Lovely stuff. For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). So there are two places you can click to get the autopilot wing leveler button, or any other button. One where you can see the button, and another where the same button would appear on the other type of panel. A minor misalignment of some of the hotspots makes one or two controls a little awkward (e.g. COM1 tuning button). That is nothing to do with the 3D code; they are misaligned in the 2D view as well. That is, if you click just to the left of the centre of that knob it should decrease the digits but it increases them instead. A way to display the hot-spot outlines would be useful for checking and debugging ... don't know if that's as easy as it sounds though. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable 3D panel
Andy Ross wrote: Julian Foad wrote: For those who were wondering why it seems intermittently broken, what seems to be happening is the 2D panel hotspots are always active as well, and they pick up the mouse clicks as well (or instead, if the 2D hotspot area overlaps a 3D hotspot area). Are you sure? I thought this might be it too, and tried tracking it down. The 3D panels are loaded through the model code, and never get a chance to register themselves as the current_panel object in globals. Is there an invisible 2D panel loaded from somewhere else? FWIW, I still haven't been able to duplicate the rogue mouse click problem. Well, I'll put it this way: If I turn the 2D panel on and off with P while flying --aircraft=c172-3d, and note where a particular button is, and then turn it off so that only the 3D panel is visible, I can still click where the 2D button was as well as where the 3D button is visible. Clicking in either place has the same result of activating the feature. As I said, if the position of one of these invisible 2D hot-spots obscures a 3D hot-spot, then the 3D one appears not to be working, until you change view direction a bit or zoom so it is in a different area of the screen. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Clickable cockpit
Andy Ross submitted a patch which changes the way the HUD works. Norman Vine wants the old behaviour to remain available as an option. I really shouldn't get involved in this, but ... well ... here are my views. When a developer changes a program that is used by other people, he/she needs to consider the inconvenience that change may cause, and to minimise that inconvenience as far as is compatible with the other aims. Perhaps someone has developed other software which interfaces to FlightGear and will need to be changed to accommodate these changes. For example, Andy says he has inverted the sense of the compression tag to correct it. If the only configuration files that matter are under our control then he should supply a patch to fix them and the correction will be complete. If users are likely to have their own files which would, after this patch, be broken, he should consider fixing the problem in a backward-compatible manner, e.g. by deprecating the existing tag while introducing a new one. The important point is how to judge, for each little change, whether backward compatibility is worth the effort. Airing the proposed change and listening to objections is an OK way to do this. However, when the number of people objecting is small, the objection itself appears small unless it is backed up by reasons. Norman seems to be wanting backward compatibility in general, which may indicate that he _uses_ this flight simulator more than _plays_ with it, which is great. Unfortunately it takes a lot of effort to keep backward compatibility in every respect, and so the request is just wishful thinking unless it can be narrowed down to specific items of importance. Because Norman's skill and contributions to the project are respected, other developers want to keep the features that he values while still being able to develop the software and change things that don't seem right. If no progress is made soon, I recommend that the old behaviour option be implemented, and that Andy should modify the if statement so that it can be selected at run time. That would seem to satisfy the current objection, subject to the compatibility of the HUD configuration files being satisfactory. Then a separate patch to delete the old functionality can be proposed immediately, and the discussion of that can continue without holding up development in the short term. When the maintenance of that old codes becomes a hindrance, that will be an argument for removing it. At least, in the short term, it will be useful to have the old version available while any issues with the new version are resolved. Finally, I believe V. S. Renganathan did substantial work on the HUD for use in a research project. If anyone knows whether he is still interested in it, that might also be helpful. Please let the resolution be swift and easy so that developers will not be put off trying to change anything. - Julian Foad, Secretary, IASFGP (International Arbitration Service for Flight Gear Programmers) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ADF change?
Curtis L. Olson wrote: ... What would be really useful when you get into modeling push buttons is to be able to model a switch where it is true while the mouse is depressed and then immediately returns to false when the mouse button is released. Currently you need to click a second time to return the button to false. ... mod-up would seem to be the appropriate syntax. If that doesn't work for mouse buttons, perhaps making it work for mouse buttons would be better than inventing a new type of action. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear build failure: global_logstream/rstrip
With GCC 3.2 I get: Making all in DemChop make[3]: Entering directory `/home/julianfoad/src/TerraGear/src/Prep/DemChop' saveoutp c++ -O1 -finline-limit-256 -finline-functions -Wall -pedantic -Wpointer-arith -L/usr/X11R6/lib -o demchop demchop.o ../../../src/Lib/DEM/libDEM.a -lsgbucket -lsgmisc -lsgdebug -lsgxml -lz -lm demchop.o: In function `main': demchop.o(.text+0x52): undefined reference to `global_logstream' demchop.o(.text+0x7f): undefined reference to `global_logstream' demchop.o(.text+0x8c): undefined reference to `global_logstream' demchop.o(.text+0xa4): undefined reference to `global_logstream' demchop.o(.text+0xe9): undefined reference to `global_logstream' demchop.o(.text+0xef): more undefined references to `global_logstream' follow ../../../src/Lib/DEM/libDEM.a(dem.o): In function `FGDem::read_a_record()': dem.o(.text+0x423): undefined reference to `simgear::strutils::rstrip(std::basic_stringchar, std::char_traitschar, std::allocatorchar const)' collect2: ld returned 1 exit status PLIB and SimGear were built from today's CVS, and installed. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] TerraGear bits and pieces
I am carrying some local changes to TerraGear which probably ought to go
into CVS. Patch attached. They are just minor and cosmetic fixes;
nothing that affects the generated scenery.
- Julian
Index: acinclude.m4
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/acinclude.m4,v
retrieving revision 1.1
diff -u -3 -p -d -r1.1 acinclude.m4
--- acinclude.m428 Aug 2002 14:13:51 - 1.1
+++ acinclude.m424 Oct 2002 14:26:38 -
-102,7 +102,7 for exdir in $exdirs ; do
mylibdir=${exdir}/lib${subexdir}
wi_EXTRA_LDIR($mylibdir)
- progdir=${exdir}/bin${subexdirr}
+ progdir=${exdir}/bin${subexdir}
wi_EXTRA_PDIR($progdir)
fi
done
Index: configure.ac
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/configure.ac,v
retrieving revision 1.5
diff -u -3 -p -d -r1.5 configure.ac
--- configure.ac18 Oct 2002 22:25:45 - 1.5
+++ configure.ac24 Oct 2002 14:26:40 -
-240,6 +240,8 fi
AC_MSG_CHECKING(for proper simgear version)
AC_TRY_RUN([
+#include stdio.h
+
#include simgear/version.h
#if !defined(SIMGEAR_VERSION)
-256,7 +258,8 AC_TRY_RUN([
int main() {
int major, minor, micro;
-printf(%d.%d.%d or greater... , MIN_MAJOR, MIN_MINOR, MIN_MICRO);
+printf(need %d.%d.%d, have %s... , MIN_MAJOR, MIN_MINOR, MIN_MICRO,
+STRINGIFY(SIMGEAR_VERSION));
sscanf( STRINGIFY(SIMGEAR_VERSION), %d.%d.%d, major, minor, micro );
Index: src/Airports/GenAirports/rwy_prec.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Airports/GenAirports/rwy_prec.cxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 rwy_prec.cxx
--- src/Airports/GenAirports/rwy_prec.cxx 22 Mar 2002 15:05:54 - 1.3
+++ src/Airports/GenAirports/rwy_prec.cxx 24 Oct 2002 14:26:41 -
-88,7 +88,7 void gen_precision_rwy( const FGRunway
double length = rwy_info.length / 2.0;
if ( length 3075 ) {
SG_LOG(SG_GENERAL, SG_ALERT,
- This runway is not long enough for precision markings!);
+ Runway rwy_info.rwy_no is not long enough (
+rwy_info.length ) for precision markings!);
}
double start_pct = 0;
Index: src/BuildTiles/Parallel/client.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/BuildTiles/Parallel/client.cxx,v
retrieving revision 1.11
diff -u -3 -p -d -r1.11 client.cxx
--- src/BuildTiles/Parallel/client.cxx 30 Jan 2002 14:10:00 - 1.11
+++ src/BuildTiles/Parallel/client.cxx 24 Oct 2002 14:26:43 -
-200,7 +200,7 bool construct_tile( const SGBucket b,
for (int i = 0; i (int)load_dirs.size(); i++) {
command = command + + load_dirs[i];
}
- command = command + + result_file + 21;
+ command = command ++ result_file + 21;
cout command endl;
system( command.c_str() );
-253,7 +253,8 usage (const string name)
cout--host=address endl;
cout--port=number endl;
cout--rude endl;
- cout--cover=landcover-raster ] endl;
+ cout--cover=landcover-raster endl;
+ cout--min-angle=degrees ] endl;
cout load directory... endl;
exit(-1);
}
Index: src/Lib/Geometry/line.cxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.cxx,v
retrieving revision 1.4
diff -u -3 -p -d -r1.4 line.cxx
--- src/Lib/Geometry/line.cxx 14 Aug 2002 15:41:54 - 1.4
+++ src/Lib/Geometry/line.cxx 24 Oct 2002 14:26:46 -
-48,7 +48,7 Line::addPoint (const Point3D point)
_points.push_back(point);
}
-const Rectangle
+Rectangle
Line::getBounds () const
{
Point3D min;
-68,11 +68,9 Line::getBounds () const
if (_points[i].y() max.y())
max.sety(_points[i].y());
}
-return Rectangle(min, max);
}
- Rectangle bounds;
- return bounds;
+ return Rectangle(min, max);
}
};
Index: src/Lib/Geometry/line.hxx
===
RCS file: /var/cvs/TerraGear-0.0/TerraGear/src/Lib/Geometry/line.hxx,v
retrieving revision 1.3
diff -u -3 -p -d -r1.3 line.hxx
--- src/Lib/Geometry/line.hxx 14 Aug 2002 15:41:54 - 1.3
+++ src/Lib/Geometry/line.hxx 24 Oct 2002 14:26:46 -
-82,7 +82,7 public:
*
* return The bounding rectangle.
*/
- virtual const Rectangle getBounds () const;
+ virtual Rectangle getBounds () const;
private:
vectorPoint3D _points;
Re: [Flightgear-devel] FlightGear 0.8.0 on Win98SE
Jacek M. Holeczek wrote: ... There are two problems with the joystick. First, there are two vertical bars/arrows in the cockpit for the elevators, but only the right one is following the joystick (the left one always stays in the middle) - however, if I view the plane from outside I can see that both (left and right) are moving up/down. This is correct: the right-hand indicator is indicating elevator position, but the left-hand indicator is indicating elevator trim, which can be adjusted with numeric keypad 7 and 1 (or is it 9 and 3) and possibly with joystick buttons/hat switch if the joystick configuration file says so. Second - both the aileron and elevator quite often misbehave - what I observe is that when I move them then appropriate bars/arrows are also moving, but every now and then the bars/arrows suddenly jump to the neutral position (and so they quite often jump between the actual joystick position and the neutral position). This can also be seen when I view the plane from outside - indeed ailerons and elevators are jumping - this makes the steering quite difficult. I monitored the joystick with an external utility and this utility does not show such problems, so it must be the software. I did not observe such problems with the rudder, but ... maybe it is just the lack of experience. That sounds like both the joystick and some other input device are trying to drive the controls at the same time. The other device might be the mouse, which has three modes, indicated by three different cursor shapes. Clicking the right-hand mouse button cyles around the three modes. When the cursor is a normal pointer, it is for pointing and clicking on menus and the panel controls. When it is a cross (+), it is in control of the elevators and ailerons - perhaps that is what you have. When it is a double arrow (=) it controls the view direction, for looking around. Hope this helps. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] dc3 pannel lights
Curtis L. Olson wrote: [EMAIL PROTECTED] writes: Agreed. Instruments that test whether they are powered should default to powered if the aircraft does not provide a suitable electrical system. This could translate to if the required power bus property is not present. A simple default electrical system that provides just a main bus would only satisfy instruments that connect _directly_ to the main bus. I know that David disagrees with me on some of this, but my view is that the electrical system should provide common named outputs. Hang on ... I don't think these are mutually exclusive options. Woudn't you agree that, as well as standardising on bus names as much as possible, it would be good to smooth the transition from always-on to having a proper electrical system, by making all instruments default to on if they have been modified to check whether power is provided but have been plugged into an aircraft which does not yet specify any electrical system? For instance, panel lights would always check /systems/electrical/outputs/panel-light-power or something like that. And the green navigation light would check /systems/electrical/outputs/nav-lights-power and the turbofan engines' fuel flow monitors would check /systems/electrical/outputs/engines/engine[n]/monitoring-power and ... The only way I can see of making a generic simple electrical system serve this scheme is if we can somehow make /systems/electrical/*/*-power return true - i.e. any unknown property under a given branch returns a default value. I don't think the property mechanism has this feature at the moment, but it might be possible to add it. However, I completely agree that, to the extent possible, it makes sense to standardise the names. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TC ball
Curtis L. Olson wrote: I'm guessing that Ay / Az is roughly proportional to Fy / Fz so these two methods won't be exactly the same, but should be similar enough. Well, a classic rule of physics is F = m.a (force = mass x acceleration) and that applies to the directions of the force and acceleration as well as their magnitudes. Therefore at every instant Ay / Az must be precisely equal to Fy / Fz. Well, assuming that Ay is in the same frame of reference as Fy, etc. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Licensing issues
Curtis L. Olson wrote:
What I would like to propose for people's consideration, is the idea
of taking each of FlightGear's component libraries and converting them
to the LGPL license. The top level wrapper code (i.e. whatever is in
src/Main) would remain GPL.
Well, it doesn't matter what license is used for the wrapper code:
for (i=1, iN; ++i) {
subsystem[i].start();
}
because anyone could re-write it easily. Effectively we're talking
about putting as much as possible under LGPL. At first I thought that
sounded like betrayal, but now I'm thinking it sounds good. It would
allow companies who sell a product to include part or (essentially) all
of Flight Gear in their product. They would still have an obligation to
make freely available any modifications to Flight Gear components, so we
and anyone else would not lose out and might benefit if they felt
generous. They might just put minimal hooks in to get at what they
need, and not contribute anything valuable back to us. I don't think
that matters much. They won't gain a special commercial advantage,
because all of their competitors will be able to use FG in their
products too.
If we do not do this, companies which might want to use (part of) FG in
their products will instead write their own proprietary code, and almost
certainly keep it proprietary. Their potential input to the world of
computing will be sealed in a private box and never shared.
Curt, you have mentioned before that you work in a Human Factors
Research Lab and use FG (or parts of it) for (ground-) vehicle display
systems. I assume you are thinking of enabling a commercial product to
be made from this. That's OK by me.
As a programmer I strongly support measures that avoid duplication of
work. I'm not sure whether GPL does this better by persuading users
to share their own code so that they can use shared code, or the LGPL,
by giving users more flexibility with what they can do.
If people are concerned about unfair use of LGPL'd libraries, then we
should think about how to make such a library less susceptible, probably
by making its interface tighter.
Disclaimer: these are just some current thoughts, and I reserve the
right to change my mind.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FWIW
Cameron Moore wrote:
Also while I'm here, I wanted to mention that I get around 3 spams per
day to the flightgear lists that noone ever sees (I'm the primary
moderator if you haven't picked that up yet). The moderating is working
out pretty well I think.
Yes, it must be because I haven't noticed anything. My day job is
firmware for building control systems (ventilation, heating, lighting
etc.) so the same criterion applies: if the customers don't notice it
then it is working well.
trying_to_make_myself_seem_more_useful('ly yours');
Ooh! So you run a 64-bit C compiler!
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Andy Ross wrote: This is a good point, actually. Almost all the Linux filesystems use a 4k block as the minimum allocation unit*, and I presume NTFS is similar. I thought it was the other way around: that most Linux filesystems (by which I mean ext2) and NTFS had 1K or 0.5K blocks, and that Windows FAT filesystems had big (generally 4K to 16K) blocks. [* Geeky aside: reiserfs doesn't. It has a unique tail folding feature where the last sub-block of files gets folded into a single block with the tails of other files, so small files take space proportional to their actual size. Very cool, although apparently not used much.] ReiserFS is the default with SUSE 8.1 which I've just installed. Oh yes ... hey folks, I've just made the switch from Windows to Linux. Played with RedHat and Debian a couple of times in the last few years, but now I think it's a permanent switch. The windows issue is, I think, true only on very old FAT32 variants. I'm pretty sure the block size limitation went away at the same time the 2G limit did, no? Everything from Win98SE on should be fine, I believe. Any windows users want to comment? Certainly anyone running XP won't have this problem. My Windows ME (successor to 98SE) had a single 15 GB FAT-32 partition, and it uses 8 KB blocks. On that, FG scenery was eating large chunks of my disk space. I think FAT-32 is capable of using small (0.5K or 1K) blocks but is not configured to do so because the FAT itself would be big and therefore slow when following the block chain in large files. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Internal compiler error
Andy Ross wrote: http://www.memtest86.com/ I haven't noticed random crashes or corruption in the two years I've been running my current PC, but I decided to try this anyway. Most of the tests showed no problems, but the block move tests found thousands of errors, mostly in a particular bit of the data bus. I was surprised and concerned! This is running at rated speed; I haven't yet tried under-clocking. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Julian Foad wrote: Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v ... Can anyone tell me how to get CVS update going again? Well, I think I've worked out what I need to do: 1. Connect to the old repository (was -0.7, now renamed to -0.8, I think) and update to the 0.8 release tag (there is one, I hope) which indicates the point at which you created the new (-0.9) repository. 2. Connect to the new repository (-0.9), force all my local CVS/Entries files to refer to revision 1 of each source file, and then update. Anybody want to stop me before I try this? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Updating to new CVS trunk repository
Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Joystick files still contain bad names
Two base package files, Input/Joysticks/CH/pro-pedals-usb.xml Input/Joysticks/CH/pro-yoke-usb.xml both still (or again) contain nameMicrosoft-PC-Joysticktreiber /name namePilote de joystick PC Microsoft /name which is less than useful as discussed before. Please could someone remove those lines, and could contributors please be careful not to include such lines in their contributions. Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? - Julian Just trying my first CVS update in a couple of weeks. I see there is a new repository for the trunk, so I changed all my CVS/Root files to point to the -0.9 one and logged in with the new password. [Why not just have no password?] But I get: cvs server: Updating . cvs [server aborted]: could not find desired version 1.9 in /var/cvs/FlightGear-0.9/FlightGear/configure.ac,v When the same was done to the SimGear repository a few weeks a go I ended up doing a complete fresh check-out, but in my FlightGear tree I have quite a lot of local changes which I want to keep, and also I'm on a 56k (actually never more than 40kbps) modem link. Can anyone tell me how to get CVS update going again? Thanks, - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updating to new CVS trunk repository
Curtis L. Olson wrote: Julian Foad writes: Alex Perry wrote: The username changed too. Yes, I forgot to mention that. However, you can see that my problem was not logging in but updating. Someone must know how to get around this ... anyone? Personally, I just did a fresh checkout. Curt. D'oh. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] concave mirrors
The focal point is where rays will be focussed to/from a parallel beam of light - like the rays from an object at infinite distance. The theory is normally quoted in these terms, as it avoids having to consider two distances at once (the distance to the object and the distance to the image or observer). Thus: / Parallel rays from a distant object / | | + Are all focussed to here | (the focal point, by definition) \ \ ... but in real life, the object will be nearer than infinity ... / /Non-parallel rays from nearby object (O) | | + I O | \Are focussed to an inverted real image somewhere else (I) \ ... and as the object moves closer to the mirror, the image of it moves further away, and crosses over the object position (at the point where, looking into the mirror, you find the image of your eye disappearing into a singularity) and continues to move further away until ... / / | Rays from an object at the focal point (O) | O | \ \ Are focussed to infinity ... you get back to an easy-theory situation. The geometry of the intermediate positions is probably something like: (1 / distance_to_object) + (1 / distance_to_image) = (1 / focal_length) ... at least qualitatively. I don't know whether that is correct quantitatively. I hope this was the clue to the obvious that you needed. - Julian Curtis L. Olson wrote: Ok, this is *way* off topic, but I'm hoping the people here are a bit smarter than my stupid coworkers (I guess stupid _self_ is implied.) :-) The following web site explains the basic behavior of a concave mirror and pretty much agrees with everything I remember from physics: http://www.physicsclassroom.com/Class/refln/U13L3a.html If the object distance is beyond the focal point, the reflected image will be inverted. If the object is at the focal point, the reflected image will hit a singularity. If the object distance is less than the focal length, the object will be magnified and right-side up. Now, I have a concave mirror with a 40 radius of curvature. This means it has a 20 focal length. My problem is that I'm not observing behavior that matches the theory. My initial speculation is that the position of my eye is an important factor that isn't addressed by the simple theory, but from the simple theory, I don't see how that could be possible. Here are some things I'm observing: if my eye is closer to the mirror than the focal distance, I see myself and the entire room right side up. Even though objects in the distance (i.e. the other side of the room) are further than the focal point, they are still right-side up. If I move my eye point away from the mirror and watch myself, I seem to hit the singularity at 40 which is the center of curvature, not the focal point. Yes, I've verified that the radius is indeed 40 and is most definitely not 80. If my eye point is further than 40 I can move an object (such as a pen in and out and it hit's the singularity at 40 and inverts beyond that.) If I move my eye away from the mirror and watch an object on the otherside of the room, it hits the singularity and inverts at 20. This sort of agrees with the above theory except it's a distant object that never moves, only my viewpoint is moving. ?!? I've been trying to reconcile this all in my head and have put myself into a state of complete befuddlement ... Can anyone tell me what stupid thing I am missing? Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Bug tracker
The SourceForge Bug Tracker has the following outstanding bug reports: ID SummaryDate Assigned To Submitted By 433286 Sun lights plane at night. 2001-06-14 17:33 nobody dmegginson (still a bug) 433288 Switching view causes slow pan.2001-06-14 17:38 nobody dmegginson (still a bug) 433735 FDM Airport Altitude 2001-06-16 07:38 nobody apeden 435655 no terrain intersection bug at e75n35 2001-06-22 20:39 nobody hrothgar 439307 LaRCSim Segfault Bug 2001-07-07 09:31 nobody nobody 440019 Aircraft level when it shouldn't be2001-07-10 05:02 nobody nobody 471112 Visual zoom out squashes and twists view 2001-10-14 14:03 nobody julianfoad (fixed) 471116 Some text on panel stays white at night2001-10-14 14:09 nobody julianfoad (mostly fixed) 471118 Turn ball flickers from side to side. 2001-10-14 14:14 nobody julianfoad (fixed) 471127 Setting sun chopped by horizon and cloud 2001-10-14 14:39 nobody julianfoad (still a bug) 471134 Httpd seg-faults on invalid paths. 2001-10-14 14:46 nobody julianfoad (I have a fix; not in CVS yet) 471136 Nav needle flickers when nav radio off 2001-10-14 14:50 nobody julianfoad (still a bug) 477578 Mouse pointer lost when menu turned off2001-11-02 09:33 nobody dluff 504761 No video when starting FGFS2002-01-16 23:41 nobody jtwilley I have marked the status in parentheses of some of these. (The oldest one is still a hot topic!) Anyone got any info on the rest? I don't know whether the tracker can be made to send notification to this mailing list of any new reports or changes, but I would like that as long as the frequency stays low. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS not working
Curtis L. Olson wrote: Julian Foad writes: The CVS server is not working for me at the moment. It was working 10 hours ago when I last tried it. $ cvs diff cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF Seems to be working for me at the moment. Yes, it's back again for me too. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] CVS not working
The CVS server is not working for me at the moment. It was working 10 hours ago when I last tried it. $ cvs diff cvs [diff aborted]: recv() from server cvs.flightgear.org: EOF - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote:
I've just checked in a new patch for automatic joystick type detection
(where available). NOTE: it will work *only* if you have a recent (2
months or so) CVS version of plib.
...
Please send me your bindings for your own device. Under Linux, you
can find the device name with a command like
jstest /dev/js0 | less
(You must include any trailing spaces.)
May I offer this patch which will help non-Linux users find their joysticks' names:
Index: js_demo.cxx
===
RCS file: /var/cvs/FlightGear-0.7/FlightGear/src/Input/js_demo.cxx,v
retrieving revision 1.1
diff -u -3 -p -d -r1.1 js_demo.cxx
--- js_demo.cxx 4 Jun 2001 19:26:53 - 1.1
+++ js_demo.cxx 5 Jul 2002 17:47:09 -
@@ -26,9 +26,12 @@ int main ( int, char ** )
t = 0;
for ( i = 0; i Z; i++ )
{ useful[i] = ! ( js[i]-notWorking () );
-if ( useful[i] )
+if ( useful[i] ) {
t++;
-else printf ( Joystick %i not detected\n, i ) ;
+#ifdef FG_PLIB_JOYSTICK_GETNAME
+ printf ( Joystick %i: \%s\\n, i, js[i]-getName() ) ;
+#endif
+} else printf ( Joystick %i not detected\n, i ) ;
}
if ( t == 0 ) exit ( 1 ) ;
For my Saitek Cyborg 3D Gold USB joystick, that gave:
Joystick test program.
~~
Joystick 0: Microsoft PC-joystick driver
Joystick 1 not detected
...
which is presumably because I haven't bothered to install Saitek's driver, because the
default Windows one does the job. Some other people will have done the same, of
course, but there's not a lot we can do about it.
On a related note (Windows compatibility), a given joystick's axes are sometimes
numbered differently under Windows and under Linux. This is nearly always true for
the hat switch with the present version of PLIB. Therefore we should either:
- provide different configurations for the same joystick under different OSs; or
- make PLIB present the axes numbered in the same way under all OSs.
PLIB is supposed to provide cross-platform portability, so obviously the latter should
be attempted. It is not a simple bug in PLIB, it is a slightly complicated issue due
to the different ways the joystick interface is provided by the different OSs, and may
rely on cooperation from the vendor driver writers. I will raise the issue on the
PLIB list.
One more point: it would be good to separate the joystick axis number-to-name mappings
(axis 0 = left/right, axis 2 = twist, axis 3 = slider, etc) from the name-to-function
mappings (left/right = ailerons, twist = rudder, etc.). At least, if we don't
separate them, we should probably make sure that all of our joystick mapping files
give the same functions. It would be silly if users find that the twist axis controls
rudder when they use some types of joystick, but controls view direction when they use
other types.
I have hat fwd/back mapped to elevator trim. Are we standardising on the hat
controlling view direction (for the supplied bindings; I know I can keep my local
changes)?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
I (Julian Foad) wrote: For my Saitek Cyborg 3D Gold USB joystick, that gave: Joystick test program. ~~ Joystick 0: Microsoft PC-joystick driver Joystick 1 not detected ... which is presumably because I haven't bothered to install Saitek's driver, because the default Windows one does the job. Some other people will have done the same, of course, but there's not a lot we can do about it. Hmmm... Saitek's driver for the Cyborg 3D Gold USB is called Saitek Gaming Extensions (e.g. SGEv3.exe). This is NOT a joystick driver (the default Windows driver is used) but just facilites for customising the joystick for different games. I installed it but it did not change the name reported. Does this happen with all USB joysticks? - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ANN: Customized Joystick Bindings and Autodetection
David Megginson wrote:
I've just checked in a new patch for automatic joystick type detection
(where available). NOTE: it will work *only* if you have a recent (2
months or so) CVS version of plib.
The present sets of bindings result in the throttle being squared about its centre,
which is silly. This is because the squared parameter is not set by the throttle
binding, but the default is true. We discussed this before and I think there was
general agreement that the default should be false on the basis of generality.
Therefore may I request this change to the default (in src/Main/fg_commands.cxx):
class PropertyCommandState : public SGCommandState
{
...
virtual const SGPropertyNode * getSquared () const
- { return _squared ? _squared : _dummy_1; }
+ { return _squared ? _squared : _dummy_0; }
...
};
Thanks.
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: crashes at tile borders revisited
Andy Ross wrote: Curtis L. Olson wrote: I agree that random/periodic bugs are insidious and frustrating and makes the software look like crap; therefore we should have a 'culture' of agressive pursuit of these problems. But, unfortunately I can't replicate your particular problem here which makes it difficult for me to do anything about it. I've been playing around a bit and have a somewhat simpler test case that I can reproduce consistently. These coordinates place you immediately (100m or so) in front of the tile boundary that Melchior originally posted. On my graphics card, it's visible as a tiny white crack. fgfs --lon=-122.498813 --lat=37.586699 --heading=275 Just roll along for a little bit and you'll crash when you hit the tile boundary. Yup, I see just the same as you. On crossing the dotty white crack, my little plane topples over on its back like a beetle waving its legs in the air. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS log browser broken
Curtis L. Olson wrote: I'm not a python expert and do not claim to have any knowledge on the subject. But tcl will give very similar errors when a sub program dies. It builds a pipe to the IO of the other process and if it dies it reports a 'broken pipe.' So my best guess is still that enscript is dying, breaking the 'pipe' between it and the viewcvs python script. OK. I know almost nothing about it, so I expect you are right. Maybe for now I'll just hope the problem goes away when the next version comes out. No problem. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Capturing warnings
I now have a practical solution for saving the compiler warnings: a wrapper script
replacement for the compiler.
rm config.cache # Otherwise it keeps the previous values of CC and CXX.
GCCFLAGS=-Wall -pedantic -Wpointer-arith
CC=saveoutp gcc CXX=saveoutp c++ CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS
./configure
where ~/bin/saveoutp contains:
#!/bin/bash
# Run a program, also capturing stderr to a file.
#
# Usage: saveoutp program option... filename
#
# Treat the argument list as a shell command. Run the command, displaying
# stderr but also capturing it into a file named .deps/filename.err.
# (Bug: the command's exit status is reduced to just true or false.)
if [ -d .deps ] ; then
# Make name of error file from last positional argument.
ERRFILE=.deps/${!#}.err
# Execute program; save stderr; display stderr; return true/false exit code.
{ $* 2 $ERRFILE cat $ERRFILE 2; } || { cat $ERRFILE 2; false; }
else
$*
fi
This wrapper script is specific to Bash, but it would be possible to write one for any
shell that can redirect stderr, or even write a compiled program.
Then you will always have the last warnings available for each C file and can run
(e.g.)
cat src/*/.deps/*.err
to see them.
[
My previous attempt was no good. I wrote:
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g. in each
Makefile.in:
...
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
...
But if the compilation fails, 'make' will quit before displaying the error output
file. That's no good. It needs to be done within a single command. What I really
need is one of these:
gcc 2| tee file.err# No: stderr-pipe not available AFAIK, and exit
status is lost.
gcc 2 file.err 2 /dev/con# No: in Bash the first output file has nothing
written to it.
gcc 2(tee file.err) # No, though Bash can _almost_ do this on _some_
systems.
gcc 2 file.err || { cat file.err; false; } # This might just about work!
... but I don't know if I can get automake to put stuff like this in the generated
make files.
]
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Metakit build problem...
Gene Buckle wrote: I get the attached error when building Metakit. I'm using the latest Cygwin installation. g++ -c -O2 -I../unix/../include -I/usr/include/generic -I/usr/include ../unix/../tcl/mk4tcl.cpp -DDLL_EXPORT -DPIC In file included from ../unix/../tcl/mk4tcl.cpp:22: ../unix/../tcl/stubtcl.h:3: syntax error before `*' I had the same problem building MetaKit on CygWin. I just typed: ../unix/configure --without-tcl and the rest of it would then build and install, which was enough for FlightGear. (n.b. The --without-tcl option was broken in metakit version 2.4.2, but fixed in 2.4.3) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Capturing warnings
Making all in Main
c++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src
-I/usr/local/include -DPKGLIBDIR=\/usr/local/lib/FlightGear\ -g -O1 -finline-limit-6
-finline-functions -Wall -pedantic -Wpointer-arith -c main.cxx
main.cxx: In function `void fgUpdateTimeDepCalcs()':
main.cxx:766: warning: unused variable `int i'
main.cxx: In function `void fgLoadDCS()':
main.cxx:1742: warning: unused variable `class ssgVertexArray * lights'
main.cxx:1746: warning: `int light_type' might be used uninitialized in this function
... and there are many others in other files.
I have realised that in order for warnings to be useful, it is no good for them just
to scroll past and then be lost until after the next make clean. At work, I capture
the compiler output for each file and then display all the warnings and errors at the
end of the build. Not just those from the files that were compiled during the last
run of make, but for all source files. I don't want to force everyone to see the
warnings if they don't want to, but I think we should provide a set-up that makes it
easy to do so.
Three things are needed:
1. Enable warnings. e.g.
GCCFLAGS=-g -O1 -Wall -pedantic -Wpointer-arith
CFLAGS=$GCCFLAGS CXXFLAGS=$GCCFLAGS ./configure
2. Save the error output for each C file as (e.g.) .deps/*.err. E.g. in each
Makefile.in:
%.o: %.cxx
@echo '$(CXXCOMPILE) -c $'; \
- $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
+ $(CXXCOMPILE) -Wp,-MD,.deps/$(*F).pp -c $ 2 .deps/$(*F).err
@-cp .deps/$(*F).pp .deps/$(*F).P; \
tr ' ' '\012' .deps/$(*F).pp \
| sed -e 's/^\\$$//' -e '/^$$/ d' -e '/:$$/ d' -e 's/$$/ :/' \
.deps/$(*F).P; \
- rm .deps/$(*F).pp
+ rm .deps/$(*F).pp; \
+ cat .deps/$(*F).err
3. Display the results (when?). e.g.
find . -type d -name .deps -exec cat {}/*.err \;
So, can anyone suggest good ways of doing each of these steps, especially step 2: how
do I get that change into every Makefile.in, or what would be a better way?
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Duplicate properties?
I see rho-slugsft3 in the built-in property browser (View/Properties), but rho-slugs_ft3 in the httpd property browser. I think what is happening is that the latter is correct, but the PLIB default font fails to show underscore characters. I would guess that you took the name as you saw it without the underscore, inserted it in an XML configuration file and then ran FG, which would cause your new property to be created. Then the property browser would show both of them; it knows they are different, but they display the same. We need a different (or rather a complete) font. This has been mentioned before. The PLIB guys said something like It's easy to create one. We could supply one in Flight Gear, but really someone ought to complete the one in PLIB. - Julian John Wojnaroski wrote: Odd. I'm only calling tie once, and my little fltk property browser only shows the correct value. The duplicate showed up in the pull-down menu from view properties. You might check the value of /environment/density-slugft3. It's probably better to use that one anyway as it is not FDM specific. Right, that's what I wound up doing. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Altimeter broken
I should have mentioned that the altimeter in my local source code is connected to the
reported air pressure, rather than just an artificial conversion of the FDM's known
altitude. This is what I have in steam.cxx to find the static pressure:
#ifdef FG_WEATHERCM
sgVec3 plane_pos = { cur_fdm_state-get_Latitude(),
cur_fdm_state-get_Longitude(),
cur_fdm_state-get_Altitude() * SG_FEET_TO_METER };
double static_inhg = WeatherDatabase-get(plane_pos).AirPressure *
(0.01 / INHG_TO_MB);
#else
double static_inhg =
globals-get_environment_mgr()-getEnvironment().get_pressure_inhg();
#endif
set_lowpass ( the_STATIC_inhg, static_inhg, dt );
It was working OK with WEATHER_CM, but not now with the new Environment.
FGEnvironment::get_pressure_inhg() is returning a ridiculously tiny number.
By the way, I have just stepped through this and I noticed that
FGEnvironmentMgr::getEnvironment returns a _copy_ of the environment object, which
involves setting up new interpolation tables. Wouldn't it be more appropriate to
return a reference to it?
- Julian
Julian Foad wrote:
The altimeter seems to be broken at the moment. /steam/altitude-ft shows a huge,
unchanging, random value for me, and the instrument (on more than one aircraft) just
stays at zero.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property browser bugs
I'm debugging the property browsers. Currently they don't handle indexing properly: multiple instances of /input/mice/mouse/mode[0]/button/ are shown without indices because the buttons are numbered 2,3,4 but the test it uses is Is there a child of this name with index 1?. Clicking on any of them causes a seg-fault because no such node (with implied index zero) exists. I propose to change it to display the index if the index is non-zero OR it has siblings with the same name (i.e. if index!=0 or there are two or more different indices). I also want to factor out this code from FG's telnet interface, FG's property picker, and SGPropertyNode::getPath which all try to do the same thing. Proposal: /** * Return name[index], or just name if 'simplify' is true and * the index is 0 and there are no siblings with the same name. */ string SGPropertyNode::getPrettyName(bool simplify) const; (PrettyName is a horrible name. Suggestions?) This seems an appropriate addition because the class already contains the ability to parse such a string (name with optional index) in getNode(const char * relative_path, ...) and to generate one as a complete path, but not yet to generate one as a single path component. While investigating, I found that SGPropertyNode::getPath returns a (char *) pointer to the character data of a string on its stack, i.e. to undefined memory after it returns. I remember someone was changing strings to char* for efficiency. Perhaps this bug was introduced then. I'll include a patch for it with my eventual patch for the above, unless someone beats me to it. I don't think it affects any existing callers: they all want a string anyway. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Altimeter broken
The altimeter seems to be broken at the moment. /steam/altitude-ft shows a huge, unchanging, random value for me, and the instrument (on more than one aircraft) just stays at zero. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Patch for options.cxx
If the program cannot find options.xml, I strongly suggest that it still should give a sensible (if brief) reply to --help. This reply should tell the user how to help it to find options.xml. - Julian C. Hotchkiss wrote: Erik Hofman wrote: C. Hotchkiss wrote: ... If the file isn't needed because an error wasn't made, does the program abort because it cannot find the file? Admittedly I'm being lazy in not testing this myself. It only throws an exception when --help (or an incorrect argument) was specified or *and* the file options.xml doesn't exsist. So, does the program abort or advise and go on? I'm thinking that the exception event would be rare, but even so, a miss installation or an accidentally deleted file shouldn't leave the user scratching his or her head. When easily done, good hints about why things went wrong should be given. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SimGear tidy-up (GCC -Wall warnings etc.)
1. simgear/simgear_config.h.in should not be in CVS, as it is generated from
configure.in and so gives conflicts on every update.
2. simgear/metar/Dcdmetar.cpp: function static bool vrblVsby is unused, so could
profitably be removed or surrounded by #if 0. (Note that, being static, it can't
possibly be used by anything outside that file. Hence gcc -Wall warns about it.)
3. simgear/threads/SGThread.hxx: comma at end of enumeration list is warned about, so
we ought to get rid of it:
diff -u -3 -p -r1.3 SGThread.hxx
--- simgear/threads/SGThread.hxx11 Apr 2001 21:14:24 - 1.3
+++ simgear/threads/SGThread.hxx5 Jun 2002 20:58:33 -
@@ -54,7 +54,7 @@ public:
{
CANCEL_DISABLE = 0,
CANCEL_DEFERRED,
- CANCEL_IMMEDIATE,
+ CANCEL_IMMEDIATE
};
public:
4. simgear/timing/geocoord.cxx: variable nearest is possibly used un-initialised,
according to GCC, so we ought to initialise it, even though I've checked that it is
actually OK:
diff -u -3 -p -r1.3 geocoord.cxx
--- simgear/timing/geocoord.cxx 24 Mar 2001 03:20:47 - 1.3
+++ simgear/timing/geocoord.cxx 5 Jun 2002 20:58:34 -
@@ -80,7 +80,7 @@ GeoCoord* GeoCoordContainer::getNearest(
sgVec3 first, secnd;
float dist, maxDist=SG_MAX;
sgSetVec3( first, ref.getX(), ref.getY(), ref.getZ());
- GeoCoordVectorConstIterator i, nearest;
+ GeoCoordVectorConstIterator i, nearest = NULL;
for (i = data.begin(); i != data.end(); i++)
{
sgSetVec3(secnd, (*i)-getX(), (*i)-getY(), (*i)-getZ());
5. simgear/xml/xmltok_impl.c: variable open is possibly used un-initialised,
according to GCC, so we ought to initialise it, even though I've checked that it is
actually OK:
diff -u -3 -p -r1.1 xmltok_impl.c
--- simgear/xml/xmltok_impl.c 26 Jul 2000 19:17:46 - 1.1
+++ simgear/xml/xmltok_impl.c 5 Jun 2002 20:58:39 -
@@ -1391,7 +1391,7 @@ int PREFIX(getAtts)(const ENCODING *enc,
{
enum { other, inName, inValue } state = inName;
int nAtts = 0;
- int open;
+ int open = 0;
for (ptr += MINBPC(enc);; ptr += MINBPC(enc)) {
switch (BYTE_TYPE(enc, ptr)) {
- Julian
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Does yasim-747 work?
Jim Wilson wrote: Andy, I dumped the last 3 iterations (for my own benifit) and following that is the solution report. What I did for now was go into the Airplain.cpp Airplain - Airplane ? Drag factor: 1.000199 Lift Factor: 1.000410 aoaDelta: 0.000110 tailDelta: 0.83 elevDelta: 0.000114 Drag factor: 1.000475 Lift Factor: 1.000451 aoaDelta: 0.000100 tailDelta: 0.000986 elevDelta: 0.95 Drag factor: 1.000276 Lift Factor: 1.42 aoaDelta: 0.10 tailDelta: 0.001069 elevDelta: 0.18 tailDelta is increasing here. At a guess, I'd say maybe the solution is oscillating. YASim solution results: Iterations: 10002 Drag Coefficient: 12.3517 Lift Ratio: 85.8242 Cruise AoA: 2.97772 Tail Incidence: -4.82189 Approach Elevator: -0.714202 CG: -29.5, -0.0, 1.3 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations[ - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: I simply don't know what I'm doing wrong
Another idea: you might have old versions of SimGear, plib or other libraries
installed somewhere. This should find exactly one copy of libsgsky:
$ find /usr -name 'libsg*' -exec grep -l getSpan_m {} \;
/usr/local/lib/libsgsky.a
If it finds none or more than one, there's a problem with the SimGear build/install.
- Julian
Keith Wiley wrote:
environment_mgr.cxx: In method `double FGEnvironmentMgr::get_cloud_layer_span_m(int)
const':
environment_mgr.cxx:206: no matching function for call to `SGCloudLayer::getSpan_m
()'
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: The telnet interface produce wrong line ending when I run both FlightGear and the telnet client on Win2k. I've just sent a patch to Curt that produce line ending based on the platform where fgfs is running ( something between #ifdef and #endif ). For the moment, this patch only address the issue when fgfs and the telnet client run on the same platform. Thinking of it now, it would be better to generate proper line endings based on the capabilities of the client. Do the telnet interface support telnet commands DO, DONT, WILL and WONT ? or perhaps line ending can be deduced from the incoming command. Ideas ? Idea: the receiver should accept any of these four line endings: CR LF CR,LF LF,CR In fact, I strongly believe that all text parsers, viewers, and readers of any kind should accept these. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
I (Julian Foad) wrote: Idea: the receiver should accept any of these four line endings: Sorry, I misunderstood. I was thinking of a peer-to-peer type connection. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Bad line endings when running on windows
Frederic Bouvier wrote: Perhaps I didn't made me clear. The problem is when FlightGear send text to the telnet client. Each line begins where the previous ends because Win2k telnet client needs a cariage return (\r) with the line feed (\n). OK. The Telnet protocol (RFC854) requires that line ends are sent as CR-LF, so I think FlightGear is faulty. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
Christian Mayer wrote: Note: You 2nd version does *not* use the string concatenation. The 2nd version boils down to the very C++ dependant operator(operator(operator(cout, usage),endl),...); Yes, it does. What point are you trying to make by saying very C++ dependant? Nearly all of FlightGear depends on C++. That syntax is the first thing taught in any book on C++, and is just as suitable for use by experts as by beginners. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Environment subsystem status
John Wojnaroski wrote: I recall reading an article several years ago in a flying mag (can't remember exactly where or when) on someone's proposal to change the number of degrees on the compass from 360 to 400. ... Have you noticed Deg/Rad/Grad or DRG on every scientific calculator? Those are Grads. I've heard that the military use them ... but I haven't seen any evidence of it. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Cameron's time zone
Cameron, your latest e-mail message is time-stamped with: Date: Fri, 17 May 2002 09:41:01 -0500 which means 09:41 on the 17th, local time, which is 5 hours behind UTC, which is about a day into the future. (The current time now is Thu 16 May 2002 16:38 UTC.) - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/Main options.cxx,1.162,1.163
Christian Mayer wrote: I wanted to point out the very big (internal) differnce of the ANSI C style string1 string2 THat ends up as string1string2 in a normal array of char vs. The C++ way: cout string1 string2 wich uses the operator() method. Both are valid and have their pro and cons. But they are fundamentally different (and the later doesn't use the string concatenation), although Yes, fair enough. It does seem a bit of a waste to have a separate function called. I think part of the reason for the existence of endl is this: If endl were enforced as the only legal way (i.e. if \n was made illegal in a future version of C++) then the string outputting functions would no longer have to scan for '\n' in the text that they output. Presently, each time they find '\n' they generally flush the stream output buffer, as well as to converting it to the local line ending character(s) where necessary. - Julian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cameron's time zone
Alex Perry wrote: Cameron, your latest e-mail message is time-stamped with: Date: Fri, 17 May 2002 09:41:01 -0500 which means 09:41 on the 17th, local time, which is 5 hours behind UTC, which is about a day into the future. Don;t worry about it; Cameron just likes to have his messages at the top of your in-box. That way you get around to reading them somewhat earlier. Actually I read my messages in chronological order, so I get to his last! No, wait ... I won't get to read his messages until tomorrow :) (The current time now is Thu 16 May 2002 16:38 UTC.) No, it isn't ... not any more. :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
