[Flightgear-devel] Re: Terragear, 64 bit
Alex, I think I have it one patch from cvs. I have built scenery with this patch on my AMD64. As you can see I just redeclared the 'long int' to int32. now if I can just get the land mass from e00 Jason ? simgear_cvs.diff Index: simgear/io/lowlevel.hxx === RCS file: /var/cvs/SimGear-0.3/source/simgear/io/lowlevel.hxx,v retrieving revision 1.2 diff -r1.2 lowlevel.hxx 43a44,45 typedef long int int32; ___ 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 1320
Re: [Flightgear-devel] TaxiDraw-0.3.2 released
On Tuesday 16 August 2005 14:49, David Luff wrote: 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). 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. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] multiplayer patch for enianess
Ok, this is *way* better than what was there before! Thanks so far! What I have problems with is that, as long as you use a struct for the whole message, the compiler is free to do alignment decisions different than your expectations on it. I posted, at the time of the first attempts to fix that, a xdr stream implementation from the c++ journal. That one would guarantee independence of struct alignment. The ip address of the sender is redundant. I do at the moment not know the actual implementation of the udp socket we use here, but there must be a way to get them from the recv call (at least for the udp/ip case). Is that address used to send a reply? If so, this will not work for everybody behind a nat gateway which rewrites the ip headers but cannot know something about flightgears internals. Also why do you use fixed length strings? It seems better to me if there is a length field in front of the string data which tells the implementation how much characters it can expect (within the limits of the current udp connection of course). Also that xdr stream would not have the problem with returning hardware doubles if floats are returned by declaration (your comment in timy_xdr.h). I have access to a DEC alpha. I don't believe that I can run flightgear on that machine successfully and I doubt that there is a single alpha left on this earth where flightgear will be run on. So if you just want to be complete, I can help you with that, but my be we can ignore the DEC's ... Objections? So all together this is good work, but as we are on it, we might be able to make it fool proof :) Greetings Mathias On Montag 15 August 2005 10:02, Oliver Schroeder wrote: Hi, I've written a patch that _should_ solve issues with endianess in multiplayermode, which can be found at: http://www.o-schroeder.de/fg_server/patch.php Please try it out. Multiplayermode will still be broken on non IEEE-encoding platforms (eg. Motorola 68XXX, vax, some DEC-alphas). Since I have no access to those machines I can't help it. If you have such a computer you may be able to provide the nessacary information (ie. internal representation of floats/doubles), so I can fix this, too. regards, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Multiplayer Location Transformation toLat/Lon/Alt
Hi, Is there a plan to switch to OSG? Just wondering. I didn't know. I do not know of concrete plans, but here and then there are roumors. I for my own would apprecheate that, since it looks very promising. ... also a few weeks ago a small cvs checkin with some 'flightgear' path in it slipped into osg's cvs. So there must be people on it behind the scenes. :) I think the current math utilities are self-documented adequately. One of my obstacles has been learning the definition of the multiplayer interface, so I know where to start. I think I am beginning to understand now. It appears the position is cartesian (ecef), but is the difference between the player location and the center of _his_ current tile. The position is in the fourth row of the 4x4, in the first three columns. The upper left 3x3 represents the orientation. That depends a bit. The scenery center is in current cvs now locateable at any position. This fixes problems with roundoff and jumpy 3d objects near the eyepoint. In fact it is allways near the current eyepoint. There has been much talk here about reworking the multiplayer model. I'm guessing that the assumption that the other players are all on the same tile will not be required in future versions. Are the current thoughts toward sending absolute position across the wire? Would that be geodetic or cartesian? (just gathering current thoughts, not definitive answers for where this is heading) It looks like they will be cartesian. And IMO this is the preferred way, even if people find lat/lon more intuitive, cartesian coordinates are much more handy for nearly every kind of computation required to be done in this area. 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
Re: [Flightgear-devel] Real weather fetch stops FG from starting
On Monday 15 Aug 2005 08:55, Erik Hofman wrote: Lee Elliott wrote: I've just been having a problem with FG failing to start when real-weather-fetch is enabled and the METAR data is too old This problem has been reported before. I (or someone else) still need(s) to take a look at it. I don't think it's that much of a problem to solve though, probably just a matter of incrementing the error counter it the right location. Erik I sort of got around it by increasing the metar-max-age-min entry in preferences.xml from 2 to 4 hours. I figured that this would let FG accept out of date reports but still use up to date ones where available. Seemed to work. LeeE ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] FlightGear freezes (float point interrupt)
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 Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
