Re: [Flightgear-devel] MP what data to send
From: Christian Mayer [EMAIL PROTECTED] Norman Vine wrote: Andy Ross writes: But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. -Fred ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] MP what data to send
Frederic Bouvier wrote: From: Christian Mayer [EMAIL PROTECTED] Norman Vine wrote: Andy Ross writes: But note that there is lots of opportunity for compression here; it's just that dumb general-purpose algorithms like zip are unable to find them for a single packet. A few ideas that occur to me: + Position needn't send three full 64 bit doubles, since the position will always be near the last one. Sending deltas will work (if you are careful to handle potential bugs like successive round-off errors), as will (reliably!) transmitting a zone coordinate every so often and sending packets as deltas from that. If the updates are always within ~100m of the last position, you can get each position coordinate down to 15 bits or so and still achieve millimeter precision. Yup.. using deltas should be a big win Yes, but make sure that you deal with the precision loss smoothly. E.g. x-Position (in base 10), every 10 steps you'll transmit the real position and no delta: data data Source to transmit: transmitted: result: 1. 100.00 100.00 100.0 100.00 And what happens with deltas and positions when you will lose UDP packets ? How will you restore the correct position or orientation ? Perhaps, from time to time, it will be good to send absolute positions to resynch. Just read what I've written. In my example I wrote every 10 steps you'll transmit the real position and no delta: which is the absolute position. You'll need that, not only due to the lost packages but also due to the precision loss My post was about how to handle the difference that occures between the absolute position and the position the other computer thinks where I am. This difference is caused by precision loss and lost packages. CU, Christian -- The idea is to die young as late as possible.-- Ashley Montague ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Virtual Cities
Simon Fowler writes: What kind of buildings and other stationary models do we need for VFR use? What would be the easiest place to start work on them? It's not that predictable. For example, around my home airport, ATC uses a water tower, a bridge, and a slightly-isolated subdivision when giving VFR instructions; to get to and from the practice area, we use a quarry, a lake, and a small bay in a river as well. In the circuit, we (can) use an apartment building off the threshold of 22, a red barn under the turn to base for 04, a railroad track under the length of the downwind for 22 or 04, and the control tower itself to line up the slant base for 22 (to stay out of the way of the approach to 25). Coming in from the west at low altitude, we know it's time to call Ottawa Terminal when we're over the Corel Centre (a sports stadium). And so on. 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] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
Victoria Welch writes: Presuming that the cvs version of plib did something, I'll try hacking around with the values in .fgfsrc and see what happens. It looks enough like it did that I have no confidence of success here, but one never knows. When you run js_demo in the plib distro, what values do you see for the axes? Are the first two 0, 0 when the stick is centred? Is the first axis -1 with the stick all the way to the left? And so on. 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] Input binding flexibility
Hi all, The recent addition of binding USB devices by name is great. No more crawling under the table to unplug and replug the yoke and pedals, which would come up in random order on a reboot and get assigned to different js? values. One issue is name variability. I have a different version of the CH pedals, where the ID, instead of CH PRODUCTS CH PRO PEDALS USB is CH Pro Pedals USB Rudder Pedals . I have edited the .xml file on my system as a workaround. Any way to allow multiple names? If not, how is the file name collision to be handled? -- Bill Earnest wde3@ptd-dot-net Linux Powered Allentown, PA, USA Computers, like air conditioners, work poorly with Windows open. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] A real C172 cockpit
FWIW, FYI: http://www.therealcockpit.com/main/index.php ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
On Saturday 13 July 2002 8:26 am, Jim Wilson wrote: Victoria Welch [EMAIL PROTECTED] said: Assuming that I have the same results I have had in the past, I'll track down that Docs/README.Joystick.html wherever plib hides it docs. Interesting that looks like one with the same name in the fg docs :-). That's in the base package...right where it says (Docs/ folder). Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel Also accessible from FG's help system! 8-O Imagine that. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Anyone using a Saitek Cyborg Gold USB Sticksuccessfully with FG ?
On Sat, 2002-07-13 at 13:44, John Check wrote: On Saturday 13 July 2002 8:26 am, Jim Wilson wrote: Victoria Welch [EMAIL PROTECTED] said: Assuming that I have the same results I have had in the past, I'll track down that Docs/README.Joystick.html wherever plib hides it docs. Interesting that looks like one with the same name in the fg docs :-). That's in the base package...right where it says (Docs/ folder). [ ... ] Also accessible from FG's help system! 8-O Imagine that. If you happen to be running netscape... I assume that is probably changeable someplace, but under linux I have plenty of desktops to keep stuff open on, so that is kind of the least of my worries ATM. Thanks take care, Vikki. -- Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer. Walking on water and developing software to specification are easy as long as both are frozen - Edward V. Berard. Do not unto others, that which you would not have others do unto you. Micro$oft Windows. I'll bet you can't install it just once! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
Vikki, I normally use a CH Product Flight Sim Yoke, but do have the Cyborg 3D Gold USB. So I removed the yoke and plugged in the Saitek. I got values from -0.8 to +0.2 or +0.3 on all four axies running js_demo (usually in ../FlightGear/bin. Then I ran jscal /dev/js4 -c to do a calibration (the Saitek was js4 in jsdemo run). After this, all axies varied from -1 to +1 in js_demo. I am running a week old CVS tarball with corresponding CVS tarball of Simgear. I did not update Plib 1.4.2, so the file joysticks.xml configures my joysticks. I did not bother to edit this file after running jscal, so I had the twist axis as rudder and the throttle axis as mixture, but other than that the plane flew normally in Flight Gear with the Saitek. Do you know that js_demo and jscal are working? If so, you should be very near to a working joystick. I would be glad to go ahead and set up a file joysticks.xml for you. I used to use .fgfsrc, but found it a lot easier to switch joysticks using joysticks.xml. Regards, Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] I have a Saitek Cyborg 3D Gold USB Stick
Hi Dave, On Sat, 2002-07-13 at 15:46, Dave Perry wrote: Vikki, I normally use a CH Product Flight Sim Yoke, but do have the Cyborg 3D Gold USB. So I removed the yoke and plugged in the Saitek. I got values from -0.8 to +0.2 or +0.3 on all four axies running js_demo (usually in ../FlightGear/bin. Then I ran jscal /dev/js4 -c to do a calibration (the Saitek was js4 in jsdemo run). After this, all axies varied from -1 to +1 in js_demo. I am running a week old CVS tarball with corresponding CVS tarball of Simgear. I did not update Plib 1.4.2, so the file joysticks.xml configures my joysticks. I did not bother to edit this file after running jscal, so I had the twist axis as rudder and the throttle axis as mixture, but other than that the plane flew normally in Flight Gear with the Saitek. Do you know that js_demo and jscal are working? If so, you should be very near to a working joystick. I would be glad to go ahead and set up a file joysticks.xml for you. I used to use .fgfsrc, but found it a lot easier to switch joysticks using joysticks.xml. Sigh, I'd like to think this is going to work. Part of the problem is that I have so many learning curves going on right at the moment that I feel like I am drowning in them :-/. Interesting to note that you comments on the stick above seem very similar and I am starting to think the deciding factor is tracking down a version of jscal that will work with mandrake. As for jscal, I am unable to locate it for mandrake. The source I found (which seems to have been an early version ?!?!?!?!) wants to be compiled into the kernel and I find that just too odd. I've been reading massive amounts of documentation and at this point I have read so much lately that it all just blends together. At this point I am running (I think?) everything from cvs including plib so I am not sure about the joysticks.xml does, goes, etc. Sorry to sound like I am burned out here, but I am :-(. I'm overall very happy to be under linux almost exclusively, but the effort to get there (heh, I am still not there, just creeping up on it - something I have done lately has managed to screw up my ability to print, add that to the list of things to fix) has been staggering, if I had just wanted the canned apps, it would have been trivial :-). As much as it bothers me to do so, I need a break and am just going to give all this up for the weekend and fire up w98 and play with fs2k2, it bugs me to do it, but it is a needed break doing something that is FUN :-) :-/. I appreciate your offer of assistance, but I am just not sure about much of anything at the moment. Perhaps I'll feel better after a break. Thanks take care, Vikki (who is aware she isn't making sense here :-). -- Victoria Welch, WV9K/7, SysAdmin, Embedded Systems Designer. Walking on water and developing software to specification are easy as long as both are frozen - Edward V. Berard. Do not unto others, that which you would not have others do unto you. Micro$oft Windows. I'll bet you can't install it just once! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A real C172 cockpit
Wolfram Kuss [EMAIL PROTECTED] said: FWIW, FYI: http://www.therealcockpit.com/main/index.php Impressive package. Expensive, but cheaper than the real thing ;-) Actually I was most impressed by the quality of the photos. Great photo work. Certainly it'd be outside the limits of fair use to turn those into 3d instrument textures for Flight Gear. Just the same, they're a nice detail reference to supplement David's pics for anyone interested in doing some models. To see what I mean look under Press and Press Images. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A real C172 cockpit
Certainly it'd be outside the limits of fair use to turn those into 3d instrument textures for Flight Gear. True, if you don't ask them. You an always ask them, and they might say yes. They might let you make up a set of FGFS instrument files that are a 1-for-1 correspondence with their product line ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A real C172 cockpit
Alex Perry [EMAIL PROTECTED] said: Certainly it'd be outside the limits of fair use to turn those into 3d instrument textures for Flight Gear. True, if you don't ask them. Of course. But they should be fully informed about GPL and it wouldn't suprise me if they didn't or couldn't go along with that. You an always ask them, and they might say yes. They might let you make up a set of FGFS instrument files that are a 1-for-1 correspondence with their product line ... Can't hurt to ask. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OT: Schedule
Hi! I am Brandon Bergren. I am currently enrolled in Systems administration at Southeast Tech. in Sioux Falls, SD, for the fall semester. I got my schedule and it seems a Curtis Olson will be teaching me Basic Electronics on tuesdays and thursdays. I was wondering if this is the same person as THE Curtis 'L.' Olson. I almost fell out of my seat while reading the schedule ;) --Brandon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] joysticks.xml for Saitek Cyborg 3D Gold USB
Vikki, Concerning joysticks.xml for your Saitek. I decided to go ahead and make a joysticks.xml file for this joystick and try it out. This file is set up for 1 or 2 engines and it includes buttons for flaps, propeller pitch, mixture, elevator trim, external view cycle, and the hat is set up to the standard 8 quadrants. Ran out of buttons, so you must use the keyboard g key to raise and lower the gear. In README.Joystick from the ../FlightGear/Docs/ directory, you see the precedence: .fgfsrc in your /home/user directory, then system.fgfsrc in $FG_ROOT (usually something like /usr/local/FlightGear or /usr/local/lib/FlightGear, depending on the switches used to configure fgfs). Then comes joystick.xml (in $FG_ROOT). Copy the attached file into which ever $FG_ROOT you are using. You may wish to save the original joysticks.xml file. Make sure you move any .fgfsrc or system.fgfsrc to different names, or fgfs will use the earlier precedence file instead of joysticks.xml. The comment at the top of the file should allow you to see which button does what. If you don't like where I assigned things, just exchange the button numbers. Also, you will need to change the line js n=4 to js n=0 or whatever is the right number. Concrning jscal. In the last several Red Hat distros, it is part of a joystick utilities RPM. It resides in /usr/bin/jscal and there is a manual page for it. I am running RH7.3 updated to kernel 2.4.18-4. Your kernel is even newer. The RH RPM is joystick-1.2.15-11. It also includes jsattach and jstest that you may see references to in the documentation. Mandrake uses RPM's right? Can't you just get the RH RPM and install it? Hope this helps. You are really closer to success than you think. Been there, don't give up! Dave ?xml version=1.0? !-- Joystick binding definitions for Saitek Cyborg 3D Gold USB joystick. This file is included by preferences.xml, and uses the context of its inclusion point; that means that you need to prepend /input/joysticks to all property names. This file defines primary flight-control bindings for a simple three-axis, three-button joystick, as follow: axis 0 (left-right): aileron axis 1 (forward-backward): elevator axis 2 (twist left-right): rudder axis 3 (slider): throttle axis 4 (hat left-right): look left or right axis 5 (hat forward-back): look ahead or behind button 0 (trigger): brakes button 1: (left of hat) reduce RPM (constant speed prop) button 2: (below hat) external view cycle button 3: (righ of hat) increase RPM (constant speed prop) button 4: (F1) trim nose down button 5: (F2) retract flaps button 6: (F3) trim nose up button 7: (F4) extend flaps button 8: () mixture rich button 9: () mixture lean hat leftlook left hat right look right hat backlook behind hat forward look forward hat diagonallook diagonal -- PropertyList js n=4 axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/aileron/property squared type=booltrue/squared /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/elevator/property factor type=double-1.0/factor squared type=booltrue/squared /binding /axis axis n=2 descRudder/desc binding commandproperty-scale/command property/controls/rudder/property offset type=double0.0/offset factor type=double1.0/factor /binding /axis axis n=3 descThrottle/desc binding commandproperty-scale/command property/controls/throttle[0]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding binding commandproperty-scale/command property/controls/throttle[1]/property offset type=double-1.0/offset factor type=double-0.5/factor /binding /axis axis n=4 desclateral view/desc binding commandproperty-scale/command property/sim/current-view/axes/lat/property factor type=double-1.0/factor /binding /axis axis n=5 desclongitudinal view/desc binding commandproperty-scale/command property/sim/current-view/axes/long/property factor type=double-1.0/factor /binding /axis button n=0 descBrakes/desc binding commandproperty-assign/command property/controls/brakes[0]/property value type=double1.0/value /binding binding commandproperty-assign/command property/controls/brakes[1]/property value type=double1.0/value /binding binding commandproperty-assign/command property/controls/brakes[2]/property value type=double1.0/value /binding mod-up binding commandproperty-assign/command property/controls/brakes[0]/property value type=double0.0/value /binding binding commandproperty-assign/command
Re: [Flightgear-devel] A-4 manual
Andy Ross [EMAIL PROTECTED] said: I've been doing really well recently with my A-4 landings, so I wrote up a putative Flight Operations Manual to record the stuff I've learned: http://www.plausible.org/a4-ops/ Andy, This is a great tutorial. I've been working on the landings, and have put 5 aircraft in the shop, but no fatals. It took me a few trys to figure out the aircraft trim for the correct approach AoA. And apparently the indicator is way out there when in a climb. From what I remember reading about it's operation it should work for climbing too. But when I try to trim at climb speed it's putting me at far too high an AoA. Right now my biggest problem is getting the throttle right on approach (too heavy handed/reactive I suspect). Maybe someday I'll get this figured out :-) Fun aircraft! Thanks, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
