Re: [Flightgear-devel] starting the c310u3a-3d
FWIW I checked the logs for the c172-set.xml: revision 1.10 date: 2002/01/19 17:18:19; author: david; state: Exp; lines: +6 -2 Added initial levels for each fuel tank (not full capacity). revision 1.9 date: 2002/01/19 03:10:07; author: david; state: Exp; lines: +7 -0 Set initial levels for fuel tanks (not quite working yet). So it looks like we haven't been using the JSBsim supplied value for fuel, at least on the stock c172, since mid january. On Friday 11 October 2002 02:50 am, John Check wrote: > On Friday 11 October 2002 01:17 am, Jon Berndt wrote: > > > Whats the deal with the x24b fuel wise? That's missing a > > > section as are the shuttle and x15 > > > > ?? > > > > The JSBSim config files have fuel loaded for the X15, the X24B, the C310, > > the C172, etc. But NOT the shuttle (we just use it as a glider). I don't > > know what this "consumables" thing it, but JSBSim loads its aircraft with > > fuel in the JSBSim config files. If it has no fuel, the FlightGear is > > screwing around with the fuel, after the aircraft is already loaded by > > us. > > > > Jon > > It's where the amount of fuel is published to drive the guages, or so I > thought.. > > j4strngs@araka c310u3a $ cvs log c310u3a.xml > > > revision 1.5 > date: 2002/09/24 12:56:05; author: tony; state: Exp; lines: +76 -84 > Updated all JSBSim aircraft config files to new file format > > Hmm... that section is a comment about the gear section... > > So the question is, is the cfg file parsing broken or are the values > getting overwritten. Well... they're getting overwritten now that I added a > section to the *set.xml files for the 310. > > poking around. > > Okay I see the c182-set has a consumables section as well and the last time > that file was molested was 8/28: > > revision 1.10 > date: 2002/08/28 15:00:26; author: curt; state: Exp; lines: +2 -0 > Add a brief description to each *-set.xml file. > > Yow, I bet list traffic will be high tomorrow. > > > > > > > ___ > 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
Re: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt wrote: > Who emptied the fuel tanks? I took it out for a trip on thursday. I must have forgotten to fill it up again. Sorry guys. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] ANN: Localization extended to options
Hi, The new code to localize the options sections has been added yesterday, making it possible to translate the descriptions of the help message now (you can take a look at FlightGear/Translations/strings-default.xml). Also, the code to select a different font for a specified language has sneeked in about a week ago, so if anybody feels the need to create an internatiolized font next to Helvetica.txf, please go ahead. Not that the font section has moved from /sim/font to /sim/intl/locale/font and is defined in FlightGear/Translations/locale.xml now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: > The question is: which one should override which? Unless the user setting overrides the config file, there's no point in having a user setting because the config file value will always be used. To paraphrase Henry Ford, you'll be able to start with any amount of fuel you want, as long as it's 32 gallons. > My own preference is to set the fuel level in the config file and > let it be, but that's just me. I don't recall that change being > made, so it was a bit of a surprise to me. It was more recent than I thought -- January 2002. It happened around the time we added Dave Luff's piston engine model to JSBSim. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Erik Hofman <[EMAIL PROTECTED]> said: > Jon Berndt wrote: > > Who emptied the fuel tanks? > > I took it out for a trip on thursday. I must have forgotten to fill it > up again. Sorry guys. > hehe...Curt should have caught that preflight. Lucky for him they were bone dry :-) Maybe we should randomize tank level. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Norman Vine <[EMAIL PROTECTED]> said: > David Megginson writes: > > > > Please remember that FlightGear is not just a > > visualizer for batch-mode aero runs -- people use it to fly > > interactively. > > NIT: Please remember what it says on our Home Page > > """The FlightGear project is working to create a sophisticated flight > simulator framework for the development and pursuit of interesting flight > simulator ideas. We are developing a solid, basic sim that can be expanded > and improved upon by anyone interested in contributing. """ > > OOPS -- I see that this has changed too. > > """The goal of the FlightGear project is to create a sophisticated flight > simulator framework for use in research or academic environments, for the > development and pursuit of other interesting flight simulation ideas, and as > an end-user application. We are developing a sophisticated, open simulation > framework that can be expanded and improved upon by anyone interested in > contributing. """ > My vote goes with the newer goal statement. Change is always a given (fortunately!). But, actually the second seems more like an broadening of the first. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
> IMHO in steam module should be added some reality switch. > When /instrumentation/steam is true then it cook all values, when > /istrumentation/steam is false then it simply copy /orientation/heading-deg > to /instrumentation/magnetic-compass/indicated-heading-deg and etc. I suspect this might be a bad route to take, but I'm not sure. I have a suspicion that we will usually have many instruments that want cooked and many that want uncooked values. When the need changes, I don't think we will want to eliminate _all_ cooked values, just _some_. In the GUI property browser, can we add a button that does a 'find all properties that point to this property' listing ? That would make it convenient to push individual data users around. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Jim Wilson <[EMAIL PROTECTED]> wrote : > Erik Hofman <[EMAIL PROTECTED]> said: > > > Jon Berndt wrote: > > > Who emptied the fuel tanks? > > > > I took it out for a trip on thursday. I must have forgotten to fill it > > up again. Sorry guys. > > > > hehe...Curt should have caught that preflight. Lucky for him they were bone > dry :-) Maybe we should randomize tank level. Do we have a working fuel gauge ? Can't check for the moment. Cheers, -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Frederic BOUVIER writes: > > hehe...Curt should have caught that preflight. Lucky for him > > they were bone dry :-) Maybe we should randomize tank level. > > Do we have a working fuel gauge ? Can't check for the moment. Yes we have, at least for the 172. Note, however, that regular fuel gauges are not all that reliable, so much so that they are not even on the preflight checklists at my flying club; instead, you climb up and stick a finger in each tank. Of course, turns and accelerations cause the fuel to move around, but the needles often bounce around even when you're on the ground. I wouldn't trust them within 0.25 of a tank. I've read a aviation writers claiming that fuel gauges kill more people than they save by giving misleading readings, the only reliable fuel gauge is a watch, etc. etc. For now, our simulated gauges are very reliable, however. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
> Yes we have, at least for the 172. Note, however, that regular fuel > gauges are not all that reliable, FAA certification standards require that fuel gauges read (1) empty when there is only unusable fuel (or less) in that tank (2) a different indication when the tank is full I suspect the only reason for (2) is to prohibit manufacturers from painting a needle onto the dial that always points to empty. Thus, an acceptable gauge might have a needle that indicates full when the tank is above half full and empty when less than half full. Hope that helps ... ___ 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] Airport Database Model
Julian Foad writes: > 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. Welcome to the side of the angels. > 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. The nice thing about Reiser is that you don't have to decide in advance -- it allows multiple small files to share a single block. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On Thu, Oct 10, 2002 at 01:10:55PM -0700, Andy Ross wrote: > Curtis L. Olson wrote: > > Just a couple thoughts to consider. We are looking at 16-20,000 > > airports so we couldn't stuff them all in a single directory. Even > > splitting them into subdirectories by first letter probably isn't > > enough. > > There are 17073 airports in the current database. Splitting on first > letter only, the largest is (no surprise) 'K', with 2161 airports. On > a lark, I created such a directory containing all the US airports. > The creation process was relatively slow -- 20 seconds or so. But > once the files are there, access to them is very fast (a few tenths of > a second). This was true even after I was careful to flush the buffer > cache by cat'ing a different disk to /dev/null, if the stuff is in the > cache, of course, access is milliseconds at most. If you think about > it, 2000 is about the same number as the number of device files in > /dev, and no is complaining about performance issues there. > One thing to note here is that all this cache take up RAM, and will be dropped on the floor as soon as there's any memory pressure. As it stands, on a 128MB system FlightGear will probably push most of that data out with it's own memory use, let alone leaving space for any other apps . . . So you'd likely get large performance deltas for this system depending on many subtle issues in the VM and VFS. At least using our own code would allow us to make things consistent . . . Not that I think it's a bad idea at all, though, particularly for the future: under Linux at least there are a number of new developments in filesystem-land that will make using this kind of thing much easier. ReiserFS is specifically designed for that kind of thing, and ext3 with the directory index performs as well or better on large directories. XFS probably handles such things fairly well, too. Reiser has tail packing, though at a performance cost, and there's some talk of adding tail packing to ext3. The problem is, FlightGear is portable, and most of these new features are Linux-only, and linux-2.4.$BIGNUM or 2.5+ only . . . Performing well under Linux with ReiserFS is a good advertisement for Linux and ReiserFS, but not so good for FlightGear if that's /all/ we perform well under. > the size of the scenery. Remember that with a file per airport, there > is no need to have the whole airport database in the base package. > You can download the airports along with the scenery. Airports aren't > very useful without scenery, anyway. > I rather like the idea of the airport files being /part/ of the scenery. It certainly seems to be where they'd belong, logically speaking. It'd also mean that the airports in the scenery matched perfectly the airports that FlightGear sees when running (unless you've explicitly hacked things up) - there've been several reports of runways and their navaids being completely out of sync with the scenery, and this seems like a good way to fix them . . . Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg08800/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Airspeed indicator and pitot system
On Fri 11. October 2002 02:14, you wrote: > Norman Vine writes: > > I will still argue that the method used was and still is poor > > > > There are those who want 'steam' and those who don't > > Sure, and we make both available through the property tree. If you > want to know the exact true heading, look at /orientation/heading-deg; > if you want to know the indicated compass heading, look at > /steam/, soon > /instrumentation/magnetic-compass/indicated-heading-deg. No one took > away information that you had before, and the HUD still displays the > exact heading if you're interested. > > On the other hand, it's just silly to build a control panel that looks > like a real one and not have it act that way -- why waste all the > texture memory to simulate analog gauges when the HUD can do the job > better? > IMHO in steam module should be added some reality switch. When /instrumentation/steam is true then it cook all values, when /istrumentation/steam is false then it simply copy /orientation/heading-deg to /instrumentation/magnetic-compass/indicated-heading-deg and etc. Regards, MaDr -- Martin Dressler e-mail: [EMAIL PROTECTED] http://www.musicabona.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
John Check writes: > Dunno. I checked a few revisions back and didn't see anything. > I'm committing wet tanks shortly. Remember that I just fixed FlightGear to stop picking up defaults from c172.xml. Hmm. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] multiplayer / AI property tree - questions
David Megginson writes: > Andy Ross writes: > > > I have limited experience here, but the nosewheel shimmy I noticed in > > a friend's PA-180 was only a rumble. It didn't seem to effect the > > orientation or handling of the aircraft. > > If it's bad enough, the whole plane shakes (we've had trouble with the > nose strut on C-GPMR at the Ottawa Flying Club, and it had to be > rebuilt); of course, since I'm holding the yoke, I feel it through > that first. That should have been the rudder pedals, not the yoke. Don't worry, people, I do know how to steer the nosewheel. Really. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Curtis L. Olson writes: > John Check writes: > > Also, what happened to the runway lighting? I'm a little out of touch > > since I've spent the last week (at least) installing Gentoo > > It should still be there, isn't it? I have been working on building > more infrastructure for doing runway/approach lighting and working on > using environment mapping to simulate directional lights which (except > for VASI/PAPI) is working out very well. It's still there for me, but it appears as 3-point triangles now. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: > The JSBSim config files have fuel loaded for the X15, the X24B, the C310, > the C172, etc. But NOT the shuttle (we just use it as a glider). I don't > know what this "consumables" thing it, but JSBSim loads its aircraft with > fuel in the JSBSim config files. If it has no fuel, the FlightGear is > screwing around with the fuel, after the aircraft is already loaded by us. Right. We allow the users to change the fuel level, so the default in the JSBSim config file doesn't matter. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re: [Flightgear-devel] spot landings
Alex Perry writes: > This coming Saturday is the annual safety competition for San Diego and, > as one of the organizers, I've been thinking about the spot landings task. > It occurs to me that FGFS should be able to do that really well, except > the touchdown report is minimal. How much hassle would it be, to have > the existing gear message (to console) report the (u,v) and name of the > texture which the wheel hit, or some other relative-to-runway numbers ? > That would enable sim pilots to fly TnG series, with automatic scoring. It should be possible to specify a lat/lon and then get the distance and bearing of first wheel contact. In fact, given sufficient update frequency, you might even be able to do this with an external program (poll the WOW property). All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Erik Hofman writes: > Jon Berndt wrote: > > Who emptied the fuel tanks? > > I took it out for a trip on thursday. I must have forgotten to fill it > up again. Sorry guys. Damn -- do you know how much condensation there must be in the tanks? I'll be draining water for half an hour. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Martin Dressler writes: > IMHO in steam module should be added some reality switch. > When /instrumentation/steam is true then it cook all values, when > /istrumentation/steam is false then it simply copy /orientation/heading-deg > to /instrumentation/magnetic-compass/indicated-heading-deg and etc. The steam module is just about finished, since most things have already moved to /instrumentation/. I don't think you really need a proper autopilot for using true values, just something that works with the magic FDM and moves the plane in a certain direction at a certain speed -- more of an animation manager than an autopilot. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Starter problem: solved
The /controls/starter[0] property is being forced to true by the new
electrical-system code, which automatically sets all switches on:
} else if ( cname == "switch" ) {
// set default value of switch to true
// cout << "Switch = " << child->getStringValue() << endl;
fgSetBool( child->getStringValue(), true );
add_switch( fgGetNode( child->getStringValue(), true ) );
}
Instead, we should set the appropriate switches to 'on' in
preferences.xml or c172-*-set.xml so that the user can override. For
the starter, a default to 'on' is clearly not what we want.
All the best,
David
--
David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: > The JSBSim config files have fuel loaded for the X15, the X24B, the C310, > the C172, etc. But NOT the shuttle (we just use it as a glider). I don't > know what this "consumables" thing it, but JSBSim loads its aircraft with > fuel in the JSBSim config files. If it has no fuel, the FlightGear is > screwing around with the fuel, after the aircraft is already loaded by us. David replied: > Right. We allow the users to change the fuel level, so the default in > the JSBSim config file doesn't matter. H. I don't like this at all. Why was this done? For one thing, in the JSBSim config file the capacity is listed there as well, so one can easily be alerted to accidentally giving too much fuel. There should be one place for this to be done. Overriding the config file value will confuse people, and make people think something is broken. Like it has here. Also, there are mass properties isues. This "feature" needs to be removed from FlightGear, I think. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson > > I don't think you really need a proper autopilot for using true > values, just something that works with the magic FDM and moves the > plane in a certain direction at a certain speed -- more of an > animation manager than an autopilot. http://gps.faa.gov/Programs/WAAS/waas.htm Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
David Megginson writes: > > Instead, we should set the appropriate switches to 'on' in > preferences.xml or c172-*-set.xml so that the user can override. For > the starter, a default to 'on' is clearly not what we want. NIT *-*-set.xml so that the user can override. The Sim is more then a C172 simulator Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
Jon Berndt writes: > > Right. We allow the users to change the fuel level, so the default in > > the JSBSim config file doesn't matter. > > H. I don't like this at all. Why was this done? 1. We have several different FDMs and need a common mechanism for setting and displaying fuel levels for all of them. 2. Users need to be able to select an initial fuel level with each run, just as in real life -- flying a small plane is often a tradeoff between how much fuel you'd like and how much weight you can manage. 3. When we restore a saved flight, we want to be able to start with the same amount of fuel we had when we saved the flight. We've done it this way for a year (maybe two) and it generally works well -- Tony did a good job interfacing it. Soon, we'll also need an FDM-independent way of specifying the payload positions. Note that the FDMs still manage fuel consumption themselves -- FlightGear just tells them how much the user wants to start with. > Overriding the config file value will confuse people, and make > people think something is broken. We tracked this one down easily enough. It would be much worse if there were a different mechanism for fueling JSBSim, LARCsim/UIUC, and YASim planes. Please remember that FlightGear is not just a visualizer for batch-mode aero runs -- people use it to fly interactively. A fixed setting in an FDM-specific static init file isn't sufficient. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
Norman Vine writes: > > Instead, we should set the appropriate switches to 'on' in > > preferences.xml or c172-*-set.xml so that the user can override. For > > the starter, a default to 'on' is clearly not what we want. > > NIT > *-*-set.xml so that the user can override. > > > The Sim is more then a C172 simulator Correct, but the C172 is the only one that Curt has modelled an electrical system for so far. When he has done others, then their *-set.xml files will need to be changed as well. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airspeed indicator and pitot system
Norman Vine writes: > > I don't think you really need a proper autopilot for using true > > values, just something that works with the magic FDM and moves the > > plane in a certain direction at a certain speed -- more of an > > animation manager than an autopilot. > > http://gps.faa.gov/Programs/WAAS/waas.htm Norm, Norm, Norm -- I'm very disappointed. You're the one who has spent the most time drilling into everyone's head that GPS receiver readings are *not* the same as true values. Certainly, we'll want to be able to slave the autopilot to a GPS receiver as well as the HI, VOR, etc., but then we'll be modelling the GPS altitude errors and sampling-rate lag and adding a slight fuzzy factor (a significant one for altitude); if we get fancy we might even let the receiver have trouble locking on to satellites sometimes. In fact, even the C172R (which we're modelling) comes with a KLN89 or better GPS receiver, together with an autopilot that can be slaved to it instead of the VOR gauge for lateral control. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
David Megginson writes: > > Please remember that FlightGear is not just a > visualizer for batch-mode aero runs -- people use it to fly > interactively. NIT: Please remember what it says on our Home Page """The FlightGear project is working to create a sophisticated flight simulator framework for the development and pursuit of interesting flight simulator ideas. We are developing a solid, basic sim that can be expanded and improved upon by anyone interested in contributing. """ OOPS -- I see that this has changed too. """The goal of the FlightGear project is to create a sophisticated flight simulator framework for use in research or academic environments, for the development and pursuit of other interesting flight simulation ideas, and as an end-user application. We are developing a sophisticated, open simulation framework that can be expanded and improved upon by anyone interested in contributing. """ Can't find the CVS log entry but it is relatively recent http://web.archive.org/web/20020124173417/http://www.flightgear.org/ Hmm... Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] starting the c310u3a-3d
> Jon Berndt writes: > > 1. We have several different FDMs and need a common mechanism for >setting and displaying fuel levels for all of them. > 3. When we restore a saved flight, we want to be able to start with >the same amount of fuel we had when we saved the flight. > Please remember that FlightGear is not just a > visualizer for batch-mode aero runs -- people use it to fly > interactively. A fixed setting in an FDM-specific static init file > isn't sufficient. The question is: which one should override which? As for FlightGear being a visualizer, well, Duh! Of course I agree with your statement. My own preference is to set the fuel level in the config file and let it be, but that's just me. I don't recall that change being made, so it was a bit of a surprise to me. Jon smime.p7s Description: application/pkcs7-signature
Re: [Flightgear-devel] Airspeed indicator and pitot system
David Megginson > > Norman Vine writes: > > > > I don't think you really need a proper autopilot for using true > > > values, just something that works with the magic FDM and moves the > > > plane in a certain direction at a certain speed -- more of an > > > animation manager than an autopilot. > > > > http://gps.faa.gov/Programs/WAAS/waas.htm > > Norm, Norm, Norm -- I'm very disappointed. You're the one who has > spent the most time drilling into everyone's head that GPS receiver > readings are *not* the same as true values. David David David You rewrite history well all the best Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
Norman Vine writes: > > Please remember that FlightGear is not just a > > visualizer for batch-mode aero runs -- people use it to fly > > interactively. > > NIT: Please remember what it says on our Home Page > > """The FlightGear project is working to create a sophisticated flight > simulator framework for the development and pursuit of interesting flight > simulator ideas. We are developing a solid, basic sim that can be expanded > and improved upon by anyone interested in contributing. """ > > OOPS -- I see that this has changed too. > > """The goal of the FlightGear project is to create a sophisticated flight > simulator framework for use in research or academic environments, for the > development and pursuit of other interesting flight simulation ideas, and as > an end-user application. We are developing a sophisticated, open simulation > framework that can be expanded and improved upon by anyone interested in > contributing. """ I'm not sure I follow: we're using a common mechanism to pass user requests for initial fuel level to all FDMs, just as we use a common mechanism to pass user requests for aileron deflection to all FDMs. We did this a long time ago, before there even was a YASim (for example). It's also worth noting that we are (very slowly) spinning off the framework part into SimGear, so that FlightGear will eventually be the a specific flight simulator built on top of the framework rather than the framework itself. When the original mission statement was written, there was no separate SimGear. All the best, David -- David Megginson, [EMAIL PROTECTED], http://www.megginson.com/ ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Julian Foad wrote: > 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. Nope, 4k. The underlying disks have 512 byte blocks (all IDE and most SCSI, at least), but the OS doesn't cut things that fine. The 4k block size matches the processor page size on x86 and most other processors, so it makes things like swap and mmap'ed I/O simpler to implement. You can see this for yourself pretty easily (this is ext3; I'd be curious to see what the results are on other filesystems): # Make a scratch area mkdir foo cd foo # Make 100 empty files for i in 0 1 2 3 4 5 6 7 8 9; do for j in 0 1 2 3 4 5 6 7 8 9; do touch $i$j done done # Note that no space is taken up by the empty files, only 4k for the # directory itself cd .. du -s foo # Now append one byte to each of them cd foo for i in *; do echo "" > $i done # Note that the directory now contains 404k -- 4k per file cd .. du -s foo -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 10:30 am, Jim Wilson wrote: > Erik Hofman <[EMAIL PROTECTED]> said: > > Jon Berndt wrote: > > > Who emptied the fuel tanks? > > > > I took it out for a trip on thursday. I must have forgotten to fill it > > up again. Sorry guys. > > hehe...Curt should have caught that preflight. Lucky for him they were > bone dry :-) Maybe we should randomize tank level. > > Best, > > Jim > I -was- gonna just put in a gallon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] starting the c310u3a-3d
On Friday 11 October 2002 07:02 am, David Megginson wrote: > John Check writes: > > Dunno. I checked a few revisions back and didn't see anything. > > I'm committing wet tanks shortly. > > Remember that I just fixed FlightGear to stop picking up defaults from > c172.xml. Hmm. > > > All the best, > > > David Okay. I've been wanting to move the style related stuff out of preferences.xml for a long time. I'll see if it works now. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Simon Fowler wrote: > One thing to note here is that all this cache take up RAM, and will > be dropped on the floor as soon as there's any memory pressure. Right, which is why I was careful to cite numbers that reflected actual disk I/O, and not cache performance. Even hitting the disk, performance is acceptable. If "most" machines are faster than that, it's a bug not a feature. :) > Performing well under Linux with ReiserFS is a good advertisement > for Linux and ReiserFS, but not so good for FlightGear if that's > /all/ we perform well under. I think you have perhaps misinterpreted. My point was that a blunderingly simple file-per-airport scheme was adequate on all filesystems, not that it required fancy stuff. The reiserfs note was a fun bit of trivia about how OS authors try to accomodate stuff like this. If we work everywhere, but are blazingly fast (or take up far less space) under linux/reiserfs, I'd again consider that a feature and not a bug. > I rather like the idea of the airport files being /part/ of the > scenery. It certainly seems to be where they'd belong, logically > speaking. [...] there've been several reports of runways and their > navaids being completely out of sync with the scenery, and this > seems like a good way to fix them. Right. The only complication is that there's an existing use case that requires doing fast lookup of airports by ID. My idea was to distribute files with the scenery and drop them in a single global directory. Trivially simple to implement and maintain -- users who discover airport or navaid bugs can just fix the file and post it to the mailing list; they don't need any coding experience at all. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
On Friday 11 October 2002 08:09 am, Norman Vine wrote: > David Megginson writes: > > Instead, we should set the appropriate switches to 'on' in > > preferences.xml or c172-*-set.xml so that the user can override. For > > the starter, a default to 'on' is clearly not what we want. > > NIT > *-*-set.xml so that the user can override. > > I agree with Norman here. IMO there shouldn't be anything aircraft specific in preferences.xml. By that I mean setting up the environment is good but setting up the aircraft inside the environment should be "one stop shopping" The nav and environment related stuff is okay, but controls and instrument options should be in the set files. It would be nice in the future to have scenario related params as a separate included file and just have eg input devices and views in preferences. I supose you have to draw the line someplace though. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
On Friday 11 October 2002 08:20 am, David Megginson wrote: > Norman Vine writes: > > > Instead, we should set the appropriate switches to 'on' in > > > preferences.xml or c172-*-set.xml so that the user can override. For > > > the starter, a default to 'on' is clearly not what we want. > > > > NIT > > *-*-set.xml so that the user can override. > > > > > > The Sim is more then a C172 simulator > > Correct, but the C172 is the only one that Curt has modelled an > electrical system for so far. When he has done others, then their > *-set.xml files will need to be changed as well. > > > All the best, > > > David We could plug in a basic system with an alternator,battery and one buss in the meantime. It might not be accurate, but at least we won't be grounded (no pun) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On Fri, 11 Oct 2002 13:50:21 -0700, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > # Make 100 empty files > for i in 0 1 2 3 4 5 6 7 8 9; do > for j in 0 1 2 3 4 5 6 7 8 9; do > touch $i$j > done > done ..wee tweak: for i in $( seq 100 ) ; do touch $i done -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
Arnt Karlsen wrote: > ..wee tweak: > for i in $( seq 100 ) ; do > touch $i > done Cute. You learn something new every day. I've never noticed that utility. I have a vague memory that there is some bash syntax that does a similar thing, too. And the $(...) syntax was new for me too -- I would have used backquotes. Honestly, I'm not much of a shell junkie. This is about as elaborate as any of my shell scripts get; anything bigger gets done in perl. Andy -- Andrew J. RossNextBus Information Systems Senior Software Engineer Emeryville, CA [EMAIL PROTECTED] http://www.nextbus.com "Men go crazy in conflagrations. They only get better one by one." - Sting (misquoted) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On Fri, Oct 11, 2002 at 01:57:17PM -0700, Andy Ross wrote: > Simon Fowler wrote: > > Performing well under Linux with ReiserFS is a good advertisement > > for Linux and ReiserFS, but not so good for FlightGear if that's > > /all/ we perform well under. > > I think you have perhaps misinterpreted. My point was that a > blunderingly simple file-per-airport scheme was adequate on all > filesystems, not that it required fancy stuff. The reiserfs note was > a fun bit of trivia about how OS authors try to accomodate stuff like > this. If we work everywhere, but are blazingly fast (or take up far > less space) under linux/reiserfs, I'd again consider that a feature > and not a bug. > Actually, I was thinking of the behaviour I've seen with large directories on ext2/3 . . . And also how mutt handles my maildirs with several thousand files. That's not really an issue here, though, so consider it random paranoia ;-) > > I rather like the idea of the airport files being /part/ of the > > scenery. It certainly seems to be where they'd belong, logically > > speaking. [...] there've been several reports of runways and their > > navaids being completely out of sync with the scenery, and this > > seems like a good way to fix them. > > Right. The only complication is that there's an existing use case > that requires doing fast lookup of airports by ID. My idea was to > distribute files with the scenery and drop them in a single global > directory. Trivially simple to implement and maintain -- users who > discover airport or navaid bugs can just fix the file and post it to > the mailing list; they don't need any coding experience at all. > What about simply putting all the airport files in the scenery, and having a script that searched through the scenery directories for all the *-apt.xml files and built/updated a set of indexes from them? That keeps the files in the right place, and gives the indices needed to get fast lookups based on whatever criteria are needed. Although none of this deals with the problem of making sure the scenery and the airports are consistent . . . That would rely on having consistent data when the scenery is generated, which is a very different matter. Unless we're all building our own scenery, of course . . . /me needs to acquire an eight-way alphaserver to play around with this scenery generation thing . . . ;-) Simon -- PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc (crappy) Homepage: http://himi.org doe #237 (see http://www.lemuria.org/DeCSS) My DeCSS mirror: ftp://himi.org/pub/mirrors/css/ msg09166/pgp0.pgp Description: PGP signature
Re: [Flightgear-devel] Airport Database Model
Simon Fowler writes: > > What about simply putting all the airport files in the scenery, and > having a script that searched through the scenery directories for > all the *-apt.xml files and built/updated a set of indexes from > them? That keeps the files in the right place, and gives the indices > needed to get fast lookups based on whatever criteria are needed. Sounds good to me Now we just need to figure out what we want for indices The way I see it we have two radically different needs 1) Search by name 2) Search by location 1) is easy and we could just use metakit or any other disk based indexable file < I have suggested using a trie > 2) is a little more complicated but we allready have a good start if we leverage the Scenery directory structure I suggested using a quadtree for each 10x10 degree block but there are spherical indexing methods that might be better in that there is no cos(lat) shrink factor to account for when doing range lookups. Here is a link to a good one http://www.sdss.jhu.edu/htm/implementation.html note this package is near optimum for a "show all points within X distance" when on a sphere and should be great at keeping an updated list of radio frequencies that were within range at 'altitude'. This is not a trivial task Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Airport Database Model
On Fri, 11 Oct 2002 15:04:51 -0700, Andy Ross <[EMAIL PROTECTED]> wrote in message <[EMAIL PROTECTED]>: > Arnt Karlsen wrote: > > ..wee tweak: > > for i in $( seq 100 ) ; do ..should have been "$( seq 0 1 99 )" to be precisely like your i/j job. > > touch $i > > done > > Cute. You learn something new every day. I've never noticed that > utility. I have a vague memory that there is some bash syntax that > does a similar thing, too. And the $(...) syntax was new for me too ..yeah, "for i in ` seq 0 1 99 ` ; do" etc. Cat skin. ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;-) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Starter problem: solved
I did this as a stop gap until we can get master bat/alt and avionics
master switches on the panel, but yeah, starter[0] shouldn't be on by
default.
Curt.
David Megginson writes:
> The /controls/starter[0] property is being forced to true by the new
> electrical-system code, which automatically sets all switches on:
>
> } else if ( cname == "switch" ) {
> // set default value of switch to true
> // cout << "Switch = " << child->getStringValue() << endl;
> fgSetBool( child->getStringValue(), true );
> add_switch( fgGetNode( child->getStringValue(), true ) );
> }
>
> Instead, we should set the appropriate switches to 'on' in
> preferences.xml or c172-*-set.xml so that the user can override. For
> the starter, a default to 'on' is clearly not what we want.
>
>
> All the best,
>
>
> David
>
> --
> David Megginson, [EMAIL PROTECTED], http://www.megginson.com/
>
> ___
> Flightgear-devel mailing list
> [EMAIL PROTECTED]
> http://mail.flightgear.org/mailman/listinfo/flightgear-devel
--
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
