[Flightgear-devel] Modular / portable cockpit design
On 2 Dec 2005, at 00:32, John Wojnaroski wrote:Just a question of time and energy. The design issue is how to keep it portable so we can haul the gear around to shows like Scale4x coming up in Feb 06. Same problem with putting everything into a shell, fantastic for a fixed installation but kind of like the old story of the fellow who builds the 30 foot sailboat in his cellar I would talk to some exhibition set / theatre set people if you can (I am slightly involved in the tech side of an amateur theatre company) - generally such people have to produce stuff which is pretty cheap, pretty durable and which can be transported, assembled and taken apart pretty fast without lots of support equipment.As far as I can tell (I haven't worked on set myself), a lot of it comes down the finding sufficiently fancy pins / hinges / bolts / locks that you can have everything be modular (eg, the pedestal, main panel, glare shield), but still be rock solid when it's all set into place. Experience is a big factor in that...James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 25 Nov 2005, at 00:33, David Luff wrote:Thanks, that's great! Would you prefer me to upload it to SourceForge for download from there, or to simply provide a link to your webspace?There's no problem with leaving it in my webspace, but you may as well add it to SF -that way you get SF's download stats and so on. No problem. I don't really know much about Mac versions. Am I right in thinking that Tiger is the latest one? Does one have to pay to upgrade from one version to another? Tiger is the latest, upgrading from any previous versions costs in the region of £90 / $110 I think. As I said, producing a panther build should be doable by someone with Panther, or if you get many complaints, I can set up a cross-build environment to target Panther myself; I'm just being lazy on the assumption flight sim users are probably early-ish adopters and already have Tiger...HHJames -- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 23 Nov 2005, at 20:44, David Luff wrote:Disregard this, using the current X-Plane data everything works. It's my fault for not reading the instructions. Will test some more (and, err, get some sleep) and post a link to a .dmg once I verify what happens on Panther. Thanks, I'm looking forward to it :-) I'll probably ditch support for the old FG data format in the next version - should reduce the potential for confusion. Okay, a DMG is available from my .Mac account: http://homepage.mac.com/zakalawe/.Public/taxidraw-0.3.2.dmgThis only works on Tiger; the problem (or at least the first one) is that Tiger ships with libcurl-3, wheras Panther only includes libcurl-2. I suspect a build from source on Panther would produce something that works just fine, and I've said as much in the readme file. If this is a big problem, I can setup my build environment to target Panther and rebuild wxMac + taxiDraw, it's just a bit complex so I will hold off for now.Hope this helps some people out,James -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 22 Nov 2005, at 23:50, David Luff wrote:Are there any Mac developers here who might be able to make up a Mac package of TaxiDraw v0.32 for me? The last version was done an X-Plane user, but there is no Mac binary available for the current version, and the Mac is popular among X-Plane users. TaxiDraw source can be found at http://taxidraw.sf.net There should be very few code tweaks needed (I *think* I got most of the patches required for the last version into the code), but a non-unicode version of wxWidgets is needed for compilation (the next version of TaxiDraw should be unicode-safe). I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.HHJames___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 22 Nov 2005, at 23:17, James Turner wrote:I built a binary that ran last year, haven't tried in ages - the issue is getting everything required linked statically, I think. I shall experiment, but don't let that stop any other Mac people having a go.Okay, so building it was pretty painless (mostly because wxMac almost works out of the box these days; I had to create a few symlinks to get it to link, but anyway). I have a static taxidraw binary, which should work on Tiger (10.4), but probably not on anything earlier, I'll try Panther at work tomorrow.And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.HHJames -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Request to the Mac folk
On 23 Nov 2005, at 00:23, James Turner wrote:And now the bad news - when I point TD at my (CVS) apt.dat (unzipped), and do 'New...', I enter an ICAO code (say, EGPH), and crash. The crash is consistent at line 48 of fgfsIO.cpp: looking at the code it seems like a string-pointer issue. Is this a Mac-specific problem? I can dig deeper, but some guidance would be good.Alternatively, I can just upload what I have someplace and people can try - perhaps X-Plane data files would work.Disregard this, using the current X-Plane data everything works. It's my fault for not reading the instructions. Will test some more (and, err, get some sleep) and post a link to a .dmg once I verify what happens on Panther.BTW, David, you should really investigate using a config.h - your compile lines are, uh, rather long :)HHJames -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture isnotinitialized!
On 19 Nov 2005, at 01:49, Arthur Wiebe wrote:I have found the problem. My Xcode projects seem to be buggy. The PLIB project is fine but something is wrong with the SimGear project. I just built using the autoconf system and everything worked fine. It even fixed my spash screen problem! :) I'll try to have it fixed by tomorrow afternoon if possible. I'll experiment as well - I had some strange issues earlier in the year building FG with my own X-Code projects; I was being more ambitious, and building PLIB and SimGear as frameworks, but on reflection that's not such a great idea. One change I have made is to use a 'copy files' stage for your Prepare files; otherwise they always touch config.h / version.h, and that tirggers a dependant rebuild of many files for me. The Copy Files stage has the right 'only re-copy if src mod time is more recent than existing destination' logic.HHJames -- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RenderTexture::BeginCapture(): Texture is not initialized!
On 18 Nov 2005, at 20:08, Arthur Wiebe wrote:When running fgfs 0.9.9 I get this output: opening file: /Users/arthur/Projects/FlightGearOSX/data//Navaids/carrier_nav.dat /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat RenderTexture::BeginCapture(): Texture is not initialized! /Users/arthur/Projects/FlightGear/../SimGear/SimGear/simgear/threads/SGThread.hxx:233: failed assertion `status == 0' Abort trap At first if failed right after this line: /Users/arthur/Projects/FlightGearOSX/data//Navaids/TACAN_freq.dat But then I uncompressed TACAN_freq.dat.gz and carrier_nav.dat.gz and got past that. And now it aborts with RenderTexture. As long as things go like this there'll be no Mac release anytime soon. I built from CVS last night (using Arthur's XCode projects, I've got 2.2), and hit this problem. I assumed it was a local config problem, but from Arthur's description it is something that broke very recently hmm. The obvious reason for this to fail would be a corrupted / un-inited SGMutex; I am going to add some logging and check.Arthur / Ima / Anyone - can you confirm the latest CVS versions of SimGear / FlightGear that worked?James -- All hail the hypno-toad! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mac thread woes.
On 18 Nov 2005, at 22:18, Adam Dershowitz wrote:But then it continues to load and run. So I think that the error may be a red herring, and not the cause of the abort that you are seeing. The RenderTexture error is a red-herring, for certain, and by instrumenting SGThread I've found at least two trigger points - one in SGMutex, and another in SGPthreadCond. In both cases the pthread function is returning EINVAL, even though the object at the address has been created (I've instrument the mutex create/destory paths too).So, it's weird - perhaps something is trampling some memory structures? Hmmmph.James -- There is no such thing as a humble opinion. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] XCode project files
On 12 Nov 2005, at 14:30, Arthur Wiebe wrote:I've been using Xcode 2.2 for some time now building Flightgear and everything else. Preview builds until now of course.By the way Xcode projects you can use to build PLIB, Simgear, and FlightGear are available now. I've polished them up so they should be ready. If you're interested I'll commit them to the macflightgear cvs.Please do commit them, I've had hand-rolled projects for all three for some time, but they're out of sync. If I find any issues, I'll let you know.James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] diff for browser change for mac os x to use safari
On 12 Nov 2005, at 00:58, Ima Sudonim wrote:With this change, FlightGear on Mac OS X launches the mac os x Safari browser instead of netscape (w/o this change, the browser won't launch without netscape installed, and netscape isn't one of the installed mac os x browsers). This approach seems silly - I've got Core Foundation code to launch a URL string via LaunchServices - using whatever browser the user has selected in the system. Hard-coding a browser is always going to annoy people.I'll post the patch once I dig out the code.HHJames___ 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 9 Nov 2005, at 19:31, 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... De-lurking for a moment,I recall the original intention was to include at least one aircraft from each common category (single, light twin, heavy twin, bizjet, etc). The new criteria seems to be features / polish / completion - I'm not arguing which criteria makes more sense for a 0.9.9 or 1.0 release, but that's why the c310 is in, as I understand it - in the absence of a Baron or Diamond TwinStar, it's the only light twin that really exists with a model and cockpit. It's had very little love, and the default skin has been the military variant, which a few people have objected too in the past.If the argument about 'covering the categories' still holds, then replacing the c310 with b1900d is moot - for sure the b1900 should go in, because it's polished and slick, but it's a totally different class of aircraft (replacing the DC-3 with the b1900d would be more equivalent, but there are other reasons the DC3 is nice)Anyway, I guess all I'm really saying is, it sounds as if the criteria for inclusion have shifted changed, and that's fine, but it might put the existing aircraft selection from 0.9.8 in a new perspective.JamesPS - any time someone wants to do the TwinStar, I am prepared to offer all kinds of bribery! Cash, beer, you name it! -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On 14 Oct 2005, at 08:33, Oliver Schroeder wrote:Finding the "right" port isn't easy, since we have about 32 thousand (64 thousand on newer OSes) to choose from ;) However, I decided to use port 5000 on the server-side (and 5001 for telnet), both ports are configurable but these are the defaults. Both ports are only used by the free internet chess server (fics), which uses tcp. The udp ports are not used, yet. (AFAIK) Although a client can choose any incoming port he prefers, my personal predilection is to use the same port as used for outgoing. (=5000) It would be better to pick a port range that is entirely unused, for two reasons:- I think there's an implicit assumption that if the TCP port is well-known, the UDP port is reserved for your use- This stops FG providing a TCP alternative to UDP on the same port, which is something I think should be done anyway. Requiring people to update their firewall NAT tables is not a long term approach, even assuming the user is permittd to do such a thing; a much better approach is to have a 'try UDP, fall back to TCP approach', since TCP traversal from inside the firewall to out 'just works' with most NAT boxes. (One solution to using UDP is to implement Microsoft's UPnP system for asking the firewall to set up a dynamic port forward, but we looked at doing that for WorldForge and it's horrible. Really big spec. Nasty.)- As a side issue to the second point, unless you want to implement your own reliable layer on top of UDP (boring, fiddly), it makes sense to have a TCP channel open anyway for reliable transfer of critical information. Textual ATC might fit into this category, and I'm sure there is other meta-info that should be reliably delivered.HHJames-- Some people, when confronted with a problem, think “I know, I’ll use regular expressions.” Now they have two problems. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [PATCH] README.multiplayer update
On 14 Oct 2005, at 10:27, Oliver Schroeder wrote:But I do admit, that it might be a huge barrier for a user to alter firewall rules as needed. But anyway, using a fallback mechanism leads to everyone using tcp connections, as they would simply work. And I repeat, you don't want tcp in multiplayer environments. I simply don't agree with that statement - many Windows games offer both options, for this exact reason. The notion that using TCP for multiplayer games is inadvisable is simply unfounded in my experience. It is certainly 'conventional wisdom' that TCP is evil / bad / slow, and for sure it offers a performance and overhead cost, but TCP works perfectly acceptably providing you have a faster-than-modem connection and low packet loss rates, which is the case for virtually everyone with a DSL or cable connection these days.Back in the days of QuakeWorld and Tribes 1, for sure this was more critical, but we've using nothing but plain TCP in WorldForge for years, in a interactive environment, and the response is pretty good. For sure we will move the 'lossy' position update data to UDP in the future to get smoother updates, but it's purely an optimisation, and we will always keep TCP as a fallback, since so many people are NATed.So my perspective is that amount of code added is trivial, the usability benefit is high, the people who can make UDP work see no change, and a large group of people who previously would be completely unable to use MP can give it a go. Anyway, I'll resume lurking now.James -- Java is, in many ways, C++-- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Scenery files triangles
On 13 Jul 2005, at 15:36, Andy Ross wrote:These days, it's usually faster to use indexed vertices. Strips and fans are faster because they reduce the number of vertices that need to be transformed by (and sent to) the hardware by "saving" 1 or 2 from the last triangle drawn. But modern cards have vertex caches that are much (!) larger than 1 or 2 entries. If someone wants to change the terrain format, I'd suggest trying indexed vertices first -- it's simpler, too. Whilst wishing to avoid a 'me too' post, I fully agree with this; writing a strip-ifier is a complex job, storing each tile as several, or maybe even one vertex array with indices is easier to generate, involves fewer SSG nodes, and is easier for drivers to optimise on the card, than either fans or strips.James___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fedora Core 4
On 12 Jul 2005, at 03:14, Paul Kahler wrote:I'm looking to build FGFS on FC4-x86_64. I looked at the instructionsat: http://www.flightgear.org/cvsResources/anoncvs.html It soundsreasonable, but I can't just "yum install plib". Is there a repositorywith a suitable package? A link to instructions on using non-standardrepositories would also be helpful ;-) http://download.fedora.redhat.com/pub/fedora/linux/extras/4/x86_64/(and search for plib)http://download.fedora.redhat.com/pub/fedora/linux/extras/readme.extrasBut for simgear / flightgear, you need to build following the instructions on the website; also if you want to run a CVS version of plib (to get bugfixes), then obviously you can't use the fedora-extras version.If someone here is building simgear / flightgear packages and providing a custom repo, I've never seen it mentioned.HHJames--The real enemy is the gramophone mind, whether or not one agrees with the record that is being played at the moment.___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear Build Problem Under MacOS 10.4
On 20 May 2005, at 15:30, Andy Ross wrote:it is no longer legal to do this: int i; glGenTextures(1, i); Instead, you have to declare 'i' as GLint (and similarly for GLuint and so on) Are you sure? I thought the Apple compiler was still a 32 bit environment on OS/X. And in any case, PPC64 is an "LP64" ABI, which means that a plain "int" is still 32 bits, just like GLint. Really, there are no meaningful (for our purposes) systems any more where an "int" is anything but 32 bits. The size of longs and pointers is variable, but ints are pretty fixed. Umm - I am not sure about the reason for making the change, but the fact is that on Tiger, GLuint is a typedef for 'unsigned long'. Hence, the code has to be changed to use the portable names, or GCC 4.0 chokes.Next time I run into an Apple engineer, I'll ask about this.HHJames ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: opening window splash screen
On 5 May 2005, at 09:18, Melchior FRANZ wrote:Oh. I hope you mean that the startup time has become much too long over time, and not that this patch made it worse. I don't think that the patch has a noticable effect, neither positive nor negative. Except that it possibly improves the perception and makes it feel a bit faster. And that will further improve with progress info. What has slowed down fgfs in the last time was the migration to the new database formats -- not because they are read less effectively, but simply because they contain much more data. That's at least the impression that I got from valgrind (http://www.valgrind.org/) runs. I don't have much time to delve into this right now (hah!), but I have some log calls in my local build, which have been fairly consistent (haven't tested since your changes, Melchior - when I do, I'll post those numbers).That said, here are the numbers I have (for three runs) time to run fgMainInit: 44 sec 32 sec 29 sectime between idle_state 0 and idle_state 1000 33 sec 10 sec 10 sec(wall-clock) time after hitting idle_state 1000 before scene appears consistently about 25 - 30 secondsComments - the first phase (lots of database traversal) is obviously very dependant on file system cache hot-ness, and the second phase similarly. The third phase, *after* idle-state 1000, is the bit I was referring to when I talked about starvation; while it's doing this wait, I see the splash screen, and see log output from subsystems frequently (traffic manager, clouds, ephemeris), but it seems to sit there for ages before showing the cockpit + scenery.I ran a statistical profiler on the startup, and it didn't get all the way through startup before it hit it's log size limit, but the first part was spending huge amounts of time parsing data files, especially doing string - to float parsing. Doing the equivalent of 'atof' was something like 11% of the total time for the profile I ran.Lazyness is the way to go here, I'd suggest. Or binary file formats.James -- Ignorance more frequently begets confidence than does knowledge. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] opening window splash screen
On 4 May 2005, at 21:39, Melchior FRANZ wrote:It opens the window (with splash image if configured) as soon as possible, and does all the other initializaion in the idle loop, split up into appropriate chunks. The patch does basically only shuffle parts around, without changing the order of initialization or removing anything. It is tested with glut sdl, with and without /sim/startup/splash-screen and /sim/sceneryloaded-override. Minor partial objection - the Mac startup is dog slow (like 90 seconds to get to a usable plane in the C172 and SFO), and I think at least part of the problem is the 'init while idle' scheme - FG wastes too much time doing rendering type things when I'd be happier to have it be 'frozen' but take half the time.I think the fix for this could be as simple as a render flag that disables the entire scene graph and replaces with a dummy scene (black screen + progress bar?) while some property is set.Ah, wait ... does this affect tile-loading and hence hit-testing and hence ground-trimming?Anyway, I am nervous of changes that do yet more stuff in the idle callback, because I think it's a bit starved for time.HHJames -- Some people, when confronted with a problem, think I know, Ill use regular expressions. Now they have two problems. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 09:46, Erik Hofman wrote: Modified Files: fg_os_sdl.cxx Log Message: Melchior FRANZ: Make SDL window resizable; This exposes the same problem that many GLUT users have: resizing up may cause a temporary switch to software rendering if the card is low on memory. Resizing down again switches back to HW rendering. (KSFO is texture intensive, but there are no problems in LOWL, and elsewhere.) Less and less users will have the problem as cards become better, and it's no reason not to allow resizing altogether. Bad news - I've had this change in my tree for a few months now, and it doesn't work right on OS-X, due to a fairly deep-rooted problem with PLIB / FlightGear - there doesn't seem to be a way to do a 'vid restart', i.e force every display list / buffer / texture to get deleted and reloaded. This is really something that should be supported at the PLIB level, but, well, that's another story. Anyway, the Linux GL implementation appears to re-use GL contexts upon re-size, but the OS-X sometimes tears them down and re-allocates them. When this happens, I get a very interesting looking, un-textured version of FlightGear; kinda retro but not usable. Incidentally, the OpenGL spec dodges this whole issue, but from porting various other pieces of GL code, the rule seems to be that Windows and Linux tend to re-use contexts (but some Windows drivers don't always), but the Mac drivers are very aggressive about throwing out contexts are starting again. Anyway, the 'display lists and textures are valid across a context change' assumption is basically an unportable one. BTW, this is also the reason it's hard to do a 'full-screen toggle' at runtime (which otherwise would be easy in SDL), or other graphics changing options. However, I had a look around the code and I'm pretty sure trying to make vid-restarts possible at this point would be quite invasive changes, so I didn't even bother to suggest it. Ho hum, James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 11:14, Melchior FRANZ wrote: So then add a #ifdef for OS-X around the resize event, so that it is simply ignored? Did you send a bug report to the SDL people? I think you misunderstand, it's not an SDL bug: *FlightGear is relying on assumption about how OpenGL implementations work that does NOT hold on OS-X, and may not hold on some Windows drivers, but which happens to hold in the common case on Windows, and apparently always holds on Linux* There are plenty of SDL + GL applications on the Mac that do re-sizing just fine, but they have the ability to initiate a vid-restart (as they correctly should on *every* platform, strictly speaking) when re-sized. Of course, we can certainly live without the feature on Mac - just be aware the fault lies with FG / PLIB for not providing an API that is somewhat important in real-world situations. I for one would love to be able to switch from full-screen mode to windowed while running, for example. HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: FlightGear/src/Main fg_os_sdl.cxx, 1.11, 1.12
On 6 Apr 2005, at 12:53, Melchior FRANZ wrote: Err ... or is it SDL_SetVideoMode() in SDL's video/SDL_video.c? There's a suspicious comment in there: * WARNING, we need to make sure that the previous mode hasn't * already been freed by the video driver. What do we do in * that case? Should we call SDL_VideoInit() again? */ Would be nice if we could identify and fix the bug where it is, instead of removing a useful feature that is certainly *not* the bug. I'm going to restate the problem, just to be very clear. - When a window is resized, SDL (or GLUT) need to re-allocate the GL context. The SDL documentation explicitly mentions that SDL_SetVideoMode will be called again with new size, so a new context will definitely get created on the Mac. I'm putting aside any platform specific ways to modify existing contexts. - There is nothing (absolutely nothing) in the OpenGL spec about the sharing or lifetime of texture objects or displays lists across different contexts - logically they are completely separate. - The current FlightGear code assumes that display lists and textures are preserved across a context switch. - This has not been noticed for the past X years because it *so happens* that the Linux and stock Win32 implementations happen to implement the sharing behaviour between contexts, while OS-X does not. Both behaviours are completely valid and compliant implementations of the OpenGL spec. - Most (if I'm being bitchy, *good*) scene-graph / engine libraries have some kind of 'invalidate' button you can kick that makes them delete all their display lists / textures and reload them. This is what Unreal / Quake / etc are doing which you change full-screen-ness or many other graphics settings while they running, i.e a vid restart. - Making PLIB / FG support vid restarts would be a very good thing to do, but would be a lot of work and invasive. I would be happy to give it a go if I thought the patches would be accepted! - Until such a change is made, re-sizing the window is not going to work right on OS-X - We can live with this situation. But if there are any user bugs reported from Windows users with odd drivers about 'everything looking crazy after I resize the window', well, now you know :-) Regards, James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Running Flightgear on Mac OS X
On 10 Mar 2005, at 05:02, Josh Babcock wrote: I've successfully compiled Flightgear from CVS (thanks for the help), but for some reason it won't run. FlightGear loads and all i see is a Black screen with a white box in the middle (where the splash screen should be). The CPU usage goes to 100% and stays there until i kill fgfs. Sounds like it is using software rendering. Do you have a 3D card and the appropriate driver installed? It would help to know what OS, driver and 3D card you are using. It is pretty much impossible for any recent Mac to use software rendering - even a G3 iBook has some kind of Radeon in it as standard. What this could be is something that caught me ought the first few times - FG is now taking an looong to startup on OS-X, something on the order of 90 seconds on my PowerBook G4 1GHz. The first few times I assumed it had hung, but then I waited and it actually got as far as showing the splash screen. I have spent some time doing some profiling and spot timing of startup, and unfortunately there are no really obviously bad things happening; there's just an awful lot of work to be done, much of it greedily, and it takes a while. If you run with the logging level put back up (as it used to be), you can see all the work that's going on. Of course, your problem could be something completely unrelated - you could run under gdb and ctrl-c once it seems to have stopped, to find out where. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: instrument xml question
On 4 Mar 2005, at 15:08, Curtis L. Olson wrote: It's maybe analogous to writting assembly language without any sort of jump labels ... anytime you insert a statement, you have to go back and recompute all your jump addresses (or in this case any time you add anything you need to go back and recompute all your indentation levels ...) An 'obvious', not non-trivial solution: the current alias logic is used to refer to one XML node, from another, using a file-system like syntax. This is pretty much the job XPaths were designed to solve. XPaths support a syntax similar to what is being used for aliases (I think), but also support matching by tag name / attribute (for example, and id attribute) So one option would be to implement a small subset of useful XPath functionality, or just to support something like a 'named-alias' where instead of using ../../../../../my-params/foo/bar you could use (for example) @my-params/foo/bar This is robust against the relative position / depth of the XML nodes changing, naturally. Implementing the '@' operator is not especially difficult, but it can be a costly operation to do repeatedly (you need to either build a map of named nodes, or do a search each time). I assume for panels the alias is only resolved at panel load, so the cost is unimportant. HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Speedbrakes / Spoilers
I've been spending as much time as possible over the past few days just flying around (I've had a very long gap where FG wouldn't build and I was busy with other things), but this has raised a small issue which may indicate something about my flying habits... Basically, I have not yet found an aircraft where the speedbrakes or spoilers seem to work, either visually or in terms of slowing the plane down. From looking at data/keyboard.xml, I can see the current bindings are j/k for the spoilers, and Ctrl-B for the speedbrake, but pressing the keys doesn't seem to do anything. So, have I missed something here? In particular, which models should have spoilers and speedbrakes that definitely work, and maybe even animate? I could swear I recall seeing pictures of the Fokker-100 with it's 'distinctive' tail brake assembly deployed. And on a related note, do any of the jets have thrust reversers installed? HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speedbrakes / Spoilers
On 10 Feb 2005, at 11:57, Innis Cunningham wrote: Basically, I have not yet found an aircraft where the speedbrakes or spoilers seem to work, either visually or in terms of slowing the plane down. From looking at data/keyboard.xml, I can see the current bindings are j/k for the spoilers, and Ctrl-B for the speedbrake, but pressing the keys doesn't seem to do anything. Can't remember if the speedbrakes actually slow the aircraft on the 737 but the animation should work when you hit Ctrl-B Ah, ok. Thanks to Martin, I realised they work on the TSR2 as well, and both the spoilers and speed-brakes work on the Fokker-100. I haven't had a chance to test if the FDM is seeing any effect yet, this is just checking over the visual models. So, apologies for the confusion, I didn't check closely enough, and the two aircraft I happen to have been using the most, the F16 and the A320, don't seem to have either system installed. And on a related note, do any of the jets have thrust reversers installed? Not that I am aware of. Drat, and no auto-brakes either - I guess I'll have to stop flying my approaches so fast :-) Adding animated reverser cowls to the A320 would be a seriously nice touch, if whoever made the model + animations has any free time to kill. HH James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Speedbrakes / Spoilers
On 10 Feb 2005, at 13:03, Martin Spott wrote:
While we are are it, do we already have consensus on which keys to use
for these functions - are the keys consistent across different aircraft
and FDM's ?
The keys do seem to be standard, j/k for spoilers and Ctrl-B for
speedbrake, the issue of course is guessing for a given model which
surfaces are assigned to which name. I guess 'things on the wings' are
spoilers, and 'things not on the wings' are speed-brakes?
Except that the TSR2's brakes are on the spoiler key. The Fokker uses
the spoiler key for the wing spoilers, and Ctrl-B for the tail-brake
thing, which seems sensible to me.
BTW, there is no keybinding for reverse thrust : I'm going to test with
some nasal code i found in one of the joystick files, but is there a
free key I should use? Ctrl-R perhaps?
Here's the snippet I found (in Top-Gun-Afterburner.xml):
reverser = !getprop(/controls/engines/engine[0]/reverser);
props.setAll(/controls/engines/engine, reverser, reverser);
if (reverser) {
gui.popupTip(Thrust Reverser ON);
} else {
gui.popupTip(Thrust Reverser OFF);
}
HH
James
--
They are laughing with me, not at me.
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Mac joysticks
I finally managed to get my FlightGear behaving itself last week - there are a few issues I want to investigate before I bring them up here, but one affected me almost immediately - the input code as it stands right now means Mac joysticks tend not to be recognised. There are two issues: firstly, when support was added in the XML joystick definitions for platform specific axis / button identifiers, a case was added for 'mac' as well as 'unix' and 'windows' - but most (none?) of the joystick files actually use this tag. Now, one option is to go around adding 'mac' tags, but at least for my SideWinder, the OS-X axis / button assignments match the Unix ones. I would be prepared to bet a small sum of money that most of the time, the assignments are going to match ... but of course I can't be sure until Mac users with some of the existing joysticks test this. (Knowing what happens with the logitech and thrustmaster sticks would be interesting) Anyway, I have a trivial patch to 'input.cxx' which adds in a fallback to 'unix' on OS-X; it works for me. The second issue is probably my fault, since I did the original code to add joystick support to PLIB on OS-X (but various people have fixed bugs since then). The code that reports the device name is only using the Product ID, and not the manufacturer ID as well. Hence, on OS-X, the name returned for my joystick is 'SideWinder Precision 2 Joystick', whereas on Linux it would be 'Microsoft SideWinder Precision 2 Joystick'. Obviously this is breaking the config lookup logic. I guess I should submit a patch to PLIB for this issue - in the short term I have just extended my joystick definition. HH James -- That which does not kill me has poor aim___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
On 1 Feb 2005, at 10:34, Erik Hofman wrote: I've done some work to make this code at least compile on MacOS. It's obvious I can't really test it myself so any patches needed to get it compiling are accepted. Those who want to implement a real render-to-texture implementation for MacOS might find the following example helpful: http://developer.apple.com/samplecode/Carbon_Pbuffer_Shared/ Carbon_Pbuffer_Shared.html I'm in the middle of trying to resurrect my FG build (right now it's dying during startup, oh well), but getting this integrated should be ok, assuming I can clone the existing WGL / GLX code. Question, though : what is FG using render-to-texture *for*? HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Mac os x simgear build break with RenderTexture.cpp
On 1 Feb 2005, at 15:11, Erik Hofman wrote: It is not yet used. I've put the code in CVS in different stages to get developers the chance to get things working without being overwhelmed with changes. At least Atlas can use this code to render the maps (accelerated) in the background though. Ok. I note that Manuel's excellent looking terrain code is using impostors, and hence will need this too, but also that GL 1.5 has finally ratified the render buffer object extension, so coding up the pbuffer stuff will be a temporary measure, with a bit of luck - render buffers are platform independent. Assuming I was to add support, is there a simple test-case? Or do I need to build Atlas? HH James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Individual aircraft downloads
On 4 Jan 2005, at 23:49, Jim Wilson wrote: tar and gzip come free out of the box on Unix. We have to get (un)zip separately to get it working. It's either way and I don't feel like giving windows users the benefit of the doubt (the number of windows _developers_ is frighteningly low compared to any UNIX flavor). gzip extracts pkzip files. Just to add an extra idea to the fire; many game engines [1] (and one bytecode computer language [2]) support reading data from compressed zip files (as certain datafiles in FG are already read from gzipped sources, I think). The code to do this can be as simple as a self contained, public-domain C file (that builds ontop of zlib), assuming only read-access is necessary. (If anyone wants the code, I can dig it out, we use it at my work for exactly this purpose) Hence, in the future, these files could be downloaded and dropped into an aircraft folder directly (this works for other kinds of 'pluggable' things too, such as scenery). The only penalty is the time taken to decompress the zip data when it's read, but zip decompression is very fast. Anyway, obviously not a priority, but it 'might be nice one day' For some reason, I have never seen code to do this with the .tar.gz format, thought in principle it should work; the issue is that ZIPs have a table of contents that can be read without extracting all the files, whereas for a .tar.gz I think you'd have to uncompresss the whole contents and then start examining the tarball. But I know very little of how tars are structured internally. HH James [1] - Quake 3 (not sure about doom) uses zip renamed to PK3, earlier versions used a custom WAD format which was essentially the same idea. CrystalSpace supports 'mounting' a .zip to access textures / meshes / etc from it [2] - Java .jar files are zips with a magic file inside -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Diamond TwinStar Panel
On 1 Jan 2005, at 17:38, David Megginson wrote: Here's a high-resolution picture of the Garmin-1000-based panel on the new Diamond TwinStar, one of my dream aircraft (it rececently crossed the Atlantic non-stop from Canada to Spain burning less than USD 200.00 worth of fuel). Anyone aircraft model designers ready to take this one on? http://www.diamond-air.at/Pressebilder/DA42TwinStar/Panel/tn/ DA42panel_high.jpg.html That's a beautiful airplane, and an amazingly clean panel. I want one. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On 26 Dec 2004, at 00:37, Curtis L. Olson wrote: What did I say that was incorrect? If I've missunderstood something about plib/ssg I'd appreciate being corrected. If modeling is still done in blender/ac/multigen/whatever, then you need a conversion path to plib. That means going through one of the existing loaders no matter how you approach it. Using .ssg doesn't gain you anything in terms of rendering quality or features since you have to pass through a higher level format anyway. The only thing .ssg gives you is potential model load performance increases, although I've never seen any comparison benchmarks ... If you do get a performance increase, then perhaps we could have some util that converts to other formats to .ssg on the fly ... so you pay a price when you first load a new model, but after that, for each subsequent run of the application, you can load the .ssg format. We just need to handle this in a way the doesn't send us down a one way .ssg street. What it means is that the MAX / Blender exporters for .ssg need to be linked against PLIB, but so what? That's not difficult (that I can see). And the core issue is that it's easier to do the selective mapping of modeller features (nurbs, meshes, materials, animations, whatever) to renderer features inside that modeller's exporter API, which invariably makes all the data available in sensible, documented ways. The exporter becomes code that builds a PLIB scene graph by traversing the modeller's data, and then saves that graph. One catch is that the Blender exporter would have to be a compiled plugin, not a Python script (unless Norman is sitting on a Python-wrapper for PLIB :-), but that will still be less coding, and more maintainable, than trying to deal with the entirety of a Blender file (or other high-level format) inside a PLIB loader. Which, as you pointed out, is *exactly* why many of the PLIB loaders have limitations. Again, this is exactly analogous to the 2d art pipeline - people edit in a rich format like Gimp / Photoshop, but no one would suggest trying to load those formats directly in a game (layers, paths and all); you keep your original files around some place, and export / Save As to whatever simple format suits your needs, whether it be PNG or RGB or JPEG. Anyway, I'll go back to lurking now. James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] are we switching from blender to ac3d?
On 25 Dec 2004, at 14:43, Chris Metzler wrote: A plib loader for .blend would, IMHO, be an incredible boon for FG. As noted, ac3d file format can't include specular/diffuse shading info. Blender/.blend files also give you the ability to texture an object's faces in a fashion other than UV mapping -- by assigning (named) materials to faces, and then assigning different textures to the different materials. ac3d files can't do this. There's a lot of other .blend functionality that ac3d can't do (e.g. procedural textures), but these two are the ones that have bitten me so far. This is absolutely the wrong approach; the .blend file (like the .3ds format) is a very, rich, complex format that evolves with Blender releases. Just like 3DS, it is a dreadful format to import / export, and no-one should try. The correct approach is to pick a format that makes sense for FlightGear (whatever that may be), and write / find / improve a Blender exporter script (which are written in Python) for that format. The exporter API evolves slowly across Blender releases and is stable for precisely this reason. BTW, this is why 3DS do not document their file format, but do provide a very good exporter API. All commerical games invariably use an efficent, renderer specific format for their meshes; early in the development cycle they write a 3DS exporter (or Maya, etc) and give it to the artists, and that it the tool-chain. For plib, that format would probably be some kind of serialised representation of the scene-graph, but I'm not a PLIB expert. BTW, I have been through this cycle with WorldForge clients; currently one client loads 3DS files, but we are hurriedly switching to 'export' formats (as opposed to editable ones) becuase the 3DS loaders are enormous and complex. Trying to load 3DS / .blend / .lwo (and, I would contend, .ac3d) is analagous to saying FG should load it's textures as XCFs / .psps / PaintShopPro files - it's possible, but why on earth would you go to so much effort? HH James ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: FlightGear on Mac OS X
On 14 Nov 2004, at 13:42, Arthur Wiebe wrote:
What needs to be done is something like this
if (defined(macintosh) {
#include OpenGL/gl.h
}
else {
#include GL/gl.h
}
Can you tell that I don't program in C? :)
Two things - please use __APPLE__ to detect OS-X, 'macintosh' is more
for Classic era stuff (though still works, of course)
Secondly, Flightgear in most places has #defines for gl.h and glu.h,
which are setup by configure. The files you have encountered are the
ones that have been added since I sent Curt the changes (probably two
years ago) for the FG_GL stuff, I think.
My current inclination (which I've done in other projects) is to make a
'fg_gl.h' which simply includes the #ifdef test you have above, and use
that everywhere instead of the system GL headers. This needs to be done
for glu, glut and gtlext.h as well, of course.
The reason I haven't done that yet is, SDL already has a header that
does this (SDL/SDL_gl.h), any scene graph FG switches to will also do
this, and PLIB probably ought to be doing it, I'm just too busy to
fight to get patches into plib. Doing it locally in FG will work, of
course, but is slightly redundant.
BTW, I have local changes to built with XCode, run as a bundle, with
PLIB and SimGear as private frameworks, I'm just having some SDL
startup issues I haven't had time to look at.
HH
James
--
Morbo finds all humans pathetic
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FG MAC OS 10.3 binary for 0.9.6 scenery?
On 28 Oct 2004, at 11:57, Geoff McLane wrote: Can anyone help with such a beast? Have tried the 0.9.3 (from Wally's World) and 0.9.4 binary (FlightGear-0.9.4.tgz) with the current 0.9.6 scenery base, thank you for these, but no go ... even when the 'version' file is altered to match! I had this problem, I was able to work around it eventually but I forget how - sorry. Says missing Navaids/default.nav, (and thus also .nav.gz) for a start ... It seems there is a default.something in several folders, but the data/Navaids folder of 0.9.6 contains awy.dat.gz, fix.dat.gz and nav.dat.gz, among other things ... Yes, that sounds about right. (a) can anyone make a recent MAC OS (10.3 bash) binary available? or (b) is there an archive where the old scenery base 0.9.3 or 4 is/are available for download? I've done bits of work in this direction in the past, and since Jonathan Polley is busy these days (he's the guy who did the previous Mac binaries) I guess I should step up to the plate. I'll take a look tonight / over the weekend, but don't hold your breath. HH James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] ATC Network Test
On 4 Oct 2004, at 19:17, John Wojnaroski wrote: A few details... Volunteers will get a package of software that contains the TNL libraries and a basic set of software to connect to the ATC net as a controller or pilot. Package will include ALL source code and make files for a Linux system. Sorry, I'm just not an MS type. However, it will build under Cygwin. I'm happy to test, and probably even get the code building on OS-X, since it should be very close to working already. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Linuxtag
On 18 Jun 2004, at 13:09, Mathias Fröhlich wrote: Next week is the Linuxtag in Karlsruhe, Germany. http://www.linuxtag.org/ Is Flightgear present this year? Or will somebody be there for an other project? I'm exhibiting at the WorldForge booth, where we are also going to have a few Blender guys. Games in general seem fewer this year, last time I attended LinuxTag (2001) Alex Perry and Durk were there exhibiting Flightgear and doing demos that everyone loved. Of course, I'm not sure anyone will be able to beat Jon Stockhill and co's amazing efforts at LUDEX back in April this year. Anyway, if you're at LinuxTag, stop by the WorldForge booth and say hi. I have flightgear on the demo machine, but it's got a job to do demoing our client software! HH James -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OpenAL - http://www.openal.org
On 22 Apr 2004, at 09:24, Erik Hofman wrote: Go with SDL's sound support. SDL itself supports OpenAL giving best of both worlds. This is not quite right, I think; like OpenGL, SDL can use OpenAL, but it doesn't wrap the OpenAL API. In general, I think OpenAL would be a big improvement, not least because it uses CoreAudio (modern) vs the Sound manager (old) on OS-X; I've looked into updating PLIB's snd code, but it's not a fun task. And besides, the doppler effects and such would be cool. Another more noticeable one for me is hearing the engine sound change as I pan around the aircraft in an external view... HH James PS - Congrats to Jon Stockhill and co on a truly excellent demo of Flightgear at this year's Linux User Developer Expo, which I just got back from. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] SGPropertyListener (was Re: [Flightgear-flightmodel] crash reporting)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 19 Dec 2003, at 19:03, Andy Ross wrote: You would need to hook up the reset code as a command, so that Nasal and other bindings could see it. But it should work. One thing that isn't implemented yet is a SGPropertyListener interface that can be used from Nasal; you would have to poll the property value just like the external script would. Just so you know, I think the *only* code in FG which uses the listener is the patch I submitted to the property browser to make it 'live'. The problem, which was discussed at the time, was that certain properties (eg, 'bound' ones, I think) don't fire listeners correctly. David Megginson and I proposed a few schemes, which would allow keeping both the existing binding interface, but also the existing listener interface : they basically revolve around listeners which poll their SGProperty once per tick : so there is still polling, but it's centralized. Ideally, many more things would use the listener interface, and thus any polling of properties would be removed from all the other code, and only done if required by the property listeners themselves. However, I think that large number of properties (all the JSBSim ones?) are of the 'bound' type, so quite a bit of polling would still occur (iff there's a listener on the property). HH James - -- They are laughing with me, not at me. -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (Darwin) iD8DBQE/45nb7QfkxSkK4DcRAs3nAJwOUmy6N/3rEqY58wpvNCIaOwykcwCgiy63 y7vMlbOFB9/FMVO9E1TByj8= =aOwZ -END PGP SIGNATURE- ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 25 Nov 2003, at 23:56, Jon Stockill wrote: On Tue, 25 Nov 2003, David Luff wrote: Eliminated the bloody annoying flickering. I was going to ask if you could do anything about this - not good on the eyes - particularly when zoomed in, and a large percentage of the screen is flashing. In case anyone cares, TaxiDraw works for me using the CVS version of WxMac, on Panther (10.3) - I've had to hack a few things about, will clean them up and submit patches at some point. Thing is, I was only doing this to add Taxiways for EGPH (Edinburgh) and ... and ... it's already got them! So I'll have to find something else to do :-) One thing I'd really like is the ability to place some generic, rectangular buildings objects down, on the airports. Obviously this outputs to a totally different place to the runways.dat file so is there any chance of eventually rolling TaxiDraw into FGSD? (I assume the hard / complex work is the canvas and positioning code, so moving from wx to FLTK would be tedious but not especially difficult) The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 26 Nov 2003, at 10:53, Frederic BOUVIER wrote: The reason I mention is, I was about to add a couple of GUI features to taxidraw (like a list box to select airports by name instead of ICAO code), but I don't really want to invest brain-space learning WxWindows if I can avoid it. Not that I'm a fan of FLTK either ... Any ideas how this might develop in the future? This is something I would like to do, as time permit, or someone else do. It shouldn't be very difficult to draw OpenGL rectangles over the existing framework. It would benefit of having map or chart as an underlying overlay and placement aid. Right, being able to include an aerial photo as Jon suggested, or a plan (as is available from the CAA, for major Uk airports), would obviously greatly ease taxi-way creation. I might see if i can get FGSD running on OS-X too, and then see how much work would be involved in moving some functionality around. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TaxiDraw-0.0.5 available.
On 26 Nov 2003, at 11:44, David Luff wrote: I've almost finished getting a 5 arc-second orange grid overlay working, which is the same as used on the CAA aerodrome charts available online (UK aip). I was also going to add functionality to call wget to get the Terrasever US aerial photos and use them as background - Terraserver terms of use specifically allows any use whatsoever of the images. I agree though that fgsd is ultimately the way forward in this area. Sounds great on all counts :-) snip apps I'm also working on. Once FLTK 2.0 is released I'll have a good play with fgsd, in the meantime I'll try and code the functionality as generically as possible to make it easier for others to port if they want to. The only upside I can think of for the wxWindows version over an fgsd addition is that it doesn't need hardware openGL support to run smoothly, but realistically even most laptops should handle that these days. Yeah, personally I think we should be doing all our tools as plain GL / PUI with extensions, though using a real toolkit has advantages too, and it's pointless to waste time bickering about toolkits rather than actually getting useful tools written. So, I'll shutup :-) How can you not be a fan of wxWindows? - the chap who started it lives in Edinburgh, and it uses 'colour' instead of 'color' ;-) Because of the hideous macros for the event maps, for one thing. It's like a throwback to MFC. But, as I said, no futile toolkit bickering :-) And remember chaps, pressing 'w' will completely and silently overwrite your ICAO.dat file, so keep it backed up somewhere other than the working copy!!! (Putting the .dat file handling into the file open/save dialog should be easy - I'll have a look) This would resolve some of the Mac issues : the Mac version is running as a bundle, so it's CWD is '/' - my hacks are mainly changing paths so it can find runways.dat Being able to use the gzipped version would be nice, if the code isn't excessive. Maybe a simgear dependancy is they way to go, since at least some of the parsing code must already be duplicated HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] SimGear/matlib.cxx: problem with gcc-3.3 and PowerPC
On 10 Nov 2003, at 13:38, Olivier ABILLON wrote: On a PowerPC platform (iMac) the gnu compiler gcc-3.3 (from Xcode) creates a bad object file when optimisation are turned on. This causes FlightGear to crash at startup. There is no problem when optimisations are off (-O0) for this file. I didn't found such a problem on another file. That explains a lot . can we do a #pragma optimization level 0 in the file, or is it only CodeWarrior that supports such options? HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FG and Mac OS X - standalone app (bundle, ...)
On Monday, November 3, 2003, at 04:57 PM, Olivier ABILLON wrote: Here are a few comments about making a standalone application for Mac OS X: I do not think that putting all data stuff (scenery, ...) in the application bundle is a good idea: users will no be able to edit preferences files, aircraft files, and so on, without a special menu function in FG or with the terminal. On my Mac, I put the data folder in the same folder where FG application is. I just add an APPLE case in the funtion bool fgInitFGRoot ( int argc, char **argv ) in the fg_int.cxx file: I think the correct solution is to allow the base files to be packaged inside the bundle, but search the application support locations and preference support locations. That's pretty easy using FSFindFolder and the various domain and folder flags. However, many places in Flighgear currently only support a single location, rather than a list of paths to search, so this can't be done right now. it's simpler than using Apple's functions... I don't think that's a big problem, the Apple functions are pretty verbose, but I'm happy to stick them in a separate source file, and they're a bit more robust than mangling the paths by hand. There is another problem: the Finder adds an argument in the argument list argv: -psn:xxx. It must be removed. The Apple version of GLUT removes this funky argument; so a call to GlutInit must be done before parsing options. Another method is to trap this argument in the fgParseArgs function (file options.cxx): snip Isn't it safer to move glutInit? We don't know what behaviours glutInit is relying on, so passing it the raw command line seems more likely to work if things change in the future. I also added the following code at the beginning of the fgMainInit function in the file main.cxx: #if defined( __APPLE__ ) freopen (/Users/'your_login'/stdout.txt, w, stdout ); freopen (/Users/'your_login'/stderr.txt, w, stderr ); #endif this way I can see what happens without using the console or the terminal (very useful for debugging) I noted that from version 0.9, FlightGear is slower (about 5 fps)(I have a 500 MHz G3 iMac, with an ATI rage pro graphic card - 16 Mo only). Disabling the drawing of objects does not speed the rendering. Reducing the size of the textures can enhance greatly the fps: up to 15 to 20. I haven't got FG running on my powerbook yet, but i'm hoping that with a 64mb radeon 9600, it will be usable (it wasn't, on my ibook). Still waiting on panther, alas. HH James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OSX 10.3 (Panther) Build
On Tuesday, October 28, 2003, at 04:57 AM, Jonathan Polley wrote: Oops, I sent this to the Users list instead. For those of us who use Macs, I just installed Panther on my machine. Just the OS upgrade increased my frame rate by about 15%. I am currently working through some compiler issues with Xcode and will let you know how well the new compiler works. I assume you're using your own project files? I've locally set up project files for PLIB, SimGear and FlightGear, and it all compiles, but it's dieing even earlier than you are, in glut initialization. Oh, and I'm still on Jaguar : I will rebuild once my copy of Jaguar turns up. I'm also still waiting to get my framework changes into PLIB ... HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Patch : support bundled operation on OS-X
Here's a patch to locate the base package inside the application bundle on OS-X. The patch also disables the CPSForeground hack in boostrap.cxx, which is unnecessary if the we're running as a proper bundle rather than a Unix command line program. Both of these changes are only compiled if OSX_BUNDLE is defined (I'm doing this via a setting in ProjectBuilder), so if you're building on OS-X using configure + make, you shouldn't see any chance. I'll submit the actual project files once we resolve the OpenGL includes issues I mentioned in my previous email. HH James fg-osx-bundle.patch Description: Binary data -- That which does not kill me has poor aim___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OS-X binaries for 0.9.3-pre1
On Thursday, October 16, 2003, at 05:18 am, Curtis L. Olson wrote: Gene B. pointed me to a free windows setup.exe creator so I'm thinking we ought to bundle the windows version up with that (or something similar) for upcoming releases. I know Darrel Wassiler (who's probably lurking here somewhere) has already done similar work, but for my own amusement, I've been working on getting SimGear and FlightGear compiled as a framework (in the case of SimGear) and a bundle (in the case of FlightGear). This translates as 'relocatable, double-clickable end-user-application' for those who don't know OS-X packaging formats. It's not working yet (still fixing link errors), and I have a few patches to submit, but I'll keep playing over the weekend, so providing shrink-wrapped OS-X binaries for this release ought to be no problem. Darrel / Other OS-X people : I was thinking of doing something clever with the FG_ROOT detection, especially now FG supports multiple scenery directories, such as searching $HOME/Library/Application Support/FlightGear/ As a sidenote to all FG developers, it would be great if any part of the base package that normal users might want to expand can handle multiple paths : then I can locate the main base package, which is essentially static for a given release, inside the the application bundle (i.e invisible to the end user), and they can drop new aircraft / scenery / other extendable resource into a 'plugin' directory location as described above. But of course, that can wait till post 0.9.3 (and a minor beef-up of the path / directory functions in SG, I suspect) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OS-X binaries for 0.9.3-pre1
On Thursday, October 16, 2003, at 09:55 am, Erik Hofman wrote: As a sidenote to all FG developers, it would be great if any part of the base package that normal users might want to expand can handle multiple paths : then I can locate the main base package, which is essentially static for a given release, inside the the application bundle (i.e invisible to the end user), and they can drop new aircraft / scenery / other extendable resource into a 'plugin' directory location as described above. This sounds like an excellent idea! Heh, I'll take a look once I have a working binary, then. Packaging is a pet-peeve of mine, because installing and un-installing add-ons for MSFS and Fly! was such a chore. This is related to my desire of packaging each add-on as a zip / tarball, but that's going to have to wait until the PLIB model loaders are fixed not to access the filesystem directly. Anyway, just being able to search a list of places for Scenery and Aircraft will be a start, I have no idea which other pieces of the base package end-users might modify (nav-data maybe? but even then, probably not, if releases are every 6 months ... and most people don't care about having the most accurate AIRAC cycles) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] OS-X binaries / OpenGL includes
First the good news : I have a 'shrink-wrapped', double-clickable FlightGear CVS-as-of-today binary working on the Mac. The bad news - boy is it slow! and big (which may be why it's slow, killing the CPU caches) I need to check what debug info and optimizations are being used, because simgear is coming in at 14mb compiled, and FG at 64mb! (that's including statically linked PLIB, but even still). On my 700Mhz, Radeon 7500 Mobility equipped iBook, i'm getting 2-3 FPS in the cessna's cockpit, and 4-5 in outside views, or 7-8 if I look away from the model. If i look directly down at the ground (from the tower view, i.e to remove fill-rate / polygon-rate limits as much as possible), I can just about get 19fps However, I'm getting a new laptop in a couple of days, will see how that improves things! Anyway, before I can start submitting patches, I need to agree a solution which, alas, affects everyone, thought it's entirely of Apple's making: the OS-X openGL headers are in 'different' places from every other OS. Essentially, on the mac, we need to do: #include OpenGL/gl.h instead of #include GL/gl.h For a myriad of reasons, this cannot be symlinked or worked around - the code needs to use a different file on OS-X. The prior solution which I did (and Curt agreed to, I think), was to make the header file name a #define, define it in config.h via autoconf, But this sucks, because it's easy to end up with the value not defined, which leads to a really odd error. Here's what I'm talking about: (in config.h or on the command line via -D:) #define FG_GLUT_H GLUT/glut.h (in the file using glut) #include FG_GLUT_H So, my proposed new solution, is to add 3 files to simgear (at the root, beside sg_inlines and so on): sg_gl.h sg_glu.h sg_glut.h These will all look like: #ifdef (__APPLE__) #include OpenGL/gl.h #else #include GL/gl.h #endif Then I will go through, and convert every reference to the open GL headers over to use these new headers. How does this sound? Acceptable? Hideous? HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] gear door sequencing
On Thursday, September 25, 2003, at 01:20 pm, Erik Hofman wrote: Speed brakes are on the top of the wing ( the extrados ? ) and can be used flying, On civilian aircraft and gliders this is usually the case. Military types can have them in different places - such as the F16 (on top of the fuselage?), the Buccaneer (opening tail cone) etc. F-15 : top of the fuselage. F-16 : horizontally along the fuselage, between the horizontal tail and turbine compartment, at the end of the strakes. One thing I've never been clear on - is there a distinction between 'things you deploy in the air' and 'thing you deploy on touchdown'? I know the things I call spoilers on the wings of big jets can be extended in flight to slow the aircraft, as well as auto-deploying (more?) on touchdown to kill lift + decelerate. But, I can't imagine deploying the split tail brake of the Fokker 100 while in the air is this actually ok, or is there some definite separation of usage? On a related point, do any of the FDMs / FlightGear model an increase in buffet / vibration / noise when deploying spoilers (or indeed, lots of flap) at high speed? For thrust reversers, as well as a sleeve, you also get two (or more?) segments of the exhaust pipe that pivot at their rear end, to redirect the thrust. I think the fokker has this type of reverser. Playing with google image search turned up the following: (2nd is especially nice) http://www.thrustair.com/dc9_thrust_reverser.jpg www.robl.w1.com/Pix-4/ C970493.jpg Anyway, the sooner FG / the FDMs / the planes support more of these devices, the happier I'll be - because I habitually fly my approaches too fast, and auto-spoilers really help stick the plane to the ground :-) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Wireeframe and Flat Shaded Display
On Thursday, September 25, 2003, at 11:25 am, Norman Vine wrote: Wireframe mode works, it's the turning the textures on and off that no longer works. Maybe we should remap F9 to switch wireframe on and off? We really need either 1) a key for wire-frame or 2) figure out how to get PLIB to switch back to shaded after switching to wire-frame as the prop browser is useless in wire-frame mode I was just looking at main.cxx (in mounting fear...) and it looks pretty simple to cancel and restore the wire-frame state around puDisplay(), which I **presume** is what does the PUI drawing. There are probably a bunch of other things that might want to be excluded from wireframe mode, I guess. Around about line 748 of main.cxx, btw As to *why* I as looking at main.cxx - I'm trying to get an idea how complex a conversion to SDL would be - what other people are working in this area? I've got quite a bit of experience with SDL itself, but main.cxx is frightening me. HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] San Francisco city lake
On Monday, September 8, 2003, at 04:07 pm, Alex Perry wrote: I suspect that, since the vmap data was collected, the dips were drained and thereby turned into the parkland that you see in the photo. The problem is, that 'lake' is the Golden Gate Park. Having it be anything other than green parkland would be as wrong as having Central Park show up as water or sand in NY city! Note I'm not arguing that the park isn't low enough (or sandy enough) at the western end to have been tidal flats in the past, but it's been a park for a long time, and the land rises up (and gets less sandy) less than a quarter of the way east. The impression I have is that no matter what texture is picked for 'default' landcover, it's going to be massively, obviously wrong much of the time. James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: [Flightgear-cvslogs] CVS: data/Aircraft/fokker50/Models
On Friday, September 5, 2003, at 03:12 pm, Martin Spott wrote: 3.) I know, you should not employ the flaps at 200 kts But if you do so, the aircraft climbs like attached to a high speed elevator :-) I've been flying the Fokker 100 quite a bit, and I've noticed similar instabilities. Roughly (I am not a pilot) - very rapid control response, especially on the roll axis). This sometimes extends to a 'snap' condition where I command an aileron reversal (okay, I just pull my joystick to the other side), and there is a very prolonged period with no response (for example, 8 or 10 seconds, usually continuing the previous roll command) until the roll suddenly flips over. - a similar elevator effect to that martin described, when deploying the flaps at high speeds - very odd high pitch angle behavior ... I can't really describe it, alas. It seems like way too much lift is getting developed at high angles of attack, without a corresponding increase in drag to slow the aircraft. Essentially, the aircraft flies pretty well (if a bit twitchy) providing you stick to a 'good' flight regime, but handling deteriorates exponentially when I go even moderately beyond it. I'm aware that part of this may be running 'past the end of the data' in JSBsim, but other models do not seem to have these problems. Can this be alleviated by tuning the last data point for various coefficients, which I assume is what JSBsim extrapolates from? (I was about to say the 747 is much more forgiving of my 80-degree banks, but of course, it uses YASim). Anyway, aside from the nit-picking, it's a lovely plane, at least until we get an ERJ ;-) James -- There is a very fine line between 'hobby' and 'mental illness' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Packaging data files
I did a bit of background research on the packaging / bundling issue, partly for my own curiosity, and in the vague hope of helping someone who wants to take a crack at this.. Essentially, anyone who's installed add-ons for MSFS (any version) knows what a pain it is, and uninstalling them is next to impossible. As people here have noted, the sane thing is to support (optionally!) reading files from a package. This is done by Fly! (.pod files), Doom, Quake, Mozilla, Crystal Space and indeed, Java. The preceding list of software was not selected at random :-) The last four all use .zip files (but renamed to pk3 in the case of Quake 3, and .jar in the case of Mozilla and Java) as the packaging format. Using a well known format makes many thing easier, as anyone who's found the limitations of Fly!'s POD editor will agree. Now, I wondered why no one has used tar.gz, rather than .zip so I went and read the file format specs for .tar, and for .zip. Essentially, the tar format was designed around a write-once, stream orientated device (well, yeah, it's a Tape ARchvie). One of the things it's therefore lacking is a Table-of-Contents structure listing the archive contents. This makes accessing arbitrary individual files from the archives a bit of a pain; you either do a linear search each time, or build a TOC in memory (with offsets into the archive) at startup. This has issues of it's own, like further slowing down startup time :-) So, it seems like ZIP might actually be the way to go ... extracting a single (say) 2k texture from a 300MB archive is doable without reading the entire archive. The next issue is stealing some code Mozilla has a libjar, which is rather large (it also handles the 'MANIFEST' files which are part of the Java JAR spec, and which provide lots of useful meta-data about the file contents, like the classes it contains ... we could use meta-data, certainly, but I think it's be easier to define a trivial XML syntax than use the JAR one). However, CrystalSpace contains a single file, C++ implementation of a .ZIP reader, with a sane API. It's at: crystal/CS/libs/csutil/archive.cpp Obviously it would need a little adaption for FG, but it's pretty simple code (it even has comments), so if anyone is considering doing this, I'd strongly recommend it, rather than someone here having to grovel in the ZIP format manually, or to create a dependancy on some heavy-weight library. Anyway, hope this is of some use. James -- There is no such thing as a humble opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Packaging data files
On Monday, August 25, 2003, at 11:57 am, Erik Hofman wrote: As a unix user the first thing that comes to my mind is off course tar and gzip (or maybe bzip2). I am aware of the limitations of the tar format, but the scan once for a TOC method seemed fast enough for me. For very large archives, I contend this is not the case, and FG's startup performance is already, uh, poor. Pulling a 100Mb or 200Mb archive off the disk and through memory is going to hit any machine hard. Regarding ZIP files, is it legal to use the compression algorithm without any limitations at the moment (for example GIF has a similar issue). ZIP can use a range of compression schemes (including BZIP2!), and only one of them (compress) is covered by the LZW patent, which in any case expired in the US at the end of June. (and in europe / japan early next year) I suspect that encoders deliberately avoid this scheme, or don't support it, to avoid the issue. Notably, the CrystalSpace code only appears to support the common deflate / implode methods, but since I personally have used various 'random' ZIPs with crystal space, I assume these are the widely used methods. Presumably, this also means the code could be extended to support the BZip2 format, by linking with libbzip2 (which is widely deployed on Linux, at least), and we'd get much smaller zip archives. I've no idea what spectrum of Zip readers, eg Nautilus, Konqueror, or WinZip or WinXP's builtin ZIP-as-a-folder mode, support that encoding. HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Packaging data files
On Monday, August 25, 2003, at 02:44 pm, Erik Hofman wrote: Not necessary, it is mainly the number of files that causes the slowdown. You can jump from one info block to another without actually reading any date in between them (there is a pointer in the current info block that points to the next). SO it's not that bad. That's true. I don't suppose you'd like to code up an SGArchive class that does this, then? Obviously it won't be much use until PLIB is modified to support virtualizing disk operations, but i'd be curious to see how a 'base.tar.gz' performed at startup compared to the unpacked files... Alas, I wasn't able to find any open-source projects that have already written a single-source-file, decode only tar impl ... which is annoying. Oh, I just did some browsing of the SSG loaders they're full of fopen / fseek calls. Damn. Much work to be done there, I think. James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Glut
On Wednesday, August 13, 2003, at 09:56 am, Erik Hofman wrote: Oh, I almost forgot. It's actively developed. Nobody seems interested in anything but ssg in the plib list (and still). For me this is the absolute crux of the argument; SDL has been and is used to develop commercial quality game releases, on Linux, FreeBSD and windows (and probably other platforms I don't know about). While there's nothing in GLUT that explicitly stops you from using it in large projects, having used both, I say positively that SDL is by far the more polished and elegant tool. A classic example being video-mode switching, which SDL implements well (and with a sane API and fallbacks) on all it's platforms. The existing full-screen mode has never worked for me, ever. And while we can move code / implement features in PLIB, we're making work for ourselves. Eg, I ported the SDL OS-X joystick driver to PLIB. It works, but it's still not very good, because the PLIB js API is a bit limited in terms of the objects it describes. And PLIB's sound code certainly seems to be the source of many problems around here. If the only issue is cygwin support, why not just switch to mingw? Is there any actual advantage to having win32 binaries that rely on Cygwin? Obviously the code is pretty close to building under mingw, given that Fred has been doing MSVC builds All my opinion, naturally James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] request for comments?
On Tuesday, August 5, 2003, at 05:23 pm, Curtis L. Olson wrote: At the risk of tainting the discussion I will say that from my investigation, Open Scene Graph seems to be the better choice. There are people here locally that use it, and I know that other flightgear developers have used it as well. It seems to support all the platforms that we currently support. No one I've talked to seems to know much about OpenSG and the one web link I found (http://sgi.felk.cvut.cz/~pavlicm/Dipl/sw.htm) seems to put Open Scene Graph ahead in terms of performance (based on a single test which doesn't say too much actually.) OpenSceneGraph looks much better than I remember, but it's also worth looking at OGRE, which is being (very) actively developed. http://ogre.sf.net/ Is the place to start. Note that OGRE is a bit more 'gamey' than the other systems mentioned, notably it supports DirectX in addition to OpenGL. I'm not really sure if being more game-orientated would be considered a bonus or not for FlightGear. Also, I'm far more concerned about getting rid of PLIB / GLUT for our OS interaction, than the graphical shortcomings of SSG. There are a couple of obvious replacements: SDL, SDL, or just possibly, SDL. :-) This would remove various limitations on joysticks (SDL supports hats), number of sound channels (SDL has a mixer), video mode-switching (SDL knows how to make X do that, quite apart from on Win32 or OS-X) Perhaps most importantly, SDL gives the application back it's event loop. Oh, and the the OpenSceneGraph FAQ lists SDL as a candidate rendering layer, for people who're finding GLUT a pain. Of course switching both the scene graph and the OS-abstraction at the same time would be silly : one could either switch to SDL, and initially retain SSG, or alternatively, try and get OpenSceneGraph working alongside the rest of PLIB. Not sure which makes more sense. All my opinion, naturally. James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] 747 Panel Feedback
A few comments, after playing with the 747 panel a bit more. Firstly, I'd just like to say how amazing it is, given the non-impact on the frame-rates, smoothness and clarity of the text, and so on. It's just lovely. Now, on with the nit-picking. Note many things I'm going to suggest probably require some level of C++ coding (even if it's just exposing more properties), and given sufficient arm-twisting I might even look at them myself. I've looked over the panel files, but I find the relation between the 3d models and the panel a bit hard to grasp... Also note my 'experience' is based on the PMDG 777 for Fly!, but I assume Boeing glass cockpits don't vary much. - The PFD auto-pilot annunciation is lacking supported for armed modes (in white, rather than green text). Eg, when in heading mode, and engaging a NAV mode to intercept a VOR radial, NAV should be displayed in white above (below?) the still-green HDG until the radial is intersected. And the more common case, in V/S mode, heading towards a commanded ALT, ALT should be displayed in white. The whole reason I'm writing this is because I subconsciously found it very disturbing to enter a target altitude and not see ALT there in white (I've obviously spent way too much time with the PMDG 777 in Fly!). - The speed trend indicator bar is missing; obviously this requires code and probably FMS interaction to be accurate, though I suspect a first order approximation [trend-velocity = velocity + (current_acceleration * 5.0)] would be enough. Again, it wasn't till I sat and thought about this I realized it was missing, but it made my flying much worse (on a manual throttle) And now a couple of 'please's - I really need a visual indicator of flap position, either the lever itself or the EFIS page showing the flap 'bar'. And related to that, is the 747 missing some detents? I'd expect 1,2,5,10,15,25 (and maybe 40?). It seems like there's only three detents at the moment, and I keep ballooning on approach picking the wrong one. [anyone who points out a good visual indicator of flap position would be switching to the external view gets a sullen look from me] Oh and, if we're being clever, updating the safe Vmax marker on the speed-tape based on the current flap setting would be wonderful (yes, I'm a lazy person who uses that to schedule flap retraction on climb-out). But of course, this requires code and aircraft-dependent data (though maximum rated speed for each flap setting is usually given in pilot manuals) When we finally get an FMS, it will of course compute notches on the speed tape for flap retraction, given the gross weight of the aircraft and so on but that's *a lot* of C++ coding. - I *really*, *really* need the ADF indicator on the NAV display. Especially intersecting an ILS localizer, I keep over-shooting because the 747 turns so slowly, when normally I'd use a handy ADF to work out when I'm almost on the glideslope and hence start turning in. Anyway, that's more than enough nit-picking. I'll go back to lurking and bouncing the 747 down runways.. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] 747 Panel Feedback
Are you talking about the xml files for 3d animation? The objects refered to in the xml are specific polys on the display. For example the apalt1 on the PDF might refer to the first digit on the AP Altitude setting display, apalt2 the second digit. For the most part they are numbered right to left, where 1 is the rightmost digit. Ah, I didn't realize you could 'address' individual polygons this way... This is the way it should work. But I don't have the ARM displays in there yet. BTW when waiting for NAV intercept is it just HDG (and not HDG SEL) annunciated? IIRC selecting NAV in the autopilot currently sets the aircraft on a course 60 degrees off the radial. When it hits the radial it switches to a heading that follows the radial. There is some voodoo I put in there a long time ago to make sure the 747 didn't overfly the radial. Any suggestions on how this mode should actually work? Also, at what point (degrees from radial?) is the radial considered intercepted? HDG SEL is right, I think. here's how I remember it working in the PMDG 777: assume no LNAV mode is active, or HDG SEL is; providing you have a valid NAV 1 signal, and the line projected from the current position of the airplane along the heading at some point intersects the radial, I think NAV mode will arm. Certainly it always has when I've tried. It obviously can't be a pure angle cutoff, because you might be flying very close to the radial, but almost parallel to it, and NAV should still arm. Anyway, the NAV mode stays armed until you get 'close' to the radial, at which point it activates and executes the turn to bring the aircraft onto the radial's heading. I'm not sure how 'close' is quantified, but in the PMDG 777, it never over-shot, so it must be a bit cleverer than a fixed distance. Actually the autothrottle is now outputing a trend value. I'm just not sure exactly how the graphics should look. It's a green purple line on the speed tape, with an arrow at it's top / bottom indicating the speed in K seconds (I think K = 5, but it might 8 or 10). The other end of the vertical line is fixed at center of the speed tape. Visually, you use the height of the line to judge the plane's acceleration. I googled for 'boeing PFD' on images.google.com, and some of the pics include the speed trend line. Also, some of them also show the yellow right-hand speed-tape border than indicates warning speed regimes, and the red dots that indicate danger speeds. I'll be doing an EICAS display that will have that. Also there's a center console thing, not sure when the center console will get done. Are the number of flap setting and the detents correct, btw? - I *really*, *really* need the ADF indicator on the NAV display. Especially intersecting an ILS localizer, I keep over-shooting because the 747 turns so slowly, when normally I'd use a handy ADF to work out when I'm almost on the glideslope and hence start turning in. Again, I need more info. I'm not really sure what it should look like or how it should work. If you can help, I'll add the features. Ah, the ADF is pretty easy, it's just a green arrow on the NAV display, with the the head in the 'compass ring' pointing at the NDB, and the tail (which is forked) also in the track. I can't remember if there's a solid line between the head and tail or not. Hopefully, Dave Culp or someone else who's looked at these things for too long can fill in more gaps, or correct any mistakes I've made. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New Sutro tower in CVS
On Friday, June 20, 2003, at 09:19 pm, Frederic Bouvier wrote: The highest point of the bay area is in CVS : http://perso.wanadoo.fr/frbouvi/flightsim/fgfs-sutro-sf.png I appreciate this is a dangerous precedent to set, nominating requests, but : the buildings that *really* stand out are not the big skyscrapers, but the 'edge' buildings and bridges. Notably the Coit tower (though it's hill isn't very noticeable with our current DEM data), the Ferry Building at the end of market, and Candlestick park. On flying the actual approach, though, the most visible objects by a long, long way are the bridges. The approach I've always flow into SFO has been down over Marin / Napa, coming quite close to pacific coast, then turning inland (with the golden gate bridge visible to starboard), then turning south-east once almost central over the bay, (parallel to the 28L/R runways) flying over the oakland bridge (bay?) bridge and down as far as the dunbarton bridge. Once past this there's a long U-turn onto final, which brings you back over the dunbarton bridge at what feels like quite a low altitude (still 2000 feet, I suppose). So in general, you don't have a sense of individual buildings, but more the pattern of green and built-up areas, but lots of water (which we do pretty well) and the bridges. That said, if the auto-gen could use some hinting data to place rings of bigger buildings towards 'centre points' of cities, we'd get the sense of city 'mass' much better. (Oakland would probably need one centre-of-density to look about right, SFO would need a couple, as would London) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] New release
On Saturday, June 7, 2003, at 12:45 am, matthew Law wrote: Nice to see the 0.92 release made it on to flightsim.com quickly. Although it's dominated by FS2002, any publicity is good publicity as they say. Though this is a slippery slope, what about avsim.com? (Which I consider to be marginally higher quality, though they're both FS2002 heavy) HH James -- The real enemy is the gramophone mind, whether or not one agrees with the record that is being played at the moment. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] setting fuel load
On Thursday, May 29, 2003, at 01:05 pm, Erik Hofman wrote: Jon Berndt wrote: The reset file sets the current *dynamic* state. I suppose we could (for JSBSim standalone) set actual fuel load in a script, but if that's not done right we might still end up with a user going: why don't my plane start? I see. There are some conflicting requirements here. Maybe JSBSim should use the pre-defined value as an initial value and provide a function call to override it by the user (program). This issue (JSB needing to set values that FG also wants to set) has come up before, and I'm unclear why we can't always do the following: 1. JSB sim reads config file (maybe sets fuel load, etc) 2. FG reads -set.xml file, and potentially over-writes some JSB sim values 3. Everyone is happy. Am is missing something here? Obviously bits of the -set.xml files may need to be loaded before the JSB (or yasim or UIUC) file is loaded, but in general I'd always expect to be able to over-ride any values they specify from the -set file. Is this what already happens, and the fuel thing is simply a bug, or is there some ordering constraint I'm unaware of? HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Corrupted p51d textures on windows
On Wednesday, May 28, 2003, at 07:08 am, Frederic Bouvier wrote:
I also had a hard time remembering how to start the engine. I finally
found
the
magneto switch on the panel and hopefully it has hotspot because keys
'('
and ')'
are not working on my system although they are present in my
keyboard.xml.
Is it
the same for you ?
Umm, this is embarrassing, but after hunting around for quite a few
minutes, I couldn't find the magneto switch ... where is it?
HH
James 'it must be on the overhead panel, beside the IRS ...' Turner
--
The real enemy is the gramophone mind, whether or not one agrees with
the record that is being played at the moment.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] fgLoadAircraft build failure
cvs up -dP as of 30 minutes ago, Making all in Aircraft make[2]: Entering directory `/home/jmt/FGFS/FlightGear/src/Aircraft' source='aircraft.cxx' object='aircraft.o' libtool=no \ depfile='.deps/aircraft.Po' tmpdepfile='.deps/aircraft.TPo' \ depmode=gcc3 /bin/sh ../../depcomp \ g++ -DHAVE_CONFIG_H -I. -I. -I../../src/Include -I../.. -I../../src -I/usr/X11R6/include -g -O2 -D_REENTRANT -c -o aircraft.o `test -f 'aircraft.cxx' || echo './'`aircraft.cxx aircraft.cxx: In function `bool fgLoadAircraft(const SGPropertyNode*)': aircraft.cxx:143: `bool fgLoadAircraft(const SGPropertyNode*)' was declared `extern' and later `static' aircraft.hxx:62: previous declaration of `bool fgLoadAircraft(const SGPropertyNode*)' make[2]: *** [aircraft.o] Error 1 OS is Suse 8.1, gcc version 3.2. I don't get why aircraft.cxx defines fgLoadAircraft as a static inline, since both of these seem wrong; it's a large function to inline (and not called frequently, I assume), and it's been declared in a public header file. HH James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] fgLoadAircraft build failure
On Saturday, March 29, 2003, at 05:57 pm, James Turner wrote: I don't get why aircraft.cxx defines fgLoadAircraft as a static inline, since both of these seem wrong; it's a large function to inline (and not called frequently, I assume), and it's been declared in a public header file. Silly me, forgot to add, removing the static inline keywords from aircraft.cxx means I can build fine, though switching doesn't seem to affect the aircraft model (and hence, the 3d panel). Anyway, I guess this is work in progress, so not too worried about that (waiting on a new graphics card so I can properly use FG again, the 3d panels pushed my geforce 1 over the edge...) HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] base package cvs update failing...
Doing 'cvs up' in fgfsbase. (flags are -dP) cvs server: Updating . cvs [server aborted]: cannot stat /tmp/cvslck: No such file or directory cvs [server aborted]: cannot stat /tmp/cvslck: No such file or directory Have I done something dumb (been away from my FG box for 2 weeks, it worked before then) and has failed every time from it since I got back (Friday). Also get and identical error when I do the update on my iBook. So if it's me, it's not the machines or the OS. Hope this isn't completely uninformative, I don't know much about the internals of CVS. HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT navids
On Friday, February 21, 2003, at 02:27 pm, David Megginson wrote: 1. For VORs, we're interested in the slaved magnetic variation; you can always ignore the actual one, since we calculate that inside FlightGear anyway. Already done 2. Entries for TACANs have only a channel, not a paired VHF frequency. By trial and error, I've figured out how to get the VHF (I think): snipped scary conversion Err, I'm not sure this is correct. the VORTACs have an explicit frequency as well as a channel, and a straight TACAN isn't receivable using a VHF NAV radio, is it? 3. Entries for civilian DMEs also have only a channel. You can use the same formula as you used for TACANs, but you have to add 0.05MHz to every one (I don't know why, but that is the pattern I found on the charts). I'm again not clear about this, I assumed these were 'DME only' military installations. 4. You have to split the NDB/DME entries into two to make them usable for FlightGear. The DME channel will be provided, so handle it as above to get a paired VHF frequency (tuning the NDB will never automatically tune a DME). I haven't done this, but right now I don't believe the radiostack logic works this way. I think it simply looks for the 'isDME' flags on FGnav. 5. Non-U.S. VORs don't have a range provided, but they do have the usage code -- you can kludge a range from that (I used 200 nm for 'H' or 'B', 20 nm for 'T', and 50 nm for anything else). I was going to do this, but various people indicated these values were bogus and we'd be better using the 'practical approximation' you and Norman discussed a few weeks back. I don't need any arm-twisting to dump Metakit -- these are tiny databases for modern computers (that 20-second porn video clip your roommate/son/neighbout just watched probably needed several times as much memory as all our nav/arpt data put together). Yes, please. I'd also be interested in ILS. Supporting new types is trivial. I would greatly prefer to switch the airport data over too, simply for consistency in the data set. Can anyone establish what (if anything we would lose by doing so?) HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Navaids and fixes from DAFIF
On Friday, February 21, 2003, at 02:12 pm, David Megginson wrote: We should also consider whether we want to compress the DAFIFT files. They take much more disk space uncompressed, but presumably CVS updates would be significantly faster, since they would exchange only deltas (or does the whole file come anyway?). I was assuming we wouldn't ship the DAFIFt files at all, but instead use wget / PLIB's http client to pull them down automatically. But in any case, I'm using Simgear's gzip_ifstream so just gziping the dafift text files will work fine too. -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] DAFIFT navids
On Friday, February 21, 2003, at 03:23 pm, Curtis L. Olson wrote: The DAFIFT doesn't have taxiway data. Beyond that, it would be interesting to compare the X-Plane data set vs. DAFIFT to see what airport X-Plane has that are not in DAFIFT. Much of the X-Plane data is hand entered, especially for areas outside the USA. I'm a bit confused by this : why can't we get the runway data from DAFIFT and the taxiway data from ... oh .. wait... it won't match up, will it? Nevermind, I'll leave the airport data for now! /me learns an important lesson about trying to be too clever. James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Boeing 747 cockpit
On Saturday, February 15, 2003, at 11:19 pm, Jim Wilson wrote: The two possible options that come to mind are as follows: 1) Use the current 3D Modeling system. 2) Take code from the opengc project and change it so that it gets data directly off our property system (property paths configurable). The idea then would be to load these using Andy's panelnode code that currently loads the 2D panel into 3D cockpits. I'm thinking that these could be special 2D panel types and there could be a separate panel class (inherited from a general) for each glass display. Any comments? My plan was to add a bunch of new panel element types, though at some stage we are going to need some big chunks of custom code. For example, for the KLN-89b, the screen is essentially a 4-line, 20? character display, so I was figuring on an ncurses-like markup of fields, pages and lists, all of fixed character positions and dimensions. This will work really well for the [M]CDUs of big jets too. But even the KLN-89b has the dreaded NAV4 mode, which provides a graphical map of the flightplan, waypoints, airspace boundaries an so on. I was mentally planning to cross that bridge when I got to it, but obviously it'd be nice to share code with other similar displays. Basically, I think the currently panel method (a tree of elements we place) is essentially right model (i.e declarative, not just procedural bits of openGL). We would need quite a few custom elements in this approach, and NAV (map) displays are a special problem, but I think the other stuff is pretty doable (tapes, number fields, artificial horizon) in a tuneable way. And would also map closely to a XML-ified HUD. Indecisively, James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Hmmmm
On Monday, February 17, 2003, at 04:21 pm, Jon Stockill wrote: http://www.linux.org.uk/diary/ if anyone has the ability to translate. According to my native welsh friend (who also hacks the kernel, so I assume the technology is correct to): 'Too many collisions, DRI collides too much when playing Flightgear, cars colliding in front of the house' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Updated set of goals?
On Monday, February 10, 2003, at 10:09 am, Erik Hofman wrote: Rendering - snip * Material edge blending This one, and some fractal subdivision of soft-edges, would give far and away the best visual improvement for the current data set, in my opinion. The issues get fairly complex though (this is what I tried to do for my final year project, and didn't get very far at all). What you'd 'like' to do: - use a generic coastline texture for sea boundaries (and a 'narrower' one for non-tidal inland water) - use shore gradient to pick a rocky texture, and, just maybe, VMap sand/mudflat land coverage to get decent tidal zones (of course then people will demand correct tides ... yukc) - blend the major 'massy' land use types together, based on their type. - fields / agricultural areas have sharp edges and mostly straight boundaries - snow / rock / moorland / pasture tends to have very rough edges - urban areas have rough transitions of empty but non-agricultural land and smaller 'chunk' sizes. - forrest have varying edges based on whether they're natural or managed! So this gets to be quite a major task very quickly, and your polygon count is soaring through the roof all the time. The attribute data in the VMap files can help, eg it differentiates between parkland (hard edges) and open grassland, natural vs managed forests, and so on. Making sensible guesses is still a huge undertaking and guaranteed to go badly wrong in some places. HH James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Question about METAR updates
On Sunday, February 9, 2003, at 01:25 am, Ima Sudonim wrote: Is it possible to use a metar file to give flightgear the current weather conditions for the world. Are there special setup or options required to set this up? Are there any mac os x compatible apps (java probably ok, too) to download metar info periodically (from http://weather.noaa.gov/weather/metar.shtml ) so that flightgear can (possibly) use it? I was actually looking at this (on a complete whim) the other day. It looks to be fairly easy, if you can assume the existence of wget / curl on the system. Otherwise, you need to write a bit of FTP functionality (probably a trivial amount, though). Also, I didn't look at the actual weather code inside FG but based on the command line switches I think gluing it in will be doable. That said, I've got quite enough on my plate with the flightplan / flightcomputer stuff to look at this (sorry). HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)
On Saturday, February 8, 2003, at 03:23 am, Jonathan Polley wrote: Hmm, that's odd. Out of the box, the version of the Mac joystick code that is in CVS does not compile. As I reported to the plib group, if I incorporate the non-CVS versions of jsMacOSX.cxx and js.h, I get the following errors in the FlightGear joystick code: ld: Undefined symbols: jsJoystick::read(int*, float*) _CFArrayApplyFunction snipped lots of CoreFoundatioon / IOKit symbols _kCFAllocatorDefault I've been trying to help David Drum get his FlightGear to build and he discovered that adding -framework Carbon to the Makefile reduces the link errors down to ld: /Users/david/FlightGear/FlightGear-CVS/lib/libplibjs.a(jsMacOSX.o) illegal reference to symbol: _IOCreatePlugInInterfaceForService defined in indirectly referenced dynamic library /System/Library/Frameworks/IOKit.framework/Versions/A/IOKit Sorry, I thought I'd covered this : you need to add '-framework IOKit -framework CoreFoundation' to configure.ac, around link 168. I've attached my version of configure.ac, let me know if you have any other problems. HH James configure.ac Description: Binary data -- The lack of planning on your part does not constitute to an emergency on mine
Re: [Flightgear-devel] Does SGRoute.distance_off_route() work?
On Friday, February 7, 2003, at 03:57 am, Norman Vine wrote: John A. Gallas I was just wondering if the subroutine SGRoute.distance_off_route() calculates accurate results (or even reasonably usable results for navigation in fgfs) for waypoints on a wgs84 system. I've run some tests and it seems okay, but I'm no expert - can someone verify this? This is a *much* better approximation http://williams.best.vwh.net/avform.htm#XTE Just to add, in my local tree I've got an FGRouteBase which (I hope) supersedes the SGRoute stuff totally. I spent ages trying to come up with a better 'distance off route' calculation (trigonometry not being my strong point), clearly I should just have asked here. Whatever I do is going to have to be compatible with SGRoute (but I don't think inheritance from it is going to work, since my routes aren't 'flat', as they can incorporate chunks of other routes, i.e airways and procedures), but let me know if you'd like to see the code (it's alpha-quality and incomplete but loads a route from XML fine, and basic traversal is working too. Adding the distance and course and distance-off-route computations could be done tonight if it would be of interest). HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 02:10 pm, David Megginson wrote: I think that we can centralize this and make it invisible to JSBSim and other suppliers of property values. Polling inside the property manager makes sense, since a) it will be done only on demand (when someone assigns a listener to a property), b) it will be done only once for each property, no matter how many other routines are listening to it, c) it will create no extra work for anyone. I'm happy to have a go at this, or do you (David) want to take a look? i agree it's far and away the best suggestion I've heard in terms of non-impact on the code, efficiency and so forth. -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 01:56 am, David Megginson wrote: If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? This is a good discussion to start. I'm inclined to eliminate tying altogether and have every module set properties explicitly; what does everyone else think? Couldn't agree more, but I think this is likely to be unpopular. We can keep tying if we have an efficient 'notifyTiedValueChanged' method, which should be a no-op if there are no change-listeners registered on the property, and otherwise should run through them. Tony Peden wrote, I'd really like to see tying stay in. I'm not sure we ever would have incorporated the property tree into JSBSim without it. I don't understand why xPosNode.setFloatValue( x ) is so much worse than my_tied_xPos_float = apart from being a bit verbose. And the advantage is, it forces you to appreciate (when you do the set) that some extra working is going to get done (listeners being invoked for now, who knows what else in the future) Jim Wilson wrote, Ummm...it's not polling, it's just updating the data. Same as many of the subsystems do every frame. Polling is a contious loop that waits for something to happen. Like I said, if we're not displaying the prop_picker then it should not be updated. Well, I take polling to mean, going and looking at a value over and over again (one 'look' per frame). That works fine, and I'm *not* trying to argue an efficiency point (sorry if my original email came across that way, since that's how most people seem to have taken it). It's an issue of dataflow in the program : should it be driven by the people updating the values, or by people reading them? Basically, I can envisage lots of things the ChangeListener API is perfect for, whether you're observing a value that changes one a week or 50 times a second, but right now those things won't work because some % of the properties don't tell you they've changed. Now, we could always flag some properties as 'immediate' I suppose, but that seems like a hack. There's nothing wrong with the current API, we just ought to make all the property nodes meet the contract it defines, or we need to remove change listeners from the API and have everyone poll / update as you suggest. HH James -- That which does not kill me has poor aim
Re: [Flightgear-devel] Live property picker
On Thursday, February 6, 2003, at 10:16 am, Frederic BOUVIER wrote:
Aren't the C++ opperators the perfect place to add this kind of action
to tied properties?
I had the same idea reading the message from James.
imagine that template (we are not against templates, aren't we ? ;) :
template class T
class tied_value
{
snip quite reasonable template idea
}
Then replace every tied values with that template :
change :
double xPos;
into :
tied_valuedouble xPos;
You get the picture ?
I do, but this is not the problem (as I understand it). The tie-ing
system is 'low-invasion' for existing code / code which may not be part
of FG, and works well with existing state variables. Your template /
operator overloading fix the syntax, but I sort of think that's worse,
because people may not realize what they're doing will be more
expensive than assigning to a double. But the main problem is people
now need to pull in your template and the property node headers into
places they don't want to.
The impression I have is that a bunch of code uses 'tieing' to expose
lots of internal variables directly. I'd prefer an explicit
'publishing' phase, i.e calls to setValue. Of course your template
works fine too, if you're prefer the syntactic sugar.
HH
James
--
That which does not kill me has poor aim
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] CVS FlightGear and plib 1.6 (was Mac OS X: at a loss)
On Wednesday, February 5, 2003, at 01:22 pm, Jonathan Polley wrote: The solution, for me at least, was to revert back to the CVS version of plib and overwrite the src/js directory with plib 1.6's (as the current Mac joystick code is in a major broken state). Hopefully, David will have a chance to see if it fixes his build problem as well. Err, the JS code is fine for me now (and for Ima too, I think), once you replace js.h and jsMacOSX.cxx with the ones I posted to plib-devel a few days ago. If these do not fix any problems you're having, then **please** post something to plib-devel or email me directly. Since getting things checked into plib CVS seems to be rather slow, I'd rather get the files confirmed working for people before requesting another commit. FWIW, CVS of 'everything' is working on my iBook, updated today, but I have a bunch of local mods to simgear/flightgear (in addition to the plib JS updates) : let me know if you want them. (I'll start feeding them to Curt / David soonish anyway I think) HH James -- They are laughing with me, not at me. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Live property picker
On Wednesday, February 5, 2003, at 05:42 pm, Jim Wilson wrote: Currently, the property tree knows about changes only when someone changes a value through it; when a property is tied to C++ code, the valueChanged() method is never fired. Sounds like a better technique would be to just reread the current directory's values once every 5 frames or some such thing. It'd be pretty quick. Actually, every frame wouldn't be bad. I'm pretty adamant that's the wrong way to do this, we're reduced to polling. Being anal for a second, SGPropertyNode is an interface, and therefore is supposed to make some guarantees about it's behavior. One of these is that changeListeners are correctly invoked. Sure the property picker dialog can do polling, but that's wasteful for infrequently changing values. If there's a performance issues with the core values needing to notify listeners, that's something we need to address too. BTW, I assumed listeners worked, because I figured several things, such as updating panel state, the telnet property browser and so on used the changeListeners: are they actually all using polling?! If so, seems like we're kind of shooting ourselves in the foot or am I just being super-anal and should just poll them as Jim Wilson suggests? HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] DAFIFT progress
Okay, so I have FG working with the DAFIFT NAV and WPT data (replaces default.fix and default.nav). Now, I need some advice: - What things to test that may have broken. I've extended 'testnavs' quite a bit and everything in there works, but this is a minute sample compared to what's out there. So, any suggestions for things to try? Other than 'fly around a bit, tuning the radios lots'.. - I uncovered some API inconsistencies between the fixlist and the navlist (some routines taking degrees, others radians, for lat / lon) : which do we prefer? (I'll fix the offenders) - I'm getting a bunch of odd records from the DAFIFT NAV file: they have no frequency defined (which renders them rather useless except as waypoints). They appear on my SimCharts from Jeppesen, along with frequencies. Examples: In the UK: SAT ODH In the US: VBG TOL SSC PAM In the netherlands: TWN SSB At least the UK ones all have the 'TAC' prefix on my SimCharts. So does anyone know what these things are? I'm guessing it's something military related. The have frequencies in the VOR range (eg 117.7 Mhz based on SimCharts). Now, I can happily ignore them, but I'd like to know what I'm looking at before I do that. - The current code detects the datafile format dynamically, so with a trivial patch to fg_init, I can dynamically use FG_ROOT/DAFIFT instead of FG_ROOT/Navaids if the DAFIFT files are present ... assuming I do this, shall I go ahead and send my changes out for some wider testing? Curt / Dave, which of you is less busy? - Next stop, airways and I almost have a 737 to fling about them, thanks to Dave Culp :-) HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] TACANs (was DAFIFT progress)
On Monday, February 3, 2003, at 07:40 pm, David Megginson wrote: It's more complicated than that. DME receivers (which are UHF) can use TACANs to get distance information -- usually, you do that by tuning in a fake paired VOR frequency. For example, if I tune my DME to 108.8, or slave it to a NAV radio tuned to 108.8, I get distance readings from the UPP TACAN at CYOW, even though there's no VOR. Can the paired frequency be deduced from the channel? Right now, I think the answer is no. I was hoping that such TACANs simply listed the fake frequency in their FREQ column, but I've got checks for that in place and I'm not hitting them (just got that code working). That said, the UPP TACAN is not listed in NAV.TXT, if you know of any others, please let me know and I'll check. (Or did you mean UUP, 'Uplands'?) HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] OT: question about Atlas build - missing files on MacOS X
On Tuesday, February 4, 2003, at 01:38 am, Ima Sudonim wrote: I can't find any information on building Atlas from CVS to use with flightgear. I've modified configure.ac to get past autogen.sh and configure. I have the following build problems. I'll give Atlas a shot today :-) LoadPng.o: Where/what is png.h Get libPng via Fink, hopefully Atlas has a ./configure --with-libpng= option, otherwise we'll need to add one. 'fink install libpng' or pick it from the list using dselect. Or you can just build it from source, Apple already supply 'zlib' which libpng requires. MapMaker.o: What is dirent.h? The problem is the uint parts of this struct This sounds a bit strange, possibly pulling in sys/types will help (as Bert Dreihuis suggested) but I think that should have been done automatically.. I am using MacOS 10.3 with 12/2002 dev tools, gcc 2.95, latest plib, fg from cvs, simgear is recent Is there any reason you're using 2.95 rather than 3.2? It's a much better compiler for C++ And unlike other OS-s, switching back and forth is simple. HH James -- That which does not kill me has poor aim ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X: at a loss
On Friday, January 31, 2003, at 05:14 am, David Drum wrote: OK, both of you that are left reading this, thanks. /me looks around the room and waves I'll make a long story short: every attempt I have made to compile FlightGear, whether 0.9.1 or from CVS, fails in the final link in the same way: ld is unable to resolve the symbols gen_leaf and ssgVtxTable::ssgVtxTable. I have attempted the compile in every permutation I can imagine, which is not a few. More importantly, I have attempted the compile on a fresh install of OS, etc. with as little as possible installed. Same error. I can only conclude that I am introducing the problem somewhere in the same way each time. I am installing: - Mac OS X 10.2.0 (minus all extra languages and applications) - Mac OS X Update Combo 10.2.3 (at this point I change my shell to bash) - Dec 2002 Dev Tools CD (plus BSD SDK) - StuffIt STD 7.01 OS X Install - Fink 0.5.0a (at this point I add the Fink init.sh to my .bashrc, and source it) - cvs-1.11.2.tar.gz (to support fink, installed via fink) - dlcompat-20021117.tar.gz (to support fink, installed via fink) - X4211src.tar.bz2 (via fink) (everything below is installed in a work directory in my $HOME) - plib-1.6.0.tar.gz - metakit-2.4.3-33.tar.gz - SimGear (via CVS) - FlightGear (via CVS) Umm, I am going to bet a moderate amount of money that CVS plib will help, though you may need a patch from me to make the OS-X joystick code compile. Simgear CVS needs a few tweaks to build too, again I have a diff. Also, I find that metakit 2.4.3 doesn't work, I have to use 2.4.8 to get it to build correctly. And again, there are some local mods for flightgear. Otherwise, everything looks sounds. I can send you unified diffs for Simgear and PLIB anytime, and giving them some testing would be good. I haven't actually tried to build FG in a while, been doing other FG hacking on linux. I did have it all up and running a couple of weeks ago, though. Hope this helps, James -- You whine like a mule. You are still alive! ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Naivd frequency / Magnetic variance
So, I've got the basic FGNav structure being constructed from a row in the DAFIFT NAV.TXT file. A couple of the fields are giving issues: - it looks like the scaling of ADF frequencies in the Robin Peel data is wrong: they're in KHz? (eg 340.0), whereas the VORs are in MHz (eg 109.8), but there's a uniform scaling of 100 applied this seems a bit odd to me. I'd rather 'freq' was just the frequency in Hertz. - All the navids in the DAFIFT have a supplied Magnetic Variance, so I need some help dealing with the format. It's basically: E/W (direction) degrees variation (actually deg / min / tenths of minute, but I can convert) year / month stamp. Now, what I'm wondering is whether I can do anything with the year / month stamp to update the variation? Oh, and what's the sign convention for our magvar values? +ve = East, -ve = West? Anyway, the DAFIT stuff is going well, I'm able to pull in lots of extra data which will be useful for ATC and the like, as well as reception quality: there are things like guaranteed service ranges / volumes, transmitter wattages and the like. HH James -- There is no such thing as a humble opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FW: Cygwin Build problems
On Wednesday, January 29, 2003, at 02:43 pm, Curtis L. Olson wrote: SimGear/FlightGear configure used to automatically add /usr/local/lib to the library search path. That was removed because apparently it causes gcc-3.2 to gripe? Someone needs to explain the gcc-3.2 problem so that we can get this resolved in a way that works for everyone SNIP Same /usr/local/lib issue ... apparently we don't include /usr/local/lib in order to appease the gcc-3.2 gods, but then it never get's included at all ... why does gcc-3.2 detest having to look in /usr/local ??? The problem is that /usr/local/include and /usr/local/lib are in the default *system* search path, so #include simgear/foo.h works. When you manually add /usr/local/include to the search path using -I, you're adding it as a *user* path, with a totally different order in the search. Apparently, this can cause very obscure breakage (don't ask me to provide an example). As a result, GCC 3.2 prints out a *huge* warning for every single source file it processes, which is very, very annoying. Hence, the correct solution is only to add /usr/local/include (or lib) on systems where it is not already in the search path. Which, it sounds like, includes cywgin. Hope this is of some help. HH James ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] RFC: Radios and Instrumentation
On Wednesday, January 29, 2003, at 03:18 pm, David Megginson wrote: With the move, I'm also considering cleaning up the radio code a bit, and introducing better lags for the ADF and VOR needles (they're a little too snappy right now). Just one thing : when I get to the KLN-89b, I'm going to need support for optionally back-driving the instruments from the GPS's output (this couple if required in order for the installation to be certified for GPS precision approaches). Such operation is usually done via simple NAV/GPS toggle switch on the panel somewhere. I *think* the only thing I need to drive is CDI deflection, since you can't get GS from a GPS approach (please, someone, correct me if I'm wrong here, all I have to go on is Fly! and the Bendix-King PDF manual..) In larger aircraft, I assume there's other things that can be back-drive, even before you get up to a full PFD / NAV display. So, I'd just like to establish how we differentiate between 'signal output from the radio' versus 'signal input to the HSI instrument', so that someone can trivially add the toggle switch to their panels. HH James PS - reading the DAFIFT is going well, more on that in a few days. -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Partially Offtopic: Help open up the FSD protocol
On Monday, January 27, 2003, at 01:27 pm, Michael Basler wrote: Neither my flying skills nor my spare time are sufficient for taking part in Vatsim :-( Me too ... However, I know that there are a few competiting networks a la Vatsim present or just emerging and I read several quite sharp debates (from various parties) about stealing ideas, data, members from each other in Newsgroups right now (instead of sharing services, members, controllers...). There's also IVAO? which is a different group but uses the same software If you can do it, I'd propose developing our own (albeit small) service. If not more, than just a few controllers around KSFO as a proof of concept. The problem will all these system, as I see it, is the lack of people willing to control. What I think would work much better is a web of servers, but with the ATC manned by AIs. Of course in the long run people could write a controller client and take over from the AI at a position, but basically the system could function happily without any human controllers. Now, writing those ATC AIs is non-trivial, but it's something that's in the pipe-line anyway. This also suggest a 'Quake-like' approach for local traffic and ATC : simply start a local server running the ATC ai and some plane AIs, and connect the main program to it over loopback. (Quake-like as in this is how every modern first-person shooter based on Quake or Unreal is set up. Bots on the server are indiscernible from other live players, and single-player works as expected, but is in fact running a server too). Comments? HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FGNavList searching
On Saturday, January 25, 2003, at 09:55 pm, Curtis L. Olson wrote: I made some changes to the FGNavList class, take a look and see if it will work better for your needs. Thanks, I already saw this and picked it up, it works great! I'd done the research (okay, 2 minutes with grep) to see who the users of the NavList code were, but obviously that hadn't made me realize they were all doing their own range checks. Anyway, thanks again. HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] FMC / GPSs [ was End of /steam approaches]
On Sunday, January 26, 2003, at 05:12 pm, Norman Vine wrote: Hopefully we can now actually start implementing a realistic 'navigation computer', as is present in most modern GPS units and autopilots that, since the hopefully the AP is no longer dependent on hardwired to steamed input from C172 instrumentation Actually, I'm rapidly approaching that area, from a different direction. I'm working on extending the Navaids layer to know about structured route data, namely DPs / SIDs / STARs / GPS approaches / airways, but most importantly, flight plans. I've got an XML format I'm reading in, and am about to start exposing the data to the property system. One of my 'route' types is FGActiveFlightPlan, which is designed to provide a good chunk of the runtime state necessary to drive either a KLN-89b-style thing, or a full blown FMC (c'mon Dave Culp, I need that 737!). What I'm hoping is that with our new-found scripting capability, a lot of the 'device specific' logic I was probably going to do in code can be done in scripts in the instrument files, providing my C++ code exposes rich enough data to the property system (shouldn't be a problem). BTW, there is another important goal of my flightplan code that it should be common to multiple subsystems. most notably that AI aircraft and full-blown ATC systems should be able to work from the same base classes. FMCs and such are my initial goal, though. Current plan of attack is : - get the flight plans exposed into the property system. Will look something like / .. owner system /flightplan[n]/origin/icao = EGPH / .. owner system /flightplan[n]/origin/runway = 06 / .. owner system /flightplan[n]/destination/icao = EDDF / .. owner system /flightplan[n]/desintation/runway = 27L / .. owner system /flightplan[n]/eta = .. computed time / .. owner system /flightplan[n]/waypoints[0]/id = TLA / .. owner system /flightplan[n]/waypoints[0]/alt = 8000 (this is a crossing restriction) / .. owner system /flightplan[n]/waypoints[1]/id = DCS / .. owner system /flightplan[n]/waypoints[2]/id = ... etc (all subject to change!) The owner system might be an FMC / GPS unit, an /aircraft[n]/ai node for an AI plane, an /atc/aircraft/ node, or so on. - one the above is done (hopefully in the next few days), I'm going to hook up the waypoint following in the current autopilot to follow my loaded flight-plans. Once that's done I need to try adding route sub-structures, i.e airways (easy) but then also the different kinds of DPs, STARs and GPS / non-precision approaches. My intention is to write loaders that parse some of the existing formats out there, so we leech the data available for the various FS2000/2 flight computer devices. Anyway, that's about where I am, none of this stuff is in CVS yet, if anyone else thinks they're working in an area where they might benefit from this, let me know and I'll see about getting it committed. Otherwise I'll keep the damage confined locally, the API, such as it is, is changing daily at the moment! HH James -- Morbo finds all humans pathetic ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] FMC / GPSs
On Sunday, January 26, 2003, at 08:47 pm, Norman Vine wrote: You are aware of these http://www.ibiblio.org/fplan/ http://www.ibiblio.org/fplan/avdbtools/guide.html and FlyWay at http://www.bellz.org/progs.html Ah, I'm aware of things like them, but I guess my terminology is wrong. What I'm working on is the in-memory representation of routes. Obviously I'm expecting to write importers for any formats that exist already (eg SquawkBox and FS2k2), as well as the XML one I've knocked up. I know there's a Java one for X-Plane which is also popular, again, I'm happy to steal people's data formats. If someone wants to write an in-process flight planner, they can do that too (hell, I might even get around to it myself in a year or so...) Right now, I'm not really worrying about that, but rather pulling all the disparate bits of data (navaids, airports, aero data, position info) to make up the working flight-management system. I simply had to do the 'flight plan' bit first because that's something that wasn't already there (at least, the logic in Simgear/Route and the existing simple flight plan format isn't nearly semantically rich enough for my purposes). I am aiming to eventually support the full feature set of Boeing and Airbus CDUs, so I need things like 'smart' joining of airway and procedure segments into chunks of route, on-the-fly (re-)selection of arrival runways and procedures, auto-sequencing of missed-approach segments, holding at waypoints (including picking up default hold parameters for holds on STARs), and so on (and on...). Hopefully the classes I'm doing up are flexible enough to handle all this and more, since I certainly don't know all the things every FMC out there can do. Anyway, I'm calling a sequence of waypoints you *could* fly a 'flightplan', and a set you *are* flying (i.e once you get clearance, pick an aircraft and fuel load, and know your departure runway and procedure) an 'active route'. If my terminology is horribly skewed, please correct me sooner rather than later :-) HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Missing FGCondition.h
My Linux and OS-X builds (cvs updated today) are both failing in FDM/JSBSim/FGSwitch.cpp, because FGCondition.h is not found ... a missing cvs add? HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] KSFO International Terminal
On Saturday, January 18, 2003, at 12:44 am, David Megginson wrote: Michael Basler writes: as an interim report, the guy with the FS98 add-on KSFO scenery did not answer until now (but mail did not bounce either). I'll stay tuned, but doubt he will... it's just been so long ago and he did never provide upgrades for FS2000/2 . I fear you'll have to find pictures and stuff somewhere else. You're not willing to make a quick trip from Germany and take some, then? Where's your team spirit? Actually, I'll be flying into KSFO at the start of march (going to GDC again), so I can easily get snap away .. the problem is I'm unlikely to get good shots out the window of a 747, hopefully some good elevation ones of the terminal after touch-down though. It doesn't help that it'll be easiest for me to get you shots of the bit you already have, the international terminal. BTW, I'd just like to point out that I saw the terminal model 'first', I was just keeping quiet :-P Incidentally, if anyone fancies doing up EHAM (Amsterdam Schipol), I could try and get some shots of that too, though similar issues apply. HH James -- We are all in the gutter, but some of us are looking at the stars. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Displaced thresholds
That looks pretty similar to what I've been aiming for (screenshot of current progress at http://www.nottingham.ac.uk/~eazdluf/taxidraw.jpg - and yes I know its currently windoze only - its just a fast prototype proof-of-concept and I'll port it to a multiplatform toolkit if it works). It would certainly make sense to be able to import AFCAD files. However, there may be issues concerning whether the airports are placed in exactly the same location in FS2K2 and FGFS, and as regards the files, even if permission could be obtained from some authors to use their files, I would have thought that we would have to make absolutely sure that these represented their original creation, and were not an extension/modification Just wanted to provide some ideas based on the Fly! Taxiways Editor (which is an excellent tool, once you get over the learning curve..). Basically, you can import an airport diagram (bitmap), and define the lat/lon of two points on it (usually the start and end of major runways are easiest), and then trace over the image. Where the tool gets smart is in laying out the graph structure (i.e one line per-taxiway), it automatically handles the generation of curved sections of tarmac, intersection markings on the centre-line, and so on. Basically it's doing a little bit of trig, and using some modifiable constants for radius of turns, but the end result looks much more 'real' than what FG has right now, with a fairly minor amount of work. (and from nearly identical data, I think) I'd like to have a go at implementing the 'joining' algorithm, but I'm totally lost where to begin (at least that's my excuse). Oh, and, as a random thought that's been bugging me in this area for ages, I think it'd be really cool (but virtually pointless from a simulation point of view) to support roads (and a accompanying AI graph) in any such editor too nothing like having an errant baggage-truck zip or busload of passengers shooting over a taxiway to wake you up in the morning :-) Hmm, having said it's pointless, it occurs to me it may have safety-training implications for pilots to teach them there's other things besides aircraft they need to watch out for. I'll leave such considerations to the real pilots though. HH James -- We are all in the gutter, but some of us are looking at the stars ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC Sound
On Monday, December 23, 2002, at 02:14 pm, David Megginson wrote: Hmm. I wonder what the issue is. At 10, I can hear, perhaps, 75% of it over the idling engine, but I still have to strain to make it out. I don't know enough about the audio side to troubleshoot this easily. I would just like to corroborate David's results, I thought ATC was broken until I realized I could *just* hear it over the engine noise. This is on Linux with ALSA, all the other FG sounds have a 'normal' volume. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Mac OS X 0.9.1 build available
On Saturday, December 14, 2002, at 08:20 pm, darrell.l.walisser.1 wrote: I would like to get joystick support included soon (this would involve working on PLIB). Is anyone else already working on this? I am about to, by porting Max Horn's work in SDL to plib. I've got as far as reading over Max's code (IOKit HID hell), just thinking how to fit it to the PLIb API. Beofre going any further I wanted to ping the PLIB guys and check no one else was planning to work in that area. I should get the joystick stuff done 'this week' but if you want to have a go, just say the word. BTW, I submitted a bunch of fixes to Curt which mean that, 'so far', SimGear and flightGear CVS compile fine under Jaguar. I'm planning to do up a bundle eventually, I'm just not sure how to handle add-on files (mapping the FGFS data directory to Library/FlightGear? ) .. anyway that's longer term. HH James -- The lack of planning on your part does not constitute to an emergency on mine ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Re: ld: Undefined symbols error linking fgfs 0.9.1
On Sunday, December 8, 2002, at 04:15 am, Andy Ross wrote: David Drum wrote: I am compiling FG 0.9.1 on Mac OS X. ld: Undefined symbols: _CPSEnableForegroundOperation _CPSGetCurrentProcess _CPSSetFrontProcess _CPSSetProcessName [...] I sent this to flightgear-users a couple days ago when 0.9.0 was out. No response. My word. The reason these symbols are undefined is they're undocumented 'secret' Apple APIs (but very useful ones). They are used to assemble a hack that is doing the rounds of many ported Unix tools and libs : for example libSDL and gtk-quartz. I have so far contacted two people trying to trace the origins of the hack (waiting for Max Horn at the Fink project to see if he can find his source). I am probably going to propose this hack as an addition to debug builds of Mozilla (MachO builds), so it's getting fairly widespread : I didn't realize it has made it into FG / plib though. Anyway, you need to link against an extra library. I did this: grep -r CPSEnableForegroundOperation /System, and got the following (on Jaguar, be warned the link library may be different on Puma) And it seems that the symbols are in the CoreGraphics framework (which you should get as part of CoreServices). I assume that for FG and plib we only link against Carbon, so of course we don't pick up any 'extra' CoreServices functions like this. BTW, doing this: nm /System/Library/Frameworks/ApplicationServices.framework/Frameworks/ CoreGraphics.framework/CoreGraphics | grep CPS turned up a whole slew of interestingly named methods! :-) BTW, I haven't even got as far as linking due to problems with PLIB CVS versions (Mac gcc keeps moaning about Plib's ul.h, it seems to be getting included as C file, not a C++ one, and hence function overloading is not permitted). Haven't taken this up with the plib guys yet. HH James -- There is no such thing as a humble opinion. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Blender Status
On Wednesday, November 13, 2002, at 07:16 pm, Gene Buckle wrote: Wouldn't it just be easier to allow the user to configure how they'd like the aircraft lists presented? The model file can indicate aircraft details such as licence requirements, operation category, etc. The user could then configure via a global option of some kind as to how they want the available aircraft sorted and listed. Agreed whole-heartedly I think storing each aircrafts' data in a tar file was mentioned earlier. Why not use the infozip libs (gpl'd I think) to create .FGAR (FlightGearARchive) files that would hold the model configuration and any associated textures in a compressed format. It would keep things simple for the end-user and any fancy editing tools could be built to crack open the archive easily enough. The software should be smart enough (based on data in the config portion of the model definition) so that directories breaking down aircraft by FDM wouldn't really be required any longer. Basically I have been planning to suggest the same thing : Mozilla uses .jar files for this purpose, and it works really (really) well. Managing different packages / installing aircraft for FS2k(2) / Fly! is an exercise in tedium and hassle getting paths correct, copying panel files, etc, etc. A simple package format (hence something zip / tar.gz based) with good meta-data for type and versioning will be a huge, huge benefit as the number and kind of add-ons grows. And FG already uses Zlib, so adding jar support wouldn't even require another library dependency. Crystal space again uses .zips for this purpose, with a VFS layer that can 'mount' zip archives into the data file-tree, and again it's very simply to author for and works well. Dependency tracking would be a huge benefit here (common instruments / models / sounds / whatever) if it can be done simply and effectively. And of course if the system can be coupled to wget / curl, it will just rule :-) Though that's getting a bit carried away. Good ideas or should I go back under my rock? :) Excellent ideas :-) HH James -- Whenever a friend succeeds, a little something in me dies. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
