Re: [Flightgear-devel] CVS compiling error CYGWIN
Have you tried adding -DNOMINMAX to your CFLAGS and CXXFLAGS?
Alternatively try adding
#ifdef HAVE_CONFIG_H
# include
#endif
as the first include of each cxx or cpp file giving problems.
I'm not using Cygwin any more BTW, so I'm posting blind, but I'm pretty sure it
will turn out to be the old min/max redefinition problem again.
Cheers - Dave
Georg Vollnhals writes:
> Hi,
> after many!!! new builds without any problem I have got a new one over
> the last days when trying to compile the newest CVS under Cygwin.
> At last I even made a complete new Cygwin install and complete new
> download of SimGear and FlightGear CVS and tried to compile the whole
> stuff - same result: SimGear without problems, FlightGear compilation
> does not work.
> Any ideas? Thank you in advance!
> Regards
> Georg EDDW
>
> In file included from
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/deque:71,
> from
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/queue:74,
> from ../FGJSBBase.h:47,
> from FGFCSComponent.h:46,
> from FGDeadBand.h:40,
> from FGDeadBand.cpp:40:
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_deque.h: In
> member function `void std::_Deque_base<_Tp,
> _Alloc>::_M_initialize_map(size_t)':
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/bits/stl_deque.h:446:
> error: expected unqualified-id before '(' token
> In file included from
...
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New segfault [bug] activating mini-panels (2d)
"Curtis L. Olson" writes: > Andy Ross wrote: > > > > >It's much more enlightening if you embarass them publically. Unless > >it's me, of course. > > > > > > I'll give them my usual 30 minutes grace period. Then I'll bring down > the hammer. You hear that Dave, you only have 15 minutes now! > Thanks Curt ;-) I suspect that this is due to my sneaky multiple inheritance of the special instrument from both SGSubsystem and FGPanelInstrument - subsystems seem to be somewhat less robust than panel instruments to some of the shenanigans that can go on with the panel operations. I already know that Ctrl-C (panel reload) breaks when a panel includes the KLN89 - I suspect that the mini-panel woes (never tested since I completely forgot about it) are a variation on the same theme. As an immediate fix, simply comment out the section in the C172 2d panel xml file. You'll be left with the GPS background and buttons, but without the working text. I'll give some thought to a more robust fix - it's on my TODO list anyway since the Ctrl+C problem became apparent. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: KLN89 GPS added: cleanups [patch]
Alex Romosan writes: > David Luff <[EMAIL PROTECTED]> writes: Urgghh - email addy in header! > > > I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). > > Briefly, since it's late, it's only included on the c172p 2D panel > > (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 > > since the fonts are at 1:1 pixellation at that resolution. > > the attached patch replaces passing strings by value with passing them > by reference (string -> const string&) to avoid copying them > needlessly. also makes GetId() in GPSPage a pure virtual function. > > Thanks, I'll read through that and apply it, probably tomorrow. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] KLN89 GPS added
Joacim Persson writes: > I'm curious about the choice of language/linkage for the implementation: > Why have a specific vendor model hard-coded in c++? Seems more like task > for xml/nasal scripts to me. ?:-P Nothing wrong with the language (c++) > but isn't it a little out of place in the fgfs /core/. > That's a fair point. I used c++ because that's what I'm used to, and that's what I *know* can get the job done without running into major obstacles, whereas nasal, and adding the 'C' code function hooks for it, is an unknown quantity to me. Additionally, the c++ code could concievably be used as the basis for a standalone KLN unit simulation where nasal is not available, for instance as an X-Plane or MSFS plugin. Not on my TODO list, I hasten to add! > Another way to go (in the future) could be implementing specific instrument > models as "plug-ins" -- dynamic objects. Then the model designer can choose > implementation language freely. (If for instance one is well familiar with > c++ and find nasal et.al. awkward to work with.) It could also be > easier to debug in that manner. (using stubs) I agree, a plugin architecture would be ideal, since then complex avionics UIs wouldn't have to add weight to the core code in terms of compilation time, compiled code size and so forth. However, a plugin architecture would have to be well thought out, and crucially, stable, to avoid plugins that by definition aren't compiled by all developers having the interface shift from beneath them. I have no experience of plugin architectures, and don't feel competent to attempt it at the moment. I'd happily alter the kln89 code to make use of one if available though. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: GPS
Steve Knoblock writes: > > Now that we are seeing a choice of GPS units, it beings to raise a > similar question to the autopilot. There will be confusion over the > waypoint and gps dialogs on the FG toolbar. It may be necessary to do > something similar as I proposed with autopilot. > Yes, I agree absolutely. The currently situation of a totally non-functioning menu entry simply confuses users. I guess that in the short term we should grey them out if non-functional, and in the longer term they should be an alternative interface to the instrument than the panel representation, since we work within the constraints of simulating the real world on a small screen, and sometimes real-world-style instrument use is simply hard to do during simulation. In this case, the dialogs might need customising slightly for each unit, although for the GPS that might be simply a case of the maximum number of flightplans allowed, or the maximum number of waypoints per flightplan, since fundamentally their operation is probably more similar between units than autopilots. > The approach I took to integrating GPS into my autopilot was to rely > on the existing built-in GPS. I assume this is a C coded model of a > generic GPS unit. It raises the issue of should instrument autopilots > (that ones that appear in the cockpit) all use the same model and put > a different face on them or should there be any number of gps units > available? > > If there are many gps units coded in C, it might be wise to remove the > generic one. However, then those who might want to build a GPS model > based on the generic gps using NASAL might be out of luck (I'm not > sure if it is possible or reasonable to implement a moving map GPS > display in NASAL and instrument XML, however, a simple text display > might be feasible). > There's absolutely no reason to remove the generic one. Indeed, the KLN89 unit uses the output from the generic unit. Fundamentally, everything in src/Instrumentation/KLN89 is only a simulation of an avionics user interface (albeit an extremely complex one). Src/Instrumentation/gps.[ch]xx (should I capitalise lower-case directory names when they start a sentence?) as it currently stands (unaltered by me) is simply an export to the property tree of position, to/from flag between 2 waypoints, and various other positional/speed/track related quantities. In the middle I have added src/Instrumentation/dclgps.[ch]xx, which adds more advanced capabilities than gps.[ch]xx, such as waypoint sequencing during flightplan operation, cdi needle deflection calculation, approach mode sequencing during non-precision approaches, great circle distance calculations, stuff like that. Currently none of this is exported to the property tree. However, this is not how it is intended to remain. All the complex GPS stuff in dclgps.[ch]xx should move to gps.[ch]xx and be exported to the property tree, for the benifit of non C UI implementations. By 'should', I mean that it's on my TODO list. > The autopilot I modeled is tightly integrated with a GPS unit. It > needs to access GPS properties. However, this means that if there are > more than one gps unit available in FG, the autopilot code must be > changed to use the properties of the particular autopilot. That may > not be too great an issue if instruments are supplied with particular > aircraft as opposed to something generic that can be placed in any > aircraft (like GPS in MSFS). Given that the wiring can be potentially > different with each aircraft, the autopilot code may need customizing > each time it is placed on a panel. > Ideally the instruments will be as multi-usable as possible, and nasal is probably ideal to do the plumbing. But the more complex the systems we are modelling, inevitably the more complex the sim integration will become. Let me know what you need exported from the GPS and I'll try to oblige (but bear in mind I sometimes can't get online for a few days at a time). BTW, can you remind me again where I can download your autopilot from. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] KLN89 GPS added
Hi folks, I've added a KLN89 GPS unit hardcoded in C++ (OK'd by Curt). Briefly, since it's late, it's only included on the c172p 2D panel (--aircraft=c172p-2dpanel). It looks best at --geometry=1024x768 since the fonts are at 1:1 pixellation at that resolution. As with the KAP140, it's independent of the menu dialog, and needs reference to the real life manual for proper use, which can be found on the web via Google. For non-manual readers (!), very briefly the inner and outer knobs and the crsr button are the crucial ones to get started (hit Ctrl-C for hot-spots). Inner knob changes subpage or item under cursor, outer knob changes page or cursor position, crsr toggles cursor on/off. A few flight plans are hardwired in - others can be added through the unit, but are not saved between FG sessions. Non-precision approaches for C83 and KHWD (both in the FG base package) are hardwired in and can be loaded from the APT8 page (IIRC), and the unit will simulate non-precision approach operation, including the cdi scale changes at the approach-arm and approach-active points (make sure you switch nav1 to gps on the annunciator/switch unit). Thanks to Roy Ovesen for supplying me with the svg drawings of his KAP140 as a starting point for the background. Cheers - Dave ___ 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
James Turner writes: > > 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. I've put a link to your webspace for now, since I can't log in to SF's web-based admin pages at the moment (but can ssh into the shell OK to update the webpages). When I finally manage to move it to SF I'll let you know. Once again, many thanks for taking the trouble to do this - it's much appreciated :-) Cheers - Dave ___ 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
James Turner writes: > > Okay, a DMG is available from my .Mac account: > > http://homepage.mac.com/zakalawe/.Public/taxidraw-0.3.2.dmg > 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? > This 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. > 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? Cheers - Dave ___ 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
James Turner writes: > > On 23 Nov 2005, at 00:23, James Turner 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. > > BTW, David, you should really investigate using a config.h - your > compile lines are, uh, rather long :) > Yes, I know, it's one of those things that never makes it near enough to the top of the TODO list to actually get done, given how many more serious annoyances there are in both TD and FG. One day... Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Request to the Mac folk
Hi guys, 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). If anyone is able to do this, TIA. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New commit ssgEntityArray not built
ssgEntityArray.[ch]xx has recently been added to simgear/screen, but doesn't get compiled since there appears to be no reference to it added in Makefile.am. Is this intentional or an oversight? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] SEGV with ATIS
Pigeon writes: > > Hi all, > > Running fgfs cvs, starting up normally at KSFO. Bringing up the radio > dialog and switching COM1 to the ATIS frequency. Sometimes I get: > > > ERROR - mismatch between ATC .wav and .vce file in ATCVoice.cxx > > Offset + length: 2890 exceeds rawdata size: 0 > > > And sometimes it segvs, with a backtrace that looks like this: > > > #0 0x404e5927 in memcpy () from /lib/libc.so.6 > #1 0x080ee52d in FGATCVoice::WriteMessage (this=0xac0efc8, > message=0xb4a , [EMAIL PROTECTED], > [EMAIL PROTECTED]) > at ATCVoice.cxx:173 > #2 0x080c7f6b in FGATC::Render (this=0xe6b9550, [EMAIL PROTECTED], > [EMAIL PROTECTED], repeating=true) at basic_string.h:717 > #3 0x080c88a2 in FGATIS::Update (this=0xe6b9550, dt=0.125) at > atis.cxx:78 > #4 0x080a98a8 in FGATCMgr::update (this=0xaf93ba0, > dt=0.025001) > at stl_list.h:169 > #5 0x0805354d in fgMainLoop () at globals.hxx:279 > #6 0x08089235 in GLUTidle () at fg_os.cxx:114 > #7 0x400ab5c2 in glutMainLoop () from /usr/lib/libglut.so.3 > #8 0x08055800 in fgMainInit (argc=2, argv=0xb5c4) at main.cxx:1007 > #9 0x08051c2a in main (argc=2890, argv=0xb4a) at bootstrap.cxx:193 > Hmm, I think that line 79 of src/ATC/ATCVoice.hxx should be changed from unsigned int rawDataSize; to int rawDataSize; I think that this should avoid the seg fault when the sanity check is failing ( well, I can't think of any other reason OTOH ;-) ), but I'm not sure why your sound data buffers are empty. It seems that the .wav file is not loading properly, but that's more Erik's area so I'll leave it to him ;-) Excellent multiplayer map you've done BTW :-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: [RFC] dynamic dialogs (ATC example) ... or forever hold your peace.
Melchior FRANZ writes: > * Melchior FRANZ -- Sunday 23 October 2005 20:15: > > Is this method acceptable? (I'd convert further hard-coded dialogs > > in this style then.) > > OK. Accepted by overwhelming lack of interest and objections. > > > > > Is this patch acceptable for the ATC people? > > Passive agreement here, too. But don't say I didn't warn you! > I'll commit a first version now. Will refine it later. > Hi Melchior, I was on Holiday without web access last week, but I'm very happy to see you diving into that bit of the ATC code :-) I'm sure there are a lot of cobwebs in there that need shaking out. I'll take a look at what you've done soon... Thanks - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Bug in ATC code.
On 20/10/2005 at 21:40 George Patterson wrote: >Hi All, > >I have noticed two annoying bugs in the ATC dialog boxes. > >When you press ' for the first ATC dialog labelled "ATC menu" is >displayed. (btw, Can we change that title as it's not an accurate >description, perhaps "ATC communication") > >Anyway, if you change frequencies for another ATC tower, extra lines >showing :- >1. Contact tower for VFR arrival (full stop) >2. Contact tower for VFR arrival (full stop) >3. Contact tower for VFR arrival (full stop) >etc, depending on how often you have switched frequencies. > >The other one which might be related is if you reset FlightGear >(File->Reset), the state for the ATC is not reset back to the "Contact >tower ..." dialog. Instead it will continue when you partially finished >from before.. Contact tower-> Report Downwind -> Runway vacated. > > Thanks George. I'll attend to those in the next few weeks. The extra lines problem I was aware of, but the state persistance through reset is new to me. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
On 20/10/2005 at 10:50 Erik Hofman wrote: >David Luff wrote: > >> Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to >-HUGE_VAL >> and I suspect this should compile. > >Ok, I've committed a fix. >> >> I guess that we could do something in compiler.h along the lines of >> >> #ifdef __CYGWIN__ >> #define HUGE HUGE_VAL >> #define -HUGE -HUGE_VAL >> #endif >> >> or something like that. Erik? There is already an instance of this >> problem in TerraGear. > >Maybe someone has to convince the Cygwin developers to add it to the >appropriate header files instead? I've seen several projects that have >to make special cases just for this. It's better fixed at the root of >the problem. > Fair point. Do you know if HUGE is part of a standard anywhere that definately should be supplied by Cygwin, or is it simply available from everyone else by unwritten convention? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS compiling error
On 19/10/2005 at 12:05 Georg Vollnhals wrote: >Hi Erik/Durk? >Since your update of simple.cxx/hxx on the 18.10.05 the newest CVS >version does not compile anymore :-( > >Error: >simple.cxx: In member function `int >FGGroundNetwork::findNearestNode(double, > double)': >simple.cxx:1331: error: `HUGE' undeclared (first use this function) >simple.cxx:1331: error: (Each undeclared identifier is reported only >once for > each function it appears in.) >make[2]: *** [simple.o] Fehler 1 >make[1]: *** [all-recursive] Fehler 1 >make: *** [all-recursive] Fehler 1 > >Any solution? Cygwin doesn't have HUGE, so change HUGE to HUGE_VAL and -HUGE to -HUGE_VAL and I suspect this should compile. I guess that we could do something in compiler.h along the lines of #ifdef __CYGWIN__ #define HUGE HUGE_VAL #define -HUGE -HUGE_VAL #endif or something like that. Erik? There is already an instance of this problem in TerraGear. BTW, Georg, CVS SimGear should compile on Cygwin 3.4.4 now, and CVS FlightGear will probably compile on it if you add #ifdef HAVE_CONFIG_H # include #endif as the first include for every source (cxx or cpp) file where you get the strange error message you reported a while ago. Then send the output of "cvs diff -u" from the FlightGear directory to Erik, and the 3.4.4 problem should be sorted :-) Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instant replay broken?
On 16/10/2005 at 18:19 Erik Hofman wrote: >David Luff wrote: >> Is it just me, or is it completely impossible to escape from instant >replay once engaged in the current CVS? > >You can end the repeating loop by pressing 'p' twice. > Ah, OK, that works. It's not exactly intuitive though! How about I remove the superfluous view combo box from the replay dialog which isn't wired up anyway, and add a tick box to specify looping or one repeat. And any objections to ESC exiting replay, if I can avoid it popping up the exit-sim dialog in that instance? In fact, that reminds me, it would be good if ESC would cancel dialogs instead of displaying the sim-exit dialog when a dialog is already displayed. Anyone have any idea about what implementing that might entail? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Instant replay broken?
On 17/10/2005 at 02:01 George Patterson wrote: > >Yes, It's just you :-P > >You can stop the replay by select the View menu, select instant replay. >On the Instant Replay dialog check the "Disable replay". and click Ok. > Believe me, I've tried that. It simply doesn't work AFAICT. On Linux the replay is unaffected and just carries on endlessly looping, on Cygwin the replay is frozen, but normal service is not resumed. Does this really work OK for everyone else? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Instant replay broken?
Is it just me, or is it completely impossible to escape from instant replay once engaged in the current CVS? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: A question regarding accurate taxiways
ojoe writes: > > You know, I'd be happy to help do some of the taxiway work if a new format > becomes available. I've been trying to work with Taxidraw, but it's kind > of difficult to work in because of the underlying format (I have no > problems with Taxidraw itself.) I find I spend a lot of time making sure > the areas are in the correct place, all to make a curve that could've been > described more easily with multiple points. > I certainly sympathise with this point of view. The current format is certainly crude. However, the problems with it only become apparent close up, when either close to or on the ground, and trying to follow taxiways at intersections. The taxiway layouts done in the current format definately improve the view of the airport on approach, when the deficiencies are too far away to be apparent. I think that what will happen with taxidraw is that we'll gradually make it capable of editing a future richer format, whilst continuing to export the current format at present. For instance, curved taxiway sections could be specified as a curve, stored as such internally in the .tpj format, and then the required rectangles to approximate it in the current format calculated on export to X-Plane (current) format. Or something like that! The next version of TaxiDraw will include support for explicitly specifying the airport perimeter. Once the perimeter of an airport is correct, and the FG scenery has been built with that definition, then it would be considerably easier for any future custom airport editor to build an airport that would fit into the same cutout from the scenery, and hence allow instant updating of the airport in the user's sim. Possibly... > I know there was some talk of extracting taxiways from the FAA's PDFs, I can't realistically see that happening! > but > until that becomes available, a 'starter set' of airports in the new > format might be a good idea. > The base package scenery area is the obviously choice for a technology demo - it just awaits someone to step up to the task. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] c172: realism of radio transmission vs ambient noise volume
Vassilii Khachaturov writes: > Sorry I haven't gotten to mention this before, > since this is smth that I kept noticing for months already. > In the c172 aircraft, the ambient noise in the cockpit > is pretty similar to what one hears w/o any headset. > When one turns the radio on and tries to hear the ATIS, > it sounds pretty low volume. > Hi Vassilii, Which C172 are you commenting on? For the default 3d version I've turned the cockpit engine noise down to allow the ATIS to be more audiable as though headsets are worn - you can hear the difference when using the 'v' key to switch to outside view and back. I haven't done this for the 2d panel c172 though yet, but probably will if there are no objections. However, I don't know what the inside of a light aircraft cockpit should sound like, unlike yourself! > In real life, you can either put the radio on the loudspeaker > (overhead), or put on the headset and have the radio in it. > In the former case, I believe the volume is higher than this > produced by fgfs. In the latter, I believe the radio volume > is just about right, yet the ambient noise is much less because > it is reduced by the headsets. > > For a quick fix, I suggest just increasing the relative volume of > the nav/comm radios vs the ambient noise. > Unfortunately, the original recording of the ATIS was done at too low an input volume (I'm not really a sound guy, and the microphone used was very cheap and nasty) and attempting to up the volume seems to crank up the hiss a lot. I'd like to make a better original recording one day. > (For full emulation, one could emulate donning headsets w/ > different noise reduction/active noise cancelling frequency-based > charachteristics, but this is pretty much an overkill, esp. > since we don't even have a volume control on the comm radios). > > FYI: I'm talking about 0.9.8 on Debian Linux 2.6.8-2, > ALSA snd_intel8x0 sound. I'm building a CVS version right now, > and will post if that behaves any differently. > One thing that was apparent originally was that the relative ATIS volume compared to the engine noise was a lot louder on Windows than on Linux. At the time I made the recording I was running FG on Windows only, and set the volume for that platform. On some Linux installations (David Megginson and others reported it) it was apparently virtually inaudiable. I'm not sure what the relative state of play on this is at the moment, since I haven't run FG on Windows for a while now. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Source code
"Jon Berndt" writes: > 1) Of course, it would be nice to incorporate the JSBSim changes into the > current JSBSim > CVS. However, as you may know, JSBSim has undergone major revisions compared > to the > version now in FlightGear CVS. Within weeks (maybe sooner) we should be > moving the new > JSBSim code into FlightGear development CVS. So, to incorporate your changes, > the Load() > method will need to conform to the use of the new XML parsing method. > Out of interest, did Mathias ever manage to fix the gear jitter at stationary with his fancy integration scheme, and if so will it be going into FlightGear when you merge up next? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Fix for SimGear Cygwin gcc-3.4.x compilation
Hi folks, The following patch needs to be applied to fix the errors that Georg Vollnhals was getting whilst attempting to compile SimGear with gcc-3.4.x in a thread a week or so ago. Could someone with CVS access commit it please - it's the old picking up the -DNOMINMAX definition from config.h thing again. Note that 3 changes to 2 header files in our downloadable openal_cyg.tgz described in: http://baron.flightgear.org/pipermail/flightgear-devel/2005-March/035270.htm l needed to be applied before I could compile successfully. Could someone apply these to our tarball please? Cheers - Dave Index: simgear/ephemeris/ephemeris.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/ephemeris/ephemeris.cxx,v retrieving revision 1.3 diff -u -r1.3 ephemeris.cxx --- simgear/ephemeris/ephemeris.cxx 19 Nov 2004 21:44:16 - 1.3 +++ simgear/ephemeris/ephemeris.cxx 7 Oct 2005 09:06:49 - @@ -22,6 +22,9 @@ // // $Id: ephemeris.cxx,v 1.3 2004/11/19 21:44:16 curt Exp $ +#ifdef HAVE_CONFIG_H +# include +#endif #include Index: simgear/ephemeris/stardata.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/ephemeris/stardata.cxx,v retrieving revision 1.3 diff -u -r1.3 stardata.cxx --- simgear/ephemeris/stardata.cxx 19 Nov 2004 21:44:16 - 1.3 +++ simgear/ephemeris/stardata.cxx 7 Oct 2005 09:06:49 - @@ -21,6 +21,9 @@ // // $Id: stardata.cxx,v 1.3 2004/11/19 21:44:16 curt Exp $ +#ifdef HAVE_CONFIG_H +# include +#endif #include #include Index: simgear/io/decode_binobj.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/io/decode_binobj.cxx,v retrieving revision 1.2 diff -u -r1.2 decode_binobj.cxx --- simgear/io/decode_binobj.cxx31 Dec 2002 14:47:35 - 1.2 +++ simgear/io/decode_binobj.cxx7 Oct 2005 09:06:49 - @@ -1,3 +1,7 @@ +#ifdef HAVE_CONFIG_H +# include +#endif + #include #include Index: simgear/io/sg_socket_udp.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/io/sg_socket_udp.cxx,v retrieving revision 1.3 diff -u -r1.3 sg_socket_udp.cxx --- simgear/io/sg_socket_udp.cxx19 Nov 2004 21:44:16 - 1.3 +++ simgear/io/sg_socket_udp.cxx7 Oct 2005 09:06:49 - @@ -20,6 +20,9 @@ // // $Id: sg_socket_udp.cxx,v 1.3 2004/11/19 21:44:16 curt Exp $ +#ifdef HAVE_CONFIG_H +# include +#endif #include Index: simgear/scene/sky/moon.cxx === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/scene/sky/moon.cxx,v retrieving revision 1.6 diff -u -r1.6 moon.cxx --- simgear/scene/sky/moon.cxx 29 Jan 2004 18:25:55 - 1.6 +++ simgear/scene/sky/moon.cxx 7 Oct 2005 09:06:49 - @@ -24,6 +24,9 @@ // // $Id: moon.cxx,v 1.6 2004/01/29 18:25:55 ehofman Exp $ +#ifdef HAVE_CONFIG_H +# include +#endif #include Index: simgear/screen/shader.cpp === RCS file: /var/cvs/SimGear-0.3/SimGear/simgear/screen/shader.cpp,v retrieving revision 1.2 diff -u -r1.2 shader.cpp --- simgear/screen/shader.cpp 5 Sep 2005 08:17:38 - 1.2 +++ simgear/screen/shader.cpp 7 Oct 2005 09:06:50 - @@ -18,6 +18,9 @@ * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA */ +#ifdef HAVE_CONFIG_H +# include +#endif #include #include "shader.h" This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] CVS Weekly Snapshot (was RFC: FlightGear 0.9.9)
"Ampere K. Hardraade" writes: > On October 5, 2005 01:49 pm, Curtis L. Olson wrote: > > If someone wants to do this, and promises to keep up on it, I can put a > > link on the FG web site ... > > > > Curt. > > How should the version number progress? Should it be 0.9.9, 0.9.10, 0.9.11, > etc. or 0.9.9.1, 0.9.9.2, 0.9.9.3, etc? > Surely one done today would be 0.9.8-20051005 Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Flightgear-devel Digest, Vol 30, Issue 14
On 05/10/2005 at 13:59 Steve Knoblock wrote: > >The model looks good. Do you have a model number for the unit? It >looks like it says BendixKing. > Bendix-King KLN 89B. There is an online manual and PC simulator (Windows only) available - you'll have to google since I don't have the links to hand. Roy sent me his original SVG files of the KAP140 autopilot as a starter for the background - thanks Roy! >I would like to see how you designed the model of the GPS unit. >Whether and how you used NASAL script to implement its functions and >how much it relies on the existing GPS unit instrument model. > >I would like to know which properties you used, the standard GPS ones >or ones internal to your GPS unit model. Perhaps both. It's all C++ - no nasal. The buttons on the unit trigger callbacks that are registered with FlightGear's command handler. I made up a "special-instrument" catorgary that gets loaded as a FG subsystem when found in the panel xml file by the panel loader, but that may be subject to change depending on Curt/Erik's view of what I've done. > >The Digitrak needs a way to know if it is receiving a valid GPS >signal. I modeled this with a manually controlled switch, but I would >prefer that it be able to look to some standard property that would >tell it the GPS is functioning and has waypoints available. If the >standard GPS is the mechanism for the GPS faceplates, then I could >look to that. Otherwise, I would need to know where each individual >GPS unit's props are or there needs to be a standard property >established. > Currently it's not integrated with the existing GPS code. It uses some of it's properties - track, groundspeed and location, but doesn't populate it's waypoint tree. However, this is a temporary situation - I believe that whatever GPS unit is running should populate the standard GPS property tree, and provide an appropriate menu dialog. I agree with your previous comments about the desirability of the autopilot providing an appropriate menu dialog - currently for instance the radios dialog sets the frequencies on the panel nav radios, but the autopilot dialog doesn't work with the KAP140. This discrepency can only lead to user confusion. The core GPS logic (cross track error / waypoint sequencing rules / approach modes etc) are fairly well separated from the KLN series specific user interface details in what I've done. Once it's in and working I'll look to merge the GPS logic with the current GPS class, to turn it into a multi-waypoint, approach capable class, that can be accessed either through the menu dialog, or through the instrument user-interface simulation on the panel. >Of course, the GPS/NAV switch is not needed because the Digitrak only >accepts course information from. > From? I assume you mean it obtains either the desired course and cross track error, or the from/to waypoint locations for your own processing, directly from the GPS, in which case you'll need the GPS unit to populate the property tree as discussed above. If it simply follows the nav needle deflection then it should continue to work, since I've modified the navradio code to output the gps-commanded needle deflection to the nav cdi when /instrumentation/nav/slaved-to-gps is set true (by the NAV/GPS switch on the annunciator). >I look forward to trying your GPS unit when you release it. > >In addition, I would like to see the Digitrak included in the standard >distribution someday, once I resolve any copyright problems with the >face. Is the face complex? Why not just knock up a new one from scratch in gimp etc. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: FlightGear 0.9.9
On 03/10/2005 at 13:35 Melchior FRANZ wrote: >(C) which features need to be completed? I've got an approach-capable GPS simulation for the 2d Cessna panel almost finished that I'd like to get into the next release if at all possible. A few screenshots (view at native 1024x768 resolution for best clarity) during the GPS RWY 30 approach to Byron (C83) in the base package scenery. Real life approach chart at: http://www.airnav.com/depart?http://204.108.4.16/d-tpp/0510/09141G30.PDF Selecting the initial approach fix from the airport data pages: http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-001.png Climb out using Roy's excellent KAP140 autopilot. Nav1 is slaved to GPS with a full scale deflection (FSD) of 5nm at this point. The NAV/GPS button on the external annunciator switches the NAV1 needle deflection source between the nav1 radio and the gps unit. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-002.png Message annunciation at waypoint progression. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-003.png GPS goes into approach-arm mode automatically 30nm from the destination airport with an approach loaded. FSD changes to 1nm over a 30sec period. In real life approach-arm should be set before reaching PATYY for this approach using the GPS APR button on the external annunciator, but I haven't virtually wired that button up yet! http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-004.png 2nm from the final approach fix the GPS goes into approach-active mode if everything checks out. (Heading towards FAF, in leg mode - simulated, RAIM monitoring OK - not simulated - assumed OK!). FSD changes to 0.3nm over 30sec or the distance to the FAF, whichever is shorter. If you don't get the ACTV annunciation by the time the FAF is reached a missed approach should be flown. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-007.png First glimpse of the airport 150ft above the MDA and 1.4nm from the missed approach point. Make sure the threshold is properly and continuously in sight before transitioning to visual. http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-008.png Landing - we can ignore the instruments now :-) http://www.nottingham.ac.uk/~eazdluf/KLSN-C83-009.png Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFC: Move aero data to SimGear?
Hi folks, FlightGear currently contains a number of functions to provide an in-memory global representation of the Airport, navaid and com databases, and searchable access. This is only likely to grow as we add SUA, approach procedures, and whatever else (TACAN!). All the functions to load and search this data are implemented in FlightGear, but also duplicated in several other apps - Atlas, fgsd, TaxiDraw, TerraGear, possibly others? It seems to me that it would be a good idea to move the aero-dataset load and search functions out of FlightGear and into SimGear, so other apps can avoid re-implementing them. I realise that SimGear is described as a 'simulation kernel' and that the aviation database is rather aviation specific, but realistically the only programs that use SimGear are all FlightGear related. It wouldn't of course help the fact that FlightGear and Atlas running together on the same PC are both loading everything into memory, but I don't see a simple way round that right now. Thoughts, objections? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Never ending story: Building SimGear CVS under Cygwin
On 02/10/2005 at 04:21 Georg Vollnhals wrote: >Hi Dave, >I installed *all* Cygwin stuff after I got the first errors some time >ago because I did not really know what I need. >I reinstalled it all now before trying again > Graphics (one of many entries, but this should it be) > 2.2.0-1 169k freeglut: OpenSourced alternative to the OpenGL Utility >Toolkit (GLUT) library >but the error did not change afterwards. >Regards >Georg > Scroll down further in the graphics section - you'll find "opengl: OpenGL-related libraries", should be version 1.1.0-6. Make sure you've checked this, and it's possible you might need to install source for both it and freeglut. (There are separate bin and src check boxes - make sure you've checked the src one for opengl). Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Never ending story: Building SimGear CVS under Cygwin
Georg Vollnhals writes: > > RenderTexture.cpp:40: warning: ignoring #pragma warning > RenderTexture.cpp:66: warning: ignoring #pragma comment > RenderTexture.cpp: In member function `bool > RenderTexture::BeginCapture(RenderTexture*)': > RenderTexture.cpp:909: warning: unused variable 'bContextReset' > RenderTexture.cpp: In member function `void > RenderTexture::_ParseModeString(const char*, std::vector std::allocator >&, std::vector >&)': > RenderTexture.cpp:1295: error: `WGL_SAMPLE_BUFFERS_ARB' undeclared > (first use this function) > RenderTexture.cpp:1295: error: (Each undeclared identifier is reported > only once for each function it appears in.) > RenderTexture.cpp:1297: error: `WGL_SAMPLES_ARB' undeclared (first use > this function) > ../../simgear/screen/RenderTexture.h: In constructor > `RenderTexture::RenderTexture(int, int, bool, bool)': > ../../simgear/screen/RenderTexture.h:334: warning: > `RenderTexture::_bDoubleBuffered' will be initialized after > ../../simgear/screen/RenderTexture.h:333: warning: `bool > RenderTexture::_bFloat' > RenderTexture.cpp:2233: warning: when initialized here > make[3]: *** [RenderTexture.o] Error 1 > make[2]: *** [all-recursive] Error 1 > make[1]: *** [all] Error 2 > make: *** [all-recursive] Error 1 > Are you sure you installed openGL support when you installed Cygwin? It's not installed by default, but is definately needed. I think it's hidden away in the graphics section. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] help: making SimGear CVS under Cygwin
Georg Vollnhals writes: > Building SimGear CVS under Cygwin > > > > Then I went back to > > /usr/local/source/SimGearCVS > ./autogen.sh > Running aclocal > /usr/share/aclocal/libsmi.m4:8: warning: underquoted definition of > AM_PATH_LIBSMI > run info '(automake)Extending aclocal' > or see http://... > /usr/share/aclocal/cppunit.m4:4: warning: underquoted definition of > AM_PATH_CPPUNIT > Running autoheader > Running automake --add-missing > Running autoconf > > Now you are ready to run './configure' > > Try removing autom4te.cache and re-running autogen.sh. Not sure if this is your problem, but it often sorts out autotools problems for me. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] cygwin problems (was Re cvslogs etc)
On 16/09/2005 at 10:34 Vivian Meazza wrote: >Erik Hofman > >> Vivian Meazza wrote: >> >> > Er ... Erik are you about to break Cygwin again? >> >> BTW, form the openal (1.1) Changelog: >> >> * More fixes for Cygwin/MinGW compilation plus some #include cleanups. >> The "linux" subtree compiles now under Linux, MinGW/MSYS and Cygwin >> (with and without "-mno-cygwin"). >> >> Erik >> Fantastic :-) > >That sounds like really good news, but I hardly dare try - cvs has been >more >or less broken under Cygwin since mid Aug. There are work-arounds but > >Vivian > If you mean FG cvs, it's compiling and running fine for me under Cygwin at the moment, with the exception of a couple of files in the utils directory that are easily tweaked to work. I haven't updated Cygwin for a while though - it's gcc version 3.3.3. It's possible I'm carrying local mods though that I've forgotten about. What problems are you seeing? Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FGNav vs. FGNavRecord
There seem to be two very similar navaid classes currently existing in the src/Navaids directory - FGNav in nav.hxx and FGNavRecord in navrecord.hxx. Is any one of these preferred / due to be depreciated? (So I don't use the wrong one). Is there any reason for the duplication / change? (Just out of interest). Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Announcement: First TerraGear landcover database export
Dave Martin writes: > > I have a feeling as we get more road data, we're going to be seeing slight > placement errors at the airports. Currently EGBB is placed over the A45 on > the 0.9.8 scenery. If I can get that road mapped by GPS and a few others > around it, we can probably move the airport to its correct location. > EGBB is spot-on in it's placement - the vmap0 road data is far worse. If you map the road with GPS around the airport it will sort the problem there. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.3.2 released
Durk Talsma writes: > That's really great news! I just started working again on the AI ground > network code, and was wondering what the status was with respect to the move > to sourceforge/CVS. I started working version 0.3.0 and was wondering how we > should go about merging this with the current release. With cvs, I guess it's > going to be fairly easy to incrementally add my changes to the repository. > > FWIW, we probably need to think a bit about the changes to the fileformat > required to support the AI networking code. > There's an AI directory under src now so you can dump all your stuff in there. I'll sort out write access for you and Ralf when I get a chance. Ralf is working on adding polyline support to autogenerate the rectangles for curved taxiway sections. I'll sort out a taxidraw-devel list shortly as well to avoid plaguing the FG list with this stuff ;-) Internally, you can store your node-arc data structures separate from the airport data structure for now, and output them in whatever file format you decide for FG. Eventually, we might want to link the internal representation of physical and logical paths, since it might be possible to largely generate one from the other. Maybe! Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] FlightGear freezes (float point interrupt)
"Ampere K. Hardraade" writes: > Lately, my computer has been freezing on me unpredictably while I am using > FlightGear. (Note: I'm not saying FlightGear is to blame.) Normally, I just > cold boot the machine. Today however, after multiple freezes, I was too > angry to try again. I went away to do other things, and when I came back, > FlightGear seems to got killed by the kernel. When I relaunch FlightGear > later, I got a lot of this: > > Floating point interrupt (SIGFPE) > > Unfortunately, this was the only message I've got. > > I start FlightGear using the following command: > /usr/local/FlightGear/bin/fgfs > --fg-scenery=/usr/local/FlightGear/data/FlightGear/Scenery-0.9.8 > --aircraft=b1900d --airport=KSAC --bpp=24 --geometry=1280x600 --fov=69.9 > --multiplay=out,10,81.169.158.37,5002 --multiplay=in,10,192.168.0.194,5002 > --callsign=AMPERE --enable-real-weather-fetch --enable-clouds3d > A real stab in the dark this, but I solved a lot of random freezes in opengl apps and internal compiler errors from gcc by clearing a layer of compacted dust from the cpu cooler (Athlon). Alternatively, does FG freeze when you start it without all the options above? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw-0.3.2 released
TaxiDraw-0.3.2 has been released. This release is primarily to track changes in the X-Plane data format. TaxiDraw has also moved to SourceForge, and can now be found at http://taxidraw.sf.net. As a result, the latest code can now be obtained from CVS, hopefully making it easier for others to collaborate in further development. It also has an autotools-type configure/make system now instead of the buggy, hand-written makefile, so those compiling from source will need to use ./configure; make (or ./autogen.sh; ./configure; make if using CVS). Cheers - Dave New in version 0.3.2: * X-Plane v810 format is now supported. Additional notes on this are at the end of this list. * A bug where calibrated images were not reloaded with a project is now fixed (hopefully). * Turf runways are now coloured dark green. * An edit->select all option has been added, to allow an entire airport to be moved at once. You'll need to unlock runways first though to move everything! * TaxiDraw has moved to SourceForge, and has been put in CVS with a source code directory re-organisation. * An autotools system has been added instead of the hand-written makefile for the source build. Notes on the X-Plane v810 format support. = X-Plane v810 format is now supported, in addition to v715 format which was already supported. TaxiDraw will save or export the same format that was originally loaded for the airport being edited. Hence you cannot currently use it as a format converter, but can edit and save both formats. Missing glideslope angles for v810 runways or taxiways (the addition in v810) do not crash the program but instead are assumed to be zero. Hence you can convert a .dat file containing 1 custom airport from v715 to v810 by inserting 810 as the initial line of the file, and just putting in the angles for runways with glideslopes. The . for taxiway and other runway entries will be assumed by TaxiDraw, and written out properly on next save. Hopefully that makes some sort of sense! Data files containing more than one custom airport would have to have each airport loaded and re-exported to the file, since the data lines for the non-edited airports are simply passed through without editing. For .tpj files, 810 would need to be added immediately after the [AIRPORT] marker. As an alternative to adding 810, simply add a glideslope angle (. allowed) to the first runway line, and v810 will be assumed. Example: the v715 project in (a) will be saved identically to (a) if loaded and re-saved as is, but if changed to (b) OR (c) in a text editor and loaded in TaxiDraw will be resaved as (d). (a) [FORMAT] X-PLANE [END-FORMAT] [AIRPORT] 1138 0 1 EGBN Nottingham 10 52.919861 -001.077917 09x 88.37 3482 699.03970. 98 121121 01 0 1 0.25 1 10 52.919862 -001.076528 03x 28.83 26590.0. 75 11 01 0 1 0.25 1 10 52.919266 -001.080319 xxx 326.60 13200.0. 70 11 02 0 0 0.25 0 10 52.917795 -001.081165 xxx 326.604000.0. 80 11 02 0 0 0.25 0 14 52.918983 -001.080831 30.00 1 Tower Viewpoint 15 52.918991 -001.080431 238.00 EGBN Nottingham Ramp #1 18 52.920399 -001.077942 1 Light beacon 19 52.920265 -001.085859 1 Windsock 54 13487 A/G VOICE RDO (b) [FORMAT] X-PLANE [END-FORMAT] [AIRPORT] 810 1138 0 1 EGBN Nottingham 10 52.919861 -001.077917 09x 88.37 3482 699.03970. 98 121121 01 0 1 0.25 1 10 52.919862 -001.076528 03x 28.83 26590.0. 75 11 01 0 1 0.25 1 10 52.919266 -001.080319 xxx 326.60 13200.0. 70 11 02 0 0 0.25 0 10 52.917795 -001.081165 xxx 326.604000.0. 80 11 02 0 0 0.25 0 14 52.918983 -001.080831 30.00 1 Tower Viewpoint 15 52.918991 -001.080431 238.00 EGBN Nottingham Ramp #1 18 52.920399 -001.077942 1 Light beacon 19 52.920265 -001.085859 1 Windsock 54 13487 A/G VOICE RDO (c) [FORMAT] X-PLANE [END-FORMAT] [AIRPORT] 1138 0 1 EGBN Nottingham 10 52.919861 -001.077917 09x 88.37 3482 699.03970. 98 121121 01 0 1 0.25 1 . 10 52.919862 -001.076528 03x 28.83 26590.0. 75 11 01 0 1 0.25 1 10 52.919266 -001.080319 xxx 326.60 13200.0. 70 11 02 0 0 0.25 0 10 52.917795 -001.081165 xxx 326.604000.0. 80 11 02 0 0 0.25 0 14 52.918983 -001.080831 30.00 1 Tower Viewpoint 15 52.918991 -001.080431 238.00 EGBN Nottingham Ramp #1 18 52.920399 -001.077942 1 Light beacon 19 52.920265 -001.085859 1 Windsock 54 13487 A/G VOICE RDO (d) [FORMAT] X-PLANE [END-FORMAT] [AIRPORT] 1138 0 1 EGBN Nottingham 10 52.919861 -001.077917 09x 88.37 3482 699.03970. 98 121121 01 0 1 0.25 1 . 10 52.919862 -001.076528 03x 28.83 26590.0. 75 11 01 0 1 0.25 1 . 10 52.919266 -001.080319 xxx 326.60 13200.0
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Martin Spott writes: > David Luff wrote: > > > Can I jump-in here and say to everyone that updated airports should > > be sent to Robin Peel now. > > So I assume he accepted all changes that you've been collecting until > now ? > All of the one's I sent him, yes, which is about half of them, including all of yours. (Including the recent small airport additions in N Germany / Denmark ?). There was a slight problem with LCHM though - at the moment his data has your taxiways from v6 but the runways from v5, so they don't line up. I'll send it again and remind him about the runways! Hopefully I'll get rid of the rest of the data onto him by the time he updates again. Robin is using TaxiDraw himself now, as are a number of the regular X-Plane contributors, so there really should be no problem now :-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Linux Expo, UK
Christopher Horler writes: > Hi All, > > Although I've not recently been active, I've just spotted something. > > After last years success I was wondering if anyone was interested in > returning > to the .org Village again? > > This year I can bring some hardware. > > Hotel arrangements - If anyone needs a hotel, I might be able to help out. > I'd very much like to do another expo, but this year I might be simply too busy to find the time unfortunately :-( I can't even keep up with the mailing list. If you were doing it I'd try and make at least one day, but I simply can't commit any time in advance. It was great to meet up with everyone last time though - we ought to try it again one year. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Airport LFPO Paris Orly Update
Martin Spott writes: > Orly is a well-known airfield which means the location is vermy much > expected to be correct in the airport database. If the airport layout > is incorrect, then the best bet is to correct this with TaxiDraw and > send the result to David Luff. > Can I jump-in here and say to everyone that updated airports should be sent to Robin Peel now. Simply export your project in X-Plane format from the 'File' menu, and sent to to Robin: www.x-plane.org/home/robinp/Contact.htm I believe he can cope with TaxiDraw project format as well, and changed runways are no problem as long as you tell him. Now that he is reliably accepting our data again there is no need to store data ourselves - it's simply slowing my coding down. I guess it might become necessary again in the future if/when we extend the data format beyond what X-Plane offers, but we can cross that bridge when we come to it. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Harald JOHNSEN writes: > Oliver Schroeder wrote: > > >2) chat messages > >[...] > >protocoll supports chat-messages and the ATC-module has functions to queue > >and display them on screen. So it should'nt be too hard to combine them and > >enable chat-messages. Somebody willing to give it a try? > > > > > As Pigeon said, make that a separate window, because the ATC line is > allready nearly impossible > to read ;) It should not be hard to code but the atc code is not good > for that (anyway it does not > queue messages). > Correct - it's not intended to queue messages. Messages transmitted at the same time end up displayed on top of each other and appear garbled, much as messages transmitted at the same time probably sound garbled, screeched, or one non-existant in real life. All the message collision logic is in the ATC and AI units, which attempt to speak only when the frequency is clear. There are a few bugs in there, so sometimes garbled speech occurs! I do agree though that the basic ATC display can be nearly unreadable under some colour conditions - it's very much a quick hack ;-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TOWER
On 21/06/2005 at 12:20 [EMAIL PROTECTED] wrote: >Hi, > >1) I would like to disable the messages that appear on the TOP of screen, >the >tower control. > >Is there any property that I could set to disable it on FGFS 0.9.4? > fgfs --prop:"/sim/atc/enabled"=false Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain Replacments trough other sources
On 11/05/2005 at 09:50 Dave Culp wrote: >> "disused" airfields, > >OK, this would then not be the same as an airport that no longer exists? >I would think some people would have a problem with having these added to >the >scenery. > Airfields which still exist but are now disused can be submitted to Robin - there's some of those already. OTOH I'm not sure if TerraGear currently builds them or not. Airfields that don't physically exist anymore might be more problematic - I don't think he'd want to include those! It's not *that* hard to rebuild a few tiles of custom scenery oneself though. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ 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 04/05/2005 at 23:40 Melchior FRANZ wrote: * James Turner -- Wednesday 04 May 2005 23:14: >> 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 > Ditto Cygwin for long startup times. I've taken a look in the past, and loading the airport and nav data consumes the vast bulk of the time. This happens before any rendering (and before the splash-screen appears, which I assume Melchior's patch fixes). Melchior FRANZ wrote: > >I thought about a progress bar, or better: an info line that says: >"initializing navigation data", "initializing airport data", etc. >That entertains people a lot and makes the startup time appear shorter. > Excellent idea! Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [RFC] keyboard changes: warp/mixture
On 20/04/2005 at 12:20 Melchior FRANZ wrote: >Would anyone mind if I moved "increase/decrease warp" to w/W and use >m/M for "richer/leaner mixture"? > An excellent idea IMO. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: "material" animation (and the bo105 as an example)
On 24/03/2005 at 13:40 Melchior FRANZ wrote: >But >the rest of the paralyzed developers here need to be entertained! Or are >boring >threads like this the reason for the silence? ;-) > More likely the fact that spring has arrived in the Northern Hemisphere, where most FG developers reside. Which reminds me, I'm still sitting on your atan2 patch from ages ago! Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw-0.3.1 released.
Hi folks, I've put another version of TaxiDraw up at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html This is primarily a bug-fix release - a couple of X-Plane format writing bugs are fixed so all users should upgrade. Changes from 0.3.0: * Runway shoulders are now preserved when exporting to X-Plane format. * Several helipad runway codes that were not previously recognised are now recognised and preserved on export correctly. * A spurious warning when importing airports containing lakebed surface is fixed (eg. KEDW). * Airports that span UTM zone boundaries can now be displayed using UTM projection. * UTM zone can be manually changed by 1 when attempting to fetch USGS photography, since when a block of colour photography spans a UTM zone it is often projected using 1 zone only. * A bug is fixed whereby USGS photography was not displayed for airports containing 'X' in the code (eg. KLAX, KOXR). * The runway number of end 1 is displayed in the runway dialog title bar, in order to allow similar runways and helipads to be correctly identified. * Thanks are due to Austin Goudge for reporting many of the bugs fixed in this release, and on the TODO list for the next release. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Nav0/Nav1 course tracking and ILS approach code corrections
On 27/02/2005 at 22:51 Hans-Georg Wunder wrote: >Hi all, > >some days ago, I have made some proposals to correct errors in >flightgear. Now, I would like to know, Ãf this is the right >procedure to add code to the cvs or if there is an other way defined ?? > > The best way is to send it directly to either Curt or Erik. Curt prefers to be sent whole files, Erik prefers a unified diff against cvs (I think): cvs diff -u filename > patchname.diff Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 12/02/2005 at 22:31 Hans-Georg Wunder wrote: >One question I have: With the left key,I am able to move around on >the map. But then I destroy the flight track. Is it a bug or just a >missing feature ? > A bit of both, I guess. It won't be fixed for this release, but it irritates me as well, so I guess I'll eventually fix it if no-one does it sooner. > >The only thing I am missing is the multiplayer capability. Last week I >flew with my daughter, each on a Linux box. But it was very difficult to >fly together. Then I wanted to use atlas to have an overview, where we >are. But that doesn't work. I would be great to have to ports where >atlas is listening. > Hmm, I hadn't thought of that. I guess it shouldn't be too difficult, but once again, it won't make this release (unless you send in a patch ;-)). Support for multiple tracks, and separate colours per track, is something I'd like to add at some point since I'd like to use Atlas to visualise the AI traffic - it shouldn't be much of a stretch from that to listening on two ports. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] STL help requested
Christian Mayer writes:
> "The C++ Programming language 3rd ed." tells me:
>
> Basically you've got 2 options:
>
> 1 - create a class with the "<" operator
> class IACOcode
> {
>string the_code;
> }
> bool operator<( const IACOcode& a, const IACOcode& b )
> {
> return your ordering;
> }
> map apt_map;
>
>
> 2 - create a custom sort order
> class IACOcode_compare
> {
> public:
> bool operator()( const string& x, const string& y) const
> {
> return your ordering;
> }
> }
> map apt_map;
>
>
> Then you'll automatically get the desired result with your described lookup.
>
Thanks to everyone who replied. I can see how to do it now, but unfortuanately
it's now been complicated by the fact that the GPS unit appears to sometimes
consider letters before numbers (forward prediction of airports), but sometime
consider numbers before letters (scanning through the waypoint lists). It
seems that associative containers need the comparison operator specified at
creation (for good reason when I think about it) so I guess I'll just carry on
with my hack to avoid storing the data in memory twice.
Cheers - Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Fun with the FAA DOF.
On 31/01/2005 at 17:19 Chris Metzler wrote: >With building positions and heights from the FAA Digital Obstruction >File, and a few new buriable (thus, height-adjustable) models, here's >an approach into La Guardia Rwy 04, starting over Staten Island. > >http://www.speakeasy.org/~cmetzler/KLGA_04_approach_001.jpg > >thru > >http://www.speakeasy.org/~cmetzler/KLGA_04_approach_023.jpg > >Some highlights: > >lower manhattan and downtown brooklyn start to come into view -- >http://www.speakeasy.org/~cmetzler/KLGA_04_approach_003.jpg > That looks really, really good! I think that having realistic default buildings for US downtown areas will make a huge difference to how newcomers percieve FlightGear - they're pretty major landmarks. I'm looking forward to seeing them propogate into the default scenery, hopefully before v1.0 gets released. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] STL help requested
Hi folks,
I've run into a tricky problem when using stl map, and am hoping someone might
be able to point me on the right direction.
I have a map of airports, indexed by string, which is the ICAO code:
map apt_map;
Now, I want to emulate the 'search ahead' function of GPS code entry, so that,
for instance, entering "KC" will cause "KCAD" to be displayed - the first
airport in the database starting with "KC". To do this I use the lower_bound
function, for both "KC" and "KD". If the returned iterators don't match, then
there is a valid match for "KC".
map::iterator it1, it2;
it1 = apt_map.lower_bound("KC");
it2 = apt_map.lower_bound("KD");
return(it1 == it2 ? NULL : it1->second);
So far, so good. Now, the problem is that the KLN89 (and probably most/all GPS
units) regards A->Z as coming before 0->9, whereas the standard string compare
function regards 0->9 as coming before A->Z. So in this instance I might get
"KC52" displayed instead of "KCAD" (there isn't really a KC52, but there are
many examples outside the US where this bites).
Now, I can get round this by using a comparison of lower_bound tests for "KC",
"KCA" and "KD", and it works. Unfortunately I then have to check for non-alpha
chars down to the end of the returned string, and re-test any with 'A'
substituted in place. It's effective, but really ugly! I had to think quite
hard about code I only wrote a week ago to compose the last sentence, and
that's always a bad sign. What I'm sure I ought to be able to do is to define
a custom comparison operator that performs a string comparison where numbers
are considered to come after letters, and for good measure to do a
case-insensitive match on the letters. I want to be able to do something like:
it1 = apt_map.lower_bound("KC", gps_less);
with all the ugly bits tucked away in gps_less which I can get working and them
forget about. Unfortunately, I can't find any good example in any of my books
to do this, nor on the internet, and everything I try is giving me swathes of
typical gruesome-to-mentally-parse stl error messages. If anyone has an
example of how to do this, or any pointers to one, I'd be most grateful.
Cheers - Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Simgear-cvs
On 02/02/2005 at 09:11 Vivian Meazza wrote: >I'm having a problem compiling Simgear-cvs under Cygwin. The compiler > >I would suppose that this is a consequence of Erik's latest improvements to >the sound. We Cygwin users are still using Norman Vine's OpenAL stuff. > >Any advice on fixing this? You need the following patch to alc.h (one of the files in Norman's tarball). According to Erik this alteration is in OpenAL CVS - I guess we should update the tarball. Cheers - Dave $ diff -u alc.old.h alc.h --- alc.old.h 2005-01-31 15:20:33.785550400 + +++ alc.h 2005-01-31 15:17:49.299030400 + @@ -17,7 +17,7 @@ #define ALCAPI __declspec(dllimport) #endif -#ifdef _MSC_VER +#ifdef _WIN32 typedef struct ALCdevice_struct ALCdevice; typedef struct ALCcontext_struct ALCcontext; #endif This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ 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 01/02/2005 at 11:45 James Turner wrote: > >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. > Atlas currently contains a copy of the SimGear render-to-texture code (to avoid depending on SimGear CVS) - you could possibly get this working in Atlas if FG won't start for you - and then it should also work in SimGear/FlightGear. >Question, though : what is FG using render-to-texture *for*? > Atlas is using render-to-texture to avoid image corruption due to overlaid windows, and to allow the creation of images larger than the screen resolution (on some hardware). I don't know what Erik has in mind, but I think that render-to-texture would be useful in FG for procedurally drawing complex 2D images into a texture in real-time (eg. gps unit / glass cockpit display), and then using that to texture a 3D instrument face. I have an inkling in the back of my mind that it might also possibly be useful for drawing impostors for the 3D cloud rendering, but that's just a wild guess. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
David Luff writes: > Lee Elliott writes: > > > > > I'm using an ATI 9200 vid card with ATI's drivers and I'm > > getting: > > > > Seaching for extensions... > > GLX_SGIX_fbconfig: NO > > GLX_SGIX_pbuffer: NO > > > > One or more required extension(s) could not be found: > > GLX_SGIX_fbconfig > > GLX_SGIX_pbuffer > > Unable to continue in headless mode - revert to doublebuffer > > mode? [Y/n] > > > > if I try to use --headless mode:( > > > > Seems ok if I render to a screen though. > > > > Hi Lee, > > Could you post the output of glxinfo please? > > I've tested this on Radeon 7200 + DRI drivers, and GeForce 5900XT + NVidia > binary drivers on Linux, but never on ATI's binary Linux drivers. It's quite > possible that they've omitted support for GLX extensions entirely, but it's > also conceivable that they might have used a different name - the output from > glxinfo might enlighten us. > Umm, a google around indicates that they don't support GLX_SGIX_pbuffer & fbconfig, but offer GLX_ATI_render_texture instead: http://www.gamedev.net/community/forums/topic.asp?topic_id=191510 I believe that Fred has got a cross-platform render-texture library to work with Map in order to extend headless mode to windows - hopefully this will be more robust than the code that I wrote and work across a greater range of cards on Linux as well. I'll make up another release candidate when it's added. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
Lee Elliott writes: > > I'm using an ATI 9200 vid card with ATI's drivers and I'm > getting: > > Seaching for extensions... > GLX_SGIX_fbconfig: NO > GLX_SGIX_pbuffer: NO > > One or more required extension(s) could not be found: > GLX_SGIX_fbconfig > GLX_SGIX_pbuffer > Unable to continue in headless mode - revert to doublebuffer > mode? [Y/n] > > if I try to use --headless mode:( > > Seems ok if I render to a screen though. > Hi Lee, Could you post the output of glxinfo please? I've tested this on Radeon 7200 + DRI drivers, and GeForce 5900XT + NVidia binary drivers on Linux, but never on ATI's binary Linux drivers. It's quite possible that they've omitted support for GLX extensions entirely, but it's also conceivable that they might have used a different name - the output from glxinfo might enlighten us. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 28/01/2005 at 17:55 Jon Stockill wrote: >It builds ok on Slackware Linux 10.0, --headless seems to work ok with >Map - I'm running it remotely at the moment. I'll test the Atlas app >when I get home and it finishes building the maps. > >One thing it is showing up is quite a few missing scenery tiles in the >0.9.8 scenery. > Yes, there's one just north of Cambridge. I checked, and it is a definite missing scenery tile, not a Map/Atlas error. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 28/01/2005 at 09:15 Adam Dershowitz wrote: >I have never tried to build Atlas before, but just tried with this >release. >I am working on a Mac and ./configure gives me the following errors: > >checking for pthread_exit in -lpthread... yes >checking for glNewList in -lGLcore... no >checking for glNewList in -lGL... yes >checking for gluLookAt in -lGLU... yes >checking for glutGetModifiers in -lglut... no >checking for glutGameModeString in -lglut... no > >Unable to find the necessary OpenGL or GLUT libraries. >See config.log for automated test details and results ... > >In order to build flightgear, a little while ago, it was necessary to make >a >few changes to the source code to get it to properly find GLUT stuff. But >these changes are now all incorporated into FG. These locations are now >all >captured in simgear/compiler.h. >In the time that I have been working with the code, no changes were >required >to the config stuff, only some of the paths in the source itself, now in >compiler.h. >The truth is that I have not done much with automake, so I am not really >sure how to go about fixing this. But clearly something is different in >how >Atlas checks for GLUT versus how Simgear and FG do it, since they succeed >just fine in finding and using that stuff. >If you can point me in the right direction I can try to work with it some >more. > Hi Adam, I'm afraid I don't use a Mac, and I'm not good with shell or configure scripts. If you want to have a try at fixing this, then configure.ac is the file you need to edit (try looking in FlightGear's configure.ac for inspiration), and you'll need to run ./autogen.sh before ./configure after making any changes to configure.ac. Unfortunately, the whole glut/gl section of the Atlas/FlightGear configure.ac files appears to be somewhat different - I don't think it's a matter of just dropping a mac test in from the FG one to the Atlas one. It really needs someone who know's what they're doing in this area to take a look at it. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Atlas release candidate
On 28/01/2005 at 15:34 Roberto Inzerillo wrote: > >Do you think there will be some Win32 binary too? It would be very nice :-) > >I don't know if it's even possible (I didn't look into the code in order to >determine if libraries and the source itself is portable) but I really hope >so. > > A windows binary of the code a few weeks ago is here: ftp://ftp.ihg.uni-duisburg.de/FlightGear/Win32/atlas-win32-20050112.zip courtesy of Fred Bouvier. Hopefully he will produce a release binary as well. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Atlas release candidate
Hi all, I've put a release candidate of Atlas-0.3 up at: http://www.nottingham.ac.uk/~eazdluf/Atlas-0.3.0-rc1.tar.gz If a few folk could take the time to download this and try it out that would be great. Changes in the last year or so: * Now reads FG-0.9.8 airport and navaid formats * Atlas now displays ILS localisers * Map has an off-screen rendering option (--headless) to avoid image corruption due to overlaid windows and possibly allow maps greater than screen resolution depending on graphics hardware and drivers [X-Windows with fairly modern GLX only at present] * Map supports multiple scenery paths via FG_SCENERY or --fg-scenery= (only Map at present, not MapPS). * Atlas has --airport=ICAO startup option. * Bug fixes. Note that Atlas/Map is written by Per Liedman and others, not myself, but Per is unable to maintain it at the moment. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On 28/01/2005 at 00:00 Paul Surgeon wrote: >On Thursday, 27 January 2005 20:47, David Luff wrote: >> Note that the EGLL poly count is already >> hitting my frame rate to begin with - at daytime it's about 60 with view >> away from airport, 30 with view including airport. Then 10 with the >> lighting added. The frame rate with lighting enabled at EGLL is >completely >> independent of anisotropic filtering, FSAA, or screen resolution - it's >> pegged solidly at 10. I guess it's either CPU or AGP bus limited - any >way >> to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. > >Is this with or without enhanced runway lighting enabled? > This is with the standard runway lighting. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Runway lighting
On 27/01/2005 at 12:19 Curtis L. Olson wrote: > < snip rwy lights are dropping the frame rate > > >Any ideas? > Not on the technical side, but one thing we could do now is to ditch the green taxiway center lights. These aren't specified in the new format apt data, and the latest build has defaulted to enabling them for all taxiways that have edge lights. If we switch them off for the next scenery build, then the majority of smaller airports will probably be more accurate (ie. they shouldn't have them anyway), and the larger airports will gain a framerate boost at the expense of missing the green lights that might exist in real life. Currently the lighting at EGLL or KSFO drops my frame rate from around 30 to about 10. Based on a rough estimate of light numbers, I reckon that ditching the green taxiway centerlights might get back 3 - 4 fps, not brilliant but a start. Note that the EGLL poly count is already hitting my frame rate to begin with - at daytime it's about 60 with view away from airport, 30 with view including airport. Then 10 with the lighting added. The frame rate with lighting enabled at EGLL is completely independent of anisotropic filtering, FSAA, or screen resolution - it's pegged solidly at 10. I guess it's either CPU or AGP bus limited - any way to try and find out / guess which? [AMD XP2000+, GF5900XT 128M, 4x AGP]. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Terrain elevation question
On 24/01/2005 at 21:17 Durk Talsma wrote: > >What I am really looking for is a hint where I can find the code in >FlightGear Hi Durk, I obtain ground elevation for taxiing AI traffic in AILocalTraffic.cxx, lines 1569 - 1602 (or thereabouts). Note that this is not a cheap operation, and you should only do it for traffic in a location which already has a tile loaded - otherwise it triggers tile loading, resets the scenery cache to the wrong location, and probably has other undesirable side effects as well. I'm still not entirely sure how all this works, but when I dug into it once it seems that the way I do it can mess with the tile cache unless I'm not determining elevation for the tile currently at the center of the cache (or something like that). FG could really do with a clear, unambiguous, documentated elevation API of the GetGroundElevation(lat, lon) type that would not mess with the tile cache, and not bother giving accurate elevations for unloaded tiles. Until then, a lot of subsystem writers have / will spend a significant amount of time figuring out how to get a ground elev, and wondering what they're breaking whilst doing it. As Curt says, regardless of the above, ground elev will always be expensive - if the airport has a node arc layout you could dynamically cache lookups for following traffic, interpolate between reasonable differences, etc, etc. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Possible config (file type) problem?
William Earnest writes: > Hello, > > This morning the 0.9.8 package in WinXP, running normal defaults > (KSFO, c172p) starts with all instruments normal. The current CVS > compiled here in Fedora 3 is much the same, but sitting on 24R, the DG > looks as expected, but the mag compass is showing North. Is some xml > file dropping the bearing info? > Warning - the following is just a wild guess. I think that this might be due to excessive side forces reported by JSBSim when the aircraft is stationary. This results in the instrument physics code 'locking' the compass as though it was forced to the side of the cage until the force subsides. Once you start rolling down the runway the compass unlocks, but it's a pain for setting the DG when stationary. That's my guess as to what's happening - I could be completely off base, but it doesn't seem to affect yasim models IIRC. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On 21/01/2005 at 20:04 Durk Talsma wrote: >So time permitting I wouldn't mind having a stab at porting (some of) your >code to interact with the AIModel system, it that is okay with you. As I >mentioned yesterday, the taxiway code comes to mind. This approach might >actually be mutually benificial, if this would free up some time for you >to >work on taxidraw. Eventually, we need data for the AI system, such as, >taxiways and parkings/gates and taxidraw would be an ideal tool for that. >Let >me know what you think. > Yes, in principle that's fine by me. I'd like to keep the ATC system itself in it's own directory, but I'm happy for a significant portion, or possibly all of, the AI code to move over, and for you to 'take ownership' of it. I'm not sure how far you want to go in moving it over - some of the stuff is very AI/ATC interaction specific, such as the logic to fly circuits, respond to ATC instructions, and alter the circuit pattern in response to the user position (in theory anyway - one of the little blighters on downwind the other day was instructed by ATC to follow me in whilst I was about 2 mile final on straight-in. At about 1 mile final he cut in front of me, and caused me to get told to go around after taking a shade too long to clear the runway!). I'll have a mull over it this w/e and have a think about where a good cut-off point might be, and what API the AIModel code will need to expose to allow the 'intelligent AI' to continue to do what it does if left in the AI/ATC branch. Certainly, taxiing and 3D model creation and management would be good candidates for moving over to AIModels initially, leaving the heuristic GA generator and the circuit-flying/tower control interaction portions in the AI/ATC for now. The AIModel code would need to expose an API for the heuristic generator to call to generate appropriate traffic, and another API for the 'intelligent-flying' code to have sufficient control of the plane. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On 21/01/2005 at 18:02 Jim Wilson wrote: >David Luff said: > >> Hi all, >> >> I've commited a fix for the program crash when the piper model is not >> present, and apologise for that. Would a v0.9.8a release be in order? > >Just the base package maybe? Weren't there some file permission issues >too? > If it's just the base package then you'll need to re-add the pa28-161 - I've patched the source to be tolerant to it's non-existance. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] AI piper load fix - v0.9.8a needed?
On 21/01/2005 at 18:38 Durk Talsma wrote: >On Friday 21 January 2005 16:51, David Luff wrote: >> I'd like to overhaul my loading of GA aircraft models properly - instead >of >> pulling them out of the installed aircraft, I think some dedicated AI >> models should be available to help avoid this kind of problem. Dave >Martin >> - do I remember you saying that you had done / intended to do low-poly >> count versions of the pa28 and c172 at some point? If so, they would be >> very useful. >> >David, earlier, I seemed to remember that you were leaning toward >integrating >your AI/ATC code with Dave Culp's AIModel code. In the light of this, >wouldn't it be a more feasable approach to start thinking about ways to do >this and eventually phase out your model animation code? I'm not >suggesting >you should do this, but in the light of your earlier mail, it would seem a >logical step. Any thoughts? > Yes, I'm still inclined to go this way (integration), but haven't had the chance to dig into the AIModel code yet. The comments above were intended to be somewhat generic, to be implemented in whatever method/branch I wind up using. I guess I can comment more inteligently on this without the risk of suggesting stuff that already exists once I've had a good dig into the AIModel code, so I'll go and take a look... Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AI piper load fix - v0.9.8a needed?
Hi all, I've commited a fix for the program crash when the piper model is not present, and apologise for that. Would a v0.9.8a release be in order? The current package almost certainly crashes for everyone who doesn't have an existing base package or extra aircraft installed, and Frederic's fix of the surplus radio towers in downtown SFO is pretty important too. I'd like to overhaul my loading of GA aircraft models properly - instead of pulling them out of the installed aircraft, I think some dedicated AI models should be available to help avoid this kind of problem. Dave Martin - do I remember you saying that you had done / intended to do low-poly count versions of the pa28 and c172 at some point? If so, they would be very useful. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] menu problems (was v1.0 musings)
On 20/01/2005 at 19:42 Stewart Andreason wrote: >I've had my attitude indicator on the panel get stuck 30 degrees off >level, and Debug.Reload Panel doesn't reset it. Something else perhaps >is... broken as a feature? Once again, Reset doesn't fix it. > This is a feature - apparently uncaged gyros really do this in real-life at, erm, attitudes and accelerations outside of the 'normal' flight envelope - aerobatic aircraft have special gyros to avoid this. It gradually comes back after 5 minutes or so. I don't think that debug.reload panel should reset it - that's designed to reload the textures and instrument models to aid panel development I think - not to override the instrument physics and output. It ought to be re-set to it's initial, working, condition during a reset though. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] fgrun improvements
On 21/01/2005 at 13:16 Frederic Bouvier wrote: >To bring fgrun to 1.0 quality grade, and after receiving suggestions from >Curt, >I am now planning to add basic options to the wizard instead of keeping >them >hidden behind the Advanced button. Maybe by reducing the size of the >command >line textfield ( it could also be move to the Advanced section ). > >For the moment, my shortlist for basic options is : > >--geometry ( with a combo box of standard resolutions ) >--time-of-day >--(en/dis)able-game-mode >--(en/dis)able-random-objects >--(en/dis)able-ai-models >--(en/dis)able-auto-coordination >--(en/dis)able-real-weather-fetch >--(en/dis)able-horizon-effect >--(en/dis)able-enhanced-lighting >--(en/dis)able-specular-highlight > >and optionally >--atlas ( with default options ) >--3d-clouds ( perhaps. they are not finished but are sometimes gorgeous ) >--multiplayer > >I also want to have better resizing to have a more professional look. > >Also it would be nice to be able to fetch and install aircraft and scenery >directly from the master server ( a "add new" button that connect via http >). >Maybe it would require that the script that generate the aircraft download >page >also generate an XML file that could be remotely parsed to ease aircraft >selection. > >Comments welcome > It would be nice if fgrun could detect when Map/Atlas were installed, and have an option to create the maps of the installed scenery using Map (with a warning that this might take a while!). Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] aircraft required to start
On 21/01/2005 at 10:05 Jim Wilson wrote: >Frederic Bouvier said: > >> Stewart Andreason a écrit : >> >> > It seems this aircraft is required to start FlightGear. >> > >> > > fgfs >> > >> > WARNING: ssgLoadAC: Failed to open >> > '/usr/local/share/FlightGear/data/Aircraft/pa28-161/Models/pa28-161.ac' >> > for reading >> > Abort >> > >> This plane is required by the AI/ATC module and has been removed from >> the standard distribution. It is available on the website though. >> > >Any chance the AI could be intelligent enough to silently load a different >model or skip it altogether if the ac file isn't there? > That would make sense. I've never worked with exceptions before - only failure indicated by function return value. What's the general gist - if I wrap my call to the load aircraft function in try.. catch blocks and then handle the exception will it stop the "Failed to load aircraft" and "Abort" messages currently getting to teh screen? Oh, and BTW, the reason the AI system initialises even when turned off is so that the user can turn on the traffic from the AI/ATC menu whilst running the sim. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] Aircraft included in base package
On 20/01/2005 at 10:55 Jon Berndt wrote: >> Ok wrong word. Let me just say that it seems to lack some magic. >Setting up >> the p51d in Yasim was not my original intention as Jon S. Berdnt was >claiming >> at the time I started the 3D that he had a nearly working JSBSim model. > > ... which I did. I thought. The more I looked at the numbers for aero >qualities that I >was getting from DATCOM, the more I realized something was amiss. Also, at >the time I >believe our engine capabilities were not what I thought they were. Now we >have a >turbocharged piston engine model. You should consider the turbocharging to be an alpha model though - we haven't applied it in anger yet. When you start on a P51 or Spitfire (or any other model) give me a heads up and I'll test/refine/debug the turbo/supercharging stuff in tandem with what you're doing. Cheers - Dave This message has been checked for viruses but the contents of an attachment may still contain software viruses, which could damage your computer system: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Windsocks
David Megginson writes: > OK, thanks for the replies to all who responded. It's clarified things quite a bit. FWIW, I'm not trying to alter the automatic windsock generation, simply tidying up stuff like windsock placement for the airport layouts that I did whilst testing TaxiDraw, before sending them in to Robin. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] TaxiDraw-0.3.0 released
On 1/6/05 at 5:11 PM Martin Spott wrote: >"David Luff" wrote: >> TaxiDraw-0.3.0 is now released. It can be found at >> http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. > >Thanks, David, this release apperars to be very 'handsome' ! >Here are 'your' binaries: > > ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/README.strange-binaries > ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/taxidraw-0.3.0-FreeBSD.bz2 > ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/taxidraw-0.3.0-IRIX.bz2 > ftp://ftp.uni-duisburg.de/FlightGear/TaxiDraw/taxidraw-0.3.0-SolSparc.bz2 > Thanks Martin, I've now updated the web page. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] View window with 2d panel
When using the 2D panel, it appears that the view window to the outside world gets shifted up and down depending on whether the panel is visible or not (try viewing slightly left or right and then back straight again to see it). This appears to be done without changing the position of the eyepoint relative to the 3D scene (the perspective and distance to the runway remain the same. Can anyone enlighten me as to how this is done, where in the code I can find it, and if it's governed by any properties? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Windsocks
Can anyone who flies in the US tell me how prolific windsocks at GA airports actually are. Currently we get one at each end of the runway by default in the airport data, but I'm wondering if that's generally overkill? If an airport has a segmented circle (nicely visible from aerial photos) is that where the windsock is usually located? Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] TaxiDraw-0.3.0 released
TaxiDraw-0.3.0 is now released. It can be found at http://www.nottingham.ac.uk/~eazdluf/taxidraw.html. The brief changelog is as follows: *** * libcurl is used for download instead of relying on the presence of wget. * Downloaded USGS images are used as multiple tiles instead of concatenating them. As a result, the presence of ImageMagick is no longer required. * As a result of the above two changes, USGS image downloading is now enabled in the Windows binary. * The USGS image downloader first checks for colour imagery, and then reverts to black and white imagery if colour is not available. * A scrolled canvas is now used, giving a more standard feel to moving the airport around than previously. * Seaplane bases can now be opened, edited and written. * Stopways are now displayed. * Threshold position is now displayed for displaced thresholds. * Beacons can now be added and deleted. * Windsocks and tower viewpoint position are now displayed and editable, include add and delete (maximum of 1 tower viewpoint position per airport). * An airport properties dialog is available allowing the airport properties to be edited. * The runways properties dialog is greatly extended allowing all runway properties to be edited. * Insert Taxiway shortcut is changed from T to Ctrl+T. * Cygwin fixes from Bruce Finney. * The windows binary release now uses a proper installer (thanks to Inno-setup). * Menu items are now greyed out when not logically available. (Most of them - some still need to be done such as undo/redo). * Probably more stuff that I can't remember! *** Note the change from wget to libcurl for downloading. This means that folk compiling TaxiDraw will need development libraries for libcurl installed. It's a pretty ubiquitous library though, and shouldn't cause any problems. Some of the 'improvements' can cause some problems. The downloaded images are now handled as tiles, which makes operation at high zoom levels much better, but there can be slight pauses during panning as tiles are loaded/unloaded. The scrolled window can also cause some problems - on Linux it can cause flicker during zoom and sometimes whilst dragging taxiways, and on all platforms the view position can sometimes move whilst trying to drag large taxiways (just the view position, *not* the actual airport position). I'm sure most of the glitches will eventually be ironed out. On non-windows platforms it is possible to revert to the old non-scrolled-window code by undefining _TD_SCROLLED_WINDOW in TaxiDraw.h. I'm gradually removing support for the old FlightGear airport data format. It will no longer export to it, although it will still read it. Note that exporting to X-Plane format now merges with the specified file if the file already exists - only the target airport is overwritten, the rest are left unchanged. This is to avoid upsetting X-Plane users who are used to exporting to apt.dat from WorldMaker. At this point TaxiDraw is pretty much feature-complete as far as editing the current airport data format goes, IMHO. I'm sure there's loads more refinement that could be done to it, but I'm going to try and spend more time on stuff that will be progress to FlightGear now, rather than stuff that simply extends what we already have (which realistically is all TaxiDraw does at present - it is/does nothing new, but is simply a convienience tool). Stuff that springs to mind includes extending the range of 2D objects - for example allowing airport boundaries to be defined, and allowing simple hangars to be defined. I think in the long run I'd like to move TaxiDraw's airport definitions over to a node-arc arrangement, from which both physical layout in our current (or future format) and also logical taxying information could be exported. This would also probably make it easier to build better airports with a modified genapts. I'm also very keen to announce TaxiDraw to X-Plane users in the near future, since I feel that our voice might get heard a little louder with regards to the airport data format if we get used by the X-Plane community. I think that the current release has reached a point where it's pretty easy to figure out, and should be OK for WorldMaker users to try without too much hassle. So if you find any critical bugs in the next week or so, please let me know ASAP before I do this. As always, back up your data before using new software... Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib release
"Curtis L. Olson" writes: > David Luff wrote: > >Wow, is that what it's meant to look like? Most of the instruments are > >holes through to the runway on the dhc2, the b1900d and the Citation for me > >on both Cygwin/ATI and Linux/NVidia OS/hardware combinations. I'd always > >assumed they were works-in-progress. FWIW, they all spew a few 'no element > >found' and 'not well-formed' messages as well - I wonder if that's related > >to the problem? > > > > > > What version of plib are you running? I'm running 1.8.3 (latest > release) here and have never noticed any problems with any of the > versions of these aircraft. (They are really well done by the way.) > Latest CVS. Forget the error messages I mentioned BTW - they were caused by an unrelated local issue. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] plib release
On 1/5/05 at 4:17 PM Martin Spott wrote: >Jon Stockill wrote: >> Curtis L. Olson wrote: > >>> I've never noticed any holes in the instrument panels of either of >>> these. How about the Citation-II that looks good here too, but is by >>> the same author ... (?) >> >> I'll try it when I get home, and grab some screenshots. > >The DHC2 looks good now: > > http://document.ihg.uni-duisburg.de/bitmap/FGFS/DHC2_01.jpg > Wow, is that what it's meant to look like? Most of the instruments are holes through to the runway on the dhc2, the b1900d and the Citation for me on both Cygwin/ATI and Linux/NVidia OS/hardware combinations. I'd always assumed they were works-in-progress. FWIW, they all spew a few 'no element found' and 'not well-formed' messages as well - I wonder if that's related to the problem? Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 3D instrument kit.
Martin Spott writes: > I believe there are platforms out in the wild, even not that up to > date, that won't be hit that much by ploygon count I myself would > love to try it out in order to see how much the polygon count has > influence on the frame rate. > I think you might be very right there. I used to think that my Radeon 7200 was getting hit by polygon count with complex airports and the recent 3d airport furniture, but it turns out that it's lights that kill it - get a vasi or papi in view and the framerate plummets from the twenties into single figures, whereas even complex airports with no glideslope lighting have neglible effect. I suspect it's the beacon lights rather than poly count that kill it as well. My Geforce3 ti200 by contrast is completely unaffected by the lights. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] X-plane airport data
Paul Surgeon writes: > I need country and state/province fields to be included in the X-Plane data > so > that I can sort and filter airports by country and state/province. > > I thought of filtering by ICAO but that is not 100% accurate because 3 letter > IATA codes are GLOBAL. (e.g. London Heathrow = LHR) > If it was just the 3 letter FAA codes it would have been easy. The airport database uses ICAO codes, not IATA codes - Heathrow is EGLL. In the US the codes are the same, but for the rest of the world they are (always?) different. I'm not sure, but I'll hazard a guess that US airports might be the only ones in our database with 3 letter codes. > This will also not provide me with state/province filtering which I would > like > to include. > > The DAFIF data does include country codes as well as state/province codes per > airport. > > Will we need this data in FG in the future? I'd certainly like to see our airport selector use country and possibly state/province - it's pretty unusable at present (even if it did work) due to the sheer size of the database and the usability problems with the widget (no response to arrow keys, page up/down, mouse wheel, typing first letter of name etc). I hadn't realised that state/province info was in the DAFIF - that's a pleasant surprise :-) > My app is standalone so I can write my own DB's but I prefer to derive all my > data from FG otherwise one usually ends up with conflicting data when one DB > is not kept in sync with the other. > > What's the best way to go about this? > Should we : > 1. modify our X-Plane database and include the fields and sit (yet again) > with > a non-X-Plane DB or > 2. get Robin to include it in the main X-Plane airport database or > 3. create an entirely new file to store the data in? > 2 would be ideal, but almost certainly subject to a time lag. It might be best to ask Curt if he'll approach Robin with it for the best chance of success. However, either 1 or 3 would be good stop-gap measures to get you/us up and running until then. I believe that we can assume that codes above 500 may be safetly used for FG use without conflict - maybe you could write a script that merges the country/province data with the master data using a couple of codes up in that range for now? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Real weather fetch
Dave Martin writes: > > ps: David you have Mail (taxiways). > OK, great. If they've gone to my nottingham.ac.uk address I won't get them until tomorrow, but I'll make sure I pick them up then. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] RFC: Set starting runway into wind?
David Luff writes: > ... the patch below ... Note that the patch requires a recent CVS update to work - the runway search code was fixed a couple of days ago. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Real weather fetch
I tried out the real weather fetch option for the first time yesterday. It's absolutely excellent! It just worked, with no setup or bother, and gave the correct weather in Chicago according to the forcast, and the correct weather in Nottingham according to the view out of the window. I'm afraid I can't recall who is responsible for this - I can't always keep up with all the list traffic, but whoever it was - thanks :-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] RFC: Set starting runway into wind?
Gentlemen,
It really irritates me that the starting runway is always set closest to
270degrees instead of into the wind when the [EMAIL PROTECTED] or --random-wind
options are used, unless --heading= or --runway= is specified explicity. The
patch below fixes that, but it also has one side-effect, so I guess I'd better
throw it open for discussion before sending it to Curt.
The side-effect is that when wind or random-wind is specifed explicitly (either
in .fgfsrc or on the commandline), then it becomes impossible to specify a
crosswind runway using the --heading= option. It *is* however possible to
specify a crosswind or specific runway using the --runway= option. So the only
change is that you now need to know the runway number instead of the general
heading. The heading option still works fine when the starting location has no
connection with a runway.
Personally I think the change is worthwhile. Currently one must use the
--heading= or --runway= option with the --wind= option in order to get a
sensible runway, and there is no way I know of to set a sensible runway with
--random-wind. With the patch a sensible runway is automatically set with the
--wind= or --random-wind options, and can be overridden with the --runway=
option.
Note that this doesn't work with the --enable-real-weather-fetch option - this
is completely unaffected. I'd love to get the starting runway set sensibly
with this option, but it's tricky. It seems to me that first general location
must be initialised to get the correct weather, then the environment system
needs to be initialised, and finally specific position needs to be set to get
the correct runway. Ie runway depends on weather which depends on location.
At the moment I'm stumped on getting the environment fully up and running
during init - I can't seem to force an update of the relevent environment_ctrl.
Cheers - Dave
$ cvs diff -u
cvs diff: Diffing .
Index: fg_init.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/fg_init.cxx,v
retrieving revision 1.115
diff -u -r1.115 fg_init.cxx
--- fg_init.cxx 27 Dec 2004 17:35:22 - 1.115
+++ fg_init.cxx 29 Dec 2004 01:09:18 -
@@ -1145,10 +1145,17 @@
if ( !set_pos && !apt.empty() ) {
// An airport is requested (find runway closest to hdg)
-if ( fgSetPosFromAirportIDandHdg( apt, hdg ) ) {
+ // DCL - When finding rwy, first set hdg into wind where possible
+ double d = fgGetDouble("/sim/presets/wind-from-heading-deg");
+ double s = fgGetDouble("/sim/presets/wind-speed-kt");
+ double rhdg = hdg;
+ if(d > 0 && s > 0) {
+ rhdg = d;
+ }
+if ( fgSetPosFromAirportIDandHdg( apt, rhdg ) ) {
// set tower position (a little off the heading for single
// runway airports)
-fgSetTowerPosFromAirportID( apt, hdg );
+fgSetTowerPosFromAirportID( apt, rhdg );
set_pos = true;
}
}
Index: options.cxx
===
RCS file: /var/cvs/FlightGear-0.9/FlightGear/src/Main/options.cxx,v
retrieving revision 1.66
diff -u -r1.66 options.cxx
--- options.cxx 4 Dec 2004 21:06:57 - 1.66
+++ options.cxx 29 Dec 2004 01:09:26 -
@@ -977,6 +977,8 @@
double max_hdg = min_hdg + (20 - sqrt(sg_random() * 400));
double speed = sg_random() * sg_random() * 40;
double gust = speed + (10 - sqrt(sg_random() * 100));
+fgSetDouble("/sim/presets/wind-from-heading-deg", (min_hdg + max_hdg) /
2.0);
+fgSetDouble("/sim/presets/wind-speed-kt", speed);
fgSetupWind(min_hdg, max_hdg, speed, gust);
return FG_OPTIONS_OK;
}
@@ -989,6 +991,8 @@
SG_LOG( SG_GENERAL, SG_ALERT, "bad wind value " << arg );
return FG_OPTIONS_ERROR;
}
+fgSetDouble("/sim/presets/wind-from-heading-deg", (min_hdg + max_hdg) /
2.0);
+fgSetDouble("/sim/presets/wind-speed-kt", speed);
fgSetupWind(min_hdg, max_hdg, speed, gust);
return FG_OPTIONS_OK;
}
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Realistic parking
Durk Talsma writes: > I haven't implimented taxiway routing yet, so right now, each aircraft taxies > straight from the gate to the active runway. I bet you can guess what my next > logical move will be. :-) > Hi Durk, Take a flight at KEMT with the ai-traffic turned on. There's some taxying going on there. There are some good bits and some bad bits in my taxying code. The in-memory storage of a node-arc network, and the routine to find a shortest path between any two nodes is probably quite reasonable (now there's a hostage to fortune ;-)), and possibly worth you using. The code to supply the network from FGGround to the AI plane, and the code for the AI plane to follow it, is really quite hideous, and probably still has a few potential blow-ups in it. It really needs re-writing from scratch. Note how the plane 'wiggles' a bit as it passes each node - I guess I ought to read up on my control theory. Anyway, at this point we definately need to start co-operating, since we're going to need the same file format and editing tools for both of our AI traffic, else users are going to suffer. The file format I used was never meant to be permament BTW - just a one-off quick hack to get the KEMT proof-of-concept up and running. Do you have any firm convictions in this area already? I think that the time has probably come for the AI systems to merge IMHO. I think that probably the best thing to do is for me to instantiate my models through the Dave Culp system, since his model code is much better than mine I think. Then I can add ATC-AI interaction in my own bit, and anything we both need (such as taxying) can go in the AI-models (Culp) code to be used by both of us from one bit of code. This will require the AI-models code API to be extended so I can instantiate and control the models programatically. I believe Erik has some plans to make sure all models can be distributed logically between multiple and networked clients as well - it can only help if all AI systems use the same model tree in that respect. Any objections? I'll take a look anyway and see how much damage I'd need to do to merge. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Comm radios broken
Melchior FRANZ writes: > * David Luff -- Friday 24 December 2004 11:31: > > I can set the frequency on the radios, the problem is that there is no > > response from ATC. This was working a couple of weeks ago, and I haven't > > changed anything in the ATC end, so my guess is that something has got > > mixed > > up in the property system somewhere during some of the recent changes. > > Hardly. Almost all of the changes are reverted in cvs. These are the only > changes that were effectively made to the simgear/props/ directory in the > last three months: > It's OK, I've found the problem, it's got nothing to do with properties - my apologies! Curt has turned the ATC off 3 days ago: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/preferences.xml.diff?r1=1.166&r2=1.167&cvsroot=FlightGear-0.9 Curt, is there any reason the ATC needs to be turned off? I'm happy with having the AI traffic turned off by default for releases, but I can't think of any reason to turn the ATC off. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Comm radios broken
Chris Metzler writes: > On Thu, 23 Dec 2004 23:18:33 + > David Luff wrote: > > > > With the latest CVS of Simgear, FlightGear and base package, comm radios > > are completely broken, both attempting to set through the panel, > > http://baron.flightgear.org/pipermail/flightgear-devel/2004-December/032990.html > > I can set the frequency on the radios, the problem is that there is no response from ATC. This was working a couple of weeks ago, and I haven't changed anything in the ATC end, so my guess is that something has got mixed up in the property system somewhere during some of the recent changes. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Comm radios broken
With the latest CVS of Simgear, FlightGear and base package, comm radios are completely broken, both attempting to set through the panel, and through the property tree. It would be good to get this fixed before the release, but I won't have time to look at it for a few days. What is our release schedule at the moment? Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz andrunways.dat.gz
"Curtis L. Olson" <[EMAIL PROTECTED]> writes: > David Luff wrote: > > >I've been keeping the Atlas CVS up-to-date with FlightGear's changes, since > >Per Liedman (the author) no longer has regular net access. I'll do the > >latest airport change, and see if I can make a release. It probably won't > >be until after Christmas now though. > > > > > > Some sample code for parsing the apt.dat.gz file can be found in > src/Airports/apt_loader.cxx > Thanks. It's done now though - I found some sample code in TaxiDraw ;-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz and runways.dat.gz
On 12/22/04 at 6:00 PM Curtis L. Olson wrote: >I just commited a change to cvs that replaces the old basic.dat.gz and >runways.dat.gz files (which were in an old depricated/unsupported >format) with apt.dat.gz which is in the X-Plane format. This is the >format we now officially support. Having one single format between >X-Plane and FlightGear greatly simplifies the work Robin Peel has to do >to maintain the database. > Atlas has now been patched to use this data format by default (it should still work with the earlier formats as well). It'll probably take a few hours to show up on the anonymous CVS servers at Sourceforge. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] apt.dat.gz replaces basic.dat.gz andrunways.dat.gz
"Curtis L. Olson" writes: > Innis Cunningham wrote: > > > Does this work with Atlas now?.The last time I went to build the maps > > using Atlas I had to get the old default.nav files to get Atlas to work. > Hmm - I fixed this for Atlas itself (in CVS), but since I don't build the symbols on the maps there might be a problem with Map. I'll fix it if there is, but please report these problems to the Atlas list or they won't get fixed unless I happen to be bitten by them. > > I think Atlas is about 2-3 generations behind here. Someone should look > at updating the airport loading code, and if no one is available to do > that, then perhaps Atlas should consider maintaining it's own > "historical" database format? > I've been keeping the Atlas CVS up-to-date with FlightGear's changes, since Per Liedman (the author) no longer has regular net access. I'll do the latest airport change, and see if I can make a release. It probably won't be until after Christmas now though. Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On 12/20/04 at 11:41 PM David Luff wrote: >Of course, oversights like this would get picked up more easily if an adept >3D modeller added a magneto switch to the 3d C172 Oops, found it, bottom left! and pa28-161 :-) It is missing from that though. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
On 12/18/04 at 7:15 PM Dave Martin wrote: >While you're there, is there any chance of a magneto-related performance >loss? > >ie: when you run left mags only you get a power loss. > >Cheers :) > Hmm, I thought I already had, but it seems I'm mistaken. It's in the LaRCsim code (IO360.cxx), but never made it over to JSBSim's FGPiston.cpp. I believe I was gunning for about 25 rpm drop on one vs. two magnetos in the original code. I'll port it over... Of course, oversights like this would get picked up more easily if an adept 3D modeller added a magneto switch to the 3d C172 and pa28-161 :-) A master-on switch would be great as well :-)) Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
David Megginson writes: > On Sat, 18 Dec 2004 15:27:09 +0000, David Luff <[EMAIL PROTECTED]> wrote: > > > I've always assumed that it's a fairly late model injected 172, in order to > > justify the current lack of carb heating in the engine model ;-) > > The 172P is carbureted, unfortunately. > > Ah! Carb heating has just moved several places up my TODO list! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] C172P Model Year?
Dave Martin writes: > On Friday 17 Dec 2004 22:27, David Megginson wrote: > > > Totally up to you, but my 172P POH is for the 1981 model > > However, I also discovered that the early 172s had more dihedral and a > slightly different shape to the aerofoil. Comparing this the FG 172P, which > has little dihedral. It looks like 'our' one is a fairly-late 172P. > I've always assumed that it's a fairly late model injected 172, in order to justify the current lack of carb heating in the engine model ;-) Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
"David Luff" writes: > > I guess I'd better go and see what it looks like on an NVidea card now... > Well, I've had a very good pan round the Chicago scenery in the ufo with both the old and new materials.xml on a Linux box with a Geforce3, and I can't find a shred of difference in any of the runways, regardless of surface or marking type. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On 12/16/04 at 12:16 PM Curtis L. Olson wrote: >David Luff wrote: > >>I've commited a work-around to the base that wraps all the symetrical >>runway panels in the v direction (everything except the threshold panel >has >>identical upper and lower borders, and so can safetly be wrapped in v >given >>that we're only wrapping a handfull of pixels). This removes the vast >>majority of the lines (all except at the threshold, and the longitudional >>line where rwy numbers are made of 2 digits). You can still test Andy's >>plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will >>almost certainly exhibit panel jointing problems if you've been seeing >>runway lines. >> >> > >Dave, > >Based on all my knowledge of OpenGL, this is the wrong thing to do and >will introduce additional (although possibly less visible) artifacts at >the edges. The visual results should be examined *very* carefully. I >don't think this is what we want to do. > Hi Curt, I had a feeling I'd cop some flak for this ;-) I'm quite prepared to be proved wrong and to revert it if need be. Lets look at the benefits first though and give it a couple of days to see if there really are some downsides. Here's some screenshots to look at - 2 before the change, and 2 after. KDPA screenshots from my Cygwin build, KSFO from the official binary, both with an ATI Radeon 7200 32Meg card. http://www.nottingham.ac.uk/~eazdluf/KSFO-default.jpg http://www.nottingham.ac.uk/~eazdluf/KSFO-new.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-default.jpg http://www.nottingham.ac.uk/~eazdluf/KDPA-new.jpg Without any change thousand of users who download the official binary and use (an unknown but significant subset of) non-NVidia cards are going to be seeing those lines in the runway. They don't look good :-( Explanation of the ATI vs. NVidia differences is given by Andy Ross, a full two years ago: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095.h tml http://sourceforge.net/mailarchive/forum.php?forum_id=4479&max_rows=25&style =nested&viewmonth=200212 His patch never got included in Plib though (looking at the current source), and even if it did I don't have the knowhow to get OpenGL-1.2 stuff working under Windows. I can think of 3 possible avenues for fixing this: 1 - Look at the airport generator. Perhaps we've got tiny over or underruns on the tex co-ords. Maybe lining them up perfectly or even with slight overlap would fix it. Disadvantage - need to regenerate scenery to see benefits - not practical for this release. 2 - Fred compiles Plib with Andy's patch and gets the official binary to use GL_CLAMP_TO_EDGE if available. Apparently most modern cards should handle this. Disadvantage - AFAICT using 1.2 extensions on Windows is possibly somewhat non-trivial - win32api supplies openGL 1.1 by default if I'm not mistaken. 3 - My, erm, hack. I can't theoretically see where it's going to cause artifacts. AFAICT, I'm just wrapping in one direction where the bottom and top pixels of the texture are practically the same anyway. That's why I can't do the threshold piece. I'm quite prepared to be proved wrong though - I thought I'd better do this with enough time before the release to back it out if need be ;-) We could almost certainly wrap all the full width pieces in u and v if it's the 1D wrapping you're concerned about, since the left and right are identical, as long as we don't overrun the small runway shoulder. Can't do the 9r, 7l etc bits in that direction though. I guess I'd better go and see what it looks like on an NVidea card now... Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On 12/16/04 at 11:43 AM Martin Spott wrote: >"David Luff" wrote: > >> >http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095. html >> >> It requires openGL-1.2 for the patch to take effect, which I don't have >on >> Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if >> it makes any difference on your system? > >I'll have a look tonight, I've commited a work-around to the base that wraps all the symetrical runway panels in the v direction (everything except the threshold panel has identical upper and lower borders, and so can safetly be wrapped in v given that we're only wrapping a handfull of pixels). This removes the vast majority of the lines (all except at the threshold, and the longitudional line where rwy numbers are made of 2 digits). You can still test Andy's plib patch by using the 2D c172 (--aircraft=c172p-2dpanel) which will almost certainly exhibit panel jointing problems if you've been seeing runway lines. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] New scenery build
On 12/5/04 at 9:21 PM Martin Spott wrote: >"David Luff" wrote: >> Completely off topic, your screenshots look like you're getting dark >lines >> at runway texture boundaries similar to what I see on an ATI machine, but >> not on a NVidia machine. Are you also on an ATI card, and am I correct >in >> thinking that Andy Ross might have once produced a plib patch to cure >this >> - does anyone know if it ever went into plib or not? > >Sorry, I'm not aware of such a PLIB patch but I'm definitely not an >authoritative source of information in this topic. >My screenshot was made on an SGI Octane MaxImpact, no ATI, no NVidia - >but probably a platform that you'd be willing to declare as OpenGL >reference platform :-) > I've finally found the patch, and it didn't go into plib. The patch and description of it are at: http://mail.flightgear.org/pipermail/flightgear-devel/2002-December/014095.h tml It requires openGL-1.2 for the patch to take effect, which I don't have on Cygwin. If your SGI is openGL-1.2 capable, then perhaps you could see if it makes any difference on your system? Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Advice needed: rwy dist rem sign installation
On 12/14/04 at 11:06 AM Chris Metzler wrote: >Hi. So, I recently got a chance to pick this back up. In principle, >everything is finished: I have a set of signs which are designed >as per the U.S. FAA regs (FAA AC-150-5340-18C, Standards for Airport >Sign Systems, and FAA AC-150-5345-44G, Specification for Taxiway and >Runway Signs). > >I also have a script for generating .stg file entries. Features: > >- can read in airport data in either apt.dat or runways.dat format. >- will generate sign placements either for a single airport, a list >of airports (a list of ICAOs in a file), every airport in apt.dat >or runways.dat (but not heliports or seaplane bases), or every >airport in apt.dat that has the "has runway distance remaining signs" >flag set. >- can place signs using any of the three layout methods given by >the FAA regs. >- makes sure that there are no signs placed on top of intersecting or >nearby runways or taxiways. Specifically, it makes sure that no signs >are placed within 50' of any other runway/taxiway at the airport. It >attempts to adjust the positioning of a sign to avoid such a conflict, >omitting the sign entirely if it'd have to be moved by more than 50' >along the runway length, as per the FAA regs. > >I'd like to contribute this to FlightGear -- I think they'd make a >nice addition to the scenery at the airports where it'd be appropriate >to have them. However, I'm stuck on one thing that I'm hoping those >who build scenery will advise: what's the best way to write this stuff >out? Is the best option to: > >- have the script determine the tile numbers, go to the .stg files, and >insert the sign entries directly? >- have the script create an "installation" script, into which the sign >entries are embedded (e.g. as a here document); such a script could also >have a removal option, to take the signs back out? >- do things monolithically, or by airport (could be lots of files if >doing all relevant airports)? > >To be of most use to the project, how should this script write its info? > Now that we have the 'has distance remaining signs flag' for each runway in the data, I think that your script should be run by genapts during future scenery regeneration, and get put into the Terragear cvs IMHO. As an interim measure for users, I guess inserting directly into the stg files would work. It sounds like you can do this anyway based on the first part of your mail. Cheers - Dave This message has been scanned but we cannot guarantee that it and any attachments are free from viruses or other damaging content: you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
