Re: [Flightgear-devel] YASim config question
I wrote: > It wouldn't be hard to get the solver to handle both situations. You > could have a fuel-fraction="..." attribute in the and > blocks, and a sub-tag > where you set the weights. Does that sound acceptable? OK, the fuel bit is done. You can now specify fuel="1.0" in the cruise tag to get a heavier aircraft. The weight stuff requires a little more work and might have to wait until tonight. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim config question
David Megginson wrote: > I'm not sure about using an index="" attribute, since it isn't fully > transparent. Perhaps you could allow a way to attach internal > identifiers to spot weights: > > > > As a matter of fact, an "id" or "name" attribute generally might > improve debugging. OK, this feature is checked in. But it *is* using an index currently, because I don't have a handy hash table available in the Airplane class. I'll get that fixed eventually. Most planes have no more than a handful of weight tags, so hopefully the index won't be too confusing. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] What is nasal?
[Bouncing to flightgear-devel, since this is so very much not a user question. :)] Richard Harke wrote: > For example, back trace shows naHash_set called from hashcolumn which > is not so. This may be related to architecture, I'm on ia64. > > Any case if I knew what nasal is supposed to do, it would be > easier to debug. Nasal is a scripting/extension language. You might be the first person compiling Nasal on a 64 bit architecture, so I'm not terribly shocked that you found a bug. Can you post the backtrace? This may require a little bit of work; you can also try downloading and compiling the Nasal standalone interpreter from http://www.plausible.org/nasal, which might be easier to debug with than a giant fgfs executable. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] truncf undeclared rearing its ugly head
Seamus Thomas Carroll wrote: > I have read the discussion about the truncf problem and with the > latest cvs checkout i still recieve the error. The messages subject > is: Re: [Flightgear-devel] Re: Fix for compilation error in panel.cxx: > `truncf' undeclared > > I did not notice any real solution other than some red hat people had > successful compiles and others didnt. It works for me on Fedora Core 1. Try adding a: #include At the top of panel.cxx and see if this fixes your problem; this is the header that the autoconf stuff uses to detect the truncf function. The panel.hxx header uses , which might not export exactly the same symbol set in all cases (maybe...). If that works, we can either replace the C++ header with the C one, or re-write the autoconf test to use instead. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] truncf undeclared rearing its ugly head
Seamus Thomas Carroll wrote: > I just added #include source/src/Cockpit/panel.cxx > recompiled and still the same error. Then something is bad wrong. Your configure script is detected the truncf function when it ran, but it isn't there for you at compile time. Both of those conditions can't be true; did you copy the build tree from another system? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Seg fault in nasal
Richard Harke wrote: > I have found the bug leading to a seg fault that I reported > previously (on the flightgear-users list). Though this is on > an ia64, the bug is not completely architecture dependant. > [...] > For several architectures, reftag does not overlay num and needs > to be explicitly set. Good catch. The reftag field will be separate from num on any architecture where a pointer is 64 bits. If this was the only 64 bitness bug, then I'm pretty happy. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: floorf in panel.cxx
Erik Hofman wrote: > Martin Spott wrote: > > Absolutely the same revision and date here. I don't have any idea if > > 'truncf' and 'floorf' belong together but I can state that the latter > > is definitely present: > > Does ffloor exists for Solaris? Why do we care? Just call floor(), which is in the ANSI C standard. The extra precision won't hurt anyone, and there is zero performance difference. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 2D EFIS Instrument
Jim Wilson wrote: > Don't they use glut fonts? Anyway, I'm thinking the font texture > would be with the model, and plib doesn't support that AFAIK. They use .txf fonts, which are another Mark Kilgard invention but not part of glut. They used to use glut bitmap fonts as well, but events of the past few weeks have finally seen plib cut ties with glut. :) And you can instantiate a fntTexFont object out of any file that you like. We'd probably want to have some caching in place so that models could share fonts, but it's certainly not a requirement. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Paraglider model
David Megginson wrote: > Jon Berndt wrote: > > If neither of the two (YASim and JSBSim) are appropriate for your > > expectations, you can code a special flight model in C within LaRCSim or > > perhaps set up a special model in UIUC-LaRCSim, although I am not very > > familiar with that. > > Right, but that's roughly equivalent to writing your own operating > system to support your spreadsheet. If there's something that you > cannot get from YASim or JSBSim, we'd prefer to improve them if we > can, since other people might need the same functionality in the > future. There shouldn't be anything really weird about a paraglider. The big differences from airplane behavior are due to funny mass distribution: the engine acts near the c.g., but the lift and drag are rather high above it. My guess this is the source of the original complaint. In a YASim model, you could try playing with ballast tags to move the default weight distribution around. This holds so long as the parachute stays inflated. Handling the non-rigid behavior of a flopping chute is going to be hard, but that's more of a failure mode than a flight simulation issue. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud movement
David Megginson wrote: > Arnt Karlsen wrote: > > ..ahem, _not_; wave lift sometimes cause static clouds over and > > downwind of mountain ridges, in some cases you can fly backwards > > thru these clouds. ;-) > > I'm trying to think this one through. It's a condensation effect. The air gets carried up over a mountain into lower pressures. The expansion causes it to cool down. If it starts out humid enough, it will eventually reach the dewpoint and the water will condense out and it will become a "cloud". Then it goes back down the ridge, compresses, heats up, and reabsorbs the water to become "clear air" again. To an outside observer, it looks like the cloud is staying in the same place over the ridge as the air moves "through" it. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Cloud movement
Arnt Karlsen wrote: > ..ahem, _not_; wave lift sometimes cause static clouds over > and downwind of mountain ridges, in some cases you can fly > backwards thru these clouds. ;-) This is true enough. But I don't think the cloud motion code is trying to model this particular behavior. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Automatically change a property
Lee Elliott wrote:
> What I'd like to do is to be able to switch the AP mode from
> Glide-slope hold to this new Touch-down mode automatically at a
> specified agl-ft.
>
> Any ideas how I can do this in xml?
Probably the best thing to do is write a little nasal code to poll the
property at maybe 5Hz or so (since AGL changes every frame, you
*don't* want to do it with a property-listener style interface,
polling is actually faster). Something like this:
checkagl = func {
agl = getprop("/andy/cannot/remember/the/agl/prop/name");
if(agl < THRESHOLD) {
setprop("/ditto/for/the/autopilot/mode", "touchdown-mode");
}
settimer(0.2, checkagl);
}
checkagl();
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] A load of YASim engine stuff
David Megginson wrote: > I've been spending a bit of time on the PA-28 model in YASim, and > one problem is that the engine idles far too fast sitting still on > the ground (around 1000 rpm, instead of 600-650 rpm). Is there any > simple parameter I can tune to slow it down a bit? Not really. The propeller torque near zero airspeed is just too low right now. I'm really happy with the way the existing propeller model works under normal cases; it works backwards from an efficiency curve to come up with a model that produces good physics for simple inputs without going wacky in some important regime. It's not good with edge cases, though. One option would be to port another engine/propeller model onto the existing yasim::Thruster interface. This might not follow the "solution from known performance" idiom, but for the case of a single aircraft can probably be tuned to work better. Short term, we could try to hack in a "idle speed" or "minimum torque coefficient" or somesuch too, although even that is probably going to be difficult. > What do we need to do to get YASim to publish convincing values for > these properties for piston engines? > /engines/engine[*]/oil-pressure-psi > /engines/engine[*]/oil-temperature-degf > /engines/engine[*]/fuel-pressure-psi I'm not quite sure what convincing values for these properties would be. The pressures are pump-driven and are, or should be, static under normal conditions, right? The oil temperature can probably be driven by a low-pass-filtered output power. Maybe a tiny bit of YASim-specific Nasal glue is what's required here. > Once YASim is running, it takes control of the > /consumables/fuel/tank[*]/level-gal_us property (as well as the > associated weight property) and will not accept changes. To > simulate refueling, either in the ground or on the air, it would be > nice to be able to change these values dynamically inside a > FlightGear session. This one is much easier to fix. I proposed a Nasal-driven fuel system a few months back, and still have half-finished YASim support for it sitting in my build tree. The basic idea is that YASim merely exports an ever-increasing "consumed fuel" number for each engine. The Nasal code then poll this at some sane frequency (maybe 3 Hz), inspects configuration, subtracts the fuel from the appropriate tanks, sets engine out-of-fuel flags, and finally resets the consumed fuel numbers to zero. YASim then just reads the fuel quantities for mass calculation only. The best part is that this can be done portably. The consumed fuel properties will be missing for non-YASim aircraft and the script can simply disable itself. And for the future, arbitrarily complicated fuel flow schemes can be implemented entirely in Nasal with no FDM support needed. I'll try to get this working tonight. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] quick gear question
Josh Babcock wrote: > What drives gear/gear/position-norm? I can't seem to find any place > in the code where this is getting interpolated. I'm actually trying > to figure out how to change the speed that the gear retracts. For YASim aircraft, this is a configuration issue. It is driven by a subtag of the gear object. You can control the interpolation time of the property with a subtag. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] isnan()
Jim Wilson wrote: > FWIW that doesn't sound like a "good programming practices" sort of > function. A quick test before executing division isn't very > expensive (no worse than an isnan). Actually, untrapped division by zero produces a positive or negative infinity, not a NaN. The idea of a NaN is that it is never produced as the result of an FPU operation involving non-NaN values. This is actually a useful feature -- Nasal uses this property to store a pointer in a union with a double without fear of confusing the two. But I agree -- checking for NaNs after the fact is a little like checking for a null pointer. If they're showing up at all, they are a the result of a bug. Using isnan() for non-debug situtations is probably just going to hide problems. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New joystick configuration.
Matthias Frohlich wrote: > I have done a new joystick definition for my hardware. This is the > thrustmaster top gun afterburner USB (what a name!) throttle/stick > combination. Wow, that's some significant Nasal hackery. Very cool. :) When inline scripts get that elaborate, it's probably a good idea to split them out into a "CyborgGold3DUSB.nas" file which would presumably be easier to maintain. You could, for example, store the current joystick mode as a module-scoped Nasal variable and not have to worry about getting it out of the property system. Some stuff, like the differential brake handling and afterburner range mapping, could even go into controls.nas for other sticks to use. The afterburner handling would obviously have to be configurable though. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More YASim engine stuff: chilly exhaust
David Megginson wrote: > (apologies to Andy for posting only about the problems -- the model > flies beautifully for the most part). Don't be silly. I can't fix that. > With the engine running at full blast, YASim sets > /engines/engine[0]/egt-degf to about 58 degF, or 14.5 degC, while > the outside air temperature is 14.3 degC. That's one cool exhaust. Heh, yeah, that sounds wrong. YASim comes up with an exhaust pressure via some thermodynamic prestidigitation that I remember being really (heh, really) proud of when I wrote it. I'm sure I must have convinced myself that it was working before I let my ego loose. Maybe something has broken since, or there's a conversion issue that never got fixed. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New joystick configuration.
Frederic BOUVIER wrote: > Would it be possible to handle in Nasal the OS differences in axis > layout ? In theory, but I'm not sure that's really the right thing. The scripts would have to check the platform* for every input event. Probably a better way to do this would be to "tag" the joystick description with the appropriate platforms and cull them out if they don't match. * Something that isn't actually visible in the property tree right now, I believe. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaying FlightGear on a Plasma Display
Jonathan Polley wrote: > Plasma TVs tend to be 1280x1024 at a 16:9 aspect ratio, rather than > the 4:3 (or 1:1) that it would normally expect. I am assuming that I > can just adjust the field of view, but will that only adjust the > horizontal field or will it adjust the vertical as well? They don't have square pixels? Are you sure? Ick. A better way than hacking at FlightGear is to cook up an XFree86 mode which uses the same aspect ratio as the monitor. Using a 1820x1024 mode will preserve vertical resolution at the expense of some horizontal downsampling. 1280x720 will have to upsample the veritical pixels a little. Presumably the display is multisync, so either of these should work. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question on Solaris 9 stops on xml part andbase
Murray wrote: > The base pak is still unusable as a tar file giving me problems when I use > the tar xvf command. > > I have verified the checkusm and all looks fine but I am still getting an > error. See below from the two examples. Can the owner/sysadmin do a tar xvf > on a SUN box for me. Have you tried GNU tar? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] heads up for 3D modelers - plib cvs issue
Erik Hofman wrote: > I think it really is time to make that a configuration option in the > animation configuration file. That would require s patch for plib, but > it allows the simple "random" scenery objects to go untouched and look > nice also (while preserving the simplicity of the model). Ah, now I understand today's plib traffic. I should have read this first, sorry. :) I agree, this could be very sanely implemented as a plib global. We could even control it per-object by reading/setting and resetting the value across a call to ssgLoadXXX(). I'm also not opposed to choosing something other than 46 as the built-in default. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
David Megginson wrote: > I'm struggling a bit with the best way to implement text for the new > (3D-capable) animation code in FlightGear. Plib's current approach > seems suboptimal -- it uses textured fonts (good), but instead of > adding the text directly to a scene graph, it requires a separate > drawing pass for it (bad). I wonder if the plib text is one of the > reasons that the old (2D-only) animation code could hurt the framerate > so badly. What interface would you like? The Plib fnt library is an immediate mode kind of thing. If you want it to live in the scene graph, you need only write a node object that sets up the matrices appropriately. A fancy implementation of static text might precompile it into a set of textured quads instead of doing it at render time from the input string; but for static text you might as well use a static texture anyway. I'd suggest an interface where you specify a location for the lower left corner of the text, a "plane" in which it exists, and a "point size" in real world units. This stuff can compile down to a single matrix push, and the node object just calls the immediate mode fnt stuff inside of draw(). Honestly, I think you might be fooling yourself on the 2D/3D performance issues. There's no secret sauce in ssg that makes it faster; my guess is that the existing 3D cockpits are faster than the 2D ones because they use fewer and smaller textures, and do less animation of the layers. If you were to port the 2D panels to 3D model files with a 1:1 mapping, you probably wouldn't see any difference. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFD: 3D Text Issues
Jim Wilson wrote:
> With the EFIS displays a lot of the text is what you might call
> "semi static". It doesn't change often, but it changes (autopilot
> settings and nav id's for example). I think the idea of generating
> the quads makes the most sense.
So how about an interface that looks vaguely like (apologies in
advance for getting Plib details wrong -- this is off the top of my
head):
class ssgTextNode : public ssgNode {
void setBaseline(sgVec3 start, sgVec3 end);
void setUp(sgVec3 up, bool correctToPerpendicular = true);
void setPointSize(float lineHeightInMeters);
void setText(char* text);
void setFont(FntFont* font);
void setFntRenderSettings(int AndyForgetsTheDetailsHere, ...);
void draw();
};
You would set the text baseline with a start point, and an "end" point
which lies along the line (not necessarily the end, I suppose). You
need to specify an "up" vector to get the plane and orientation
correct. This can be any point on the plane "above" the baseline. I
added the correctToPerpendicular option so that you can do affine
transformations on the text to simulate italics or whatnot.
The object would precompile its transformation matric and re-compile
only when the baseline/up points change. Likewise, the text string
would be precomputed as an array of quads (this might require some
surgery in the Fnt library to expose the right details) and changed
only when the text does.
Most of this would be pretty straightforward. The geometry code could
be lifted from the 2D-panel-in-3D hack I did (which does basically the
same thing), and the quad synthesis is already done inside the fnt
library; we just need to expose it in the right way.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal & Sockets...
Gene Buckle wrote: > Andy, is it possible to make socket calls within a Nasal script? If > not, how hard would it be to add that kind of ability? Right now, you can only talk to the rest of FlightGear through the properties tree. Adding the socket stuff probably wouldn't be hard at all; what do you need to do with it? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Specular reflections/high-lights
Erik Hofman wrote: > Lee Elliott wrote: > > I was wondering how well it might work if it could also be > > applied to water covered scenery. > > It won't, the surface is too flat and the polygons too > large. What you will see whenever it is applied is that when you > change the view direction all the water inside the view will > highlight with the same amount. What would work is to apply a reflection texture to the water. It's flat, so the texgen math is really quite simple. Other consumer simulators have done this; it looks really good at sunrise and sunset. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal question
David Culp wrote:
> The problem is that the script is executed while the aircraft's
> heading is still zero, prior to it being oriented with the runway. Is
> there a way to have the script execute only after the aircraft is
> aligned with the runway?
As an immediate hack, you can set it up to run after a timeout.
Something like this will work:
SRCPROP = "/orientation/heading-magnetic-deg";
DSTPROP = "/autopilot/settings/heading-bug-deg";
DELAY = 1;
settimer(func { setprop(SRCPROP, getprop(DSTPROP)) }, DELAY);
You will probably need to experiment to find a value of DELAY that
works on all systems. What is *really* needed here is a way to tell
when "initialization" is done, and hook in a callback for that. Right
now the various subsystems finish their work at different times, which
causes problems like this one.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] autoflight
David Culp wrote: > Would anyone be interested in an autoflight subsystem that acts as a > higher-level controller of the autopilot? If been thinking of > making one to avoid lots of nasal code [...] Is this exactly the kind of high level glue task that a scripting language is good for? Honestly, my thinking would be exactly the opposite: replace the C++ stuff with Nasal/properties where possible. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Terrain model holes
Oliver C. wrote: > Just a question: What kind of reasons were that? Simplicity. Stability. CPU usage. Rendering performance. Ease of development and maintenance. Robustness in the face of non-heightmap geometry features (roads, airport cutouts). Texture memory usage (LOD algorithms tend to require unique texturing). The list goes on and on. CLOD algorithms are nifty and elegant. But they ain't easy. They tend to work a lot better as isolated demos than they do as platforms for future development. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal bug in keyboard binding
Jim Wilson wrote:
> The "nasal" script doesn't work on the keyboard binding for the "c"
> key (99). I can't see any problem, and there apparently are not any
> useful debugging methods for nasal scripts
Have you tried print? It goes out via the standard SG_LOG channel as
an alert. It's true that there isn't a symbolic debugger for Nasal
yet. :)
> if (property) {
> }
>
> Does not work if the "property" type is undefined.
I'm a little confused. Is "property" completely unset (which should
cause a symbol lookup failure), or does if have a value of nil (which
should have a boolean value of false)?
One thing I noticed just recently is that the top-level C++ code for
timers (as opposed to input bindings) did not properly print the stack
trace on error. I have this fixed in my tree; I suppose I need to get
it checked in before Curt forks 0.9.4. :)
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: gl-info suffers from undefined references
Alex Perry wrote: > > [...] > > /usr/lib/gcc-lib/i486-linux/3.3.3/../../../libglut.so: > > undefined reference to `glXChannelRectSGIX' > > [...] > > Never mind. It looks like Debian Testing has managed to temporarily > have insufficient dependency constraints. It is currently possible to > have incompatible versions of glut and glX libraries installed. This is exactly the same problem that bit Red Hat about a year ago, got me into a viscious flame war with Mike Harris, and ultimately led them to pull glut from their distribution entirely. The issue is that glut (being ancient, crufty, unmaintaned, and slightly non-free) uses compile-time checking to look for OpenGL extensions. Around version 4.3, XFree86 implemented some SGIX extensions that glut uses. When compiled against XFree headers from 4.3+, glut generates a library with dependencies on those extension symbols. But ATI and NVidia ship libGL.so's that don't implement them. Debian's glut will work against debian's libraries, but not against 3rd party ones. The Mesa distribution has a version of glut that has been fixed to use runtime testing for this extension. The problem as I understand it, though, is that this distribution isn't quite compatible with glut's license terms. So no one wants to ship it. What I've done on my system is compile a static glut from Mesa which I put (by hand) into the FlightGear /lib directory when I build. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] nasal bug in keyboard binding
Andy Ross wrote:
> Jim Wilson wrote:
> > if (property) {
> > }
> >
> > Does not work if the "property" type is undefined.
>
> I'm a little confused. Is "property" completely unset (which should
> cause a symbol lookup failure), or does if have a value of nil (which
> should have a boolean value of false)?
Never mind, I understand. The getprop() function returns nil if the
SGPropertyNode type of the property is UNSPECIFIED. That's definitely
a bug. Fixed.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: gl-info suffers from undefined references
Curtis L. Olson wrote: > This might be another reason to look at plib's PW or SDL or at least > moving away from glut? Yeah, this has been on my list for a while. I actually got started a while back with snipping out the glut dependencies from the input and main loop code and putting them into a "fg_os.cxx" file. Our requirements are pretty simple. I'm just now coming out of a period of business at work, and can start picking up the FlightGear stuff I have sitting around. First on the list is the Nasal-based fuel system, which is almost there (the Nasal works, the YASim changes aren't debugged yet). The ssg "font object" would be another good candidate, as would the de-glutification stuff. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Trademark violations could be a problem
Oliver C. wrote: > We should also keep in mind that they could say "we allow it for > none commercial usage" but in that case we can't use it because > the GPL license does not forbid that flightgear can be sold for > example as part of a commercial Linux distribution. No, but such distribution wouldn't be done by us, then, would it? Folks, please stop the amateur lawyering. If someone wants to get a real attorney's opinion, that's fine. But this is just making us look dumb. Fair use is fair use. You can buy books full of photographs that don't have explicit licenses from every holder of every copyright in the image. What we are doing is no different. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] last-minute addition
Mathias Fröhlich wrote: > The current JSBSim cvs FGPropulsion.cpp file with the 'hangar' patch > just works as drop in replacement with the JSBSim version in > FlightGear. > > According to the prevous discussions the patch goes in the right > direction pand we can start a hangar. OK, I'll ask the dumb question: What exactly does "hangaring" mean as a FDM feature? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] New YASim fuel code
Now that the new release is out (yeah, that's my exuse...), I've finally checked in the new Nasal fuel code I've been working on, along with YASim changes to enable it. This hasn't been tested terribly well, so please let me know if I broke something. You should be able to set the /consumables/fuel/tank[n]/level-gal_us properties and watch the FDM do the right thing. As we come up with new fuel flow behavior (in flight refuelling, etc...) we can hook the Nasal script to do what we want. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
Vivian Meazza wrote: > How do we handle fuel in lbs and account for Avgas/JP4? For read access, you will find a level-lbs property also. But the only one you are allowed to change is the gallons one. There is a density-ppg property there too, for doing conversions. It gets set from the FDM with a density appropriate to the fuel in the tank. Here's the complete "documentation" as it appears at the top of fuel.nas: # Properties under /consumables/fuel/tank[n]: # + level-gal_us- Current fuel load. Can be set by user code. # + level-lbs - OUTPUT ONLY property, do not try to set # + selected- boolean indicating tank selection. # + density-ppg - Fuel density, in lbs/gallon. # + capacity-gal_us - Tank capacity # # Properties under /engines/engine[n]: # + fuel-consumed-lbs - Output from the FDM, zeroed by this script # + out-of-fuel - boolean, set by this code. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] YASim starter motor
David Megginson wrote: > When you engage a starter on a piston engine (I have no turbine > experience), it spins the propeller at an extremely slow, constant > speed -- maybe 30 rpm -- until the engine fires; at that point, the > engine spins the propeller up to speed (say, 1000 rpm with the > throttle slightly open) almost instantly. Yeah, although that's not too terribly different than what happens now. The issues are all with tuning and threshold changes. The problems with the current approach that I can see: + The "start" threshold is probably too high (it's currently set to 200 RPM, which doesn't match your value of 30 very well.) + The torque behavior of the engine and propeller at low speeds is kinda broken. The propeller isn't draggy enough, so you had to tune up the engine friction to get the idle speed right, which led to complaints on IRC that the Mustang wouldn't start, which led me to hack in the starter motor changes for a near-term fix. Turning down the start RPM would probably be the fix required here. I'll check that in instead (I think I might use 60 instead of 30, which really does seem awfully slow) and see if folks like it. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: releases FlightGear-0.9.4.tar.gz, NONE,
David Megginson wrote: > I agree with Curt. There are two basic strategies for releasing: > 2. Release often, testing every release only lightly. > I think that #2 works better for most cases What he said. One way of looking at it is this: The goal isn't to produce individual releases with the greatest quality, it's to produce the best software we can with the resources available. Waiting on releases for testing means that developers have to put off contributions, bug reports on those contributions then come in later than they would otherwise, the bug fixes go in later and the next release gets pushed back. We end up doing less development and making fewer releases, which is *bad* for software quality in the long run. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
I'm picking up work on the de-glutification stuff right now, and have
a question:
Does anyone understand what is going on in src/Input/mouse.cxx with
the {X|WIN32}_CURSOR_TWEAKS preprocessor defines? I'm having a hard
time figuring this out. Right now, it looks like the windows and X11
builds actually have different/incompatible behavior for the mouse
cursor.
Nothing in the underlying (portable) glut API should require this, so
far as I can see, nor should there be a need for platform dependency
in this code. Does anyone know the history here?
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] mouse.cxx: CURSOR_TWEAKS??
Norman Vine wrote: > Andy Ross writes: > > Does anyone understand what is going on in src/Input/mouse.cxx > > AFAIK mouse.cxx is not in the current CVS I typoed the path. It's in src/GUI Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
Vivian Meazza wrote: > In the YASim file we quote tank capacities as lbs (and that is normal AFAIK > in UK) and can specify Avgas or JetA. > [...] > I can fix up the density for Avtur, when I've worked up the ppg equivalent > (phew!!), for my own use if that's required. Or have I got this all > wrong? You don't need to do anything short term. YASim will fill out the tank record for you at initialization (it has hard-coded values for gasoline and jet fuel). But ultimately, this stuff should move out of the FDM proper and into the aircraft configuration, since it needs to interact with the rest of the system through the property tree. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-Releases and Releases
Martin Spott wrote: > Another example (among others) is the altimeter-dialogue that was > recently introduced by DaveM. [...] I have to familiarize myself with > that feature. How should this be done with such a short pre-release > cycle ? I don't follow. Are you trying to say that the feature should never have gone out in the release, or that there is no use in providing feedback and/or improving features once they have been released? I can only disagree on both counts. If you don't like the alitimeter dialog, then write up your suggestions and it will be fixed. What does that have to do with release procedures? Especially in this case, I can't see Curt holding this release back due to a minor i18n issue with the altimeter dialog even if you had been given a month to air your grievances. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FAQ or archive for Windows compile
Jacob George wrote: > Is there an FAQ or doc on how to compile FG and components such as > SimGear in MSVC under Windows (XP)? I am having trouble with > finding a .dsp or .dsw for SimGear. Both of these files are in CVS, the logs indicate that Curt checked in new copies for the recent release, so they should certainly be there. Are you using a stale version? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire & Hurricane manuals
Vivian Meazza wrote: > How do we set the reduction gearing ratio? Set the "gear-ratio" attribute of the propeller tag. This is the reduction ratio, so typical values will be less than 1.0. > Can we do a constant speed propeller? The min-rpm and max-rpm attributes define the range of the blue lever. These are the speeds to which the propeller will seek; it may not be able to achieve them in practice. The documentation for these was, er, wrong. I'll fix that. > And can we set the handedness of the propeller to RH? Sure thing. Use a negative moment value. :) No joke: that will have exactly the effect of a counter-rotating engine. The DC-3 uses this trick for the starboard engine, for example. I'll add some documentation for that as well. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] De-glutification, stage one
OK, I've just commited the hard part of deglutification. All glut dependencies in the source tree are now isolated in "Main/fg_os.cxx". This file (header attached) defines a really tiny wrapper API around the subset of glut we actually use. Think of it as yet another OS abstraction API, but one that we can control and mutate as our needs change. Note that the current version is still using glut, so nothing should have changed in FlightGear's behavior. If it did, then I broke something. The changeset is big. Feel free to revert it if it doesn't work out of the box. The next step is to decide what toolkit(s) to support for future versions and write a fg_os implementation for them. Now, I suppose, is the time to have the flame war about toolkit choices. To seed the debate: SDL: Big and complicated. This is the current "gold standard" for portable game APIs, and tends to support new paltform features very quickly and completely. It has a lower-level "event loop" API which might be a little more flexible. It also includes a lot of auxilliary libraries (input devices, sound mixing) that we might want to make use of in lieu of the plib equivalents. It's standard on all (?) linux distributions, and can be shipped as a single DLL for Win32 binary distribution. I'm not sure how easy it is to get for Cygwin or Mac users. PW: Plib's new integrated toolkit. This is sort of a "glut light" (OpenGL window creation; no menus, no fonts, no joysticks, no spaceballs, no tablets, no game mode), and looks quite clean to me. It has the distinct advantage of adding no new dependencies, because it is shipped with Plib. It is also brand new, and probably still a little rough around the edges. Roll our own: Probably no one will be interested in this option, but I thought I'd throw it out there just in case. FlightGear is a big enough project now that maintaining our own OS integration layer wouldn't be a terribly large part of the development effort. This would get us maximum flexibility for nifty hacks. Think about platform-specific features like automatically popping the window to the foreground when the autopilot reaches the destination, "headless" operation, FlightGear on the desktop background, panel applet integration... While we could steal code from other sources to get started, this would obviously be lots more work. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Spitfire & Hurricane manuals
Vivian Meazza wrote: > Thanks for all that: all looks good - the documentation has got a > bit astern of station. Could you explain a bit more about the > "turbo" attribute when used for a supercharger? Actually, the existing turbo-mul implementation is *more* like a supercharger than a real turbo. YASim models the boost as a simply multiplication factor on the input manifold pressure. If it's set to 2.0, then the engine sees twice the static pressure, etc... Real turbochargers don't have linear boost-vs-RPM curves, and tend to lag (in time) engine power by a little bit. A gear-driven supercharger is going to be closer to that ideal. > MOI = # of Blades * (8.2*(10^-5))*(D^5), slug-ft^2 > then converted to kg-m^2 and finally square root to kg-m for torque > value Is "D" diameter? That looks like the right relationship (linear dimension to the fifth power) for a moment as a function of size, but I'd be *really* suspicious of using that equation for anything else. The .82 constant is pure fabrication, and will change depending on the shape and density (wood? aluminum? composite?) of any given propeller. A Lockheed Constellation and a Piper Cub sure as hell aren't going to have the same constant. :) Here's (IMHO) a better framework: Think of a propeller blade as a stick, with a constant density along its length. That's not quite right, but for most propellers the "non-stickness" is concentrated in the thick middle, which makes very little contribution to the moment of inertia. So the MOI is the integral along the blade length (from zero to "R" -- the propeller radius) of rho*r*dr, where rho (the density) is just propeller-[M]ass / ([N]umber-of-blades * R). So we do the integral for each blade and multiply by N: R M N * INTEGRAL --- * r * dr 0 N * R M, N and R come out as constants (and the N drops out entirely), so we have just a trivial: MR --- * INTEGRAL r * dr R0 Which of course is just (M/R) * (R^2/2) == M*R/2 So multiply your propeller mass (which you might have to guess at) by its radius and divide by two. Much simpler, and no magic constants needed. And you can do it in native units, without looking up what a slug is. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Martin Spott wrote: > An outsider's view: Wouldn't it make sense to roll all these nifty > hacks into PLIB so everyone can make use of them or is PLIB too > restricted to make this a realistic vision ? This is more of a design theory issue, but in general "nifty hacks" like this are *not* something that belong in utility libraries. The whole point of having Plib/PW (or SDL, or anything else) is that they isolate the user from the complexity of the underlying platforms. That simplicity gets broken when you have to worry about all the brain damage that other people have introduced to the library over its lifespan. To some extent, SDL has this disease (it wants to #define main(), for goodness sake!); the library is much larger and less orthogonal than it could be. In isolation, a single project can make the decision as to whether an odd or non-portable hack is worthwhile or not. But we don't want to be subjected to everyone else's tricks, and quite frankly other plib users aren't likely to be interested in our tweaks either. Gene Buckle wrote: > From what I've hread about this kind of think in the past, patches > submitted to PLib from FlightGear have been totally ignored. Well, they went through a quiet period for a while. But things have improved markedly over the past few months. The real problem wasn't really that they were ignoring patches, it was that "significant" changes (the vertex splitting stuff that I did, for example) required code review and integration work from the core team, and no one had time to do that. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] Application recommendations solicited
Jon S. Berndt wrote:
> Is ayone aware of a program that does on-the-fly image conversion that
> will run under Cygwin from the command line? Specifically, what I am
> looking for is a program that will take a specified-resolution image
> from a Kodak photo-CD format file (.pcd) and convert it to a .png
> file. That's the most basic requirement. I might want to do other
> stuff, as well such as resizing, etc.
You want the ImageMagick package. It comes with an amusingly named
"convert" program:
convert MyPhoto.pcd MyPhoto.png
More elaborate transformations, including rotation, resize and
cropping, can be done by the even more amusingly named "mogrify".
> Does anyone know of a program/utility thingie that can be assigned
> to listen to a port and simply spit out whatever comes across?
> JSBSim has a socket capability and I wanted to play with that some
> more (after a long hiatus). A command line application would be
> fine. Anything would be fine. I just want to see what's coming over
> the wire.
This is best handled by the "nc" program ("net cat"), which I'm sure
must be available in cygwin. Doing "nc -l -p 12345" will listen on
TCP port 12345 and print everything it hears to the console. There
are zillions of options to this program, it's a handy tool.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Frederic Bouvier wrote: > MOUSE_CURSOR_INHERIT and MOUSE_CURSOR_LEFT_RIGHT are not defined and > not handled. Indeed, those two aren't defined (it's *_POINTER and *_LEFTRIGHT in my code). Can you be more specific about the error you are seeing? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Norman Vine wrote: > I see that you removed gamemode support :-( > > This means that Windows users only have 'slow' windowed > mode available now. :-( Is game mode support actually configurable? I looked around, and couldn't find a way to enable this stuff short of hacking at the source code. I just assumed it was dead code. Remember, the point here is that glut (and thus game mode) is going away RSN in favor of a hopefully saner and more portable API. We can add it back if you can show me how to use it. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-setting fuel levels at start-up
Lee Elliott wrote: > De-selecting the external tanks on the model, depending on the > --aircraft param, is straight forward and I can zero the levels once > FG has started but setting the tank levels to zero in the 'set' file > doesn't seem to work. I guess this might be because the fdm is > initialised after the stuff in the 'set' file has been read and > actioned, overriding the zeroing of the levels. No, that sounds like it's just a bug. :) What should be happening is that YASim should be checking for the fuel properties at initialization and setting them (via the legacy fuel-fraction property) only if they are missing. I'll take a look. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Pre-setting fuel levels at start-up
Lee Elliott wrote: > Oops! - just noticed that the tanks have to be zeroed _before_ > they're de-selected (selected=false) otherwise the weight isn't > deducted from the total. The empty tanks have to be de-selected > before the engines will run. Right. Trying to draw fuel from an empty tank, even if other selected tanks are not empty, will set the out-of-fuel flag. What do multiple-tank fuel systems (a Cessna, for example) do when one tank runs dry? In fancy systems, trying to pump fuel out of an empty tank is a serious error. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Frederic Bouvier wrote: > Frederic Bouvier wrote: > > MOUSE_CURSOR_INHERIT and MOUSE_CURSOR_LEFT_RIGHT are not defined and > > not handled. > > This patch worksforme. Ah, good catch. In CVS. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Curtis L. Olson wrote: > What "game mode" does in X11 is open up FlightGear full screen with > no window system decorations. This is critical if you are using FG > as an image generator, especially if you are doing multiple > projectors like this: Are you sure you're not using "full screen" mode, which does pretty much the same thing? Regardless, I think this is back. It was wrapped inside a stale ifdef (GLUT_WRONG_VERSION) which no longer exists. But I misread the sense of the test (#ifndef, not #ifdef) and assumed it was dead. There was also some WIN32 code in there to pick up current desktop settings, which I didn't include because it was commented out and I can't test it anyway. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New YASim fuel code
Frederic Bouvier wrote: > -float Airplane::setFuel(int tank, float fuel) > +void Airplane::setFuel(int tank, float fuel) Are you using an older version? The code in CVS looks fine to me. Yes, the set method returns the current value; that's intentional (although for all I know it is no longer used). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Frederic Bouvier wrote: > The current game mode ( I mean the code Andy resurrect ) is totally > useless for me : less than a frame every 3 seconds Is this different from the old game mode? Can you tell why? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] De-glutification, stage one
Norman Vine wrote:
> untested but I think this will work as an alternative to game-mode
> for WIN32
>
> note this assumes that the Window and OpenGL have all been properly
> initialized ahead of time
FWIW everyone, this is exactly the kind of "nifty hack" I was talking
about regarding rolling our own integration framework. Making stuff
like this play nicely without breaking when SDL/{free}glut/pw releases
a new version is difficult. Simply hacking it into fg_os_win32.cxx is
much less involved; Norman could submit patches without worrying about
the appropriate #ifdef's, and the only coordination would be at the
top level (the function prototype of fgToggleFullscreen(), in this
case).
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
Rick Ansell wrote: > I don't think Yasims solver is set up to account for this sort of > strange behaviour. It's not, but then again it's also not set up to model some much more important power effects, like prop wash on the control surfaces. You hear about this magical radiator design an awful lot; I kinda have to wonder if it's mostly a myth. Are there any numbers on this thing? Jim Wilson wrote earlier: > it seems like I'll get the thing nicely trimmed for landing so that > you have to apply a little power to keep it on approach and above > stall speed. It feels right. Then once I get above the runway > (still above ground effect height), it just glides much too well > with all power shut down to idle. Are you sure you're above ground effect height? The Mustang has a big wingspan, and sits relatively low on its gear. It will definitely have a much higher ground effect threshold than the other piston engine planes will. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: De-glutification, stage one
Alex Romosan wrote: > something broke. if i do a ctrl-v to come back to the cockpit view > the mouse gets reset to pointer mode even though i had it in fly > control mode Fixed, thanks. The problem was with modifier key handling: it could get "stuck" during mouse motion callbacks due to a limitation in glut. The original code worked around the issue, but I re-exposed it when I wrote the new API in fg_os. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGFS 0.9.4 - Aircraft Data - P51d
Rick Ansell wrote: > I think that the article was referring to net thrust from the > propellor-powerplant combination. 2000lb of engine ;power' doesn't > necessarily make for 2000lb of thrust from the prop. Actually, 2000 pounds of thrust doesn't sound that far off. To start with an intuitive argument: 2000 lbs is about half of what a light bizjet of the same weight as the Mustang gets, so we're not too far from the right ballpark. More numerically: The engine is listed as 1590 horsepower. Figure that it can develop that power at sea level while going at 360 knots (~180m/s). One HP is 745 watts, and figure about 80% efficiency (peak for most propellers is 85%) so we have: 1590 * 745 * 0.8 / 180 = 5264 Newtons == 1180 pounds of force. That's at max speed. If you develop the same power and get the same prop efficiency at 200 knots (which is still well within a "normal" environment), then you'll see 2000 pounds from the prop. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jim Wilson wrote: > One thing I noticed is the altitude-agl is reported at the gear > level by YASim, where JSBSim reports the distance of the nose above > the ground. I'm not sure one is better than the other, but perhaps > this should be standardized. I interpreted the "agl" level as a cooked altitude, as reported by a cockpit annunciator, for example. The absolute altitude of the coordinate origin is (in principle, anyway, even if it's not available in the property tree) easily computable from the origin coordinates themselves. We should definitely standardize it; if the "gear altitude" needs to move to a different property, that's fine. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jim Wilson wrote: > My understanding is the agl should simply be the "fdm's altitude-ft" > less the "ground elevation-ft directly under the aircraft". I'm not > sure by your response if you are aware that the "agl" in > altitude-agl is "above ground level". Of course. But the agl definition you posit is computable easily as a simple subtraction. It is not acceptable for some applications (cockpit altitude annunciators or a radar altimeter) which need to have a "zero" point calibrated to the actual position of the touchdown gear. I'm happy to dumb down the existing AGL property, but we should pick a new name for the "gear altitude" property, which is IMHO a much more interesting value. We should also pick a coordinate origin to report it relative to. If JSBSim is using the (moving) c.g., then we're both bugged. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
Tony Peden wrote: > I'm running RH9 and have found the need to add > #include FG_GLUT_H > > to > src/ATC/ATCdisplay.cxx > src/Cockpit/cockpit.cxx > src/Cockpit/panel.cxx It sounds like you're missing something from the recent glut changes. The glut.h header should not be included from *anywhere* in the general source code anymore. Can you be sure to do a complete cvs update and post the errors you get? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Jim Wilson wrote: > What JSBSim does that YASim does not is if the aircraft is a little > too close to the ground at initialization JSBSim hurls the thing up in > the air. Why is it that only JSBSim reacts by flipping over the > Cessna? YASim does something similar though: it doesn't have a trimming routine per se. Instead, if it detect the aircraft "near" the ground, it sets the altitude such that the lowest (extended) gear is at exactly ground level and "drops" it. No fancy trimming code needed. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Mathias Fröhlich wrote: > To me there arises the question which gear do you take for this? The > nose gear for example will have a different agl then any other gear > depending on the orientation of the aircraft. The lowest one. That's obviously smarter than a real sensor would be, but that's fine since this feature won't be useful in strange orientations anyway. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Raised Runways
Curtis L. Olson wrote: > Innis Cunningham wrote: > > Just wondering if the problem of raised or sunken runways in all > > parts of the world other than the US can be fixed or will it not be > > possible till the rest of the worlds data matches the US data. > > Could you send me an example or two or three of airports that are > especially glaringly wrong? I hope to dig into this problem in the > upcoming week to see if I can get to the bottom of it. I've never looked carefully at the terrain generation code, but it strikes me like it should be relatively straightforward to come up with a "smoking gun" case where a published runway elevation clearly doesn't match the corresponding terrain data. In such a case, we're basically SOL. We have to trust one or the other. Even in the best case, we'd have to use a smoothing algorithm or somesuch, which is (by definition) going to visibily change the local terrain details. My hope, I guess, would be that the data difference would lead to an "Oh, duh!" moment where we realized that they were in different projection datums, or run through a transformation with a broken constant (remember the old WGS84 stuff had a few bugs) or something like that. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD? De-glut victim?
Curtis L. Olson wrote: > Ever since we took a step towards de-glut-ification, I have been > unable to toggle the hud on off. This is a very useful tool for > debugging even for planes that don't technically have a HUD as a stock > option. Any chance we could get this funtionality returned? Oops again. There were some hard-coded key handlers with a comment that I took to mean "these are obsolete". Apparently they weren't. :) The Right Thing would have been to turn them into commands that can be mapped via keyboard.xml, but I was too lazy. One of the bindings (F6) was easily duplicated with Nasal, but the HUD stuff is now hardcoded again. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] HUD? De-glut victim?
I wrote: > The Right Thing would have been to turn them into commands that can > be mapped via keyboard.xml, but I was too lazy. One of the bindings > (F6) was easily duplicated with Nasal, but the HUD stuff is now > hardcoded again. :) No, sorry. That was too ugly; I just couldn't do it. :) I added new commands for these things and checked modified keybindings into keyboard.xml. This still isn't quite the "Right Thing", which would involve modifications to the HUD code so it could be driven by properties. But at least now all the keybindings are in one, configurable place. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SDL "early access" implementation
For those interested, I just checked an SDL implementation of
fg_os.cxx ("fg_os_sdl.cxx") into the source tree. It isn't quite
ready for prime time yet, but does seem to work if anyone is
interested in testing it.
It obviously isn't integrated into the build process, though. The
easiest way to get it building it to modify your Makefile.am,
replacing fg_os.cxx with fg_os_sdl.cxx and adding -lSDL to the
fgfs_LDADD libraries. It's OK to leave the glut library in
opengl_LIBS, it won't hurt anything. On my Linux distribution, I also
had to add an "-lpthread" to resolve symbols for the SDL threading
API. YMMV.
Finally, you need to change the PU_USE_GLUT line at the top of
fg_os.hxx to PU_USE_SDL, so the PUI library knows which
initialization routine to call.
The one thing that is missing is support for changing the mouse cursor
image. Unlike glut (or X11, Win32, or anything else) SDL doesn't give
you a preset list of cursors and requires you to define your own
cursor images via bitmaps. I looked around, but couldn't find any
easily-importable ones. It wouldn't be much harder to ignore the
hardware mouse cursor entirely and draw our own in OpenGL (with color,
alpha, whatever). This is what most commercial games do, FWIW, and it
looks a lot better.
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
Tony Peden wrote: > ATCdisplay.cxx:75: `gluOrtho2D' undeclared This is a GLU function, not a glut one, so the appropriate header to include should be . Including glut.h works presumably because it pulls in GL.h and GLU.h on its own. I'm honestly not sure why you're seeing compilation errors, though. What are the other files you're having trouble with? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG_GLUT_H
I wrote: > Tony Peden wrote: > > ATCdisplay.cxx:75: `gluOrtho2D' undeclared > > I'm honestly not sure why you're seeing compilation errors, > though. Never mind, you were absolutely right. Something upstream from these files used to include glu.h, and no longer does. I don't know why my build didn't pick up the dependencies correctly. Fixed. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
I wrote: > The one thing that is missing is support for changing the mouse > cursor image. Melchior pointed me at a font editor (http://fontforge.sf.net) that can read .pcf files, so I've thrown together a set of bitmaps based on the X11 cursor font and checked them in. This basically makes the SDL port complete, even if the cursors aren't as pretty as I was initially intending (they aren't any uglier than they are now, though). I'd appreciate it if folks, especially those on non-linux platforms, would give it a whirl and see what they think. Is SDL something we want to commit to? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
Norman Vine wrote: > since we are now agnostic as pertains to the lowlevel OpenGL > initialization routines I don't see why the choice of OpenGL toolkit > used couldn't just be an option Uh, that's the whole point. What would you prefer, if not SDL? If you want to write a windows-only implementation, feel free. The problems with glut are well-documented. It is no longer developed, doesn't track changes in the underlying systems (mode switching has never worked under XFree86, for example), is not free software, is being dropped by most linux distributions, and is filled with cruft that we don't use. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman wrote: > JSBSim does basically the same (although there is a name allocated > for it), but the real question is: Is left most defined 0, or is > right mos define d0, or is it something completely different > (numbered in order of appearance)? Maybe I'm confused: why do we care? The "0" gear is the first one listed. If it happens to be the nose gear, then the 3D modeller will use .../gear[0]/... to animate it, etc... The only time we need to worry is when synchronizing the number across FDMs, and even then it's just a convention: make sure than gear N in the YASim configuration matches the corresponding gear in JSBSim. Notions like left, right, nose, main, etc... don't seem relevant to me. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] More on JSBSim ground trimming issue
Erik Hofman wrote: > This way it is easy to change the YASim or the JSBSim or the > animation configuration file to match each other. Fixed (non > compatible numbers) don't allow for that. I'm not arguing against having names for the gear, which actually sounds kind of elegant. But it should be pointed out that the numbers aren't fixed: YASim numbers the gear in the order they appear in the configuration file. There's no reason you couldn't move them around to match a JSBSim configuration. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
Norman wrote: > Out of curiosity what can't you do today that would make FlightGear > better because we are using GLUT that you would do differently today > if we were using SDL and what exactly is it that would make FGFS > better. Off the top of my head: + Build out of the box on Fedora, which no longer ships glut. Other linux distributions are likely to drop it in the future as well, I suspect. It has portability issues when built against current versions of the X libraries and has a license which disallows redistribution of modified versions. + Switch video modes on an XFree86/Xorg server, which has supported this capability for 4+ years but have never had a complete "game mode" glut port written. + Be able to handle stuff like "Shift-3" instead of "#", so the Europeans don't think our key mappings are on drugs. + Future features we might like to investigate: SDL has a portable threading API, so we could enable threads by default. SDL has an audio library which is more featureful and portable than SL (it speaks to APIs like ALSA, arts, ESD, and DirectSound; SL doesn't even work on my laptop) Seriously, glut has not been maintained for almost 6 (!) years. Almost no one else uses it. It was a nice demo library in its time, but it has long since faded. Everybody doing portable open source OpenGL development is using SDL. I don't like everything about the library, but I can feel where the wind is blowing. And I'm serious: if you want to write a Win32 implementation of the stuff in fg_os.hxx, feel free. The whole point of having an abstraction API under our own control is that it allows us to do things our way. I'm not wedded to SDL, by any means. Honestly, I thought you of all people would enjoy this change. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
Curtis L. Olson wrote: > I understand that there are (or at least were) issues between SDL > and cygwin, but perhaps it would be more productive to address that > problem directly ... Ah. I honestly didn't know this. I just assumed that cygwin was one of their native platforms. I just checked, and it's true that cygwin doesn't ship an SDL library as part of the distribution. I did find the following README on the SDL website which seems to imply that the process is pretty straightforward: http://www.libsdl.org/extras/win32/cygwin/README.txt It basically sounds like "configure && make && make install" is all that is needed, with a few caveats about making sure to install "extras" packages containing OpenGL and DirectX headers. But remember: I think a native Win32 implementation would be pretty cool, too. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
Curtis L. Olson wrote: > Probably the best short term solution is to make sure we can build > with both SDL and glut and let the builder decide? Sure. This should work right now. The only bits missing are the autotools magic to do the detection and set up the makefiles appropriately. I fear autoconf, I really do... Does someone with a more solid handle on these things want to help out? :) > If we can get SDL working well for all but cygwin people, it might > make sense to make SDL be the default rather than glut, or default > to SDL if it is detected and fall back to glut if there is no SDL? Another option might be for someone to fight through the SDL installation just once and provide a binary package for cygwin folks to install. Dumb question for windows folks: would it not work to simply use the mingw library? My understanding is that windows SDL is built entirely on the Win32 API, and won't conflict with cygwin.dll or the C library. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SDL "early access" implementation
Norman Vine wrote: > FWIW I would be much more excited about this if we were switching to > a library designed for highend simulations such as OpenProducer > which by the way also has a portable threading library OpenThreads The argument is still open. Sell us on OpenProducer. I've never heard of it, but would be willing to investigate. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: Raised runways
Curtis L. Olson wrote: Today (I *think*) [...] Yeah. Daylight savings time always confuses me too. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Melchior FRANZ wrote: > Isn't. Key combinations with Alt and Meta are neither > processed (Alt-Tab) nor forwarded to the DE (Meta-F1). They are > simply dismissed, which is bad, because they are used for > interaction with the the desktop (Meta-F1 is supposed to switch > to Desktop 1 here). To my knowlege, there is no API for "forwarding" to the desktop environment. The window manager is expected to grap those events on its own. This is an interaction issue, I suspect. Do the SDL test programs have the same behavior? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Melchior FRANZ wrote: > Oh, and the geometry isn't restored after exit. fgfs/SDL switches to > 800x600 when called without --geometry, and leaves it at that. One > has to call it again with the geometry that one wants to have > afterwards. Known issue. Lots of places in our source tree like to call exit(), which is bad in an environment where you need to reset the video mode. They all have to be hooked to call fgExit(), such that SDL_Quit() gets called before the end. That's trivially easy, but a lot of work. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
I wrote: > Melchior FRANZ wrote: > > Isn't. Key combinations with Alt and Meta are neither > > processed (Alt-Tab) nor forwarded to the DE (Meta-F1). They are > > simply dismissed, which is bad, because they are used for > > interaction with the the desktop (Meta-F1 is supposed to switch > > to Desktop 1 here). > > To my knowlege, there is no API for "forwarding" to the desktop > environment. The window manager is expected to grap those events on > its own. This is an interaction issue, I suspect. Do the SDL test > programs have the same behavior? OK, here's the deal: When in fullscreen mode, SDL runs with an X11 grab on the keyboard input, so the window manager never gets a chance to intervene. It does normal input processing in windowed mode, though. Unfortunately what you want (the ability to Alt-Tab from a full screen window in a custom video mode and get back to a desktop at normal resolution) is going to be really hard. Doing it right requires window manager involvement, since it is the only client that knows what the real desktop resolution is "supposed" to be. I suppose we could mimick the behavior by writing our own code to handle the unmap and focus events generated when the WM shift desktops or applications. But looking at the SDL source, I don't think it's ever going to do this. You can have resolution switching or desktop integration, but not both. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Melchior FRANZ wrote: > What I really, really want is: switch to another desktop and write two > lines in "konversation", or look at Atlas, or check for mail, > etc. Without the possibility to switch desktops (despite running fgfs > in fullscreen mode) SDL is completely out of question for me. I'll > stick with freeglut then. I'm confused. SDL works just fine in windowed mode, and freeglut doesn't support resolution switching, so I can't see what capability you've lost. Can you explain exactly what your problem is again? It sounds like you really want to be running in windowed mode in the first place. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Curtis L. Olson wrote: > If SDL can't switch to other virtual desktops when running > fullscreen/no-window decorations, then perhaps would there be a way > to toggle between fullscreen/window mode so that once you are > running in a standard window again, then you can hotkey between > virtual desktops. OK, I'm starting to understand the issues now. There are *two* dimensions to the notion of a window being "fullscreen": The state of being undecorated, and mapped on top of the other windows; and the current video mode being different from the normal desktop one. So "switching out of fullscreen mode" requires that both states be reset. The first (unmapping the top window) is traditionally handled by the window manager, but the second (setting the video mode) *must* be done by the application. The WM doesn't know what the current mode is, or that it has been changed. The glut stuff works only because it can't set the video mode, so nothing needs to change. The problem is that SDL isn't prepared to "switch out" of modes like this. It presumes that it will run to completion and then exit. We could probably fix it to (1) not grab the keyboard events, and (2) switch back to the desktop mode on an Unmap or FocusOut event. But then we'd be requiring a bleeding edge SDL build, which negates most or all of the compatibility advantages. Apparently none of the other SDL users care enough about this feature to complain about it. The idea of writing a custom "fg_os_x11.cxx" is starting to sound better and better... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Melchior FRANZ wrote: > There's a workaround under KDE that makes SDL as usable as glut: > $ kstart --fullscreen fgfs What does that do? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
I wrote: > Melchior FRANZ wrote: > > There's a workaround under KDE that makes SDL as usable as glut: > > $ kstart --fullscreen fgfs > > What does that do? Never mind. We can't use that: it's a brutal window management hack that grabs the window at creation and diddles its properties before the WM sees it (or maybe it's a hook into the WM implementation, same thing). Note, by the way, that this is *not* actually capable of running SDL in fullscreen mode (i.e. at a custom resolution). This runs the fgfs binary as a *windowed* application, and then hacks around with the window properties such that the WM displays it fullscreen. The only way to get SDL to change the video mode is to use SDL_FULLSCREEN, and if you do that the only way you'll get back is via SDL_Quit(). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [OT] g77 and link errors
Jon S. Berndt wrote: > I'm trying to build an application in gnu fortran (g77) but I end up > with these link errors: > > undefined reference to `__umoddi3' > undefined reference to `__udivdi3' Those look like the software math emulation stuff implemented in libgcc. You could try adding -lgcc to your link line, but I'd be suspicious that something else is wrong. On x86, the only functions from that library that should be required are the 64 bit long integer ones... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Curtis L. Olson wrote: > Ok, since you have your head into this at the moment: With X11, is it > possible to run an SDL app in window (so it behaves well with the > window manger) but in a window that fills the entire screen and is > undecorated (so it looks "full screen")? Sadly, no. Even if it were, that's basically a hack to get around other issues. The Right Thing is to change the video mode, throw up a desktop-integrated fullscreen window, detect when the window is unmapped or loses keyboard focus, and reset the resolution to get back to the desktop. Glut does the desktop integration thing by ignoring the video mode issue. SDL handles mode switching by taking over the desktop. No one does both. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
> How can this be a "wrong way" to run an app? It's a fine way, just not the only one. Most people run their desktops at high resolutions that may not be good choices for a 3D buffer. Older cards (like the Radeon 7500 in my laptop) can handle FlightGear just fine, but not at 1280x1024. And some 3D features don't make sense on a desktop: in many cases, it is visually preferable to run a 3D application at, say, 1024x768 with FSAA than to have a single buffer at 1600x1200. All of these choices involve setting the video mode; this has been a very traditional feature in the windows gaming world. Users have gotten used to applications taking over the screen and (ahem) mixed compatibility with desktop stuff like Alt-Tab. But maybe it's time to re-investigate that assumption; it seems like few people here are interested in running at anything but desktop resolution, but still want a full screen mode. For myself, I've always been happy to run it in a window if I wanted to do desktop stuff and have missed the ability to switch modes and play with toys liks FSAA. The problem isn't that SDL is unwilling to support what you want: it's that SDL hasn't traditionally distinguished "fullscreen" from "mode switch" and (in the early days) didn't have a portable way to integrate with the desktop world. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: CVS: source/src/Main fg_os_sdl.cxx, 1.5, 1.6
Curtis L. Olson wrote: > So I still don't understand, is SDL unable to open a window covering > the entire desktop but with no window decorations? Or can this be > done? No. Well, yes. It's complicated. :) SDL *is* opening a window covering the entire desktop but with no window decorations. But it is also setting the video mode at the same time (even if the actual hardware mode technically doesn't change because you asked for the desktop resolution). The normal action when the user presses alt-tab (or any of the other desktop-global keystrokes) is for the window manager to assert control and do stuff like minimize the fullscreen window, change keyboard focus, etc... But if the mode is changed, it won't be reset and the user will be left with a confusing partial desktop on the screen. So as a safety feature, SDL *also* does a keyboard grab, to prevent the window manager from taking any action that will confuse the user. But that's a symptom, not the problem; a proper fix would not be to eliminate the keyboard grab, but to work with the window manager to enforce a policy like "always set the video mode to XXX when this application is mapped and has the keyboard focus". To my knowlege, no work has been done on such a window management protocol. Maybe that's where we should start... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Jorge Van Hemelryck wrote: > This is a patch (plus examples of use) I've created to solve the > problem we had at work. Short explanation - the aim was to have a > separate HUD code (as opposed to included in the FlightGear code). > > Long explanation - the easiest solution I saw was to develop a plugin > system for the HUD code. I've done it under Linux (using dlfcn.h), and > I don't know how this can be adapted to other systems. Indeed, portable shared library development (and especially portable late-binding to those libraries) is a big mess. :) What exactly is the goal here? Do you have a particular external HUD renderer that you want to link in? Is it so large that it can't simply be included in the FlightGear distribution? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Jorge Van Hemelryck wrote: > We already have an external HUD code. Actually, it is quite large, > [...] and more importantly it can't be distributed. At all. That was my fear. Opinions differ (widely!) on this point. But in general, adding a dynamic loading API to a free software project for the sole purpose of interfacing to non-free software is not considered to be within the spirit of the GPL. > Therefore, I'm doing the best I can (that is, mixing my hobbies and > my work, and working at home) in order to make flightgear benefit > from this. I don't want to start a flame war here, but it's not clear to me that the FlightGear community would receive any benefit from having an interface layer to software it cannot use. The standard GNU/FSF argument is that, by enabling and protecting proprietary development (of HUD modules, in this case), it would in fact discourage free software contributions. You are right, of course, that you are under no obligation to distribute your internally-developed modifications to FlightGear. The GPL only requires that *if* you distribute them, you do so under the same license. Accepting this interface layer as part of FlightGear would have the effect of removing that restriction. I do not mean to seem ungrateful, but I'm not sure that's in the community's best interest. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Jorge Van Hemelryck wrote: > Is it not possible to just include my work (with some improvements > such as conditional compilation of the functionality) with the > distribution of FlightGear ? It would make my task of making people > accept FlightGear here easier... But you seem to miss the point. It would also *remove* the GPL requirements from anyone who develops HUD code. I'm not sure that's a good tradeoff, especially when the code in question is something we can never see or use. I'm not questioning your motive. I admire that you want to evangelize FlightGear and that you have worked at home to do integration work for your project. But I don't think you have considered the licensing issues completely. Taking this kind of design to an extreme: we could write a dynamic loading API for every module in the simulator. A proprietary, non-GPL simulator (clearly "derived from" FlightGear) could then legally redistribute itself along with FlightGear solely by linking to those APIs. Now, that might be OK if we all agreed that is what we wanted. But such a situation is certainly not the "normal" interpretation of the GPL, which says that modified versions must be shared under the same license. Honestly, if there were actual simulator features involved here (an existing external library that we wanted to use), I would be more amenable to this idea. But as it stands, the only beneficiaries to this patch are doing proprietary development and cannot contribute to the project. And as written, the patch acts as an "escape clause" that allows HUD module developers to ignore the requirements that the GPL places on the rest of the code. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Erik Hofman wrote: > I'm not sure what to think about this, but ... We already allow for > things like this and I can see the need to drive external HUD code > from within FlightGear (if nothing else for FlightGear's own HUD code > on a separate display). My understanding was that this was a patch to draw the *internal* HUD using externally loaded code. Basically, it allows someone to write a (non-GPL) C++ class implementing a HUD object and get it to display on the FlightGear display. That was my concern. In the past, our linkage to proprietary projects has been either via well-defined stream protocols (net_fdm, NMEA, etc...) or via the same configuration interface (properties) that we give to the user. This is a little different; instead of defining an external interface and telling proprietary developers "you can use this", it points at an existing code module and tells the proprietary developers "you don't need to worry about the GPL here". The *implementation* of this patch is just plain C++ code, but the *effect* is a change in the license of the project. That kind of design is a slippery slope. We obviously can't/won't apply it to the whole project, because it would be easier to simply re-license it under a more permissive license. So why are we using the GPL in the first place, and what makes the HUD rendering special, that it shouldn't be covered by the same license? Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Jorge Van Hemelryck wrote: > The GPL requirements are in no way removed, of course. OK, excellent. My fear was that your management/team was afraid the GPL, and you were trying to sell them on this patch as a way to "get around" it. But do be aware that this stuff is complicated. An FSF interpretation of their license in a FAQ is not itself a license. There are many examples of dynamic linkage between GPL and proprietary code that are not generally interpreted as violations (binary linux kernel drivers, for example). We would need to be very careful to explain that this mechanism is *not* a exemption to our license. So I would still argue against this patch simply because it confuses the issue of license requirements. But it's good to know that at least we all interpret the license the same way. > Now that I have made the patch, it can be made available for > everyone to use, but I don't think I will do that anyway. I'm just > trying to show you why I find it odd to see you reject my patch. > > [...] we would have spent a *lot* of money on a new visualization > system. I'd rather try and put that money to better use. Maybe try > to make FlightGear profit by this later on. This part still has me confused. No offense, but your patch as submitted doesn't do anything but add code to the already complicated HUD implementation. Even if Curt applied it, there is no way a user could tell that it was there. It is a "feature" only for people who (1) cannot or do not want to contribute code to the project and (2) want to distribute binary HUD rendering modules. As far as I can see, that group has a population of zero. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] external HUD proposal (with code !)
Jon Stockill wrote: > That's because Linus made the exception - not because it's allowed by > the GPL - in effect he extended the rights granted by the GPL (this is > allowed - it's restricting rights that's forbidden). You're thinking about the exception for running programs, which appears at the top of the kernel COPYING file. In the case of modules, actually, Linus has notably refused to issue such an exception. Instead, he issued a statement saying something to the effect that "If you ship a binary [i.e. dynamically loadable] module, you had better be damn sure that it does not constitute a derived work of the kernel." The general public consensus seems to be that hardware drivers are OK, FWIW. Like I said, it's complicated. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FlightGear Abort: AIMgr problem??
Durk Talsma wrote: > It looks like the crash is somewhere inside the AIMgr (judging from stackdump > item #15), but since I'm still incredably unfamiliar with this part of the > code, this might just be a wild guess. > > Anyways, I hope that this is useful debug information. Can others > confirm this? The 0xdeadbeef assertion failure in ssg is almost certainly memory corruption. Other typical symptoms are heap corruption, which is what seems to be happening here (the crash happens under operator new). There's no particular reason to suspect the AIMgr in particular, it was just unlucky enough to be the first to traverse the broken ssg node. This kind of bug is really hard to track down. Valgrind helps, but it would take *days* to get to where you are seeing the crash. Basically, you end up having to search the configuration space: + What was the last version that worked? + Does turning off threads fix the problem? + [Ditto for any other configuration choices you have made] + How about changing plib versions? Some things can be ruled out already: since this is a YASim aircraft, JSBSim is off the hook. Likewise, the 747 has no 2D panel, etc... Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Memory Corruption
Lee Elliott wrote: > I first reported this on 02-April and had updated from cvs two > days prior to mentioning the problem. I think the last update > I'd done before that was about two weeks earlier. Can anyone confirm the same behavior from the 0.9.4 binaries? (I think it branched sometime right around there.) Is there any platform dependence to this? I have to admit it's been a long time since I've have a single fgfs running for that long. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Command Line Options
Jon S. Berndt wrote: > Where in the FlightGear code are command line options parsed? They're XML-controlled and map to properties at runtime. You can add new ones in options.xml in the base package. The actual C++ code is, I think, in Main/fg_options.cxx Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
