[Flightgear-devel] Mouse frozen after running fullscreen
Since I updated FlightGear a few days ago, my X Windows mouse has been frozen after exiting whenever FlightGear is in full-screen mode (there is no problem in window mode). Switching to a text console and back does not help -- I end up having to restart X. Any suggestions on where I should start looking for the problem? I don't know much about SDL. Thanks, and all the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Mouse frozen after running fullscreen
David Megginson writes: Since I updated FlightGear a few days ago, my X Windows mouse has been frozen after exiting whenever FlightGear is in full-screen mode (there is no problem in window mode). Switching to a text console and back does not help -- I end up having to restart X. Any suggestions on where I should start looking for the problem? I don't know much about SDL. Is this specific to the SDL implementation ? i.e. does it also happen if you use GLUT instead of SDL HTH Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mouse frozen after running fullscreen
Norman Vine wrote: David Megginson writes: Since I updated FlightGear a few days ago, my X Windows mouse has been frozen after exiting whenever FlightGear is in full-screen mode (there is no problem in window mode). Switching to a text console and back does not help -- I end up having to restart X. Any suggestions on where I should start looking for the problem? I don't know much about SDL. Is this specific to the SDL implementation ? i.e. does it also happen if you use GLUT instead of SDL A while back I added code to hide the mouse pointer after 10 seconds of inactivity. This is configurable in the preferences.xml file. I've never seen a frozen mouse pointer on any of the machines I've tested on (or heard of it with anyone else) but it's the only mouse related change I'm aware of. 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] terrasync and terrain/scenery
Does terrasync download terrain only or scenery objects as well. Because the current terrasync repository still has the old structure IMO. (I set the terrasync root dir to fgfs/data/Scenery/Terrain to get it work, but this doesn't include objects download, as they are in fgfs/data/Scenery/Objects, right?). - Matev ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Matevz Jekovec wrote: Does terrasync download terrain only or scenery objects as well. Because the current terrasync repository still has the old structure IMO. (I set the terrasync root dir to fgfs/data/Scenery/Terrain to get it work, but this doesn't include objects download, as they are in fgfs/data/Scenery/Objects, right?). You will only get windsocks and radio towers (in the US only) simply because there are no objects for the rest of the world (yet). Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Spitfire - new release
Eric has kindly uploaded the most recent release of the Spitfire model to cvs. If you haven't already noticed, this release adds a fuel system with Upper and Lower tanks (which are interconnected), priming pump, fuel cocks, and a fuel gauge. Unfortunately, there are three problems with this release: 1. With both fuel cocks open, when the fuel in the Upper tank runs out, the engine stops, despite the lower tank having fuel available and being selected. This is, I believe, due to a bug at line 67 of the script ~/data/nasal/fuel.nas which improperly sets the tank property kill-when-empty. This problem is not unique to the Spitfire model, but affects all YASim models. This can readily be demonstrated by taking any such model, and using the drop-down dialog to reduce the fuel in one tank. With the engine running you can watch the fuel in that tank run out and the engine stop. 2. If both fuel cocks are moved to the off position and back to the on position the engine will not start or restart, even if fuel is available in all tanks. The Simulator has to be restarted to overcome this problem. This problem is caused by the logic of fuel.nas, and is not a bug. 3. When a tank is empty, the tank is de-selected by fuel.nas. Thus the position of the fuel cock levers on the Spitfire panel do not necessarily reflect the state of the tank. Again, this is not a bug, but a consequence of the logic of fuel.nas and of the operation of the levers. Solutions: 1. Short term. A. Use only the Lower Tank. Although this is contrary to the POH, it works perfectly well. B. Avoid setting both fuel cocks to off. C. Move the fuel cocks through their full range to realign them 2. Medium Term. I attach a script - fuel-new.nas which is a minor modification of fuel.nas that works around the bug at line 67 and modifies the logic so that problems 1 2 above are corrected. Problem 3 remains. You can use this script to replace fuel.nas if you want, or perhaps, if accepted, it could be uploaded to cvs as a temporary replacement for fuel.nas. I believe that it will work for all YASim models, and has no adverse effects on non-YASIM models: don't throw fuel.nas away just in case (But don't leave both in ~/data/nasal). 3. Longer term. It would be a better solution if the problem with line 67 could be investigated so that it can be made to work correctly. Similarly, the logic of fuel.nas could be reviewed to correct problems 2 3 above. I am well aware that Andy is very busy right now, but perhaps he could spare some time? On the other hand, this is not a show-stopper. Melchior Franz has been most helpful in helping me with testing the problems and the replacement script. I think that he may be in a position to confirm both my findings and the efficacy of the new script. Regards, Vivian fuel-new.nas Description: Binary data ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] terrasync and terrain/scenery
Erik Hofman wrote: Sent: 12 August 2004 14:59 To: FlightGear developers discussions Subject: Re: [Flightgear-devel] terrasync and terrain/scenery Matevz Jekovec wrote: Does terrasync download terrain only or scenery objects as well. Because the current terrasync repository still has the old structure IMO. (I set the terrasync root dir to fgfs/data/Scenery/Terrain to get it work, but this doesn't include objects download, as they are in fgfs/data/Scenery/Objects, right?). You will only get windsocks and radio towers (in the US only) simply because there are no objects for the rest of the world (yet). I'm not sure, because I change things so often, that if you set the scenery path to include both the default scenery, and the down-loaded terrasync scenery thus: --fg-scenery=/FlightGear/scenery:/FlightGear/data/Scenery Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Regards, Vivian ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] tough week
Hey guys, For all of you who have emailed me and still haven't received a response, I just wanted to let you know that I haven't forgotten about your messages. They are still in my pending/inbox. I was out of town over the weekend and this has been a tougher than average week here. My wife started back to work full time and the kids started up in day care full time so we have massive scheduling adjustments going on here, and mornings/evenings have become way more hectic. Also I have a huge thing going here at my day job with a tight deadline (end of next week) so it's tough for me to sneak a few background few cpu cycles during the day for FG stuff. And on top of all that, my big dog has become very un-well and we aren't sure yet what's going on. We are starting to get pretty worried about him. I know that several people have emailed me with important FG stuff and it's all still in my pending inbox, but other than lurking and maybe kicking out a quick message here or there relating to things that are quick/easy, I'm probably not going to be able to deal much with FlightGear stuff this week ... and maybe not next week either the way things are going ... 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 [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spitfire - new release
Vivian Meazza wrote:
This is, I believe, due to a bug at line 67 of the script
~/data/nasal/fuel.nas which improperly sets the tank property
kill-when-empty.
Haven't we already been here and thrown out this explanation? Here is
line 67:
if(t.getBoolValue(kill-when-empty)) { outOfFuel = 1; }
The property is *read* here, not written.
Can someone else reproduce this issue (the tank's kill-when-empty
property being set mysteriously) with another aircraft?
Andy
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Spitfire - new release
Melchior FRANZ wrote: Yes, I've seen these annoying bugs in both the Spitfire and the p51d. Vivian's changes to fuel.nas fix them. I haven't seen any negative side effects. Could someone please replace fuel.nas? Could someone *PLEASE* explain, from scratch, exactly what is wrong with the current implementation? The patch to fuel.nas changes the intended behavior, for no reason that I can identify. Describe only the bug please, not the changes. Yes, I've been busy and others have had to fill in to fix issues with YASim. But no, this really isn't the right way to do this. I promise. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] terrasync and terrain/scenery
Vivian Meazza wrote: Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Are you sure about the radio towers? Curtis uses an US only database for that ... Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: terrasync and terrain/scenery
* Erik Hofman -- Thursday 12 August 2004 19:00: Vivian Meazza wrote: Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Are you sure about the radio towers? Curtis uses an US only database for that ... He probably means the beacons. These are everywhere, along with the towers socks. m. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: terrasync and terrain/scenery
Melchior FRANZ wrote: * Erik Hofman -- Thursday 12 August 2004 19:00: Vivian Meazza wrote: Then windsocks and radio towers will magically appear in Europe. Or anyway, they do for me :-). Are you sure about the radio towers? Curtis uses an US only database for that ... He probably means the beacons. These are everywhere, along with the towers socks. Ah, that would make sense. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
David Megginson said: Chris Metzler wrote: Is there an official announcement of this somewhere? I've looked all around the NGA and NACO sites but haven't found anything. How did he hear about this? Is there any kind of timetable? Were there reasons stated? According to the message I quoted, the Australian government is suing Jeppesen for publishing information obtained from Australian aviation publications. That's bad news not only for the flying community but for the Ah...oh. H. What is the AIP? I hadn't read government into that first posting at all, but maybe there was a typo. If it is the RAAF or Aussie government in some form, this could be a serious problem for information on the web, that goes a bit beyond this one data set. Uggh...greed. Best, Jim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Spitfire - new release
OK, Melchior helped to debug this via chat while I was working on cell phone UI bugs at work. :) It turns out to have been a pair of typos in fuel.nas that were causing all the problems. What I *read* wasn't what the code was actually doing, which explains all the confusion. This one, though, isn't fixed: 3. When a tank is empty, the tank is de-selected by fuel.nas. Thus the position of the fuel cock levers on the Spitfire panel do not necessarily reflect the state of the tank. This is really a metaphor collision. The notion of a tank selected as used by the fuel code and FDM isn't quite the same as that of position of the switch in the cockpit (the magneto switches have traditionally had the same issue). It might be a better idea to define a different property to drive the fuel cock animation, and use a Nasal binding to synchronize this with the tank selected property only when it changes (basically: make the fuel cocks output only devices). Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ALERT: Losing the DAFIF
David Megginson said: Lee Elliott wrote: I'm pretty sure that information/data can't be copyrighted - but the design of the presentation of the information/data can. I hope not, but every country has its own (bizarre) laws about this kind of thing -- for example, in Commonwealth countries, including Canada and Australia, the Book of Common Prayer has a perpetual copyright in the name of the Queen. Jeppesen does draw its own approach plates, updated based on the information in the Australian AIP (I'd assume), so it really looks like a data grab from the little I've seen so far. Before I bash Oz any more, I'll repeat the problem that Garmin had with my own government recently. The Garmin 296 handheld GPS includes terrain obstructions (such as towers), which could save of lives; however, the Canadian government refused to provide obstruction information for Canada unless they got a royalty for each unit sold -- as a result, Canadian pilots do not see towers displayed on their Garmin 296 units, and at least a few will likely crash in the next few years as a result, costing the Canadian government millions in search and rescue, medical bills, lost taxes, etc. etc. But people don't mind paying all sorts of taxes for emergency services. It is those behind the scene revenue streams (e.g. royalties), which can be used to fund politically unpopular line items, that government officials find hard to come by. Best, Jim (the pesimistic american) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
