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
[Flightgear-devel] multi display related
Hi people, I think I have good results with asymetric frustum as I've described weeks ago. Maybe I will need to see with Curt or anybody else if and how it could be added to FG. So Curt, feel free to send me an email off list. By looking at the three screens on which FG was running, I saw two visual anomaly : * I have nearly the same preferences.xml files on the visual hosts, but the clouds are not always the same, I mean clouds layers look the same kind, but the clouds are not always continuous on two screens. * Sometimes I can see the moon, and by turning, the moon doesn't move from a screen to another. I haven't looked at the code yet, but I think the cloud layers depend on a random parameter, which I may turn not random... I think the moon is drawn depending on the hour of the day in FG. If that's true, is there a way to set the time identical for all visual hosts so that I will have the same moon position ? Maybe I'm wrong. Once this mail is sent, I will look at the code, but if you have experienced this or have ideas to point me on, I would be interested ;-) Thanks David ___ 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] Marignane !?
Hi Martin, Marignane is in the airport list under the name "LFML Provence". Marignane is the name of the city, and the airport is called "Marseille Provence". Hope this helps ;) David > Hello, > I was surprised not to find Marignane in the airport list. Does any of > our French fellows have a description for this airfield ready ? ___ 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: > 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] Tile manager customization
Thanks Curt, I think I understand the policy. Is the visibility distance really what we can see ? I mean is there a real relation between the /sim/visibility and the far plane of the view frustum ? David > Hi David, > > The system is based off the visibility distance. The tile manager can > compute the size (width x height) of a tile at the current location. > Then it computes how many tiles vertically and horizontally it needs to > load to cover the specified visibility distance completely. > > Then it sends a series of tile load requests to the tile loader thread. > It starts out by requesting the current center tile, then it requests > the first concentric "square" ring of tiles (3x3 minus the center > tile). Then it requests the second concentric "square" ring (5x5 minus > the 3x3 minus the center) and proceeds until all needed tiles have been > requested. > > The loader thread checks the tile cache to see if a tile is already > loaded or not. If not already loaded, it dumps an old tile out of the > cache and starts loading the new one. > > The system is quite complex because we wanted to impliment the tile > loading as much as possible in a seperate thread. But there are many > unfortunate constraints with opengl and plib so we ended up with a > hybrid that does some work in the tile loader thread and some work in > the main thread. And as is usually the case with real world threads, > there are a lot of really subtle and difficult interactions that must be > considered. So if you poke around in that section of the code, please > tread very carefully because any seemingly innocuous change, could blow > up the whole thread interaction scheme (or introduce bugs that occur > rarely and are very difficult to track down.) > > Curt. > > -- > Curtis Olsonhttp://www.flightgear.org/~curt > HumanFIRST Program http://www.humanfirst.umn.edu/ > FlightGear Project http://www.flightgear.org > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Tile manager customization
Hi people, I wonder if today, there is a way to customize the tile manager in preferences. Is it possible to set the number of tiles to load "around" view position ? The covered area to load ? Could somebody explain me the tile loading/queuing policy ? Thanks in advance. David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] asymetric frustum
Hi Curt, I am one week late but here are the pics that I hope will help you to help me ;-) http://paxettepaxou.free.fr/fg/horizontal_fov.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_fov.JPG [19 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_front.JPG [17 Ko] http://paxettepaxou.free.fr/fg/vertical_view_front.JPG [14 Ko] http://paxettepaxou.free.fr/fg/horizontal_fov_side.JPG [19 Ko] http://paxettepaxou.free.fr/fg/vertical_fov_side.JPG [15 Ko] As I told you in my last mail, I have a cylindrical projection and the point of view is not centered in the cylinder. I have three asymetric frustums (vertically and horizontally asymetric). I really hope it will help you to help me. Thanks David > That's the basic idea. You specify a larger "virtual" screen that has a > symmetric frustum and then each display get's assigned a portion of the > larger display. I realize this is probably not an industry standard way > to do it, and this approach probably can't cover every possible screen > configuration, but I needed something quick a few months ago, and this > approach meshed pretty well with the existing code. > > I shold point out that there is some subtle wierdness depending on the > size of your display so for example, let's say you have 5 forward > displays. The center 3 are all parallel so they need to act as a single > larger fov display. If you want to assign 30 degrees field of view to > each of them, you would naturally pick a 90 degree field of view for the > center 3 and give each display 1/3 of that. However, you can't just > give the 2 edge displays an symmetric 30 degrees and have them match > up. There is some subtle aspect ratio stuff going on there that causes > problems. So what you'd need to do is setup the side channels as a 90 > degree fov virtual display and give them 1/3rd of that, then they should > match up with the center channels. > > At some point it would probably make sense to clean up the view pipeline > to handle this better, but time and priorities are always the big problem. > > Regards, > > Curt. > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] groundcache related
Hi Mathias, I'm not sure I understand what you've proposed me. You suggest me to add the few lines before I prepare the ground cache ? Do I have to set the altitude to something high to be sure no terrain will be over ? Do your few lines will ensure the required ground will be loaded ? In fact I don't understand why my code doesn't work cause I ask the altitude for an object I can see if I set its altitude manually, that makes me think the tile is already loaded ... David --- Message d'origine --- > De : Mathias Fröhlich <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] groundcache related > Date : sam 09 jui 2005 16:08:15 CEST > > > Hi, > > On Freitag 08 Juli 2005 12:42, BONNEVILLE David wrote: > > I'm trying to use the groundcache to determine the terrain elevation at a > > given position. > [...] > > Does anybody know where I am wrong or how I could solve my problem ? > > At the moment, the groundcache does not itself care for the required ground > tiles to be loaded. > I guess that this is missing. > > Try doing something like that: > > SGLocation location; > [ set the location to lat/lon/alt ] > globals->get_tile_mgr()->update(location, your_radius, > location->get_absolute_view_pos()); > > Not tested myself, but hopefully works. > > I am thinking about making the ground cache schedule tiles to be loaded. > ... so I am still working on that :) > > Greetings > > Mathias > > -- > Mathias Fröhlich, email: [EMAIL PROTECTED] > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] asymetric frustum
As you asked me my screen configuration, I am scanning it to explain it more precisely. In fact I have a cylindrical screen with 3 projectors and edge blending. The point of view is not centered on the center of the cylindrical screen, and it is not centered relatively to the screen height... lets say it is not centered at all... that's where the 3 asymetric frustums come from. I am ok to add this functionnality to FG, but I think I will need some help or some advice. I hope I could send images on monday. David --- Message d'origine --- > De : "Curtis L. Olson" <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] asymetric frustum > Date : ven 08 jui 2005 17:00:21 CEST > > Manuel Massing wrote: > > >Hello David, > > > > > > > >>I saw few months ago some posts about asymetric frustum for a screen wall. > >>I got > >>a similar installation so I will have three displays, each of them with > >>asymetric frustum (the point of view is not centered on the screens). I > >>will have these parameters : > >> > >>LeftScreen_Left_FOV > >> > >> > >[...] > > > > > >>RightScreen_Bottom_FOV > >> > >> > > > >Well, as Curt stated already, that depends on how these displays should > >be aligned. > > > >Assuming you want to simply combine three coplanar, untilted views (e.g. for > a > >multi-projector configuration on a single projection screen), and if these > >parameters are angles relative to the viewing direction, it should > >work as follows: > > > > -create a symmetric frustum with FOV of > > hor_fov = 2*max(-LeftScreen_Left_FOV, RightScreen_Right_FOV) > > vert_fov = 2*max(-CenterScreen_Top_FOV, > > Center_Screen_Bottom_FOV) > > > > -calculate the viewport coefficients [in range 0..1] by > > LS_l_coeff = 0.5 + 0.5*tan(LS_Left_FOV)/tan(hor_fov) > > LS_r_coeff = 0.5 + 0.5*tan(LS_Right_FOV)/tan(hor_fov) > > > > LS_t_coeff = 0.5 + 0.5*tan(LS_Top_FOV)/tan(vert_fov) > > LS_b_coeff = 0.5 + 0.5*tan(LS_Bottom_FOV)/tan(vert_fov) > > > > etc. > > > >These can then be set via the property system, i believe. Curt will surely > >be able to enlighten you on this. > > > > > > That's the basic idea. You specify a larger "virtual" screen that has a > symmetric frustum and then each display get's assigned a portion of the > larger display. I realize this is probably not an industry standard way > to do it, and this approach probably can't cover every possible screen > configuration, but I needed something quick a few months ago, and this > approach meshed pretty well with the existing code. > > I shold point out that there is some subtle wierdness depending on the > size of your display so for example, let's say you have 5 forward > displays. The center 3 are all parallel so they need to act as a single > larger fov display. If you want to assign 30 degrees field of view to > each of them, you would naturally pick a 90 degree field of view for the > center 3 and give each display 1/3 of that. However, you can't just > give the 2 edge displays an symmetric 30 degrees and have them match > up. There is some subtle aspect ratio stuff going on there that causes > problems. So what you'd need to do is setup the side channels as a 90 > degree fov virtual display and give them 1/3rd of that, then they should > match up with the center channels. > > At some point it would probably make sense to clean up the view pipeline > to handle this better, but time and priorities are always the big problem. > > Regards, > > Curt. > > -- > Curtis Olsonhttp://www.flightgear.org/~curt > HumanFIRST Program http://www.humanfirst.umn.edu/ > FlightGear Project http://www.flightgear.org > Unique text:2f585eeea02e2c79d7b1d8c4963bae2d > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] groundcache related
Hi people who are not yet on vacation,
I'm trying to use the groundcache to determine the terrain elevation at a given
position.
Here is the way I call it :
double radius = 50.;
double xyz[3];
sgGeodToCart( lat, lon, 1., xyz );
bool cache_ok = _ground_cache.prepare_ground_cache( 0., xyz, radius );
if( !cache_ok )
{
std::cout << "getTerrainAltitude is being called without scenery below
the
position" << std::endl;
std::cout << "latitude = " << lat << std::endl;
std::cout << "longitude = " << lon << std::endl;
}
double contact[3];
double normal[3];
double vel[3];
int type;
double loadCapacity;
double frictionFactor;
double terrain_elev = 0.;
_ground_cache.get_agl( 0., xyz, contact, normal, vel, &type, &loadCapacity,
&frictionFactor, &terrain_elev );
I call this code in my render loop and at each iteration i get cache_ok equal
to
false.
Does anybody know where I am wrong or how I could solve my problem ?
Thanks.
David
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] asymetric frustum
Hi again, I saw few months ago some posts about asymetric frustum for a screen wall. I got a similar installation so I will have three displays, each of them with asymetric frustum (the point of view is not centered on the screens). I will have these parameters : LeftScreen_Left_FOV LeftScreen_Right_FOV LeftScreen_Top_FOV LeftScreen_Bottom_FOV CenterScreen_Left_FOV CenterScreen_Right_FOV CenterScreen_Top_FOV CenterScreen_Bottom_FOV RightScreen_Left_FOV RightScreen_Right_FOV RightScreen_Top_FOV RightScreen_Bottom_FOV Is there anybody who have ideas about this particular case ? How could I do it in FG ? I think I will have to modify SGFrustum in plib. Help welcome ;-) David ___ 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 : Re: Re : Re: [Flightgear-devel] getting the best perfo with FG
I forced 60 Hz because I will use a projection system ;) Well for the moment, I don't think I need to lower my fps, but maybe, what would be nice is if I could force FG to run at a given fps which prevents me from "little freezes"... ;) David --- Message d'origine --- > De : Harald JOHNSEN <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: Re : Re: [Flightgear-devel] getting the best perfo with FG > Date : ven 17 jun 2005 10:45:48 CEST > > BONNEVILLE David wrote: > > >>From the Quadro FX 3000 : > >* 60 Hz refresh > >* vertical synchro forced > >* no AntiAlias > >* no Anisotropic filtering > >* 1280*1024 > >* 32 bpp > >* visibility 5 meters > > > > > >--- Message d'origine --- > > > > > >>De : "Ampere K. Hardraade" <[EMAIL PROTECTED]> > >>À : FlightGear developers discussions > >>Sujet : Re: [Flightgear-devel] getting the best perfo with FG > >>Date : ven 17 jun 2005 10:11:46 CEST > >> > >>On June 17, 2005 03:17 am, BONNEVILLE David wrote: > >> > >> > >>>Hi again people, > >>> > >>>problem solved ! :D > >>> > >>>I've just recompiled the latest cvs of plib, simgear and FlightGear, > >>> > >>> > >>turned > >> > >> > >>>on the threads flags, and now I have a FG running up to 60 fps (i have > >>>forced the synchro with the vertical refresh). > >>> > >>>Cuold somebody explain me the way to tune FG options to get the best > perfo > >>>? visibility, threads, dynamic terrain loading ... > >>> > >>>Thanks > >>> > >>>David > >>> > >>> > >>Well, 30 fps isn't that bad in my opinion, considering I only have 15 fps > if > >>I > >>am lucky. > >> > >>What other options did you use beside vertical synchronization? > >> > >> > >> > >>Ampere > >> > >>___ > >>Flightgear-devel mailing list > >>Flightgear-devel@flightgear.org > >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel > >>2f585eeea02e2c79d7b1d8c4963bae2d > >> > >> > Your 60 Hz refresh seems too low, you should try 80-85, it will be more > confortable for your eyes. > But now that your fps is maxed you want to know how to lower it ? ;) > > Harald. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] getting the best perfo with FG
>From the Quadro FX 3000 : * 60 Hz refresh * vertical synchro forced * no AntiAlias * no Anisotropic filtering * 1280*1024 * 32 bpp * visibility 5 meters --- Message d'origine --- > De : "Ampere K. Hardraade" <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] getting the best perfo with FG > Date : ven 17 jun 2005 10:11:46 CEST > > On June 17, 2005 03:17 am, BONNEVILLE David wrote: > > Hi again people, > > > > problem solved ! :D > > > > I've just recompiled the latest cvs of plib, simgear and FlightGear, > turned > > on the threads flags, and now I have a FG running up to 60 fps (i have > > forced the synchro with the vertical refresh). > > > > Cuold somebody explain me the way to tune FG options to get the best perfo > > ? visibility, threads, dynamic terrain loading ... > > > > Thanks > > > > David > > Well, 30 fps isn't that bad in my opinion, considering I only have 15 fps if > I > am lucky. > > What other options did you use beside vertical synchronization? > > > > Ampere > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] getting the best perfo with FG
Hi again people, problem solved ! :D I've just recompiled the latest cvs of plib, simgear and FlightGear, turned on the threads flags, and now I have a FG running up to 60 fps (i have forced the synchro with the vertical refresh). Cuold somebody explain me the way to tune FG options to get the best perfo ? visibility, threads, dynamic terrain loading ... Thanks David --- Message d'origine --- > De : Gerard Robin <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] getting the best perfo with FG > Date : jeu 16 jun 2005 17:29:09 CEST > > Le jeudi 16 juin 2005 à 17:15 +0200, Gerard Robin a écrit : > > Le jeudi 16 juin 2005 à 15:12 +0200, BONNEVILLE David a écrit : > > > Hi people, > > > > > > I have a bi Xeon 3.2 GHz with 3.25 Go RAM and a NVidia Quadro FX 3000 on > WinXP. > > > Without any anysotropic and antialiasing, i get FG running 30 fps and > sometimes > > > 20 fps. > > > Here are the option i use in my command line : > > > --airport-id=LFMI --aircraft=ufo --control=mouse --enable-game-mode > > > --enable-horizon-effect --geometry=1280x1024 --visibility=5 --bpp=32 > > > > > > that means i have also "specular highlight" and i don't have "enhanced > runway > > > lighting". > > > > > > The FG version is the one Fred put on a webpage with the process splash > screen. > > > I had the same performances with the official 0.9.8 release. > > > I am currently downloading the latest NVidia quadro driver for XP to > check if it > > > is the main cause. > > > Do you have any idea, suggestion, to improve FG perfo ? > > > > > > Thanks > > > > > > David > > > > > > > > > > > Your --visibility=5 seems very high more than usual > > > > AND with Metar on LFMI we get only 12000 , the visibility is pretty > good. > > -- > Gerard > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] getting the best perfo with FG
Hi people, I have a bi Xeon 3.2 GHz with 3.25 Go RAM and a NVidia Quadro FX 3000 on WinXP. Without any anysotropic and antialiasing, i get FG running 30 fps and sometimes 20 fps. Here are the option i use in my command line : --airport-id=LFMI --aircraft=ufo --control=mouse --enable-game-mode --enable-horizon-effect --geometry=1280x1024 --visibility=5 --bpp=32 that means i have also "specular highlight" and i don't have "enhanced runway lighting". The FG version is the one Fred put on a webpage with the process splash screen. I had the same performances with the official 0.9.8 release. I am currently downloading the latest NVidia quadro driver for XP to check if it is the main cause. Do you have any idea, suggestion, to improve FG perfo ? Thanks David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : [Flightgear-devel] Re: terrain elevation at a given position
That is the problem ;-) I am diving into SG code, but if Norman or somebody helped by Norman know where i could find it, feel free to post a maessage :D David > But if you say "at runtime", you possibly mean to get terrain elevation > while flying, so you can't simply teleport the aircraft to some lon/lat > just to read out a value. In this case you have to search for terrain > intersecion code in sg. I'm no expert in that. But Norman has already > pointed people there at several occasions, and you'll certainly find > something about it in the archives. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] terrain elevation at a given position
Hi there people, I think Melchior will answer me the first cause it is a city signs related question ;-) How could I get the terrain elevation at a given lat/lon at runtime ? Could you point me to the right way ? Thx David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] visual freeze
Thanks Mathias. I guess there is no solution for the moment ? Any idea ? David --- Message d'origine --- > De : Mathias Fröhlich <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] visual freeze > Date : jeu 19 mai 2005 08:19:10 CEST > > > Hi, > > On Mittwoch 18 Mai 2005 11:54, BONNEVILLE David wrote: > > When I fly straight forward, I have fps drops from 20 (average) to 5. If I > > scope disk access, it is synchronous with fps drops. Is it due to the next > > tile loading ? Does Mathias patch to simgear change something at this > point > > ? > That visual jitter elimination patch does not affect this part. > > I can see that too, but I see that since ever ... > I believe this is due to scenery loading including the static buildings in > that scenery. > Profile runs showed me that computing mipmaps from the original high > resolution textures takes a significant part of the time when loading 3d > Models. > >Greetings > >Mathias > > -- > Mathias Fröhlich, email: [EMAIL PROTECTED] > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: Re : [Flightgear-devel] airports and scenery
Now everything goes fine, I have the airports, the problem was I had no btg files in my scenery/Terrain/e000n40 directory. Thx David --- Message d'origine --- > De : Gerard ROBIN <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: Re : [Flightgear-devel] airports and scenery > Date : mer 18 mai 2005 14:08:41 CEST > > Le mercredi 18 mai 2005 à 10:34 +0200, BONNEVILLE David a écrit : > > Problem solved ! > > > > The tile scenery I downloaded from the graphical interface does not contain > any > > btg file ... > > I have another version of this tile I've downloaded 2 months ago and it > works > > fine. > > > > David > > > > > > --- Message d'origine --- > > > De : BONNEVILLE David <[EMAIL PROTECTED]> > > > à : ! FlightGear-devel > > > Sujet : [Flightgear-devel] airports and scenery > > > Date : mer 18 mai 2005 10:08:22 CEST > > > > > > > > > Hi people, > > > > > > maybe my problem should be exposed in FG user list... > > > I've installed from scratch the 0.9.8 win release. I've downloaded the > tile > > > e000n40 from FG scenery ftp and e000n40 airport package too. I've used > > > fgadmin > > > to install the scenery and i unpacked the aiports package in tha > airports > > > directory. When I start fgrun, it doesn't find the new airports ... > > > I want to go to LFML (Marseille Provence), I've looked into my new > > > directories, > > > and I have this airport in the apt.dat.gz and LFML.gz in > Airports/e000n40. > > > Did I forget something ? > > > > > > Thx > > > > > > David > > > > Hello > have you tried any other airports : > LFMO Orange > LFMY Lançon de Provence > LFNR Berre la Fare > On my side not any problem > living in Provence i usually use theses Airports. > The last Scenery version is better than the previous one > especially near NICE LFML CANNES LFMD > > -- > Gerard > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] visual freeze
Hi again people, When I fly straight forward, I have fps drops from 20 (average) to 5. If I scope disk access, it is synchronous with fps drops. Is it due to the next tile loading ? Does Mathias patch to simgear change something at this point ? Thx David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : [Flightgear-devel] airports and scenery
Problem solved ! The tile scenery I downloaded from the graphical interface does not contain any btg file ... I have another version of this tile I've downloaded 2 months ago and it works fine. David --- Message d'origine --- > De : BONNEVILLE David <[EMAIL PROTECTED]> > À : ! FlightGear-devel > Sujet : [Flightgear-devel] airports and scenery > Date : mer 18 mai 2005 10:08:22 CEST > > > Hi people, > > maybe my problem should be exposed in FG user list... > I've installed from scratch the 0.9.8 win release. I've downloaded the tile > e000n40 from FG scenery ftp and e000n40 airport package too. I've used > fgadmin > to install the scenery and i unpacked the aiports package in tha airports > directory. When I start fgrun, it doesn't find the new airports ... > I want to go to LFML (Marseille Provence), I've looked into my new > directories, > and I have this airport in the apt.dat.gz and LFML.gz in Airports/e000n40. > Did I forget something ? > > Thx > > David > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] airports and scenery
Hi people, maybe my problem should be exposed in FG user list... I've installed from scratch the 0.9.8 win release. I've downloaded the tile e000n40 from FG scenery ftp and e000n40 airport package too. I've used fgadmin to install the scenery and i unpacked the aiports package in tha airports directory. When I start fgrun, it doesn't find the new airports ... I want to go to LFML (Marseille Provence), I've looked into my new directories, and I have this airport in the apt.dat.gz and LFML.gz in Airports/e000n40. Did I forget something ? Thx David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] positionning object and view
Hi again people, In my tests, I place an aircraft on KSFO, 28R runway. If I set its heading to 280, it is not aligned with the runway, I have to set the heading to 300. I tried the same by setting the view position instead of the aircraft, and I see the same angle difference. I am new to aeronautics, so maybe I didn't understand the heading measurment. Could somebody explain me this difference please ? Thx David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] multi window
Hi people, I know FG can handle different views, but there is only one window. Would it be possible to display more than one view at a time in more than one window ? If not, do you have any ideas of the load it would require to add this functionnality ? Thx David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] maths and orientation
Hi there, I need some explanation about FGTileEntry::WorldCoordinate. Its parameters are : - sgCoord* obj_pos, must be the computed coordinates (cart + hpr) - Point3D center, guess it is an offset in cartesian coord - double lat, must be the lat (in deg) of the point to convert - double lon, must be the lon (in deg) of the point to convert - double elev, must be the elevation (in m) of the point to convert - double hdg, must be the heading of my object located at lat, lon elev Tell me if I am wrong at this point ... hope not :D First, I see that in this method the starting location is converted in cartesian coord (sgGeodToCart), but what surprised me is that in the construction of this point lat and lon are inverted ... don't know why for the moment. Before I looked to this method here is what I was doing. What I want to do is to compute a geod location of an object attached to another which I only know the location in lat/lon/z. Lets talk about an aircraft and its missile. Here is how I started to do. I tried to determine how the axis were placed using special geod coord and converting them into cartesian. I guessed that : - X is from the center of the earth to lat 0, lon 0 (equator, meridien of greenwich) - Y is from the center of the earth to lat 0, lon 90 (equator, east) - Z is from the center of the earth to lat 90, lon 0 (north pole) Is it still right at this point ? Then to compute the cart coord of the missile I intended to compute a mark_shifting matrix with : - a rotation around Z axis of an angle of "lon" - a rotation around Y axis of an angle of "90-lat" Then I computed the transposed matrix of this : mark_shifting_transposed. I created my local_transformation matrix using missile_deltaX, missile_deltaY, missile_deltaZ, aircraftH, aircraftP, aircraftR. Then, I computed my global transformation matrix as follow : mark_shifting * local_transformation * mark_shifting_transposed Then I guessed that I could compute my cartesian cooord of the missile by multiplying this transformation matrix with the cartesian coord of the aircraft. But I get strange results ... (if I use only one delta, sometimes I get a translation composed on 2 axis) It's been a long time since I practices maths... too long... Could anybody explain me maybe how I get wrong, and maybe a better way to compute what I want ? Thanks (a lot) in advance. David ___ 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 : Re: Re : Re: [Flightgear-devel] Manipulating 3D objects
Ok I see, maybe my example was too selective ;) Could you explain me how to scale a model ? Is it possible to scale it along the three axis ? thx David --- Message d'origine --- > De : Erik Hofman <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: Re : Re: [Flightgear-devel] Manipulating 3D objects > Date : mar 10 mai 2005 12:02:47 CEST > > BONNEVILLE David wrote: > > > As I am creating objects on-the-fly i want to be able to adjust objects. > Example > > : I have a generic "dynamic" building. I want to place a small one and a > long > > one, or i want to scale it up to add floors... > > Keep in mind then, that scaling a object doesn't affect the texture. SO > scaling down a building will also result in smaller floor heights so to > speak (the number of floors remains the same). > > To overcome that problem we would need a texture-scale animation that > and scale exactly the opposite to scaling the 3d model. > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] Manipulating 3D objects
> BONNEVILLE David wrote: > > Hi people, > > > > could somebody explain me how I could manipulate a 3D model ? > > Here is what I want to do : I want to load a 3D model (.ac or .3ds) and > > customize it on-the-fly : scale, rotate, translate (maybe toggle its > > visibility). > > How things could be done ? > > You want to scale a model?? > Now I'm starting to get curious, what are you modeling? As I am creating objects on-the-fly i want to be able to adjust objects. Example : I have a generic "dynamic" building. I want to place a small one and a long one, or i want to scale it up to add floors... David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Manipulating 3D objects
Hi people, could somebody explain me how I could manipulate a 3D model ? Here is what I want to do : I want to load a 3D model (.ac or .3ds) and customize it on-the-fly : scale, rotate, translate (maybe toggle its visibility). How things could be done ? Thanks in advance. David ___ 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
[Flightgear-devel] AI related
Hi there, I'm looking for documentation about AI objects. Maybe someone can help : I want to be able to create AI objects within my code on the fly, to be able to move them and let FG draw them. Does somebody has an idea ? remarks ? Can somebody point me on doc ? Thanks in advance. David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] AIManager and AIBase
Hi people, I intend to use FG as a "viewer". I have an application that manipulate aircrafts, boats and more, and I'd like to see them living in a 3D world. I saw that in FG there is an AIManager that can do what I want. If I've understood its function, it manipulates AIBase objects which have a position and an attitude (that's all I need). I then have to create AIBase objects corresponding to the entity living in my first application and then refresh properties of AIBase objects. * Is this possible ? I think I will integrate this in FG code... * If I'm right I won't need any FDM. What should I do in FG code to remove/disable this feature ? * Is it possible to attach the viewer on an AIBase object ? If it is, how can I do it ? All remarks are welcomed and thanks in advance for your answers. Regards, David ___ 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] Big Nasal Changes
For what this is worth: For work, I build flightgear with some custom mods using 2003 .NET It builds with pretty much zero code changes. I do have to munge around with the project files and add a bunch of include paths, lib paths, lib refs, etc. to get a clean build. However, the interesting part of 2003 .NET is the debugger. I have nothing but problems with it. It is just plain not as stable as the VC6 debugger. Constant crashes with large applications like FlightGear. I've been told that this is a install specific thing and that our messed up workstation config is the cause (our network IS/mgmt people are quite inept.) Other people tell me "no, it just sucks like that for any install." So I'm not sure where the truth lies. Probably somewhere in the middle. Many people in our company that are forced to do windows development refuse to upgrade to 2003 .NET even though the development environment is nicer than VC6. Hope this helps you at least somewhat. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Terry ReinertSent: Tuesday, April 19, 2005 8:25 AMTo: FlightGear developers discussionsSubject: Re: [Flightgear-devel] Big Nasal Changes I am still using VC++ 6.0 from 98 myself. I have been thinking of upgrading to either 2003 or 2005 but hesitant to do so until I find out whether I can still code the same way as I do now in those environments. I did some reading on the MS website last night and it seemed to imply that I do not need to program in .NET or the other fancy stuff they implimented but being Microsoft I am leary to believe them. So, anyone out there with VC++ 2003 that could shed some light on this? Will the programs I use now still compile without any modifications under the 2003 / 2005 IDE? Frederic Bouvier wrote: Selon Andy Ross: Frederic Bouvier wrote: I found where it is not C : you don't always declare local variables at the beginning of functions but you have the C++ habit to declare them as you need them. ... which is a well-established feature of the (now 6-year-old!) C99 standard. It's not a "C++" thing. And GCC stopped warning about this (in C mode, under -Wall) several years ago. You need to engage -ansi and disable --std=c99 to see stuff like this. I am not here to endorse Microsoft choices, but I see little point to use C syntax when C++ is available and is the language of choice for the overall FlightGear project. However, the link below should clarify Microsoft point of view : http://www.dotnet247.com/247reference/msgs/56/280444.aspx Not speaking about the fact that a lot of people are still using the v6 version that was released in 1998. Thanks for committing the patch. -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Simgear related problem
Hi there, I get errors running FG under Windows in debug mode : assertion failed in ctype.h in isspace cause a character was not in the range 0..255. Running in debug mode I saw that the problem happened during airports loading because of the copyright character. I modified simgear/misc/strutils.cxx so that in split_whitespace method isspace(str[i]) is replaced by isspace((unsigned char)str[i]). Then it works. I see isspace call in do_strip method too. I have not modified as below and this method was never called during my little test. Does my modification make sense ? Is this a simgear bug ? Maybe each isspace call should be cast as I did... David ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re : Re: [Flightgear-devel] compiling with .NET
I think I see what you mean, but my intention is to make a .NET project that is coherent with the GNU makefiles so that I could fully use all the wonderful .NET functionnalities is it too much ? ;) Comments ? David --- Message d'origine --- > De : Gerhard Wesp <[EMAIL PROTECTED]> > À : FlightGear developers discussions > Sujet : Re: [Flightgear-devel] compiling with .NET > Date : mer 06 avr 2005 19:01:15 CEST > > On Wed, Apr 06, 2005 at 03:58:24PM +0200, BONNEVILLE David wrote: > > we don't have this : should we use a bat file to launch msdev with > environment > > variables for each libs paths ? Another idea ? > > You know you can use .NET's cl from the command line and from makefiles > (I mean sane ones, i.e. GNU make). Just start their ``command line > tool'' and cygwin from it, then all .NET tools are available under your > cygwin shell. > > Cheers > -Gerhard > -- > Gerhard Wesp o o Tel.: +41 (0) 43 5347636 > Bachtobelstrasse 56 | http://www.cosy.sbg.ac.at/~gwesp/ > CH-8045 Zuerich \_/ See homepage for email address! > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] compiling with .NET
Hi people, I am currently "breaking" the FlightGear .NET project to make it look like the Linux one, that means divided in several libraries. If the comunity is interested I could give you back the final .NET project. But I saw few problems : On Linux we have configure which creates the makefile with the good paths to libs and includes so that we don't have to care for all the FG libs. With .NET we don't have this : should we use a bat file to launch msdev with environment variables for each libs paths ? Another idea ? Any comments are welcomed. I'd be glad to help you by giving a nice .NET project ;) David ___ 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] FlightGear BitTorrents
Good idea! Now what would be really neat is if we could get some seeders started with the entire world scenery distribution. Things that size (i.e. HUGE!) is where bit torrent can really shine. I would volunteer, but I don't have the entire set ... -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Arthur Wiebe Sent: Tuesday, March 15, 2005 2:24 PM To: FlightGear developers discussions; FlightGear user discussions Subject: [Flightgear-devel] FlightGear BitTorrents Hey everyone, FlightGear (source and base), and SimGear source are now available for download via BitTorrent, thanks to http://www.open-bits.org See: http://www.open-bits.org/browse.php?cat=3 http://www.open-bits.org/details.php?id=902 (SimGear Source) http://www.open-bits.org/details.php?id=901 (fgfs-base) http://www.open-bits.org/details.php?id=900 (FlightGear source) For those who don't know what BitTorrent is, see http://www.bittorrent.com/introduction.html And you can download the client from http://www.bittorrent.com Currently we need seeders. So even though I'm very sure most if not all of you already have the above releases, you can still seed for those who don't :) Curtis, Maybe you might want to link to the torrents on the download page? I have no idea what kind of load you have on your servers but this may sure help to reduce it. Thanks, and enjoy! (And happy seeding) -- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] 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] 2D-Panel for A320
> I started to create a 2D-panel for the A320. > ... > But now i got stuck, because I have 3 questions: Nice work Hans-Georg! It seems to me that the FlightGear developers who have OpenGL experience have lost interest in the 2D panel code some time ago, and their answer to you will be to switch to 3D panels. I prefer the 2D panels, so I'm hoping you know C++ and OpenGL? Dave ___ 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
[Flightgear-devel] Taking a break
I'm going to be taking a short break from the FlightGear, SimGear, and TerraGear mailing lists to help me focus on finding new customers to build up my XML consulting business back up (and to do lots of real flying, of course). I'll still be using FlightGear for practice and I will keep up to date on the CVS and read the announce lists. I expect that I won't be gone long -- likely weeks, and maybe a few months at worse -- and if people have any problems with or questions about my code chunks, I'll be happy to discuss them by private mail. I'll try to devote some time to my 3-D models while I'm away, especially the Warrior and the J3 Cub. Thanks, and all the best, David -- http://www.megginson.com/ ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] link to my homepage
On Sat, 22 Jan 2005 16:43:13 +0200, Paul Surgeon <[EMAIL PROTECTED]> wrote: > I say pull the package in question. If the author wants to distribute it on > his own site then that is fine with me but as it stands it looks like we > endorse what is in that package. > I'd rather upset one contributor than piss off the whole FG community. Let's take this whole discussion offline, guys -- it has become a bit silly. All the best, David -- http://www.megginson.com/ ___ 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
