Re: [Flightgear-devel] Re: howto compile on SuSE 10.0 running gcc
Steve Knoblock wrote: On Tue, 08 Nov 2005 11:26:51 -0600, you wrote: freeglut (fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. I installed freeglut, all three packages found in the SuSE library. Restarted and ran ./configure again for FG. It seems to have compiled okay without complaining about glutInit, but I am now getting this error. So I've made progress. ;-) An archive post says that the CVS version does not have this problem. Should I try the CVS version? I installed 0.9.8 because of the previous error, just to see if the version was at fault. Like I said yesterday: the easiest way is to install the freeglut rpms from SUSE 9.3. They work on 10.0, too and are available on your favourite ftp.suse.com mirror. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Feature/change/update/fix list since v0.9.8
Jim Wilson wrote -Original Message- If you contributed something that is missing, or poorly described here, please send me something better. Hi Curt, This may not be helpful at this point (haven't been reading for a few days). Here's an addition: * Material animation added to Simgear's 3D model support, allowing things like dimmable cockpit lights and other exotic color and transparency morphs in 3D models. Here's something we seem to have missed: * Extensive revisions to the Multiplayer code. Multiplayer servers are now available. A Google-based map server is also available Hope we can get this in somewhere Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Andy Ross wrote: Again: I've run fairly rigorous tests on both Sparc and PPC at this point with no failures, so I think we've pretty much ruled out endianness. Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've asked others to send me a version of FlightGear compiled with the latest version of MIPSpro but have had no response so far. The good thing is that I now have a way to distribute FlightGear 0.9.9 and 1.0 for IRIX. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: B1900D fuel/engines
On Tue, 2005-11-08 at 17:16 -0800, syd wrote: Andy, (or whoever is maintaining the b1900d), I hate to do this to you, but I think I have spotted another bug to do with fuel and engines. When you run out of fuel the engines continue to run, despite /engine/engine/out-of-fuel[0]='true' and /consumables/fuel/total-fuel-gals|lbs|norm[0]='0.00' But the both engines are still running. I hope this is clearer.. George Patterson Hi George . I am maintaining the b1900d , and yes I mentioned the same problem a while back, I run out of fuel and continue to fly on if I understand correctly, the turboprop engine code is fairly new and still a work in progress , so Im sure it will be straightened out soon.I have thought of trying to fix it myself , but I think the engine code is Andy's work and he knows FAR more than I do about such things . Thanks for the note , sometimes I get so far into the modelling aspect I miss bugs :) Cheers Syd, I didn't intend that to be a criticism of any sort.. I much appreciate the effort of all involved with the modelling of any of the planes and models. Otherwise, it looks and feels great :-) While I haven't seen a b1900d, it seem around the mark, tend to enter a spin when air speed drops too low but that's extreme flight dynamics. George Patterson ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FG CVS error report
* Georg Vollnhals -- Tuesday 08 November 2005 21:00:
Melchior FRANZ schrieb:
but for now I think we can live with that.
That is ok, I think it should only be fixed before the new version gets
officially out.
You don't seem to understand: this is a very *minor*, almost cosmetic
glitch, and I'll most likely not fix it for 0.9.9, but rather for
0.9.10/1.0.0.
one more serious problem:
- adjust HUD transparency
does not switch but after you leave the menue ('cancel') the *main*
How is this more serious? This is by *design* and was like that since
ages. It was hard coded and modal. I only changed that now because I felt
like it, and because I always found that dialog ugly. The transparency wasn't
justified and looked like a bug. (But can easily be added again if
necessary. :-)
one less serious problem:
- Browse internal properties does not switch,
Yes, because it's yet another hard-coded dialog, just like the airport
list dialog and the waypoint dialog. I'd like to get all of those
modernized after the 0.9.9 release.
Yes, might be - but we should tell them! It is all a question of
personal taste, but the new style is really nice and my default from
now. Yes, eye-candy somehow - but I also like my house much better after
I have painted it :-)
The funny thing is, though, that nobody came up with an alternative
'theme' yet.
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FG CVS error report
Melchior FRANZ wrote: The funny thing is, though, that nobody came up with an alternative 'theme' yet. And why should one? The new style is very nice, not too intrusive when flighing at night. And it works now, so what more coule one want? Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FG CVS error report
* Georg Vollnhals -- Tuesday 08 November 2005 21:00: [dynamic dialog components lost after them switching] That is ok, I think it should only be fixed before the new version gets officially out. Oh, well. You just can't rely on what I say. I felt like fixing that, too. Will commit later today. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Buildings ?????
Ima Sudonim wrote: Next on the list are the Nat. Cathedral, Basilica of the Immaculate Conception, Mormon Temple, Pentagon and then the Mall. Not sure what timetable I'm looking at though. If you can think of any other big visible structures that you would like to see (sorry, I'm not tackling the bridges yet, there's issues with the VMAP data I don't want to deal with) let me know. No promises though. Josh, Thanks for your interest on building up a more recognizable washingon, DC! SNIP On my wishlist for dc: (in addition to yours): Oh, yeah I forgot, I am also planning on doing the stadiums. the georgetown and dalecarlia sp? reservoirs might help avoid the restricted area around the us vice presidents house (at the naval observatory) Don't forget the reflecting pool:) The reservoirs should eventually get taken care of by more accurate shoreline data. Curt may be filtering them out because of their size right now. I don't know if they are in the data set. If they are there may be a way to get him to whitelist them. Curt? SNIP Probably accurately displaying the borders of parks and forested areas could help with VFR, no? (this is not to imply that the borders are not accurate, I don't know but it might be worth looking into) Again, a function of how accurate the VMAP data is. I think it's already pretty good, actually. I don't know what your schedule is, but it's probably moving a lot faster than mine will be. My schedule is remarkably unreliable 8-(. I hope that eventually I will be able to do some of this... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FG CVS error report
Melchior FRANZ schrieb:
one more serious problem:
- adjust HUD transparency
does not switch but after you leave the menue ('cancel') the *main*
How is this more serious? This is by *design* and was like that since
ages.
Melchior, you cut off the very *important* part of the sentence:
- does not switch but after you leave the menue ('cancel') the
*main* menue is frozen (no reaction on clicks)
In my eyes something is serious when you make a legal keypress and
afterwards a big part of the programs functions don't work anymore = the
main menu is frozen = you can only use keycodes not the mouse and the
main-menue entries are not accessible anymore.
Ok, if this is by design then all is ok, I just reported an error
which might be a problem for *other* user.
Not for me anymore as I know about these features.
Regards
Georg
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FG CVS error report
* Georg Vollnhals -- Wednesday 09 November 2005 17:11:
- does not switch but after you leave the menue ('cancel') the
*main* menue is frozen (no reaction on clicks)
In my eyes something is serious when you make a legal keypress and
afterwards a big part of the programs functions don't work anymore
Yes, but it's the same with all modal dialogs. I didn't say it's a
good idea, but it was designed like that. It's annoying and *seems*
like a bug, so we'll change it. But it's really only legacy gui design,
not a bug. And the pending 0.9.9 release does not mean that we have
to improve everything that we can think of. I didn't criticize that
you reported it -- that was the right thing to do. I just didn't share
your opinion that it had to be fixed for the next release. Someone
has to spend the time after all. And there will be a release after
0.9.9, or two. ;-)
m.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FG CVS error report
Melchior FRANZ schrieb: I didn't criticize that you reported it -- that was the right thing to do. I just didn't share your opinion that it had to be fixed for the next release. Someone has to spend the time after all. And there will be a release after 0.9.9, or two. ;-) m. This is ok :-) - other priorities and limited time is an important factor! After all, I am really happy with this new GUI style Cheers Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: FG CVS error report
* Georg Vollnhals -- Wednesday 09 November 2005 17:39: This is ok :-) - other priorities and limited time is an important factor! After all, I am really happy with this new GUI style And it's even fixed meanwhile, and I'm quite satisfied with the result. (Now it even re-opens the Nasal dialogs.) So your bug report encouraged me to fix the non-bug. ;-) The only thing that would be nice is if dialogs would remember their former position. They don't. And then there are the remaining hard-coded dialogs ... but some points *have* to be remain for 1.0.0/0.9.10, or we will be bored to death. m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] dialog boxes (Was: FG CVS error report)
On Wednesday 09 November 2005 16:49, Melchior FRANZ wrote: * Georg Vollnhals -- Wednesday 09 November 2005 17:39: This is ok :-) - other priorities and limited time is an important factor! After all, I am really happy with this new GUI style And it's even fixed meanwhile, and I'm quite satisfied with the result. (Now it even re-opens the Nasal dialogs.) So your bug report encouraged me to fix the non-bug. ;-) The only thing that would be nice is if dialogs would remember their former position. They don't. And then there are the remaining hard-coded dialogs ... but some points *have* to be remain for 1.0.0/0.9.10, or we will be bored to death. i patched my code to disable dialog boxes when making screenshots, because they were quite annoying. shouldn't we do something about that in general? Thorben ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: dialog boxes (Was: FG CVS error report)
* Thorben -- Wednesday 09 November 2005 20:22: i patched my code to disable dialog boxes when making screenshots, because they were quite annoying. shouldn't we do something about that in general? I just made two nice shots for the screenshots page, which are *supposed* to show menu and dialogs. Would one have to patch his/her fgfs then to allow that? I'd say, if you don't want the dialog boxes, just close them. Same with the menu. :-P m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Persistant Nasal big-endian bug
Erik Hofman wrote: Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. great sigh of relief Excellent. Thanks for your work, I was completely out of ideas on this. :) Ok, I've test compiled the simgear/nasal library using gcc on IRIX and linked it with the MIPSpro build version of FlightGear and it's working like a charm. Now remains the question, is it an exploited gcc bug/feature or is it really a MIPSpro bug? I've personally built and tested it using the Sun Studio compiler on Sparc, and the windows builds are done using MSVC. That proves nothing, of course, but if code were a democracy MIPSpro would be losing 3:1. :) Note that the naRef structure is a nested union, and the code makes heavy use of structure assignment of these things. That's not a common idiom (most other interpreters just use casts), so I wouldn't be shocked if it triggered a bug or two. There's one spot in there already (I forget who found it -- not me, anyway) with a workaround for a gcc 2.95 code generation bug. If you want to continue tracking this down, you could try starting with a gcc library, and replace each .o file in turn with a MIPSpro one to figure out where the faulty code generation is (it might be more than one location, of course), then start moving code out symbol-by-symbol until you zero in on the location. Then we can try to rewrite it so it compiles correctly. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Pending v0.9.9 release
As some of you may have noticed, I completed a prerelease of FlightGear-0.9.9(pre1) and SimGear-0.3.9(pre1). I haven't heard any complaints about the prerelease, so I am planning to do a pre2 release this week. If all goes well and we have no major show stoppers, I would like to start working on the official v0.9.9 release next week and have it out by the end of next week (optimistically.) I'm trying to fit this into my own 'spare' time schedule so I may not be able to accomidate everyone's needs and wishes. But, there is always the next release if we miss something this time around. We haven't officially decided, but right now we are talking about doing a v1.0 release after the dust has settled on 0.9.9. That would likely happen sometime early 2006 after the holidays. Regards, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Joystick issues with throttleAxis()
Hi, some time ago a new version of the joystick configuration file for Logitech Wingman FF 3D was committed, containing a change to the throttle-handling. Shortly after that I couldn't get the engines down to idle. As I noticed, jsdemo reports that the throttle axis returns +0.3 when on idle. I'm using Linux on a 2.6.8 kernel. I thought that plib would calibrate the joystick axes to 0 in the positions they are in on construction of the plib Joystick object. However, there is no evidence on this in the plib code. I had to go back to a previous version of the configuration file and idling worked again. Maybe we should have a general calibration utility and load the resulting data on FlightGear startup. This would also spare us some of the offset-hacks in joystick configuration files. I don't have time right now (maybe within a week's time), but if nobody else jumps in I'll create a tool as soon as I have time. Best regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] wp altitudes
Hello all, I'm messing around with waypoints, ie race track loop around airports, etc... but found the [EMAIL PROTECTED] command doesn't seem to work with multiple waypoints altitudes... The plane eventually has it's own mind with regard to what altitude it wants to fly. I also tried the flightplan, but have the same isue. The altitude in the gui autopilot works very stable. So... is there a way to implement a series of waypoints at different altitudes? My next attack was going to cut into the route manger code in try to implement a file read to the autopilot data points, any input would be appreciated... Thanks for your help... Craig E. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] uneven brakes (and another spotted bug+fix)
Using a Saitek stick, I've noticed a peculiar bug in the brakes which I still haven't pinned down. The nasal function interpolate() works on left wheel only, not the right wheel, making the plane twist when brakes are applied (or released). One can see it by watching the internal properties (controls/gear) while applying the wheel brakes. Right wheel jumps from 0.0 to 1.0 in an instant. I've been scanning the source for assymetries on right and left brake implemetation, and so far I've only found a line in src/Aircraft/replay.cxx: replay.cxx line 365 and on: result.ctrls.brake_left = weight( ctrls1.brake_left, ctrls2.brake_right, ratio ); result.ctrls.brake_right = weight( ctrls1.brake_right, ctrls2.brake_right, ratio ); line 366 should probably read: = weight( ctrls1.brake_left, ctrls2.brake_left, ratio ); This however, is not the source of the uneven brakes bug. I'll keep looking. Oh, and I doubt if the js button in question should be marked as repeatable when interpolate() is being used -- ? I set repeatable to false and the interpolation time to one second. (should perhaps be a bit less) As it is now, the value is interpolated from the previous value to 1.0 (or 0.0) by each repeat step, which in theory takes forever... ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: dialog boxes (Was: FG CVS error report)
* Thorben -- Wednesday 09 November 2005 20:22: i patched my code to disable dialog boxes when making screenshots, because they were quite annoying. shouldn't we do something about that in general? In case you mean the popups that have the annoying habit of not going away when fgfs is paused: yes, these are annoying as hell! We should really fix that. Most annoying if you halt at a really photogenic flight position, then go to outside view to find a cool perspective, and ... gahhh! m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] wp altitudes
[EMAIL PROTECTED] wrote: I'm messing around with waypoints, ie race track loop around airports, etc... but found the [EMAIL PROTECTED] command doesn't seem to work with multiple waypoints altitudes... The plane eventually has it's own mind with regard to what altitude it wants to fly. I also tried the flightplan, but have the same isue. The altitude in the gui autopilot works very stable. So... is there a way to implement a series of waypoints at different altitudes? My next attack was going to cut into the route manger code in try to implement a file read to the autopilot data points, any input would be appreciated... Thanks for your help... Craig E. This used to work back when it was first implimented. You may want to check that the route manager is setting the same property name for target elevation that the autopilot is using. Downside of using properties for these things rather than C++ variables if you change one side and not the other, the compiler won't catch it for you, but the upside is a tremendous amount of increased flexibility and power so we live with it ... Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
On Wednesday 09 November 2005 12:58 pm, Ralf Gerlich wrote: ... some time ago a new version of the joystick configuration file for Logitech Wingman FF 3D was committed, containing a change to the throttle-handling. Shortly after that I couldn't get the engines down to idle. As I noticed, jsdemo reports that the throttle axis returns +0.3 when on idle. I'm using Linux on a 2.6.8 kernel. That configuration file applies an offset of -0.3 prior to the scale. That shouldn't be allowed, and I guess someone's personal configuration snuck in by accident? Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] uneven brakes (and another spotted bug+fix)
Joacim Persson wrote: Using a Saitek stick, [..] The nasal function interpolate() works on left wheel only, not the right wheel, making the plane twist when brakes are applied (or released). One can see it by watching the internal properties (controls/gear) while applying the wheel brakes. Right wheel jumps from 0.0 to 1.0 in an instant. Which stick, and which aircraft? I don't see anything weird in the joystick configurations, at least. The C++ input handling is a possibility, but the FDM configuration could be glitched too. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Which aircraft to include in v0.9.9?
I reserve the right to make the final determination (and all non-included aircraft will still always be available for separate download from the web site ...) Given that new aircraft have arrived on the scene since the last release, do we want to make any changes to the list of default aircraft included in the base package? The rule generally is that if we add one, we have to remove an existing one so the total number of included aircraft remains about the same... The current list is: data/Aircraft/737 \ data/Aircraft/A-10 \ data/Aircraft/bo105 \ data/Aircraft/c172 \ data/Aircraft/c172p \ data/Aircraft/c310 \ data/Aircraft/c310u3a \ data/Aircraft/Citation \ data/Aircraft/f16 \ data/Aircraft/j3cub \ data/Aircraft/Hunter \ data/Aircraft/p51d \ data/Aircraft/pa28-161 \ data/Aircraft/ufo \ data/Aircraft/wrightFlyer1903 \ Just glancing through the list very quickly, potential candidates for inclusion might be the b1900d, Citation Bravo, Concorde, dhc2, F-8E, Hurricane, Marchetti, MiG-15, seahawk, Spitfire, tu154 ... (?) Any opinions? Note that if you propose adding an airplane, you also have to say which one we remove from the existing list ... Thanks, Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
Hi, Dave Culp wrote: On Wednesday 09 November 2005 12:58 pm, Ralf Gerlich wrote: [SNIP] Shortly after that I couldn't get the engines down to idle. As I noticed, jsdemo reports that the throttle axis returns +0.3 when on idle. I'm using Linux on a 2.6.8 kernel. That configuration file applies an offset of -0.3 prior to the scale. That shouldn't be allowed, and I guess someone's personal configuration snuck in by accident? The major change to that file was that appropriate Nasal-scripts are used on throttle and other axes and that's a Good Thing (tm). However, that effectively broke the calibration that was in there, as throttleAxis() and friends don't currently support these offsets. I was just thinking of a more general way of solving the calibration issues than putting it into the configuration files. Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] (no subject)
On Wed, 9 Nov 2005, Andy Ross wrote: Which stick, and which aircraft? Saitek Cyborg Evo (but the code is copied from Saitek to other sticks) And it's the same for all aircrafts I've tested, including uiuc-models (so it's probably not the FDM engine. Not that I have full understanding of how FlightGear is designed. ;) I've also experimented with commenting out the lines about left gear in the joystick config file (and thus tie the button to right gear only), to see if it had something to do with nasal per se. (as in not being able to handle two interpolate simultaneously) But the right wheel keeps braking hard. I don't see anything weird in the joystick configurations, at least. Me neither. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
On Wednesday 09 November 2005 19:04, Dave Culp wrote: That configuration file applies an offset of -0.3 prior to the scale. That shouldn't be allowed, and I guess someone's personal configuration snuck in by accident? I don't think so in this case. That offset apparently worked for most people with this stick - I know my throttle's been broken since using the new nasal based config, in that I can never get the throttle input less than 0.24. If an offset fixes a problem for everyone with this stick, I can't see any valid argument against it. If the offset required is completely unpredictable of course, it's not an acceptable solution. I would be interested to know if anyone has a Wingman Force 3d which gives the correct full range of throttle values with the new config... Cheers, AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear v0.9.9-pre2
FlightGear v0.9.9-pre2 (second prerelease for v0.9.9) is now available for downloading and testing from the FlightGear web site (http://www.flightgear.org) It would be great if as many people as possible could download the tarballs for this release and build and test it on as many platforms as possible. Also note you will need the corresponding SimGear-0.3.9-pre2 (from http://www.simgear.org) The more build errors and platform bugs we can catch now, the smoother the v0.9.9 release will be for your favorite platform! I am currently targeting the official v0.9.9 release for late next week (time permitting.) Thanks! Curt. -- Curtis Olsonhttp://www.flightgear.org/~curt HumanFIRST Program http://www.humanfirst.umn.edu/ FlightGear Project http://www.flightgear.org Unique text:2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] (no subject)
Joacim Persson wrote: I've also experimented with commenting out the lines about left gear in the joystick config file (and thus tie the button to right gear only), to see if it had something to do with nasal per se. (as in not being able to handle two interpolate simultaneously) But the right wheel keeps braking hard. Theory: the right brake property is flagged as a boolean in the property tree, and is clamping all values to 0 or 1. This can be complicated to debug -- you need to figure out where it's created. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
On Wednesday 09 November 2005 19:31, Curtis L. Olson wrote: Just glancing through the list very quickly, potential candidates for inclusion might be the b1900d, Citation Bravo, Concorde, dhc2, F-8E, Hurricane, Marchetti, MiG-15, seahawk, Spitfire, tu154 ... (?) Any opinions? Note that if you propose adding an airplane, you also have to say which one we remove from the existing list ... I think, especially in view of the spate of posts a short while ago, it would be wise to only include (by default) aircraft which are quite complete - i.e. with populated cockpits etc. People who know what they want and what they're doing can easily download the others. My vote would probably go for the Spitfire - that way you actually get two planes for the price of one, and one of those is carrier capable - I think we should make sure we have at least one or two carrier capable planes distributed by default. To remove... probably the one of the Cessnas (purely personal tastes!) or the Wright Flyer (which I'd say is kind of special interest and not that useful for general flying). Anyway, like you say anything removed would still be there for download... AJ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] uneven brakes mystery
On Wed, 9 Nov 2005, Andy Ross wrote: Theory: the right brake property is flagged as a boolean in the property tree, and is clamping all values to 0 or 1. This can be complicated to debug -- you need to figure out where it's created. Sounds plausible. Some sort of type mismatch. But I figure left and right gear should be identical throughout the code (including data/-files), so it ought to show up by extensive grep'ing and counting occurrences in various files. Rather tedious though. :P ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 29
Buchanan, Stuart wrote: --- Steve Knoblock [EMAIL PROTECTED] wrote: I am unsure if I can help, I do hope to convert a model of the Cape May Light I made for MSFS for FG once I understand the tools. As a first pass, you could place a generic lighthouse (from http://fgfsdb.stockill.org/models.php) in the correct location by editing the the correct .stg file. Or just let me know where it is, and I'll add it to the database. Is there an organisation that manages lighthouses? (in the UK there's Trinity House, and the Northern Lighthouse Board). If so then it's possible they list all the lights they manage - that's then an easy addition to the scenery. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] uneven brakes mystery
On Wed, 9 Nov 2005, Andy Ross wrote: Theory: the right brake property is flagged as a boolean in the property tree, and is clamping all values to 0 or 1. Confirmed. I tried a setprop to 0.3 for right wheel in the js config file, and got a 1.0 in the browse internal props dialog. Somewhere control/gear/brake-right is set to 'true' (i.e. not zero). ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Curtis L. Olson wrote: I am currently targeting the official v0.9.9 release for late next week (time permitting.) Is there any preferred version of OpenAL for this release? Just wondering if there's a recommended version for linking against for the binary packages. Also, is there an fgrun release planned to coincide with 0.9.9? Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: uneven brakes mystery
* Joacim Persson -- Wednesday 09 November 2005 21:30: I tried a setprop to 0.3 for right wheel in the js config file, and got a 1.0 in the browse internal props dialog. Somewhere control/gear/brake-right is set to 'true' (i.e. not zero). Is this the development version (cvs/head)? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: uneven brakes mystery
On Wed, 9 Nov 2005, Melchior FRANZ wrote: Is this the development version (cvs/head)? Yes, but it has been the same for shipped versions too. How can I tell which version of fgfs I'm running? fgfs --version didn't work on the version I have installed in /usr/local/... anyway. Think it's the last official stable release. In that installation I've replaced the calls to interpolate with setprop in the js config file, when I first noticed the problem after buying a new js. But it's an a few hours old cvs version I'm working on now. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Joystick issues with throttleAxis()
--- AJ MacLeod [EMAIL PROTECTED] wrote: I would be interested to know if anyone has a Wingman Force 3d which gives the correct full range of throttle values with the new config... Mine does, but then since I sent in the patch I probably don't count... I wonder if it is OS or USB specific? I've got a USB version and run under WinXP. -Stuart ___ To help you stay safe and secure online, we've developed the all new Yahoo! Security Centre. http://uk.security.yahoo.com ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Before 0.9.9 is released I think one problem should be resolved: on some planes (like the 737, f16, Concorde, fokker100) the engine sounds are missing. Specifically Sounds/jet.wav is not audible. I discussed this problem some weeks ago on the IRC channel and tried to find out what's causing it. It's no local problem and happens to all planes that use the /engines/engine[0]/thrust_lb[0] property for volume calculation. I had to stop investigating due to some real life stealing my time, but I'm sure this should be fixed before a release. If someone has an idea what caused this I could spend some more time for debugging. Nine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
Jon Stockill wrote: Is there any preferred version of OpenAL for this release? The CVS from 1st April this year appears to be a good choice - BTW, this is what FreeBSD folks decided to stick to ;-) Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] 737 nosewheel animations
Hi, attached are two small patches for giving the 737 nosewheel some animations. Namely it rotates when steering and compresses on breaking. For the latter I attached a one line patch that let's JSBsim expose compression-norm to the property tree just like YaSim. I don't know if this is in any way correct, but it gives some plausible movement visually. Now if there were some skid sounds you could get an impression how such a large plane feels like on the ground ;) Nine diff -u -3 -p -r1.36 JSBSim.cxx --- src/FDM/JSBSim/JSBSim.cxx 1 Nov 2005 13:41:49 - 1.36 +++ src/FDM/JSBSim/JSBSim.cxx 9 Nov 2005 21:18:59 - @@ -1023,6 +1023,7 @@ void FGJSBsim::init_gear(void ) node-setBoolValue(has-brake, gear-GetBrakeGroup() 0); node-setDoubleValue(position-norm, FCS-GetGearPos()); node-setDoubleValue(tire-pressure-norm, gear-GetTirePressure()); + node-setDoubleValue(compression-norm, gear-GetCompLen()); if ( gear-GetSteerable() ) node-setDoubleValue(steering-norm, gear-GetSteerNorm()); } @@ -1038,6 +1039,7 @@ void FGJSBsim::update_gear(void) node-getChild(wow, 0, true)-setBoolValue( gear-GetWOW()); node-getChild(position-norm, 0, true)-setDoubleValue(FCS-GetGearPos()); gear-SetTirePressure(node-getDoubleValue(tire-pressure-norm)); + node-setDoubleValue(compression-norm, gear-GetCompLen()); if ( gear-GetSteerable() ) node-setDoubleValue(steering-norm, gear-GetSteerNorm()); } diff -u -3 -p -r1.3 boeing733.xml --- Models/boeing733.xml 17 Feb 2004 09:39:46 - 1.3 +++ Models/boeing733.xml 9 Nov 2005 21:13:35 - @@ -42,6 +42,35 @@ /axis /animation + animation + typerotate/type + object-namenosegear/object-name + property/surface-positions/rudder-pos-norm/property + factor-35/factor + center + x-m-11.1/x-m + y-m0/y-m + z-m-0.40/z-m + /center + axis + x0/x + y0/y + z1/z + /axis + /animation + + animation + typetranslate/type + object-namenosegear/object-name + property/gear/gear/compression-norm/property + factor0.3/factor + axis + x0/x + y0/y + z1/z + /axis + /animation + animation typerotate/type object-namerhgear/object-name ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] waypoints, waypoint loops, route manger
Title: Message Hello all, I'm trying certain senarios via waypoints and varying altitudes by using flightplan/.fgfsrc file. I plan on implementing a data input change for route manger code to read a file with my data, but in the mean time I was wondering if there's a reason why [EMAIL PROTECTED] has issues maintaining the wanted altitude. I have alts at 15k, but the craft drifts to 20 k, etc... I also want to maintain a senario for a certain amount of time, so go to waypoint 1 and 2 looping for 10 mins, etc... then hit waypoints 3, 4 and 5... If anyone has a better way to approach this please give me ur ideas.Thanks a lot.. Regards, Craig E. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Curtis L. Olson wrote: I reserve the right to make the final determination (and all non-included aircraft will still always be available for separate download from the web site ...) Given that new aircraft have arrived on the scene since the last release, do we want to make any changes to the list of default aircraft included in the base package? The rule generally is that if we add one, we have to remove an existing one so the total number of included aircraft remains about the same... The current list is: data/Aircraft/737 \ data/Aircraft/A-10 \ data/Aircraft/bo105 \ This is a nice selection data/Aircraft/c172 \ This one can be removed (no more dependencies) data/Aircraft/c172p \ data/Aircraft/c310 \ data/Aircraft/c310u3a \ I would switch the c310 for the Citation or B1900d data/Aircraft/Citation \ data/Aircraft/f16 \ data/Aircraft/j3cub \ data/Aircraft/Hunter \ data/Aircraft/p51d \ data/Aircraft/pa28-161 \ data/Aircraft/ufo \ This would be Santa until 1.0? data/Aircraft/wrightFlyer1903 \ Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: uneven brakes mystery
I have pinned down the exact moment in gdb when brake-right is set to 1.0
(without a cause, so to speak), but I feel I don't have enough knowledge
about how FG is designed to come further.
gdb backtrace below. This is after initialisation is done, FG is up and
running and the fire button (apply all brakes) is pressed and held. Just
before this br stop, there was another one with the correct value (from the
nasal setprop to 0.3, which I used for testing instead of interpolate() in
the js config file). I have not a clue where this spurious 1.00 comes
from, nor why it only affects the right wheel brake. It seems like more
than one function has been bound to the button in question, or some list
handler is running amok.
--
Breakpoint 1, FGControls::set_brake_right (this=0x0, pos=1) at controls.cxx:40
40 {
(gdb) bt
#0 FGControls::set_brake_right (this=0x0, pos=1) at controls.cxx:40
#1 0x080a1624 in SGRawValueMethodsFGControls, double::setValue (this=0x0,
value=1)
at props.hxx:404
#2 0x0848f900 in SGPropertyNode::setUnspecifiedValue (this=0x89fa878,
value=0x8af39fc 1.00) at props.cxx:408
#3 0x0805b154 in do_property_assign (arg=0x8af2c70) at fg_commands.cxx:795
#4 0x082f9b92 in FGBinding::fire (this=0xbf4d0f8) at input.cxx:127
#5 0x082f9d8f in FGBinding::fire (this=0xbf4d0f8, offset=1, max=-1) at
input.cxx:139
#6 0x08301368 in FGInput::_update_button (this=0x4baa9008, [EMAIL PROTECTED],
modifiers=204483636, pressed=true, x=-1, y=-1) at stl_vector.h:501
#7 0x082ff5c3 in FGInput::_update_joystick (this=0x4baa9008,
dt=187.94)
at input.cxx:811
#8 0x082fa653 in FGInput::update (this=0x4baa9008, dt=187.94) at
input.cxx:203
#9 0x084c0698 in SGSubsystemGroup::Member::update (this=0xb966d68,
delta_time_sec=187.94) at subsystem_mgr.cxx:237
#10 0x084c0041 in SGSubsystemGroup::update (this=0x891711c,
delta_time_sec=187.94)
at stl_vector.h:501
#11 0x084c0c49 in SGSubsystemMgr::update (this=0x8917100,
delta_time_sec=187.94)
at subsystem_mgr.cxx:297
#12 0x08052b6c in fgMainLoop () at main.cxx:495
#13 0x08088592 in GLUTidle () at fg_os.cxx:114
#14 0x400a4929 in __glutRegisterEventParser () from /usr/X11R6/lib/libglut.so.3
#15 0x400a50ad in glutMainLoop () from /usr/X11R6/lib/libglut.so.3
#16 0x08055567 in fgMainInit (argc=3, argv=0xb424) at main.cxx:1007
#17 0x080519d6 in main (argc=3, argv=0xb424) at bootstrap.cxx:193
(gdb)
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Georg Vollnhals wrote: Curtis L. Olson schrieb: man touch ? Curt. Yes. My 13 years old son is actually a co-user on my PC. He does not ask, he does not think a lot - just trial and error method. Very good if you have all your important data burned on CD/DVD and have a good firewall, virus-scanner and no possibility to make a dial-up connection from your PC! But only until christmas, then I'll upgrade my PC and I'll build him his own with the parts I don't use anymore and those he gets as presents :-) :-) Joy of fatherhood! Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d Or you could run linux, then he could only mess up his own files. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 29
Jon Stockill wrote: Buchanan, Stuart wrote: --- Steve Knoblock [EMAIL PROTECTED] wrote: I am unsure if I can help, I do hope to convert a model of the Cape May Light I made for MSFS for FG once I understand the tools. As a first pass, you could place a generic lighthouse (from http://fgfsdb.stockill.org/models.php) in the correct location by editing the the correct .stg file. Or just let me know where it is, and I'll add it to the database. Is there an organisation that manages lighthouses? (in the UK there's Trinity House, and the Northern Lighthouse Board). If so then it's possible they list all the lights they manage - that's then an easy addition to the scenery. Jon ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d They used to all be operated by the Coast Guard, but there are very few still active. Most are just museums now. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: uneven brakes mystery
Joacim Persson wrote: Andy Ross wrote: Which stick [...]? Saitek Cyborg Evo [...] I have pinned down the exact moment in gdb when brake-right is set to 1.0 (without a cause, so to speak), but I feel I don't have enough knowledge about how FG is designed to come further. What this is showing is a joystick button (not a key) causing a property-assign binding to fire, which is setting your brake property. The problem is, the Cyborg Evo joystick definition doesn't *have* any property-assign bindings. It does everything with nasal scripts. Something odd is going on -- apparently some other stick's binding for the right brake only is being picked up by your configuration. Have you modified the name properties of any of you joysticks files? Can you verify that your base package is unmodified? If you want to continue playing with the debugger, you could try stepping through the joystick initialization (or, alternatively, selectively removing files from your Input/Joysticks directory) to figure out which stick is being incorrectly loaded, and why. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: uneven brakes mystery
On Wed, 2005-11-09 at 21:54 +0100, Joacim Persson wrote: On Wed, 9 Nov 2005, Melchior FRANZ wrote: Is this the development version (cvs/head)? Yes, but it has been the same for shipped versions too. How can I tell which version of fgfs I'm running? fgfs --version didn't work on the version I have installed in /usr/local/... anyway. Think it's the last official stable release. In that installation I've replaced the calls to interpolate with setprop in the js config file, when I first noticed the problem after buying a new js. But it's an a few hours old cvs version I'm working on now. You have more than one version of FlightGear installed? To find out which copy is being loaded when you type fgfs, open up a terminal and type which fgfs and you should get something like /usr/local/bin/fgfs. Perhaps a command line parameter could be added to display the version of the binary and the version of the fg_root data. George ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Please upgrade to version: 0.9.8
Josh Babcock schrieb: Or you could run linux, then he could only mess up his own files. Josh Yes Josh, that's my way for the future :-) I already created a second partition for Linux some months ago and tried Suse, Fedora, Kubuntu, Knoppix and Kanopix (Debian version). The last was the best for me - installed all my hardware without problems, runs fine. Only problem is that I cannot get my WLAN/router working (Ethernet no problem). I am playing with that whenever I have some time left. But this is the cutting edge for me: no WLAN, no serious work under Linux :-( But I hope I'll find a solution for that in the next future - working with FlightGear under Linux would be a lot easier, I think. Regards Georg ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: uneven brakes mystery
* Andy Ross -- Thursday 10 November 2005 00:37: stepping through the joystick initialization (or, alternatively, selectively removing files from your Input/Joysticks directory) to figure out which stick is being incorrectly loaded, and why. ... or simply look in the property browser under /input/joysticks/js[0]/. You'll find there these entries: name[0], name[1], etc. ... all joystick IDs that the driver was made for id ... the joystick's ID string; this is one of the name[]s and the reason why this driver was picked up source ... the file path to this driver m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
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. Ampere ___ 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
RE: [Flightgear-devel] Pending v0.9.9 release
Curtis L. Olson writes We haven't officially decided, but right now we are talking about doing a v1.0 release after the dust has settled on 0.9.9. That would likely happen sometime early 2006 after the holidays. This sounds good I have a 737 on the go but it won't be finished in a week.I am hoping for sometime in January 2006 Regards, Curt. Cheers Innis ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 31, Issue 30
Syd, I didn't intend that to be a criticism of any sort.. I much appreciate the effort of all involved with the modelling of any of the planes and models. Otherwise, it looks and feels great :-) While I haven't seen a b1900d, it seem around the mark, tend to enter a spin when air speed drops too low but that's extreme flight dynamics. George Patterson Hi George no, I didnt take it as critisism . Just thought I'd let you know that I did run across the same problem ... just not sure how to fix it :) ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Which aircraft to include in v0.9.9?
Hi Stefan Stefan Seifert writes Before 0.9.9 is released I think one problem should be resolved: on some planes (like the 737, f16, Concorde, fokker100) the engine sounds are missing. Specifically Sounds/jet.wav is not audible. I discussed this problem some weeks ago on the IRC channel and tried to find out what's causing it. It's no local problem and happens to all planes that use the /engines/engine[0]/thrust_lb[0] property for volume calculation. I had to stop investigating due to some real life stealing my time, but I'm sure this should be fixed before a release. I do a lot of my model testing on a 9.4 copy of FG and the engine sound is working just fine there.I will check out the 737 in 9.8 today and see if I can get to the bottom of it If someone has an idea what caused this I could spend some more time for debugging. Nine Cheers Innis ___ 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, A bit off topic: does anyone have success in compiling FlightGear and related libaries using GCC-4.0? I have only one problem, building src/FlightGear/src/Instrumentation/ od_gauge.cxx. I mentioned it in october here: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/ 039393.html the workaround is to build just od_gauge.cxx with -fpermissive. I am using: ima% gcc --version powerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc. build 5026) Copyright (C) 2005 Free Software Foundation, Inc. The problem still occurs with latest CVS. 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... best regards, Ima ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear v0.9.9-pre2
Ima, that problem can be fixed with a small patch to simgear.On 11/10/05, Ima Sudonim [EMAIL PROTECTED] wrote:Ampere, A bit off topic: does anyone have success in compiling FlightGear and related libaries using GCC-4.0?I have only one problem, building src/FlightGear/src/Instrumentation/od_gauge.cxx.I mentioned it in october here: http://mail.flightgear.org/pipermail/flightgear-devel/2005-October/039393.htmlthe workaround is to build just od_gauge.cxx with -fpermissive.I am using:ima% gcc --versionpowerpc-apple-darwin8-gcc-4.0.0 (GCC) 4.0.0 (Apple Computer, Inc.build 5026)Copyright (C) 2005 Free Software Foundation, Inc.The problem still occurs with latest CVS.Alex,I guess you're not seeing this problem with 4.0.3 ? Nice to know it'sbeen fixed! (assuming it's not a private patch) 8-) Now if only applewould update to 4.0.3...best regards,Ima___Flightgear-devel mailing list Flightgear-devel@flightgear.orghttp://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d-- Arthur/- http://sourceforge.net/users/artooro/- http://artooro.blogspot.com ___ 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] CVS problems
Hi all, I am having a problem compiling the lattest ( 1/2 Hour ago ) flightgear. I have also updated simgear and recompiled. the error I get is while making flightgear as follows, Making all in MultiPlayer make[2]: Entering directory `/root/source/src/MultiPlayer' if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT multiplaymgr.o -MD -MP -MF .deps/multiplaymgr.Tpo -c -o multiplaymgr.o multiplaymgr.cxx; \ then mv -f .deps/multiplaymgr.Tpo .deps/multiplaymgr.Po; else rm -f .deps/multiplaymgr.Tpo; exit 1; fi if g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -I/usr/local/include -g -O2 -D_REENTRANT -MT mpplayer.o -MD -MP -MF .deps/mpplayer.Tpo -c -o mpplayer.o mpplayer.cxx; \ then mv -f .deps/mpplayer.Tpo .deps/mpplayer.Po; else rm -f .deps/mpplayer.Tpo; exit 1; fi make[2]: *** No rule to make target `tiny_xdr.cpp', needed by `tiny_xdr.o'. Stop. make[2]: Leaving directory `/root/source/src/MultiPlayer' I have tried ./configure --without-multiplayer but it didn't help. Thanks Jason Cox ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear v0.9.9-pre2
On November 9, 2005 02:46 pm, Curtis L. Olson wrote: The more build errors and platform bugs we can catch now, the smoother the v0.9.9 release will be for your favorite platform! Well, I still can't get FlightGear to run under Xorg at 24bit depth. I am still getting the following messages: X Error of failed request: GLXUnsupportedPrivateRequest Major opcode of failed request: 145 (GLX) Minor opcode of failed request: 16 (X_GLXVendorPrivate) Serial number of failed request: 41 Current serial number in output stream: 42 freeglut (/usr/local/FlightGear/bin/fgfs): Failed to create cursor If I switched to 16bit, I get the following messages: freeglut (/usr/local/FlightGear/bin/fgfs): Failed to create cursor freeglut ERROR: Function glutSetCursor called without first calling 'glutInit'. Here are my graphic related packages: ii xserver-common 6.8.2.dfsg.1-10 files and utilities common to all X servers ii xserver-xfree866.8.2.dfsg.1-10 transitional package for moving from xfree86 ii xserver-xfree86-dri-trunk 2004.02.28-2 The XFree86 X server [DRI trunk] ii xserver-xorg 6.8.2.dfsg.1-10 the X.Org X server ii xlibmesa-dri 6.8.2.dfsg.1-10 Mesa 3D graphics library modules [X.Org] ii xlibmesa-gl6.8.2.dfsg.1-10 Mesa 3D graphics library [X.Org] ii xlibmesa-gl-dev6.8.2.dfsg.1-10 Mesa 3D graphics library development files [ ii xlibmesa-glu 4.3.0.dfsg.1-14sarge1 Mesa OpenGL utility library [XFree86] ii xlibmesa-glu-dev 4.3.0.dfsg.1-14sarge1 Mesa OpenGL utility library development file lspci: :02:0b.0 VGA compatible controller: ATI Technologies Inc RV280 [Radeon 9200 SE] (rev 01) (prog-if 00 [VGA]) Subsystem: C.P. Technology Co. Ltd: Unknown device 2074 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium TAbort- TAbort- MAbort- SERR- PERR- Latency: 64 (2000ns min), Cache Line Size: 0x04 (16 bytes) Interrupt: pin A routed to IRQ 169 Region 0: Memory at e000 (32-bit, prefetchable) [size=256M] Region 1: I/O ports at d000 [size=256] Region 2: Memory at ff9f (32-bit, non-prefetchable) [size=64K] Expansion ROM at ff9c [disabled] [size=128K] Capabilities: available only to root Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
