Re: [Flightgear-devel] valgrind: diff no 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Denker wrote: | On 01/18/2008 09:05 AM, till busch wrote: | | i've started to run fg through valgrind. i found this to be a nice option for | getting an overview over the code in flightgear. | | 1) This is important, valuable, and overdue. | | 2) It's going to be a lot of work. That's because | | 2a) Although it is easy to write valgrind-clean code, once | somebody has written unclean code it is not necessarily | easy to clean it up. | | 2b) Although some of the FGFS code is exemplary c++ code, | some of it is not. Some of it is what we call c-- code | compiled with the c++ compiler. The point is is, c++ is a | different language from c--, and unfortunately some of FGFS | code exhibits a deep non-understanding of the purpose and | capabilities of the c++ language. | | This is related to the recent discussion (in another thread) | of memory management. C++ is perfectly capable of automatic | memory management, if allowed to do so. Sure, c++ gives folks | enough rope to hang themselves (in contrast to e.g. java, which | gives them less rope) but c++ does not /require/ anyone to hang | themselves. | | As a simple guideline, with few exceptions, one should put new | and delete in constructors and destructors, and then let the | automatic memory management do its thing. Yeah, I know this | is more work than manually newing and deleting things, but it | makes the code vastly more reliable, more maintainable, more | readable, more reusable, and more extensible. | Actually, we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. We have two classes for smart, reference- counted pointers, osg::ref_ptr and SGSharedPtr which should be used for all long-lived, shared objects. It's unfortunate that there are two choices, and I've contemplated removing the simgear version in favor of OSG, but I think SGSharedPtr has some performance advantages in multi-threaded situations. Anyway, use osg::ref_ptr for scene-graph related stuff. | There's waaay too much c-- style manual memory management in | FGFS, for no good reason ... and waaay too many memory leaks. | Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHkdOHeDhWHdXrDRURAmBZAJ9V3ri6ihfeee2u/Av7RzsCrwrjTgCdEXFt 0S2rxBwctvsU5yBWjcs9Xlc= =IXd4 -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Air Traffic Control (ATC). Fixing bugs and adding new features.
Hi,
i'm newbie in FG development (just subscribed to this mailing list) and in
C/C++ programming, but i'm interested in making
FG's ATC more usefull and realistic.
I learned the code and read comments in /src/ATC/* files and have some ideas
about adding new interesting features to FG's
ATC.
This (attached) diff fixes only two (little) bugs in Tower-ATC:
1. Sometimes ATC tells you to follow yourself when you report Downwind,
like: GFS, number two, follow GFS on
base/final/other leg.
2. When ATC tells you to go around because of traffic, but that traffic is
you!
My ideas (something of this i already wrote and there's a code):
1. Requesting weather codition in airport. Some airports don't have ATIS, so
you can ask ATC: Please advise weather
condition and ATC answers: active runway, wind heading and speed, visibility,
QFE...
2. When aircraft requests landing, pilot says: for full stop with ATIS,
but in reallife he must say: information
Bravo/Charlie/Delta/etc. I added this changes to FG.
3. Now ATC knows only two answers when requesting landing: report
straight-in and report downwind. What about other
legs, turns and vectoring? Like: Turn left heading 120 degrees until advised
or Turn right heading 10 degrees for landing
runway 28R, report final ?
4. Then i added some checkings of landing gear position and when reporting
final pilot can say: Gear down, ready to
land.
5. If you forgot gear on final, ATC can report you: Your landing gear
appears up.
But this is a very little changes. What about other new feature to make ATC
more realistic?
Please tell your ideas and advices about adding changes to ATC. What would you
like to see in FG's ATC?
Thank you and sorry for my bad English :)
Best,
Daniyar
--- src/ATC/tower.cxx 2008-01-19 16:36:42.0 +0500
+++ ../fgfs-cvs-last/src/ATC/tower.cxx 2007-05-10 01:41:08.0 +0500
@@ -613,7 +613,7 @@
doThresholdETACalc();
TowerPlaneRec* tf = NULL;
for(tower_plane_rec_list_iterator twrItr = appList.begin(); twrItr != appList.end(); twrItr++) {
- if((*twrItr)-eta (t-eta + 45) strcmp ( (*twrItr)-plane.callsign.c_str(), t-plane.callsign.c_str() ) != 0) { // strcmp added to fix bug when ATC says that you must follow yourself
+ if((*twrItr)-eta (t-eta + 45)) {
a++;
tf = *twrItr;
cf = true;
@@ -1057,28 +1057,18 @@
// eg. is the plane accelerating down the runway taking off [OK],
// or stationary near the start [V. BAD!!].
// For now this should stop the AI plane landing on top of the user.
-tower_plane_rec_list_iterator twrItr;
-twrItr = rwyList.begin();
-TowerPlaneRec* tpr = *twrItr;
-if(strcmp ( tpr-plane.callsign.c_str(), t-plane.callsign.c_str() ) == 0 rwyList.size() == 1){
- // Fixing bug when ATC says that we must go around because of traffic on rwy
- // but that traffic is our plane! In future we can use this expression
- // for other ATC-messages like On ground at 46, vacate left.
-}
-else{
- string trns = t-plane.callsign;
- trns += GO AROUND TRAFFIC ON RUNWAY I REPEAT GO AROUND;
- pending_transmission = trns;
- ImmediateTransmit();
- t-instructedToGoAround = true;
- t-clearedToLand = false;
- // Assume it complies!!!
- t-opType = CIRCUIT;
- t-leg = CLIMBOUT;
- if(t-planePtr) {
- //cout Registering Go-around transmission with AI plane\n;
- t-planePtr-RegisterTransmission(13);
- }
+string trns = t-plane.callsign;
+trns += GO AROUND TRAFFIC ON RUNWAY I REPEAT GO AROUND;
+pending_transmission = trns;
+ImmediateTransmit();
+t-instructedToGoAround = true;
+t-clearedToLand = false;
+// Assume it complies!!!
+t-opType = CIRCUIT;
+t-leg = CLIMBOUT;
+if(t-planePtr) {
+ //cout Registering Go-around transmission with AI plane\n;
+ t-planePtr-RegisterTransmission(13);
}
} else if(!t-clearedToLand) {
// The whip through the appList is a hack since currently t-nextOnRwy doesn't always work
@@ -1217,34 +1207,24 @@
// eg. is the plane accelerating down the runway taking off [OK],
// or stationary near the start [V. BAD!!].
// For now this should stop the AI plane landing on top of the user.
- tower_plane_rec_list_iterator twrItr;
- twrItr = rwyList.begin();
- TowerPlaneRec* tpr = *twrItr;
- if(strcmp ( tpr-plane.callsign.c_str(), t-plane.callsign.c_str() ) == 0 rwyList.size() == 1){
- // Fixing bug when ATC says that we must go around because of traffic on rwy
- // but that traffic is our plane! In future we can use this expression
- // for other ATC-messages like On ground at 46, vacate left.
- }
- else{
-string trns = t-plane.callsign;
-trns += GO AROUND TRAFFIC ON RUNWAY I REPEAT GO AROUND;
-pending_transmission = trns;
-ImmediateTransmit();
-t-instructedToGoAround = true;
-t-clearedToLand = false;
-t-nextOnRwy = false; // But note this is recalculated so don't rely
Re: [Flightgear-devel] Air Traffic Control (ATC). Fixing bugs and adding new features.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 First: Please don't hijack a thread like you did. Most clients that allow displaying threaded view of messages don't base it on subject but on other, normally hidden headers (that are more reliable normally, unless someone hijack the thread like you did). So when you created this message by hitting reply to Re: [Flightgear-devel] valgrind: diff no 1 you mess up that thread sort. Just hit the button/menu option/whatever to create a new mail and put in the address of the mailing list in to. Regards, Arvid Norlander Daniyar Atadjanov wrote: Hi, i'm newbie in FG development (just subscribed to this mailing list) and in C/C++ programming, but i'm interested in making FG's ATC more usefull and realistic. I learned the code and read comments in /src/ATC/* files and have some ideas about adding new interesting features to FG's ATC. This (attached) diff fixes only two (little) bugs in Tower-ATC: 1. Sometimes ATC tells you to follow yourself when you report Downwind, like: GFS, number two, follow GFS on base/final/other leg. 2. When ATC tells you to go around because of traffic, but that traffic is you! My ideas (something of this i already wrote and there's a code): 1. Requesting weather codition in airport. Some airports don't have ATIS, so you can ask ATC: Please advise weather condition and ATC answers: active runway, wind heading and speed, visibility, QFE... 2. When aircraft requests landing, pilot says: for full stop with ATIS, but in reallife he must say: information Bravo/Charlie/Delta/etc. I added this changes to FG. 3. Now ATC knows only two answers when requesting landing: report straight-in and report downwind. What about other legs, turns and vectoring? Like: Turn left heading 120 degrees until advised or Turn right heading 10 degrees for landing runway 28R, report final ? 4. Then i added some checkings of landing gear position and when reporting final pilot can say: Gear down, ready to land. 5. If you forgot gear on final, ATC can report you: Your landing gear appears up. But this is a very little changes. What about other new feature to make ATC more realistic? Please tell your ideas and advices about adding changes to ATC. What would you like to see in FG's ATC? Thank you and sorry for my bad English :) Best, Daniyar -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.7 (GNU/Linux) iD8DBQFHkgDlWmK6ng/aMNkRCoNyAJsF+TG0mjF3lvT93+fZYpUqfHNpbACcDDAh Bhq6aey6cOYN4AV+mNtZhZY= =X7UH -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
On 01/19/2008 03:40 AM, Tim Moore wrote: Actually, we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. Yes indeed. We have two classes for smart, reference- counted pointers, osg::ref_ptr and SGSharedPtr which should be used for all long-lived, shared objects. It's unfortunate that there are two choices, and I've contemplated removing the simgear version in favor of OSG, but I think SGSharedPtr has some performance advantages in multi-threaded situations. Anyway, use osg::ref_ptr for scene-graph related stuff. That's good advice. Forsooth it would make sense to *start* by cleaning up the source i.e. getting rid of needlessly non-automatic memory management (rather than starting with valgrind), for several reasons: a) It's just plain easier to look at the source than to look at the valgrind output. Valgrind can see the mess left behind by buggy code, but it doesn't tell you which line of code is buggy. b) Cleaning up the code is at least as effective, possibly more effective at fixing memory leaks. c) It's the Right Thing to do anyway. Beyond fixing memory leaks, it has the side-effect of making the code more readable, more re-usable, more extensible, et cetera. osg::ref_ptr and SGSharedPtr which should be used for all long-lived, shared objects. Ah, should be. There is presently a noticeable gap between what is and what should be. Examples of non-automatic memory management include: AIModel/AIAircraft.cxx:FGAIFlightPlan* fp = new FGAIFlightPlan(flightplan); AIModel/AICarrier.hxx:FGAICarrierHardware* ch = new FGAICarrierHardware; AIModel/AICarrier.hxx:FGAICarrierHardware* ch = new FGAICarrierHardware; AIModel/AICarrier.hxx:FGAICarrierHardware* ch = new FGAICarrierHardware; AIModel/AIFlightPlanCreateCruise.cxx:init_waypoint = new waypoint; AIModel/AIFlightPlanCreateCruise.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreateCruise.cxx:wpt = new waypoint; AIModel/AIFlightPlanCreateCruise.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreateCruise.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreate.cxx: taxiRoute = new FGTaxiRoute; AIModel/AIFlightPlanCreate.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreate.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreate.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreate.cxx: wpt = new waypoint; ... AIModel/AIFlightPlanCreatePushBack.cxx:wpt = new waypoint; AIModel/AIFlightPlanCreatePushBack.cxx: parking-setPushBackRoute(new FGTaxiRoute(route)); AIModel/AIFlightPlanCreatePushBack.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreatePushBack.cxx: wpt = new waypoint; AIModel/AIFlightPlanCreatePushBack.cxx: wpt = new waypoint; ... AIModel/AIFlightPlan.cxx: waypoint* wpt = new waypoint; AIModel/AIFlightPlan.cxx: waypoint* wpt = new waypoint; AIModel/AIFlightPlan.cxx:waypoint* init_waypoint = new waypoint; AIModel/AIFlightPlan.cxx: waypoint *wpt = new waypoint; AIModel/AIManager.cxx: FGAITanker* tanker = new FGAITanker; AIModel/AIManager.cxx:FGAIAircraft* aircraft = new FGAIAircraft; AIModel/AIManager.cxx:FGAIShip* ship = new FGAIShip; AIModel/AIManager.cxx:FGAICarrier* carrier = new FGAICarrier; AIModel/AIManager.cxx:FGAIStorm* storm = new FGAIStorm; ... AIModel/AIShip.cxx:FGAIFlightPlan* fp = new FGAIFlightPlan(flightplan); AIModel/submodel.cxx:FGAIBallistic* ballist = new FGAIBallistic; AIModel/submodel.cxx:submodel* sm = new submodel; AIModel/submodel.cxx:submodel* sm = new submodel; Aircraft/aircraft.cxx:globals-set_aircraft_model(new FGAircraftModel); Airports/groundnetwork.cxx: segments.push_back(new FGTaxiSegment(seg)); Airports/groundnetwork.cxx: nodes.push_back(new FGTaxiNode(node)); Airports/groundnetwork.cxx: nodes.push_back(new FGTaxiNode(n)); Airports/simple.cxx:_dynamics = new FGAirportDynamics(this); Airports/simple.cxx:FGAirport* a = new FGAirport(id, location, tower_location, name, has_metar, ATC/AILocalTraffic.cxx: node* np = new node; ATC/AIMgr.cxx: ID_list_type* apts = new ID_list_type; ATC/AIMgr.cxx: FGAIGAVFRTraffic* p = new FGAIGAVFRTraffic(); ATC/AIMgr.cxx: FGAILocalTraffic* local_traffic = new FGAILocalTraffic; ATC/AIMgr.cxx: FGAIGAVFRTraffic* t = new FGAIGAVFRTraffic(); ATC/AIMgr.cxx: FGAIGAVFRTraffic* t = new FGAIGAVFRTraffic(); ATC/AIPlane.cxx:SGSoundSample* simple = new SGSoundSample(buf, len, 8000); ATC/ATC.cxx:= new SGSoundSample(buf, len, 8000); ATC/ATCmgr.cxx:current_commlist = new FGCommList; ATC/ATCmgr.cxx: v1 = new FGATCVoice; ATC/ATCmgr.cxx:current_transmissionlist
[Flightgear-devel] [BUG] Sound
Hi, I discovered that you can't turn the sound in FlightGear off. There's a Mute Sound option, but it only decreases the volume. So there's no button to turn the sound off. Is this a bug or didn't I look well? Gijs _ Nieuw: Windows Live Messenger 2008! Gratis downloaden http://get.live.com/messenger- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 John Denker wrote: | On 01/19/2008 03:40 AM, Tim Moore wrote: | | osg::ref_ptr and SGSharedPtr which should be used for all long-lived, | shared objects. | | Ah, should be. There is presently a noticeable gap between | what is and what should be. Examples of non-automatic | memory management include: | [hundreds of lines of grep output omitted] I know for a fact that many of those allocations and assignments use smart pointers. How about a more useful list of those that don't? Thanks in advance, Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHkg1qeDhWHdXrDRURAscHAJ9qmEpPp1aRTXkVKFS/s8MFt/phxACfa/kB sx6UV7wFepJ3ILViqciJfKg= =Ww0y -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Traffic Control (ATC). Fixing bugs and adding new features.
On Saturday 19 January 2008 12:59:00 Daniyar Atadjanov wrote: i'm newbie in FG development (just subscribed to this mailing list) and in C/C++ programming, but i'm interested in making FG's ATC more usefull and realistic. Hi Daniyar, I'll leave the C++ experts to consider your patch, but in the meantime thanks for addressing two of our more embarrassingly obvious bugs :-) I seem to have become more interested in modelling aircraft and systems than flying in FG now, but one thing that always seemed lacking was any kind of taxi/takeoff clearance. I've not used FG's ATC for a long time, but as far as I'm aware this is still missing. Anyway, I think there's plenty that could be added and it's great that someone's working on it again. Cheers, AJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] SimGear compilation on OS X
Here's a patch, more of the same thing that went into CVS revision 1.18.2.3
Index: sg/simgear/screen/RenderTexture.cpp
===
--- sg.orig/simgear/screen/RenderTexture.cpp2007-10-14 07:46:13.0
-0600
+++ sg/simgear/screen/RenderTexture.cpp 2008-01-19 07:48:07.0 -0700
@@ -514,7 +514,7 @@
}
if (error =
- CGLChoosePixelFormat(pixFormatAttribs[0], pixFormat,
iNumFormats))
+ CGLChoosePixelFormat(pixFormatAttribs[0], pixFormat,
(GLint*)iNumFormats))
{
fprintf(stderr,
RenderTexture Error: CGLChoosePixelFormat() failed.\n);
@@ -556,7 +556,7 @@
}
long screen;
- if (error = CGLGetVirtualScreen(CGLGetCurrentContext(), screen))
+ if (error = CGLGetVirtualScreen(CGLGetCurrentContext(),
(GLint*)screen))
{
_cglCheckError(error);
return false;
--
Hans Fugal
-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
Flightgear-devel mailing list
Flightgear-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] clearer patch to renderer.*xx - accomodates non 4:3 aspect ratios with osg
Tim Moore wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
dave perry wrote:
| Patch adds a member function to FGRenderer class that returns the
| current aspect ratio. Uses this in place of 4.0/3.0 in setFOV and
| setNearFar.
|
| The diff follows:
|
This seems a little confusing / confused. In setFOV, why would you ignore the
w argument?
Now, I happen to know that /sim/startup/xsize is set to the value of w
somewhere in
one of the callers, but this is not clear at all. Can we untangle this a bit?
In setFOV, you can use w/h for the aspect ratio. But in setNearFar just
below this, w and h are not defined in that context, so you need to get
the real current aspect ratio from some where. I noticed that
/sim/startup/xsize and /sim/startup/ysize we being updated as I changed
the window, so it seemed most clear to define a getAspectRatio() member
function in this class that was available to both setFOV and
setNearFar. This is certainly more correct than assuming an aspect
ratio of 4.0/3.0 in both calls.
Thanks for the bug fix all the same. I think we've blown off this problem
because it
was unclear how to deal with multiple cameras (monitors / graphics cards),
but now we're
only coding to the osgViewer interface, so it will be easier to arrive at a
coherent
solution.
It is interesting that with this patch, the osg branch behavior still
depends on the fgfs configure switches. There are still 3 cases:
case 1: Don't enable either SDL or osgviewer (in this case, you are
using either glut or freeglut).
This case seems to work just like the plib branch. The initial view
has the right aspect ratio as well as resized windows no matter what
the initial --geometry= is. Also, all the keyboard events are
translated correctly.
case 2: --enable-sdl is added to the ./configure command line.
In this case the initial window has the correct aspect ratio as well
as resized windows no matter what the initial --geometry= is. But
many keyboard event only work the first time. I have tried to trace
this bug down to no avail.
case 3: --enable-osgviewer in place of --enable-sdl.
In this case the initial window has the correct aspect ratio no
matter what the initial --geometry= is. But you need to adjust the
window once to get the mouse events in the right coordinates.
Before this adjustment, the hot spots are vertically off. Also, if
you adjust the window width or height so as to have a different
aspect ratio, the view will be distorted.
I believe we need to commit this patch so that those with non 4:3
monitors can continue to develop aircraft and other models for the osg
branch. They can use either case 1 or case 3 to configure an osg branch
fgfs compile and at least the first window will not be distorted. I am
continuing to use case 1.
Tim
| ? renderer.diff
| Index: renderer.cxx
| ===
| RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.cxx,v
| retrieving revision 1.100
| diff -p -u -r1.100 renderer.cxx
| --- renderer.cxx6 Jan 2008 23:03:20 -1.100
| +++ renderer.cxx16 Jan 2008 22:41:59 -
| @@ -864,6 +864,11 @@ static float fov_height = 42.0;
| static float fov_near = 1.0;
| static float fov_far = 1000.0;
|
| +float FGRenderer::getAspectRatio() {
| +float xsize = fgGetInt(/sim/startup/xsize);
| +float ysize = fgGetInt(/sim/startup/ysize);
| +return xsize/ysize;
| +}
|
| /** FlightGear code should use this routine to set the FOV rather than
| * calling the ssg routine directly
| @@ -872,7 +877,7 @@ void FGRenderer::setFOV( float w, float
| fov_width = w;
| fov_height = h;
| osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
| -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| 4.0/3.0,
| +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| FGRenderer::getAspectRatio(),
|fov_near,
| fov_far);
| }
|
| @@ -886,7 +891,7 @@ n = 0.1;
| fov_near = n;
| fov_far = f;
| osgViewer::Viewer* viewer = globals-get_renderer()-getViewer();
| -viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| 4.0/3.0,
| +viewer-getCamera()-setProjectionMatrixAsPerspective(fov_height,
| FGRenderer::getAspectRatio(),
|fov_near,
| fov_far);
| }
|
| Index: renderer.hxx
| ===
| RCS file: /var/cvs/FlightGear-0.9/source/src/Main/renderer.hxx,v
| retrieving revision 1.17
| diff -p -u -r1.17 renderer.hxx
| --- renderer.hxx21 Nov 2007 20:51:50 -1.17
| +++ renderer.hxx16 Jan 2008 22:41:59 -
| @@ -32,6 +32,8 @@ public:
| void splashinit();
| void init();
|
| +static
[Flightgear-devel] Build errors with flightgear 1.0.0
I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. But i get the following error when trying to build flightgear. g++-L/usr/X11R6/lib -L/usr/local/lib -o test-up test-up.o -lsgmath -lsgxml -lsgmisc -lsgdebug -lsgstructure -lsgtiming -lplibsg -lplibul -lz -ldl -lm -ljpeg /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libsgmisc.so: undefined reference to `SGPropertyNode::getDoubleValue() const' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libsgmisc.so: undefined reference to `SGPropertyNode::setDoubleValue(double)' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libsgmath.so: undefined reference to `SGPropertyNode::getChildren(char const*) const' /usr/lib/gcc/i486-linux-gnu/4.2.3/../../../../lib/libsgmath.so: undefined reference to `SGPropertyNode::getDoubleValue(char const*, double) const' collect2: ld returned 1 exit status make[2]: *** [test-up] Error 1 make[2]: Leaving directory `/media/ext_drive/devel/build/FlightGear-1.0.0/tests' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/media/ext_drive/devel/build/FlightGear-1.0.0' make: *** [build-stamp] Error 2 How do i solve this? -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Air Traffic Control (ATC ). Fixing bugs andadding new features.
Hi AJ, I seem to have become more interested in modelling aircraft and systems than flying in FG now, but one thing that always seemed lacking was any kind of taxi/takeoff clearance. I've not used FG's ATC for a long time, but as far as I'm aware this is still missing. Yes, take-off clearance are now missing in FG's ATC. As i saw in sources, take-off clearance is implemented in FG, but really doesn't work. Maybe it worked long time ago. I'll try to understand old code and fix problems. What about taxi... As i know, Ground-ATC works (?) only in KEMT-airport. So, maybe add some random messages like Cleared to taxi to GA parking (now this works only in airports without Ground-ATC), Taxi to the end of RWy 28R, etc ? Best, Daniyar - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). Im on Kubuntu and it still hosts 0.9.10. I downloaded the source packages from the repository and updated the versioning the changelog before starting to build. i have built simgear_1.0.0 and fgfs-base_1.0.0 (which of course is just data) packages. Something, however is going wrong when building flightgear. Strange, I modified the rules file to configure with simgear in the directory that i built 1.0.0 and compilation seems to be going through... I'll report progress but hope i find the right solution. -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Please update changelog on website
The website changelog is outdated as it only gives information up to 0.9.11-pre1. http://www.flightgear.org/version.html Please update! ;o) ~ Ken Mays @ Blastwave.org Be a better friend, newshound, and know-it-all with Yahoo! Mobile. Try it now. http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
Debian insists on building shared libraries for plib and simgear, even though FlightGear is the only package that would use them on the system. Unfortunately, there seems to be some strange error reports from people trying to use these shared libs on debian system. If it was me, I'd remove all the debian prepackaged stuff, ignore their patched source, and build static versions of these libs (the default) from the native source code. It should build clean, and should work better. Regards, Curt. On Jan 19, 2008 9:38 AM, kitts wrote: On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). Im on Kubuntu and it still hosts 0.9.10. I downloaded the source packages from the repository and updated the versioning the changelog before starting to build. i have built simgear_1.0.0 and fgfs-base_1.0.0 (which of course is just data) packages. Something, however is going wrong when building flightgear. Strange, I modified the rules file to configure with simgear in the directory that i built 1.0.0 and compilation seems to be going through... I'll report progress but hope i find the right solution. -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
kitts wrote: On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). Im on Kubuntu and it still hosts 0.9.10. I downloaded the source packages from the repository and updated the versioning the changelog before starting to build. i have built simgear_1.0.0 and fgfs-base_1.0.0 (which of course is just data) packages. Something, however is going wrong when building flightgear. Strange, I modified the rules file to configure with simgear in the directory that i built 1.0.0 and compilation seems to be going through... I'll report progress but hope i find the right solution. Hi This is probably related to debian using dynamic linked libraries and Simgear is by default a statically linked one. I'm sure someone else might provide more details Cheers, Tiago - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
kitts skrev: On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). Im on Kubuntu and it still hosts 0.9.10. I downloaded the source packages from the repository and updated the versioning the changelog before starting to build. i have built simgear_1.0.0 and fgfs-base_1.0.0 (which of course is just data) packages. You could grab the source package from http://packages.debian.org/unstable/games/flightgear (download links in the blue panel on the right), then you should end up with the patched makefiles... Well, apropos, recently I've considered making static-only debian packages of simgear (I think policy has relaxed the everything-must-be-shared-libs rule since the packages were initially created), but suspect that since the plib packages are still shared libraries, there might be problems with that... hmm... - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Please update changelog on website
On Jan 19, 2008 9:38 AM, ken mays wrote: The website changelog is outdated as it only gives information up to 0.9.11-pre1. http://www.flightgear.org/version.html Please update! ;o) A note was sent to our release manager, thanks for the reminder. Durk? Anyone want to fill in the cracks here? Thanks, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
On Jan 19, 2008 9:58 AM, Ove Kaaven wrote: You could grab the source package from http://packages.debian.org/unstable/games/flightgear (download links in the blue panel on the right), then you should end up with the patched makefiles... Well, apropos, recently I've considered making static-only debian packages of simgear (I think policy has relaxed the everything-must-be-shared-libs rule since the packages were initially created), but suspect that since the plib packages are still shared libraries, there might be problems with that... hmm... For what it's worth, the primary plib author (Steve) has always been very adamant that plib be built as static libs. He has expressed several times his opposition to compiling C++ code into shared libraries. I forget all the issues he pointed out, but certainly C++'s name mangling scheme can cause problems since different compilers or different versions of the same compiler can use different name mangling algorithms, and then the runtime linker may be unable to find the needed function at runtime. I wonder if there may also be potential runtime/memory allocation issues. The whole shared library scheme presupposes C code. Regards, Curt. -- Curtis Olson: http://baron.flightgear.org/~curt/ - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
Jon S. Berndt a écrit : [hundreds of lines of grep output omitted] I know for a fact that many of those allocations and assignments use smart pointers. How about a more useful list of those that don't? Thanks in advance, Tim And some others appear to me to be properly used. I'm perplexed by the previous comment stating: we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. Where there is a new, there is a delete. What am I missing in the above comment? I can see memory leaks being caused by NOT delete-ing memory that was allocated by a previous new. Jon Hi Jon, the good practise is to give the result of the new operator to smart or auto pointer objects that would do the delete job automatically and rigorously, even in the presence of exceptions. See the std::auto_ptr class template for example. -Fred -- Frédéric Bouvier http://my.fotolia.com/frfoto/ Photo gallery http://fgsd.sourceforge.net/FlightGear Scenery Designer - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
On Saturday 19 Jan 2008 9:19:35 pm Csaba Halász wrote: On Jan 19, 2008 4:38 PM, kitts [EMAIL PROTECTED] wrote: On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: I am trying to build debian packages for flightgear 1.0.0. I have successfully built and installed simgear binary package, simgear dev package and the fgfs-data package. Have you removed the original simgear/flightgear debian packages? Just checking ;) Yes I did. -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
On Saturday 19 Jan 2008 9:21:59 pm Curtis Olson wrote: Debian insists on building shared libraries for plib and simgear, even though FlightGear is the only package that would use them on the system. Unfortunately, there seems to be some strange error reports from people trying to use these shared libs on debian system. If it was me, I'd remove all the debian prepackaged stuff, ignore their patched source, and build static versions of these libs (the default) from the native source code. It should build clean, and should work better. SimGear appears to be divided into two packages. the runtime package contains shared libs and the dev package contains static libraries along with respective header files. -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
On Saturday 19 Jan 2008 9:28:46 pm Ove Kaaven wrote: kitts skrev: On Saturday 19 Jan 2008 8:53:07 pm Ove Kaaven wrote: kitts skrev: If you want to do that, you should probably do apt-get source flightgear and build that, to get the modified makefiles needed to build against Debian's simgear packages (they're built a little weird). Im on Kubuntu and it still hosts 0.9.10. I downloaded the source packages from the repository and updated the versioning the changelog before starting to build. i have built simgear_1.0.0 and fgfs-base_1.0.0 (which of course is just data) packages. You could grab the source package from http://packages.debian.org/unstable/games/flightgear (download links in the blue panel on the right), then you should end up with the patched makefiles... Interesting. I built flightgear by modifying the configure command in debian/rules from --with-simgear=/usr to --with-simgear=/media/ext_drive/devel/build/SimGear-1.0.0/debian/simgear-dev/usr which is where i built SimGear and it compiled fine and executes fine as well. I shall download the sources from the above link. Do i only need to get flightgear or its dependencies (simgear and fgfs-base) too? -- Cheers! kitts - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Updated Joystick config Extreme 3d pro
Hy all, Since I have one myself I've updated the Logitech Extreme 3d pro joystick confiig.The buttons I've updated where not yet.Button 2 is Scrolling ViewsThe buttons 7 and 8 are now for aileron trimThe buttons 9 and 10 are for rudder trim.I've included the extreme-3d-pro.xml as a attachement. Regards, Dick _ De mooiste afbeeldingen van Angelina Jolie vind je met Live Search http://search.live.com/images/results.aspx?q=angelina%20jolieFORM=MIINTM?xml version=1.0 ? !-- * Bindings for Logitech Extreme Digital 3D Pro joystick. * * * Axis 0: ailerons * Axis 1: elevator * Axis 2 (twist): rudder * Axis 3 (slider): throttle * Axes 4 and 5 (hat): view direction * * Buttons according to the numbers printed on the joystick: * Button 1: all brakes * Button 2: scroll views * Button 4: flap down * Button 6: flap up * Button 5: elevator trim up * Button 3: elevator trim down * Button 7: aileron trim left * Button 8: aileron trim right * Button 9: rudder trim left * Button 10: rudder trim right * Button 11: left brake only * Button 12: right brake only $Id: extreme-3d-pro.xml,v 1.9 2006-03-01 18:17:26 mfranz Exp $ -- PropertyList nameLogitech Extreme Digital 3D Pro/name nameLogitech Logitech Extreme 3D Pro/name nameLogitech Extreme 3D Pro/name nameLogitech Extreme 3D Pro USB/name nameLogitech Extreme 3D Pro USB/name axis n=0 descAileron/desc binding commandproperty-scale/command property/controls/flight/aileron/property squared type=booltrue/squared /binding /axis axis n=1 descElevator/desc binding commandproperty-scale/command property/controls/flight/elevator/property factor type=double-1.0/factor squared type=booltrue/squared /binding /axis axis descRudder/desc number unix2/unix windows3/windows /number binding commandproperty-scale/command property/controls/flight/rudder/property factor type=double1.0/factor /binding /axis axis descThrottle/desc number unix3/unix windows2/windows /number binding commandnasal/command scriptcontrols.throttleAxis()/script /binding /axis axis descView Direction/desc number unix4/unix windows6/windows /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double5.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-heading-offset-deg/property step type=double-5.0/step /binding /high /axis axis descView Elevation/desc number unix5/unix windows7/windows /number low repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double5.0/step /binding /low high repeatabletrue/repeatable binding commandproperty-adjust/command property/sim/current-view/goal-pitch-offset-deg/property step type=double-5.0/step /binding /high /axis button n=0 descBrakes/desc binding commandnasal/command scriptcontrols.applyBrakes(1)/script /binding mod-up binding commandnasal/command scriptcontrols.applyBrakes(0)/script /binding /mod-up /button button n=1 descScroll Views/desc binding commandnasal/command scriptview.stepView(1)/script /binding /button button n=4 descElevator trim up/desc repeatable type=booltrue/repeatable binding commandproperty-adjust/command property/controls/flight/elevator-trim/property step type=double0.001/step /binding /button button n=2 descElevator trim down/desc repeatable type=booltrue/repeatable binding commandproperty-adjust/command property/controls/flight/elevator-trim/property step type=double-0.001/step /binding /button button n=3 descFlaps down/desc binding commandnasal/command scriptcontrols.flapsDown(1)/script /binding mod-up binding commandnasal/command scriptcontrols.flapsDown(0)/script /binding /mod-up /button button n=5 descFlaps up/desc repeatablefalse/repeatable binding commandnasal/command scriptcontrols.flapsDown(-1)/script /binding mod-up binding commandnasal/command scriptcontrols.flapsDown(0)/script /binding /mod-up /button button n=6 descAileron trim left/desc repeatable type=booltrue/repeatable binding commandproperty-adjust/command property/controls/flight/aileron-trim/property step type=double0.001/step /binding /button button n=7 descAileron trim right/desc repeatable type=booltrue/repeatable binding commandproperty-adjust/command property/controls/flight/aileron-trim/property step type=double-0.001/step
Re: [Flightgear-devel] valgrind: diff no 1
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 till busch wrote: | hi all, | | i've started to run fg through valgrind. i found this to be a nice option for | getting an overview over the code in flightgear. | | i plan to prepare some patches to fix various issues reported by valgrind. | this is the first in (i hope) a series of several patches yet to follow. i | couldn't correct any serious issues so far (just small glitches and leaks). | when i get to know the code in flightgear a little better, there might be | more outcome. | | this diff is against current cvs. | please apply and/or comment, | I've checked this in. Thanks a lot for this work. Tim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.7 (GNU/Linux) Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org iD8DBQFHkjxOeDhWHdXrDRURAuEtAKDPzUrhSUQ7W2nK54h6Yqai173PgwCfcWGO okko6xvsMgOce1lw2u1RNek= =clIM -END PGP SIGNATURE- - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
kitts wrote: Thanks. It built clean after applying the patch. I looked at the patch and noticed that while there are a few source changes most of the makefile changes only had to do with addition of more libraries. Should this then not be updated upstream? Nah. Like I said, the debian packages are built in a weird way, so it's probably only debian's problem, not upstream's. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Nasal error with YASim aircraft having 4 fuel tanks
On Friday 18 January 2008 18:22, LeeE wrote: On Friday 18 January 2008 16:49, Chris Metzler wrote: On Fri, 18 Jan 2008 15:38:47 +0100 Melchior FRANZ wrote: * Chris Metzler -- Tuesday 08 January 2008: fgfs --aircraft=ufo is enough to give me the same } Nasal runtime error: props.setDoubleValue() with non-number } at /home/cmetzler/Projects/FlightGear-0.9/data//Nasal/props.na s, line 26 Can't reproduce that here, neither with fg/plib nor fg/osg. Well, I've since then done another CVS update/rebuild, and now I can't reproduce it either. Fixed? Do you still see it, Lee? -c I didn't look to see if I got the problem here with the ufo and because I _needed_ to check the cog with different fuel loads I just added a dummy tank to get around the problem until it's fixed. Incidentally, I didn't set up an index to the dummy tank entry and the dummy tank doesn't appear in the fuel dialogue, which works ok, but just shows the three real tanks. I'll update from cvs now but I'll be out later and won't be able to test it until tomorrow sometime - I'll confirm whether it still happens with YASim aircraft with 4 tanks then. LeeE With latest cvs code data I longer see the Nasal errors reported on the terminal. I removed the dummy tank entry from the YASim config for the aircraft I was working on and the fuel system seemed to be working ok and I can change the fuel levels in all three fuel tanks, from full to zero and back to full again ok. However, when I checked an aircraft that only has a single fuel tank I found that although I still got no errors reported in the terminal, once I had set the single fuel tank contents to zero I wasn't able to re-fill it again. Moving the dialogue slider updates the gal contents but after rechecking the box the fuel weight and the totals remain at zero. Still no errors reported though. LeeE - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Build errors with flightgear 1.0.0
Curtis Olson wrote: For what it's worth, the primary plib author (Steve) has always been very adamant that plib be built as static libs. He has expressed several times his opposition to compiling C++ code into shared libraries. I can sympathize, but unfortunately I'm not responsible for the plib packages in Debian, so it's not my call. That they're shared libs kind of forces me to also make simgear shared, but if the maintainer of the plib package (Philipp Frauenfelder) could be convinced, I could perhaps change simgear... I forget all the issues he pointed out, but certainly C++'s name mangling scheme can cause problems since different compilers or different versions of the same compiler can use different name mangling algorithms, and then the runtime linker may be unable to find the needed function at runtime. Presumably that's not his strongest argument. For example, all of KDE is C++ code, and nobody wants to link Qt and the KDE libs statically into everything. In Debian, whenever the C++ ABI (which could include the name mangling scheme) changes, a transition is initiated, where packages compiled against the new compiler gets a new name. For example, the plib package currently in Debian is called plib1.8.4c2, which means it has already gone through such a transition, and is currently using g++ 4.0's ABI (name mangling). I'm sure other major distros have to do something similar. I'd consider things like PIC code being bigger and slower as better arguments. I wonder if there may also be potential runtime/memory allocation issues. The whole shared library scheme presupposes C code. I guess you're not a KDE fan? (Well, me neither...) - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Bug#461399: simgear_1.0.0-1 (alpha/unstable): FTBFS: Unrecognized CPU architecture
Ove Kaaven wrote: It's not just him being cranky about his own pet issues, it's about policy and the pursuit of high software standards. High standards for software you (literally!) can't run? Please. This is pedantry and egotism at its worst. I'm terribly sorry my software isn't good enough for you, I really am. But you can either work with me to fix it or take potshots about trivial build problems and Heisenberg bugs that can't actually be exhibited. You and Steve picked the latter. I think he already provided the requisite defines, though somewhat buried in his mail. Beyond that, perhaps this web page would be of interest: http://predef.sourceforge.net/prearch.html No, someone needs to *run* this and *test* it on those architectures.* I'm not going to commit blind changes to either Nasal or SimGear. Since you can't actually run the code you are complaining about, someone needs to work with the command line Nasal interpreter from http://plausible.org/nasal to do the test. [* Something, I will point out yet again, that no one has done. Do either you or Steve have console access to a s390, Alpha, or PA-RISC box with 3D hardware? Has *anyone* ever run the Debian fgfs binary on those architectures?] And I'd very much prefer the gcc output I asked for to anything that comes out of a single individual's brain. This stuff is too easy to get wrong, and it's literally one command to run. Just run it and send me the output. Or don't, I guess. Your call. Andy - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
On Saturday 19 January 2008, John Denker wrote: ... Forsooth it would make sense to *start* by cleaning up the source i.e. getting rid of needlessly non-automatic memory management (rather than starting with valgrind), for several reasons: a) It's just plain easier to look at the source than to look at the valgrind output. Valgrind can see the mess left behind by buggy code, but it doesn't tell you which line of code is buggy. b) Cleaning up the code is at least as effective, possibly more effective at fixing memory leaks. c) It's the Right Thing to do anyway. Beyond fixing memory leaks, it has the side-effect of making the code more readable, more re-usable, more extensible, et cetera. the good things about doing it from the valgrind side are: a) you get a call trace b) you can start with things that either leak a lot (which valgrind tells you) or are easy to fix c) it is hard to detect uninitialized variables by looking at the source by only looking at the source i woudn't have known where to start. now things are already a bit clearer and i am starting to do general clean-ups and optimizations (e.g. replacing serveral if - else if - else if... with switch) i just hope i don't step on anone's feet by doing so ;-) osg::ref_ptr and SGSharedPtr which should be used for all long-lived, shared objects. Ah, should be. There is presently a noticeable gap between what is and what should be. Examples of non-automatic memory management include: ( ... long long grep-listing ...) this list is rather useless. it is not forbidden to assign new objects to normal (non-smart) pointers. often the pointers then get into some structure that manages them. but yeah, often they don't. also. your list is much too long. did you want to scare me off? regards, - till - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
* [EMAIL PROTECTED] -- Saturday 19 January 2008: and i am starting to do general clean-ups and optimizations (e.g. replacing serveral if - else if - else if... with switch) Don't do that! Switch *may* sometimes be the better solution, and very often it isn't. When I used if/else-if somewhere, then I *meant* it and don't want it changed! m. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
On 01/19/2008 07:47 AM, Tim Moore wrote: I know for a fact that many of those allocations and assignments use smart pointers. OK. How about a more useful list of those that don't? Good idea. Here you go: If we exclude files that make *any* mention of 'SGSharedPtr' or 'ref_ptr' then it appears we have: 471 lines with 'new' statements in 84 files. For the lurid details, see http://www.av8n.com/fly/fgfs/mmm.find I'm sure some of these have carefully balanced, tightly controlled new/delete pairs ... but some of them don't. If anybody wants a copy of the tool I used to ferret these out, let me know. The tool is non-judgmental; it does not distinguish between well-used new statements and ill-used new statements. == On 01/19/2008 08:47 AM, Jon S. Berndt wrote: I'm perplexed by the previous comment stating: we want to avoid writing explicit deletes as much as possible, as that need is the source of most memory leaks. Where there is a new, there is a delete. That depends on what the definition of is is. I think it would be better to say where there is a new, there _should be_ a delete. Alas, there is a noticeable gap between what is and what should be. This is a problem in fact, not just in theory. I have found memory leaks due to mismatched new/delete in JSBsim (and submitted patches to fix the problem). And JSBsim is very far from being the only place in FGFS where c-- style manual memory management is used, as detailed above. What am I missing in the above comment? I can see memory leaks being caused by NOT delete-ing memory that was allocated by a previous new. If you use the automatic memory management that is a feature of the c++ language, you don't need 'new' *or* 'delete' except in the lowest of low-level code, where ordinary folks don't see them. The main point to keep in mind is that c++ is a different language from c-- ... for good reasons. Switching from c-- to c++ does *not* consist of replacing malloc with new and replacing free with delete. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
I have found memory leaks due to mismatched new/delete in JSBsim (and submitted patches to fix the problem). And JSBsim is very far from being the only place in FGFS where c-- style manual memory management is used, as detailed above. I appreciate any bug reports, and others have run valgrind and reported the results to us many times over the years. I also have run various memory management tools on our code (most recently I have tried runtimechecker). But, the reference to the use of new/delete as so-called C-- style is not helpful, nor is it valid for us, IMO. In our case (and I would guess for FlightGear as well) lists of objects are often needed where the number of objects is not known. That is, objects (engines, landing gear, flight control components, etc.) are read and pushed onto a vector as they are read. Pushing an object instance onto a vector is a bad idea, as a proper copy constructor must then be created, because the elements stored in a vector may be rearranged as the vector grows. We create instances of engines and other components at runtime and place pointers to those objects in the vector. Each object instance is [supposed to be] properly destroyed as the sim shuts down. I looked at using auto_ptr some years ago, but in compiling across platforms it wasn't working very well for me. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Bluebird hovercraft
I would like to request a commit for my Bluebird model, and have it added to the Flightgear Aircraft page. I realize a futuristic hovercraft is inconsistent with those who seek reality and accuracy with regard to real aircraft, but I think there is also a niche for people who get tired of crashing and give up. There should be a beginner's level for having fun. I figure if there is room for the Santa and Lego models, there should be room for a real UFO. I think I am finally satisfied with the flight characteristics, lighting effects, animations, and other features. My hanger is at http://www.geocities.com/sandreas41/flightgear_aircraft.html Thank you, Stewart - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] valgrind: diff no 1
hi melchior, On Saturday 19 January 2008, Melchior FRANZ wrote: * [EMAIL PROTECTED] -- Saturday 19 January 2008: and i am starting to do general clean-ups and optimizations (e.g. replacing serveral if - else if - else if... with switch) Don't do that! Switch *may* sometimes be the better solution, and very often it isn't. why. i need an explanation here. what is the advantage of if-else-if-else-if? more so: why very often? When I used if/else-if somewhere, then I *meant* it and don't want it changed! that's why i said i didn't want to step on anybody's feet. seems like i already did. - till - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] c++ constructors etc. (was: valgrind....)
On 01/19/2008 02:22 PM, Jon S. Berndt wrote in part: Pushing an object instance onto a vector is a bad idea, as a proper copy constructor must then be created, Well ... that is exactly the point I'm trying to discuss. IMHO if you are going to write 23,000 lines of c++, it might be worth your trouble to figure out how to write a copy constructor. It ain't that tricky. You only need to figure it out once, and then you can use the technique over and over again. Actually you usually need four things: the basic constructor, the copy constructor, the assignment operator, and the destructor. Or just use something like ref_ptr. You might want to take a look at http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html which says in part: the concept of reference counted objects will add years to your life in the long run. I am aware that JSBsim doesn't want to have an OSG dependence, but there are plenty of ways of having reference-counted objects without OSG dependence. C++ was invented for a reason. We create instances of engines and other components at runtime and place pointers to those objects in the vector. Each object instance is [supposed to be] properly destroyed as the sim shuts down. Computers are good at counting things. Why not let the computer keep track of the reference count? For example, stdlib lets you have strings, and then lets you have lists of strings, maps from strings to strings, et cetera. Stdlib does all the memory management so that the memory used by the string is freed when the last reference to the string goes away. Why not set it up so that we can have a std::list of engines? Reference-counted objects make that easy. It's not rocket science. I would say that pushing an object (such as an engine) onto a list is a good idea. A very good idea. C++ was invented for a reason. Switching from c-- to c++ does *not* consist of replacing malloc with new and replacing free with delete. Using automatic variables makes the code more reliable, and reduces the burden on those who want to read, debug, maintain, re-use, and/or extend the code. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c++ constructors etc. (was: valgrind....)
On 01/19/2008 02:22 PM, Jon S. Berndt wrote in part: Pushing an object instance onto a vector is a bad idea, as a proper copy constructor must then be created, Well ... that is exactly the point I'm trying to discuss. IMHO if you are going to write 23,000 lines of c++, it might be worth your trouble to figure out how to write a copy constructor. It ain't that tricky. You only need to figure it out once, and then you can use the technique over and over again. Done it. Years ago. JSBSim has several copy constructors. But, they are more trouble than they are worth, IMO - particularly when classes are evolving over time, and one must then modify the copy constructor. When objects also include pointers to other objects, it's complicated. Copying is also more expensive. Pointers ain't that tricky once you figure them out. C++ was invented for a reason. :-) I actually moved away from explicit storage of objects in a vector recently, going with storage of pointers instead (adding the requisite destructors) and am very happy with the results. Seriously, this is open source code. If you think there's something that could be done better, try it, play with it, prove that it works better, is more readable, and more maintainable. To me, though, it seems like you are underscoring the fact that everyone codes differently. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c++ constructors etc. (was: valgrind....)
I have been following flightgear-devel for months now, but this is my first post... Please have the respect to refer to the language by its correct name. I think we all understand that C and C++ are very different languages - other than some low-level intrinsic operators, and some basic syntactic similarities, they don't really have that much in common at all. But your insistence on using the somewhat snide c-- appellation belies a non-objective attitude and a myopic arrogance bereft of perspective. Of course one should use reference counted objects in a language that supports them, but C does not. That does not make it a bad language. Just a different one. gl On Jan 19, 2008 4:51 PM, John Denker [EMAIL PROTECTED] wrote: On 01/19/2008 02:22 PM, Jon S. Berndt wrote in part: Pushing an object instance onto a vector is a bad idea, as a proper copy constructor must then be created, Well ... that is exactly the point I'm trying to discuss. IMHO if you are going to write 23,000 lines of c++, it might be worth your trouble to figure out how to write a copy constructor. It ain't that tricky. You only need to figure it out once, and then you can use the technique over and over again. Actually you usually need four things: the basic constructor, the copy constructor, the assignment operator, and the destructor. Or just use something like ref_ptr. You might want to take a look at http://andesengineering.com/OSG_ProducerArticles/RefPointers/RefPointers.html which says in part: the concept of reference counted objects will add years to your life in the long run. I am aware that JSBsim doesn't want to have an OSG dependence, but there are plenty of ways of having reference-counted objects without OSG dependence. C++ was invented for a reason. We create instances of engines and other components at runtime and place pointers to those objects in the vector. Each object instance is [supposed to be] properly destroyed as the sim shuts down. Computers are good at counting things. Why not let the computer keep track of the reference count? For example, stdlib lets you have strings, and then lets you have lists of strings, maps from strings to strings, et cetera. Stdlib does all the memory management so that the memory used by the string is freed when the last reference to the string goes away. Why not set it up so that we can have a std::list of engines? Reference-counted objects make that easy. It's not rocket science. I would say that pushing an object (such as an engine) onto a list is a good idea. A very good idea. C++ was invented for a reason. Switching from c-- to c++ does *not* consist of replacing malloc with new and replacing free with delete. Using automatic variables makes the code more reliable, and reduces the burden on those who want to read, debug, maintain, re-use, and/or extend the code. - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] c++ constructors etc. (was: valgrind....)
Of course one should use reference counted objects in a language that supports them, but C does not. ... gl I'd add: when there is a need to do so. I don't see a need to go that level with JSBSim. In the beginning, after an aircraft file is loaded, objects are created, and remain intact for the entire lifetime of the program, at which time an orderly destruction of elements occurs. Items that have been created (through new) are addressed by pointers, which are stored in vectors (generally). In this case, it's all fairly deterministic. Jon - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configure/make/run on MacOS X
On Jan 18, 2008 9:14 PM, Ulrich Hertlein [EMAIL PROTECTED] wrote: Hi all, is anyone successfully building and running fgfs under MacOS X using configure? Yes, I do. It compiles and runs the splash screen and setups but then crashes applying a texture (don't know which). I don't see that here (MacBook with Leopard), it runs fine. I think I have had a problem like this before and it ended up being related to the OSG plugin search path. Make sure you only have one set of plugins and that OSG and FlightGear are successfully finding them. Are you using the released OSG framework or did you compile OSG yourself? -- Hans Fugal - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Time to Resync JSBSim in FGFS?
Hi, There has been a lot of changes to JSBSim of late and I'd like to see FGFS's copy updated to match. Does anyone have an easy, automated way to accomplish this or should I plow through the files manually applying changes? Thanks, Ron - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] Time to Resync JSBSim in FGFS?
Dave Culp is running the newest JSBSim with FlightGEar and it seems to be doing well. We are getting ready for a 1.0 release ourselves pretty quick. I think that the migration of JSBSim CVS code to FlightGear should be fairly painless, but I need to make a few more changes in the code for making it easier. Keep at us, but give us at least a few days. If you'd like specifics, maybe drop a line on the JSBSim list. Jon -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ron Jensen Sent: Saturday, January 19, 2008 9:29 PM To: FlightGear Dev Subject: [Flightgear-devel] Time to Resync JSBSim in FGFS? Hi, There has been a lot of changes to JSBSim of late and I'd like to see FGFS's copy updated to match. Does anyone have an easy, automated way to accomplish this or should I plow through the files manually applying changes? Thanks, Ron --- -- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] configure/make/run on MacOS X
Hi, Hans Fugal wrote: It compiles and runs the splash screen and setups but then crashes applying a texture (don't know which). I don't see that here (MacBook with Leopard), it runs fine. I think I MacBook Pro with Tiger. have had a problem like this before and it ended up being related to the OSG plugin search path. Make sure you only have one set of plugins and that OSG and FlightGear are successfully finding them. Seems to be OK at least nobody's complaining about anything i.e. 'fgfs --log-level=debug' and OSG_NOTIFY_LEVEL don't give away anything. Are you using the released OSG framework or did you compile OSG yourself? Compiling myself from svn, as library not framework. I'm pretty confident that the OSG build is OK as I'm using it for other projects as well. I've attached a gdb backtrace of the crash along with some detail of the images it's crashing on (cirrus.rgba). As you can see the crash is actually in the OpenGL driver (gldAllocVertexBuffer..gldGetTextureLevel..gleGenMipmaps..glTexImage2D) called from osg::Texture::applyTexImage2D_load(). The texture and image look fine so maybe this is completely unrelated to the actual problem. If it's the first texture download it could just as well be a GL context problem... I'm just getting my feet wet with the codebase so any help/hints etc. are appreciated. Cheers! /ulrich Splash screen progress setting up time renderer Updating time Current Unix calendar time = 1200738689 warp = 0 Current GMT = 1/19/2008 10:31:29 Current Unix calendar time = 1200738689 warp = 0 Current GMT = 1/19/2008 10:31:29 Current Julian Date = 2.45448e+06 COURSE: GMT = 0/19/108 10:31:29 March 21 noon (GMT) = 1206100800 Time since 3/21/108 GMT = -62.0615 days = -62 hours = 10.5247 lon = 0 lst = 18.3914 COURSE: GMT = 0/19/108 10:31:29 March 21 noon (GMT) = 1206100800 Time since 3/21/108 GMT = -62.0615 days = -62 hours = 10.5247 lon = 122.357 lst = 10.2342 Current lon=0.00 Sidereal Time = 18.4049 gst = 210.405 Current LOCAL Sidereal Time = 10.2478 (10.2478) (diff = 0.0135466) After fgInitTimeOffset(): warp = 0 Panel visible = 0 Splash screen progress loading scenery objects Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: KERN_INVALID_ADDRESS at address: 0x238ff000 0x0884 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:228 228 /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h: No such file or directory. in /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h (gdb) where #0 0x0884 in ___memcpy () at /System/Library/Frameworks/System.framework/PrivateHeaders/i386/cpu_capabilities.h:228 #1 0x18b2a58c in gldAllocVertexBuffer () #2 0x18b2b045 in gldGetTextureLevel () #3 0x18a9788c in gleGenMipmaps () #4 0x1897e7c2 in glTexImage2D_Exec () #5 0x92b27517 in glTexImage2D () #6 0x06f6a79b in osg::Texture::applyTexImage2D_load (this=0x290d1e60, [EMAIL PROTECTED], target=3553, image=0x29944a20, inwidth=256, inheight=256, numMipmapLevels=1) at /Users/uli/Projects/osg/OpenSceneGraph/src/osg/Texture.cpp:1057 #7 0x06f72a2c in osg::Texture2D::apply (this=0x290d1e60, [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osg/Texture2D.cpp:204 #8 0x06fffaa7 in osg::State::applyAttributeList (this=0x76aed20, [EMAIL PROTECTED], [EMAIL PROTECTED]) at State:1158 #9 0x06f56625 in osg::State::apply (this=0x76aed20, dstate=0x290d2fa0) at /Users/uli/Projects/osg/OpenSceneGraph/src/osg/State.cpp:398 #10 0x06cd4722 in osgUtil::RenderLeaf::render (this=0x2ea85d60, [EMAIL PROTECTED], previous=0x0) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderLeaf.cpp:71 #11 0x06cd0896 in osgUtil::RenderBin::drawImplementation (this=0x2ea85580, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderBin.cpp:408 #12 0x06cd0985 in osgUtil::RenderBin::drawImplementation (this=0x2ea852f0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderBin.cpp:458 #13 0x06cdd242 in osgUtil::RenderStage::drawImplementation (this=0x2ea852f0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderStage.cpp:1051 #14 0x06cdd57c in osgUtil::RenderStage::drawInner (this=0x2ea852f0, [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderStage.cpp:719 #15 0x06cdcac3 in osgUtil::RenderStage::draw (this=0x2ea852f0, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderStage.cpp:913 #16 0x06cd4d45 in osgUtil::RenderStage::drawPostRenderStages (this=0x76ad480, [EMAIL PROTECTED], [EMAIL PROTECTED]) at /Users/uli/Projects/osg/OpenSceneGraph/src/osgUtil/RenderStage.cpp:1069 #17 0x06cdc8f0 in osgUtil::RenderStage::draw (this=0x76ad480,
[Flightgear-devel] Weekly CVS Changelog Summary: SimGear
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-17_02:28:15 (timoore) /var/cvs/SimGear-0.3/source/simgear/scene/tgdb/SGTexturedTriangleBin.hxx fix memory leaks in random object code Don't allocate mt structures (for the random number generator) on the heap. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-17_15:41:48 (fredb) /var/cvs/SimGear-0.3/source/projects/VC7.1/SimGear.vcproj Update MSVC 7.1 projects 2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear data
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:11 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/TODO /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/changelog Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:12 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-8day-clock-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-alt-hotspots.xml Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:13 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-id-249-hotspots.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-id-249.ac /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-id-249.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-id-249.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-ils.ac /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-ils.rgb Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:14 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-ils.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-mag-compass.ac /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-mag-compass.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-mag-compass.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Instruments/jrb-usn-rad-alt-hotspots.xml Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:16 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/ch53e-controls.xml /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/ch53e-overhead-panel.rgb Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:18 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/ch53e-trans.rgb Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-13_08:18:21 (stuart) /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/ch53e.fail /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/ch53e.succ.ac /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/overhead.rgb /var/cvs/FlightGear-0.9/data/Aircraft/ch53e/Models/saved_animation.path Update from Josh Babcock: -Cleaned up stick position indicator code, fixed minor bug with test button. -Baked AO map into center console panel UV image. -Completed overhead panel mesh. -UV mapped overhead panel. -Baked AO into overhead panel UV image. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-15_02:25:19 (vmmeazza) /var/cvs/FlightGear-0.9/data/AI/load_demo.xml Modify experimental demo for an underslung load =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-15_13:47:39 (mfranz) /var/cvs/FlightGear-0.9/data/Aircraft/pa24-250/action-sim.nas Dave PERRY: 1. Fixes pa24 shadows on stabilator. 2. Adds full functioning landing lights animations. =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-16_10:32:42 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/BV-141/Nasal/views.xml - Correction in views.xml =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-16_10:32:43 (helijah) /var/cvs/FlightGear-0.9/data/Aircraft/DH-89/Nasal/views.xml /var/cvs/FlightGear-0.9/data/Aircraft/Lionceau/Nasal/views.xml - Correction in views.xml =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= 2008-01-16_10:32:45 (helijah)
[Flightgear-devel] Weekly CVS Changelog Summary: FlightGear source
2f585eeea02e2c79d7b1d8c4963bae2d - This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
