Re: [Flightgear-devel] Re: Sim Reset
On Monday 19 December 2005 21:26, Alex Romosan wrote:
The Interface is deleted and a new one is created.
That is a bit crude, but it works ...
it doesn't work anymore though:
Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread -1223874848 (LWP 22155)]
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
It's hard to help for me either since I cannot preproduce ATM.
it's happened with all the jsb aircraft i've tried so far (including
the F80 dave culp just announced). i noticed this at sfo but i just
tried a few random airports and the same thing happens. it does not
happen with yasim planes. again, my jsb fdm has the carrier patch
applied.
IIRC a destructor can't call virtual methods, so if the interface
needs to do some kind of cleanup it can only be something pertaining
to this instance and using just the compile-time resolved calls.
I haven't looked at the code you cite above so this might be irrelevant
there, but I am a bit suspicious because of the name FGInterface that
hints at an abstract class.
Sorry I am overloaded with non-fgfs tasks right now --- I haven't even
pulled the last week's CVS updates and haven't reviewed them :-( ---
but maybe sharing this piece of info is better than doing nothing at all.
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Next world scenery build
This next world scenery build will include SRTM2 data. In the USA I [snip] My goal is to have everything done (for this round) by Jan 1 of the new year. But I reserve the right to push that date back in case I run into any new glitches. Thanks! Don't forget to take the rest on the seventh day of the world creation :-) Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Freeglut and game mode
From your description, it looks like the --enable-game-mode works with the debian freeglut3 package due to a debian specific patch. Just verified with freeglut3 and freeglut3-dev/2.2.0-8, it still works as expected here on a Debian system with the CVS flightgear, i.e., this is not some breakage due to some recent FG change. I am not using the CVS freeglut, relying on the Debian packages. I vaguely remember that something like you describe did happen with fgfs 0.9.8, and that some change to the FGFS code was made to make the game mode option work again. While I am sure that you are using the latest CVS code, maybe that will give some clue to the nature of the breakage of freeglut. You can apply the Debian patch over the baseline freeglut 2.2.0 of Fedora Core, or maybe use the alien tool to convert the debian package for use with that Fedora system, in case you don't like unfree libs. HTH, Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] c172r model - switches panel ordering; WB
I've tried today the c172r from today's CVS, and had this effect - the magnetos/electrical switches panel seems rendered OVER the yoke, no matter how the latter is rotated/pushed, the panel still gets drawn over it. http://www.tarunz.org/~vassilii/fg/Images/c172r-switches-over-yoke.jpg for a screenshot. I'd also like to note that the plane seems unrealistically tail-heavy -- just like the c150 model, it gets pushed on its tail with neutral controls and pretty light (11kt) winds. Even when empty, it doesn't happen in real life, but if you add inside even a 50kg pilot, it's going to be absolutely impossible. Vassilii ___ 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
And now comes the attachment... Sorry.
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19 pro-yoke-usb.xml
--- ../data/Input/Joysticks/CH/pro-yoke-usb.xml 22 Jun 2005 13:08:02 -
1.19
+++ ../data/Input/Joysticks/CH/pro-yoke-usb.xml 14 Dec 2005 20:17:06 -
@@ -4,6 +4,33 @@
nameCH PRODUCTS CH FLIGHT SIM YOKE USB /name
nameCH FLIGHT SIM YOKE USB /name
+ nasal
+ script![CDATA[
+ view_mod = 0;
+ reset_view = func {
+ setprop(/sim/current-view/field-of-view,
+ getprop(/sim/view/config/default-field-of-view-deg));
+ view_mod = 0;
+ }
+ if (props.globals.getNode(/rotors) != nil) {
+ disable_pref =
+
props.globals.getNode(/input/joysticks/disable-cyclic-yoke);
+ if (disable_pref != nil and disable_pref.getBoolValue()) {
+grove = props.globals.getNode(this);
+
+grove.getNode(axis[0]).removeChildren(binding);
+grove.getNode(axis[1]).removeChildren(binding);
+ }
+ else {
+ print (Forcing cyclic control with your yoke. Change
by adding\n
+ ~ \tdisable-cyclic-yoke
type=\bool\true/disable-cyclic-yoke
+ ~ \nto your joysticks.xml (the buttons/collective
control will still work then!)\n);
+ }
+ }
+ ]]
+ /script
+ /nasal
+
axis n=0
descAileron/desc
@@ -110,7 +137,7 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double2.0/step
+step type=double-2.0/step
/binding
/low
high
@@ -118,29 +145,25 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double-2.0/step
+step type=double2.0/step
/binding
/high
/axis
button n=0
-descFire Starter on Selected Engine(s)/desc
+ repeatablefalse/repeatable
+ descScroll in reverse through views./desc
binding
commandnasal/command
- scriptcontrols.startEngine()/script
+ scriptview.stepView(-1)/script
/binding
- mod-up
- binding
-commandnasal/command
-scriptprops.setAll(/controls/engines/engine, starter, 0)/script
- /binding
- /mod-up
/button
button n=1
repeatablefalse/repeatable
binding
- commandview-cycle/command
+ commandnasal/command
+ scriptview.stepView(1)/script
/binding
/button
@@ -221,31 +244,46 @@
/button
button n=8
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double+0.01/step
- /binding
+ descDecrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+ view.decrease();
+ if(view_mod0) { reset_view(); } else { view_mod = -1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double+0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod += 1;}
+]]/script
/binding
+ /mod-up
/button
button n=9
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double-0.01/step
- /binding
+ descIncrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+view.increase();
+ if(view_mod0) { reset_view(); } else { view_mod = 1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double-0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod -= 1;}
+]]
+/script
/binding
+ /mod-up
/button
button n=10
Index: ../data/joysticks.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/joysticks.xml,v
retrieving revision 1.34
diff -u -p -r1.34 joysticks.xml
--- ../data/joysticks.xml 24 Nov 2005 13:04:31 - 1.34
+++ ../data/joysticks.xml 14 Dec 2005 20:17:59 -
@@ -20,6 +20,7 @@
js n=0 include=Input/Joysticks/Local/joystick_0.xml/
--
+ disable-cyclic-yoke type=boolfalsedisable-cyclic-yoke
js-named/ !-- dummy to keep SimGear happy --
/PropertyList
___
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
Following Melchior's suggestions of not disabling the axis0/1 as somebody might want to fly a rotorcraft with the yoke nevertheless, I have modified the patch. Here's what it does now: 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 unless the yoke doesn't send the axis0/1 position as aileron/elevator control bindings. Thus, the patched file checks at startup if the /rotors property exists (thanks to Melchior for the tip on what to check!) and then ruthlessly removes the bindings at runtime. ...if the /input/joysticks/disable-cyclic-yoke property is set to true. Otherwise, it prints a message on the NASAL's stdout: Forcing cyclic control with your yoke. Change by adding disable-cyclic-yoke type=booltrue/disable-cyclic-yoke to your joysticks.xml I've also included a patch to the joysticks.xml to provide the default false (current behaviour); note that if somebody doesn't have the property node at all, it'll work as well. (I initially thought of using the menu for doing this (and have it disabled unless /rotors are present), but then I realized how annoying this must be for somebody who disables (or enables - depending on the default) this thing on every startup, and thus understood this should be a 1-time preference thing). 2) the view pitch change is reversed so that the hat movement now corresponds to one's head (view) movement (tilting it forward means tilting your head forward) About this one I think the important thing is to be consistent about all the joysticks. I wonder how other joysticks with the hat thing are mapped? 3) remap of some buttons: #0: instead of firing the starter, this one cycles the views in the reverse direction I think this is pretty safe to do along my patch, because starter is a pretty much one-time thing, whereas the view change is really handy to do while flying w/o removing the hands off the yoke. #1: this one uses the nasal view cycle wrapper instead of the old view-cycle command, thus we get the tip popup with the new view name #8/#9: these get to work as x/X on the keyboard, and pressing them together gives the same as Ctrl-X on the keyboard. For this, I removed the /controls/engines/engine[?]/boost control bound to them Here I really don't know what to do, and would be happy to hear David's and Erik's opinion first of all, as those having priority over mapping this hardware. (Actually, I'd love their and others' input on everything else in the patch as well, but here I am telling in advance that I am at a loss). The aircrafts affected are b29 (but it has 4 engines which are not selectable individually w/o the keyboard, and the current binding was broken anyway for b29 as it only moves the 1st 2 engines' boost!) dc3 p51d Hurricane Spitfire For all the other aircraft the buttons remained wasted anyway. It would be possible to create an ugly if to just remap around these 5 aircraft (or maybe if the boost control is present), or if the original authors don't object, just change the default to what the patch proposes. Safe flying, Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
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, because I picked it off working tree. I tested after that with the new property set to false, true, and absent. If you mean the markup in the print statement, it's harmless as it's wrapped with a CDATA block. 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.) I don't think it is driver specific --- since there may be other yokes, not just CH Products' one. Also, even if you say it should be a per-driver thing, I didn't understand which property do you suggest to check instead. PS: I still don't like the whole idea. :- What is so wrong? Asking the developers if the button defaults I propose are more sensible, or the idea of disabling the cyclic control via the yoke so that the rotorcraft flying is more real? or the way via which the disablement is customized even in the revised version? Constructive criticism welcome. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
oh, I see what you mean -- the closing tag in the joystick.xml file. Strange thing I didn't caught it while testing... Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] CH Pro Yoke USB XML patch
oh, I see what you mean -- the closing tag in the joystick.xml file. Strange thing I didn't caught it while testing... I know what happened. First, I tested it without the joystick.xml change and it worked (yoke controls the cyclic). Then I put the true in, and it worked (yoke control of cyclic disabled). Then I changed it to what you have seen, and it still was controlling the cyclic, yet in the very startup (which had scrolled off my screen) there was an XML parser warning (which didn't harm the rest of the startup). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] simgear+flightgear warning cleanup
Attached are 2 patches for cleaning up some build warnings,
in both simgear and flightgear. Caught with gcc-4.0.
Please apply...
Vassilii
Index: src/FDM/LaRCsim/ls_model.c
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/LaRCsim/ls_model.c,v
retrieving revision 1.4
diff -u -p -r1.4 ls_model.c
--- src/FDM/LaRCsim/ls_model.c 25 Jul 2003 17:53:41 - 1.4
+++ src/FDM/LaRCsim/ls_model.c 12 Dec 2005 09:38:55 -
@@ -154,6 +154,8 @@ Initial Flight Gear revision.
OUTPUTS:
--*/
+#include stdio.h
+
#include ls_types.h
#include ls_model.h
#include default_model_routines.h
Index: src/FDM/SP/ADA.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/SP/ADA.cxx,v
retrieving revision 1.3
diff -u -p -r1.3 ADA.cxx
--- src/FDM/SP/ADA.cxx 1 Nov 2005 13:41:50 - 1.3
+++ src/FDM/SP/ADA.cxx 12 Dec 2005 09:38:55 -
@@ -36,7 +36,7 @@
#define numberofbytes 472 // from FDM to visuals
#define nbytes 8 //from visuals to FDM
-struct {
+static struct {
double number_of_bytes;
double lat_geoc;
double lon_geoc;
@@ -111,7 +111,7 @@ struct {
double view_offset; //if this zero, means center window
-struct {
+static struct {
double ground_elevation;
} visuals_to_sixdof;
Index: src/Instrumentation/KLN89/kln89_page_nav.cxx
===
RCS file:
/var/cvs/FlightGear-0.9/source/src/Instrumentation/KLN89/kln89_page_nav.cxx,v
retrieving revision 1.1
diff -u -p -r1.1 kln89_page_nav.cxx
--- src/Instrumentation/KLN89/kln89_page_nav.cxx30 Nov 2005 00:18:42
- 1.1
+++ src/Instrumentation/KLN89/kln89_page_nav.cxx12 Dec 2005 09:38:55
-
@@ -123,12 +123,12 @@ void KLN89NavPage::Update(double dt) {
// Desired and actual magnetic track
if(!_kln89-_obsMode) {
_kln89-DrawText(DTK, 2, 0, 1);
- _kln89-DrawHeading(_kln89-_dtkMag, 2, 7, 1);
+ _kln89-DrawHeading((int)_kln89-_dtkMag, 2, 7,
1);
}
_kln89-DrawText(TK, 2, 9, 1);
if(_kln89-_groundSpeed_ms 3) { // about 6
knots, don't know exactly what value to disable track
// The trouble with relying on FG gps's track
value is we don't know when it's valid.
- _kln89-DrawHeading(_kln89-_magTrackDeg, 2,
15, 1);
+ _kln89-DrawHeading((int)_kln89-_magTrackDeg,
2, 15, 1);
} else {
_kln89-DrawText(---, 2, 12, 1);
_kln89-DrawSpecialChar(0, 2, 15, 1);
Index: simgear/environment/visual_enviro.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/environment/visual_enviro.cxx,v
retrieving revision 1.5
diff -u -p -r1.5 visual_enviro.cxx
--- simgear/environment/visual_enviro.cxx 30 May 2005 09:04:57 -
1.5
+++ simgear/environment/visual_enviro.cxx 12 Dec 2005 09:03:05 -
@@ -419,7 +419,8 @@ void SGEnviro::drawRain(double pitch, do
glDisable( GL_FOG );
glDisable(GL_LIGHTING);
- int slice_count = (40.0 + rain_norm*150.0)* precipitation_density /
100.0;
+ int slice_count = static_castint(
+ (40.0 + rain_norm*150.0)* precipitation_density
/ 100.0);
float angle = speed;
if( angle 90.0 )
@@ -500,7 +501,7 @@ void SGLightning::lt_build_tree_branch(i
nseg++;
// add a branch
if( energy * sg_random() 0.8f )
- lt_build_tree_branch(tree_nr + 1, pt, energy * 0.9f,
nbseg == 50 ? 10 : nbseg * 0.4f, segsize * 0.7f);
+ lt_build_tree_branch(tree_nr + 1, pt, energy * 0.9f,
nbseg == 50 ? 10 : static_castint(nbseg * 0.4f), segsize * 0.7f);
if( nb_tree = MAX_LT_TREE_SEG )
return;
Index: simgear/io/sg_binobj.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/io/sg_binobj.cxx,v
retrieving revision 1.9
diff -u -p -r1.9 sg_binobj.cxx
--- simgear/io/sg_binobj.cxx12 Oct 2005 16:43:26 - 1.9
+++ simgear/io/sg_binobj.cxx12 Dec 2005 09:03:05 -
@@ -45,7 +45,7 @@ SG_USING_STD( string );
SG_USING_STD( vector );
-enum {
+static enum {
SG_BOUNDING_SPHERE = 0,
SG_VERTEX_LIST = 1,
@@ -60,14 +60,14 @@ enum {
SG_TRIANGLE_FANS = 12
} sgObjectTypes;
-enum {
+static enum {
SG_IDX_VERTICES = 0x01,
SG_IDX_NORMALS = 0x02,
SG_IDX_COLORS =0x04,
SG_IDX_TEXCOORDS = 0x08
} sgIndexTypes;
-enum {
Re: [Flightgear-devel] Re: [PATCH] GUI/menubar.[ch]xx, Main/fg_commands.cxx: add fgCommand 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. Great idea. Do that, and I'll rework the CH Products Yoke cyclic hack to 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 :-) V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] SimGear Doxyfile: track newer sources addition
The patch below enables the SimGear doxygen-produced docs to relate to the sources that were added since last time the sources list was updated. Please apply, it's harmless for stability and helps those using the Doxygen docs. Vassilii Index: Doxyfile === RCS file: /var/cvs/SimGear-0.3/source/Doxyfile,v retrieving revision 1.15 diff -u -r1.15 Doxyfile --- Doxyfile5 Nov 2005 19:30:52 - 1.15 +++ Doxyfile5 Dec 2005 10:54:34 - @@ -303,16 +303,19 @@ simgear/compiler.h \ simgear/constants.h \ simgear/debug \ + simgear/environment \ simgear/ephemeris \ simgear/io \ simgear/magvar \ simgear/math \ simgear/misc \ + simgear/nasal \ simgear/props \ simgear/route \ simgear/scene \ simgear/screen \ simgear/serial \ + simgear/structure \ simgear/sg_inlines.h \ simgear/sg_traits.hxx \ simgear/sound \ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] yasim vs jsbsim c310
I've just tried out the c310 @KSFO, current metar conditions. The Yasim one develops 38PSI of manifold pressure, ~2700RPM at props and throttle full forward on the ground, brakes applied. The JSBsim gives a (more realistic-?) 29PSI. No surprise the ground roll at the Yasim one's is much shorter. 25 squared in Yasim means the throttle around halfway in at 500agl. I've never been in a c310 myself, passenger or pilot, but one of these aircraft simulations seems wrong. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover Are you flying using the mouse? Affirmative. When you hit F3 the cursor is slewed to the bottom left corner of the screen. If you are using the mouse for control at the time then you get full up elevator and full left aileron. LOL! Maybe I'll post a patch to switch off the mouse control mode temporarily during the snapshot on F3, if I find time for it... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
Having seen the recent request to try out a list of yasim-based aircraft from the current CVS, I've tried out the TU154. Here are 3 things I've noticed: 1) by hand-flying, I was able to get supersonic, pretty low and the aircraft flew all right, with no fluttering or reaching limits of some controls http://www.tarunz.org/~vassilii/fg/Images/tu154-supersonic.jpg 2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover (had to get back into realistic flying speed range to do that) (Too much CPU eaten while dumping the screen = big inter-frame time = model jolt?) 3) Throughout the flight, the in-cockpit altimeter showed the altitude in feet not meters (despite the dial marking meters in Russian). BTW, the ASI (marked speed in Russian) correctly indicated km/h. Cross-checked by the alternative HUD, see http://www.tarunz.org/~vassilii/fg/Images/tu154-altimeter-ft-not-m.jpg 4) the autopilot (even in the realistic subsonic speed range) goes berserk, starting with divergent pitch oscillations, and running out of pitch trim. Its altitude hold is usable in very low (under 200 KIAS) speed range, esp. if controlled by the AoA hold or pitch. I remember smth like this had happened to 737 and was fixed later. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] CH Pro Yoke USB XML patch
The attached patch does the following things:
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 unless the yoke doesn't send the axis0/1 position
as aileron/elevator control bindings. Thus, the patched file
checks at startup if the /rotors property exists (thanks to Melchior
for the tip on what to check!) and then ruthlessly removes
the bindings at runtime.
2) the view pitch change is reversed so that the hat movement
now corresponds to one's head (view) movement (tilting it forward means
tilting your head forward)
3) remap of some buttons:
#0: instead of firing the starter, this one cycles the views in the
reverse direction
#1: this one uses the nasal view cycle wrapper instead of the old
view-cycle command, thus we get the tip popup with the new view name
#8/#9: these get to work as x/X on the keyboard, and pressing them
together gives the same as Ctrl-X on the keyboard. For this,
I removed the /controls/engines/engine[?]/boost control bound to them
(I have no idea what these are for anyway)
Vassilii
Index: ../data/Input/Joysticks/CH/pro-yoke-usb.xml
===
RCS file: /var/cvs/FlightGear-0.9/data/Input/Joysticks/CH/pro-yoke-usb.xml,v
retrieving revision 1.19
diff -u -p -r1.19 pro-yoke-usb.xml
--- ../data/Input/Joysticks/CH/pro-yoke-usb.xml 22 Jun 2005 13:08:02 -
1.19
+++ ../data/Input/Joysticks/CH/pro-yoke-usb.xml 3 Dec 2005 01:41:34 -
@@ -4,6 +4,24 @@
nameCH PRODUCTS CH FLIGHT SIM YOKE USB /name
nameCH FLIGHT SIM YOKE USB /name
+ nasal
+ script![CDATA[
+ view_mod = 0;
+ reset_view = func {
+ setprop(/sim/current-view/field-of-view,
+ getprop(/sim/view/config/default-field-of-view-deg));
+ view_mod = 0;
+ }
+ if (props.globals.getNode(/rotors) != nil) {
+grove = props.globals.getNode(this);
+
+grove.getNode(axis[0]).removeChildren(binding);
+grove.getNode(axis[1]).removeChildren(binding);
+ }
+ ]]
+ /script
+ /nasal
+
axis n=0
descAileron/desc
@@ -110,7 +128,7 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double2.0/step
+step type=double-2.0/step
/binding
/low
high
@@ -118,29 +136,25 @@
binding
commandproperty-adjust/command
property/sim/current-view/goal-pitch-offset-deg/property
-step type=double-2.0/step
+step type=double2.0/step
/binding
/high
/axis
button n=0
-descFire Starter on Selected Engine(s)/desc
+ repeatablefalse/repeatable
+ descScroll in reverse through views./desc
binding
commandnasal/command
- scriptcontrols.startEngine()/script
+ scriptview.stepView(-1)/script
/binding
- mod-up
- binding
-commandnasal/command
-scriptprops.setAll(/controls/engines/engine, starter, 0)/script
- /binding
- /mod-up
/button
button n=1
repeatablefalse/repeatable
binding
- commandview-cycle/command
+ commandnasal/command
+ scriptview.stepView(1)/script
/binding
/button
@@ -221,31 +235,46 @@
/button
button n=8
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double+0.01/step
- /binding
+ descDecrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+ view.decrease();
+ if(view_mod0) { reset_view(); } else { view_mod = -1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double+0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod += 1;}
+]]/script
/binding
+ /mod-up
/button
button n=9
- repeatabletrue/repeatable
- binding
-commandproperty-adjust/command
-property/controls/engines/engine[0]/boost/property
-step type=double-0.01/step
- /binding
+ descIncrease field of view./desc
+ repeatable type=boolfalse/repeatable
+ binding
+ commandnasal/command
+ script![CDATA[
+view.increase();
+ if(view_mod0) { reset_view(); } else { view_mod = 1; }
+ ]]
+ /script
+ /binding
+ mod-up
binding
-commandproperty-adjust/command
-property/controls/engines/engine[1]/boost/property
-step type=double-0.01/step
+commandnasal/command
+script![CDATA[
+ if (view_mod0) { view_mod -= 1;}
+]]
+/script
/binding
+ /mod-up
/button
button n=10
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
2) when I hit the F3 to generate the above snapshot, I got an unusual attitude, from which it was very difficult to recover Are you flying using the mouse? Affirmative. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] post-incidence-angle-update tu154 4 problems feedback
Last night I noticed that a couple of the yasim-related updates happened later after my prev. pull. This time tu154 doesn't want to load up at all (btw this time I am not flying using the mouse, having the CH Products USB yoke+pedals connected): YASim SOLUTION FAILURE: Insufficient elevator to trim for approach ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
Flightgear (and any other flight sim) is trying to reproduce the experience of flying, both in terms of the flight dynamics and (to a limited extent) the whole experience. As such, many of the instruments in the virtual cockpit can be configured with mouse-clicks on the instruments themselves. Some can also be configured through dialog boxes. If FG wants to try and model the flight experience, these alternative dialog-box UIs must go. There are no pull-down menus on a real plane, and no dialog-boxes. Providing them therefore breaks the flight experience. I disagree with the fact that it breaks the flight experience. On the real plane, you extend your hand and twist a knob. Unless you're building an external hardware to augment your flight simulation experience (i.e., actual radio stack panel with the knobs to twist that will interface the PC), you will not have the same experience. Touchscreen might be smth, but most of us don't have a touchscreen either. Doing a mouse click on a radio knob (that is rendered to a tiny circle less than the natural size as the whole screen is less than 1:1 at the default zoom where you see both the window and the radios) is thus significantly more difficult and a more time consuming task. BTW, I am comparing it to real flight experiences. Mostly you even twist these knobs BLIND in the real life, only occasionally glancing at the frequency displays when you make the approximately correct amount of clicks, and look outside. No way to model that w/o a real knob. There is a concept of flow in real flying, referring to the flow of your hands around the cockpit, and the only way to train these is to do it in 1:1 scale 3D physical environment. Clicking will not give you the correct flows, because your hand doesn't move the same. Therefore, a way to do it via keyboard shortcuts/dialogs is a reasonable compromise --- you want to be able to make it with an approximately same ease. If, however, you want to do the clicking, that's all right, too --- but please back off from the idea that everything but the clicking must go. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible new thinking for 2D/3D cockpit instruments
windowmanagers have a magnifier tool. It can't magnify beyond the screen resolution of course (640x480 would still be 640x480), but it solves the problem with blurred tiny characters on small weathered monitors, like is it not the same effect as if the characters are rendered w/o antialiasing? Is it possible to do from within flightgear (to render them in this way)? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
So I'm unsure if it is a good idea to include those patches. They are harmless, but according to what Melchior has pointed out, some of the code (what I added to the exceptions classes) is redundant (basically, what is written there is auto-generated by the compiler unless it has problems). For the other parts of the patch, it is still relevant. I'm going to rework it later by eliminating the above redundancy when I have time (probably this weekend). Actually, I've looked at them now myself, and I ask the patching powers that be to apply it, save for the redundant parts patching the files SimGear/source/simgear/structure/exception.cxx and SimGear/source/simgear/structure/exception.hxx for which Melchior has voiced rightful objection. The 2nd revision of the patch is just a cleanup of some exception throwing and catching, sometimes providing additional diagnostics (e.g., the mysterious Failed to open file is now augmented with the actual file location caught). Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Well, I object. How could I tell others to postpone their contribution until after the release of FlightGear 1.0 if you are allowed to add this rather comprehensive peace of code? What about labelling the fg tree with your own 1.0 pre-release label? And branching off it, only merging in the trunk changes that you see fit? I have no problem creating a second devel. env. to test both versions, and I think others can do the same, for the benefit of better quality of the upcoming 1.0 release. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
For example I'd strongly consider the missing options saving a bug that has to be fixed before we give FlightGear to all the people out there. They are used to this behavior from nearly every program they use, and will expect the same from FG. Others may think, that we lived without this feature (who doesn't have his own private preferences.xml in the search path?) and it would be too an intrusive change. But that's the difference between a developer and an end user release. Nine I agree that this is a very serious feature for 1.0 inclusion. Maybe if we just have several people signing off the patch before inclusion (by 1) reading the code 2) testing it locally 3) sending an email to the list it's OK from their point of view for the 1.0) this will help. Personally, I will be willing to do this to the above patch. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] No 0.9.9 scenery yet?
Right now I suspect that most users of FG are either developers or bleeding edge people. But the idea is that that should start changing as of 1.0.0. Indeed - that's *why* there's a 1.0.0, surely? FYI: I had been on and off subscribing the fg lists and basically just the Debian stable package user (not even the most recent release off the fg pages!) for a year and a half until a couple of months ago, when I actually started building from the CVS and submitting patches. I suspect that a lot more people than those that fetch the CVS or those that fetch from the site are those who install the package of their favourite distribution (well, windows users probably do download the fgrun-augmented one off the page). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Autopilot
Could be added to the list of admitted features for 1.0, next to landing lights ... :-) Agreed. Esp. because this is mostly a gui XML / trivial NASAL thing. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pressure distribution calculation on planes when landing?
Andy Ross schrieb: Dai Qiang wrote: I'm wondering, if it's possible to calculate and record the pressure distribution on all parts of a plane, e.g. gears, wings etc, when it's landing? [snip] Dai Qiang, for what do you need that data? I can only think of animating the model. This works already for the gear model. And an reasonable animation of the wings could be easily faked. All you need is the amount of lift they produce. Divide that with a constant weight-force of the plane (e.g. MTOW * earth acceleration) and you get a number that is zero when the wings produce no lift and 1 during a steady flight (and somewhere above 7 when the wings break...) I thought more about structural integrity and the residual weakness after the plane is abused beyond the certified envelope rather than the way it is animated when I read the original poster. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport of Hell?
On Samstag 26 November 2005 19:47, Joacim Persson wrote:
fgfs --airport=EGLL --aircraft=ufo
...puts you in a mysterious place with thick fog, where ground level is
about 6 million m below sea level. This must be the airport of Hell.
While trying to investigate this, I found the following peculiar logic in
FDM/groundcache.cxx, line 364:
if (0 sgdScalarProductVec3( off, down ) || !found_ground) {
found_ground = true;
Which reads if ground is not found, then ground must be found. ?:-P
Well that must be logic from hell ...
Seriously, I can reproduce, I am currently investigating ...
Just to aid the investigation/possible fixing:
in case you missed it, a similar crash (ground-minding models)/teleport to
hell (ufo) happens in a slightly different scenario I had reported --
see
http://sourceforge.net/tracker/index.php?func=detailaid=1354007group_id=583atid=100583
for description/screenshots.
If you use the --offset-distance workaround to taxi onto the white cut-out
areas in, say, a cessna, you fall down to the hell.
(That was a marvelous description of the problem).
Vassilii
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Displaying Multiple Views/Using cockpit controls
Of course, any changes to the Getting Started Guide will only be present in the next release for most users, so we'll have a fair few questions until then... It's safe to assume that if users are smart enough to RTFM and see the local docs folder, then most of them will also check the up-to-date doc on the flightgear org site, provided the local version has a big notice that the most updated version is always to be found there. (Same as with HOWTOs). Another question is to how to drive the users to the guide in the first place, local or remote copy :-) V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
So I'm unsure if it is a good idea to include those patches. They are harmless, but according to what Melchior has pointed out, some of the code (what I added to the exceptions classes) is redundant (basically, what is written there is auto-generated by the compiler unless it has problems). For the other parts of the patch, it is still relevant. I'm going to rework it later by eliminating the above redundancy when I have time (probably this weekend). If yes, how to test if it works well? Depends on what kind of testing you want to do. Either look at the exceptions thrown and try to induce each one of them, or probably just do the regular flying and see if it is still OK. Also look at the code and see if you find something obviously stupid that I've overlooked. BTW. Vassilij, what's your platform? I overlooked it, maybe. (Mine is Linux on AMD 32bit) linux/Pentium IV 32 bit. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
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
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.
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, and,
AFAIU, precisely because the default member copy semantics is byte-by-byte
on my gcc (now it could well be that this is not the std, but I was pretty
happy about gcc compliance so far). What do you think?
BTW, maybe you meant to say that if I don't provide a copy ctor
in the derived class, then the parent's copy ctor is nevertheless
involved on the parent portion? I know *that*, but it doesn't cover
copying of the derived class' instance data.
#include exception
#include iostream
#include string
using namespace std;
struct E : exception {
E() : _msg(DEFAULT) { cout E::E() endl; }
E(const char* s) : _msg(s) {
cout E::E(const char* s ) endl; }
E(const E e) : _msg(e._msg + (clone)) {
cout E::E(const E e._msg ) endl; }
E operator=(const E e) {
cout E::operator=( e._msg ) assigned over _msg
endl;
_msg = e._msg + (assigned);
return *this;
}
virtual ~E() throw() { cout E::~E() _msg endl; }
const char* what() const throw() { _msg.c_str(); }
string _msg;
};
struct EE {
E e;
EE(const char* s) : e(s) { cout EE::EE( s ) endl;}
virtual ~EE() throw() { cout EE::~EE( e._msg ) endl;}
};
void foo(int i) throw(exception)
{
cout foo entering endl;
E unused(xUNUSED);
switch (i) {
case 0:
break;
case 1:
throw E(x1);
case 2: {
E weird(x2);
throw weird;
}
case 3: {
EE default_cloned(x3);
throw default_cloned; // CRASH as EE::e is never cloned
properly
}
}
cout foo exiting endl;
}
int main()
{
for (int i = 0; i 4; i++) {
try {
foo(i);
}
catch (E e) {
cout Caught e.what() endl;
}
}
return 0;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
Hi Melchior, thanks for the help. * 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 sure... Since now I see the code behaves that way, too :) 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! :-) yeah, right... and I never added a handler catching EE in the catch loop, so it aborts even w/o the exception specification. Fixing those shows (e.g. by adding EE's inheritance from exception (as you suggested), and catching an exception instead of E) that everything works, and that the E's copy ctor does auto-fire when the EE gets cloned via the default copy ctor semantics - it's fixed at http://www.tarunz.org/~vassilii/locally-created-exceptions.cpp What do you think? I think that I should debug fgfs/sg, not your code snippets, ...which of course have no relation to fgfs/sg debugging :-))) [snip] thanks for catching this one. I'll 1) go to sleep and hope that the flu will go away enough to get thinking sanely again 2) will try not to submit lengthy patches coded up when being sick before reviewing them myself being sane 3) re-read the BS book ASAP in case I forgot smth else out of C++ V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] [PATCH] (1/3) throwing stale exceptions and missing copy ctor/assignment
Index: ../../SimGear/source/simgear/environment/metar.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/environment/metar.cxx,v
retrieving revision 1.7
diff -b -u -p -r1.7 metar.cxx
--- ../../SimGear/source/simgear/environment/metar.cxx 6 Oct 2005 09:45:36
- 1.7
+++ ../../SimGear/source/simgear/environment/metar.cxx 25 Nov 2005 13:15:36
-
@@ -107,7 +107,9 @@ SGMetar::SGMetar(const string m, const
scanType();
if (!scanId() || !scanDate()) {
delete[] _data;
- throw sg_io_exception(metar data bogus ( + _url + ')');
+ static sg_io_exception E(metar data bogus );
+ E.setLocation(_url);
+ throw E;
}
scanModifier();
@@ -133,7 +135,9 @@ SGMetar::SGMetar(const string m, const
if (_grpcount 4) {
delete[] _data;
- throw sg_io_exception(metar data incomplete ( + _url + ')');
+ static sg_io_exception E(metar data incomplete );
+ E.setLocation(_url);
+ throw E;
}
_url = ;
@@ -196,7 +200,9 @@ char *SGMetar::loadData(const char *id,
sock-set_timeout(1);
if (!sock-open(SG_IO_OUT)) {
delete sock;
- throw sg_io_exception(cannot connect to + host);
+ static sg_io_exception E(cannot connect to host );
+ E.setLocation(host);
+ throw E;
}
string get = GET ;
@@ -232,8 +238,11 @@ char *SGMetar::loadData(const char *id,
char *b = buf;
scanBoundary(b);
- if (*b == '')
- throw sg_io_exception(no metar data available from + _url);
+ if (*b == '') {
+ static sg_io_exception E(no metar data from the URL );
+ E.setLocation(_url);
+ throw E;
+ }
char *metar = new char[strlen(b) + 2]; // make room for \0
strcpy(metar, b);
Index: ../../SimGear/source/simgear/props/condition.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/props/condition.cxx,v
retrieving revision 1.4
diff -b -u -p -r1.4 condition.cxx
--- ../../SimGear/source/simgear/props/condition.cxx24 Sep 2003 17:19:23
- 1.4
+++ ../../SimGear/source/simgear/props/condition.cxx25 Nov 2005 13:15:38
-
@@ -219,7 +219,8 @@ doComparison (const SGPropertyNode * lef
break;
}
}
- throw sg_exception(Unrecognized node type);
+ static sg_exception E(Unrecognized node type);
+ throw E;
return 0;
}
Index: ../../SimGear/source/simgear/props/props.cxx
===
RCS file: /var/cvs/SimGear-0.3/source/simgear/props/props.cxx,v
retrieving revision 1.18
diff -b -u -p -r1.18 props.cxx
--- ../../SimGear/source/simgear/props/props.cxx23 Oct 2005 14:04:42
- 1.18
+++ ../../SimGear/source/simgear/props/props.cxx25 Nov 2005 13:15:41
-
@@ -103,6 +103,7 @@ parse_name (const string path, int i)
{
string name = ;
int max = path.size();
+ static string E;
if (path[i] == '.') {
i++;
@@ -112,8 +113,10 @@ parse_name (const string path, int i)
} else {
name = .;
}
-if (i max path[i] != '/')
- throw string(Illegal character after + name);
+if (i max path[i] != '/') {
+ E = Illegal character after + name;
+ throw E;
+}
}
else if (isalpha(path[i]) || path[i] == '_') {
@@ -129,15 +132,18 @@ parse_name (const string path, int i)
} else if (path[i] == '[' || path[i] == '/') {
break;
} else {
- throw string(name may contain only ._- and alphanumeric characters);
+ E = name may contain only ._- and alphanumeric characters;
+ throw E;
}
i++;
}
}
else {
-if (name.size() == 0)
- throw string(name must begin with alpha or '_');
+if (name.size() == 0) {
+ E = name must begin with alpha or '_';
+ throw E;
+}
}
return name;
@@ -170,7 +176,8 @@ parse_index (const string path, int i)
}
}
- throw string(unterminated index (looking for ']'));
+ static string E(unterminated index (looking for ']'));
+ throw E;
}
@@ -291,8 +298,10 @@ find_node (SGPropertyNode * current,
// .. means parent directory
else if (components[position].name == ..) {
SGPropertyNode * parent = current-getParent();
-if (parent == 0)
- throw string(Attempt to move past root with '..');
+if (parent == 0) {
+ static string E(Attempt to move past root with '..');
+ throw E;
+}
else
return find_node(parent, components, position + 1, create);
}
Index: ../../SimGear/source/simgear/props/props_io.cxx
===
RCS file:
[Flightgear-devel] [BUG] [PATCH] (2/3) throwing stale exceptions and missing copy ctor/assignment
Index: ../../FlightGear/source/src/ATC/AIMgr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/ATC/AIMgr.cxx,v
retrieving revision 1.29
diff -b -u -p -r1.29 AIMgr.cxx
--- ../../FlightGear/source/src/ATC/AIMgr.cxx 11 Nov 2005 13:45:35 -
1.29
+++ ../../FlightGear/source/src/ATC/AIMgr.cxx 25 Nov 2005 13:21:55 -
@@ -82,7 +82,7 @@ void FGAIMgr::init() {
planepath.c_str(),
globals-get_props(),
globals-get_sim_time_sec() );
- } catch(sg_exception e) {
+ } catch(sg_exception) {
_loadedDefaultOK = false;
}
@@ -102,7 +102,7 @@ void FGAIMgr::init() {
planepath.c_str(),
globals-get_props(),
globals-get_sim_time_sec() );
- } catch(sg_exception e) {
+ } catch(sg_exception) {
_havePiperModel = false;
}
Index: ../../FlightGear/source/src/Environment/environment_ctrl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Environment/environment_ctrl.cxx,v
retrieving revision 1.40
diff -b -u -p -r1.40 environment_ctrl.cxx
--- ../../FlightGear/source/src/Environment/environment_ctrl.cxx22 Nov
2005 17:02:31 - 1.40
+++ ../../FlightGear/source/src/Environment/environment_ctrl.cxx25 Nov
2005 13:21:57 -
@@ -572,9 +572,11 @@ FGMetarEnvironmentCtrl::fetch_data( cons
result.m = NULL;
if (++_stale_count 10) {
-_error_count = 1000;
-throw sg_io_exception(More than 10 stale METAR messages in a
row.
+ static sg_io_exception
+ Error(More than 10 stale METAR
messages in a row.
Check your system time!);
+_error_count = 1000;
+ throw Error;
}
} else
_stale_count = 0;
Index: ../../FlightGear/source/src/Input/input.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Input/input.cxx,v
retrieving revision 1.72
diff -b -u -p -r1.72 input.cxx
--- ../../FlightGear/source/src/Input/input.cxx 23 Nov 2005 12:48:09 -
1.72
+++ ../../FlightGear/source/src/Input/input.cxx 25 Nov 2005 13:22:07 -
@@ -492,8 +492,10 @@ FGInput::_init_joystick ()
\\nUsing default: \ source '');
} else {
-throw sg_throwable(string(No joystick configuration file with
+ static sg_throwable Error(
+ string(No joystick configuration file with
namedefault/name entry found!));
+ throw Error;
}
js_node = js_nodes-getChild(js, i, true);
Index: ../../FlightGear/source/src/Main/fg_os_sdl.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Main/fg_os_sdl.cxx,v
retrieving revision 1.12
diff -b -u -p -r1.12 fg_os_sdl.cxx
--- ../../FlightGear/source/src/Main/fg_os_sdl.cxx 6 Apr 2005 08:46:39
- 1.12
+++ ../../FlightGear/source/src/Main/fg_os_sdl.cxx 25 Nov 2005 13:22:09
-
@@ -66,12 +66,14 @@ static void initCursors();
void fgOSOpenWindow(int w, int h, int bpp,
bool alpha, bool stencil, bool fullscreen)
{
+ static sg_throwable Error;
int cbits = (bpp = 16) ? 5 : 8;
int zbits = (bpp = 16) ? 16 : 24;
-if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE) == -1)
-throw sg_throwable(string(Failed to initialize SDL: )
- + SDL_GetError());
+if (SDL_Init(SDL_INIT_VIDEO|SDL_INIT_NOPARACHUTE) == -1) {
+ Error.setMessage(string(Failed to initialize SDL: ) +
SDL_GetError());
+throw Error;
+ }
atexit(SDL_Quit);
SDL_WM_SetCaption(FlightGear, FlightGear);
@@ -89,9 +91,11 @@ void fgOSOpenWindow(int w, int h, int bp
if(fullscreen) {
VidMask |= SDL_FULLSCREEN;
}
-if (SDL_SetVideoMode(w, h, 16, VidMask) == 0)
-throw sg_throwable(string(Failed to set SDL video mode: )
- + SDL_GetError());
+if (SDL_SetVideoMode(w, h, 16, VidMask) == 0) {
+ Error.setMessage(
+ string(Failed to set SDL video mode: ) +
SDL_GetError());
+throw Error;
+ }
// This enables keycode translation (e.g. capital letters when
// shift is pressed, as well as i18n input methods). Eventually,
@@ -185,6 +189,7 @@ void fgOSExit(int code)
void
[Flightgear-devel] [BUG] [PATCH] (3/3) throwing stale exceptions and missing copy ctor/assignment
This is just a pinpointing portion of the patch, as it doesn't fix
anything -- since it's all in the JSBsim, and that one is about
to be overridden with another upstream version. Please apply nevertheless
so that we have it in the fgfs code, until that happens --- it's just
comments change.
Index: ../../FlightGear/source/src/FDM/JSBSim/FGFDMExec.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/FGFDMExec.cpp,v
retrieving revision 1.14
diff -b -u -p -r1.14 FGFDMExec.cpp
--- ../../FlightGear/source/src/FDM/JSBSim/FGFDMExec.cpp11 Jun 2005
08:19:16 - 1.14
+++ ../../FlightGear/source/src/FDM/JSBSim/FGFDMExec.cpp25 Nov 2005
13:21:59 -
@@ -159,7 +159,7 @@ FGFDMExec::FGFDMExec(FGPropertyManager*
// to the property tree.
try {
Allocate();
- } catch ( string msg ) {
+ } catch ( string msg ) { // FIXME CATCH
cout Caught error: msg endl;
exit(1);
}
@@ -172,7 +172,7 @@ FGFDMExec::~FGFDMExec()
try {
DeAllocate();
checkTied( instance );
- } catch ( string msg ) {
+ } catch ( string msg ) { // FIXME CATCH
cout Caught error: msg endl;
}
Index: ../../FlightGear/source/src/FDM/JSBSim/FGMatrix33.cpp
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/FGMatrix33.cpp,v
retrieving revision 1.6
diff -b -u -p -r1.6 FGMatrix33.cpp
--- ../../FlightGear/source/src/FDM/JSBSim/FGMatrix33.cpp 15 Mar 2004
09:24:57 - 1.6
+++ ../../FlightGear/source/src/FDM/JSBSim/FGMatrix33.cpp 25 Nov 2005
13:22:00 -
@@ -284,7 +284,7 @@ FGMatrix33 FGMatrix33::operator/(const d
} else {
MatrixException mE;
mE.Message = Attempt to divide by zero in method
FGMatrix33::operator/(const double scalar);
-throw mE;
+throw mE; // FIXME THROW
}
return Quot;
}
@@ -307,7 +307,7 @@ FGMatrix33 FGMatrix33::operator/=(const
} else {
MatrixException mE;
mE.Message = Attempt to divide by zero in method
FGMatrix33::operator/=(const double scalar);
-throw mE;
+throw mE;// FIXME THROW
}
return *this;
}
Index: ../../FlightGear/source/src/FDM/JSBSim/JSBSim.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/FDM/JSBSim/JSBSim.cxx,v
retrieving revision 1.37
diff -b -u -p -r1.37 JSBSim.cxx
--- ../../FlightGear/source/src/FDM/JSBSim/JSBSim.cxx 10 Nov 2005 10:04:33
- 1.37
+++ ../../FlightGear/source/src/FDM/JSBSim/JSBSim.cxx 25 Nov 2005 13:22:07
-
@@ -180,7 +180,7 @@ FGJSBsim::FGJSBsim( double dt )
} else {
SG_LOG( SG_FLIGHT, SG_INFO,
aero does not exist (you may have mis-typed the name).);
- throw(-1);
+ throw(-1); // FIXME THROW (not a bug here, but review still --vassilii)
}
SG_LOG( SG_FLIGHT, SG_INFO, );
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
This is to announce the 3-part patch I have just submitted to the list. It has been split as follows: 1. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040968.html SimGear-level changes 2. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040969.html FlightGear-level changes (except for the JSBSim code) 3. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040970.html JSBSim code changes (no bug fixed there, they're only pinpointed with FIXME comments). What has been done in the patch: * 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 object use in the same scope. I've reviewed all the cases for the potential MT problems this might create, and think that there's nothing dangerous, but I'd appreciate your review of the code from this aspect. * in some cases more specific sg exception types were used in place of the more generic one, e.g., sg_io_exception instead of sg_exception when the context of the error was an IO error * in some cases, the error message was made more specific * in a couple of cases, I fetched the IO error string via strerror, knowingly pulling in bogus data in case another thread does an IO call at the same moment. These are marked with a FIXME. * 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! See the PropsVisitor::setException for an example of a faulty use that is no longer broken because of this change. * minor style fix for exception rethrowing --- using throw; whenever a re-throw is made; sometimes optimizing away the exception symbol name in the catch handler at all * more specific catch handlers added in some places -- e.g., an sg_io_exception caught ahead of sg_exception Please review, test, comment and apply! Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
I wonder: what does actually happen when you create a static object in the middle of a method? Same as if you create it in the beginning of the method :-) it gets initialized before it's first used, that's guaranteed; whether it's actually done before the function first runs or before the block first gets executed, is unspecified. Where does it get stored? In the static data section of the memory. When does it get released? Never. Static vars are just like extern vars, the only difference being that they are only accessed within the lexical scope that they're defined in (can be the whole file if defined outside a function, i.e., external static). Does it create a higher static memory footprint? (Does it's size matter?) Yes, but the 10 or so exceptions I've created with less than 50 string static objects overall don't matter that much, I hope (we're a several tens of megabytes binary image anyway already). I haven't really looked into the patches but what you describe sounds good to me. Thanks. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [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 ... :-) AAARGH. If you had noticed me talking about the problem with JSB and others last 2 weeks, you'd have been able to prevent smth like 2 days of my work (patching and testing). :-) I didn't have a Stroustrup on hand, and several folks around did tell me this is a problem indeed. Thanks for the quote, better later than never. I wonder what compiler was JSB using in his string throwing example, can you please re-read that thread and see if you can find an alternative explanation? I'm sure that some (older) compilers do behave the ugly way I had described in my patch (this was definitely the case in the pre-ANSI-C++ days). If w/o this we're losing some platform (e.g., MSVC-based builds), maybe we should still apply it. (This is the problem of NOT being a C++ newbie --- you forget what's standard these days and what is coming from your habits to circumvent older quirks.) Nevertheless, a lot of things in the patch do make sense --- e.g., even in the light of what you quote, w/o proper copy semantics of the exception object, the things are broken. I can shred the conversion to static from the patch, but I'd like to hear more on whehter we do need the explicit static objects for some older compilers on other platforms. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
* 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
I've created the following C++ snippet:
-- CUT HERE --
#include exception
#include iostream
#include string
using namespace std;
struct E : exception {
E() : _msg(DEFAULT) { cout E::E() endl; }
E(const char* s) : _msg(s) {
cout E::E(const char* s ) endl; }
E(const E e) : _msg(e._msg + (clone)) {
cout E::E(const E e._msg ) endl; }
E operator=(const E e) {
cout E::operator=( e._msg ) assigned over _msg
endl;
_msg = e._msg + (assigned);
return *this;
}
virtual ~E() throw() { cout E::~E() _msg endl; }
const char* what() const throw() { _msg.c_str(); }
string _msg;
};
void foo(int i) throw(exception)
{
cout foo entering endl;
E unused(xUNUSED);
switch (i) {
case 0:
break;
case 1:
throw E(x1);
case 2: {
E weird(x2);
throw weird;
}
}
cout foo exiting endl;
}
int main()
{
for (int i = 0; i 3; i++) {
try {
foo(i);
}
catch (E e) {
cout Caught e.what() endl;
}
}
return 0;
}
-- CUT HERE --
and gcc C++ compiler version 3.3.5 (Debian 1:3.3.5-13) has this to
say when compiling it with default flags (fully confirming what
you say -- you can throw either tmp variables, or automatic ones,
created inside a frame to be unwound, and the objects won't be
destroyed until caught):
foo entering
E::E(const char*xUNUSED)
foo exiting
E::~E() xUNUSED
foo entering
E::E(const char*xUNUSED)
E::E(const char*x1)
E::~E() xUNUSED
Caught x1
E::~E() x1
foo entering
E::E(const char*xUNUSED)
E::E(const char*x2)
E::E(const Ex2)
E::~E() x2
E::~E() xUNUSED
Caught x2(clone)
E::~E() x2(clone)
If anybody has access to a suspicious compiler that's critical for their
platform's flightgear development, please do this test and check that
1) no exception is caught before its dtor is called
2) the amount of ctor calls equals the amount of dtor calls
3) no crash occurs
Vassilii
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Re: [BUG] [PATCH] (announcement) throwingstale exceptions and missing copy ctor/assignment
I use Borland C++, and the g++ compiler in the cygwin distribution. I also compile under a flavor of Linux, just to see what happens. I've been worried that try/catch/throw is something that is not supported similarly on different compilers. I've got other priorities right now, but please make use of our bug reporting mechanism at www.jsbsim.org. It's really the only way to be sure we don't lose track of stuff. Well, I want to make sure I know there's a bug before I report it :-) Either I need to remove the explicit conversion to static objects from my patch (most likely unless dictated by a specific compiler not adhering to the standard clause that Melchior has cited from the BS book), or I don't. For the JSBSim code it means that the only bug you might have, if your compiler is sane, is that MatrixException doesn't have copy ctor/default ctor/assignment (see the cloned x2 case in my snippet example run), thus its string member is copied bit-by-bit. Please run the snippet from the other mail on your compilers (esp. the borland one) and tell if it works. I'll file a bug on www.jsbsim.org as soon as I know what the problems are. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [BUG] [PATCH] (announcement) throwing stale exceptions and missing copy ctor/assignment
I've tried to compile FG with this patches. But there is a problem Dear Ladislaw, thank you very much for your help in testing this. to compile it because no errno is declared in those files. I don't know, how it is mentioned, I'm not up to the code. I don't know how to fix it cleanly. So please, can you post the correction? Thank you. Please back the changes out. I am about to post a shortened version, as per the comments by Melchior, without the MT problems issues, and without the errno at this time. It will not use any explicitly static exception objects, even in the case where the whole exception object could be made static w/o ever changing it (i.e., when there's no per-throw data change of the exception). (I'm preserving the errno and the fully static hunks aside, they're not lost). Since you are running on a different platform than I do (I have the errno there), I would like to ask you to run the exception checking snippet in this thread and report the results, while I'm doing the final testing of the shortened patch. BTW. Paste the patch into the body of email is not good idea. I have to edit it manualy, because tabs and some spaces were lost. I don't know how, maybe it is a feature of gmail. I'd prefer an attached file. The problem is that some list archives don't store the attachments. I'll now include URLs to a backup of the patches on my site instead of pointing to the mailing list archives, for people like you that prefer direct binary download of a patch over piping an email through to a patch(1) pipeline. Vassilii ___ 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
I have re-worked the patch into a shorter one. It has been split as follows: 1. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040968.html SimGear-level changes Please see the attached simgear-except.diff for the new version of these, or http://www.tarunz.org/~vassilii/fg/simgear-except.diff 2. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040969.html FlightGear-level changes (except for the JSBSim code) See the attached flightgear-except.diff for the new version of these, or http://www.tarunz.org/~vassilii/fg/flightgear-except.diff 3. http://mail.flightgear.org/pipermail/flightgear-devel/2005-November/040970.html JSBSim code changes (no bug fixed there, they're only pinpointed with FIXME comments). I haven't included any JSBSim-related changes now at this stage. What has been done in the patch: This item * 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 object use in the same scope. I've reviewed all the cases for the potential MT problems this might create, and think that there's nothing dangerous, but I'd appreciate your review of the code from this aspect. is N/A any longer, as per Melchior's quote of the BS C++ 2nd ed book The following things are still there * in some cases more specific sg exception types were used in place of the more generic one, e.g., sg_io_exception instead of sg_exception when the context of the error was an IO error * in some cases, the error message was made more specific except for this one * in a couple of cases, I fetched the IO error string via strerror, knowingly pulling in bogus data in case another thread does an IO call at the same moment. These are marked with a FIXME. 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! See the PropsVisitor::setException for an example of a faulty use that is no longer broken because of this change. * minor style fix for exception rethrowing --- using throw; whenever a re-throw is made; sometimes optimizing away the exception symbol name in the catch handler at all * more specific catch handlers added in some places -- e.g., an sg_io_exception caught ahead of sg_exception as is my request below Please review, test, comment and apply! (don't forget to revert the older larger patch if you've already started testing it). Also, please contribute your thoughts testing results for my snippet and on the exception handling portability issues with throwing local objects from within a frame that is about to be unwound due to the throw. Thank you, V. ? ../../SimGear/source/simgear.doxytags ? ../../SimGear/source/simgear/misc/swap_test ? ../../SimGear/source/simgear/xgl/.deps ? ../../SimGear/source/simgear/xgl/Makefile ? ../../SimGear/source/simgear/xgl/Makefile.in Index: ../../SimGear/source/Doxyfile === RCS file: /var/cvs/SimGear-0.3/source/Doxyfile,v retrieving revision 1.15 diff -b -u -p -r1.15 Doxyfile --- ../../SimGear/source/Doxyfile 5 Nov 2005 19:30:52 - 1.15 +++ ../../SimGear/source/Doxyfile 25 Nov 2005 21:11:15 - @@ -46,17 +46,17 @@ OUTPUT_LANGUAGE= English # Private class members and static file members will be hidden unless # the EXTRACT_PRIVATE and EXTRACT_STATIC tags are set to YES -EXTRACT_ALL= NO +EXTRACT_ALL= YES # If the EXTRACT_PRIVATE tag is set to YES all private members of a class # will be included in the documentation. -EXTRACT_PRIVATE= NO +EXTRACT_PRIVATE= YES # If the EXTRACT_STATIC tag is set to YES all static members of a file # will be included in the documentation. -EXTRACT_STATIC = NO +EXTRACT_STATIC = YES # If the HIDE_UNDOC_MEMBERS tag is set to YES, Doxygen will hide all # undocumented members of documented classes, files or namespaces. @@ -111,7 +111,7 @@ STRIP_FROM_PATH= # to NO (the default) then the documentation will be excluded. # Set it to YES to include the internal documentation. -INTERNAL_DOCS = NO +INTERNAL_DOCS = YES # If the CLASS_DIAGRAMS tag is set to YES (the default) Doxygen will # generate a class diagram (in Html and LaTeX) for classes with base or @@ -498,7 +498,7 @@ TREEVIEW_WIDTH = 250 # If the GENERATE_LATEX tag is set to YES (the default) Doxygen will # generate Latex output. -GENERATE_LATEX = YES +GENERATE_LATEX = NO # The LATEX_OUTPUT tag is used to specify where the LaTeX docs will be put. # If a relative path is entered the value of OUTPUT_DIRECTORY will be @@ -558,7 +558,7 @@ LATEX_BATCHMODE= NO # The RTF output is optimised for Word 97 and may not
Re: [Flightgear-devel] 0.9.9 compile problem
Hrm... Why is debian shipping shared libraries for SimGear? As discussed, that is not the intended deployment mode for the upstream package (us!), so it seems awfully strange for debian (or Linspire?) to be making its own decisions there. Does it do the same for plib? FYI: we do have the source/package/debian/ subdir in the CVS, hosting Ove Kaaven's debian packaging scripts. SimGear really isn't designed to be a shared library anyway -- the various libsg*.a files just match the directory structure of the source code. As Alex pointed out, they have complicated dependency relationships that are going to be difficult to manage. Hmmm what about fgsd and Atlas? they link against the same codebase, don't they? why not lower the use of the VM by sharing it? As it is, running atlas+fgfs on a lower-grade PC with an older 32Mb gfx card really hurts (although I believe in my case it's the graphics card that's the bottleneck, not the RAM). Personally, I welcome anyone's attempt to clean up the mess and have the debian framework work cleanly with the up-to-date code, but I have other priorities ahead of that on my personal TODO list for the flightgear. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
I suppose I could complain that maybe the reliance on an environment variable to point to the scenery may be great for scenery developers, but isn't so great for package maintainers who might like to try and make (say) FlightGear-LakeConstance-Scenery-0.9.9-0.rpm Rather difficult for the post-install script in a package to make sure that the users' environment gets updated to know about the new scenery. Even more difficult to remove it cleanly and correctly afterwards when they uninstall the package. There is an XML property for the scenery path. A packager can create a preferences.xml with an included subfile which would be maintained automatically by such packages, adding/removing lines for things like LkConstance scenery and such. Actually, there's no harm in having non-existing paths listed on the scenery path IIRC. One could even create a package for each tile, and have virtual packages depending on such packages, for either 10x10 tiles, or countries, or states, or whatever else. (But nothing will beat a GUI-map-based interface, which is a bit difficult to implement within your typical minimalist curses-based package manager like aptitude). Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Re] Buildings?????
but you should note that there is no way to feed this terrain back into the 'official' FlightGear Scenery, [snip] I'm pretty sure we will have tools in the near future to merge certain landcover enhancements into the main scenery. We may have tools to merge elevation data into the main scenery but I fear we will almost _never_, as we already said in an earlier discussion, never have the tools to merge those enhancements that people created with FGSD. Is Jon's database only for actual objects and their location on the virtual Earth, i.e., are these terrain changes impossible to submit to his DB? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic daytime skycolor
Like in the dawn screenshot where I tried to show that off; http://www.adeptopensource.co.uk/personal/fg/747-Heathrow-dawn_moon.jpg [snip] I don't know anything about the theory of it all, but I do know that the sky in FG looks truly amazing at dawn and dusk in particular (colours, moon phases, star positions etc) - and I think we are _really_ underselling FG by not having a few screenshots illustrating that on the website. Agreed 100%. I'm sure others can come up with much nicer ones than I have... they're all going to offend the darkness police whatever :-) A trivial solution comes to mind --- create a decent out-of-cockpit screenshot facing a scene like that. Your particular image would offend not just the darkness police but the FAA as well for not sporting the exterior aircraft lighting when it should be on! V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D modelers
Yeah, a while back I stopped posting me email address on usenet news. It gets into the web archives, goes all over the internet and the world, and pretty soon you are back to measure your spam in messages per second ... :-( I'm proudly posting my email address on the webpages and never changed it. All I needed to do is tweak my spam-processing software, and periodically upgrade it (I stick to spambouncer + a couple of handwritten procmail recipes). In the inbox and the dedicated bulk mail inbox for the subscribed lists I don't get any spam. In the block folder, I get most always spam, and occasionally (within 5 times a month) an email from a clueless someone using a generic free email and posting in HTML with their ads image embedded. Whatever is tagged as virus or spam, is always safe to throw. BTW, i'd like to express the gratitude to the list master(s) at this time (Curt, that's you, right?) for no spam in our list. But if anyone else is feeling brave, be my guest. I'm brave enough as I have said, but I am not a modeller. If somebody posts a detailed announcement+request for information here, I'll be happy to forward it on to the r.a.simulators and/or .piloting on the behalf of the fgfs devel team, of which I am a happy junior member :-) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Two issues/question
1) If I fly out of an airport that is located out of the included sample scenery, then at the command line I get: Failed to open file repeated twice. I am using 0.9.8 scenery in that case, because that is all that is available. But there is no indication of what files are not opening, or what the problem is. Is there a difference This is something related to the broken exception throwing, be thankful it doesn't crash at the moment you see the message because it fetches its parts from freed memory! I'm now working on a huge patch fixing these issues all around the fg/sg/atlas/fgrun, and meanwhile you can run with --log-level=info and see what is the file it is trying to open just before the message is printed. V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Stale documentation links on the fgfs WWW
Dear Curt, please update the links to the getting started and the short reference guides to point to the newer docs which are now in the CVS. (Or maybe just copy the docs into the same place). Currently, http://www.flightgear.org/docs.html and http://www.flightgear.org/Downloads/source.shtml links lead to older documentation. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Landing Lights (was Re: Release of v0.9.9 source code)
I noticed that on one of your FG pages you mentioned that OpenGL can have a maximum of 8 light sources. Presumably this is going to cause some dull rendering issue if we ever had landing lights enabled in a mult-plane environment? Good point. Perhaps the non-local models should have a luminous fake light like the other lights in fg for this reason. In the real life you don't see others' landing lights light cones unless you taxi by while they land or smth like that. Finally, on a more practical note, I assume that landing lights work a bit like car headlamps - i.e. you switch them on during landing and they illuminate the runway infront of your so you can see when to flare? In traffic congested areas, e.g., when approaching an airport, one is encouraged to switch the landing light on for being seen better, even during daytime. I'd call this the main actual purpose of the landing light. (The positional lights, OTOH, have no practical use in daylight). 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). Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Landing Lights
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. Absolutely. When taxiing, a landing light or taxi light is needed at night. I once taxied a c152 off a taxiway and into a mud, had a ~10cm remaining between the prop and the ground --- when my ldg light burnt out in flight :-)) Had to get out and push the aircraft back, with the passenger helping, standing in the mud... yuck. 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] Never flown in such big planes myself, passenger or pilot, but it indeed seems too bright and too wide an angle. 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? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Landing Lights (was Re: Release of v0.9.9 source code)
Where are they located on the C-172, C-182, C-310 - on the wing or on the nose like I've seen in pictures of a C-210? I own the pilot info manuals for various model C-172 planes, so I can look it up and even scan for you the relevant drawings. Will do in the evening. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New Rendering Option?
I'm thinking, if it's a good idea to add a new rendering option into FGFS: water shader, which will make the sea and the experience of carrier taking off and landing more realistic. It's certainly a good idea! go ahead. Here's a screenshot of a game using OpenSceneGraph, and the technique is to load GLSL shader in OpenGL. http://www.openscenegraph.org/osgwiki/uploads/Screenshots/pirates-2005-06-01-07.jpg looks really cool, although the sea has a somewhat plastic feel in the picture... Its hardware requirement will be the same to that of bumpmapped clouds. If you add the feature, you'll probably want to make it conditionally enabled --- similar to the 3d clouds etc --- so that people with lower end hardware could disable it. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrain texture question
Well, there's this: Format: SNINCR [i/g] i - Increase in snow level in inches per hour. g - Snow level on the ground in inches. I googled for metar snow level :-) OTOH, various stations have various capabilities, which is (in the US at least) differentiated by the METAR prefix. Some don't have the necessary sensors to get the precipitation levels/accumulation. So if you encounter such a station, don't discard the snow that blows around from its neighbours :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] impending v0.9.9 release
I would really like to get v0.9.9 out the door this week ... maybe committing to the final source code version on thursday or friday. The earliest time slot I might possibly have at serious hacking of fgfs is this Friday night. However, I would like to give everyone the opportunity to mention any show stopping bugs that we should be concerned about. It's ok to report bugs, but at this point we really need people reporting *fixes*. The magic source code gods have this week off so we are going to have to fix all the bugs ourselves. :-) I'm very much concerned about the buggy exception throwing pattern that flightgear and simgear have (ab)used, and have circa 100 throws to verify and modify their vicinity in some cases. I have not started this work yet, so if somebody wants to do it before Friday night, go ahead. Furthermore, I can not commit at anything right now, because things happen outside of flightgear (e.g., 15 minutes ago my 3-year-old daughter turned out to have fever, and this may steal whatever free time I have planned for the next week altogether). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
On Mon, 14 Nov 2005, Stefan Seifert wrote: Buchanan, Stuart wrote: OK, I'll suggest /var/share/FlightGear/WorldScenery/[Terrain|Objects] for *nix, and FG_ROOT\Scenery\[Terrain|Objects] for Windows. I'm sure you meant /usr/share/FlightGear/... and not /var. I thought /var because of the indeterministic size --- some folks will terrasync only a small local area, some will more... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] error:Unknown exception in the main loop
I've seen a couple of Failed to open file messages w/o a file, and decided to hunt for that one. It looks like this is only thrown from within simgear, but always with a path. Closer examination reveals that easyxml.cxx throws it, and uses the same pattern as JSB and I had recently agreed to be problematic --- dynamically creating things on the stack and throwing them! Either I managed to persuade JSB in a wrong C++ fact (I'm not 100% sure about it), or each and every throw throughout simgear and flightgear must be reviewed and such usages rewritten. One might argue that this is smth that only aids in error recovery in already screwed up situations, but some exceptions might be thrown to indicate non-globally-fatal situations --- i.e., without looking at every such place we can't be sure. Bad news --- I've verified, and indeed this is a wrong way to throw a tmp object out of a stack frame. It's fine as long as the catch handler is in the same function. If all that the catch handler does is catch smth by reference and never access the instance, it is fine, but 1) the throw is still unsafe 2) in this case, all that the exception object is used for is just signal the type of exception by its C++ type, and thus it makes more sense to have one static object of that class for this very purpose, to save the ctor/dtor hassle. Bottom line: sg/fg contains a lot of unsafe and unportable code (i.e., some compilers will have it crash earlier than the others), and a patch is needed. I'll try to work on this in this coming weekend, time permitting. It's a lot of code to verify -- find . -name '*.[ch]*' | xargs cat | grep -c throw gave me 66 on sg and 43 on fg. It's a pity no exceptions like these had been thrown during the valgrind runs some folks were running. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Hi All, As with 0.9.9 we'll be using the FG scenery DB objects, will the default scenery directory topology be something this Scenery/Terrain/w010n50 Scenery/Objects/w010n50 ? I suggest encouraging 2 directories --- 1 for the static scenery coming with FG, and the other one for the Terrasync DB/Jon's database/ whatever else external source. Melchior has it summed up pretty nicely at 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. Assuming this is the case - a) Should this be what is mentioned in the Getting Started Guide as the way scenery is installed (I'm happy to make the update) b) Should the binary installers create the Terrain and Objects subdirectories (someone else will have to do this one) The binary installers could also have an option of launching a local terrasync service in a dedicated account with write permission into the world scenery Terrain subdir. From a documentation point of view, I don't want to have to explain two different approaches and the issues with a Terrain subdirectory that can arise, so it would be nice only to have one standard. In some place the difference would have to be explained because of the people that make the upgrade, wouldn't it? Thank you very much for the docu. updates! V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Additionally no one should run terrasync as root anyway, so it can't write to /var/share/FlightGear. terrasync users should have their own scenery directory in their homes or anywhere their user is able to write. Nine I agree. User data (like from terrasync) belong to ~./local/share/FlightGear or ~./flightgear/ When using the latter one, we could also start to put the .fgfsrc config file into ~./flightgear/ I thought about a dedicated account for terrasync (non-root), with right permissions only to the /var/share/FlightGear/Scenery/Terrain (or WorldScenery/Terrain). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Getting Started Guide - Terrain/Objects
Terragear is sufficiently crude and unrefined and user unfriendly that I think we should leave it out of the getting started guide. We are going to send unsuspecting users down a wild goose chase and they'll be disappointed. We can mention it and forward them to more information, but I think we are asking for a lot of trouble if we try to document it in the getting started guide. For instance, it requires rsync to be OK. This means that we should suggest $FG_ROOT/... based layout (but with different scenery dirs between the base package and the user-installed additional scenery --- unless we keep the scenery download page SFO tile to be the most up-to-date so that the SFO scenery is no longer nukable), and just have a terrasync pointer. Everything else (per-FHS-distro-flavoured dispersion of things under /opt's /share's /var's etc, suid terrasync etc) actually belongs in another document (not yet written, and needed with a much smaller priority, if at all) documenting the best current practices of fg packagers, so that Debian/Gentoo/RH/win32/... packages have the same shared know-how. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] diff for browser change for mac os x to use
Help Help from the gui on mac os x is still broken. The help application is STILL set to netscape even after the options.cxx change Doesn't it mean that something resets it between the options parsing and the GUI help stuff processing? I'd rather see a patch that finds the offending code modifying it, if that's the case. BTW: there's an option to debug/trace every property read/write for a given property, sorry I can't say more right now as I am logging into my mail remotely at this moment w/o any graphics around to test the things. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [fgrun-users] initial wizard screen in fgrun lacks obvious defaults (fwd)
Forwarding a notice about fgrun over to flightgear-devel, as per Bernie Bright's suggestion. Please see below, if you feel like patching fgrun. -- Forwarded message -- Date: Mon, 14 Nov 2005 09:28:39 +1100 From: Bernie Bright [EMAIL PROTECTED] To: Vassilii Khachaturov [EMAIL PROTECTED] Subject: Re: [fgrun-users] initial wizard screen in fgrun lacks obvious defaults Hi, I'm not supporting fgrun any more. However you should be able to get help from the flightgear-users or -devel mailing lists. Bernie Vassilii Khachaturov wrote: OK, now I am running fgrun, and its Executable, FG_ROOT and FG_SCENERY are all empty, despite being run in the environment where it has all the reasons for guessing right: [EMAIL PROTECTED]:~$ echo $PATH /home/vassilii/flightgear.nobackup/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/usr/games [EMAIL PROTECTED]:~$ type fgfs fgfs is /home/vassilii/flightgear.nobackup/bin/fgfs [EMAIL PROTECTED]:~$ echo $FG_ROOT /home/vassilii/flightgear.nobackup/FlightGear/data [EMAIL PROTECTED]:~$ echo $FG_SCENERY /home/vassilii/flightgear.nobackup/FlightGear/data/Scenery:/usr/share/games/FlightGear/Scenery:/var/games/FlightGear/Scenery --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ fgrun-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/fgrun-users ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runtime error 0.9.9 on Debian/Testing
$ fgfs opening file: /usr/local/share/FlightGear/Navaids/carrier_nav.dat /usr/local/share/FlightGear/Navaids/TACAN_freq.dat RenderTexture Error: glXCreateGLXPbufferPtr() failed. Initialising callsign using 'Aircraft/c172p/Models/c172p.xml' freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called \ without first calling 'glutInit'. Hey Alex, this has been a 'common' issue that has bit a lot of people. There appears to be a problem with freeglut 2.4. The solution has been to downgrade to freeglut 2.2 or run freeglut-cvs. You could also build with sdl (configure --enable-sdl) and that might side step the issue altogether. Regards, Curt. It looks to me that this will be a recurrent issue following 0.9.9 release as well. Can an autoconf guru please add a relevant check into the configuration scripts? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] diff for browser change for mac os x to use safari
On things like Debian, this is also wrong because sensible-browser should be used instead. Is there some autoconf library function to discover the most likely browser on a system? Also the WIN32 section in src/GUI/gui_funcs.cxx with the 1024-long hardcoded buffers can be a crash trigger when the buffer overflows for somebody with a long enough path... V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review (was: Which aircraft to include in v0.9.9?)
Maybe some German-speaking user could point the reporters to Atlas for the moving map solution they describe as absent (and to the new Pigeon's map!) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] try ... catch ... throw (up)
Here's what I'm doing:
In the Table class:
In FGTable constructor:
if (operation_types.find(parent_type) == string::npos) {
internal = true;
} else {
throw(string(An internal table cannot be ...));
}
Now, this seems to work OK - I throw an exception if a situation
occurs that is invalid.
[snip]
I'm probably missing something fundamental here. Anyone have any suggestions?
Jon
I am unsure it is OK to through a temporary object like this.
It's created on the stack right there at the same frame where it's thrown,
but IIRC, as throw unwinds the stack, it is auto-destructed. You should
be throwing an object that has lifetime encompassing the outer catch
handler.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] diff for browser change for mac os x to use safari
OK, is there a way to get sensible-browser at compile time? Is this a link know to the OS or something? is it callable or does it need to be read on Debian somewhere? It's a callable standard script on debian. It tries various intelligent decisions to guess what browser to run. It is pretty debian-dependent though (e.g., it relies on the fact that the browser packages register themselves via the alternatives mechanism available on debian). On Debian, however, it is the preferred thing to call in order to be user-friendly. My point is that fgfs doesn't have the means to know the target system defaults and thus the hardwired default is probably best left as a toplevel configure option. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Review
I probably would do, but I don't have any experience with Atlas at all, so I'm unable to give appropriate response to the questions that I suppose will follow It's pretty straightforward, just give it a try following the WWW instructions. Be sure to use the CVS version and not the last released one, please --- much more stable and less autoconf problems. http://atlas.sourceforge.net/ On a low-end 3D card you probably want either to use a very small window for atlas, or even split atlas over to another computer from the FGFS. Be sure to use the lowres tiles, too --- see the Installing and Running page there. HTH, Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] no 3d clouds?
I am unable to get 3d clouds with todays CVS for FlightGear and data and SimGear. I am running via fgrun and 3D clouds is checked and --enable-clouds3d is in the list under the show command line window. I also ran fgfs from the command line with --enable-clouds3d and still no 3D clouds. In the Render menu, it looks like the 3D Clouds is grayed out. Is this now a hard wired default in CVS? Surely not, because render/enable 3d clouds and the cmdline option do work here for me on Linux. I would love to help you with the fgrun setup, but I was unable to compile it here --- see my lament at http://sourceforge.net/mailarchive/forum.php?thread_id=8954364forum_id=39103 Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] error:Unknown exception in the main loop
Unknown exception in the main loop. Aborting... Possible Cause: No error This makes me report the following seemingly related sighting that I had today in the middle of something else, w/o exploring it until the end (I did mention it on the IRC earlier today). I've seen a couple of Failed to open file messages w/o a file, and decided to hunt for that one. It looks like this is only thrown from within simgear, but always with a path. Closer examination reveals that easyxml.cxx throws it, and uses the same pattern as JSB and I had recently agreed to be problematic --- dynamically creating things on the stack and throwing them! Either I managed to persuade JSB in a wrong C++ fact (I'm not 100% sure about it), or each and every throw throughout simgear and flightgear must be reviewed and such usages rewritten. One might argue that this is smth that only aids in error recovery in already screwed up situations, but some exceptions might be thrown to indicate non-globally-fatal situations --- i.e., without looking at every such place we can't be sure. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Pending v0.9.9 release
Yep, but sipmly _delaying_ the next release doesn't cure anything. This only makes sense if the developers agree on a feature freeze and announce a bugfix-only phase. ..or if it can be enforced somehow. ;o) or that a separate branch is created for the feature freeze while the development continues at the trunk, with only hand-picked patches getting into the release branch... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: OT: FYI, mac os x developers,
Just a suggestion: Maybe it is a good idea to put some of the important rules on the http://www.flightgear.org/mail.html webpage so people can read them, before they subscribe to the mailinglists. Good idea, in case someone really is annoyed with top-posts/encodes etc. Such folks are welcome to check-out the www module from the flightgear CVS, change the appropriate HTML, validate it, and send the patch over to Curt. Curt also likes the web pages' modified full text sent over as well, along with the patch, due to the way the website is now managed. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
3). J3 - The J3-Cub is complete (not much to cubs anyway) and easy to fly for someone just starting out. A real life Cub has a ball slip/skid indicator (just like in a turn coordinator), and a wire sticking out of the fuel cap in front, showing the fuel level. Other than that, it's pretty complete indeed. (Well, except that maybe real life Cubs are so much harder to start up...) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
Thanks for applying the patch to the current code. I wonder what the jamming logic should be instead. Maybe check whether the angle between the cockpit Y axis and the resultant force presently acting on the plane is within some limit? I have no problem checking the angle above (based on the 3 /accelerations/pilot/[xyz]-accel-fps_sec properties); the question is, how do I get a realistic threshold value for jamming? (I don't remember any jamming from my real life flights anyway). Also, in a Cessna one can swivel the compass around the lateral axis; does it happen on other planes where it is installed? Do we want to model that? (that is just smth for future development) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Next on the list are the Nat. Cathedral, Basilica of the Immaculate Conception, Mormon Temple, Pentagon and then the Mall. Not sure what timetable I'm looking at though. If you can think of any other big visible structures that you would like to see (sorry, I'm not tackling the bridges yet, there's issues with the VMAP data I don't want to deal with) let me know. No promises though. I think the Statue of Liberty is a nice thing to have. It's a nostalgic thing for those of us who had seen the Flight Simulator II on Atari ST and Amiga. the first home personal computer program ever to apply to the FAA for an official PCATD status. Even a very crude, low-poly version would be great. It was this very program that had inspired in me the desire to fly in the real life one day, back when I was 13 years old. I distinctly remember the thought: Hey, those folks in the US have the small planes to fly in available to common people to try. Maybe in 30 years, when they have rocket ships at the same availability level over there, we'll have small planes available to common people like me here in the USSR! since then I had managed to witness the USSR collapse, the iron curtain fall, and eventually get my private pilot wings in the US... V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Did you upgrade your data from the cvs? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery DB (Was: San Jose)
I would like to see all new scenery object contributions to end up in the scenery database. However, the last time I wanted to sync the base package and the DB there were more than one objects in the same space because of automatic object generation. btw it looks pretty cute sometimes --- e.g., a skyscraper swallowing a radio tower and thus it looks like a skyscraper with a smaller antenna tower on its top; such things happen in real life as well :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] minor internal consistency improvement for the freq search dialog
Since when the search via the input is used, the dialog is closed, I suggest to auto-close it when a nearby-ATC button is hit as well, as per the patch below. Alternatively, we can rename the OK button to Search and DON'T have it auto-close the dialog. The question is whether mostly you use the dialog for looking up the frequencies for a particular single airport only (like me - then the patch is the way to go), or for several airports in a row (then the alternative approach should be used). V. Index: ../data/gui/dialogs/atc-freq-search.xml === RCS file: /var/cvs/FlightGear-0.9/data/gui/dialogs/atc-freq-search.xml,v retrieving revision 1.3 diff -u -r1.3 atc-freq-search.xml --- ../data/gui/dialogs/atc-freq-search.xml 5 Nov 2005 18:42:28 - 1.3 +++ ../data/gui/dialogs/atc-freq-search.xml 6 Nov 2005 18:41:22 - @@ -22,6 +22,9 @@ property/sim/atc/freq-airport/property value type=stringICAO/value /binding + binding + commanddialog-close/command + /binding /button-template /group ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS version/terrasync DB problem with UG25, LL62: crash(bo105)/strange(ufo)
In the light of the recent multiple 0.9.9-pre1 commits I've been going through the list of open issues that worry me and this one When I start the CVS version at the UG25 airport with bo105 (yesterday's CVS data, the day before CVS sources), it core dumps on startup as follows: [snip] The core dump is always at the same place (pointers are different). If I do it with the ufo, it starts in some white warp space (cockpit view -- solid white around the aircraft, same w/chase etc.) and from the tower one doesn't see anything at all. The last released version just hangs if I start it up there --- the splash screen never goes away! Now if I take a UFO and fly from a nearby airport to UG25 (say, from UGGG), then one sees solid white instead of the runway --- broken scenery, or broken fgfs? See a screenshot of what I am talking about at http://www.tarunz.org/~vassilii/Images/fg/UG25-cutout.jpg A similar thing happens at LL62 (crash of the CVS version/cutout): http://www.tarunz.org/~vassilii/Images/fg/LL62-cutout.jpg [snip] got no comments from anybody yet; maybe because I should have posted it to the terragear list rather than here? (Nevertheless, it's the fgfs that crashes). Or is flightgear-devel the right place, but this is just a low priority issue? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] thanks for the keyboard accelerators
This is to say a huge thanks for the keyboard accelerators. All the times I had hit ESC to close a dialog during low-level maneuvering (and then cursing because of an extra dialog I had to close or tolerate on my windshield) are now history! The ATC xmission menu change is also very handy for the same reason. Thanks, Melchior! V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
A very cool user-felt feature is Vivian's redout/blackout, currently implemented in the hunter. Please add it to the list. I couldn't resist from taking the following picture that shows the redout sphere from the side: http://www.tarunz.org/~vassilii/fg/Images/hunter-redout.jpg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Hey, someone noticed :-) It was fixed in cvs Thursday last though. :) Of course, I keep looking at the CVS commits since I am learning FG. Actually I kept thinking of doing this one myself, since nobody answered my challenge yet to tell me about smth interesting to do for FG while learning GL. Eventually, this should probably be configurable wrt individual G-tolerances, and adapted to all aircraft. V ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [BUG] earth rotational axis poked a hole in the planet?
With either jsbsim or yasim aircraft, when is in the vicinity of the (North) pole, the AGL (as seen in the HUD) goes into 2*10^7 ranges. You can either start up with --lat=90 (and any longtitude you please), or, if you dislike the singularity of --lat=90 at the startup, use --lat=88 and head north. Soon past 89 degrees you'll see it happening. (I initially discovered it by trying to start up with santa at the pole :) ). When this happens, one can fly below earth (altitude-wise, as indicated on the altimeter) down and down w/o a problem on an aircraft (like hunter) that doesn't allow it normally. I don't think this is a particuarly annoying aspect of the flightgear universe, but maybe somebody will get a hint to another bug from this report. V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [Flightgear-cvslogs] CVS: FlightGear/src/FDM groundcache.cxx, 1.11, 1.12
Mathias Fröhlich: I have now fixed the problem that flying below bridges was broken by some groundcache work. Thanks a lot!! this is a very important eye-candy feature --- one of the bigger ones to draw folks to fgfs tryouts over here :-) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] a misprint in hunter-set.xml
Index: ../data/Aircraft/Hunter/hunter-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/Hunter/hunter-set.xml,v retrieving revision 1.13 diff -u -r1.13 hunter-set.xml --- ../data/Aircraft/Hunter/hunter-set.xml 1 Nov 2005 20:01:56 - 1.13 +++ ../data/Aircraft/Hunter/hunter-set.xml 4 Nov 2005 23:28:11 - @@ -87,7 +87,7 @@ controls gear brake-parking1/brake-parking -tailwheel-lockfalsse/tailwheel-lock +tailwheel-lockfalse/tailwheel-lock /gear flight flaps-alternate-extension type=double1/flaps-alternate-extension ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] getting hands dirtier: graphics-related programming task sought
while waiting for your advice on the subj matter, I have found the CVS source for the flightgear site --- (BTW, is the site material in the CVS somewhere, so as to make it easier to send the patches against?) it's in the www module of the same CVS repository --- and had sent a couple of minor patches over to Curt. (I'm posting this for a record in case some future poor soul looks for the CVS sources for www.flightgear.org material to help amend it.) v. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Status on Multiplayer
I have just recently got FG working and it has turned out to be a pleasant suprise - anyway just wondering what the status on Multiplayer is. Please have a look at the README.[Mm]ultiplayer in the CVS. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] getting hands dirtier: graphics-related programming task sought
Dear fellow developers, I've decided to upgrade my fgfs addiction from just submitting janitorial/small nagging feature patches to a next level --- specifically, I've begun to study the GL APIs and would like to help the project with doing some graphics-related programming. While I used to do pretty hardcore 2D graphics programming half my life ago (Z80 assembler on a ZX Spectrum-compatible (same video-wise anyway) computer), and an experienced C++ programmer, I'm a total newbie when it comes to 3D. Hence I am turning to the flightgear/simgear graphics gurus: Do you have in mind some graphics related aspect of flightgear that I could help with, that 1) needs me to do C++ work (I.e., I don't want a purely modelling/scripting task, unless you feel that's needed to get in to the C++ stage) 2) gives me a goal to aim towards such that I could also commit some useful for the project intermediate chunks/milestones (that I could polish until CVS integration before going on to the next one), keeping in mind that I'll learn along the way? I have around a day per week to commit to the coding, and I'll also read books atop of that. I'm willing to RTFM/read as much as possible as I go atop of that, too. Is there a good doc to get started with diving into the FG/SG graphics existing code base, other than the SG doxygen-generated pages? (If there is none, I'll log my learning trails in whoever asks for it next). I've read http://www.flightgear.org/goals.html , but it seems a bit outdated (BTW, is the site material in the CVS somewhere, so as to make it easier to send the patches against?) V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Speckle-Master 3000 DeLuxe Pro -- for theultimative despeckling experience
Dear Melchior, thanks a lot for the descpeckler script. I actually lifted it off your page yesterday and came on to the irc to say that it rocks, but you were not there. I used it on c150 which was the most irritating speckle-wise. I suggest you commit it to the utility scripts section of the FGFS source tree --- it is really a great tool with generic use. Are the offending faces needed at all? do they consume the polygon budget when 1-pixel-sized? * Vivian Meazza -- Sunday 30 October 2005 15:50: Melchior FRANZ Here's an example from the Hunter (which is meanwhile mostly fixed): Mostly? I thought we had fixed all such problems in the Hunter years ago?? Hunter has at least 2 nasty spots -- the black trapezes on the left canopy rail upper face inside the cockpit, one approx at the pilot's 10 o'clock, the other at 7.5. But they are not as distracting/annoying, esp. because one doesn't look there too often when flying forward :) I'm looking forward to have the despeckled aircraft committed to the data. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code
Since this got no bad comments, and since it fixes the bug, I suggest applying the patch. The tread starter, with the patch in there: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039770.html V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 feedback
On Thu, 27 Oct 2005, Harald JOHNSEN wrote: Bohnert Paul wrote: All, When the 150 was statred it was postioned with it's wheels below the runway surface. Adding z-m offset and [snip] You should try the lastest cvs version, commited a few days ago. The plane should be above the ground now. [snip] Harald, I still have problems with a CVS update from this morning. If, say, I appear at KSFO rwy 28R, and then use the Location dialog to reposition to LLBG rwy 3, I get the following (--log-level=info) lines and the model freezes: Deleting a sample Deleting a sample Deleting a sample Deleting a sample Deleting a sample Crash: Attempted to fly under ground. Playing audio after 14.8417 sec: intense ground contact However, if I just start up there, like fgfs --log-level=info --aircraft=c150 --airport=LLBG --runway=3 it works all right. Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] recent 737 autopilot change
In the recent 737 autopilot change, we see that the only improvement is the change of the target speet. diff -u -2 -r1.15 -r1.16 --- 737-set.xml 18 Oct 2005 16:32:23 - 1.15 +++ 737-set.xml 27 Oct 2005 08:34:40 - 1.16 @@ -110,5 +110,5 @@ target-altitude-ft type=double4000.0/target-altitude-ft heading-bug-deg type=double283.0/heading-bug-deg -target-speed-kt type=double200.0/target-speed-kt +target-speed-kt type=double165.0/target-speed-kt /settings /autopilot However, I am surprised to see that the target speed is hardwired here. AFAIK, the heavies use different target speeds dependant on the density altitude and aircraft landing weight. I don't know how big the difference can be within the possible range of the allowed landing weights. Can a 737 specialist sched some more light, please? V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] recent 737 autopilot change
On Thursday 27 Oct 2005 20:20, Vassilii Khachaturov wrote: In the recent 737 autopilot change, we see that the only improvement is the change of the target speet. [snip] Hello Vassilii, these aren't 'hardwired' values but defaults. The values declared here, in the aircraft 'set' file create the corresponding nodes in the property tree and their values can be changed using panel instruments, GUIs, the property browser, nasal scripts and the telnet and http interfaces. I certainly understand that one can change the property during runtime; I am definitely guilty of not reading into the aircraft model before righting the original mail in this thread. What is more, is that I missed the data/Aircraft/737/Systems 737-autopilotV4.xml update, where the actually important stuff had happened. I thus assumed that all the cure (in the log message that was common for both the changes) was in changing the above default, and hence inquired! sorry for wasting everybody's time... Vassilii ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c150 low G.
When this is done on the FG c150, the engine stutters (FDM program fuel starvation on neg-G?) According to the HUD, it stutters at about +0.30G. In the real aircraft, we could make 0G manouevers that could last for a couple of seconds without the engine missing. In a real gravity-fed Cessna, there are 2 aspects relevant to the engine problems resulting from negative Gs that I was told about by the instructors. One is the fuel flow (tanks/carb/engine intake manifold) and the other is the oil flow that has gravity-induced return of the oil into the sump. If that stops, it's as disastrous as oil leak --- permanent damage can be done. (As opposed to just engine out due to momentary fuel absense which goes away as soon as one pulls back up and the gravity is restored). I have no clue as to quantitative charasteristics of the two and which one happens first. (Sorry I don't have time for more research at the moment). As for the clearing the climb path, I was told to do some gentle S-turns rather than pushing over the nose in order not to screw up the airspeed and hence the time-to-climb calculations, as well as be less nauseating for the passengers (of course, if executed in a properly coordinated matter). V. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code (fwd)
reply from David -- Forwarded message -- Date: Mon, 24 Oct 2005 17:55:31 -0400 From: David Megginson To: Vassilii Khachaturov Subject: Re: [PATCH] [BUG] tmp-ly disable buggy mag compass jamming code (fwd) On 23/10/05, Vassilii Khachaturov [EMAIL PROTECTED] wrote: i've sent the letter below to your old address and it bounced; Erik Hofman has kindly given me this gmail address instead to contact you about the flightgear affairs. If you're still reading the Flightgear-devel@flightgear.org list, sorry for the redundancy. Thanks for copying me with that, Vassilii. I'm not keeping up with the FlightGear code now, so if everyone else thinks the change is a good idea, I have no objection. All the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] waterways ..W in your airport database
On Mon, 24 Oct 2005, Robin Peel wrote: Paul: In general, X-Plane only supports water runways at designated seaplane bases, not as additions to terrestrial airports (I forget the reason, I am afraid). I will look into whether they can be added back. I do recall that PHNL has this combination - as do a few airports in Alaska. - Robin Thanks for looking into that. I haven't seen those airports myself, and I wonder what the beacon lighting for those with the beacons are as per the AIM 2-1-8? White/green + Yellow alone? http://www.faa.gov/atpubs/AIM/Chap2/aim0201.html#2-1-8 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] cleanup of FlighGear and SimGear
http://caliban.lbl.gov/fgfs_patches/flightgear.diff
Great work. I wonder if there is a way to profile fg/sg for this kind
of inefficiencies somewhere in a tight loop.
A couple of comments:
diff -u -r1.43 AIBase.hxx
--- src/AIModel/AIBase.hxx 15 Oct 2005 14:55:51 - 1.43
+++ src/AIModel/AIBase.hxx 25 Oct 2005 06:59:49 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier, otBallistic,
otRocket, otStorm, otThermal, otStatic,
If you return the pos as a const Point3D, you should
probably mark the method to be const as well on the same occasion.
Also, by doing this change you vouch that *every* CALLER of the method
doesn't use the reference beyond the scope of the object's life
(should be fine if all that's done is a copy ctor right at the caller)
-- ignore me if you have checked this already.
Same with other similar changes (returning a const reference) further in
the patch.
diff -u -r1.8 ATCdisplay.hxx
--- src/ATC/ATCdisplay.hxx 30 Sep 2004 15:43:32 - 1.8
+++ src/ATC/ATCdisplay.hxx 25 Oct 2005 06:59:56 -
@@ -76,16 +76,16 @@
// Register a single message for display after a delay of delay
seconds
// Will automatically stop displaying after a suitable interval.
-void RegisterSingleMessage(string msg, double delay = 0.0);// OK -
I know passing a string in and out is probably not good but it will have to do
for now.
+void RegisterSingleMessage(const string msg, double delay = 0.0); // OK -
I know passing a string in and out is probably not good but it will have to do
for now.
Here it looks like you can safely remove the comment now :)
http://caliban.lbl.gov/fgfs_patches/simgear.diff
This one looks to me as containing some additional local changes you've
made, beyond the const optimization. See the chunks pertaining to
simgear/math/point3d.hxx
simgear/math/polar3d.hxx
and simgear/threads/SGThread.hxx
I suggest separating those away.
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Santa's r[ae]i?ndeer
Why are the bells commented out in raindeer-sound.xml? They do sound cute. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] problems experienced with the recent c150
On Mon, 24 Oct 2005, Martin Spott wrote: Vassilii Khachaturov wrote: H even an empty aircraft doesn't get blown away that easy. I can't believe it will be blown away by anything under 15 knots, especially with the brakes engaged. This is correct. At least you can land and taxi a C150 at 15 kts crosswind without significant trouble - not that I'd say that the C150 is well-suited for such strong wind :-) I was saying it won't be blown away or tumble due to wind even when *empty* (which is actually what is modelled now since it doesn't account for the pilot weight) when under 15 kts. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [PATCH] minor cleanup of ATCutils
-string ConvertRwyNumToSpokenString(string s) {
+string ConvertRwyNumToSpokenString(const string s) {
this should be string ConvertRwyNumToSpokenString(const string s)
so we don't make unnecessary copies.
-double dclGetHorizontalSeparation(Point3D pos1, Point3D pos2) {
+double dclGetHorizontalSeparation(const Point3D pos1, const Point3D pos2) {
same: const Point3D pos1, const Point3D pos2
I fully agree with your proposal.
all the functions are making unnecessary copies instead of passing by
reference. i've changed a lot of these for my local copy, so i can
submit a patch if there is interest.
Surely that's a beneficial change, so please submit, whether you're
talking about just the ATCutils module cleanup or of something with a
wider scope.
V.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: problems experienced with the recent c150 updates
Another problem I forgot to mention: before the update, I had the aircraft painted with a white-beige scheme outside (albeit one of the 2 sides was a mirror inverse of the other, including the tail number written in a mirrored font). After the update, it looks dull grayish on the outside, as if no paint were applied. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
