Re: Another virus message (was Re: [Flightgear-devel] Hi)
David, David Megginson [EMAIL PROTECTED] wrote: [EMAIL PROTECTED] DID NOT write: The message contains Unicode characters and has been sent as a binary attachment. For anyone keeping track, this spam with Martin's e-mail forged on it came from ma164090190.user.veloxzone.com.br 200.164.90.190 thanks for stepping in here - I didn't realize it earlier, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Question about 3D goggles...
Hi, I've tried to use FlightGear with NVIDIA's 3D goggles. The simulator works right but there're some problems. Sometimes, when I use some commands in the menu, the O.S. (windows XP) breaks the program due to an incorrect writing to memory. This happens even every time I use the normal HUD (the first one that pops up hitting H key), but not with the secondary HUD (the one that displays even the frame rate). There's a way to solve this problem? Thanks, Luca ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] External [perl] scripting
If anyone is interested in creating external scripts to remotely drive or monitor FlightGear, I have committed some convenience functions (perl) to cvs. For some time we have had a telnet.pl script which takes care of the tricky bits of interfacing to a remote copy of FlightGear. This gives you access to reading and writing any entry in the FlightGear property tree as well as running any of FlightGear's published functions (i.e. anything that you could bind a key press, joystick, mouse, or gui function to.) The functions I have committed are wrappers around the telnet.pl script to hopefully make things even easier. Here is some of the functionality that is included: Aircraft: - Start piston engine - Set weight and balance - Manipulate engine and flight controls Autopilot: - Wing leveler - Bank hold - Heading hold - Pitch hold (with trim) - Pitch hold (with yoke) - Altitude hold - Speed hold (with throttle) - Speed hold (with pitch via trim) - Speed hold (with pitch via yoke) - All off Environment - Set time of day - Set boundary/aloft wind layer - Set cloud layer - Set outside air temp (at current altitude) - Set altimeter/pressure Position - Reset in the air (airport, runway, offset distance, glideslope, velocity, heading, etc.) - Reset on the ground (airport, runway) Logging - Clear all logging fields - Add a suite of default variables - Add any property (w/ human readable title) - Start logging (to the specified file name) - Stop logging - Generate a quick plot of any field (vs. time) These functions obviously aren't a complete subset of everything possible, but we can easily add more as we need them. And it's not strictly necessary to use these functions, they are there for convenience. With this functionality, you can build scripts to do a very large variety of things, and log the aircraft action as well. These could be used (perhaps) :-) to build a set of scripts to do automated flight testing. The FAA has a suite of tests it requires for certifying simulators (for instance.) Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Curt's job for Feb - Mar.
I want to share some news that I'm very excited about. For February and March I am being paid 50% time by ATC Flight Simulators (http://www.atcflightsim.com) to do some work for one of their specific projects. They are building several simulators for a customer that will be a combination of their cockpit hardware, the FlightGear software, a commercial flight dynamics package, and a proprietary instructor station. These simulators will be FAA certified when they are finished (hopefully by June 1.) I am doing all the software work for these projects (which is a bit scary and a bit exciting.) :-) The parts of my paid work that directly involve FlightGear are being contributed back to FG of course. That is something that obviously has to happen because of the FG license terms; but beyond that, it's exciting for a percentage of my time to be paid to work on portions of FlightGear. I hope that more opportunities like this will arise in the future. :-) The parts of my work involving proprietary code clearly have to stay proprietary. We are keeping the open-source code seperate from the proprietary code by dividing it up into entirely seperate applications. For what it's worth, everyone who has seen our early prototypes has been very impressed and we have received a lot of positive feedback. The visual system is 100% FlightGear, the instrument panel rendering is 100% flightgear, the systems modeling is 100% flightgear, the whole flightgear infrastructure is 100% flightgear. :-) The use of FlightGear for this project is a bit of an experiment/risk for ATC, but so far everything has been working out far above expectations. Long term, I'm very hopeful that this project with ATC will be a stunning success and we can continue to develop a positive symbiotic relationship with them. I'm out to prove that FlightGear is a huge win for their simulators, and in return, (hopefully) they will continue to use FG for future projects and thus have a need to pay me and others to do specific project work for them that will get contributed back to FG. Anyway, the short version of this message is that I'm getting paid 50% of my time to work on flight simulators for the next two months which is very exciting! Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Nasal question
Is there a way to assign an instantaneous joystick button, but not have the value jump directly from one value to another? Currently I have the following code in my joystick file but it results in the brakes snapping on and off. I wanted to get a smoother transition to be more realistic in ground handling (I know it won't make a big difference, but I want to try it) and also so that when I animate brake pedals they don't just snap back and forth. I tried propertySlew() but it seems that the value wasn't going to the numbers I supplied, but only slewing for a very short period of time taht wasn't even consistant. I played around with stepProp but I couldn't set the /sim/brakes properties from inside the joystick config file, so I gave up on that. I think I need some clarification on how these are supposed to work before I can figure out how to do this. Thanks, Josh What I have now: button n=1 descLeft Brake/desc repeatable type=boolfalse/repeatable binding commandproperty-assign/command property/controls/gear/brake-left/property value type=double1.0/value /binding mod-up binding commandproperty-assign/command property/controls/gear/brake-left/property value type=double0.0/value /binding /mod-up /button What didn't work: button n=1 descLeft Brake/desc repeatable type=boolfalse/repeatable binding commandnasal/command scriptcontrols.slewProp(/controls/gear/brake-left, 1)/script /binding mod-up binding commandnasal/command scriptcontrols.slewProp(/controls/gear/brake-left, -1)/script /binding /mod-up /button ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Josh Babcock wrote: I tried propertySlew() but it seems that the value wasn't going to the numbers I supplied, but only slewing for a very short period of time taht wasn't even consistant. You need to mark the bindings repeatable. See the trim bindings for examples. The propertySlew() function slews a property by the appropriate amount for the current frame only (based on the time it took to render the last frame). If you only call it once when the button is pressed/released, you will only get one frame of motion. The time will look inconsistant because individual frames take varying times to render. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Curt's job for Feb - Mar.
Excellent! Congratulations! Curtis L. Olson wrote: I want to share some news that I'm very excited about. For February and March I am being paid 50% time by ATC Flight Simulators (http://www.atcflightsim.com) to do some work for one of their specific projects. Looks like they use columnated projection system. Very cool but I personally get very sick when frame rates fluctuate... They are building several simulators for a customer that will be a combination of their cockpit hardware, the FlightGear software, a commercial flight dynamics package, and a proprietary instructor station. These simulators will be FAA certified when they are finished (hopefully by June 1.) Good luck! To what level are they attempting to certify? I am doing all the software work for these projects (which is a bit scary and a bit exciting.) :-) The parts of my paid work that directly involve FlightGear are being contributed back to FG of course. That is something that obviously has to happen because of the FG license terms; but beyond that, it's exciting for a percentage of my time to be paid to work on portions of FlightGear. I hope that more opportunities like this will arise in the future. :-) The parts of my work involving proprietary code clearly have to stay proprietary. We are keeping the open-source code seperate from the proprietary code by dividing it up into entirely seperate applications. For what it's worth, everyone who has seen our early prototypes has been very impressed and we have received a lot of positive feedback. The visual system is 100% FlightGear, the instrument panel rendering is 100% flightgear, the systems modeling is 100% flightgear, the whole flightgear infrastructure is 100% flightgear. :-) The use of FlightGear for this project is a bit of an experiment/risk for ATC, but so far everything has been working out far above expectations. Best of luck here. I was on a project where we tried to certify a Lear 35 to Level 5. Neither the visual, nor the glass instruments made it. That was 5 years ago. The rules may have changed. Long term, I'm very hopeful that this project with ATC will be a stunning success and we can continue to develop a positive symbiotic relationship with them. I'm out to prove that FlightGear is a huge win for their simulators, and in return, (hopefully) they will continue to use FG for future projects and thus have a need to pay me and others to do specific project work for them that will get contributed back to FG. This announcement is certainly useful for the thing I'm working on... I'm still not ready to spill the beans on it yet though. Anyway, the short version of this message is that I'm getting paid 50% of my time to work on flight simulators for the next two months which is very exciting! Curt. -- Russ Conway's Law: The structure of a system tends to mirror the structure of the group producing it. -- Mel Conway Datamation (1968) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Andy Ross wrote: SNIP You need to mark the bindings repeatable. See the trim bindings for examples. Whoops. Typo, or cut-and-past-o I guess. That's what you get for coding with the flu I. Now the brakes go on like I want, but I have the same problem with them coming off. Apparently repeatable tags don't affect anything inside a mod-up tag. In retrospect, this makes a lot of sense. For this will I have to implement something like the flaps using stepProp? If so, will I have to make changes outside of the joystick file to define a hash for nasal? Is there a utility function to move a property from value a to value b over a given delta? I looked but didn't see anything that said it would do that. Josh ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Never mind. I just remembered interpolate. This works perfectly. Josh button n=1 descLeft Brake/desc repeatable type=booltrue/repeatable binding commandnasal/command scriptinterpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 1, 0.1)/script /binding mod-up repeatable type=booltrue/repeatable binding commandnasal/command scriptinterpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 0, 0.1)/script /binding /mod-up /button ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal question
Some quick suggestions: You wrote: interpolate(/controls/gear/brake-left, props.globals.getNode(/controls/gear/brake-left).getValue(), 0, 1, 0.1) Actually, the implementation of interpolate() always starts from the current value of a property, so in fact there's no need for the first two arguements. This call should have the same effect: interpolate(/controls/gear/brake-left, target-value, 0.1) And a more general note: the getValue() expression can be more simply (and efficiantly, for that matter) written as: getprop(/controls/gear/brake-left) The props.Node interface is there for completeness and flexibility, but grabbing constant strings out of the the property tree is best done with the simple API. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] RAM disk / Unix
Is anyone aware of a RAM disk utility or feature under Unix (specifically, IRIX)? When running a simulation on IRIX we are finding that the disk access is taking too much time at various phase boundaries. It is thought that the use of a RAM disk might help. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] RAM disk / Unix
Jon S Berndt writes: Is anyone aware of a RAM disk utility or feature under Unix (specifically, IRIX)? When running a simulation on IRIX we are finding that the disk access is taking too much time at various phase boundaries. It is thought that the use of a RAM disk might help. On Windows I have found that increading disk cache size and / or using memory mapped files is more productive then a DAM disk Maybe the same tricks would work for IRIX. The main drawback to RAM disks is that you end up needing twice the RAM, one for the Disk Image and once for the Memory Image HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
Jon S. Berndt wrote: Is anyone aware of a RAM disk utility or feature under Unix (specifically, IRIX)? When running a simulation on IRIX we are finding that the disk access is taking too much time at various phase boundaries. It is thought that the use of a RAM disk might help. RAM disks are ancient history; they date from a time before OS-managed caching of disk access. If you are sure you have the RAM to support both your application and the data file contents simultaneously, then you can prefetch the file contents into memory with a simple: cat datafile /dev/null Try this before running your program and see how that works. If it turns out you do need the memory for the running process, you might try spawning it off as a background process shortly (you'll have to measure that time delay for an appropriate value) before you start hitting the disk. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
Norman Vine wrote: Jon S. Berndt wrote: It is thought that the use of a RAM disk might help. On Windows I have found that increading disk cache size and / or using memory mapped files is more productive then a DAM disk My interpretation was that their problem was latency, not I/O throughput. The program cooks along using 100% of the CPU, then it needs to load a giant data set off the disk, so it has to wait (making 0% use of the CPU) while the I/O system does its job. If they could ensure that the dataset was in memory they could avoid this delay. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RAM disk / Unix
On Tue, 10 Feb 2004 15:06:41 -0800 Andy Ross [EMAIL PROTECTED] wrote: Norman Vine wrote: Jon S. Berndt wrote: It is thought that the use of a RAM disk might help. On Windows I have found that increading disk cache size and / or using memory mapped files is more productive then a DAM disk My interpretation was that their problem was latency, not I/O throughput. The program cooks along using 100% of the CPU, then it needs to load a giant data set off the disk, so it has to wait (making 0% use of the CPU) while the I/O system does its job. If they could ensure that the dataset was in memory they could avoid this delay. Andy Yes, it seems to be a latency issue. Thanks for all the inputs - at least we have somewhere to start, if not viable solutions. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
