[Flightgear-devel] Re: Sim Reset
Alex Romosan [EMAIL PROTECTED] writes:
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.
sorry about the noise, it turns out i had two
delete GroundCallback;
in FGFDMExec::DeAllocate(void) (in src/FDM/JSBSim/FGFDMExec.cpp). it's
probably an artifact of the carrier patch. that aside, i guess it
would make sense to set the pointers to zero right after we delete
them so things like this won't happen again.
looking at FGFDMExec::DeAllocate(void) it also looks like there are
some pointers we are deleting without setting them to zero (even
later) (GroundCallback being one of them). maybe we can apply
something like this:
Index: src/FDM/JSBSim/FGFDMExec.cpp
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/FDM/JSBSim/FGFDMExec.cpp,v
retrieving revision 1.14
diff -u -r1.14 FGFDMExec.cpp
--- src/FDM/JSBSim/FGFDMExec.cpp11 Jun 2005 08:19:16 - 1.14
+++ src/FDM/JSBSim/FGFDMExec.cpp20 Dec 2005 08:18:32 -
@@ -271,40 +271,27 @@
bool FGFDMExec::DeAllocate(void)
{
- delete Atmosphere;
- delete FCS;
- delete Propulsion;
- delete MassBalance;
- delete Aerodynamics;
- delete Inertial;
- delete GroundReactions;
- delete Aircraft;
- delete Propagate;
- delete Auxiliary;
- delete Output;
- delete State;
+ delete Atmosphere; Atmosphere=0;
+ delete FCS; FCS=0;
+ delete Propulsion; Propulsion=0;
+ delete MassBalance; MassBalance=0;
+ delete Aerodynamics; Aerodynamics=0;
+ delete Inertial; Inertial=0;
+ delete GroundReactions; GroundReactions=0;
+ delete Aircraft; Aircraft=0;
+ delete Propagate; Propagate=0;
+ delete Auxiliary; Auxiliary=0;
+ delete Output; Output=0;
+ delete State; State=0;
- delete IC;
- delete Trim;
+ delete IC; IC=0;
+ delete Trim; Trim=0;
- delete GroundCallback;
+ delete GroundCallback; GroundCallback=0;
FirstModel = 0L;
Error = 0;
- State = 0;
- Atmosphere = 0;
- FCS = 0;
- Propulsion = 0;
- MassBalance = 0;
- Aerodynamics= 0;
- Inertial= 0;
- GroundReactions = 0;
- Aircraft= 0;
- Propagate = 0;
- Auxiliary = 0;
- Output = 0;
-
modelLoaded = false;
return modelLoaded;
}
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Mathias Fröhlich writes:
Hi,
On Monday 19 December 2005 14:10, Jon S. Berndt wrote:
When a sim reset is selected from the menu, what is the calling sequence to
the FDMs that follows? That is, which FGInterface functions are called (and
from where)? I thought that might be done from main.cxx, but I can't find
it
at the moment.
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 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
#3 0x0806c7fc in fgInitFDM () at fg_init.cxx:1331
#4 0x0806deaa in fgReInitSubsystems () at fg_init.cxx:1922
#5 0x08221e31 in reInit (cb=0x0) at gui_local.cxx:81
#6 0x0821c4ad in do_reinit_dialog (arg=0x89b1a00) at menubar.cxx:35
#7 0x0823c845 in FGBinding::fire (this=0xd1b2820) at input.cxx:132
#8 0x0823cd2c in FGInput::doKey (this=0xc1b1cb0, k=27, modifiers=6, x=631,
y=-13) at input.cxx:258
#9 0x0823b23d in keyHandler (key=27, keymod=6, mousex=631, mousey=-13)
at input.cxx:1120
#10 0x080888c4 in callKeyHandler (k=27, mods=6, x=631, y=-13) at fg_os.cxx:73
#11 0xb7db0c4b in processEventsAndTimeouts () at glut_event.c:546
#12 0xb7db10a5 in glutMainLoop () at glut_event.c:954
#13 0x0805aca2 in fgMainInit (argc=3, argv=0xbff962e4) at main.cxx:1007
#14 0x0805a489 in main (argc=3, argv=0xbff962e4) at bootstrap.cxx:193
i haven't had time to really look at it though, but it seems to happen
only with jsb planes. anybody else sees this? i have the carrier
patches applied to the jsb fdm.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Jon S. Berndt [EMAIL PROTECTED] writes:
0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
237 {
(gdb) where
#0 0x0019 in ~logstream (this=0xbd3d3e8) at logstream.hxx:237
#1 0x0812a812 in ~FGFDMExec (this=0xbd3d3e8) at FGFDMExec.cpp:173
#2 0x08113095 in ~FGJSBsim (this=0xb4b39e0) at JSBSim.cxx:308
What on earth is logstream?
it's in SimGear/simgear/debug/. it's a class to manage the debug
logging stream (and it seems to have a problem with the destructor).
i'll try to find some time and look at this a bit more carefully.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Sim Reset
Mathias Fröhlich [EMAIL PROTECTED] writes:
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.
Which aircraft, airport?
Commandline flags?
Your ~/.fgfs*?
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.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: compile problem with plib
Josh Babcock writes: looks like debian is broken. There was no link from libXmu.so to libXmu.so.6 in /usr/X11R6/lib. Thanks for the tip. For you Debian guys: Package Installed PreviousNow State ===-===-===-===-= libxmu6 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 6.8.2.dfsg.1-11 install you need to install the development packages as well. in this case you need libxmu-dev but it's probably better to install xlibs-dev which will pull in all the relevant packages. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Mathias Fröhlich [EMAIL PROTECTED] writes:
By the way: the right fix would be:
float
XDR_decode_float ( const xdr_data_t f_Val )
{
union {
float f;
xdr_data_t x;
} tmp;
tmp.x = XDR_decode_int32 (f_Val);
return tmp.f;
}
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
well, this is c++ so the appropriate fix would be
float
XDR_decode_float ( const xdr_data_t f_Val )
{
return (static_castfloat (XDR_decode_int32 (f_Val)));
}
i.e., we should be using static_cast.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/MultiPlayer tiny_xdr.cxx, 1.1, 1.2
Mathias Fröhlich writes:
Please use this one. And I believe, without looking into the code,
that there are likely more of them ...
please apply the attached patch which uses static_cast:
Index: src/MultiPlayer/tiny_xdr.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/MultiPlayer/tiny_xdr.cxx,v
retrieving revision 1.2
diff -u -r1.2 tiny_xdr.cxx
--- src/MultiPlayer/tiny_xdr.cxx 2 Dec 2005 00:10:25 - 1.2
+++ src/MultiPlayer/tiny_xdr.cxx 2 Dec 2005 07:12:41 -
@@ -122,42 +122,24 @@
xdr_data_t
XDR_encode_float ( const float f_Val )
{
-xdr_data_t* tmp;
-
-tmp = (xdr_data_t*) f_Val;
-return (XDR_encode_int32 (*tmp));
+return (XDR_encode_int32 (static_castxdr_data_t(f_Val)));
}
float
XDR_decode_float ( const xdr_data_t f_Val )
{
-float* tmp;
-static xdr_data_t dummy;
-
-dummy = XDR_decode_int32 (f_Val);
-tmp = (float*) dummy;
-return (*tmp);
+return (static_castfloat (XDR_decode_int32 (f_Val)));
}
/* double */
xdr_data2_t
XDR_encode_double ( const double d_Val )
{
-xdr_data2_t* tmp;
-
-tmp = (xdr_data2_t*) d_Val;
-return (XDR_encode_int64 (*tmp));
+return (XDR_encode_int64 (static_castxdr_data2_t (d_Val)));
}
double
XDR_decode_double ( const xdr_data2_t d_Val )
{
-double* tmp;
-static xdr_data2_t dummy;
-
-dummy = XDR_decode_int64 (d_Val);
-tmp = (double*) dummy;
-return (*tmp);
+return (static_castdouble (XDR_decode_int64 (d_Val)));
}
-
-
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff [EMAIL PROTECTED] writes:
I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt).
Briefly, since it's late, it's only included on the c172p 2D panel
(--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768
since the fonts are at 1:1 pixellation at that resolution.
the attached patch replaces passing strings by value with passing them
by reference (string - const string) to avoid copying them
needlessly. also makes GetId() in GPSPage a pure virtual function.
cvs diff: Diffing src/Instrumentation
Index: src/Instrumentation/dclgps.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/Instrumentation/dclgps.cxx,v
retrieving revision 1.1
diff -u -r1.1 dclgps.cxx
--- src/Instrumentation/dclgps.cxx 30 Nov 2005 00:47:41 - 1.1
+++ src/Instrumentation/dclgps.cxx 30 Nov 2005 23:12:19 -
@@ -194,8 +194,7 @@
void GPSPage::CleanUp() {}
void GPSPage::LooseFocus() {}
-void GPSPage::SetId(string s) {}
-string GPSPage::GetId() { return(); }
+void GPSPage::SetId(const string s) {}
// - //
@@ -888,7 +887,7 @@
return((xtd / _currentCdiScale) * 5.0 * 2.5 * -1.0);
}
-void DCLGPS::DtoInitiate(string s) {
+void DCLGPS::DtoInitiate(const string s) {
cout DtoInitiate, s = s '\n';
bool multi;
const GPSWaypoint* wp = FindFirstById(s, multi, true);
@@ -1013,7 +1012,7 @@
// returns -1 if groundspeed is less than 30kts.
// If the waypoint is an unreached part of the active flight plan the time will be via each leg.
// otherwise it will be a direct-to time.
-double DCLGPS::GetTimeToWaypoint(string id) {
+double DCLGPS::GetTimeToWaypoint(const string id) {
if(_groundSpeed_kts 30.0) {
return(-1.0);
}
@@ -1089,7 +1088,7 @@
return(-1);
}
-int DCLGPS::GetWaypointIndex(string id) {
+int DCLGPS::GetWaypointIndex(const string id) {
for(unsigned int i=0; i_flightPlans[0]-waypoints.size(); ++i) {
if(_flightPlans[0]-waypoints[i]-id == id) return((int)i);
}
@@ -1240,7 +1239,7 @@
/***/
-const GPSWaypoint* DCLGPS::ActualFindFirstById(string id, bool exact) {
+const GPSWaypoint* DCLGPS::ActualFindFirstById(const string id, bool exact) {
gps_waypoint_map_const_iterator itr;
if(exact) {
itr = _waypoints.find(id);
@@ -1255,7 +1254,7 @@
}
}
-const GPSWaypoint* DCLGPS::FindFirstById(string id, bool multi, bool exact) {
+const GPSWaypoint* DCLGPS::FindFirstById(const string id, bool multi, bool exact) {
multi = false;
if(exact) return(ActualFindFirstById(id, exact));
@@ -1317,7 +1316,7 @@
// Host specific lookup functions
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-FGNavRecord* DCLGPS::FindFirstVorById(string id, bool multi, bool exact) {
+FGNavRecord* DCLGPS::FindFirstVorById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
//if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1336,7 +1335,7 @@
return(NULL); // Shouldn't get here!
}
#if 0
-Overlays::NAV* DCLGPS::FindFirstVorById(string id, bool multi, bool exact) {
+Overlays::NAV* DCLGPS::FindFirstVorById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1386,7 +1385,7 @@
#endif //0
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-FGNavRecord* DCLGPS::FindFirstNDBById(string id, bool multi, bool exact) {
+FGNavRecord* DCLGPS::FindFirstNDBById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
//if(exact) return(_overlays-FindFirstVorById(id, exact));
@@ -1405,7 +1404,7 @@
return(NULL); // Shouldn't get here!
}
#if 0
-Overlays::NAV* DCLGPS::FindFirstNDBById(string id, bool multi, bool exact) {
+Overlays::NAV* DCLGPS::FindFirstNDBById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
multi = false;
if(exact) return(_overlays-FindFirstNDBById(id, exact));
@@ -1455,7 +1454,7 @@
#endif //0
// TODO - add the ASCII / alphabetical stuff from the Atlas version
-const FGFix* DCLGPS::FindFirstIntById(string id, bool multi, bool exact) {
+const FGFix* DCLGPS::FindFirstIntById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set, and indeed can't be
// since FG can only map one Fix per ID at the moment.
multi = false;
@@ -1516,7 +1515,7 @@
return NULL; // Don't think we can ever get here.
}
-const FGAirport* DCLGPS::FindFirstAptById(string id, bool multi, bool exact) {
+const FGAirport* DCLGPS::FindFirstAptById(const string id, bool multi, bool exact) {
// NOTE - at the moment multi is never set.
//cout FindFirstAptById, id = id '\n';
multi = false;
Index: src/Instrumentation/dclgps.hxx
[Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
David Luff writes: Alex Romosan writes: David Luff [EMAIL PROTECTED] writes: Urgghh - email addy in header! sorry. if anybody knows how to change the citation line in gnus automatically please let me know. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: 0.9.9 compile problem
Curtis L. Olson [EMAIL PROTECTED] writes: What compiler are you using. This looks a bit strange. Most often, ifyou link against a library, it only pulls in the required routines from that library and ignores everything else. But in this case it almost looks like your linker is requiring all symbols in the libsgenvironment.a to get resolved, even if they are part of functions that aren't referenced or used. The sgi compilers have this tendency, but gcc is usually very smart about this. The quick fix would be to add the additional libs ... -lsgmath -lplibsg -lGL, etc. But it would be interesting to know which compiler you are using to see if it makes sense that it should squawk about this or not ... Regards, Curt. Brian Thomason wrote: I'm attempting to compile FlightGear 0.9.9 on Linspire 5.0. Compiling simgear 0.9.9 went fine, but FlightGear fails with the following error: / g++ -DPKGLIBDIR=\/usr/share/games/FlightGear\ -g -O2 -D_REENTRANT -L/usr/X11R6/lib -L/usr/lib -o metar metar_main.o -lsgenvironment -lsgio -lsgbucket -lsgmisc -lsgstructure -lsgdebug -lsgprops -lsgserial -lsgxml -lplibnet -lplibul -lz -ldl -lm -ljpeg /usr/lib/libsgenvironment.so: undefined reference to `ssgContext::loadModelviewMatrix(float (*) [4])' /usr/lib/libsgenvironment.so: undefined reference to `glRotatef' /usr/lib/libsgenvironment.so: undefined reference to `sgMakeRotMat4(float (*) [4], float, float const*)' /usr/lib/libsgenvironment.so: undefined reference to `sg_random' /usr/lib/libsgenvironment.so: undefined reference to `glVertex3f' /usr/lib/libsgenvironment.so: undefined reference to `calc_gc_lon_lat(Point3D const, double, double)' /usr/lib/libsgenvironment.so: undefined reference to `SGCloudField::CloudVis' /usr/lib/libsgenvironment.so: undefined reference to `SGSoundSample::set_source_pos(float*)' /usr/lib/libsgenvironment.so: undefined reference to `sgMakeCoordMat4(float (*) [4], float, float, float, float, float, float)' /usr/lib/libsgenvironment.so: undefined reference to `SGBbCache::startNewFrame()' /usr/lib/libsgenvironment.so: undefined reference to `SGCloudField::get_CacheSize()' /usr/lib/libsgenvironment.so: undefined reference to `glDisable' /usr/lib/libsgenvironment.so: undefined reference to `glDepthMask' /usr/lib/libsgenvironment.so: undefined reference to `glBegin' /usr/lib/libsgenvironment.so: undefined reference to he is linking against shared libraries. i see the same thing (having modified my build environment a long time ago to build shared libraries) but in my case i just modified the Makefiles and added the extra libraries needed. and, yes, there are a lot of interdependencies (including circular ones) between the simgear libraries that don't show up in the current makefiles. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: OT: FYI, mac os x developers,
Jeff McBride [EMAIL PROTECTED] writes: On 11/12/05, Arthur Wiebe [EMAIL PROTECTED] wrote: adjustment. So what is the argument here against topposting? http://www.caliburn.nl/topposting.html --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] nimitz despeckle
can somebody with cvs access please run ac3d-despeckle on nimitz.ac and commit the fixed version? i have one of those older nvidia cards and the flicker is annoying. i can confirm that running ac3d-despeckle fixes the flickering. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear v0.9.9-pre2
Ampere K. Hardraade [EMAIL PROTECTED] writes: A bit off topic: does anyone have success in compiling FlightGear and related libaries using GCC-4.0? I want to get my system sorted before I test the pre-release, but I might ended up not being able to test FlightGear if GCC-4.0 has trouble compiling FlightGear. i am using gcc (GCC) 4.0.3 20051023 (prerelease) (Debian 4.0.2-3) and i din't have any problems compiling flightgear (or if i did i have patches, i guess). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FlightGear v0.9.9-pre2
Ima Sudonim [EMAIL PROTECTED] writes: I have only one problem, building src/FlightGear/src/Instrumentation/ od_gauge.cxx. I mentioned it in october here: Alex, I guess you're not seeing this problem with 4.0.3? Nice to know it's been fixed! (assuming it's not a private patch) 8-) Now if only apple would update to 4.0.3... i never had any problems compiling od_gauge.cxx. looking at the message you mentioned, i see that at line 54 of SimGear/simgear/structure/event_mgr.hxx there is a empty declaration of check(); just comment out that line, i guess, it's not being used/declared anywhere else. or remove it entirely. this should actually be applied to cvs: --- simgear/structure/event_mgr.hxx 3 May 2004 18:39:25 - 1.6 +++ simgear/structure/event_mgr.hxx 10 Nov 2005 05:48:10 - @@ -51,7 +51,6 @@ void siftDown(int n); void siftUp(int n); void growArray(); -void check(); double _now; HeapEntry *_table; --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] cleanup of FlighGear and SimGear
Vassilii Khachaturov [EMAIL PROTECTED] writes: 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. i haven't seen my previous patches (the message was blocked because of its size and it was waiting the moderator's approval). anyway, i've updated the patches and put them on the web. you can get them from: http://caliban.lbl.gov/fgfs_patches/flightgear.diff http://caliban.lbl.gov/fgfs_patches/simgear.diff --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: FlightGear/src/Main metar_main.cxx, 1.9, 1.10
Erik Hofman [EMAIL PROTECTED] writes:
Update of /var/cvs/FlightGear-0.9/FlightGear/src/Main
In directory baron:/tmp/cvs-serv17258
Modified Files:
metar_main.cxx
Log Message:
I guess there was something in Alex' patch that wasn't all that fortunate.
Index: metar_main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/metar_main.cxx,v
retrieving revision 1.9
retrieving revision 1.10
diff -C2 -r1.9 -r1.10
*** metar_main.cxx25 Oct 2005 13:49:57 - 1.9
--- metar_main.cxx25 Oct 2005 16:28:46 - 1.10
***
*** 28,32
#include simgear/environment/metar.hxx
#include simgear/structure/exception.hxx
- #include simgear/scene/sky/sky.hxx
using namespace std;
--- 28,31
***
*** 486,491
}
- SGSky* thesky = new SGSky;
-
int main(int argc, char *argv[])
{
--- 485,488
sorry about this, but when i link against shared libraries i need this
otherwise i get:
g++ -DPKGLIBDIR=\/usr/local/share/FlightGear\ -g -O2 -D_REENTRANT
-L/usr/X11R6/lib -L/usr/local/lib -o metar metar_main.o -lsgenvironment -lsgio
-lsgbucket -lsgmisc -lsgstructure -lsgdebug -lsgprops -lsgxml -lsgserial
-lsgsound -lsgsky -lsgmaterial -lsgscreen -lsgmath -lplibssg -lplibsg -lglut
-lGLU -lGL -lXmu -lXt -lSM -lICE -lXi -lXext -lX11 -ldl -lm -lplibnet -lplibul
-lz -ldl -lm -lexpat -lalut -lopenal -ldl -lm -lpthread -lalut
/usr/local/lib/libsgsky.so: undefined reference to `thesky'
collect2: ld returned 1 exit status
i am not sure exactly _why_ it works for static libraries.
anyway, this doesn't affect anybody else (unless they use shared
libraries like me).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] cleanup of FlighGear and SimGear
Vassilii Khachaturov [EMAIL PROTECTED] writes:
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.hxx15 Oct 2005 14:55:51 - 1.43
+++ src/AIModel/AIBase.hxx25 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.
this change is okay. i am not sure what you mean by marking the
method to be const but if it's this:
inline const Point3D GetPos() const
that would mean it acts on a const object which is what we want anyway
(but not necessarily). so can we apply this patch as well:
Index: src/AIModel/AIBase.hxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/AIModel/AIBase.hxx,v
retrieving revision 1.43
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 17:15:33 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() const { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier, otBallistic,
otRocket, otStorm, otThermal, otStatic,
thanks.
btw, there are still some more cleanups i would like to do so get
ready for a second round (provided i manage to find some time soon).
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes:
I attach a diff against CVS - HEAD which I applied to get CVS to compile
under Cygwin. It may not be the best or preferred way to do it, but the
patch works here, so far as I can see.
diff -u -w -b -r1.11 AIFlightPlan.hxx
--- AIFlightPlan.hxx25 Oct 2005 13:49:56 - 1.11
+++ AIFlightPlan.hxx25 Oct 2005 19:17:09 -
@@ -77,14 +77,14 @@
time_t getStartTime() { return start_time; };
voidcreate(FGAirport *dep, FGAirport *arr, int leg, double alt, double
speed, double lat, double lon,
-bool firstLeg, double radius, const string fltType, const
string aircraftType, const string airline);
+bool firstLeg, double radius, string fltType, string
aircraftType, string airline);
void setLeg(int val) { leg = val;};
void setTime(time_t st) { start_time = st; };
int getGate() { return gateId; };
double getLeadInAngle() { return leadInAngle; };
- const string getRunway() { return rwy._rwy_no; };
- const string getRunwayId() { return rwy._id; };
+ string getRunway() { return rwy._rwy_no; };
+ string getRunwayId() { return rwy._id; };
void setRepeat(bool r) { repeat = r; };
bool getRepeat(void) { return repeat; };
void restart(void);
why do you need to do this? what was the error when trying to compile
the cvs version?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS:FlightGear/src/ATCAIEntity.cxx, 1.12,
Vivian Meazza [EMAIL PROTECTED] writes: Alex Romosan asked: Vivian Meazza [EMAIL PROTECTED] writes: The function in AIFlightPlan.cxx was not defined in AIFlightPlan.hxx so far as the compiler was concerned. It now compiles and runs OK i don't understand. does the cvs version compile or do you still have to make those changes to get it to compile? Before I made the corrections cvs failed to compile. After I made the corrections (those in the diff) cvs compiled and ran. this is why i would've have liked to see the original error message. if the compiler didn't like those changes here it should've not liked them everywhere else. unfortunately i don't have cygwin installed to compile it myself. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] [PATCH] cleanup of FlighGear (part ii)
i tried to make sure accessor functions which return by reference act
on const objects. also replaced some iterators with const_iterator
and a few return/pass by reference that were missed the first time
around:
Index: src/AIModel/AIAircraft.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIAircraft.hxx,v
retrieving revision 1.15
diff -u -r1.15 AIAircraft.hxx
--- src/AIModel/AIAircraft.hxx 4 Jun 2005 09:38:52 - 1.15
+++ src/AIModel/AIAircraft.hxx 26 Oct 2005 01:05:25 -
@@ -61,7 +61,7 @@
void SetPerformance(const PERF_STRUCT *ps);
void SetFlightPlan(FGAIFlightPlan *f);
-FGAIFlightPlan* GetFlightPlan() { return fp; };
+FGAIFlightPlan* GetFlightPlan() const { return fp; };
void AccelTo(double speed);
void PitchTo(double angle);
void RollTo(double angle);
Index: src/AIModel/AIBase.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIBase.hxx,v
retrieving revision 1.43
diff -u -r1.43 AIBase.hxx
--- src/AIModel/AIBase.hxx 15 Oct 2005 14:55:51 - 1.43
+++ src/AIModel/AIBase.hxx 26 Oct 2005 01:05:25 -
@@ -108,7 +108,7 @@
FGAIBase();
virtual ~FGAIBase();
virtual void update(double dt);
-inline Point3D GetPos() { return(pos); }
+inline const Point3D GetPos() const { return(pos); }
enum object_type { otNull = 0, otAircraft, otShip, otCarrier, otBallistic,
otRocket, otStorm, otThermal, otStatic,
Index: src/AIModel/AIFlightPlan.cxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIFlightPlan.cxx,v
retrieving revision 1.13
diff -u -r1.13 AIFlightPlan.cxx
--- src/AIModel/AIFlightPlan.cxx 25 Oct 2005 13:49:56 - 1.13
+++ src/AIModel/AIFlightPlan.cxx 26 Oct 2005 01:05:25 -
@@ -295,8 +295,8 @@
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getPreviousWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getPreviousWaypoint( void ) const
{
if (wpt_iterator == waypoints.begin()) {
return 0;
@@ -306,14 +306,14 @@
}
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getCurrentWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getCurrentWaypoint( void ) const
{
return *wpt_iterator;
}
-FGAIFlightPlan::waypoint*
-FGAIFlightPlan::getNextWaypoint( void )
+FGAIFlightPlan::waypoint* const
+FGAIFlightPlan::getNextWaypoint( void ) const
{
wpt_vector_iterator i = waypoints.end();
i--; // end() points to one element after the last one.
@@ -344,7 +344,7 @@
}
// gives distance in feet from a position to a waypoint
-double FGAIFlightPlan::getDistanceToGo(double lat, double lon, waypoint* wp){
+double FGAIFlightPlan::getDistanceToGo(double lat, double lon, waypoint* wp) const{
// get size of a degree2 at the present latitude
// this won't work over large distances
double ft_per_deg_lat = 366468.96 - 3717.12 * cos(lat / SG_RADIANS_TO_DEGREES);
@@ -386,12 +386,12 @@
}
-double FGAIFlightPlan::getBearing(waypoint* first, waypoint* second){
+double FGAIFlightPlan::getBearing(waypoint* first, waypoint* second) const{
return getBearing(first-latitude, first-longitude, second);
}
-double FGAIFlightPlan::getBearing(double lat, double lon, waypoint* wp){
+double FGAIFlightPlan::getBearing(double lat, double lon, waypoint* wp) const{
double course, distance;
// double latd = lat;
// double lond = lon;
Index: src/AIModel/AIFlightPlan.hxx
===
RCS file: /var/cvs/FlightGear-0.9/source/src/AIModel/AIFlightPlan.hxx,v
retrieving revision 1.11
diff -u -r1.11 AIFlightPlan.hxx
--- src/AIModel/AIFlightPlan.hxx 25 Oct 2005 13:49:56 - 1.11
+++ src/AIModel/AIFlightPlan.hxx 26 Oct 2005 01:05:25 -
@@ -62,37 +62,37 @@
const string airline);
~FGAIFlightPlan();
- waypoint* getPreviousWaypoint( void );
- waypoint* getCurrentWaypoint( void );
- waypoint* getNextWaypoint( void );
+ waypoint* const getPreviousWaypoint( void ) const;
+ waypoint* const getCurrentWaypoint( void ) const;
+ waypoint* const getNextWaypoint( void ) const;
void IncrementWaypoint( bool erase );
- double getDistanceToGo(double lat, double lon, waypoint* wp);
- int getLeg () { return leg;};
+ double getDistanceToGo(double lat, double lon, waypoint* wp) const;
+ int getLeg () const { return leg;};
void setLeadDistance(double speed, double bearing, waypoint* current, waypoint* next);
void setLeadDistance(double distance_ft);
double getLeadDistance( void ) const {return lead_distance;}
- double getBearing(waypoint* previous, waypoint* next);
- double getBearing(double lat, double lon, waypoint* next);
- time_t getStartTime() { return start_time; };
+ double getBearing(waypoint* previous, waypoint* next) const;
+ double
[Flightgear-devel] Re: [PATCH] minor cleanup of ATCutils
Vassilii Khachaturov [EMAIL PROTECTED] writes: 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. i just posted the patches but at ~100KB the message awaits the moderators approval. if it doesn't make it to the list i'll try to make the patches available on my web server. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [PATCH] minor cleanup of ATCutils
Vassilii Khachaturov [EMAIL PROTECTED] writes:
-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
and so on.
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.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Never ending story: Building SimGear CVS under Cygwin
Richard Harke [EMAIL PROTECTED] writes: freeglut is an alternative to glut, not to OpenGL mesa is an alternative to OpenGL but it does not have the performance required for FG Normally you need to get 3D accelerated drivers from the vendor of your video card, Nvidia or ATI, for example. this is wrong. i use mesa and the open source radeon 3d drivers (out of mesa) together with xorg and drm from cvs and i can run flightgear on my laptop (an ibm thinkpad t40 with an ati firegl 9000 card) without any problems. the open source drivers are actually faster than the ati ones because i can run them at 16bpp (the ati drivers run only at 24bpp). oh, and i can suspend my laptop which is impossible with the ati drivers. so please don't spread such nonsense. first of all, mesa as an opengl implementation is completely different from mesa providing 3d acceleration. second, for supported cards (which are quite a lot of them, with the exception of nvidia cards) the open source 3d drivers are very good. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: CVS: data/Navaids TACAN_freq.dat.gz, NONE, 1.1
Erik Hofman [EMAIL PROTECTED] writes: Update of /var/cvs/FlightGear-0.9/data/Navaids In directory baron:/tmp/cvs-serv24190 Added Files: TACAN_freq.dat.gz Log Message: Add misiing file --- NEW FILE --- hmm, there seems to be a lot of junk in this file: [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@0 13611^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@^@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@ [EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@[EMAIL PROTECTED]@Channel Reply_Freq.(Khz) 001X9620 001Y10880 i think you need to mark this as a binary file in cvs. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Melchior FRANZ [EMAIL PROTECTED] writes: On Wed, Aug 24, 2005 at 01:47:12PM -0700, Alex Romosan wrote: http://weather.noaa.gov/pub/data/observations/metar/stations/KSFO.TXT 2005/08/24 17:56 KSFO 241756Z 04005KT 10SM FEW010 19/12 A2983 RMK AO2 SLP101 T01940122 10194 20122 51005 but right now the time is: Wed Aug 24 20:45:35 UTC 2005 so this would make the metar data too old indeed. The date from the data set says when the data were acquired. If you are sure that your computer has the time correctly set, then this simply *is* old data. Could be that NOAA hasn't updated in time, or that you are running over a proxy that doesn't work correctly. Try without http proxy. as far as i know i am not using an http proxy and the time is set correctly (i am very sure of this). i've been looking at the metar code but it's a hopeless mess. in the meantime i've lost my temperature and visibility etc. (they are all set to zero). it must be some change i made but a cvs diff doesn't show any relevant changes. strange, very strange. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Alex Romosan [EMAIL PROTECTED] writes: no, the time is set correctly. the problem seems to be with the data source (but i don't understand why nobody else sees this). if i go to http://weather.noaa.gov/pub/data/observations/metar/stations/KSFO.TXT i get: 2005/08/24 17:56 KSFO 241756Z 04005KT 10SM FEW010 19/12 A2983 RMK AO2 SLP101 T01940122 10194 20122 51005 but right now the time is: Wed Aug 24 20:45:35 UTC 2005 so this would make the metar data too old indeed. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Melchior FRANZ [EMAIL PROTECTED] writes: On Mon, Aug 22, 2005 at 03:03:11PM -0700, Alex Romosan wrote: looking at the trace logs it looks like fgfs goes through every metar station out there: Initializing environment subsystem 2005/08/22 14:56 KSFO 221456Z 0KT 10SM SCT007 OVC010 13/11 A2995 RMK AO2 SLP142 T01280106 53002 METAR from weather.noaa.gov METAR data too old no metar at metar = KSFO Check if your system time is set correctly. If it's running in the future or past, every metar data set will be too old/new and fgfs searches for an acceptable one. (It should probably stop trying after the first 10 failed sets.) no, the time is set correctly. i think the problem might be with timegm() (now that i think about it, this might have started happening when debian switched to a new version of libc) but i am still trying to understand the logic. anyway, there is a bug in there for sure, fgfs shouldn't go and fetch the metar data for the whole world regardless of the time. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] very long startup time
for a while now i've been noticing that flightgear takes an incredible amount of time to start. today i attached gdb to the fgfs process and this is what i got: #1 0x08410bde in netSocket::select (reads=0xbfa895c0, writes=0xbfa895c8, timeout=0) at netSocket.cxx:384 #2 0xb7e99b3c in SGSocket::poll (this=0xd689420) at sg_socket.cxx:392 #3 0xb7e9b424 in SGSocket::readline (this=0xd689420, buf=0xbfa8966c 1124746455, length=512) at sg_socket.cxx:256 #4 0xb7dd3d09 in SGMetar::loadData (this=0xd158aa0, id=0xd158ab4 KHOU, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], time=1124746455) at metar.cxx:218 #5 0xb7dd91ec in SGMetar (this=0xd158aa0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], time=1124746455) at metar.cxx:90 #6 0x083f3e77 in FGMetar (this=0xd158aa0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at fgmetar.cxx:45 #7 0x083e93f0 in FGMetarEnvironmentCtrl::fetch_data (this=0xcb59ef0, [EMAIL PROTECTED]) at environment_ctrl.cxx:545 #8 0x083eb1bf in FGMetarEnvironmentCtrl::init (this=0xcb59ef0) at environment_ctrl.cxx:403 #9 0xb7df0acf in SGSubsystemGroup::init (this=0xcb593a0) at subsystem_mgr.cxx:92 #10 0x083e3ee6 in FGEnvironmentMgr::init (this=0xcb593a0) at environment_mgr.cxx:66 #11 0xb7df0acf in SGSubsystemGroup::init (this=0x88ad5fc) at subsystem_mgr.cxx:92 i am starting at the default airport (KSFO) so i wonder why we are even trying to load the data for KHOU (which is in huston)? could it be we are trying to load the metar data for all the airports? does anybody have any idea what's going on? btw, this is on linux. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: very long startup time
Alex Romosan [EMAIL PROTECTED] writes: i am starting at the default airport (KSFO) so i wonder why we are even trying to load the data for KHOU (which is in huston)? could it be we are trying to load the metar data for all the airports? does anybody have any idea what's going on? looking at the trace logs it looks like fgfs goes through every metar station out there: Initializing environment subsystem 2005/08/22 14:56 KSFO 221456Z 0KT 10SM SCT007 OVC010 13/11 A2995 RMK AO2 SLP142 T01280106 53002 METAR from weather.noaa.gov METAR data too old no metar at metar = KSFO 2005/08/22 14:53 KOAK 221453Z 22006KT 10SM OVC006 13/12 A2996 RMK AO2 SLP145 T01330117 53002 $ METAR from weather.noaa.gov METAR data too old no metar at metar = KOAK 2005/08/22 14:54 KHWD 221454Z 30003KT 10SM OVC007 14/12 A2995 RMK AO2 SLP151 T01390117 53003 METAR from weather.noaa.gov METAR data too old no metar at metar = KHWD 2005/08/16 13:56 KNUQ 161356Z 33003KT 9SM OVC011 17/14 A2999 RMK AO2 SLP159 T01670139 $ METAR from weather.noaa.gov METAR data too old no metar at metar = KNUQ 2005/08/22 15:20 KLVK 221520Z 23004KT 7SM SCT007 13/12 A2993 RMK AO2 METAR from weather.noaa.gov METAR data too old no metar at metar = KLVK 2005/08/22 14:53 KCCR 221453Z 23005KT 10SM CLR 14/11 A2993 RMK AO2 SLP120 T01390106 53005 METAR from weather.noaa.gov METAR data too old no metar at metar = KCCR 2005/08/22 15:53 KSJC 221553Z 0KT 8SM FEW006 BKN011 BKN020 15/12 A2995 RMK AO2 SLP140 T01500117 METAR from weather.noaa.gov METAR data too old no metar at metar = KSJC 2005/08/22 14:54 KAPC 221454Z 28004KT 2SM BR OVC004 13/12 A2994 RMK AO2 SLP131 T01280117 53006 METAR from weather.noaa.gov METAR data too old no metar at metar = KAPC 2005/08/22 14:55 KSUU 221455Z 25012KT 20SM SKC 15/12 A2991 RMK SLP129 53010 METAR from weather.noaa.gov METAR data too old no metar at metar = KSUU 2005/08/22 14:53 KVCB 221453Z AUTO 22004KT 10SM CLR 18/12 A2989 RMK AO2 SLP118 T01780117 51009 METAR from weather.noaa.gov METAR data too old no metar at metar = KVCB 2005/08/22 15:53 KWVI 221553Z AUTO 0KT 2 1/2SM BR OVC001 13/12 A2995 RMK AO2 SLP141 T01280117 METAR from weather.noaa.gov METAR data too old no metar at metar = KWVI 2005/08/22 15:23 KSTS 221523Z 0KT 1/2SM FG OVC001 11/11 A2994 RMK AO2 METAR from weather.noaa.gov METAR data too old no metar at metar = KSTS 2005/08/22 14:55 and so on something's very wrong here. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Dave Culp [EMAIL PROTECTED] writes:
I just downloaded the latest OpenAL from CVS and can't get SimGear
to compile with it. Here's the error:
apply this patch
--- openal_test1.cxx30 Apr 2004 00:44:04 - 1.5
+++ openal_test1.cxx21 Jun 2005 23:03:38 -
@@ -39,7 +39,7 @@
int main( int argc, char *argv[] ) {
// initialize OpenAL
-alutInit( 0, NULL );
+alutInit( 0, NULL, NULL);
alGetError();
if ( alGetError() != AL_NO_ERROR) {
SG_LOG( SG_GENERAL, SG_ALERT, Audio initialization failed! );
it's not like we are using the context anyway.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Dave Culp [EMAIL PROTECTED] writes: Just curious ... Is there any reason why OpenAl doesn't offer stable releases? probably because it's still under development? on their web page (openal.org) they say they are migrating to openal 1.1 specifications. as such i would expect some changes in the api. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: latest OpenAL not compatable?
Andy Ross [EMAIL PROTECTED] writes: Maybe the best thing to do is just to remove this test application from the source tree. Does the fgfs build still work? i don't think i had any problems with the build. the cvs version has this in AL/alctypes.h #define ALC_MAJOR_VERSION0x1000 #define ALC_MINOR_VERSION0x1001 and in AL/altypes.h #define AL_VERSION0xB002 not sure how these changed wrt to previous releases. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Karsten Krispin [EMAIL PROTECTED] writes: yes. would be cool if you send me a patch. this is the patch: patch.simgear.bz2 Description: simgear as shared lib the last part gets simgear to use a system installed expat lib, so you might not want to apply it. after you apply the patch you need to run libtoolize (so you need libtool installed) and then run ./autogen.sh and configure, etc. What's about the lifetime of the patch, where is it applied? How far is it affected trough the cvs? i am not sure i understand this. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Martin Spott [EMAIL PROTECTED] writes: Hello Karsten, Karsten Krispin wrote: just a small question: is it hard to include simgear as shared libs? No, it's not dificult at all. But you probably don't _want_ to, because changes in FlightGear sometimes relate to changes in SimGear so you have to rebuild SimGear anyway. I'd stick to static libs, especially since rebuilding SimGear doesn't take that long - compared to FlightGear, that was exactly the original problem: changes in simgear would involve a full recompilation of flightgear if you use static libraries. and compiling flightgear does take a very long time. now, if you use dynamic libraries, you can make your change in simgear and just go fly right away... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: SimGear as shared lib
Karsten Krispin [EMAIL PROTECTED] writes: just a small question: is it hard to include simgear as shared libs? When you want to change something in simgear you have to recompile fgfs. that needs pretty too long. i can send you a patch (i've been building simgear as shared libs for the longest time) or you can take a look at the debian simgear source package and fashion a patch from that. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: plib release
David Megginson [EMAIL PROTECTED] writes: On Wed, 05 Jan 2005 12:58:57 -0800, Alex Romosan [EMAIL PROTECTED] wrote: i see the same thing (instruments are holes in the panel on the dhc2) on linux/nvidia with the latest plib from cvs. Are you running at 16 bpp or 24 bpp? 24 bpp. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: VBOs - performance test
Paul Surgeon [EMAIL PROTECTED] writes: On Friday, 15 October 2004 22:04, Horst J. Wobig wrote: If somebody wants to try it on his box: just fetch lesson 45 from http://nehe.gamedev.net. On windows this should compile without problems, on linux you need sdl. It segfaults in glGenBuffersARB () on my system. Mandrake 9.1, Ti 4200, nVidia 6111 works fine on a radeon mobility 9000 m9 with the open source drivers (this is a thinkpad t40). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: VBOs - performance test
Horst J. Wobig [EMAIL PROTECTED] writes: Alex Romosan wrote: works fine on a radeon mobility 9000 m9 with the open source drivers (this is a thinkpad t40). Thanks. Have you tried with #define NO_VBOS? What is the difference in framerate? nevermind. turns out ARB_vertex_buffer_object is not supported by my current configuration. i am trying to figure out why (looking at the code, the r200 driver defines it, but glxinfo doesn't show it). sorry for the noise. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: VBOs - performance test
Alex Romosan [EMAIL PROTECTED] writes: Horst J. Wobig [EMAIL PROTECTED] writes: Alex Romosan wrote: works fine on a radeon mobility 9000 m9 with the open source drivers (this is a thinkpad t40). Thanks. Have you tried with #define NO_VBOS? What is the difference in framerate? nevermind. turns out ARB_vertex_buffer_object is not supported by my current configuration. i am trying to figure out why (looking at the code, the r200 driver defines it, but glxinfo doesn't show it). sorry for the noise. managed to get direct rendering working again (so ARB_vertex_buffer_object is defined). running lesson45 i get 80-100 fps with VBOS enabled. when i disable VBOS i get the same result, so it looks like, at least for this card, there is no performance gain when using VBOS. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo104 - patch
Melchior FRANZ [EMAIL PROTECTED] writes: So far we have only one user who disagrees with realistic collective, so we might not even need a property. Just revert part of today's patch. :-) i am not the only one who disagrees with the realistic collective (but you can choose to ignore any messages you don't agree with). but to tell you the truth, i don't really care. i know enough to configure fgfs to do what _i_ want. one could argue that flying a helicopter using the keyboard is not realistic. nevertheless, i find it very confusing pressing PageUp to go down, and vice versa. also, i always use the HUD and to see the throttle indicator go down when i want to go up is one more source of confusion. sorry to have brought this up. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ [EMAIL PROTECTED] writes: * Alex Romosan -- Saturday 07 August 2004 01:19: as a matter of fact it does seem that european helicopters behave differently from american ones. Yes, you are right, sorry. I was slightly pissed, because if felt as if you needlessly dragged my country into the matter, only because we didn't agree on technical ground, as if you wanted to say that Austrians (unlike US citizens) do probably not understand much of helicopters. :-) i am not a us citizen and never will (even though i live in the us now) :-) i thought the same might apply to the collective. OK. It doesn't, as others have meanwhile explained. Anyway: I wasn't aware how difficult the bo is actually to fly with just the keyboard. Accidently, I installed fgfs today on a computer at a Red Cross office (for the people on duty to make time pass faster), and it took me *quite* a while to even lift of. (We don't have a js there ... yet.) I'll try to submit a fix tomorrow. I insist on the throttle being inverted on the js, but the keyboard is a different matter. There'll certainly be a viable solution. how about we just reverse the PageUp and PageDown keys (and also add the 1 and 2 key bindings) and get the helicopter to start with the throttle at 100% so it doesn't just take off on you when you start the rotor. this way nothing will change for the joystick users, and for those of us who use the keyboard the bindings will make more sense (up will make the helicopter go up and down will make it go down). what do you say? Sorry again :-] don't worry, it happens. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] bo105 + patch
recently i took a helicopter tour of san francisco, so i decided to play a little bit more with the helicopter simulation in fgfs. it's a lot of fun. a couple of things though. i use the keyboard mappings and a mouse to fly and i noticed that the collective is mapped backwards (up goes down and down goes up). also i find PageUp and PageDown to be cumbersome, so i mapped the collective to the 1 and 2 keys (so i can use my left hand). with these changes i managed to hover and even land on top of the buildings in downtown sf. i've collected some of the screenshots at http://caliban.lbl.gov/fgfs-heli/index.html. for comparison (although we didn't land on top of any of the buildings :-( ) the real pictures of sf are at http://caliban.lbl.gov/sfhelitour/index.html. attached is the patch: ? bo105.patch cvs diff: Diffing . Index: bo105-set.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105-set.xml,v retrieving revision 1.10 diff -u -r1.10 bo105-set.xml --- bo105-set.xml 6 Aug 2004 11:12:32 - 1.10 +++ bo105-set.xml 6 Aug 2004 19:25:11 - @@ -153,6 +153,28 @@ /binding /key + key n=49 +name1/name +descCollective Down/desc +binding + commandnasal/command + script + controls.incThrottle(-0.01, -1.0) + /script +/binding + /key + +key n=50 +name2/name +descCollective Up/desc +binding +commandnasal/command +script +controls.incThrottle(0.01, 1.0) +/script +/binding +/key + /keyboard /input Index: bo105.xml === RCS file: /var/cvs/FlightGear-0.9/data/Aircraft/bo105/bo105.xml,v retrieving revision 1.9 diff -u -r1.9 bo105.xml --- bo105.xml 6 Aug 2004 11:12:33 - 1.9 +++ bo105.xml 6 Aug 2004 19:25:11 - @@ -34,7 +34,7 @@ control-input axis=/controls/flight/elevator control=CYCLICELE src0=-1.0 src1=1.0 dst0=-1.0 dst1=1.0/ - control-input axis=/controls/engines/engine[1]/throttle control=COLLECTIVE + control-input axis=/controls/engines/engine[1]/throttle control=COLLECTIVE invert=true src0=-0.0 src1=1.0 dst0=1.0 dst1=-1.0/ control-input axis=/controls/engines/engine[0]/magnetos control=ROTORENGINEON/ cvs diff: Diffing Instruments cvs diff: Diffing Instruments/asi cvs diff: Diffing Instruments/tach cvs diff: Diffing Models --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ [EMAIL PROTECTED] writes: * Alex Romosan -- Friday 06 August 2004 21:31: and i noticed that the collective is mapped backwards (up goes down and down goes up). Yes, and that's the way it should be and there's no way in hell to have this changed. If you don't like how helicopters work, don't fly them. There are enough fixed wing aircrafts. PLEASE DON'T APPLY! okay, then you should change the default so the helicopter starts with the collective up so the helicopter doesn't just take off once you start the rotor. as for the there's no way in hell to have this changed i beg to differ: i've already made the change in my local copy and i intend to keep that way :-) also i find PageUp and PageDown to be cumbersome, so i mapped the collective to the 1 and 2 keys (so i can use my left hand). Collective is where all aircrafts have the throttle. That's because there's no alternative for the collective on joysticks other than the throttle. I don't mind *additional* keys for collective, though. i am not sure what the collective has to do with the throttle. if i understand this correctly, the collective changes the pitch of the rotor blades. i thought helicopters don't have a throttle the way fixed wing aircraft do: i.e. the engine is always at a constant rpm. but then i am not a helicopter pilot so i might be wrong. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ [EMAIL PROTECTED] writes: * Alex Romosan -- Friday 06 August 2004 21:31: and i noticed that the collective is mapped backwards (up goes down and down goes up). Yes, and that's the way it should be and there's no way in hell to have this changed. If you don't like how helicopters work, don't fly them. There are enough fixed wing aircrafts. PLEASE DON'T APPLY! one more thing. i just went to http://science.howstuffworks.com/helicopter6.htm and they have a video on how the collective control works (http://static.howstuffworks.com/mpeg/heli-collective.mpg). you can clearly hear the woman say that if you lift the collective you increase the pitch of the blades so you get more lift and you'll go up. so it would seem that collective up means helicopter goes up. maybe in austria they do it differently. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Melchior FRANZ [EMAIL PROTECTED] writes: * Alex Romosan -- Saturday 07 August 2004 00:36: you can clearly hear the woman say that if you lift the collective you increase the pitch of the blades so you get more lift and you'll go up. so it would seem that collective up means helicopter goes up. maybe in austria they do it differently. Chauvinist bullshit ends every discussion, thanks. as a matter of fact it does seem that european helicopters behave differently from american ones. http://www.helicopterpage.com/html/terms.html would seem to indicate the rotor spins in different directions. there is a nice description there of the takeoff procedure. the relevant passage is: As you increase collective pitch, you need to push the left pedal (In American helicopters...right pedal for non-American models) to counteract the torque you generate by increasing pitch. and on the page describing the forces at work http://www.helicopterpage.com/html/forces.html the author states: The thrust it produces tends to push the aircraft sideways at a hover. We compensate for this by adding left cyclic control inputs (On American Helicopters, the opposite in foreign manufactured aircraft, because their rotor systems turn the opposite way from ours). This makes the helicopter hang left skid, or wheel, low at a hover. so i am not sure why you are upset. i thought the same might apply to the collective. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: bo105 + patch
Jim Wilson [EMAIL PROTECTED] writes: Those photos are really are nice! Wow! Mind me asking what you took them with? i have a sony dsc-f717 digital camera (but now i want the dsc-f828 :-( ) the original pictures are 2560x1920 though. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Frederic Bouvier [EMAIL PROTECTED] writes:
Is there a way to avoid the initial lock for scenery loading ?
I understand this is a must have for users, but it slows
down development speed dramatically when you have to test the
apparence of a new building or landmark.
i think the fix for the scenery loading is not quite right. with it i
get a very strange spitfire cockpit (i.e. i can see through the
instrument panel and the body of the aircraft). looks like z-buffer
ordering is not done properly (screen depth is 16bp, using the radeon
freedesktop drivers). if i disable it, the cockpit looks normal again.
if could only figure out how to start the damn plane...
btw, the attached patch backs out of the scenery loading hack.
Index: main.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/main.cxx,v
retrieving revision 1.173
diff -u -r1.173 main.cxx
--- main.cxx 23 Jul 2004 07:33:24 - 1.173
+++ main.cxx 24 Jul 2004 18:27:09 -
@@ -1209,13 +1209,13 @@
if ( global_multi_loop 0) {
// first run the flight model each frame until it is intialized
// then continue running each frame only after initial scenery load is complete.
-if (!cur_fdm_state-get_inited() || fgGetBool(sim/sceneryloaded)) {
+//if (!cur_fdm_state-get_inited() || fgGetBool(sim/sceneryloaded)) {
fgUpdateTimeDepCalcs();
-} else {
-// only during scenery load
-NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
-gui-showDialog(scenery_loading);
-}
+//} else {
+//// only during scenery load
+//NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
+//gui-showDialog(scenery_loading);
+//}
} else {
SG_LOG( SG_ALL, SG_DEBUG,
Elapsed time is zero ... we're zinging );
@@ -1339,12 +1339,12 @@
// END Tile Manager udpates
-if (!fgGetBool(sim/sceneryloaded) globals-get_tile_mgr()-all_queues_empty() cur_fdm_state-get_inited()) {
-fgSetBool(sim/sceneryloaded,true);
+//if (!fgGetBool(sim/sceneryloaded) globals-get_tile_mgr()-all_queues_empty() cur_fdm_state-get_inited()) {
+//fgSetBool(sim/sceneryloaded,true);
// probably not efficient way to popup msg, but is done only during scenery load
-NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
-gui-closeDialog(scenery_loading);
-}
+//NewGUI * gui = (NewGUI *)globals-get_subsystem(gui);
+//gui-closeDialog(scenery_loading);
+//}
if (fgGetBool(/sim/rendering/specular-highlight)) {
glLightModeli(GL_LIGHT_MODEL_COLOR_CONTROL, GL_SEPARATE_SPECULAR_COLOR);
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Is 'Scenery Loading...' mandatory ?
Vivian Meazza [EMAIL PROTECTED] writes:
It starts exactly the way it says in the POH.
Magneto switches to on, advance throttle a little, press start button, keep
pressed until engine fires.
so, in terms of keyboard commands this should be { } (magneto switches
on) and then press space bar?
If it fails to fire, re-index the Coffman starter by pulling the ringpull,
then try again. You have 6 cartridges.
it does. so i press C and try space bar again. the propeller sputters
a bit and that's it.
To stop, pull the cut-off ring pull.
i'll deal with that once i manage to start the engine... :-)
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: --fog-fastest --fog-disabled - the latter w/o update below horizon ?
Chris Metzler [EMAIL PROTECTED] writes: Regarding the navaids discussion I'd like to know if airports are currently exclusively bound to the scenery, actually I was looking for some airports that FlightGear also finds, but didn't see any rwys - if airports should really depend on specific scenery to be installed, it might be worth to think about separating airports from scenery - at least the basics like runways etc ...or what else is the reason for not _seeing_ an airport which FlightGear actually knows of ? Can you rephrase this? I can't figure out what it is that you're saying here. the graphics part of the airports _is_ part of the scenery. FlightGear looks up the latitude and longitude and the position and heading of the runways (in runways.dat) but if the scenery is not there there are no graphics to be loaded so you get positioned over the ocean. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Concorde
Curtis L. Olson [EMAIL PROTECTED] writes: I have commited a first stab at a Concorde model, first created by Melchior and the further enhanced by Thierry (a mailing list reader, but non-poster.) However, when I try to run it with the latest cvs version of FG, I get an endless string of: Unknown identifier: EOF in engine file: Olympus593Mrk610 Unknown identifier: EOF in engine file: Olympus593Mrk610 Unknown identifier: EOF in engine file: Olympus593Mrk610 Unknown identifier: EOF in engine file: Olympus593Mrk610 Unknown identifier: EOF in engine file: Olympus593Mrk610 Unknown identifier: EOF in engine file: Olympus593Mrk610 copy direct.xml from some other engine directory to Aircraft/Concorde/Engines. it worked for me. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke [EMAIL PROTECTED] writes: On Sunday 27 June 2004 07:18 pm, Alex Romosan wrote: Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- This is on Linux ia64 My main point was intended to be the comment which says don't use the handle after dlclose i am not using the handle after dlclose() is being called. the handle is used _before_, when it's passed at to dlsym(). i actually looked at the implementation of dlsym in glibc and what i proposed is safe as the pointer returned is resolved in the scope of the main program. remember, i noticed the crash on linux running kernel 2.6 with tls. the way we used to do it, we set the pointer outside the scope of the main program by explicitly passing libGL to dlopen. we set the pointer in this scope, but we used it in the scope of the main program _after_ we called dlclose() and unmapped libGL in that particular scope. by calling dlopen(0,...) we resolve the symbol in the scope of the main program so it is safe to use after we call dlclose(). it's not that hard. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Andy Ross wrote: Erik Hofman wrote: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. In which case the dlclose() is 100% guaranteed to be a noop anyway and can be safely removed. :) Seriously: consider the case where this symbol came out of a library that we *don't* link to statically. Why would I? Then this would undeniably be a bug, because the library would be unmapped before the function could be called. Honestly, this code is just wrong. No it's not. I can't see a case where a program that relies so heavily on OpenGL wouldn't link to the GL library at link time. you are mixing static and dynamic linking. andy is talking about dynamic linking. i am not sure what you are talking about. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patchincluded)
Frederic Bouvier [EMAIL PROTECTED] writes: I was not understanding Erik point of view of advocating a patently broken code but now I am really missing your point :-( i just posted a fix which should work on both linux and irix (and any other unix). i need somebody to test the irix part. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patchincluded)
Alex Romosan [EMAIL PROTECTED] writes: Frederic Bouvier [EMAIL PROTECTED] writes: I was not understanding Erik point of view of advocating a patently broken code but now I am really missing your point :-( i just posted a fix which should work on both linux and irix (and any other unix). i need somebody to test the irix part. just beating a dead horse: erik, are you sure RTLD_DEFAULT is not defined on irix? solaris has it, linux has it. take a look in /usr/include/dlfcn.h and see what's in there. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: Alex Romosan wrote: Frederic Bouvier writes: The fact that you are using the function pointer *after* dlclose is as broken as Erik's version. This is not good practise to bet on side effects that are beyond your control. _NO_, because the pointer now points to an object in memory in the scope of the program which is guaranteed to be always the same. this is equivalent to just calling dlsym(RTLD_DEFAULT,func). incidentally, on linux RTLD_DEFAULT is defined to be 0, but on solaris is -2. i wish i still had an irix machine So you're just guessing. The cvs version is assured to work on any system. guessing about what? the version in cvs is ugly because it never calls dlclose(). the last version i proposed assigns a pointer in the scope of the program which is guaranteed to stay same for the lifetime of the program (even after calling dlclose()). no guessing there. the irix 5.3 man page states that dlopen(0,...) is supported on irix as well so that solution is portable. i wish i still had an irix machine so i could look if RTLD_DEFAULT is defined in dlfcn.h. if it is, we can then call dlsym(RTLD_DEFAULT,func) directly. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction(patch included)
Richard Harke [EMAIL PROTECTED] writes: In dlfcn.h we find: /* Unmap and close a shared object opened by `dlopen' The handle cannot be used again after calling `dlclose'. */ extern int dlclose (void *__handle) __THROW; Also RTLD_DEFAULT is a gnu extension and requires __USE_GNU to be defined are you talking about linux or irix? the above looks like the dlfcn.h from glibc on linux. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Since FlightGear is linked to libGL at link time, the number of dlclose calls would always be one less than the number of dlopen calls. this is wrong. the whole idea of linking against a shared library is that you load only the symbols you need. it doesn't mean the library is loaded in memory all the times (that will defeat the whole idea of shared libraries). linking against a shred library doesn't count as a dlopen(). the address the library is loaded at depends on how libc implements it. for linux, the core dump happens when one uses kernel 2.6 and tls enabled. the point is that there is no guarantee the pointer is still valid once you call dlclose(). if you want to guarantee the pointer to the function is still valid after calling dlclose() you hvae to call dlopen() on libGL yourself one more time outside the lookup function. that way the library will stay in the memory all the time (but this is still not a good solution). the only good solution is to make sure you use the pointer before calling dlclose() and that means moving it out of SGLookupFunction() (and hence getting rid of SGLookupFunction). you should also do some error checking with dlerror() for completeness. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes: Unfortunately RTLD_DEFAULT isn't supported on all platforms (it isn't supported in IRIX anyhow). I think that if what you describe is the problem this really is a bug at your side. What happens is that the function pointer is copied to ftpr. So dlcose() should never be able to have any effects on this copy ?? dlclose() doesn't have the effect on the pointer. it just makes that pointer point to something non-existent once the handle becomes invalid, hence the core dump. what you have there is bad programing practice. if you do a search for dlclose and dlsym you will see that nobody uses the pointer returned by dlsym() _after_ a call to dlclose() --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: So, if the library is really unloaded, the pointer access should be really undefined and could lead to a segfault. Anyway, is it really mandatory to do dlclose after getting the pointer ? It is if we do dlopen every time we get a pointer, but the handle could be allocated only once and stored for subsequent lookup. that was my original fix: comment out the call to dlclose(). if we keep things the way they are now, we should probably call dlopen() once, pass the handle, and at the end call dlclose(). SGLookupFunction() should just call dlsym(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Frederic Bouvier [EMAIL PROTECTED] writes: There is probably no problem of not doing dlclose at all. Standard process exit routine should do it for us. So we could write : static void *handle = 0; if ( !handle ) handle = dlopen(); fct = dlsym(); return fct; or we can call dlopen() on libGL once somewhere at the beginning to make sure libGL stays loaded in memory even after calling dlclose(). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: problem with SGLookupFunction (patch included)
Erik Hofman [EMAIL PROTECTED] writes:
I think that if what you describe is the problem this really is a
bug at your side. What happens is that the function pointer is
copied to ftpr. So dlcose() should never be able to have any effects
on this copy ??
erik, maybe this test program will help you understand the problem:
#include stdio.h
#include dlfcn.h
#include stdlib.h
inline void (*lookup(const char *func))()
{
void *handle;
void (*fptr)();
char *error;
handle = dlopen (libm.so, RTLD_LAZY);
if (!handle) {
fprintf (stderr, %s\n, dlerror());
exit(1);
}
dlerror();/* Clear any existing error */
fptr = (void (*)()) dlsym(handle, cos);
if ((error = dlerror()) != NULL) {
fprintf (stderr, %s\n, error);
exit(1);
}
printf (%f\n, (*((double (*)(double))fptr))(2.0));
dlclose(handle);
return fptr;
}
int main(int argc, char **argv)
{
double (*fptr)(double) = (double (*)(double)) lookup(cos);
printf (%f\n, fptr(2.0));
}
compile as such: g++ -o foo foo.c -ldl and then run ./foo. on my
machine i get:
-0.416147
Segmentation fault
the first result is printed before calling dlclose(). libm is still
loaded in memory and the pointer is valid. after we call dlclose()
fptr is still the same (it's a copy after all) but libm is now
unloaded and fptr points to never-never land, so we core dump. if you
comment out dlclose() then the second printf works as well.
does this help you understand the problem?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] problem with SGLookupFunction (patch included)
trying to debug why i wasn't able to run flightgear on my laptop, i think i found a problem with SGLookupFunction. the problem is that we call dlclose() before we return the pointer to the GL function, and, if i understand things correctly, this invalidates the handle and the address might not be valid anymore (on my laptop i kept getting core dumps). anyway the fix is very simple: instead of calling dlopen() on libGL and then passing the libGL handle to dlsym() one can simply invoke dlsym on RTLD_DEFAULT (which is a special pseudo-handler that will find the first occurrence of the desired symbol using the default library search order). now i can run flightgear on both my laptop (with a radeon mobility card) and on my desktop (nvidia card) and i think the clouds actually look much better. this is the patch: RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/extensions.hxx,v retrieving revision 1.13 diff -u -r1.13 extensions.hxx --- simgear/screen/extensions.hxx 21 May 2004 14:50:49 - 1.13 +++ simgear/screen/extensions.hxx 23 Jun 2004 01:08:01 - @@ -69,12 +69,7 @@ // GLX extension is *not* guaranteed to be supported. An alternative // dlsym-based approach will be used instead. -void *libHandle; -void (*fptr)(); -libHandle = dlopen(libGL.so, RTLD_LAZY); -fptr = (void (*)()) dlsym(libHandle, func); -dlclose(libHandle); -return fptr; +return (void (*)()) dlsym(RTLD_DEFAULT, func); #endif } --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: New Scenery - a few notes
Durk Talsma [EMAIL PROTECTED] writes: I'm only a bit dissapointed that nobody's yet reported actually _seeing_ one of MD11's take off. :-) :-) i just did :-) took off from SFO and followed it for a couple of hours to the canadian border (i guess i was bored). a few nits: when i sped up the game (by pressing the 'a' key) the md11 didn't speed up (so this was a quick way of catching up with it). second, although it initially climbed to about 22000 feet, by the time i stopped following it it was down to about 16000. normal airliners fly at about 4 so this is probably a bug in the planning. third, i was flying the t38 but the md11 didn't show up on the radar (the two 737's did, as well as some other plane unknown plane). this probably has something to do with the md11 model. speaking of the radar, i find it strange that my plane shows up on the radar in the centre. anyway, i took some pictures along the way, you can find them at: http://caliban.lbl.gov/fgfs-md11/ --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fw: FlightGear/src/SceneryFGTileLoader.cxx, 1.7, 1.8
Frederic Bouvier [EMAIL PROTECTED] writes:
Norman Vine wrote:
Alex Romosan writes:
Norman Vine [EMAIL PROTECTED] writes:
Doesn't SGPath.apapend just do the right thing here ?
i.e. there shouldn't be a need to do the
! #ifdef _MSC_VER
! tmp.append( ;);
! #else
! tmp.append( :);
! #endif
kludge in the patch below
if append() doesn't do the right thing I suggest we would be
better off fixing append() rather then kludging every instance
of it use.
we should use sgDirPathSep instead. it's defined in
simgear/misc/sg_path.cxx, but it should be moved to the header file
instead so it can be used elsewhere.
Agreed but
append() should/will just do this automagically :-)
// append another piece to the existing path
void SGPath::append( const string p ) {
if ( path.size() == 0 ) {
path = p;
} else {
if ( p[0] != sgDirPathSep ) {
path += sgDirPathSep;
}
path += p;
}
fix();
}
sgDirPathSep is ':' for macintosh, or '/' for other systems. It is the
character that is between a parent and a child folder in a path, not
the one between 2 valid path. It that file, it is called sgSearchPathSep
and is used only in sgPathSplit, not in SGPath::append( const string ).
Maybe we need a SGPathList object for that matter.
sorry, i meant sgSearchPathSep (as you correctly point out). the more
i look at the code in sg_path.cxx, the more confused i get. what
exactly is it being fixed by SGPath::fix()?
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Fw: FlightGear/src/Scenery FGTileLoader.cxx, 1.7, 1.8
Norman Vine [EMAIL PROTECTED] writes: Doesn't SGPath.apapend just do the right thing here ? i.e. there shouldn't be a need to do the ! #ifdef _MSC_VER ! tmp.append( ;); ! #else ! tmp.append( :); ! #endif kludge in the patch below if append() doesn't do the right thing I suggest we would be better off fixing append() rather then kludging every instance of it use. we should use sgDirPathSep instead. it's defined in simgear/misc/sg_path.cxx, but it should be moved to the header file instead so it can be used elsewhere. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
Curtis L. Olson [EMAIL PROTECTED] writes: How do I turn off the bump mapped cloud feature? Under some conditions it looks great, and other times it looks horrible. I'd like to turn it off to compare. Here's what I'm seeing right now at KSFO: http://www.flightgear.org/~curt/tmp/clouds.jpg i see the same thing (only on my desktop with an nvidia card. on my laptop with an ati card i don't see it at all) but setting /sim/rendering/bump-mapping=false didn't help. i actually starting seeing this when some recent changes to the cloud rendering were made, but i can't find the cvs commit message to know what to revert. maybe erik can help since i am pretty sure it was his commit. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: bump map clouds
Frederic Bouvier [EMAIL PROTECTED] writes: I am surprised --prop:/sim/rendering/bump-mapping=false don't work for you. I am also able to turn it on and off with the property browser during flight. it turns the bump mapping off but the ugly clouds are still there. i am convinced it has something to do with some other cloud rendering changes. this all started to happen with a 2 line commit, or something like that. i've been trying to track it down. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: De-glutification, stage one
Andy Ross [EMAIL PROTECTED] writes: OK, I've just commited the hard part of deglutification. All glut dependencies in the source tree are now isolated in Main/fg_os.cxx. something broke. if i do a ctrl-v to come back to the cockpit view the mouse gets reset to pointer mode even though i had it in fly control mode (the pointer stays the same, but i have to cycle through the modes back to fly control to regain control of the airplane). also, the h key doesn't toggle the hud views anymore (but i am not sure if this is related to the deglutification changes or was intentionally removed). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] compile problem
SimGear/simgear/screen/screen-dump.hxx uses GLubyte but doesn't include the relevant GL headers (and causes the compilation of cvs fgfs to crash). this patch fixes the problem: --- a/screen-dump.hxx 7 Sep 2002 02:58:19 - 1.1.1.1 +++ b/screen-dump.hxx 31 Mar 2004 23:06:31 - @@ -22,6 +22,7 @@ // // $Id: screen-dump.hxx,v 1.1.1.1 2002/09/07 02:58:19 curt Exp $ +#include GL/gl.h /** * Dump the screen buffer to a ppm file. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] crash in FGAIPlane::Update(double)
i haven't been able to use flightgear for the past couple of days as it crashes in FGAIPlane::Update(double) (actually it doesn't quite crash, the sim just freezes and i have to kill it from the command prompt). this is the gdb backtrace: 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98, dt=0.039636) at AIPlane.cxx:124 124 while((track - _tgtTrack) 180.0) track -= 360.0; (gdb) where #0 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98, dt=0.039636) at AIPlane.cxx:124 #1 0x080a9e1a in FGAIGAVFRTraffic::Update(double) (this=0xd4dee98, dt=0.039636) at AIGAVFRTraffic.cxx:116 #2 0x0809df5c in FGAIMgr::update(double) (this=0x92efae8, dt=0.039636) at AIMgr.cxx:307 #3 0x0805b82e in fgMainLoop () at globals.hxx:263 #4 0x4020c84a in glutMainLoop () from /usr/local/lib/libglut.so.3 #5 0x0805df18 in fgMainInit(int, char**) (argc=1, argv=0xb614) at main.cxx:1706 #6 0x080588f9 in main (argc=223221810, argv=0xd4e1832) at bootstrap.cxx:139 i haven't tried to understand the code yet, as i am hoping a more knowledgeable person will figure out what's happening and fix it. thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crash in FGAIPlane::Update(double)
Alex Romosan [EMAIL PROTECTED] writes:
i haven't been able to use flightgear for the past couple of days as
it crashes in FGAIPlane::Update(double) (actually it doesn't quite
crash, the sim just freezes and i have to kill it from the command
prompt). this is the gdb backtrace:
0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98,
dt=0.039636) at AIPlane.cxx:124
124 while((track - _tgtTrack) 180.0) track -= 360.0;
(gdb) where
#0 0x080d49fe in FGAIPlane::Update(double) (this=0xd4dee98,
dt=0.039636) at AIPlane.cxx:124
#1 0x080a9e1a in FGAIGAVFRTraffic::Update(double) (this=0xd4dee98,
dt=0.039636) at AIGAVFRTraffic.cxx:116
#2 0x0809df5c in FGAIMgr::update(double) (this=0x92efae8,
dt=0.039636) at AIMgr.cxx:307
#3 0x0805b82e in fgMainLoop () at globals.hxx:263
#4 0x4020c84a in glutMainLoop () from /usr/local/lib/libglut.so.3
#5 0x0805df18 in fgMainInit(int, char**) (argc=1, argv=0xb614)
at main.cxx:1706
#6 0x080588f9 in main (argc=223221810, argv=0xd4e1832) at bootstrap.cxx:139
i haven't tried to understand the code yet, as i am hoping a more
knowledgeable person will figure out what's happening and fix it. thanks.
i looked at the code in AIPlane.cxx:122
if(_trackSet) {
while((_tgtTrack - track) 180.0) track += 360.0;
while((track - _tgtTrack) 180.0) track -= 360.0;
double turn_time = 60.0;
track += (360.0 / turn_time) * dt * (_tgtTrack track ? 1.0 : -1.0);
Bank(25.0 * (_tgtTrack track ? 1.0 : -1.0));
track is defined as a protected member but i can't figure out where
it's set prior to this. it's not initialized in the constructor
(should it be set to zero?), or from anywhere else. when the program
crashes, track has some huge value. is it garbage? this code was added
in the last revision, so i am sure this is what is causing the crash.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Eye candy
Vivian Meazza [EMAIL PROTECTED] writes: In which case we could standardise, if standardise we must for minor controls, on j/J/CTRL J for jettison, and k/K for spoilers. We will soon run out of keys unless we are careful. any capital letter requires both hands so it makes it hard to use it while you fly. i like the two lower case letters for the spoilers so i can extend and retract the spoilers as i wish when i come in for landing (probably a habit acquired flying gliders). actually, if you want to use lower/upper case combination s/S would be ideal (let's move the swap panels to something else. let s stand for spoilers). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Eye candy
Melchior FRANZ [EMAIL PROTECTED] writes: spoiler bindings are now (AFAIK) only used by UIUC aircrafts. There's also Ctrl-B for speed brake bindings. They seem to be used for one and the same thing on airliners, which is, again, a bad thing. spoilers are devices designed to reduce lift and also increase drag. they are usually attached to wings. speed brakes are attached to the fuselage and produce drag without affecting lift. airliners have spoilers, fighter jets usually have speed brakes (although the yf-23 seems to have spoilers). the gliders i fly have spoilers (even though sometimes we call them speed brakes). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: saving fgfs replay session
Jim Wilson [EMAIL PROTECTED] writes: Very nice landing. Did you make any attempt to get audio? i fly with sound disabled, so there was no audio... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: saving fgfs replay session
Jorge Van Hemelryck [EMAIL PROTECTED] writes: Try xvidcap... I haven't managed to really make a movie file with it yet, but that's what it's supposed to do. thanks. xvidcap worked great. i put the movie up at: http://caliban.lbl.gov/fgfs-carrier.mpeg the file is 33548 kB, and the movie is 800x600 in mpeg4 format. unfortunately the frame rate dropped to about 11fps (because of the recording). --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] saving fgfs replay session
is there a way to save the fgfs replay session? i managed to land the the yf-23 on the aircraft carrier and i want to save the flight (or at least the movie) for posterity :-) does anybody know of some tool that would record the display and create a movie under linux? thanks. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Building Mesa...
Gene Buckle [EMAIL PROTECTED] writes: In trying to build plib, it tells me I need glut. No biggie, right? Mesa has that so I'll just build it. I downloaded v5.0.2 and after ./configure, I try making. It explodes instantly with: [EMAIL PROTECTED] Mesa-5.0.2]$ make cd . /bin/sh ./config.status conf.h config.status: creating conf.h config.status: conf.h is unchanged make all-recursive make[1]: Entering directory `/home/geneb/Mesa-5.0.2' Making all in include make[2]: Entering directory `/home/geneb/Mesa-5.0.2/include' Making all in GL make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include/GL' make[3]: Nothing to be done for `all'. make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include/GL' make[3]: Entering directory `/home/geneb/Mesa-5.0.2/include' make[3]: Nothing to be done for `all-am'. make[3]: Leaving directory `/home/geneb/Mesa-5.0.2/include' make[2]: Leaving directory `/home/geneb/Mesa-5.0.2/include' Making all in src make[2]: Entering directory `/home/geneb/Mesa-5.0.2/src' Making all in math make[3]: Entering directory `/home/geneb/Mesa-5.0.2/src/math' /bin/sh ../../libtool --mode=compile gcc -DHAVE_CONFIG_H -I. -I. -I../.. -I../../include -I../../src-g -O2 -Wall -fomit-frame-pointer -ffast-math -fexpensive-optimizations -fstrict-aliasing -malign-loops=2 -malign-jumps=2 -malign-functions=2 -D_REENTRANT -DPTHREADS -c -o m_debug_clip.lo `test -f 'm_debug_clip.c' || echo './'`m_debug_clip.c ../../libtool: s%^.*/%%: No such file or directory ../../libtool: -e: command not found ../../libtool: -e: command not found this is a bug in libtool. you need to do 'export SED=/bin/sed' (or 'setenv SED /bin/sed' depending on your shell) before building. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: SRTM 1 arcsec trial
Frederic Bouvier [EMAIL PROTECTED] writes: I am playing with SRTM-1 too. I started terrafit with --error=2 and --maxnodes=2000 ( after the patch to terrafit.py ) and I must say it is very impressive to see in action. But I found glitches that are quite obvious, and that do not appear in the scenery made by Alex Romosan ( certainly with default options, before the patch ) : it seems that the buildings are buried in the terrain, with small pikes. i never ran terrafit. i just followed the instructions at http://www.terragear.org/docs/scenery-tutorial/fg-scenery-tutorial.html what does terrafit do? do i need to run it before generating the scenery? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: SRTM 1 arcsec trial
Curtis L. Olson [EMAIL PROTECTED] writes: The latest terragear code in cvs expects the .fit files to exist. i used the latest code in cvs and terragear didn't complain at all about the missing .fit files. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] new scenery for w130n30 using 1 arcsec data
i regenerated the scenery for w130n30 using the 1 arcsec data available from http://edcwww.cr.usgs.gov/pub/data/srtm/United_States_1arcsec/1arcsec/ a lot of details show up now (like the hills of san francisco which i am painfully aware they exist since i live there and walk almost every day to the top of nob hill from the bart). you can see a couple of comparison pictures at http://caliban.lbl.gov/fgfs/ the pictures on the left were taken with the new scenery, the ones on the right with the old. i also made the new scenery available for download from http://caliban.lbl.gov/fgfs/w130n30/ i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). hope somebody finds this useful. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Alex Romosan [EMAIL PROTECTED] writes: i need to figure out how to put the buildings back (do i just copy the objects from the old directories?). nevermind. i figured it out. seemed to have lost the sutro tower though. undoubtedly because it's under the hills somewhere (and most of the buildings are low now). how do i change the height where the building is positioned? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: new scenery for w130n30 using 1 arcsec data
Frederic Bouvier [EMAIL PROTECTED] writes: It looks a lot better, and the polygon count is not so huge. To correct building height, get this file : http://perso.wanadoo.fr/frbouvi/flightsim/942066.stg and put it in w123n37. Or use fgsd. thanks. i copied the file and the buildings are positioned as they should be. Download would be easier if there was a tarball ;-) this is a link to the actual directory where fgfs keeps the scenery. just use 'wget -r' to get the whole directory recursively. btw, i am in the process regenerating the scenery using the same 1 arcsec data for w080n40. hopefully canadian data will also be included. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: scenery doesn't load after cvs update
Matevz Jekovec [EMAIL PROTECTED] writes:
Yesterday's CVS works fine on my machine (except disappearing sound,
but that's probably plib and new sound card issue).
found the bug:
diff -u -r1.2 FGTileLoader.cxx
--- FGTileLoader.cxx8 Aug 2003 20:11:22 - 1.2
+++ FGTileLoader.cxx8 Aug 2003 22:43:47 -
@@ -97,7 +97,7 @@
tmp.set( globals-get_fg_scenery() );
} else {
tmp.set( globals-get_fg_root() );
- tile_path.append( Scenery );
+ tmp.append( Scenery );
}
tile_path = tmp.str();
beenhere = true;
this is in src/Scenery.
--alex--
--
| I believe the moment is at hand when, by a paranoiac and active |
| advance of the mind, it will be possible (simultaneously with |
| automatism and other passive states) to systematize confusion |
| and thus to help to discredit completely the world of reality. |
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] scenery doesn't load after cvs update
today's cvs update seems to have broken the loading of the scenery. does anybody else see this? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Still linker error in today's FlightGear
Erik Hofman [EMAIL PROTECTED] writes: Martin Spott wrote: Hello, today I encountered linker errors on SuSE-8.1/i386. As I understand this does not depend on the tool chain: Did you already try this: You will either have to do a make clean or remove the following files by hand: Cockpit/hud.o GUI/gui.o GUI/gui_funcs.o Main/main.o Main/options.o Main/util.o i see the same thing and i even made a distclean beforehand. anyway, looking at src/Include/config.h is see that both FG_MPLAYER_AS and FG_NETWORK_OLK are defined. shouldn't the new multiplayer mode disable the old network code? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: J3 Cub won't converge
Andy Ross [EMAIL PROTECTED] writes: OK, fixed. The model was almost converging, but wasn't getting close enough to the threshold. It was oscillating around the right values, but each iteration moved to far to be considered done. This is a problem with this kind of heuristic. Just moving the solution precision targets a tiny bit was sufficient to fix the problem. I should probably make this number settable in the configuration file, for aircraft that run into problems. after updating to the latest cvs, i can't fly the a4-yasim anymore: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to -0.000431126ft... ...initializing sea-level radius... lat = 37.6117 alt = -0.000431126 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 9.68511 Lift Ratio: 168.785 Cruise AoA: 2.77861 Tail Incidence: -3.89015 Approach Elevator: -0.557698 CG: -0.721, -0.000, 0.092 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations i wonder if the above-mentioned fixed broke the a4? the j3cub works. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgfs crashing at CYYZ
i get a crash trying to fly the a4-yasim out of toronto's pearson international airport (CYYZ). this is the backtrace: Program received signal SIGSEGV, Segmentation fault. [Switching to Thread 1024 (LWP 23176)] SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 1117 if (_attr == (READ|WRITE) _type == DOUBLE) (gdb) where #0 SGPropertyNode::getDoubleValue (this=0x0) at props.cxx:1117 #1 0x080eb3e6 in FGNavCom::update (this=0x9a90440, dt=0) at navcom.cxx:293 #2 0x080e884a in FGNavCom::init (this=0x9a90440) at navcom.cxx:95 #3 0x080fe98b in FGRadioStack::init (this=0x9a83708) at radiostack.cxx:68 #4 0x08078ac1 in fgInitSubsystems () at fg_init.cxx:1169 #5 0x08058d3e in fgIdleFunction () at main.cxx:1311 #6 0x4024bf5e in idleWait () at glut_event.c:962 #7 0x0805cb26 in main (argc=3, argv=0xb584) at main.cxx:1805 --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
David Megginson [EMAIL PROTECTED] writes: Alex Romosan writes: i get a crash trying to fly the a4-yasim out of toronto's pearson international airport (CYYZ). this is the backtrace: Which runway? What altitude at the time of the crash? Which scenery distro? I'll see if I can reproduce. the default runway i guess. fgfs doesn't even run (it crashes during initialization). i suspect some problem with the radio frequencies for CYYZ. the scenery is the standard one downloaded from flightgear.org and everything else is the latest from CVS. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: fgfs crashing at CYYZ
Alex Romosan [EMAIL PROTECTED] writes: the default runway i guess. fgfs doesn't even run (it crashes during initialization). i suspect some problem with the radio frequencies for CYYZ. the scenery is the standard one downloaded from flightgear.org and everything else is the latest from CVS. one more thing. last messages i see before fgfs crashes are: Adding subsystem instrumentation Adding subsystem systems Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.term Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.low Initializing Interpolator for /usr/local/lib/FlightGear/Navaids/range.high Segmentation fault --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] crash
i was flying the a4 trying to dodge buildings when i crashed into one of them. the problem is i was some distance away from it as you can see from the picture at http://caliban.lbl.gov/a4_crash.pnm (it's a 1600x1200 picture so it might be pretty large). so either the crash code is wrong, or the crash boxes around buildings are too big. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: crash
David Megginson [EMAIL PROTECTED] writes: There are no crash boxes around buildings -- we're not doing collision detection at all. If you crashed, you must have hit the ground (possibly at one of those nasty tile intersections people have been talking about). you can see from the picture i was about 275 feet off the ground. if i hit the ground, shouldn't my altitude be 0? anyway, i thought we were doing collision detection because the first time i tried it i purposefully crashed right into a building to see if i can do it. it looked really good, with just the wing and a bit of the tail sticking out. i should've taken a picture. i never saw these kind of crashes without the dynamic buildings... --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] see-through instrument panel
just took a look at the outside view with the cessna and i noticed you can see the instrument panel through the fuselage. this is on linux with a geforce card. picture at: http://caliban.lbl.gov/fgfs_panel.ppm also, the engine is at 0 rpm but the propeller is spinning in the animation. all this is with the latest cvs for everything. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: see-through instrument panel
Andy Ross [EMAIL PROTECTED] writes: What size depth buffer are you using? The default is to use the same depth as the color bits, so if you're in 16 bit color mode, you're probably using a shallow depth buffer. You could try a depth of 24 in your XF86Config-4 file, and see if that fixes it -- I don't see this behavior under XFree with either a GeForce 2MX or GeForce 3. indeed, i am using 16 bit depth. i just tried 24 bit depth and that fixes it. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] latest cvs a4 panel
after the merge of the cube sides in the attitude ball i now have one huge ball sitting in the middle of the panel. you can find a picture at http://caliban.lbl.gov/fgfs-screen-002.ppm. also, i looked at pictures of the a4 panel and i didn't see such an instrument. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: failed to untie property w. --aircraft-id=a4-yasim +CVS question
Jim Wilson [EMAIL PROTECTED] writes: I wonder if the recent change preferences.xml has broken everything? Yes it did. I'll take a look at it. I suspect that David has some other customizations in there, besides the view change. i downgraded to version 1.58 of preferences.xml and fgfs is working again. the only difference _is_ the view change: diff -u -r1.59 -r1.58 --- preferences.xml 2002/06/14 14:51:27 1.59 +++ preferences.xml 2002/06/05 22:23:03 1.58 @@ -32,27 +32,6 @@ current-view field-of-view type=double55.0/field-of-view /current-view - view n=1 -nameChase View/name -typelookat/type -config - from-model type=boolfalse/from-model - from-model-idx type=int0/from-model-idx - eye-lat-deg-path/position/latitude-deg/eye-lat-deg-path - eye-lon-deg-path/position/longitude-deg/eye-lon-deg-path - eye-alt-ft-path/position/altitude-ft/eye-alt-ft-path - eye-heading-deg-path/orientation/heading-deg/eye-heading-deg-path - - at-model type=booltrue/at-model - at-model-idx type=int0/at-model-idx - - ground-level-nearplane-m type=double0.5f/ground-level-nearplane-m - - x-offset-m type=double0/x-offset-m - y-offset-m type=double0/y-offset-m - z-offset-m type=double-25/z-offset-m -/config - /view panel pathAircraft/c172/Panels/c172-vfr-panel.xml/path visibility type=boolfalse/visibility --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] yasim solution failure
it seems to be back. things were working on friday, but this morning when i tried to fly the 747 out of KOAK i get this: Finally initializing fdm Start common FDM init ...initializing position... ...initializing ground elevation to 9.39244ft... ...initializing sea-level radius... lat = 37.7251 alt = 9.39244 ...initializing velocities... ...initializing Euler angles... End common FDM init YASim solution results: Iterations: 10002 Drag Coefficient: 2.22607 Lift Ratio: 531.167 Cruise AoA: 4.76141 Tail Incidence: -10.0268 Approach Elevator: 0 CG: -29.4, 0.0, 0.8 YASim SOLUTION FAILURE: Solution failed to converge after 1 iterations so what can i do to debug this problem? --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: yasim solution failure
Andy Ross [EMAIL PROTECTED] writes: It looks like you're using the 747.xml file out of the current fgfsbase CVS. As of the last fix, you need a new file to fix a tail authority problem that the fixed code exposed. Checkins to the base package tend to lag the source tree by a few days. I attached the new file to my mail on Sunday (subject: YASim 747-400 climb). that was it. thanks. the 747 flies great now. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: YASim solution solution?
Andy Ross [EMAIL PROTECTED] writes: reason to split them out. Although be aware that the flap drag bug prevents them from being very useful for speedbrakes. not only they are not useful as speed brakes but instead they seem to provide extra thrust and lift. i was playing with the 747-yasim model yesterday, trying to come in for landing, no power (still going pretty fast at about 300 knots), gear down and then i lowered the flaps. it was fun. the plane started gaining speed and altitude. i was at 2000 feet when i lowered the flaps but before i knew it i was past 7000' and my speed was about 450 knots. boy that was fun. i tried to reproduce this, but so far no luck. --alex-- -- | I believe the moment is at hand when, by a paranoiac and active | | advance of the mind, it will be possible (simultaneously with | | automatism and other passive states) to systematize confusion | | and thus to help to discredit completely the world of reality. | ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
