[Flightgear-devel] Re: Wing motion
* Melchior FRANZ -- Tuesday 20 December 2005 02:22: > * Ampere K. Hardraade -- Tuesday 20 December 2005 02:00: > > I'm not too excited about having to create another instance of the wings. > > Good news for you: you don't have to do *anything*! (Was the bitching > on IRC not enough?) Umm ... sorry for the harsh reply. You wanted a better solution, and "bitching" (or rather: criticizing the current approach) was a good ... or at least a working way to achieve that. :-) The best approach would probably be to have a generic "morph" animation (for parachutes etc.), and a special "bend" animation that works well for wings. These would then *too* work with ssgTween, but not require two or more instances, but just one from which the others are calculated at init time (using Ralf's magic formula). The first step will, of course, be to make the ssgTween thing work with "morph". (We could make our own interpolator, but this could well face the same problems.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ralf Gerlich -- Tuesday 20 December 2005 15:16: > Just an idea, but would it help to define a specialised bending > animation instead of the general purpose morph? Why instead? Adding a "bend" animation would probably not be that hard for someone proficient with vector calculation. Which I am not. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Melchior FRANZ -- Tuesday 20 December 2005 10:46: > I just hoped that the transformation would somehow > be morphed, too. Steve is using tweening for his exposer, and I > would be a bit surprised if he hadn't thought of that. Hmm ... no. I take that back. Will hardly be considered by plib. Then we'd need to make the movable objects on the wing separate "morph" animations. Or something. But as long as smooth object don't work, I won't think much about that. :-/ m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: b1900d logo
* syd -- Tuesday 20 December 2005 04:18: > I see from user screenshots that my idea of a transparent logo for the > B1900d was a bad idea . Just use a "noshadow" animation on the logo. That's what the seahawk has yet to do, as well as others. The bo105 does since a while, although this causes a different problem there: The rotor shadow doesn't appear on the emblem. But as the b1900d doesn't have a rotor ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Erik Hofman -- Tuesday 20 December 2005 10:26: > Melchior FRANZ wrote: > > In theory, aileron/flap/... movements should still work. > I'm afraid they don't work properly anymore since the center > point and the normal axis' probably have changed after the animation... Yes, possibly. I just hoped that the transformation would somehow be morphed, too. Steve is using tweening for his exposer, and I would be a bit surprised if he hadn't thought of that. But I haven't looked yet. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ralf Gerlich -- Tuesday 20 December 2005 10:16: > Melchior FRANZ schrieb: > > Unfortunately, so far it only works with "solid" (unsmoothed) objects. > > Looks like a plib bug to me, but I have yet to find the exact reason. > > Maybe the normals of the faces don't get interpolated as well? (Just a > stab in the dark) That was, of course, what I was suspecting, too. There *is* code to interpolate them, and it doesn't look wrong to me. I'll ask on the plib list. The suspicious thing is that both "solid" and "smooth" sphere are made of 92 vertices. But in the scenegraph, the solid one has 540(!?), but the smooth one only the 92. And some faces of the smooth one seem to be smooth when rendered. The real problem is that only a couple of faces are rendered, while the others are just missing. Looks like a skeleton. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
Tween method (for the curious ones): That's how you would current set up such an animation. First you organize your objects in the 3D modeler like so: |___wing |normal | |main | |aileron | |... | |bent |main |aileron |... where "normal" and "bent" are almost identical and best generated by copying the "normal" wing to "bent" and then manually bending that. 3D modeler apps should have tools for achieving good bending results. In the animation file you would then say: morph wing /sim/model/foo/wing-bending At least that's how it currently (sort-of :-) works. In theory, aileron/flap/... movements should still work. But I haven't tested that yet. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Josh Babcock -- Tuesday 20 December 2005 02:54: > I wonder what the performance hist will be. I assume that it will > go linearly with the number of vertecies. I only had two spheres side by side in the scenery (next to the bo105 in KMRY), with 92 vertices each. They were constantly morphing into each other, back and forth. This had no impact. Of course, with a very detailed wing it could be a different matter, but I don't think that it would be a big problem. Morphing is something that you only want on a few nearby objects. And yes, it should be linear. It interpolates four float values per vertex in "full mode", but could be limited to 2 (we don't *really* need to interpolate UV coords and vertex colors :-). Unfortunately, so far it only works with "solid" (unsmoothed) objects. Looks like a plib bug to me, but I have yet to find the exact reason. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Ampere K. Hardraade -- Tuesday 20 December 2005 02:00: > I am looking forward to it, although I'm not too excited about having to > create another instance of the wings. Good news for you: you don't have to do *anything*! (Was the bitching on IRC not enough?) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Vivian Meazza -- Monday 19 December 2005 09:55:
> > (C) tween method: this isn't implemented in fgfs yet, but plib offers
> > an ssgTweenController ("A morph controller") class.
> There might well be other applications for this animation: I'm thinking
> of pilot animation in particular.
I had already started. Just have to finish now. :-)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Wing motion
* Jon S. Berndt -- Monday 19 December 2005 05:04:
> Would it be possible to change the visual appearance of wing flex during
> flight?
As Curt and Joacim have mentioned already, there are ways to do it:
(A) ornithopter method: several instances of the wing. This has the
disadvantage that you'd need a lot of them for smooth transitions.
No problem for the fast moving ornithopter, but one would probably
need a *lot* of such instances for a glider wing.
(B) bo105 method: wing/blade made of smaller parts that are each
animated with smaller rotations. Smooth movements, but the hinges
between them can look quite ugly. Not a big problem for the bo105,
because the blade is dull and black. Wouldn't work well for a shiny
white wing.
(C) tween method: this isn't implemented in fgfs yet, but plib offers
an ssgTweenController ("A morph controller") class. Maybe "we" should
make it available in fgfs for wings/blades. It interpolates between
two or more objects with the same number of vertices&faces, so one
would only need two instances of the wing and could smoothly
interpolate. Would probably work better than either (A) or (B).
(see http://plib.sourceforge.net/ssg/branches.html and the
test application: $PLIB/examples/src/ssg/tween_test/tween_test.cxx)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: C310 Update
* Buchanan, Stuart -- Sunday 18 December 2005 21:50: > In particular a number of the surfaces are one-sided which causes > problems when combined with transparent surfaces like the windows. No. That's normally caused by wrong object order in the *.ac file. You can either re-order the objects there, or in the animation *.xml file by listing the objects in correct order in a type-less : foo bar m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Options saving patches
Sorry to be annoying yet again, but that's what I'm best at: * Erik Hofman -- Saturday 17 December 2005 10:48: > I must say I like the idea, but given it's current state (no windows > support) I would like to postpone it until after FlightGear 1.0 is released. And I would like to postpone the 1.0 release, until FlightGear is ready to be called 1.0. Saving GUI states is one piece of that puzzle, as are landing/taxi lights. There are no finished patches available for that yet? So? What keeps "us" from working on them and waiting until they are finished? (No, I won't be working on that, but I'm also not pressing for 1.0.) Either the 1.0 number means anything, then fgfs better be complete. Or it doesn't mean anything, then let's release it when it's done and call the next releases 0.9.10++. Or is there a compelling reason to rush out 1.0 *now*? One that we aren't told for whatever reason? Does anyone pay for it whose business depends on it? (MathWorks?) Or is it that fgfs needs for some reason to be called 1.0.0 for SCALE 2006? And why? Other reasons? Do we deserve to know about them? Doesn't look like it. I'm now sufficiently fed up with the secret 1.0 agenda, that I'll stop contributing until after this monstrosity is out. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Freeglut and game mode
* Curtis L. Olson -- Thursday 15 December 2005 21:06: > I have verified that glut game mode works great with the original > glut-3.7, but it's horribly broken in freeglut. Keyboard handling is also broken in freeglut. That's why I'm using SDL. (I don't like unfreeglut :-). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Freeglut and game mode
* Curtis L. Olson -- Thursday 15 December 2005 19:21: > In the past with Debin and Glut, specifying --enable-game-mode has > always worked for me as expected. But now I'm trying to do the same > thing with freeglut-2.2.0 and Fedora Core 4. Don't know if it has anything to do with it: http://mail.flightgear.org/pipermail/flightgear-cvslogs/2005-November/011451.html Maybe your glut doesn't understand the "preferred" format. I run fgfs with SDL, but not with the built-in "fullscreen" mode, but manually set to screensize. And I tell my window manager to omit the window decoration. Don't know if this works with multiscreen. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
* Vassilii Khachaturov -- Wednesday 14 December 2005 23:13: > > 1) You didn't even try the patch. I didn't either, but I see that > >it can't work. Hint: xmllint :-} > > I don't know how you see that, + false ^^^ m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
* Vassilii Khachaturov -- Wednesday 14 December 2005 21:41: > And now comes the attachment... Sorry. 1) You didn't even try the patch. I didn't either, but I see that it can't work. Hint: xmllint :-} 2) Polluting joysticks.xml with driver specific stuff is a no-go. Drivers need to be self-contained, and must not spread their internals elsewhere. (You can check in the nasal init block if the property exists, and if so, which value it has.) m. PS: I still don't like the whole idea. :-> ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: JSBSim broken?
* Martin Spott -- Sunday 11 December 2005 20:09:
> "Jon S Berndt" wrote:
> > On Sun, 11 Dec 2005 15:02:13 +0100 Melchior FRANZ wrote:
> > > It's the job of the glue code (JSBSim.cxx) to map internal values
> > > to standard fgfs properties. This internal /fdm/jsbsim/foo thingy
> > > will hardly ever be supported by the keyboard/joystick bindings.
>
> > Maybe I'm not understanding your meaning, though ...
>
> I'm convinced Melchior aimed at pointing out that FDM-specific names
> for non-FDM-specific properties don't belong into FlightGear.
Exactly. FlightGear isn't a shell for JSBSim. FlightGear supports more
than just one FDM. There are conventions for where to find properties.
Engine stuff is in /engines/. There are setups relying on information
being available in the same places, no matter which FDM is used. Take
for example joystick drivers:
$ cd $FG_ROOT/Input/Joysticks
$ find -name \*.xml|xargs grep reverser|sed 's,[^I ]\+, ,'
./ThrustMaster/Top-Gun-Afterburner.xml: reverser =
!getprop("/controls/engines/engine[0]/reverser");
./ThrustMaster/Top-Gun-Afterburner.xml:
props.setAll("/controls/engines/engine", "reverser", reverser);
./ThrustMaster/Top-Gun-Afterburner.xml: if (reverser) {
./Saitek/Cyborg-Gold-3d-USB.xml: i =
!getprop("/controls/engines/engine[0]/reverser");
./Saitek/Cyborg-Gold-3d-USB.xml: props.setAll("/controls/engines/engine",
"reverser", i);
./Saitek/Cyborg-Evo.xml: reverser =
!getprop("/controls/engines/engine[0]/reverser");
./Saitek/Cyborg-Evo.xml: props.setAll("/controls/engines/engine", "reverser",
reverser);
./Saitek/Cyborg-Evo.xml: if (reverser) {
This makes the reverser controllable with a joystick button or axis.
The glue code is exactly for the purpose to unify FDM internal
properties and to offer them under the same addresses. How do you
think the bindings should look like if every FDM has its own funny
properties, and developers are unwilling to cooperate?
apply thrust reverser
nasal
fdm = getprop("/sim/flight-model");
if (fdm == "yasim") {
props.setAll("/controls/engines/engine", "reverser", 1);
} elsif (fdm == "jsbsim") {
props.setAll("/fdm/jsbsim/propulsion/engine", "reverser-angle", 120);
} elsif (fdm == "uiuc") {
props.setAll("/some/other/random", "place", "please-reverse-now");
} else ...
Thrust reversers aren't unique to JSBSim, and even less to the L410.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: JSBSim broken?
* Dave Culp -- Sunday 11 December 2005 05:05: > The reverser method has changed. You set the reverser now by adjusting the > "/fdm/jsbsim/propulsion/engine[x]/reverser-angle" [...] > The property "/engines/engine[x]/Reverser" doesn't work any more. It's the job of the glue code (JSBSim.cxx) to map internal values to standard fgfs properties. This internal /fdm/jsbsim/foo thingy will hardly ever be supported by the keyboard/joystick bindings. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Disappearing objects - bug???
* Georg Vollnhals ([EMAIL PROTECTED]) [051210 17:36]: > I placed 2 objects into the sea near Bremerhaven (EDWB) which can be > seen from distance but when you come nearer they disappear. > 2. Created a file 3089361.stg > OBJECT_STATIC lighthouse.xml 8.48 53.57 0.0 10 > OBJECT_STATIC oilrig.ac 8.485 53.575 0.0 10 > 3. Put 3089361.stg into folder..\data\Scenery\Objects\e000n50\e008n53 Why did you choose 3089361.stg? Guessing? :-> In scripts/perl/scenery/ there's a script calc-tile: $ calc-tile 8.48 53.57 Longitude: 8.48 Latitude: 53.57 Tile: 3089377 Path: "e000n50/e008n53/3089377.stg" $ calc-tile 8.485 53.575 Longitude: 8.485 Latitude: 53.575 Tile: 3089377 Path: "e000n50/e008n53/3089377.stg" Both entries shoud be in file e000n50/e008n53/3089377.stg. Using calctile.nas would even have created the whole OBJECT line with just a keypress ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Disappearing objects - bug???
* Georg Vollnhals ([EMAIL PROTECTED]) [051210 17:36]: > I placed 2 objects into the sea near Bremerhaven (EDWB) which can bex > seen from distance but when you come nearer they disappear. > 2. Created a file 3089361.stg > OBJECT_STATIC lighthouse.xml 8.48 53.57 0.0 10 > OBJECT_STATIC oilrig.ac 8.485 53.575 0.0 10 > 3. Put 3089361.stg into folder > ..\data\Scenery\Objects\e000n50\e008n53 Why did you choose 3089361.stg? Guessing? :-> In scripts/perl/scenery/ there's a script calc-tile: $ calc-tile 8.48 53.57 Longitude: 8.48 Latitude: 53.57 Tile: 3089377 Path: "e000n50/e008n53/3089377.stg" $ calc-tile 8.485 53.575 Longitude: 8.485 Latitude: 53.575 Tile: 3089377 Path: "e000n50/e008n53/3089377.stg" Both entries shoud be in file e000n50/e008n53/3089377.stg. Using calctile.nas would even have created the whole OBJECT line with just a keypress ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot GUI
* Melchior FRANZ -- Wednesday 07 December 2005 21:00: > * Steve Knoblock -- Wednesday 07 December 2005 20:35: > > What if the Autopilot menu entry was bound to a function [...] > > Thanks, but I didn't ask *how* to do it [...] But, yes, I had planned to let menubar.xml just call gui.autopilot(), which would then by default open the dialog that it opens now. And everyone could redefine gui.autopilot() to open some other dialog or do other fancy stuff. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot GUI
* Steve Knoblock -- Wednesday 07 December 2005 20:35: > >What should be disabled? Only the "Autopilot settings" entry, or the > >whole "Autopilot" menu? > What if the Autopilot menu entry was bound to a function [...] Thanks, but I didn't ask *how* to do it (which I know pretty well), but *which* *entry* to disable. I assume that the whole "Autopilot" menu isn't functional when using the KAP140 (waypoints etc.). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot
* Buchanan, Stuart -- Wednesday 30 November 2005 18:27: > I would think the .nas file for the KAP140 should be able to > disable the appropriate parts of the menu tree dynamically when initialized. What should be disabled? Only the "Autopilot settings" entry, or the whole "Autopilot" menu? I wouldn't add this to the KAP140, though, but rather to gui.nas' INIT function. (Currently we operate with full property paths, and when someone inserts a menu entry, the full paths might not address the same menu entry. Better have everything in the same place if possible. At least for now. I think about adding tags to menu entries that are to be disabled/enabled for safe access.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 32, Issue 19
* Steve Knoblock -- Tuesday 06 December 2005 21:16: > My only caution would be possible malicious disabling of essential > menus. I think the author would be exposed pretty quickly, Exactly. And this isn't the first opportunity for aircraft designers to annoy others. What about a Nasal script that endlessly creates property nodes? Or disables mouse, keyboard and joystick? What about making a really bad FDM config? Sounds familiar? We have some of those already! ;-) Seriously, this is a non-issue. Code that goes into cvs is reviewed and quickly fixed. And if something doesn't work as expected, you erase it from your disk. Viola. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand to disable/enable menu entries
* Vassilii Khachaturov -- Tuesday 06 December 2005 16:41: > add a menu that would allow to disable the cyclic control from the yoke > if /rotors is detected. Moreover, thereafter the thing will remove itself > from the menu :-) Simply removing the properties from /sim/menubar/default/... will not remove the entries from the screen, though. You'll also have to reload the GUI after that, so that a new menubar is built. This is possible with Nasal, but you'll have to verify that this works well (as in: doesn't look like crap for the user :-). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand to disable/enable menu entries
* Stefan Seifert -- Tuesday 06 December 2005 16:49: > And I still believe, that you should not have to set this to false, but > set it to true if you want that item enabled. Yeah, whatever. This patch is about adding the possibility. It's up to the developer to use it in a sane way. Actually, I have done right that for the "Fuel & Payload" dialog now. It's generally turned off (false in $FG_ROOT/gui/menubar.xml), and only turned on in gui.nas when using YASim. Of course, JSBSim will soon fill this ugly gap! Or I will make disabled entries blink red! ;-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx: allow to disable/enable menu entries
* Melchior FRANZ -- Tuesday 06 December 2005 17:50: > http://members.aon.at/mfranz/menu_disable.diff [5 kB] Committed. And I forgot to mention in the cvs log message: OK'ed by Erik. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx: allow to disable/enable menu entries
* Melchior FRANZ -- Tuesday 06 December 2005 16:54: > Attached is a better patch. ... and in case someone *really* wants to review that, or maybe even test it. I fixed one bug and cleaned the code up, and I will probably make some more minor changes: http://members.aon.at/mfranz/menu_disable.diff [5 kB] m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx: allow to disable/enable menu entries
* Melchior FRANZ -- Tuesday 06 December 2005 15:57:
> This should better be hooked into the property tree, so that one can
> directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and
> get the menu disabled.
Done. Attached is a better patch. No more fgCommand, and no Nasal-wrapper.
Just set the "enabled" property. This can also be done in gui/menubar.xml.
"Fuel & Payload" would be globally disabled there, and only FDMs which
support this feature turn it on. (Or rather: gui.nas enables it for YASim.)
m.
Index: menubar.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/menubar.cxx,v
retrieving revision 1.25
diff -u -p -r1.25 menubar.cxx
--- menubar.cxx 9 Nov 2005 10:48:45 - 1.25
+++ menubar.cxx 6 Dec 2005 15:53:42 -
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -302,6 +303,8 @@ FGMenuBar::make_menubar(const SGProperty
make_menu(menu_nodes[i]);
_menuBar->close();
+make_map(props);
+
if (_visible)
_menuBar->reveal();
else
@@ -349,6 +352,106 @@ FGMenuBar::destroy_menubar ()
SG_LOG(SG_GENERAL, SG_INFO, "Done.");
}
+struct MenuListener : SGPropertyChangeListener {
+MenuListener() : menubar(0) {
+NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+if (gui)
+menubar = gui->getMenuBar();
+}
+FGMenuBar *menubar;
+void valueChanged(SGPropertyNode* node) {
+menubar->enable_item(node->getParent(), node->getBoolValue());
+}
+};
+
+void
+FGMenuBar::make_map(const SGPropertyNode * node)
+{
+string base = node->getPath();
+const char *legend;
+
+int menu_index = 0;
+for (puObject *obj = ((puGroup *)_menuBar)->getFirstChild();
+obj; obj = obj->getNextObject()) {
+
+// skip puPopupMenus. They are also children of _menuBar,
+// but we access them via getUserData() (see below)
+if (!(obj->getType() & PUCLASS_ONESHOT))
+continue;
+
+legend = obj->getLegend();
+if (!legend)
+continue;
+
+std::ostringstream menu;
+menu << base << '/' << "menu[" << menu_index << "]";
+SGPropertyNode *prop = fgGetNode(menu.str().c_str());
+if (!prop) {
+SG_LOG(SG_GENERAL, SG_WARN, "menu without node: " << menu.str());
+continue;
+}
+
+// push "menu" entry
+_entries[prop->getPath()] = obj;
+if (!prop->hasValue("enabled"))
+prop->setBoolValue("enabled", true);
+
+enable_item(prop, prop->getBoolValue("enabled"));
+prop->getNode("enabled")->addChangeListener(new MenuListener());
+
+// push "item" entries
+puPopupMenu *popup = (puPopupMenu *)obj->getUserData();
+if (!popup)
+continue;
+
+vector e;
+
+for (puObject *me = ((puGroup *)popup)->getFirstChild();
+me; me = me->getNextObject()) {
+
+legend = me->getLegend();
+if (!legend)
+continue;
+
+e.push_back(me);
+}
+
+for (unsigned int i = 0; i < e.size(); i++) {
+
+std::ostringstream item;
+item << menu.str() << '/' << "item[" << (e.size() - i - 1) << "]";
+prop = fgGetNode(item.str().c_str());
+if (!prop) {
+SG_LOG(SG_GENERAL, SG_WARN, "item without node: " << item.str());
+continue;
+}
+_entries[prop->getPath()] = e[i];
+if (!prop->hasValue("enabled"))
+prop->setBoolValue("enabled", true);
+
+enable_item(prop, prop->getBoolValue("enabled"));
+prop->getNode("enabled")->addChangeListener(new MenuListener());
+}
+menu_index++;
+}
+}
+
+bool
+FGMenuBar::enable_item(const SGPropertyNode * node, bool state)
+{
+if (!node || _entries.find(node->getPath()) == _entries.end()) {
+SG_LOG(SG_GENERAL, SG_WARN, "Trying to enable/disable "
+"non-existent menu item");
+return false;
+}
+puObject *object = _entries[node->getPath()];
+if (state)
+object->activate();
+else
+object->greyOut();
+
+return true;
+}
char **
FGMenuBar::make_char_array (int size)
Index: menubar.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/menubar.hxx,v
retrieving revision 1.7
diff -u -p -r1.7 menubar.hxx
--- menubar.hxx 22 O
[Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand to disable/enable menu entries
* Melchior FRANZ -- Tuesday 06 December 2005 15:20: > the attached patch adds an fgCommand that allows to disable/enable > menu entries This should better be hooked into the property tree, so that one can directly set /sim/menubar/default/menu[2]/item[3]/enabled to false and get the menu disabled. Working on that. Comments still welcomed, though. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand to disable/enable menu entries
Don't know if this feature is desirable for 1.0.0: the attached
patch adds an fgCommand that allows to disable/enable menu entries
( and ). It could be used for disabling the
"Fuel & Payload" dialog for non-YASim aircraft and to disable the
autopilot dialog when it has no effect on the used autopilot.
For this to work, it creates a [menu property path]->[puObject] map,
which can later also be used for all sorts of menu manipulation.
If the patch is accepted, I'll also add a nasal wrapper to
$FG_ROOT/Nasal/gui.nas, which is called like so:
gui.menuItemEnable("menu[2]/item[3]", 0);
The C++ function FGMenuBar::menu_enable() is to be called with
the full path or a property node:
enable_item("/sim/menubar/default/menu[2]/item[3]", false);
m.
Index: Main/fg_commands.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_commands.cxx,v
retrieving revision 1.64
diff -u -p -r1.64 fg_commands.cxx
--- Main/fg_commands.cxx 11 Nov 2005 07:17:26 - 1.64
+++ Main/fg_commands.cxx 6 Dec 2005 14:16:34 -
@@ -21,6 +21,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -1107,6 +1108,31 @@ do_dialog_apply (const SGPropertyNode *
/**
+ * Disable/enable menu entry.
+ *
+ * property: Full path to a or node.
+ * Example: "/sim/menubar/default/menu[1]/item[4]"
+ * state: true -> enable; false -> disable
+ */
+static bool
+do_menu_item_enable (const SGPropertyNode * arg)
+{
+NewGUI * gui = (NewGUI *)globals->get_subsystem("gui");
+FGMenuBar * menu = gui->getMenuBar();
+if (menu && arg->hasValue("property")) {
+const char * path = arg->getStringValue("property");
+SGPropertyNode_ptr item = fgGetNode(path);
+if (!item)
+return false;
+
+return menu->enable_item(item, arg->getBoolValue("state", true));
+}
+
+return false;
+}
+
+
+/**
* Redraw GUI (applying new widget colors). Doesn't reload the dialogs,
* unlike reinit().
*/
@@ -1357,6 +1383,7 @@ static struct {
{ "dialog-close", do_dialog_close },
{ "dialog-update", do_dialog_update },
{ "dialog-apply", do_dialog_apply },
+{ "menu-item-enable", do_menu_item_enable },
{ "gui-redraw", do_gui_redraw },
{ "presets-commit", do_presets_commit },
{ "log-level", do_log_level },
Index: GUI/menubar.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/GUI/menubar.cxx,v
retrieving revision 1.25
diff -u -p -r1.25 menubar.cxx
--- GUI/menubar.cxx 9 Nov 2005 10:48:45 - 1.25
+++ GUI/menubar.cxx 6 Dec 2005 14:16:34 -
@@ -4,6 +4,7 @@
#include
#include
+#include
#include
#include
@@ -302,6 +303,8 @@ FGMenuBar::make_menubar(const SGProperty
make_menu(menu_nodes[i]);
_menuBar->close();
+make_map(props);
+
if (_visible)
_menuBar->reveal();
else
@@ -349,6 +352,91 @@ FGMenuBar::destroy_menubar ()
SG_LOG(SG_GENERAL, SG_INFO, "Done.");
}
+void
+FGMenuBar::make_map(const SGPropertyNode * node)
+{
+string base = node->getPath();
+const char *legend;
+
+int menu_index = 0;
+for (puObject *obj = ((puGroup *)_menuBar)->getFirstChild();
+obj; obj = obj->getNextObject()) {
+
+// skip puPopupMenus. They are also children of _menuBar,
+// but we access them via getUserData() (see below)
+if (!(obj->getType() & PUCLASS_ONESHOT))
+continue;
+
+legend = obj->getLegend();
+if (!legend)
+continue;
+
+std::ostringstream menu;
+menu << base << '/' << "menu[" << menu_index << "]";
+SGPropertyNode *prop = fgGetNode(menu.str().c_str());
+if (!prop) {
+SG_LOG(SG_GENERAL, SG_WARN, "menu without node: " << menu.str());
+continue;
+}
+
+// push "menu" entry
+_entries[prop->getPath()] = obj;
+
+// push "item" entries
+puPopupMenu *popup = (puPopupMenu *)obj->getUserData();
+if (!popup)
+continue;
+
+vector e;
+
+for (puObject *me = ((puGroup *)popup)->getFirstChild();
+me; me = me->getNextObject()) {
+
+legend = me->getLegend();
+if (!legend)
+continue;
+
+e.push_back(me);
+}
+
+for (unsigned int i = 0; i < e.size(); i++) {
+
+std::ostringstream item;
+item << menu.str() << '/' << "item[" << (e.size() - i - 1) << "]";
+prop = fgGetNode(item.str().c_str());
+if (!prop) {
+SG_LOG(SG_GENERAL, SG_WARN, "item without node: " << item.str());
+continue;
+}
+_entries[prop->getPath()] = e[i];
+}
+menu_index++;
+}
+}
+
+bool
+FGMenuBar::enable_item(const char *path, bool state)
+{
+SGPropertyNode *prop = fgGetNode(path);
+return enable_i
[Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
We discussed it a bit on irc://irc.flightgear.org/flightgear already ... * Vassilii Khachaturov -- Saturday 03 December 2005 02:52: > 1) it's really difficult to fly a helicopter with the yoke, > but one can make good use of the throttle as the collective. > If one wants to fly and use the mouse as the cyclic control, > it's impossible [...] And if not? I someone *wants* to use the yoke for helicopters, too? Then this joystick driver will be/look quite broken and inconsistent with every other js driver. It's a matter of personal preferences, and I would only commit bugfixes (e.g. nasalifying throttle, etc.), additions (more s), or changes on which the original submitter agrees, especially if this is a fgfs core developer (David). It would also be fine if at least a few users of this js agree with the changes. But I won't replace the original submitter's personal preferences with someone else's preferences. The zooming function makes sense, and I like the way how the axes are disabled. But I don't like *that* they are disabled. I'll look away, though, if someone else commits it. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
* Melchior FRANZ -- Saturday 03 December 2005 16:45:
> +union {
> +float f;
> +int i;
> +} v;
Umm ... but is sizeof(float)==sizeof(int) on all supported
platforms? It's not on Atari ST, for example (IIRC). :-/
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Another gcc 4.0.2/SUSE 10.0 problem: engine sounds
* Stefan Seifert -- Saturday 03 December 2005 01:24:
> as discussed already on IRC, there seems to be another gcc 4.0.2/SUSE
> 1.0 problem:
> engine sounds on the 737, Concorde and every other plane that uses
> thrust_lb[0] as base for the engine sound calculation don't work on this
> platform.
It turned indeed out to be yet another one of these ugly aliasing
bugs with gcc 4.0.2 ([1] *AND* [2]!). In fastmath.hxx apparently
reinterpret_cast doesn't work appropriately. Could explain why Alex'
clean patch didn't work. Now the question is: should fgfs work
around a broken gcc release, when there's hope that the next version
will be fixed? Or is it not a bug, but something that will be in
all gcc versions for the next time (I've not found any bug reports
about it yet!). Anyway, attached is a patch that makes the
turbines whine again, and some of us whine less.
m.
[1] 4.0.2 20050901 (prerelease) (SUSE Linux)
[2] 4.0.2 20050808 (prerelease) (Ubuntu 4.0.1-4ubuntu9))
diff -u -p -r1.4 fastmath.hxx
--- fastmath.hxx8 May 2004 12:58:29 - 1.4
+++ fastmath.hxx3 Dec 2005 14:37:33 -
@@ -54,16 +54,18 @@ void fast_BSR(float &x, register unsigne
inline float fast_log2 (float val)
{
-int * const exp_ptr = reinterpret_cast (&val);
-int x = *exp_ptr;
-const intlog_2 = ((x >> 23) & 255) - 128;
-x &= ~(255 << 23);
-x += 127 << 23;
-*exp_ptr = x;
+union {
+float f;
+int i;
+} v;
+v.f = val;
+const int log_2 = ((v.i >> 23) & 255) - 128;
+v.i &= ~(255 << 23);
+v.i += 127 << 23;
-val = ((-1.0f/3) * val + 2) * val - 2.0f/3; // (1)
+v.f = ((-1.0f/3) * v.f + 2) * v.f - 2.0f/3; // (1)
-return (val + log_2);
+return (v.f + log_2);
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Harald JOHNSEN -- Saturday 03 December 2005 13:12: > Now the question are : I guess this is mostly answered in my reply to Christian. People seem to be unaware of the FG_SCENERY path list. This is not a new feature. It exists since at least two years (or something). Only the behavior changed a bit over time. > - where must I put the objects I download from fgdb on my disk fgdb contains only objects, no terrain. So it can be in the default Scenery/ dir (Terrain and/or Objects subdir, although the latter makes more sense :-), but it can also be in any other dir from the FG_SCENERY as long as it comes before the first terrain is found. (e.g. an "OBJECT_BASE 123456.btg" entry in the 123456.stg file.) > - where can I put some other objects I want to add Same as above. Can be a different dir, though. You can use as many path elements in FG_SCENERY/--fg-scenery as you like. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Christian Mayer -- Saturday 03 December 2005 12:35: > Melchior FRANZ schrieb: > > If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ > > does the seperator have to be a double colon ":"? > Or, more precisely, is it a ";" under Windos? A double colon would cause > real trouble under Windos... (imagine FG_SCENERY=D:\Scenery) It uses the OS-specific separator, as it always did. Colon on Unix/Linux, and semicolon on Windows: Unix & OSX: FG_SCENERY=$FG_ROOT/Scenery:$FG_ROOT/WorldScenery Windows: FG_SCENERY=A:\foo\Scenery;B:\bar\Scenery Same for --fg-scenery. I'm using this: FG_SCENERY=$FG_HOME/Scenery:$FG_ROOT/Scenery:$FG_ROOT/WorldScenery |-- 1 --|-- 2 ---|- 3 | (1) contains only a few objects such as hangars in LOXL, or a windsock on the gree hangar in KSFO and a helipad next to it. For this have a file $FG_HOME/Scenery/w130n30/w123n37/942050.stg with only these lines: OBJECT_STATIC helipad.xml -122.37931 37.626 1.45 60 OBJECT_SHARED Models/Airport/windsock.xml -122.37839 37.62622 28.00 0 OBJECT_TAXI_SIGN AAA -122.357357 37.613917 0 150 OBJECT_RUNWAY_SIGN Town -122.357367 37.613927 2 150 No Terrain/ and Objects/ subdirs in $FG_HOME/Scenery for now. $FG_HOME is set to $HOME/.fgfs/ (2) is the default scenery from CVS (3) is scenery for the whole world. This is also my TerraSync target directory. (Most of the scenery here is quite old, though.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Melchior FRANZ -- Friday 02 December 2005 18:44: > I will present a patch after that which restores the > original, pre-Objects&Terrain behavior. Committed. If FG_SCENERY=A:B and both dirs contain a Terrain/ and Objects/ subdir, then FGGlobals::set_fg_scenery() will expanded this to a list [A/Terrain, A/Objects, "", B/Terrain, B/Objects, ""]. The empty sting is inserted as a marker for FGTileEntry so that it can stop scanning this set of Terrain/Objects twins. If one doesn't let FGGlobals::set_fg_scenery expand A/ to A/Terrain and A/Objects, but lists these explicitly: FG_SCENERY=A/Terrain:A/Objects then those are *not* seen as twin dirs. A/Objects will then not be scanned if a terrain tile was found in A/Terrain. That's a feature. Only implicit twins make a group. Hope this wasn't too confusing. It's well tested and seems to work as expected. This does, of course, not generally prevent doubled objects. If a windsock is in both A/Terrain/123456.stg *and* in A/Objects/123456.stg, then both will still be shown. So, if you see doubled windocks in KHAF (like I do), that's not a bug but the consequence of fgdb merging. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Curtis L. Olson -- Friday 02 December 2005 18:09: > Again, it's a shame that original functionality is lost when people come > later and make changes to complex code without fully understanding the > intent. Isn't that one of the reasons why we have flightgear-cvslogs? For code review? Like in any other F/OSS project? > Ok, to summarize, if you can assure everyone that your patch doesn't > change any original behavor (the 'good' original behavior) and is well > tested, then sure go ahead and commit it. OK. Thanks. I will present a patch after that which restores the original, pre-Objects&Terrain behavior. > It appears though that the scenery path semantics and devolved into an > ill understood mess. That's a bit harsh. One feature was added, and another was modified (to the worse). This doesn't make it a mess. I think that the non-set sea tile center is *as* big a "mess", and this was by design. But nothing is set in stone. Everything can be fixed. And if nobody noticed, and nobody cared, then it can't see the tragedy. > We should discuss how we want the pathing to work and make the code do what > we want. Right now it's a bit confusing [...] I know at least FGTileEntry::load() good enough now to not find it confusing. :-) We have to keep in mind that after the change to Terrain/ and Objects/ subdirs we *had* to process further dirs, namely the respective Objects/ directory. Even though we found a scenery file in the Terrain/ dir (which was searched first). Is the following behavior OK? Generate all objects from all FG_SCENERY paths until we found the first OBJECTS_BASE entry (including the other object entries in this *.stg file). Then read the matching Objects/ directory, too. But *then* stop scanning. ? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
* Curtis L. Olson -- Friday 02 December 2005 16:57: > One of the original intentions of the scenery path was to search until > you found something and then stop. This is still the case for terrain.btg.gz files and airports, just as it was before. But objects are always set from all stg files, with or without this patch. The difference is that objects aren't set at center of Earth, especially in sea tiles. > The original intention was that you could have smaller updated areas in > a path ahead of your main scenery and those areas will completely > override stuff that is later in the path. That isn't the case since the Terrain/ and Objects/ dirs were invented. This patch doesn't change this. m. PS: cool 26 kB full-quote! :-> ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Andy Ross -- Friday 02 December 2005 16:36: > This violates the strict aliasing rules that are the default for > gcc 4.x -- I believe it issues a warning to that effect. There's is no warning (using -Wall), and info & man page claim that strict aliasing is turned off by default, even if the optimize option is used. > If you want to type-pun, you need to use a union: Yes. Mathias told me so already, and even sent me a patch in the morning. I'll commit that (if Oliver doesn't object, or anyone else with authority :-). m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] Scenery/tileentry.cxx: new feature: allow objects on sea tiles (& generally don't drop objects)
This patch reshuffles parts of FGTileEntry::load() to allow mere
sea tiles to contain objects (oil rigs, nav-, weather-buoys, stuff,
etc.), and to prevent fgfs from dropping objects listed in *.stg
files that were loaded before the one containing the first
terrain.btg.gz (-> FG_SCENERY).
The current structure is this:
(A) set center to 0/0/0
(B) LOOP {
- check for *.stg files in all FG_SCENERY dirs, and process
them one after the other, executing all entries right away(!);
- if terrain.btg.gz entry is found, load the tile (this sets
center to a meaningful value)
}
(C) if no terrain.btg.gz entry was found in the loop, create a
sea tile and set center accordingly
This has two disadvantages:
1. objects on mere sea tiles will be placed relative to
center 0/0/0, because a meaningful center is only set
afterwards. So none of them will show up in the scenery
(oil-rigs!).
2. also, all objects from *.stg files that were loaded before the
one with the terrain.btg.gz file are dropped. One can work around
that by reordering the paths in FG_SCENERY, but this may not be
obvious for users. It wasn't for me, at least.
The suggested structure is this (see patch):
(A) LOOP {
- go through all *.stg files in all FG_SCENERY paths and collect
data (objects stored in a vector of structures, the
terrain.btg.gz path stored as string)
}
(B) if tile found:
load tile and set center;
else:
create sea tile and set center
(C) LOOP {
- go through the vector of stored objects and place them in
the landscape
}
This way all objects are placed relative to a valid tile center (and
none at the center of Earth. :-)
NOTE that:
- the patch removes RWY_LIGHTS, because this is only a dummy that
doesn't do anything else than writing a log message.
- support for OBJECT_RUNWAY_SIGN and OBJECT_TAXI_SIGN isn't only
kept, I also verified that they do still work. They are crying
for a revival. (see http://www.flightgear.org/Gallery-v0.9.8/
near bottom -- for those who don't remember)
- the storage struct is very simply. Hard-core C++ programmers
might want to see it replaced with a set of inherited classes and
all. That can be done if it buys us anything. Currently it would
be overengineered. IMHO.
- the diff looks a lot uglier than the resulting file! :-]
The patch is valgrind- and EGLL-proof. It works well since a couple
of days.I don't expect any noticable effect on the frame rate.
Please add this to the list of yet to be discussed features for
1.0. Otherwise I'll keep it warm for 1.0.1. ;-)
m.
Index: tileentry.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Scenery/tileentry.cxx,v
retrieving revision 1.47
diff -u -p -r1.47 tileentry.cxx
--- tileentry.cxx 14 Oct 2005 16:25:14 - 1.47
+++ tileentry.cxx 1 Dec 2005 16:13:57 -
@@ -659,18 +659,48 @@ bool FGTileEntry::obj_load( const string
}
+typedef enum {
+OBJECT,
+OBJECT_SHARED,
+OBJECT_STATIC,
+OBJECT_TAXI_SIGN,
+OBJECT_RUNWAY_SIGN
+} object_type;
+
+
+// storage class for deferred object processing in FGTileEntry::load()
+struct Object {
+Object(object_type t, string& token, const SGPath& p, istream& in)
+: type(t), path(p)
+{
+in >> name;
+if (type != OBJECT)
+in >> lon >> lat >> elev >> hdg;
+in >> ::skipeol;
+
+if (type == OBJECT)
+SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name);
+else
+SG_LOG(SG_TERRAIN, SG_INFO, token << " " << name << " lon=" << lon
+<< " lat=" << lat << " elev=" << elev << " hdg=" << hdg);
+}
+object_type type;
+string name;
+SGPath path;
+double lon, lat, elev, hdg;
+};
+
+
void
FGTileEntry::load( const string_list &path_list, bool is_base )
{
bool found_tile_base = false;
-// obj_load() will generate ground lighting for us ...
-ssgVertexArray *light_pts = new ssgVertexArray( 100 );
-
-ssgBranch* new_tile = new ssgBranch;
+SGPath object_base;
+vector objects;
-unsigned int i = 0;
-while ( i < path_list.size() ) {
+// scan and parse all files and store information
+for (int i = 0; i < path_list.size(); i++) {
bool has_base = false;
@@ -682,243 +712,99 @@ FGTileEntry::load( const string_list &pa
SGPath basename = tile_path;
basename.append( index_str );
-// string path = basename.str();
SG_LOG( SG_TERRAIN, SG_INFO, "Loading tile " << basename.str() );
-#define FG_MAX_LIGHTS 1000
// Check for master .stg (scene terra gear) file
SGPath stg_name = basename;
stg_name.concat( ".stg" );
sg_gzifstream in( stg_name.str() );
+if ( !in.is_open() )
+continue;
-if ( in.is_open() ) {
-string token, name;
+
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36: > Perhaps adding a volatile modifier on the tmp pointer > could do the trick (of course doing that disables optimisations). It doesn't. Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp 0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x10,%esp 0x0831081c <_Z16XDR_decode_floatRKj+6>: flds 0xfffc(%ebp) 0x0831081f <_Z16XDR_decode_floatRKj+9>: leave 0x08310820 <_Z16XDR_decode_floatRKj+10>: ret m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Mathias Fröhlich -- Friday 02 December 2005 07:35:
> float
> XDR_decode_float ( const xdr_data_t & f_Val )
> {
> union {
> float f;
> xdr_data_t x;
> } tmp;
> tmp.x = XDR_decode_int32 (f_Val);
> return tmp.f;
> }
This works.
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp
0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x8,%esp
0x0831081c <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax
0x0831081f <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp)
0x08310822 <_Z16XDR_decode_floatRKj+12>: call 0x83107e2
<_Z16XDR_decode_int32RKj>
0x08310827 <_Z16XDR_decode_floatRKj+17>: mov%eax,0xfffc(%ebp)
0x0831082a <_Z16XDR_decode_floatRKj+20>: flds 0xfffc(%ebp)
0x0831082d <_Z16XDR_decode_floatRKj+23>: leave
0x0831082e <_Z16XDR_decode_floatRKj+24>: ret
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Harald JOHNSEN -- Friday 02 December 2005 11:36:
> Melchior FRANZ wrote:
> > (why does it not call _Z16XDR_decode_int32RKj? "Optimized" away?):
> decode_int32 is a nop on a x86 anyway
Huh? Looks like a nop for big-endian:
int32_t
XDR_decode_int32 ( const xdr_data_t & n_Val )
{
return (static_cast (SWAP32(n_Val)));
}
and
#define SWAP32(arg) sgIsLittleEndian() ? sg_bswap_32(arg) : arg
> Perhaps adding a volatile modifier on the tmp pointer
> could do the trick (of course doing that disables optimisations).
That wouldn't matter.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior FRANZ -- Friday 02 December 2005 09:57: > * Alex Romosan -- Friday 02 December 2005 08:16: > > please apply the attached patch which uses static_cast: No, this patch doesn't work. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: > please apply the attached patch which uses static_cast: Haven't yet tested, but it looks good. At least it calls _Z16XDR_decode_int32RKj. :-) (gdb) disass XDR_decode_float Dump of assembler code for function _Z16XDR_decode_floatRKj: 0x0831086e <_Z16XDR_decode_floatRKj+0>: push %ebp 0x0831086f <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp 0x08310871 <_Z16XDR_decode_floatRKj+3>: sub$0x4,%esp 0x08310874 <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax 0x08310877 <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp) 0x0831087a <_Z16XDR_decode_floatRKj+12>: call 0x831083a <_Z16XDR_decode_int32RKj> 0x0831087f <_Z16XDR_decode_floatRKj+17>: push %eax 0x08310880 <_Z16XDR_decode_floatRKj+18>: fildl (%esp) 0x08310883 <_Z16XDR_decode_floatRKj+21>: add$0x4,%esp 0x08310886 <_Z16XDR_decode_floatRKj+24>: leave 0x08310887 <_Z16XDR_decode_floatRKj+25>: ret Will test and apply later. Thanks! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Alex Romosan -- Friday 02 December 2005 08:16: > Mathias Fröhlich <> writes: > > Please use this one. And I believe, without looking into the code, > > that there are likely more of them ... I'll try all solutions later today. But I don't understand why any of them should be necessary. The code may not be the most elegant, but it looks right to me. Do I really have to tell the optimizer not to translate it wrongly? > please apply the attached patch which uses static_cast: Looks nice. If it works (and Oliver doesn't have other plans) I'll commit that. But even if it works, why does the current code *not* work? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Curtis L. Olson -- Friday 02 December 2005 02:55: > Here you are just returning the contents of a memory location, not the > pointer itself (aka a value). I know. That's why I had written > > * Melchior FRANZ -- Friday 02 December 2005 01:43: > > > But ... we weren't really returning the address of an auto var. I was just overwhelmed by the joy. And the not so early hour did the rest. 02:00 here in Europe then. Even later now ... -/ > So this should be perfectly safe. My bet is that the value didn't > get decoded properly, but whatever got decoded > incorrectly was returned correctly. XDR_decode_int32() seemed OK, judging by the assembler code. It's a simple byte swapper and I couldn't imagine that the compiler wouldn't get it. But, of course, a compiler bug could also be there. > I'd check the value if (*tmp) before it get's returned to see if > it looks like what you think it should. Yes. I'll do that. It works now, but the fix doesn't make sense. And depending on silly hacks isn't a pleasure. > I'll bail out here before I get to the x86 assembler portion of your > message. :-) I was fluent in 68000 assembler. But I always detested little endianness and couldn't imagine to learn x86 assembler. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior FRANZ -- Friday 02 December 2005 01:43:
> But ... we weren't really returning the address of an auto var.
Is it a gcc 4.0.2 (SuSE 10.0) compiler bug? tiny_xdr.cxx contains
this function;
float
XDR_decode_float ( const xdr_data_t & f_Val )
{
float* tmp;
xdr_data_t dummy;
dummy = XDR_decode_int32 (f_Val);
tmp = (float*) &dummy;
return (*tmp);
}
And it turned out that when compiled with gcc 4.0.2 the return
value wasn't safe. When called three times in a row with different
values, we would get three times the same result. None of those
correct. This placed MP aircraft somewhere around the middle
of our Earth. For those understanding x86 assembler, here is
the resulting code (why does it not call _Z16XDR_decode_int32RKj?
"Optimized" away?):
non-static "dummy" (-O2) --> doesn't work
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp
0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x10,%esp
0x0831081c <_Z16XDR_decode_floatRKj+6>: flds 0xfffc(%ebp)
0x0831081f <_Z16XDR_decode_floatRKj+9>: leave
0x08310820 <_Z16XDR_decode_floatRKj+10>: ret
End of assembler dump.
The following was compiled without optimization. The resulting code
works.
non-static "dummy" (-O0) --> works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x083be33a <_Z16XDR_decode_floatRKj+0>: push %ebp
0x083be33b <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x083be33d <_Z16XDR_decode_floatRKj+3>: sub$0x18,%esp
0x083be340 <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax
0x083be343 <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp)
0x083be346 <_Z16XDR_decode_floatRKj+12>: call 0x83be1b4
<_Z16XDR_decode_int32RKj>
0x083be34b <_Z16XDR_decode_floatRKj+17>: mov%eax,0xfff8(%ebp)
0x083be34e <_Z16XDR_decode_floatRKj+20>: lea0xfff8(%ebp),%eax
0x083be351 <_Z16XDR_decode_floatRKj+23>: mov%eax,0xfffc(%ebp)
0x083be354 <_Z16XDR_decode_floatRKj+26>: mov0xfffc(%ebp),%eax
0x083be357 <_Z16XDR_decode_floatRKj+29>: mov(%eax),%eax
0x083be359 <_Z16XDR_decode_floatRKj+31>: mov%eax,0xffec(%ebp)
0x083be35c <_Z16XDR_decode_floatRKj+34>: flds 0xffec(%ebp)
0x083be35f <_Z16XDR_decode_floatRKj+37>: leave
0x083be360 <_Z16XDR_decode_floatRKj+38>: ret
End of assembler dump.
and this hack (committed to cvs) works with and without optimization.
Making "dummy" static shouldn't be necessary, but
static "dummy"--> works
(gdb) disass XDR_decode_float
Dump of assembler code for function _Z16XDR_decode_floatRKj:
0x08310816 <_Z16XDR_decode_floatRKj+0>: push %ebp
0x08310817 <_Z16XDR_decode_floatRKj+1>: mov%esp,%ebp
0x08310819 <_Z16XDR_decode_floatRKj+3>: sub$0x4,%esp
0x0831081c <_Z16XDR_decode_floatRKj+6>: mov0x8(%ebp),%eax
0x0831081f <_Z16XDR_decode_floatRKj+9>: mov%eax,(%esp)
0x08310822 <_Z16XDR_decode_floatRKj+12>: call 0x83107e2
<_Z16XDR_decode_int32RKj>
0x08310827 <_Z16XDR_decode_floatRKj+17>: mov%eax,0x8560e00
0x0831082c <_Z16XDR_decode_floatRKj+22>: flds 0x8560e00
0x08310832 <_Z16XDR_decode_floatRKj+28>: leave
0x08310833 <_Z16XDR_decode_floatRKj+29>: ret
End of assembler dump.
clueless
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
* Melchior Franz -- Friday 02 December 2005 01:10: > Modified Files: > tiny_xdr.cxx > Log Message: > returning addresses of auto vars is *dangerous* [...] But ... we weren't really returning the address of an auto var. Making dummy "static" fixes the problem, but the reason must be another one. gcc 4.0.2 bug? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Autopilot
* Roy Vegard Ovesen -- Wednesday 30 November 2005 18:16: > Is this possible, Melchior, to disable the autopilot menu entry just for the > C172? Not currently, AFAIK. Wouldn't be hard to add. One would probably do that as an fgcommand() that enables/disables menu entries. Generally, making such decisions based on the aircraft is, of course, possible. Could be added to the list of admitted features for 1.0, next to landing lights ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Curtis L. Olson -- Wednesday 30 November 2005 15:19: > You may want to attack this in small steps ... for instance start out > with just getting save/load of aircraft position working. As demonstrated before [1], this is quite easy to do even with Nasal[2]. The only thing that needs to be implemented in fgfs is a way to tell it where to store the files. Something like FG_HOME/--fg-home. Paul was already working on that for exactly this purpose[3], but somehow he felt discouraged and stopped (IIRC). m. [1] http://mail.flightgear.org/pipermail/flightgear-users/2005-November/012871.html [2] http://members.aon.at/mfranz/flightgear/ac_state.nas [3] http://mail.flightgear.org/pipermail/flightgear-devel/2004-December/032641.html ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Curtis L. Olson -- Wednesday 30 November 2005 14:01: > Melchior FRANZ wrote: > > There was no discussion about this topic on flightgear-devel before > > this order was announced, and every discussion after that was passively > > suppressed by ignoring valid arguments. [...] > I don't want to passively supress your points, Good. I think that our code is not ready for 1.0, as long as it doesn't implement (A) landing/taxi lights and (B) saving GUI states. (There are others, but these two are the most important.) You think that having release 1.0 *soon* is more important? Is this what we'll see in the ChangeLog for 1.0? Two points? * fixed a few bugs that should really have been fixed in 0.9.9 * JSBSim update; in the *best* case, everything works like before and users won't notice any difference. This won't make headlines, at least no positive ones. Why wasting the 1.0 number and the special attention for a bugfix release that should really be called 0.9.9a or 0.9.9.1? > By giving certain developers cvs write access, [...] ?? I'm trying to discuss the 1.0 release policy that was made off-list and ignored any developer input so far (a.k.a. XFree86 development style or "we want your code, not your opinion"). The cvs access policy has nothing to do with it. To make that clear: I fully respect your leadership! If you say that 1.0 will be released with no new features "because I, Curt, say so", then it's OK. Then we know at least who made the decision and on which technical arguments it's based on. And we know how much time it's worth to spend for this release. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added
* Erik Hofman -- Wednesday 30 November 2005 09:56: > How could I tell others to postpone their contribution until after the > release of FlightGear 1.0 [...] Good question, indeed! How could you? There was no discussion about this topic on flightgear-devel before this order was announced, and every discussion after that was passively suppressed by ignoring valid arguments. How was this decision made and by whom? Is FlightGear no longer "cooperative" (as in "working together")? Are we minor developers now working for an elite that makes important decisions off-list? This decisions making process sucks! This is not to say that KLN89 needed to be in 1.0.0, but other features urgently need to, unless 1.0.0 is meant to be a joke. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS and PLIB
* Jon Berndt -- Sunday 27 November 2005 19:26: > Is there some kind of problem going on with downloading PLIB from CVS? Notoriously, but not necessary in this case. :-) > Seems there's been a "partial outage" in progress on SF.net for > weeks. I can't get plib from CVS, though ... I have just tried and updating worked, just like yesterday. Check your cvs root: $ cat CVS/Root :pserver:[EMAIL PROTECTED]:/cvsroot/plib Sometimes the funny guys at sf.net change it. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Airport of Hell?
* Mathias Fröhlich -- Saturday 26 November 2005 20:59: > > On Samstag 26 November 2005 19:47, Joacim Persson wrote: > > > fgfs --airport=EGLL --aircraft=ufo > So, since I do not see that problem: > Do you have any modifications in your local tree? Doesn't work for me either. This works ... $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0134 and this doesn't: $ fgfs --aircraft=ufo --airport=EGLL --offset-distance=0.0133 only grey soup. And this point seems to be exactly the airport boundary. I'm just not aware of any recent changes that could have this effect. :-| m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Aircraft Download/Install App
* AJ MacLeod -- Saturday 26 November 2005 15:50: > This hypothetical application sounds very much to me like an extension to the > existing fgrun... ... and we could call it ... *pause* ... fgadmin! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* Vassilii Khachaturov -- Saturday 26 November 2005 11:02:
> > But ... classes without copy/assignment operator aren't copied
> > byte-by-byte, but member-by-member[1].
> It's a pity I am at home & sick, and without the book. I don't know
> what is written in the section you refer to.
There's written what I said: that classes without copy/assignment
operator aren't copied byte-by-byte, but member-by-member. I'm
not going to cite the whole book. You have to trust me. :-P
> Therefore the only
> thing I can do is try to code it and see what's happening. I tried to
> amend the snippet with a 3rd case, which crashes on my machine,
No, it doesn't "crash your machine". It calls std::unexpected()
because you throw an exception that you *explicitly* disallowed.
That's a feature! :-)
> What do you think?
I think that I should debug fgfs/sg, not your code snippets,
but anyway:
> void foo(int i) throw(exception&)
Here you say that only class "exception" and its derivatives are
allowed.
> struct EE {
> E e;
> EE(const char* s) : e(s) { cout << "EE::EE(" << s << ")" << endl;}
> virtual ~EE() throw() { cout << "EE::~EE(" << e._msg << ")" << endl;}
> };
But you don't make EE a derivative of "exception":
struct EE : public exception { ...
m.
PS: FlightGear/SimGear doesn't use "Exception Specifications", so the
bug in your test program can't really happen.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* Vassilii Khachaturov -- Friday 25 November 2005 22:57: > The following are still in > > * the exception classes were lacking the copy ctors and assignment > > operators, but the default ones for them were unusable as the string > > instance members are not suitable for byte-by-byte copying! But ... classes without copy/assignment operator aren't copied byte-by-byte, but member-by-member[1]. So, for string members the string copy constructor is used. Again, the code looks right to me as it is. m. [0] Bjarne Stroustrup, "The C++ Programming Language", 2nd edition, p. 582, "r.12.8 Copying Class Objects" ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* Vassilii Khachaturov -- Friday 25 November 2005 15:11: > * whenever an exception object was created on a stack and then thrown > (thus causing the dtor for that object to fire!), it was replaced > with a STATIC exception The whole thing looks like a solution desperately searching for a problem. The reasoning for this patch contradicts Stroustrup, who has several examples of what we are doing in "The C++ programming language". Maybe it's only because I'm using an older copy (2nd ed.), but he writes (p. 602, "r.15.2 Throwing an Exception"): "A throw-expression initializes a temporary object of the static type of the operand of throw and uses that temporary to initialize the appropriately-typed variable named in the handler." The throw expression cares for the thrown class to be available until it reached the handler. No need to spread ugly static variables everywhere. Our code looks right for me as it is. But then again, I'm a relative C++ newbie ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: RenderTexture bug
* Enrique Vaamonde -- Thursday 24 November 2005 09:20: > I have tried to compile FlightGear using the TestRenderTexture.cpp in > the cvs but am unable to compile it, [...]: I had to make this change first: diff -u -p -U0 -r1.2 TestRenderTexture.cpp --- TestRenderTexture.cpp 29 Jan 2005 11:44:01 - 1.2 +++ TestRenderTexture.cpp 24 Nov 2005 08:32:18 - @@ -308 +308 @@ void _Display() -int main() +int main(int argc, char *argv[]) @@ -309,0 +310,2 @@ int main() +int argn = argc; +glutInit(&argn, argv); And then compiled with this Makefile ($ make -f Makefile.rt): all: TestRenderTexture TestRenderTexture: TestRenderTexture.o g++ -g -o TestRenderTexture TestRenderTexture.o -lstdc++ -lGL -lglut -lsgscreen -lsgdebug TestRenderTexture.o: TestRenderTexture.cpp g++ -g -c TestRenderTexture.cpp When I run the program, I get lots of "OpenGL ERROR: invalid value: RT Update", but apart from that it works. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: publicity
* Danie Heath -- Tuesday 22 November 2005 10:09: > I am the owner of Aircraft.co.za, and I'm willing to do a > complete review of FlightGear on my site ... > > If you have any specific features/aircraft/sceneries I should > focus on, please tell me so I can include it in the review I don't speak for FlightGear, but an enthusiastic review can't hurt. ;-) I don't know if there's something special to focus. It probably depends on whether your readers have ever heard of fgfs and if it's only a version review, or if you present fgfs for the first time. Just pick from the web page what interests your readers most: http://www.flightgear.org/version.html http://www.flightgear.org/features.html http://www.flightgear.org/Projects/ Things that might be noteworthy are: source code available, free (as in beer & speech), extremely configurable, numerous possibilities to interface to fgfs (built-in telnet & http server), property system, master slave setup, used a lot in academic & industrial context, detailed & worldwide scenery, ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: material animation...
* syd -- Wednesday 23 November 2005 02:31: > If I understand you correctly , I need to list all objects that > the animation applies to ? I was doing this before , (without > ) and everything worked fine ... but in the documentation > it says using an object and global affects all objects that share > that material, that is was a faster and preferred method. You make it sound as if there's a contradiction. Yes, is faster and preferred, but it only works for identical material. Two materials (ssgSimpleState) with different textures are different. So you use the slightly slower way: listing all objects in s. It's slower because it has to manipulate several ssgSimpleStates rather than just one, but I wouldn't overrate that. It's what the p51d and others do/did all the time. "material" animations don't waste any time if there is no change to be made. Just a few number comparisons. Not that they waste any time otherwise ... :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: tiny ch47 patch
* Joacim Persson -- Tuesday 22 November 2005 16:19: > This must be one of the lesser flewn models in FG. Two years has passed > since the last patch, and noone has noticed that Erik forgot (tsk tsk) that > there are /two/ rotors on the Chinook. Could well have been my patch, not Erik's. All helicopters other than the bo105 are unmaintained, broken, and have no model. These are models that should be moved to the Attic/, or at least be removed from the download page. They serve no other purpose than to fool & annoy users, and to make fgfs look bad. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] CVS: data/Aircraft/b1900d ...
* Syd Adams: [...] > Having some trouble with material animation ... > it appears global material changes only affect objects that share the same > texture file doesn't only look at what ac3d files define in a "MATERIAL" entry, but at all material parameters, including the texture. It affects all objects that share the same ssgSimpleState. Every single difference requires us to clone the ssgSimpleState node, and then the connection between such objects is lost. You just have to do what you do in all other animations then: list all objects in tags. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Buchanan, Stuart -- Monday 21 November 2005 15:29: > I thought I was doing quite well - avoiding top-posting, snipping etc. My > sincere apologies that you had to be part of my learning process. Hey, if I search long enough, I always find something. :-} > [...] offence by missing out on some netiquette. That's not exactly netiquette. That's rather protection from criminals. > Even better would be a filter on the mailing list software to parse out > email addresses in message bodies. Well, it does. But it only replaces @ with " at ". And I would be very surprised if the harvesters wouldn't be "clever" enough to detect as address [EMAIL PROTECTED] But I don't want yet another thread about this, so for me it's EOT[1]. :-) m. [1] End Of (this branch of the) Thread ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Buchanan, Stuart -- Monday 21 November 2005 13:39: > --- Melchior FRANZ <... @aon.at> wrote: Oh, and thanks for posting my email address. I had already feared that I wouldn't get enough spam in the next time. But thanks to people like you this is completely unjustified. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Buchanan, Stuart -- Monday 21 November 2005 13:39: > Ah, I didn't realize I needed a patch for it. You mentioned that the patch > was from IRC. Do you have a record of it I could plunder to patch my code > tree? http://people.freebsd.org/~jylefort/flightgear-aircraft-lights.diff [8 kB] But it has one major bug that will probably be very easy to fix for a few developers. (A bit harder for me, so I haven't tried. :-) The light doesn't follow the aircraft as it should. The problem is described in the patch. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Vassilii Khachaturov -- Monday 21 November 2005 12:27: > Do you have a set of nice sliders to adjust the glLight parameters > on the light object in real time, like the ones you've built for > the bo105 exteriour adjustment? Not yet, but I'll write one. And for the record: I didn't do the material dialog for the bo105, but for the material *animation*. The bo105 just happens to be the only model that has it permanently available, so that others can see how to use it. It's basically a copy&paste job then. The material dialog is primarily a development tool, and I hope that others are actually using it, even if it is removed before submission. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Buchanan, Stuart -- Monday 21 November 2005 10:49: > do I just need to add some "light" objects to my aircraft model and some > nasal code to switch them on? With this patch, yes. You don't even need Nasal code. Just a light definition block in your model xml file. It gets its on/off state from /controls/lighting/taxi-light. > I noticed that on one of your FG pages you mentioned that OpenGL can have > a maximum of 8 light sources. A minimum of 8. The 7676 driver for my GF 440MX defines GL_MAX_LIGHTS as 32. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Landing Lights
* Vassilii Khachaturov -- Monday 21 November 2005 11:39: > Perhaps the non-local models should have a luminous fake light > like the other lights in fg for this reason. Yes. Lights could also be assigned after priorities. You own machine's taxi lights have highest priority, then come landing lights, then taxi lights of AI, or something. If there's no AI around, you can have them all ... rotating beacons, flashers. May look nice if your flashers actually lighten the tarmac. > When landing (I'm talking about light planes here), the landing lights > are good for barely illuminate several tens of meters in front of you. > Pilots are trained to land on lighted runways without the use of > the landing lights (by using peripheral vision and the runway perimeter > lighting to judge the depth). May be. But once you have landed you are stuck on the runway without taxi lights. There's no way to leave the runway without bumping into parked aircraft, towers, windsocks. Releasing a version 1.0.0 in such a state is a bad idea. Here's a screenshot of decadix' lights patch in action: the lights aren't fully adjusted yet it seems ... http://members.aon.at/mfranz/taxi-lights.jpg [40 kB] m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
* Melchior FRANZ -- Saturday 19 November 2005 14:11: > One new feature *must* go in. Otherwise the 1.0.0 release number is > IMHO not justified: > > * landing lights ... to make fgfs actually usable at night > * aircraft switchable at runtime And here's another one: * save gui configuration: sound, shadows, etc. should all be saved into a configuration file that is loaded at each startup; Telling users to find(!) and edit XML stuff is very pre-1.0. (Could be done in gui.nas for now, where it's unlikely to cause stability problems.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FG 0.9.9 shadows and stuff
* Rodrigo Flores -- Saturday 19 November 2005 16:18: > Finally, the old fonts in the FG 0.9.8 format are still there, couldn´t > see the fonts showed in the Concorde screenshot. You have to switch the GUI style with Shift-F10, or put this into your ~/.fgfsrc or use it on the command line or in fgrun: --prop:sim/current-gui=1 m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
I also hoped that a few Nasal improvements could be committed, such as file I/O. That's hardly dangerous for overall fgfs stability, and would allow to implement some nice features in Nasal scripts. (Not that this had to be in 1.0.0, but I wouldn't like to wait some months for it. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Release of v0.9.9 source code
* Erik Hofman -- Friday 18 November 2005 18:36: > After this release we'll only accept bug-fixes to the code, except for > the new JSBSim version. Any major code changes that are not intended to > fix one or more bugs will have to wait. One new feature *must* go in. Otherwise the 1.0.0 release number is IMHO not justified: * landing lights Otherwise we'd have to admit that FlightGear 1.0.0 is a daylight-only simulator. A patch for landing lights is floating around on IRC. (Haven't tested it yet.) One new feature that I always thought should be possible in 1.0.0: * aircraft switchable at runtime This isn't something that we need, but something that every other simulator is capable of, and users expect it. Also it would be a good sign for clean subsystem design. And finally, this is my TODO "list": * try to get rid of a few more hardcoded dialogs, or at least make them accept gui colors And if none of this is possible, then I'm afraid I don't have a TODO list and this will be the most boring release cycle ever. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
* Dave Culp -- Thursday 17 November 2005 18:37: > OK, but it still looks odd. BTW, very nice screenshots. The problem is that the prop disk would also look odd. This would exactly look like a screenshot from a simulator, while I wanted to make it look as much as possible like a photo. Just to show off how (almost) photorealistic we are already. When you take a real photo, you'd probably see a propeller with some 'smearing'. But neither a propeller (like I have) nor a disk (like you'd prefer). Anyway: I think I chose the less odd variant. ;-) > If I may I'd like to include two screenshots showing FG capabilities > that are also missing from the website. I had hoped that this thread would grow and offer a whole set of nice screenshots. :-) > http://home.comcast.net/~davidculp2/A6_F8refuel.jpeg This looks very good. I also wanted to show the Crusader in one shot. But now that it has been withdrawn from CVS (with very questionable arguments), I don't think it should be on screenshots on flightgear.org. But well, at least it's another great example of what people could do with fgfs. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [0.9.9] screenshots for flightgear.org
* Dave Culp -- Thursday 17 November 2005 17:36: > On Thursday 17 November 2005 09:45 am, Melchior FRANZ wrote: > > Here are four screenshot offerings for the FlightGear page. > > ... > > http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB] > > Well, *that's* a fine time for the engine to quit :) Nowadays film material is quite sensitive and shutters are quick. IOW: This was intentional. :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [0.9.9] screenshots for flightgear.org
Here are four screenshot offerings for the FlightGear page. All of the shots show new features. I have the original ppm files in case jpeg artifacts are a problem. http://members.aon.at/mfranz/concorde-gui.jpg [130 kB] http://members.aon.at/mfranz/seafire-nimitz.jpg [70 kB] http://members.aon.at/mfranz/clouds-winter-bo105.jpg [182 kB] http://members.aon.at/mfranz/lightning-rain-b1900d.jpg [83 kB] I don't mind if you (Curt) don't use them. But we should *really* put new ones up before 0.9.9 is released. All people who see the release note will check the HP and would be disappointed to see only old screenshots. That leaves a bad taste before they even tried fgfs. Even worse: reviewers will have the same experience! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: terrain texture question
* Ivo -- Thursday 17 November 2005 04:31: > On Thursday 17 November 2005 01:50, Ampere K. Hardraade wrote: > > Speaking of snow: is there anything about snow accumlation in METAR data? > > I'm just curious. > > Well, there's this: > > Format: SNINCR [i/g] But that's not standard METAR, but only remarks (RMK) used in a few countries. Currently only stock METAR is implemented in fgfs. The only snow related parameters that we currently parse is snow precipitation and snow on runways. If there's even snow on the runways, you can take for granted that there's snow everywhere, I'd say. But even runway data groups aren't that common in METAR reports. Parsing of relevant RMK data can easily be added if we need it (lightning frequency, etc.) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: terrain texture question
* Ampere K. Hardraade -- Thursday 17 November 2005 01:50:
> On November 16, 2005 05:37 pm, Melchior FRANZ wrote:
> > * Josh Babcock -- Wednesday 16 November 2005 23:25:
> > > I considered using a Nasal script, but I don't know how the
> > > script would know when the winter textures are being used.
> >
> > if (getprop("/sim/startup/season") == "winter") { ?? }
> I believe you would need more checkings. We don't have snow all the time in
> winter.
He didn't ask when we have snow in winter, but when fgfs uses
winter textures.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: terrain texture question
* Josh Babcock -- Wednesday 16 November 2005 23:25:
> I considered using a Nasal script, but I don't know how the
> script would know when the winter textures are being used.
if (getprop("/sim/startup/season") == "winter") { ?? }
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: unhandled write
* Wendell Turner -- Wednesday 16 November 2005 04:16: > However, with this evening's CVS, with that argument, I > get this: > WARNING: Network: 17: unhandled write > Bus error > and fgfs halts. [...] > plib, simgear, fgfs, data: cvs updated as of 15.nov.05 10pm ET plib CVS/HEAD has broken networking code. Revert the last changes in net/netSocket.h and net/netSocket.cxx and try again! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Melchior FRANZ -- Monday 14 November 2005 22:29: > The strange thing is, that the return value that triggers assert() > is 35, or EAGAIN (Linux). This makes no sense. It's neither described > on the pthread_join manpage, nor is it used in any implementation that > I found on the net. BS! I've no idea where I looked that up. 35 is EDEADLK (deadlock: "Resource deadlock would occur"). Reason according to "man pthread_join": EDEADLK The th argument refers to the calling thread. So this code is trying to join itself? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Melchior FRANZ -- Monday 14 November 2005 22:29: > $ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1 > --log-level=warn I forgot --enable-real-weather-fetch. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
Unfortunately, reverting the recent changes (that caused the thread to be created with "detached" state) wasn't enough to fix the problem. The strange thing is, that the return value that triggers assert() is 35, or EAGAIN (Linux). This makes no sense. It's neither described on the pthread_join manpage, nor is it used in any implementation that I found on the net. Also, if I take it literally and try again in an endless loop, I get endless 35 codes. Maybe I've got a broken libpthread or something. Could someone try to reproduce it? $ fgfs --aircraft=ufo --prop:/environment/params/metar-max-age-min=1 --log-level=warn Then fly to another airport, say KOAK and wait. After one minute fgfs starts to fetch METAR reports for KOAK, but they are most likely older than one minute, so it fetches the next, and next, until it throws an exception after ten failed attempts. And this causes an abortion here: Error fetching live weather data: More than 10 stale METAR messages in a row. Stop fetching data permanently. fgfs: /usr/local/include/simgear/threads/SGThread.hxx:150: void \ SGThread::join(): Assertion `status == 0' failed. /home/m/bin/fgfs: line 239: 18187 Aborted (core dumped) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Erik Hofman -- Monday 14 November 2005 18:47: > If it's causing any troubles I would remove the first three lined of > SGThread::start() since we've done without it for many years. It is causing troubles: the pthread_join manpage says: The joined thread th must be in the joinable state: it must not have been detached using pthread_detach(3) or the PTHREAD_CREATE_DETACHED attribute to pthread_create(3). And environment_ctrl.cxx *is* trying to join such an unjoinable thread, and makes fgfs abort. Fortunately, I'm quite clueless about threads and don't have to decide what to do. :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Oliver C. -- Monday 14 November 2005 18:46: [/usr/local/games/FlightGear or /opt/flightgear] > Seriously, i can live with both directories. /opt/flightgear is fine too. Both are wrong, according to the FHS, and to common sense. The right path is /usr/local/share/ ... and guess what? It's already the default. So, nothing to see here -- move along. (Data sharable across platforms belong into a share/ directory -- /usr/share or /usr/local/share, depending on who installs it. There's not much room for personal preferences here. FlightGear isn't only used on "home computers". :-) But before the next suggests to install in /etc/cool/games/ I better leave this thread. :-> m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
* Harald JOHNSEN -- Saturday 12 November 2005 17:09: > Melchior FRANZ wrote: > > I've just implemented the check for stale METAR reports (to stop > > fetching after 10 stale reports). This triggers an assert in > > SGThread: > It's perhaps because of the PTHREAD_CREATE_DETACHED attribute of the thread. Yes, that's very likely the case, according to the man-pages. So, how should the fix look like? - do not create the thread with PTHREAD_CREATE_DETACHED, or - do not try to join threads m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 16:54: > This is a hopeless conversation because everyone wants to do it > different and there are so many possibilities. We are talking about different things. You talk about the organization of source and data in your home directory. I talk about correct installation of fgfs on a multiuser system, with system wide FG_ROOT. Of course, FG_ROOT is not in a user's home dir then. And, of course, it doesn't contain the source. The source is in my home directory, is not accessible by other users, and does neither follow the organization that I described in the thread, nor what you consider preferred. Also, I wouldn't want to discuss the organization of my home dir in the fgfs documentation. That's secret! :-] m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 16:34: > Melchior FRANZ wrote: > >This dir doesn't exist. There's no such thing as $FG_ROOT/data/. > Of course there is. :-) Sheesh. I resign. :-} > $FG_ROOT/source/ > $FG_ROOT/data/ > $FG_ROOT/data/Aircraft/ > $FG_ROOT/data/Scenery/ > > This is the prefered structure ... Not by me. Sourcecode doesn't really belong into /usr/local/share/, and even less into the shared FlightGear data. But you are the chief. And I keep my installation sane. :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Buchanan, Stuart -- Monday 14 November 2005 16:06: > Am I correct in thinking that someone using terrasync should have their > terrasync data in a different directory from their directly-downloaded > 10x10 scenery? No. On the contrary. > If so, is the convention to name the directories as follows: > > $FG_ROOT/data/Scenery - standard SF bay scenery included in base package This dir doesn't exist. There's no such thing as $FG_ROOT/data/. > $FG_ROOT/Scenery - scenery downloaded in 10x10 chunks That's the "official" scenery directory, containing the bay area, that is: a subset of w130n30. But installing additional scenery there is ugly, if possible at all. Not only do normal users not necessarily have write permission there, it's also always a bad idea to mix "official" data (from CVS or fgfs packages) with extra data. You'd constantly get cvs merge conflicts and cvs updating would be slower. Upgrading would become more difficult than it had to. > $FG_ROOT/WorldScenery - scenery downloaded by terrasync > or is WorldScenery just a different convention for $FG_ROOT/Scenery? No. It's no "convention" at all. Just a possible place to put additional scenery. You would then set your FG_SCENERY like this: export FG_SCENERY=$FG_ROOT/Scenery:$FG_ROOT/WorldScenery This would always take the base package terrain where it's available, and locally added scenery (terrasync or other downloaded archives) else. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Curtis L. Olson -- Monday 14 November 2005 15:12: > Let's stick with .../.../Scenery/[Terrain|Objects] on all platforms > please. Individuals are welcome to call it whatever they want on their > system and use the --fg-scenery= option to point to their favoritely > named directory. Maybe I missed something, but as far as I've understood this thread is not about renaming $FG_ROOT/Scenery/. It's only about whether to suggest a standard in the user documentation for where to install additional scenery, especially when using terrasync. Dumping terrasync fetched data into $FG_ROOT/Scenery/ is a Really Bad Idea[TM]. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Getting Started Guide - Terrain/Objects
* Vassilii Khachaturov -- Monday 14 November 2005 12:50: > http://members.aon.at/mfranz/flightgear/flightgear-howto.html > > I'd only suggest to have the world scenery under smth like > /var/share/FlightGear/WorldScenery > (maybe share/games) rather than in the FG_ROOT, to make it > more up-to-date with the current FHS. Let me clear this up: the fgfs data package is in a defined place: $FG_ROOT. Therefore it's only logical to make other fgfs ressources like world scenery available under $FG_ROOT(/WorldScenery/?). That way different utilities can easily access them. Of course it's up to the admin if $FG_ROOT/WorldScenery/ is a real dir or just a link to /var/share/FlightGear or elsewhere. If the admin maintains the data and (not so) regularly uploads a whole set, then this will be a regular dir. If he appoints a "FlightGear admin", then this will probably be a regular dir owned by that admin. And if he grants users the right to use terrasync, it will be a link to /var/share/FlightGear/WorldScenery/, or elsewhere. (Of course, regular users won't be allowed to write to /usr/local.) All IMHO, of course :-) m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: OT: FYI, mac os x developers,
* Martin Spott -- Saturday 12 November 2005 21:33: > You know as good as I do that by common practice encoded emails don't > belong into mailing lists - Sure, just like HTML, top-posting, full-quoting, Yet it happens. I tell people once to follow the rules, but if they don't and don't have anything relevant to say, either, they simply end up in my killfile. I'm not overly worried to miss an important message. And as long as even core developers send top-posted & fullquoted messages, it's hard to throw stones anyway. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: OT: FYI, mac os x developers,
* Curtis L. Olson -- Saturday 12 November 2005 21:03: > Hey, what's wrong with "ed /var/mail/curt" ... Hey, and what's wrong with "mimencode -u" and "recode utf8:latin1"? As I said: it would be nicer in ASCII, but base64 isn't an offense, unlike HTML, fullquoting, topposting, which are the real annoyances on the net. :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: OT: FYI, mac os x developers,
* Martin Spott -- Saturday 12 November 2005 20:43: > > Z2h0Z2Vhci1kZXZlbAo+IDJmNTg1ZWVlYTAyZTJjNzlkN2IxZDhjNDk2M2JhZTJkCj4KCgoKLS0K > > PEFydGh1ci8+Ci0gaHR0cDovL3NvdXJjZWZvcmdlLm5ldC91c2Vycy9hcnRvb3JvLwotIGh0dHA6 > > Ly9hcnRvb3JvLmJsb2dzcG90LmNvbQo= > > So, why are you posting this crap ? Please stop it, This is very standard base64 encoding. Every semi-decent mailer should be able to display this. Of course, it would be better in readable ASCII, but I wouldn't say it's crap. Your mailer *is* crap! :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Runtime error 0.9.9 on Debian/Testing
* Ampere K. Hardraade -- Saturday 12 November 2005 19:31: > You can get SDL and use the --enable-sdl flag when running configure for > FlightGear. Which also fixes repeatable keys. freeglut is neither compatible with SDL nor with legacy glut. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: pre3 bugs
* Stewart Andreason -- Saturday 12 November 2005 18:00: > 1. when running flightgear, press [ESC] , then [TAB] (intending to move > the cursor to the cancel button) Cycling widget focus with TAB is not implemented, and never was. > instead the instrument settings dialog comes up. ok. But: I can not press > the Close button or click in the text fields, instead I can only click on > the exit window underneath. > It looks like the "who's on top" also occurs elsewhere, but not the "can't > click close", or press [ESC]. That's because the exit dialog ($FG_ROOT/gui/dialogs/exit.xml) is "modal", This means that it blocks the gui and (because it's derived from a different plib dialog than almost all other dialogs) doesn't allow accelerator keys. > Neither can I drag the instrument window away from covering the exit window. You can set "true" in said file to false. Then it's at least movable, and the other dialog can be moved in front. Maybe this should be done in CVS? This is a usability bug, but intentional. ;-) > 2. Select Aircraft from list: looks like the list box is one line too > large and overruns the top of it's border window. > It's a pleasure to have the scroll bar work. :) FWIW: This will probably be thrown out after the 0.9.0 release. (Which doesn't mean that there won't be someone who fixes it before. :-) > 4. In a list box (like in Select Aircraft), when single clicking on an > entry, the text becomes unreadable. Perhaps the background was supposed to > darken? Well, you clicked it. Just remember the name before it becomes unreadable. ;-) FYI: you can also switch to a different GUI them (Shift-F10). Maybe it's better readable then ... or worse ... m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] environemnt_ctrl.cxx: exception triggers SGThread assert()
I've just implemented the check for stale METAR reports (to stop
fetching after 10 stale reports). This triggers an assert in
SGThread:
fgfs: /usr/local/include/simgear/threads/SGThread.hxx:155:
void SGThread::join(): Assertion `status == 0' failed.
I don't know much about threads. Could someone check (Erik, Curt? :-)
Apply this patch to reproduce (my changes aren't committed yet):
diff -u -p -r1.37 environment_ctrl.cxx
--- environment_ctrl.cxx26 Oct 2005 09:03:49 - 1.37
+++ environment_ctrl.cxx12 Nov 2005 14:14:55 -
@@ -558,6 +558,7 @@ FGMetarEnvironmentCtrl::fetch_data( cons
// fetch current metar data
try {
+_error_count = 1000;throw sg_io_exception("Boo!");
string host = proxy_host->getStringValue();
string auth = proxy_auth->getStringValue();
string port = proxy_port->getStringValue();
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
