Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
Curt wrote: I did some more digging and tracked down the offending subsystem. I will contact the developer off line and hopefully this will be a simple fix. It's much more enlightening if you embarass them publically. Unless it's me, of course. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Yasim wing incidence
Jim Wilwon wrote: If this is just flipping the sign why not just grep and fix all the aircraft in CVS that specify incidence? The files in CVS (most of them -- the ones that weren't pre-fixed for the 0.9.9 release) specify incidence as documented, not as it was actually implemented in code. So in principle none of them have to be modified. In practice, changing parameters in a FDM file can have unintended consequences. The old files were tuned for a broken implementation, and may need some re-tuning for the fixed one. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Melchior FRANZ wrote: Now the question is: should fgfs work around a broken gcc release, when there's hope that the next version will be fixed? Or is it not a bug, Strictly, it's not a bug. Within a single function, it is not legal to have two pointers of different types pointing to the same address. It never has been, AFAIK, but the gcc optimizer was never sophisticated enough to cause problems. It is now. :) Does adding --no-strict-aliasing to the CFLAGS fix the problem? Maybe we should consider that for the near term... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
Melchior FRANZ wrote: Umm ... but is sizeof(float)==sizeof(int) on all supported platforms? It's not on Atari ST, for example (IIRC). :-/ Really? I honestly thought all 68k platforms used a 32 bit int to match the register width. Certainly all 68k gcc variants do (gcc can't support a 16 bit int for internal reasons, apparently). But yeah -- on all useful platforms an int is a 32 bit 2's complement number and a float is a 32 bit value in IEEE format. The only types that have multiple sizes to worry about are pointers and long, each of which can be either 32 or 64 bits depending on platform. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] yasim(-test) vs fgfs
Joacim Persson wrote: I've discovered a difference between how fgfs calls the yasim solver, and how the yasim binary (aka yasim-test) does it. I have a -yasim.xml which doesn't pass yasim(-test) but which fgfs accepts... ?:-P So what is the difference? Number of iterations? That sounds like a bug. They are intended to produce identical behavior. Is it possible you have a yasim binary build from a different version of the code than your fgfs? Note specifically the recent incidence fix. Mathias Froelich wrote: I know of one difference: Ground intersection test Indeed. But the solver doesn't do any gear testing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Harald JOHNSEN wrote:
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) dummy;
return (*tmp);
This violates the strict aliasing rules that are the default for
gcc 4.x -- I believe it issues a warning to that effect. (Although
in this case the compiler should be able to detect that the pointer
can never be incorrectly aliased and optimize the warning away). If you
want to type-pun, you need to use a union:
union { int i; float f; } dummy;
dummy.i = XDR_decode_int32(f_Val);
return dummy.f;
The union trick also tends to be a little more readable, IMHO.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] YASim twist/incidence fix
I've been short of time recently, but Curt is keen on getting the twist/incidence fix into YASim in time for the next release. So I've committed it more or less blind. :) A quick grep through the source code gives a list of affected aircraft configurations that I've attached below. The fix is *supposed* to either do nothing or improve handling of each of these aircraft, but problems do happen. If anyone is interested in QA work, could you load up and play with some/all of these aircraft to validate that nothing weird has happened? Just make sure that (1) it solves and (2) doesn't have handling bugs like odd stalling, snap rolls, etc... (or at least handling bugs that weren't present before). The one exception is (I think) the Citation, which had its twist and incidence numbers negated in CVS prior to the 0.9.9 release. That one will have to be re-negated now that the fix is in code. Planes affected: MiG-15/MiG-15bis-yasim.xml B-52F/B-52F-yasim.xml b29/b29-yasim.xml Hurricane/hurricaneIIb.xml Citation-Bravo/Citation-Bravo-yasim.xml dhc2/dhc2F.xml dc3/dc3.xml Hunter/hunter-yasim-2t.xml Hunter/hunter-yasim.xml YF-23/YF-23-yasim.xml pa28-161/pa28-161.xml tu154/tu154.xml seahawk/seahawk-3d-yasim.xml seahawk/seahawk-yasim.xml Citation/Citation-II-yasim.xml j22/j22-yasim.xml 747/747.xml p51d/p51d.xml AN-225/AN-225-yasim.xml j3cub/j3cub.xml Spitfire/spitfireIIa.xml Spitfire/seafireIIIc.xml A-10/A-10-yasim.xml TU-114/TU-114-yasim.xml b1900d/b1900d.xml Thanks, Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] stable/unstable branches [was: No 0.9.9 scenery yet?]
Steve Hosgood wrote: It may not be universally true, but quite a few projects only start the even/odd numbering scheme *after* they've got as far as 1.0.0 My $0.02 is that we don't want to bother with this. The purpose to having a stable release is that third parties can build on the product and still get bug fixes without having to worry about regressions and interface changes in the development tree. For something as widely deployed as the kernel, that makes sense. For us? Shrug. Do we even have any such third parties? If we do, what is the argument for us bearing the support costs and not them? The cost of a separate development tree (well, one that works as intended and isn't just a synonym for an older version) is significant; every fix needs to be audited, applied and (the hard part) *tested* twice. Note also that even the kernel has abandoned this scheme. There are no plans on the horizon for branching off a 2.7 kernel -- new features are being folded into the 2.6 tree as they arrive. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock wrote: I'm not sure if it is possible or reasonable to implement a moving map GPS display in NASAL and instrument XML, however, a simple text display might be feasible. Probably not, but you might still want to script some of the functionality -- especially for complicated avionics that interact with other aircraft systems. You'll want to stay away from actual graphics/rendering in Nasal, obviously, but everything else is fair game. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff [EMAIL PROTECTED] wrote: Alex Romosan writes: David Luff [EMAIL PROTECTED] writes: Urgghh - email addy in header! And from an unexpected source, too: User-Agent: Gnus/5.110004 (No Gnus v0.4) Emacs/21.4 (gnu/linux) Someone needs to plonk the emacs folks, methinks. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: NASAL Scripted Pushback
Steve Knoblock wrote: 1. Will Nasal scripting give me all options to program the push-back function (incl. playing sound files and checking distances to other planes or to next taxi way)? I am not sure of this, but NASAL can listen for properties and then change properties, Yes, Nasal interacts with the rest of FlightGear through the property and FGCommand subsystems, and in a few special cases by extension functions (settimer() and random() being the only ones I can think of off the top of my head). So anything you can do through those mechanisms is scriptable. Anything the you *can't* do through those mechanisms is either something that we don't want to script (3D rendering, FDM internals), or just haven't gotten around to. Wiring up property/command interfaces for C++ subsystems is generally pretty easy. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pressure distribution calculation on planes when landing?
Dai Qiang wrote: I'm wondering, if it's possible to calculate and record the pressure distribution on all parts of a plane, e.g. gears, wings etc, when it's landing? Landing gear could be done fairly easily, as the force along the gear strut is known to the FDM. But stress on other aircraft parts are basically impossible with a FDM at our level of precision: you would need a full finite-element model of every load-bearing structure on the aircraft. That's definitely not a task for a real-time simulation. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 compile problem
Brian Thomson wrote: I'm attempting to compile FlightGear 0.9.9 on Linspire 5.0. Compiling simgear 0.9.9 went fine /usr/lib/libsgenvironment.so: undefined reference to Heh, methinks you're doing a bit more than compiling there. As a hint for the future: when you hack at your software and discover that you've instroduced a bug and need to ask for help, it generally works much better if you tell the developers what it is you have been doing. Your use of attempting to compile might otherwise lead us to believe that you were using the same build system that the rest of us are. :) Briefly: much of the test code in the trees likes to link against libraries which contain (unused) code that depends on other libraries. When the linker can see them all on the command line, it can figure it out. But the runtime linker isn't nearly so bright, and needs to be told explicitly which libraries to load in to resolve missing symbols. So your shared libraries either need to list all the dependent libraries when you link them, or you need to play games with LD_PRELOAD to make sure everything is there. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 0.9.9 compile problem
Brian Thomason wrote: Perhaps I wasn't clear enough. I should have stated that I am attemtping to build 0.9.9 using the debian source package framework for 0.9.8, where the .a files are converted to shared object files. Apologies for my joking at your expense, I didn't notice your email address. :) Hrm... Why is debian shipping shared libraries for SimGear? As discussed, that is not the intended deployment mode for the upstream package (us!), so it seems awfully strange for debian (or Linspire?) to be making its own decisions there. Does it do the same for plib? I think most of us would honestly prefer that if Linspire users are going to install a FlightGear binary, it match the ones that we are developing on as closely as practical. SimGear really isn't designed to be a shared library anyway -- the various libsg*.a files just match the directory structure of the source code. As Alex pointed out, they have complicated dependency relationships that are going to be difficult to manage. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
Melchior FRANZ wrote: I also wanted to show the Crusader in one shot. But now that it has been withdrawn from CVS (with very questionable arguments Not to start a flame war, but maybe someone could bang out a quickie YASim model for the F-8 so it can be shipped in the 0.9.9 release? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible bug in yasim (not sure though?)
George Patterson wrote: I have compiled and installed pre3 and noticed that I was not able to load the b1900d Yeah, that was me. The patch yesterday for turn off the engines when out of fuel broke the solver for turbine aircraft. Fixed. That'll teach me to add features right before release. Apologies. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] compile error for pre3
Stewart Andreason wrote: Since Flightgear-0.9.9-pre2 compiled fine without any problems, I was surprised to see this: fg_init.cxx:1581: error: `setRealtimeProperty' undeclared This is SimGear version skew. You need to use the properly matched version of SimGear, but are probably building against an older one still in your /usr/local. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Citation pitch down divergence. Fixed?
After some prodding from Curt, I finally spent a few hours yesterday tracking down the pitch down discontinuity in the Citation. Well, I didn't find a discontinuity. I can now graph the lift curve from a Surface (a real one, part of the real aircraft, not an isolated test instance) and verify that it's valid and correct looking through the entire AoA regime. But I think I *did* find the problem: it seems that I, er, misdocumented the incidence and twist parameters in the YASim configuration. The README.yasim file states that these numbers are positive for positive AoA (i.e. a positive incidence on a wing generates extra lift, and a negative twist causes the wing tips to stall after the root). But the code was interpreting the number as a rotation about the YASim Y axis, which points out the left wing and therefore is positive *down*. Oops. The reason the citation exhibited this especially is just luck: the file lists an incidence of 3.0 (which is relatively high, and the inversion bug therefore puts the wing 3 degrees closer to a negative stall) the solver happens to generate a nose-down cruise configuration of about 1.5 degrees, and the elevator authority is actually quite high (which causes higher pitch rates under autopilot control). So the bottom line is that Curt was right: it *was* the negative AoA stall (probably the tail's, not the wing's) happening too soon. :) I'm a little leery of changing this in code this close to a release -- the risk of breaking working aircraft is too high. For the short term, this can be fixed in the Citation-II.xml file by simply negating the incidence and twist values on the wing. I did this and tried the autopilot in a maximum speed cruise at low level (which should produce the highest nose-down AoA) without any odd behavior. Curt, can you try that and see if it appears to fix the handling issues? Likewise, anyone with a YASim aircraft that makes use of incidence or twist values is encouraged to try the same modification and report any problems. We can go back after the release and fix the code and all the aircraft files. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. great sigh of relief Excellent. Thanks for your work, I was completely out of ideas on this. :) Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've personally built and tested it using the Sun Studio compiler on Sparc, and the windows builds are done using MSVC. That proves nothing, of course, but if code were a democracy MIPSpro would be losing 3:1. :) Note that the naRef structure is a nested union, and the code makes heavy use of structure assignment of these things. That's not a common idiom (most other interpreters just use casts), so I wouldn't be shocked if it triggered a bug or two. There's one spot in there already (I forget who found it -- not me, anyway) with a workaround for a gcc 2.95 code generation bug. If you want to continue tracking this down, you could try starting with a gcc library, and replace each .o file in turn with a MIPSpro one to figure out where the faulty code generation is (it might be more than one location, of course), then start moving code out symbol-by-symbol until you zero in on the location. Then we can try to rewrite it so it compiles correctly. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] uneven brakes (and another spotted bug+fix)
Joacim Persson wrote: Using a Saitek stick, [..] The nasal function interpolate() works on left wheel only, not the right wheel, making the plane twist when brakes are applied (or released). One can see it by watching the internal properties (controls/gear) while applying the wheel brakes. Right wheel jumps from 0.0 to 1.0 in an instant. Which stick, and which aircraft? I don't see anything weird in the joystick configurations, at least. The C++ input handling is a possibility, but the FDM configuration could be glitched too. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] (no subject)
Joacim Persson wrote: I've also experimented with commenting out the lines about left gear in the joystick config file (and thus tie the button to right gear only), to see if it had something to do with nasal per se. (as in not being able to handle two interpolate simultaneously) But the right wheel keeps braking hard. Theory: the right brake property is flagged as a boolean in the property tree, and is clamping all values to 0 or 1. This can be complicated to debug -- you need to figure out where it's created. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: uneven brakes mystery
Joacim Persson wrote: Andy Ross wrote: Which stick [...]? Saitek Cyborg Evo [...] I have pinned down the exact moment in gdb when brake-right is set to 1.0 (without a cause, so to speak), but I feel I don't have enough knowledge about how FG is designed to come further. What this is showing is a joystick button (not a key) causing a property-assign binding to fire, which is setting your brake property. The problem is, the Cyborg Evo joystick definition doesn't *have* any property-assign bindings. It does everything with nasal scripts. Something odd is going on -- apparently some other stick's binding for the right brake only is being picked up by your configuration. Have you modified the name properties of any of you joysticks files? Can you verify that your base package is unmodified? If you want to continue playing with the debugger, you could try stepping through the joystick initialization (or, alternatively, selectively removing files from your Input/Joysticks directory) to figure out which stick is being incorrectly loaded, and why. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: So far I've tracked down the problem to the getMember() function simgear/nasal/code.c. The problem starts to appear when ctx-opTop increments from 2 to 3 in which case obj.ref.reftag isn't valid anymore. If it's not happening across a garbage collection, then I strongly suspect a compiler bug. Note that opTop is only modified when a new reference (with valid reftag) has been pushed on the stack. Have you tried turning off optimization in the Nasal code? No need to do it for the whole project; just hand-modifying the simgear/nasal/Makefile should be sufficient. Again: I've run fairly rigorous tests on both Sparc and PPC at this point with no failures, so I think we've pretty much ruled out endianness. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: Is is certain that reftag is set in this case? Yes. The modification to opTop is a pop, the stack contents have already been pushed at that point. I just scanned through the loop again, and don't see anywhere that an object gets copied onto the stack incorrectly -- the only way it's done is to copy the whole naRef at once, which copies the reftag also. Even a garbage collection wouldn't cause this behavior, as it would clean up the pointed-to object and not the reference on the stack. Note, by the way, that reftag is not guaranteed to be present -- if the naRef is a number, you will see the (non-NaN) top half of the double instead. The behavior you are seeing is consistent with a number being stored in the local variable hash in the slot where you used to see an object. No idea why that might happen either. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] B1900d: Fuel consumption when engine has stopped.
George Patterson wrote: /engines/engine/fuel-flow-gph[0] is shown as -0.232562 (fluctuates rapidly) /engines/engine/running[0] is shown as false. Good catch. The really primitive stop support in the turbine engine model didn't set the fuel flow value. This is fixed, such as it is. Real start/stop support is on my list, and will probably be done with some Nasal such that it can be hacked on a per-engine basis. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Mike Kopack wrote: It's not so much an issue of San Fran being BAD, it's just that KSFO is pretty far from downtown. We're talking about small slow-flying UAV's in my project (I'm using the Piper as a surrogate), so having to take off that far away means my demo is like 45 minutes long. As a left-field suggestion: how about defining the runways of the old NAS Alameda, which is just south of downtown Oakland and immediately across the bay from San Francisco. The base was closed in the mid 90's, I believe, and is now being converted into industrial loft space. But the runways are still there clear as day: http://maps.google.com/maps?ll=37.786114,-122.318387spn=0.027226,0.028824t=khl=en The folks who like to play with the carrier aircraft probably wouldn't mind having this active, either. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wish list for next release
Erik Hofman wrote: Ampere K. Hardraade wrote: A texcopy function that allows one to copy one part of the texture to another would be useful. Although it would be doable, one problem with this is that the textures themselves are stored in video memory so updating them isn't as easy as it sounds. And the APIs are complicated. Traditional (1.1) OpenGL can only do this to and from the framebuffer, not between textures. The last time I looked at this problem, about 2 years ago, there were a bunch of extensions being proposed that would represent all memory areas on the graphics card (vertex buffers, textures, framebuffers, depthbuffers, etc...) with a unified API that was tentatively called the uberbuffer. I'm not sure what happened to this, or what the status is of driver support on modern cards. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CPU usage issue
Drew wrote: I have a Windows build of FlightGear, and have recently discovered when the FlightGear window is minimized, the CPU usage jumps up to 100%. Does anyone have any idea why this happens? What can be done to fix this? Didn't this subject come up before? Note that CPU usage is at 100% is neither a bug nor a problem by itself. Do you need more CPU for calculating something else? Are your other applications unresponsive? FlightGear, like most games or real-time simulations, has a frame-based main loop. It calculates a frame, renders it, and then immediately goes back to the start of the loop to render the next one. That keeps the frame rate as high as possible given the resources available. There is currently no provision for throttling the frame rate in situations where the window is minimized, although I suppose that could be done. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
Kitts wrote: I would like to know if there is any documentation on the XML file format used within FlightGear. First, note that the file format is used to generate a SGPropertyNode C++ object. So the details of how that class should drive your understanding of the on-disk representation. All the XML files in FlightGear seem to include PropertyList as the first node. Is this node name mandatory or can the name be anything else? All XML files must have a top-level node. This is the one used by a property file. It is mandatory. This is the generated XML but how does one read the attributes present within the angled brackets? I am referring to the information such as bar n=1 type=double. Property nodes have types, indicating what kind of data they store. This one is a double, which corresponds to the built-in double precision floating poitn type. Property nodes also have numeric indices to order properties of the same name (e.g. /controls/engine/engines[2]/throttle). Note that these are not strictly required to be contiguous, they can have any number you like. But most code tends to assume a C-style array convention, where the first property has an index of zero. If the index is left out, then the property is assigned to the next highest index available. This is why the file you reference can leave out the n=0 index on the first bar nodes (although I'd argue that that's bad style -- either use implicit indices or explicit ones, but don't mix them). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] About flightgears XML property list format
Kitts wrote: Yes. But as i understand, the value of the leaf node may be read either with getDoubleValue or getFloatValue or getStringValue etc. How does one reading the node's value know what is the type so as to call the appropriate method? Unless this is an internal thing meant for the low level XML parser. The library will convert for you to the requested type. The purpose of the XML attribute is to define the actual internal type. So if you define the type as double and do a setStringValue() with foo, you will get back zero and not the string. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATC AIEntity.cxx, 1.12,
Vivian Meazza discovered: AIFlightPlan.cxx:69: error: passing `const std::string' as `this' argument of `std::basic_string_CharT, _Traits, _Alloc std::basic_string_CharT, _Traits, _Alloc::operator=(const _CharT*) [with _CharT = char, _Traits = std::char_traitschar, _Alloc = std::allocatorchar]' discards qualifiers Heh, don't you just *love* C++ error messages? :) Translated: AIFlightPlan.cxx:69: error: passing `const string' as `this' argument of `string::operator=()' discards qualifiers You can't assign to a const object, basically. No idea why this compiles correctly on other platforms... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speed problems under Solaris
Martin Spott wrote: I suspect the network stuff is coupled to the same loop as is the screen display. Just a guess, though It is. Everything except for terrain tile I/O is driven out of the main loop. Probably something that should be fixed... Note that we're going to have to start thinking about threading designs soon anyway, if we want to take advantage of all the fancy multi-core/multi-thread CPUs coming down the pipe. Rendering obviously has to stay within a single thread, but how much non-rendering work can we push out to worker threads? Ideally, everything would be handed to the renderer thread each frame, with all the matrices pre-cooked and ready for OpenGL calls. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Threading for SMP, boon or bane?
Curtis L. Olson wrote: I would like to make a case for non-threading from the standpoint of simplicity. We have had (and probably still have) some extremely subtle and extremely difficult to track bugs in our threaded tile loader. I don't disagree at all. Everything you say is true, and a reason to avoid threading wherever possible. Naive thread architectures are invariably a disaster. But unfortunately the hardware world conspires against us -- SMP is rapidly becoming the rule rather than the exception for high performance desktops. Note that there are a few spots where we could split out separate threads in a relatively clean manner: + FDM: Put a lock around the input and output stages (or wrap them into an object that can be placed in a synchronized queue) and let the actual numerics work happen on a different CPU. The advantage here is that you can crank up the simulation rate quite a bit on SMP/multicore boxes, leading to (at least with YASim) more stable ground handling. + Audio: drive the OpenAL thread with a simple command stream from the main loop. One many systems, this will (might, if OpenAL doesn't already do this) move the mixing off of the main CPU, which is good. Even better, it will decouple the audio stream from the main loop latency issues and make skips easier to handle. + Rendering: One idea here would be to clone a separate scene graph (just the non-leaf animation nodes, really) and let one thread (the renderer) draw it while another (the main loop) gets the next one ready for rendering. When done, you do a synchronized graph swap, or even triple-buffer it for higher throughput at the expense of latency. This would require significant surgery to the existing model/animation code (and, to a lesser extent, the GUI and tile code) to store the property values somewhere instead of reading them at render-time. + Everything else: This thread would contain the existing main loop, and its basic structure wouldn't change. Note that this design allows threads live by relatively simple rules. The main loop doesn't change much except where direct calls are replaced by commands to be queued. And the worker threads all work only on their internal data; they don't need (and are forbidden) to touch external state like the property tree. The first two could be done with fairly minimal code, actually. The renderer changes would be more significant. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Two problems - 1 easy and 1 hard! - in XP using MSVC7
Harald JOHNSEN wrote: Geoff Air wrote: Note, Windows is not completely out of memory, Perhaps that the system allows *only* 1GB per process ;-) That's an interesting point. A quick google comes up with this MSDN page that seems to indicate that XP uses a 2/2 split of process address space, with an optional boot flag that will get you to 3G. http://www.microsoft.com/whdc/system/platform/server/PAE/PAEmem.mspx Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Winter Textures
Erik Hofman wrote: ftp://ftp.uni-duisburg.de/FlightGear/Misc_erh/winter.tar.bz2 Karsten Krispin wrote: I'am not able to open any of them. Winter.tar.bz2 seems to be empty, for wt-source I need a user/pass kombination... AJ MacLeod wrote: Error 550 here (Not a directory) for both those files. Heh, automated tools don't provide much in the way of debugging aids. :) The files lack read permission: -rw-r- 1 erh user 9524892 Oct 21 14:47 winter.tar.bz2 -rw-r- 1 erh user 12209075 Oct 21 14:51 wt-source.tar.bz2 -rw-r- 1 erh user 10589413 Oct 21 16:26 winter.zip Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with 'V' (backwards view) on Mac os X
Ima Sudonim wrote: I noticed that with latest CVS on mac os x, I can scroll thru views (forward) with 'v' as many times as I like, but that 'V' (reverse) only works 1-3 times until I reach the view that has a name ending in 'w/o yaw'. 'V' will no longer work, until I move forward in the views with 'v' at least once. Then the 'V' cycle works (or fails to work) as mentioned above. Hrm... it works for me on linux. Are any other keys affected? Specifically, check the operation of other shifted keys. If I had to guess what would cause something like this, it would be a keymap bug in the OS X plib or glut port... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Problems with 'V' (backwards view) on Mac os X, fixed
[ Unrelated nit: who's mail client keeps breaking this thread? ] Ima Sudonim wrote: The actual problem was my error: the number-views was one less than the actual number of views. Sorry to waste bandwidth on a user error... OK, then the real symptom here is an interaction with the Nasal view management code, which doesn't read number-views at all, but instead loops through the actual property children of the view node. I agree with Melchior: what is this thing doing there? Who reads it, and why do we need it? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Taxiway design discussion
Martin Spott: Norman Vine wrote: I vote for everything being triangle based like the underlying renderer This puts us at risk to run into huge datasets for every taxiway junction. What about a purely symbolic representation? Store just centerline and width for each taxiway, and keep the existing polygonal representation for tarmac areas. Throw out the pre-cut airport This means that the tile loader will be forced to do some computational geometry at load time to decide on the actual polygons to be rendered by OpenGL. But that's not likely to be too much -- even the biggest airpots have no more than 30 taxiways with no more than ~4 curves on each. Figure an individual curve has no more than 10 segments, with 6 polygons for each segment (two yellow paint, four pavement). So that's a few thousand polygons generated and intersect per airport loaded. Not so bad, really -- note that because it can happen in the loader thread, and therefore make good use of the multi-dispatch multi-core CPUs that are becoming so popular these days. The biggest advantage is that (if you do it with the runways too) it means that the airports can be generated at runtime and edited by the user without doing a terragear scenery regeneration. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Oliver Schroeder wrote: Andy Ross wrote: The server only needs one socket for its whole lifetime. Of course, but this solves only part of the problem. The main problem is, that a a NAT router may decide to not accept (ie. forward to the client) any packets we send back to it. It may work with more than 80% of current existant NAT routers, but it still does not work for the other 20% or so. I think the ratio is more like 1000:1, honestly. I have never seen a piece of consumer hardware that is broken in that way. Is there a particular model you are worried about? Note that most internet games would also fail across such a device, so it would be unlikely to be successful in the marketplace. The whole idea of port forwarding is to enable exactly this kind of code. Simplicity is important. Junk the connected socket and just use recvfrom/sendto, you will be much happier. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
Oliver Schroeder wrote: So the server has to reread the port from the UDP header everytime it reseives new data from the client and recreate a socket for it (and clse the existing one of course). Er, no. Check the man page of sendto. :) The server only needs one socket for its whole lifetime. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] [BUG] fix a NASAL error when the WB dialog is open w/jsbsim
Vassilii Khachaturov wrote:
The length is due to the diff inability to say that a lot of
lines were just indented right (as they were put inside an else
{} )
Use the -w argument to diff to eliminate the whitespace noise for
readability.
But regardless, don't do this. :)
Wrapping huge blocks of code (like this one, which is a big GUI
object creation routine) inside giant if() statements is *very*
bad for readability, and even worse for maintainability. If you
absolutely have to, then it is almost always better to split off
more functions as in:
if(props.globals.getNode(/yasim) == nil) {
popupWarningDialog();
} else {
createWBDialog();
}
A bigger issue, however, is that this is *not* supposed to be a
YASim-specific dialog! All it does is set fuel and weight
quantities in the property system, and the intent was always that
it would be FDM-independent. As it happens, YASim is the only
FDM that reads those properties, but that is hopefully a
temporary situation. This patch, IMHO, provides a disincentive
for the JSBSim folks to implement this feature as it explicitly
cuts them off from the dialog for testing.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer ports
Jim Campbell wrote: Anyone transmitting un-encrypted data across a world wide internet needs to think ahead a little. Every hacker will be rubbing their hands with glee before trying to hit you on these ports you have just announced. [...] This really isn't much of an issue. The attack you posit is requires a man in the middle, and this is a very rare failure mode -- it essentially requires a compromised router somewhere between the client and server. It's very much not a script kiddy kind of attack; the announcement you mention requires elaborate preparation and a special case vulnerability to detect. Maybe I am paranoid (well known for it in my previous job!) but a denial-of-service attack on your multi-player ports will soon wreck your response times! No one is going to care about DoSing a single FlightGear multiplayer client or server. There's no payoff there for the attacker. The scarier doomsday scenario would be a bug in the MP code (on either side) allowing an attacker to compromise the affected machines. But this is a problem for almost all network software, and can be productively treated by careful coding. There's a *lot* of unencrypted UDP software out there. If you *really* want to avoid having unencrypted packets going over the public internet, you can always do it over an encrypted tunnel (IPsec, VPN, ppp-over-ssh, etc...) without changing the current code at all. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
James Turner wrote: This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing This is a mischaracterisation. All consumer NAT routers of which I am aware do automatic port forwarding of UDP connections. The problem you are having is a misfeature in the MP server. It should be replying to the source port address, and not to a hard-coded standard UDP port on the client (which may have been munged by intervening routers). Properly done, UDP works just like TCP -- the client connects to a well-known port on the server and the server replies to the same connection. No client port needs to be specified. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] a question on Sound/fg_fx.cxx /sim/sound/pause processing
Curtis L. Olson wrote: Oliver Schroeder wrote: Which reminds me of another thing. Is it possible to use /dev/dsp in a non-blocking mode? My general opinion is I'm not sure I would like to see us overly complicate the flightgear code to work around older hardware limitations. [...] This isn't a problem on most newer audio hardware which happily knows how to share/mix between multiple audio applications. Hardware mixing is, of course, the best solution, but note also that OpenAL can be built with any of a zillion back ends, among them the various sounds servers (esd, arts) which do their own mixing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Further Solaris incompatibilities
Martin Spott wrote:
shadanim.cxx:178: error: `fmodf' undeclared (first use this function)
Well, I tried a (too) simple fix my replacing fmodf with modf which
_does_ exist on Solaris8 but [...]
These functions don't do quite this same thing, but you can implement
one instead of the other:
#ifdef __sun
static float fmodf(float x, float y)
{
double ipart;
return (float)modf(x/y, ipart);
}
#endif
But the simplest solution is to use the standard fmod() (which returns
a double) instead of fmodf() (which returns a float) by casting the
result to a float.
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
Ampere K. Hardraade wrote: Curtis L. Olson wrote: Ampere K. Hardraade wrote: By cvs snapshots, I mean binary-snapshots packed into .deb, .rpm, etc. If someone wants to do this, and promises to keep up on it, I can put a link on the FG web site ... How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? Snapshot builds should generally be identified by their date. Alternatively, you can use a sequential build number, as is common with large commercial projects. But real version numbers typically indicate a distinct release, with a QA process, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
Erik Hofman wrote: I would like to see Nasal working again on IRIX. I think this is a nice task for Andy ... I'm out of ideas at this point. All the Nasal code I can run in isolation (which now includes several multi-threaded stress tests that work the garbage collector *far* more exhaustively than fgfs) works perfectly well on ppc/OS X and sparc/solaris. At this point, I'm starting to wonder if this isn't a memory corruption issue from somewhere else in the code that just happens to hit the Nasal interpreter state on Irix... Basically, I give up. Sorry. :( Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: Define SUN; Was: [Flightgear-devel] RFC: FlightGear 0.9.9
Martin Spott wrote: I remembered Andy's pointer to http://predef.sourceforge.net/preos.html and had a look at the different ways how Solaris-specific defines are currently implemented within FlightGear and required libraries: [...] SimGear/simgear/nasal/nasal.h: defined(sun386) [...] Would anyone object to a patch that unifies this to (__sun)? Sounds good to me. Although with the nasal.h one I think I'd prefer to change that code to one that detects CPU architectures specifically, without dependence on OS-specific header files. It's getting hard to read already, and really isn't much more portable than a big enumeration of architecture defines. On a similar note, we're using __CYGWIN__ a *lot* in the current source code seemingly as a synonym for windows with gcc and not msvc, which isn't really correct. The right way to test this would be to look for _WIN32 and __gcc__ (or !_MSC_VER), which will continue to work even under, say, mingw32. There was a bug that came up in IRC a month or two ago that was related to exactly this issue, IIRC. A CYGWIN got stuck in as a synonym for WIN32, and that caused a build failure under MSVC (or Borland, maybe, I forget the details). Cygwin is, strictly, a Unix environment and should never need to be tested except where it is incompatible with our default unix/linux code. On windows, we should be trying to build to the WIN32 API and using _WIN32 as the appropriate test. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
Martin Spott wrote: Have you tried on older Solaris setups than Solaris10 ? Did you use GCC on solaris or SunStudio10? Only Solaris 10, but with both compilers (I used the gcc Sun installs in /usr/sfw/bin and the free download of SUNWspro). But Solaris 10 is freely available, so if the problem really is OS version dependent (which seems unlikely, IMHO), then I think the real solution is just to upgrade. Note that I'm not able to run FlightGear on my Sun box, it's just too slow. And I only have shell access to the mac, so I'm only able to run the Nasal test stuff. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Hans-Georg Wunder wrote: Now there three ways to go to get the panel GPL compliant: There still seems to be a misunderstanding. The issue here is not a minor technicality regarging open source license compatibility. It is that this package got caught using artwork to which the author does not own the copyright! This is not GPL incompliance, this is called copyright infringement. It is possible that the little icons were the only Microsoft artwork at issue, but there is no way we can know that unless we know exactly how the artwork in the 707 package was generated. Especially for us, because the mechanism behing the GPL is based on the idea of copyright protection, it is extremely important that we remain clean of perceived problems. When I go to the aircarft museum and take some cockpit photos. Can I use them for panel painting (like the 737 panel) ?? Generally yes. There is a long tradition (much longer than computers or aircraft have been around) of people creating and distributed simulated representations of objects using the real thing as a reference. That doesn't mean that you *can't* be asked to stop, of course, but that it seems unlikely that you will. Note, however, that many museums have a no cameras policy (which has nothing to do with copyright law, although it is intended to protect their exhibits' uniqueness). So you may need to be sneaky when you take the photos. :) - Do we have a place to store aircrafts with uncompliant aircrafts ??? I have no objection to making separate distributions of aircraft with minor license incompatibilities. But under no circumstances should the FlightGear project distribute or link to content with known copyright problems, sorry. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Alex Romosan wrote: hmm, there seems to be a lot of junk in this file: Actually, this file is in fact a gzipped tar file containing a single TACAN_freq.txt file. Is that intended? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] Flight plan and startup in air
[cc'd to flightgear-devel b/c of the internals explanation] Jeff McBride wrote: Andy Ross wrote: The current helicopter FDM does not support variable rotor speed. The spin up is entirely animation. You are flying just fine. I don't know what FDM you are using, but when I fly the bo105 (using 0.9.8), there is definitely a spin up time where I have only partial lift. Or else it's a very good animation:). OK, I had to go look this one up. It turns out that there is a *boolean* property controling engine-on for the helicopter FDM, which is wired to the engine[0] magnetos property by the FDM configuration. This in turn is driven via a timer by Melchior's Nasal code in bo105.nas. This inspects the /sim/model/bo105/state property to determine what the current state is, and to watch for changes. The default startup state defined in bo105-set.xml is 0, indicating off. You should be able to change /sim/model/bo105/state to 2 to start with the engine on, either in bo105-set.xml or (I think, if I understand the precedence correctly) your preferences.xml file, or the rc file, or the command line. But again note: this is a boolean property. There is no actual suppot for engine starup or shutdown in the helicopter FDM (which, now that I think about it, serves as good evidence that an ugly eye-candy hack is in fact an acceptable implementation of startup/shutdown for YASim. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Microsoft artwork (!) in the 707 panel
Hans-Georg Wunder wrote: In the package there is a GPL-license. If this is enough, then everything is OK regarding the panel. Unfortunately, due to clear evidence of (minor, admittedly) copyright violation, this is not enough. The issue isn't license compatibility, it is copyright ownership. John Carty cannot legally grant a license to artwork he does not own. We need to be 100% sure that the people granting the license (GPL or otherwise) own the copyright. I wrote John a mail and told him, what Iam going to do, but I got no answer. At this point, I think a statement from Mr. Carty is really the only thing that will be acceptable. It's possible he didn't understand the rules, and generated some of the artwork via screenshots of other aircraft in MSFS. That's a showstopper for us. Obviously Innis's model and FDM configuration are fine. But my strong suggestion is not to commit the panel until we can trace the history of every image in it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TAT in Yasim
Gabor Toth wrote: I'm currently working on the EICAS display for 747-400, and I would like to display TAT (Total Air Temperature) too. Is that property available somewhere in YASim? This is not part of the FDM, the outside air temperature comes out of the environment code and is available in the /environment/temperature-degc property. There is no code currently to compute the compression heating for the static air temperature, AFAIK. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] type conversion problem for amd64
George Patterson wrote: lowlevel.cxx:84: error: invalid conversion from `uint64_t*' to `long long unsigned int*' I noticed this too. The problem is that on 64 bit systems the glibc headers have: typedef unsigned long int uint64_t; Which is correct, because a long is a 64 bit type on x86_64. Unfortunately (any C++ standards nutjobs on the list might want to clarify), it seems to be illegal according to the spec to cast between pointers to long and long long, even on platforms where they are of the same size. The identical code compiles fine with no warnings under ANSI C. I suspect the real bug here is that glibc picks a type for uint64_t that C++ thinks is different from the *other* (more portable) 64 bit integer type. But the fix for us is trivial: just change unsigned long long to uint64_t and it works. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Martin Spott wrote: Now as Andy promised I could have another try on big-endian machines I decided to actually have one. Good luck, but unfortunately it seems not to be working for Erik. I have a pretty large test suite at this point running on sparc and ppc without trouble, so I'm wondering if this is something Irix-specific? But something is hindering me that wasn't there before: This is the relevant code from simgear/compiler.h. Apparently it thinks that Solaris machines lack a stdint.h header file. This is incorrect, at least on the Solaris 10 box I have access too. The workaround should be to just eliminate the || defined(sun) bit. #if defined( _MSC_VER ) || defined(__MINGW32__) || defined(sun) typedef signed char int8_t; typedef signed short int16_t; typedef signed int int32_t; typedef signed __int64 int64_t; typedef unsigned charuint8_t; typedef unsigned short uint16_t; typedef unsigned int uint32_t; typedef unsigned __int64 uint64_t; #endif Note that it also includes these definitions for mingw builds, which is incorrect. The mingw compiler is a gcc variant, which includes stdint.h as part of the compiler suite; it is not a platform header. As far as I can see, MSVC is the only compiler we use that lacks this. Another nit is that the #include stdint.h line should probably go in an #else clause here, for symmetry. I don't know where it's being included currently. Finally, __int64 is not a standard type (is it a windowsism?), and apparently doesn't work on Sun. The most portable way to get a 64 bit value from a modern compiler is with long long and unsigned long long. I don't know any modern systems on which this fails. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear type mismatch on Solaris
Erik Hofman wrote: I'm leaning more and more to defining our own header files which solves all this troubles and byte swapping stuff. Sounds good to me. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal on Mac/Sparc/Irix fixed. Maybe.
Erik pinged me on the Nasal endianness bug, which I *think* has been
fixed. It no longer occurs with the Mac test code I have, but I
didn't find a smoking gun and can't run FlightGear on that mac (shell
access only).
Anyway, please update both (!) SimGear and FlightGear CVS sources and
let me know if I broke anything.
Ampere: there is one incompatible change here. The strc() function
has been removed in favor of the array syntax for addressing bytes
out of a string. The A380 scripts are the only code that uses it, so
I didn't bother including a compatibility version. Basically, where
you used to write strc(s, 10), you can just do s[10] now. If you
need something to limp along until you can update the code, we can use
something like this in globals.nas:
strc = func(s, n) { s[n] }
Andy
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [OT] Outlook help
Richard Bytheway wrote: I am about to go away for a week, and would like to setup my out-of-office thing in Outlook (corporate setting - no choice on email client). However I would like to prevent it replying to this, and other, lists that I am on. Does anyone know if this is possible, and if so how to do it? Resubscribe with a gmail account? (I'm serious, btw -- even your employer would probably appreciate it, personal email on work accounts is broadly frowned upon). That said, I believe that RFC822 and descendents actually specify a way to flag a message as an auto-reply, and that most list software supports it. It might just work ... :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Ampere K. Hardraade wrote: Anway, I like the idea of having a dedicated online message board for FlightGear. The primary reason why I like online message board is that all the posts in a topic are grouped under one thread and are sorted by dates, which is more organized in my opinion. This is another situation where a pro forum post has more to do with bad email client software than it does with email as a whole. All of the above (and much more) are possible with Mozilla Thunderbird. You can sort by thread, you can sort by subject/date, you can sort by date, or sender, or search. You can automatically filter into a subfolder (actually I do that part with procmail, but Thunderbird has its own filters). And being client software, it's vastly faster and more responsive than even the best websites (although as I mentioned earlier, gmail seems to be really close). It will even store all your mail on your local machine, for offline reading. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
Paul Kahler wrote: Andy Ross wrote: I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Yes, but it's sloppy. It's information that doesn't belong there. Anyone wanting to import or process that data will have to add this path stripping to their code. Better to remove it. Didn't your mother ever make you clean your room? :-) Well, sure, but that's more of a bug report for AC3D, or the Blender export script, or whatnot. It just doesn't seem like a reasonable request to force the model authors to manually remove directory paths from their files. If someone feels the need, they could submit a script that automatically trims the directory paths from an ac3d file, and encourage the content authors to use it. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
A J MacLeod wrote: Curtis L. Olson wrote: What would people think of abandoning our mailing lists and converting over to online/web-based forums? Personally, I very much prefer mailing lists. I can quite see the advantages of web-based forums, but I'm not convinced they outweigh the disadvantages. Ditto. Reading threaded mail with Thunderbird vs. with PHPbb or the like isn't even a fair comparison. It would be a very significant hardship for me to have to deal with web forums for flightgear stuff, and I'm not normally one to be a stubborn complainer. :) That said, I know I've seen gatewayed implementations that do both successfully. They have a registration-required, no-authorizing-stray-posts-necessary email interface for the clueful, and a more permissive environment for the browser jockeys. I'm not sure whether any of these are free software, but I'm sure someone's tried it... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Question: Online forums?
Oliver C. wrote: 2. The Readably of a web based forum is better. This is a joke, right? It must be all those giant, blinking, hot pink 600x200 signature GIFs that help you tell where the text content is. :) Heh, to each his own. Although I will point out that most of your complaints have more to do with poor email software and/or administration than they do to mail as a medium for discussion. If you want searchability and easy access with a web browser, for example, I can heartily recommend gmail. I don't use it myself, because I run my own IMAP server, but I have several coworkers who love the thing. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Explicit Texture Paths Committed -- not good --
Jim A wrote: I have noticed there are many instances in the data directory where developers have left explicit paths to textures, particularly in .ac files. These paths are specific to the developer's machines, and so will not be useful to others. This is benign. The plib loader strips off the leading directories on the texture file name for you and uses its own path for texture lookup. I would presume that most of these things are added not by the model authors, but by the software they are using. Other than the potentially embarassing information leakage (it exposes the author's file hierarchy), this isn't really a problem. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] DHC-6 progress
Melchior FRANZ wrote: That's not a problem, but a feature. Really. After mirroring an object you have to 'apply the rotation'. (Some key combination with a, IIRC. Ctrl-A?) I don't know why this isn't done automatically, but it is braindamage 'by design'. It's hard to fix. When you mirror a mesh, the winding order of all the polygons gets reversed, which means their normals change direction. If the mesh is stored in an optimized format (strips, fans, etc...) then it needs to be broken down and re-optimized. Big mess. It's not something that blender can't or shouldn't handle, but it *does* interact in weird ways with the geometry representation. I sympathize. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
bass pumped wrote: Andy Ross wrote: It looks to me like you're compiling CVS FlightGear with an older SimGear. I did download flightgear [...] from the 'bleeding edge' link from the website. [...] But when compiling that simgear [...] I downloaded the 0.3.8 version. Could that be a problem? These words, the same thing say. :) Yes, always match your FlightGear and SimGear versions. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter, and Citation Information Needed)
Georg Vollnhals wrote: Curtis L. Olson wrote: There are people in the world that are actually looking at FlightGear for building training simulators (certified and not certified) and these people are actually quite interested in the nit-picky details of engine operation. well argued - our real-world pilots handle these engine startup and shutdown procedures very seriously in helicopters without FADEC, ie. Eurocopter BO105, BK117. Getting the temperatures too high (hot start, ITT++) is a financial desaster. And what not might be generally known - the engines are even cooled by airflow after shutdown for a short time with the electric starter. Heh, fair enough. OK, how about this: if someone can get me reasonable data on a real turbine, I'll do a model for it and check it in such that other engines can use the same interface, even if the numbers are wrong. It doesn't need to be really involved. Basically, what I'd need is stuff like: + What the RPM curve vs. time looks like the as you hold the starter button down. + The temperature curve vs. time, showing the points where control inputs were made. + The handbook procedures that tell me which numbers are important, and which ones I can fake. + The handbook descriptions of what the failure modes are, how they are caused, and (roughly) what the effects are. I don't think anyone cares if we get this exactly right -- it doesn't matter whether the over-temp condition is exactly the same temperature as you would see on a real engine, so long as the temperature is pointing at the red area of the gauge. Maybe just a video of the panel during a successful startup would be sufficient. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
bass pumped wrote: Actually I was asking you (indirectly I guess) if there was an error in the bleeding edge file I downloaded from the simgear download page. Anyway, I will try compiling that by removing the couds3d from the solution explorer and see what happens. I'm not sure what you have, perhaps it's an old snapshot. The CVS logs show that all the files in the clouds3d directory were removed on June 25th. It's an old implementation. Really, if you want to use real bleeding edge stuff, then you want to be checking the files out of CVS directly. Cygwin contains a command line cvs client that will work with the directions you find on the website. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] MSVC build error
bass pumped wrote: I'm trying to get flightgear 9.8 built in Windows. I'm using MSVC 7 for the build. I ran into the following errors from the Nasal code. [...] cannot convert from 'naRef (__cdecl*)(naContext,naRef,int,naRef *)' to 'naCFunction' This looks like a version skew problem. That function signature (with four arguments) is the one from the current CVS version. The 0.9.8 Nasal interpreter used a different API with only two arguments. It looks to me like you're compiling CVS FlightGear (or a relatively recent snapshot) with an older SimGear. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-users] RE: Turbine Engine (Concorde, Hunter and Citation Information Needed)
Vivian Meazza wrote: YASim has not yet implemented shut down/start up controls for gas turbines. Therefore there are none for the Hawker Hunter. As far as I can see, there is no generic implementation possible for turbine startup and shutdown. Everything would have to be done specifically for each engine type. Maybe the best thing to do would be to expose some appropriate inputs to the engine code (running or not, current RPM, station temperatures, etc...) and implement the details per-engine in Nasal... I'm wholely open to suggestions. FWIW: why do people care about this stuff so much? Engine startup and shutdown is a boring, algorithmic, checklist task. It's not exactly what I'd call fun, and it certainly won't ever be implemented at a fidelity level useful for flight training. What's the deal? :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] What's up with alut?
Curtis L. Olson wrote: I was just trying to build simgear on a fresh Fedora Core 4 machine and pulled the latest OpenAL cvs snapshot. The most recent openal-cvs no longer includes alut for linux? Does anyone know what's going on there? Simgear uses alut so this is a problem (assuming I'm not doing something stupid.) They appear to have moved it into its own library now, libalut.so, which matches how it is delivered on windows. My checkout tree has an alut directory at the top level, with its own autogen.sh/configure setup. It appears to build cleanly, although it doesn't properly respect configure's --prefix option (it can't find the openal headers when they aren't installed system-wide; you have to set C_INCLUDE_PATH to get around that). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [EMAIL PROTECTED] Conference
Jon S. Berndt wrote: I'd give a lot to know what these two papers are presenting! See below: Open Source Software: Cheap Isn't Exactly Free! B. Calloni, J. McGowan, and R. Stanley, Lockheed Martin Corporation, Fort Worth, TX Bazaar Meets Cathedral: Concerns About Open Source Software in Mission Critical Systems R. Kwan, Lightsaber Computing, Fremont, CA Heh, that's amusing. This is a follow the money moment if I've ever seen one. Someone somewhere has a product that is about to be killed by free software. I found a bio page about the Rick Kwan guy here: he doesn't sound so scary: http://www.aiaa-sf.org/council/kwan_r.html It's possible we're just misreading the titles, and the talks aren't solely about OSS FUD. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] How can I participate somehow in the developping process of flightgear?
Trasca Virgil wrote: How can I participate somehow in the developping process of flightgear? Thanks in advance! Use it. Fix bugs. Get into flame wars on the lists. The usual stuff. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear freezes (float point interrupt)
Ampere K. Hardraade wrote: Lately, my computer has been freezing on me unpredictably while I am using FlightGear. (Note: I'm not saying FlightGear is to blame.) Normally, I just cold boot the machine. Today however, after multiple freezes, I was too angry to try again. I went away to do other things, and when I came back, FlightGear seems to got killed by the kernel. When I relaunch FlightGear later, I got a lot of this: Floating point interrupt (SIGFPE) This sounds to me a lot like a hardware problem. Can you make it happen when running other 3D applications? Have you tried memtest86? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer VATSIM-IVAO Network
It's not about security jvrvez wrote: Ok, They don't want that a GPL tools is used to interface their network for secutity reasons (I think this is understandable) anyway why can't we join their network with their own code? This is a non-starter. There is simply no way to make this work, sorry. They can make their code (or protocol) available under terms we can use, or not. It's not something about which we are able to compromise. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] nojoy for simgear on amd64
Mathias Fröhlich wrote: Erik Hofman wrote: I just noticed there is even an id_t in sys/types.h on IRIX, is this common? I don't think so. The only type I know that is guaranteed to be capable of storing the whole pointer is a void*. But void* is menat to be not that pure address number in the properties, it is meant to store some arbitrary property, which is ok so far. The standard type for this purpose is size_t. It is part of ANSI C, and required to be an integer type capable of holding any value formed by the difference of two char pointers. I believe it is required to by defined in sys/types.h, but any of the headers that define functions that use it (e.g. memcpy, strncpy, etc...) will pull it in. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Nasal vs. gcc 4.0.x
Just in case anyone else has noticed: I discovered today at work* that the gcc 4.0.1 shipped with Fedora Core 4 miscompiles Nasal pretty badly when the optimizer is turned on. I'm not sure what the effect will be on FlightGear specifically, as I haven't had time to do a build recently. Nonetheless, I'd suggest that anyone having trouble with FC4 (or gcc4 in general) use gcc 3.2.3 for the time being. This is available in the compat-gcc-32 package for Fedora, and you can tell the configure scripts to use it via: export CC=gcc32 I'd be curious to see if anyone else has had this problem. Andy * Yes, I'm using Nasal at work. We even have a mac here that has reproduced the endianness issues, so hopefully I'll have a fix for that ready in a few days. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] controls.throttleAxis
Josh Babcock wrote: Is there a way to get controls.throttleAxis to execute for conditions other than the throttle input changing? Specifically, I want it to also recalculate the throttle values when the rudder input changes. If I can do this I can implement steering with differential engine thrust [...] I think the input configuration is the wrong place for this. If you have a (YASim) aircraft where lateral control is always done with differential thrust, you can map the rudder properties to the throttle axis in the aircraft configuration. If you have another subsystem that wants to do this (a fly-by-wire controller, say) then you can write some Nasal that inspects the rudder input at some reasonable frequency and generates throttle changes dynamically without touching the joystick definition. The core problem is that there isn't a good (i.e. generic, non-aircraft-specific) way to tell whether a given engine index refers to a left engine or a right engine, or how far they are from the center of gravity. Any real-world system that did this would need a lot of specific tuning for a given aircraft. But the joystick files are generic -- they don't know from aircraft, they just map specific PC hardware to well-understood input abstractions like rudder or throttle. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport 3/4-letter codes data source
Gerhard Wesp wrote: anybody knows any good source for a list of all airports and their 3-letter code (like JFK, SFO, LHR, etc.) together with its coordinates and/or 4-letter ICAO code? $FG_ROOT/Airports/apt.dat.gz :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] NVIDIA 1.0-7667 breaks shadows entirely.
Gerard Robin wrote: Being Nvidia and X installed , i continu to search a good answer : After many experimentations, I did not notice any change between 24bpp and 32 bpp. There is no difference between 24 and 32 bpp on NVidia hardware. Both of them give you a 32 bit 8:8:8:8 RGBA front and backbuffer, a 32 bit Z depth and (now) an 8 bit stencil buffer, for a grand total of 104 real bits per pixel. You can inspect the list of OpenGL visuals available using the glxinfo command line tool if you like. The real choice underneath the (glut or SDL) abstraction layer is much more complicated than a single number. The reason that this suddenly breaks with the new drivers is that the new drivers have a new feature: they can now support 16 bit color buffers even when the desktop is at 32bpp. But these 16 bit modes do *not* support 8 bit stencil, which is required for the shadow implementation. So it used to by that when FlightGear asked for a 16bpp stencil framebuffer on a 32bpp desktop, it got a 32 bit mode anyway. But now, the driver can actually fulfill the request, so it provides a mode that won't work with shadows. FlightGear asks for a default color depth of 16bpp, but it also asks for stencil; this is essentially a bug. These are not compatible requests on any modern GPUs, which only support 8 bit stencil in true color modes. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SimGear RenderTexture changes causing compile problems
A J MacLeod wrote: I should perhaps mention here for those not keen on updating to the newer nvidia drivers yet that SimGear CVS (on 1st August 2005) _does_ compile here on nVidia 6629 and runs fine, so it's worth trying... You might not have the NVIDIA headers installed. Check /usr/include/GL/gl.h to see if it has an NVIDIA copyright at the top or an x.org one. I think some of the non-NVIDIA binary distributions of the driver include only the libraries and X server extension, and not the development stuff. For their own reasons, NVIDIA's drivers want to install special versions of the OpenGL headers that contain constants for NV_* extensions which aren't defined in headers from other vendors (Mesa/x.org, ATI, etc...). This would be fine, but sometimes the NVIDIA headers end up being a little behind on *standard* extensions that are required for some software to compile. FWIW, I think this is silly. The driver release is for users, who don't care about header versions. People who do care about header declarations and funny extensions are called developers, and are more than capable of going to nvidia.com and downloading headers themselves. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Preferences.xml question
Gerard Robin wrote: startup splash-textureAircraft/harrier/harrier-splash.rgb/splash-texture /startup You have a splash screen image for an aircraft with no 3D model? :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Craig Martin / email oddities
Craig, two quick issues with your mail: First, I notice that you are habitually starting new threads by replying to existing, unrelated messages. Don't. This causes problems for those of us who are using threaded mail client (I use Mozilla Thunderbird, for example). It's confusing to be reading through a thread and then come upon a block of unrelated messages in the middle. Standard etiquette requires that new threads should always be started with a brand new email message directed to flightgear-devel@flightgear.org (or wherever). Second, your mail client is generating odd content. The plaintext version is normal, but the HTML version (which Thunderbird displays in preference where it exists) is marking *your* text as a reply (that is p class=replbq ...). This may or may not be true for others, but my eyes want to skip over quoted text when reading email, on the assumption that I have already read it. It's just kinda weird, and makes your messages hard to read. I don't see anything in the headers to tell me what you're using; could you check your preferences for anything that might be causing this? Thanks, Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
Christian Mayer wrote: Shouldn't you then be able to get these documents easily by the freedom of information act? I dunno, I've never made a FOIA request. But from what I've been led to believe it's a very slow, bureaucratic process. And in this case it will be complicated because of the fact that the documents were (I assume) originally classified. They might very well *still* be officially classified if nothing has happened to change things. The ones that are available on the market are, I would guess, photocopies of versions that diffused out of the military over time and were never challenged. Basically, I honestly don't know, and don't have the patience to find out. That's why I'm generally grateful to folks like eflightmanuals.com for bothering to collect this stuff for posterity, even if it involves a ridiculous proprietary encryption scheme. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] OT: decryption
Josh Babcock wrote: These require a proprietary reader from Locklizard which does not have printing enabled. Hrm... then apparently he has changed mechanisms. The F-51D handbook I ordered a year or so ago is a plain encrypted PDF (with an extra step to get it off the CD that involves an emailed key). It printed just fine from acrobat reader; I have the hardcopy still to prove it. This is upsetting. It makes the manuals more or less useless to those of us who don't use windows as our desktop OS. Ah well. I retract the nice things I said about eflightmanuals.com. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayercrashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote: Andy is, of course, right. We should not send binary data over the wire and I think that using XDR for transmission Binary is fine. Uncooked memory is not. :) And FWIW, XDR seems awfully heavyweight to me. It involves a comparatively large amount of code for things that are really pretty easy, while at the same time making hand optimization of the packet format more difficult. Note that this hand tuning can be really beneficial, especially if the server is on a low bandwidth link. The multiplayer protocol I was thinking of (which these days is, I guess, mostly an idea box for the working version) managed to pack a full precision* position, velocity, acceleration, orientation and rotation rate into a block of 26 bytes. * Positions to within 1mm, orientations to within a degree over a typical inter-packet delay. That's about 3x smaller than a naive implementations based on floats and doubles, which means that you can transmit data on 3x as many aircraft/objects over the same link. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Free simulator of the Frecce Tricolori aerobatic jet
Erik Hofman wrote: You can always argue what would be derived work: just the modified files or the complete package. Personally I would say the first. Modifying a file is, pretty obviously, creating a derived work under any reasonable interpretation. :) There is no argument possible about the JSBSim configuration files and (as far as I know) the 3d model. In the case of the 3D model and textures, FlightGear has no relevant copyright to protect. Those are file formats that can be generated and read by other tools. The XML configuration files (the ones that were created from scratch, not copied from existing ones), however, are clearly based on FlightGear technology, and could theoretically be derived. A sane interpretation would treat these like documents though, and they would be owned by their author. I don't think any of us are making the argument that all FlightGear configuration files are derived works. Likewise, an Aeromatic-generated configuration file *can* be considered a derived work, because it contains code that was written originally by David Culp et. al. There is some precedent for this kind of thing (older versions of GNU bison generated parsers that were derived works and must be GPLed), but most tools don't bother with that notion and just treat the generated files as documents. Bison now contains a specific exception to the GPL for the generated parser code, for example. Basically, it seems to me like these guys are fine, with a few nit-picky exceptions like the joystick configuration. I don't think we need to raise a stink, except to get their derived stuff released as a separate tarball somewhere. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networking code(was:Multiplayer crashes with unknown aircrafts, any solution?)
Oliver Schroeder wrote: Apperantly gcc under cygwin uses a different alignment for structs than gcc under linux (I don't know which gcc version is used under cygwin). At home I use gcc 3.3.6, and it reports: Yet another reason why blasting raw structures out an I/O channel (especially a network socket!) is just always a bad idea. Really, to make this work without major insanity we have to cook the output. No doubt the cygwin compiler is defaulting to the MSVC standard alignment rules. Note that you can change these at compile time under both compilers by using command line switches and/or #pragma directives, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] sprintf
Christian Mayer wrote: You have to use the I/O manipulators (Stroustrup: 21.4.6.2, page 633ff.) like std::setprecision(). Compared to the fast printf syntax they are too annoying to write and not that flexible, but they are more readable and they can be combined to your own user defined I/O manipulators. So you can write easily very readable code without the need to retype everything. Just to add fuel to the fire, I will point out that this is a theoretical result. I've never once seen a complex iostream usage that I considered readable. Formatting text is a solved problem; programmers know what they want, and they want printf. C++ tried to get fancy, and failed. Much of the same can be said for the STL; 90% of developers are never going to care about pluggable algorithms, but 100% of them want a simple hash table. Guess which they got? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhauling the networkin code
Oliver Schroeder wrote: 2) A visibility range (Vivian called it Radar Echoing Area), provided by aircraft model data. That way a eg. 747 can show up on radar earlier than a cessna, making radar more real. 3) A radio transmission range, i.e. the range a client is able to reach via radio when sending (voice) messages 4) A radio receive range, i.e. the range a client is able to receive messages from. This may also be aircraft specific, not sure about that. 5) the frequency a client is listening to (erm, there are two listening frequencies, right?) 6) the sending frequency of a client While it sounds tempting, I'd strongly suggest *not* baking details of the radio model into the protocol. Eventually this is going to change in incompatible ways. I'd suggest simply allowing a set of MP configuration properties or whatnot, and leaving the implementation to more flexible code. Putting stuff like this into the protocol means that you're going to be making (incompatible!) changes very often as the implementation changes. As far as radio goes, I'd suggest using strings for the frequencies -- think of TACAN receivers, which have named channels, or an administration/chat channel, etc... Anyway, this protocol is very error prone since it neither cares for alignment nor for endianess. I don't know of it still works for x86_64, don't talk about the sgi's in Erik's zoo ... What about converting the data to network byte order before sending, and converting it back to host order when receiving? (using ntohl(3) and htonl(3) on the buffer). Yes, this is not optional. All I/O should be cooked for byte order. You can use the socket.h macros if you like, or do it yourself, but you should never, ever rely on the fact that writing a struct out of or into memory seems to work. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Properties, by position
Jon Berndt wrote: Can anyone differentiate for me the concept of position as contrasted to index in this situation? Position is arbitrary. I think it corresponds to the order of which the nodes were added to the parent. The only use I can think of for this method is enumerating over all properties, as in: for(int i=0; inode-nChildren(); i++) doWhatever(node-getChild(i)); Note that index is not always contiguous. It is perfectly legal to have a node with 4 children, which have indices 0, 7, 21 and 123, for instance. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: The position of any astronomical object relative to a viewer standing on the planet's surface is usually given as altitude and azimuth - with the true horizon and true North used as the references. [...] Additional entertainment will be provided by the fact that and code for FG needs to work with a WGS84 spheroid, meaning that the distance to the earth's centre will vary with lat and long I humbly submit that this is yet another area where an Euler (angle) representation is a bug, not a feature. We have a sane cartesian coordinate system for the earth. All that's needed is to define one for the solar system* and then do reasonably trivial conversion. The moon should be even easier, presuming that the moon's orbit passes through the equatorial plane (it does, doesn't it?). * It can be 2D, in fact -- on the plane of the Earth's orbit and with one of the axes aligned with the orbit's major axis. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: Solving where the planet is in its orbit for any given calendar time is tricky. This is just the equal area thing, right? (angular orbital velocity goes as the inverse of the distance to the focus) I kinda-sorta remember doing a parameterization of that in college way back when. It was based on an energy balace, I think... If nothing else, we can certainly solve it by brute-force integrating it for +/- a few hundred years and storing the table. The hard part is finding the calendar time given a phenomenum (like, say 'sunset'). I outlined that one in my previous post. Right, but the point was we don't give a hoot about sunset. That's a derived quantity specified in euler space (relative to an incorrect horizon, to boot). All we care about is direction. The sunset will take care of itself. (Well, no, because the renderer needs to draw pretty colors when the sun nears the horizon; but that, too, can be done in cartesian space and doesn't require a nothing of sunrise/set time). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
I wrote: that, too, can be done in cartesian space and doesn't require a nothing of sunrise/set time). Heh, s/nothing/notion/ Most of my typos are clear from context, but that one reads like gibberish, sorry. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
Paul Surgeon wrote: TeamSpeak doesn't have to be part of the FG package. It's a separate program that has an API you can interface to. Writing code that runs in the fgfs binary to interface to an API is generally considered to be making a derivative work, for fairly obvious reasons. People run FlightGear on MS operating systems which are not GPL either so I don't see what the issue is. ...whereas the simple act of running a program is not the creation of a derivative work. I know it's frustrating, but unfortunately the you can use this software for free culture isn't really compatible with the GNU notion of free software, or with the open source definition. This is a pretty fundamental thing, and it's not likely to be fixed any time soon. Most of us, I suspect, simply aren't interested in hooking someone else's proprietary stuff into FlightGear. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] feature request: MultiPlayer's Callsigns inViewport
Paul Surgeon wrote: What a pity as I don't know of any good replacements and writing VOIP software is not a trivial task. It's not so bad, really. And there certainly is open source voice communications software out there, albeit aimed more at enterprise applications than gamers. If the outcome of not being able to use TeamSpeak is a free game chat system, then we all win. So the only way it could work is if the creators of TeamSpeak released a GPL interface to their software? They could publish a well-specified protocol that we then implement to control a local client, I suppose. Protocol boundaries are a good indication of the end of a derivative work -- one doesn't usually worry about the licensing issues of using a GPL web browser to connect to a commercial web server. And it doesn't have to be GPL, just a GPL-compatible license. This generally means any loose non-copyleft license, a-la MIT or BSD. Other copyleft schemes (copyleft is the trick whereby you licence derivative works only if they are distributed under the same license) tend to interfere with each other. Basically, if they (TeamSpeak) want to make this work, they could do it pretty easily. They may be amenable to suggestions, if someone wants to talk to them. They are clearly linux-friendly if not completely free-software-friendly, at least. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Curt forwarded from Lukas Tinkl: we at SUSE recently stumbled upon this problem: some of the code contained in FlightGear contains a non-commercial lincese which forbids us from further distributing it. The consequence is that FlightGear wouldn't be part of the upcoming SUSE Linux release. SuSE is (or was, or would be) shipping FlightGear? I had no idea. We should probably fix this, I guess. Maybe the easiest way to do it would be to contact the author; is XEarth or descendents still an active project? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Erik Hofman wrote: Since you are already familiar with this stuff, I need the function to calculate the sun position (in degrees or radians) above the horizon at a certain time/lat/lon. What is this normally called: RightAscension, Declination, Magnitude or something else? None of the above. :) Right ascention and declination are the longitude and latitude of the celestial coordinate system. They specify directions to things that are outside our solar system. Things inside it will appear to move depending on their relative position with the earth. Magnitude refers to the brightness of a star. The sun position can be computed if you know the orbital parameters for the earth, but the details are tricky. The way it would work is to define some sol-centric coordinate system in which the earth moves, compute a line from the earthbound eyepoint to the sun, figure out what orientation the earth will be in at that moment, and then do an euler angle decomposition relative to the WGS-84 up vector and the earth's axis. Basically, it's not easy, which is why it's probably quickest to ask the author to change the license. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
And remember that a robust implementation can get big speedups by handling Mostyn Gale wrote: Andy Ross wrote: The best way to do this is actually dynamic: the server gets to send the X most important objects to each client per update. Importance can be defined in screen space -- think of it as the number of pixels of error that the receiving client would have if the update were not sent. Also a consideration is the detail of the updates. A plane 10km away can be have an accuracy of 1m but you would like a plane in formation to fly have about 1cm accuracy. That's why the accuracy is specified in screen space, not distance. Basically, divide by the distance from the observer and that is your priority. Sending velocity and acceleration data can also smooth make flight smother, but only for nearby aircraft. They're useful for everything, actually. Consider a jetliner in a steady turn. A single packet is enough for many seconds of extrapolation if it includes acceleration, but will rapidly become incorrect But how will the server calculate this? There will be 2^N-N relationships for the computer to work out which levels of reports to send to each client. For 20 players that is over a million calculations that the computer must perform every cycle. I'm not sure where you get the exponential there. There are N^2/2 distance calculations required to get all the inter-object distances. A naive implementation (this can actually be optimized pretty well) would then need to do another N priority calculations for each client, for a total of O(N^3), or around 8000 computations per cycle. Really, it's going to be done per packet received (which are O(N), of course), so it's really more like 400 per packet for 20 clients. Not so bad at all -- computers are really fast these days. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Shake your viewpoint baby!
Josh Babcock wrote: All you have to do is drop the file in $FG_ROOT/Nasal and set /sim/headshake/enabled='true' by the method of your choice. Then shake, shake, shake! Be sure to read the file for known bugs, and please, send me lots of comments. This is really cool. If you want to try another trick, how about a lag filter on orientation changes. My experience in lightplanes is that (for example) yaw oscillations feel like the plane is yawing around me and not that my viewpoint is shifting left and right. It might be cool if the head took a fraction of a second to catch up to the aircraft orientation. This might look cool, or it might cause nausea. But it would be fun to find out. Another thing that comes to mind is that at high accelerations, head orientation is coupled to acceleration -- bounce the plane hard and the head tilts forward, or to the side, etc... Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
