[Flightgear-devel] [Multiplayer] Oh where Oh where .......
I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? (if its just the one plane, once I get it to fly multiplayer, my focus will be to add multiple/AI plane support to the code, so comments towards achieving that goal will be welcome also) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] My first "real" patches...
Gene Buckle wrote: FDM for a parachute ?? round or rectangular chute ?? joystick controls the shrouds ?? cutting loose the main and deploying the spare ?? skydiving ?? (ok -- not really related to the ejection code itself, but it would be nice :) ) In those cases, would be nice == way over my head. :) As usual: fgfs --aircraft=paraglider --in-air --altitude=5000 Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Newbie needs a mentor(s)
> -Original Message- > From: Phil Spurr [mailto:[EMAIL PROTECTED] > Sent: 12 November 2003 12:24 am > To: [EMAIL PROTECTED] > Subject: [Flightgear-devel] Newbie needs a mentor(s) > > > Hi all > I've recently (with help from Curt) managed to download and > run the Win32 > binaries and have been very impressed with all of your work > in creating > Flightgear. > I would like to become involved with the project, but I'm > looking at using > Mandrake Linux as my platform. Is there someone out there who > could answer > my 'silly' questions as I'm new to using Linux as well - just > to get me to > the point of being able to compile successfully ! > I'm no newcomer to programming, or flight sims / real flying > / aircraft > systems, but I'm struggling with two unknowns at once here. > And if there's any reason to choose a different Linux/Windows > platform, > please tell me now before I go down the wrong avenue... > Regards > Phil > I am not a programmer or pilot, but I use Cygwin on Win2K to build Flightgear. Other than a small hiccup with ld not looking in /usr/local/lib by default, it works perfectly. Having seen the stories on the list of people struggling to get 3D accelleration working in Linux, I am planning to stay with Win32 for the time being. Richard ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett wrote: I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? For the MultiPlayer module this is handled in the MPPlayer class located in FlightGear/src/MultiPlayer/mplayer.[ch]xx Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
Erik Hofman wrote: John Barrett wrote: I'm pretty much done with the client/server startup handshake -- ready to do the code at the peer to register active aircraft with the server (active = aircraft for which this FG peer is responsible for FDM calcs, the protocol supports the idea of multiple aircraft sharing a single server connection for FG instances that are primarily handling a number of AI planes on behalf of a multiplayer scenario) In the current code -- there is just the single airplane being simulated on the display ?? or where could I find a list/array of a/c that are being managed so I can register each plane with the server and have the server relay updates for all of them ?? For the MultiPlayer module this is handled in the MPPlayer class located in FlightGear/src/MultiPlayer/mplayer.[ch]xx It just occurs to me, you want simulated aircraft (with each have it's own FDM) instead of updating the portion every frame don't you? I thank that needs a bit more thought. Most FDM's are just too heavy for having a lot of them work together. I think we need a NULL FDM with autopilot support for that. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
On 11/11/03 at 8:22 PM David Megginson wrote: >There are raw, scanned sectionals and terminal charts available >online. I haven't downloaded and unpacked the zipfiles yet, so I'm >not sure of the format. > >Sectionals, at 1:500,000 scale, are the most commonly-used charts for >VFR flying -- in Canada, we have the same thing, but call them VNC's >(Visual Navigation Charts). For busy terminal areas, there are also >special 1:250,000 scale charts available. The other popular charts >are the World Aeronautical Charts (WAC), at 1:1,000,000 -- it's harder >to make out small details, but there's less chart folding and >switching for a long flight. > >Here are the U.S. 1:500,000 Sectionals and 1:250,000 terminal charts, >in TIFF format: > > http://aviationtoolbox.org/raw_data/FAA_sectionals/East/ > >Here's the 1:250,000 chart for the SFO area: > > >http://aviationtoolbox.org/raw_data/FAA_sectionals/West/Terminal-Area-Chart s/San%20Francisco%20TAC%2063.tif > >I'm just downloading now, so I'm not sure about the quality yet. > > Thanks for the heads up, the quality appears to be very good. (At about 30 meg for the bay area alone it ought to be!). Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
Manuel Bessler wrote: I've thrown together something similar with the plib js and net examples and changed the joyclient on fgfs side. This allows you to use a joystick port on another machine via the network. One thing I'd like to change is to make it configurable via the property tree what is being controlled by the remote joystick. I'm not sure if that'll work. I imagine something like this: fgfs --jsclient=socket,in,10,192.168.1.2,16759,udp --prop:/jsclient/axis[0]/binding="/controls/engines/engine[0]/throttle" --prop:/jsclient/axis[1]/binding="/controls/engines/engine[1]/throttle" Currently the protocol assumes 4 axes, 4 buttons. If less than 4 axes are installed on the joystick server, the unused axes will read zero. No provision for endian-ness yet. Okay, this is committed to CVS. Changes and updates are always welcome. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: Flightgear-devel Digest, Vol 7, Issue 47
On Wed, 12 Nov 2003 08:25 pm, [EMAIL PROTECTED] wrote: > Message: 9 > Date: Wed, 12 Nov 2003 09:12:57 - > From: "Richard Bytheway" <[EMAIL PROTECTED]> > Subject: RE: [Flightgear-devel] Newbie needs a mentor(s) > I am not a programmer or pilot, but I use Cygwin on Win2K to build > Flightgear. Other than a small hiccup with ld not looking in > /usr/local/lib by default, it works perfectly. Having seen the > stories on the list of people struggling to get 3D accelleration > working in Linux, I am planning to stay with Win32 for the time > being. To be fair, if you have a supported graphics card, esp nvidia, it is pretty straightforward. Download a driver and install; that's it. People tend to have problems with old or bleeding edge stuff, or cards from manufacturers that won't support/allow linux drivers. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
On Wednesday 12 Nov 2003 1:22 am, David Megginson wrote: > There are raw, scanned sectionals and terminal charts available > online. I haven't downloaded and unpacked the zipfiles yet, so I'm > not sure of the format. > > Sectionals, at 1:500,000 scale, are the most commonly-used charts for > VFR flying -- in Canada, we have the same thing, but call them VNC's > (Visual Navigation Charts). For busy terminal areas, there are also > special 1:250,000 scale charts available. The other popular charts > are the World Aeronautical Charts (WAC), at 1:1,000,000 -- it's harder > to make out small details, but there's less chart folding and > switching for a long flight. > > Here are the U.S. 1:500,000 Sectionals and 1:250,000 terminal charts, > in TIFF format: > > http://aviationtoolbox.org/raw_data/FAA_sectionals/East/ > > Here's the 1:250,000 chart for the SFO area: > > > http://aviationtoolbox.org/raw_data/FAA_sectionals/West/Terminal-Area-Chart >s/San%20Francisco%20TAC%2063.tif > > I'm just downloading now, so I'm not sure about the quality yet. > > Wow, these are big, beautiful, 8-bit-colo[u]r scans, sure enough. I notice that they have geoTIFF tags. My brief reading and hazy understanding of the geoTIFF specification at http://remotesensing.org/geotiff/spec/geotiffhome.html leads me to believe that there is useful information in there which allows one to translate between the raw raster image coordinates and what the spec. refers to as Model space, i.e. geodetic coordinates. Frustratingly, I can't get the geotiff packages to install. I have installed libproj0-4.4.5-2mdk.i586.rpm, libgeotiff1-1.1.4-6mdk.i586.rpm and libgeotiff1-devel-1.1.4-6mdk.i586.rpm. But... [EMAIL PROTECTED] rpms]# rpm -ivh geotiff-1.1.4-6mdk.i586.rpm error: failed dependencies: libgeotiff.so is needed by geotiff-1.1.4-6mdk I don't really understand why this is a problem, because the libraries seem to be installed OK (the indirect symbolic linking seems odd, but valid) [EMAIL PROTECTED] rpms]# ls -l /usr/lib/libgeo* /usr/lib/geo* ## listing edited to reduce line length ## /usr/lib/libgeotiff.so -> geotiff.so.1.1.4* /usr/lib/geotiff.so.1.1.4 -> /usr/lib/libgeotiff.so.1.1.4* 1789726 Jan 30 2003 /usr/lib/libgeotiff.a* 1633716 Jan 30 2003 /usr/lib/libgeotiff.so.1.1.4* ...and ldconfig knows about them... [EMAIL PROTECTED] rpms]# ldconfig -p | grep geo libgeotiff.so.1.1.4 (libc6) => /usr/lib/libgeotiff.so.1.1.4 libgeotiff.so (libc6) => /usr/lib/libgeotiff.so Anyone know how to unstick this? geotiff gives us a tool to read the tags in the TIFF files. Regards Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scanned sectional charts online
Try using the "ignore dependencies" flag on RPM to override the dependency checking. Ugly, but it might work. Alternatively, start from source and built it yourself. Richard Frustratingly, I can't get the geotiff packages to install. I have installed libproj0-4.4.5-2mdk.i586.rpm, libgeotiff1-1.1.4-6mdk.i586.rpm and libgeotiff1-devel-1.1.4-6mdk.i586.rpm. But... [EMAIL PROTECTED] rpms]# rpm -ivh geotiff-1.1.4-6mdk.i586.rpm error: failed dependencies: libgeotiff.so is needed by geotiff-1.1.4-6mdk I don't really understand why this is a problem, because the libraries seem to be installed OK (the indirect symbolic linking seems odd, but valid) [EMAIL PROTECTED] rpms]# ls -l /usr/lib/libgeo* /usr/lib/geo* ## listing edited to reduce line length ## /usr/lib/libgeotiff.so -> geotiff.so.1.1.4* /usr/lib/geotiff.so.1.1.4 -> /usr/lib/libgeotiff.so.1.1.4* 1789726 Jan 30 2003 /usr/lib/libgeotiff.a* 1633716 Jan 30 2003 /usr/lib/libgeotiff.so.1.1.4* ...and ldconfig knows about them... [EMAIL PROTECTED] rpms]# ldconfig -p | grep geo libgeotiff.so.1.1.4 (libc6) => /usr/lib/libgeotiff.so.1.1.4 libgeotiff.so (libc6) => /usr/lib/libgeotiff.so Anyone know how to unstick this? geotiff gives us a tool to read the tags in the TIFF files. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
On Wednesday 12 Nov 2003 12:10 pm, Jonathan Richards wrote: > Frustratingly, I can't get the geotiff packages to install. > Anyone know how to unstick this? geotiff gives us a tool to read the tags > in the TIFF files. Sorry to follow up my own post. I gave up on the rpm packages and tried to install from source. Segmentation fault! So I took the binary package from ftp://ftp.remotesensing.org/pub/geotiff/libgeotiff/libgeotiff-linux-bin.1.1.4.tar.gz and copied the files under /usr/local. There are NT and MacOS binaries there, too. listgeo gives a whole shedload of information about the mapping, too much to report here unless anyone's interested, in which case mail me. Jonathan ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: "Erik Hofman" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 4:22 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... > Erik Hofman wrote: > > John Barrett wrote: > > > >> I'm pretty much done with the client/server startup handshake -- ready > >> to do > >> the code at the peer to register active aircraft with the server > >> (active = > >> aircraft for which this FG peer is responsible for FDM calcs, the > >> protocol > >> supports the idea of multiple aircraft sharing a single server connection > >> for FG instances that are primarily handling a number of AI planes on > >> behalf > >> of a multiplayer scenario) > >> > >> In the current code -- there is just the single airplane being > >> simulated on > >> the display ?? or where could I find a list/array of a/c that are being > >> managed so I can register each plane with the server and have the server > >> relay updates for all of them ?? > > > > > > For the MultiPlayer module this is handled in the MPPlayer class located > > in FlightGear/src/MultiPlayer/mplayer.[ch]xx > > It just occurs to me, you want simulated aircraft (with each have it's > own FDM) instead of updating the portion every frame don't you? > > I thank that needs a bit more thought. Most FDM's are just too heavy for > having a lot of them work together. I think we need a NULL FDM with > autopilot support for that. > right -- I'll be stealing some code out of the src/Multiplayer re: handling displaying remote aircraft -- just worried about multiple a/c w/fdm running locally :) You'll recall I mentioned the --headless option. Doing multiple FDM would be much more reasonable if there were no OpenGL display at all -- still -- for single player or small groups -- a fast machine should be able to handle the display and say 2-4 AI planes (or at least I would hope that could be achieved) In any case -- that simplifies and complicates things a bit -- but at least I know what to do next :) when you say "null fdm + autopilot" -- it doenst appear the null FDM is a plane at all - wouldnt it make more sense to use the full FDM code with scripting to drive the existing autopilot code ?? i.e. script sets desired altitude, heading, speed, limits on pitch yaw roll rate of descent, etc allowed during manuevers, updates the desired settings in realtime based on positions of other planes and/or radio message traffic -- autopilot caries out those instructions -- isolates the AI from the actual complexities of controlling the aircraft ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: "John Barrett" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 8:50 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... > - Original Message - > From: "Erik Hofman" <[EMAIL PROTECTED]> > To: "FlightGear developers discussions" <[EMAIL PROTECTED]> > Sent: Wednesday, November 12, 2003 4:22 AM > Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... > > > > Erik Hofman wrote: > > > John Barrett wrote: > > > > > >> I'm pretty much done with the client/server startup handshake -- ready > > >> to do > > >> the code at the peer to register active aircraft with the server > > >> (active = > > >> aircraft for which this FG peer is responsible for FDM calcs, the > > >> protocol > > >> supports the idea of multiple aircraft sharing a single server > connection > > >> for FG instances that are primarily handling a number of AI planes on > > >> behalf > > >> of a multiplayer scenario) > > >> > > >> In the current code -- there is just the single airplane being > > >> simulated on > > >> the display ?? or where could I find a list/array of a/c that are being > > >> managed so I can register each plane with the server and have the > server > > >> relay updates for all of them ?? > > > > > > > > > For the MultiPlayer module this is handled in the MPPlayer class located > > > in FlightGear/src/MultiPlayer/mplayer.[ch]xx > > > > It just occurs to me, you want simulated aircraft (with each have it's > > own FDM) instead of updating the portion every frame don't you? > > > > I thank that needs a bit more thought. Most FDM's are just too heavy for > > having a lot of them work together. I think we need a NULL FDM with > > autopilot support for that. > > > > right -- I'll be stealing some code out of the src/Multiplayer re: handling > displaying remote aircraft -- just worried about multiple a/c w/fdm running > locally :) > > You'll recall I mentioned the --headless option. Doing multiple FDM would be > much more reasonable if there were no OpenGL display at all -- still -- for > single player or small groups -- a fast machine should be able to handle the > display and say 2-4 AI planes (or at least I would hope that could be > achieved) > > In any case -- that simplifies and complicates things a bit -- but at least > I know what to do next :) > > when you say "null fdm + autopilot" -- it doenst appear the null FDM is a > plane at all - wouldnt it make more sense to use the full FDM code with > scripting to drive the existing autopilot code ?? i.e. script sets desired > altitude, heading, speed, limits on pitch yaw roll rate of descent, etc > allowed during manuevers, updates the desired settings in realtime based on > positions of other planes and/or radio message traffic -- autopilot caries > out those instructions -- isolates the AI from the actual complexities of > controlling the aircraft > I was just poking through the code and want to confirm something -- everything appears to be working off of globals ?? there isnt an airplane object that coordinates all the fdm/opengl/autopilot functionality that can be instanced at need, and multiple instances created if neccessary ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
On Wednesday 12 November 2003 13:10, Jonathan Richards wrote: > [EMAIL PROTECTED] rpms]# rpm -ivh geotiff-1.1.4-6mdk.i586.rpm > error: failed dependencies: > libgeotiff.so is needed by geotiff-1.1.4-6mdk > > I don't really understand why this is a problem, because the libraries > seem to be installed OK (the indirect symbolic linking seems odd, but > valid) > > [EMAIL PROTECTED] rpms]# ls -l /usr/lib/libgeo* /usr/lib/geo* > ## listing edited to reduce line length ## > /usr/lib/libgeotiff.so -> geotiff.so.1.1.4* > /usr/lib/geotiff.so.1.1.4 -> /usr/lib/libgeotiff.so.1.1.4* > 1789726 Jan 30 2003 /usr/lib/libgeotiff.a* > 1633716 Jan 30 2003 /usr/lib/libgeotiff.so.1.1.4* > > ...and ldconfig knows about them... > [EMAIL PROTECTED] rpms]# ldconfig -p | grep geo > libgeotiff.so.1.1.4 (libc6) => /usr/lib/libgeotiff.so.1.1.4 > libgeotiff.so (libc6) => /usr/lib/libgeotiff.so > > Anyone know how to unstick this? geotiff gives us a tool to read the > tags in the TIFF files. You could try rpm -ivh --nodeps geotiff-1.1.4-6mdk.i586.rpm --Ivo ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
> (if its just the one plane, once I get it to fly multiplayer, my focus will > be to add multiple/AI plane support to the code, so comments towards > achieving that goal will be welcome also) > I think it would make sense to have the server handle any non-human controlled vehicles. It would keep the load off the client which already has its hands full doing a full systems simulation as well as doing graphics work. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett writes: > when you say "null fdm + autopilot" -- it doenst appear the null FDM is a > plane at all - wouldnt it make more sense to use the full FDM code with > scripting to drive the existing autopilot code ?? i.e. script sets desired > altitude, heading, speed, limits on pitch yaw roll rate of descent, etc > allowed during manuevers, updates the desired settings in realtime based on > positions of other planes and/or radio message traffic -- autopilot caries > out those instructions -- isolates the AI from the actual complexities of > controlling the aircraft The NullFDM is just a place holder that does nothing. This is useful for cases when you want to update all the FDM variables from some other source (like an external program communicating via the net.) It doesn't do any interpolation or anything like that. Attaching the autopilot to it doesn't make sense. NullFDM does exactly nothing which is useful when you want the FDM functionality to come from somewhere else. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message - From: "Gene Buckle" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 10:48 AM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... > > (if its just the one plane, once I get it to fly multiplayer, my focus will > > be to add multiple/AI plane support to the code, so comments towards > > achieving that goal will be welcome also) > > > > I think it would make sense to have the server handle any non-human > controlled vehicles. It would keep the load off the client which already > has its hands full doing a full systems simulation as well as doing > graphics work. > What I'm driving at here is having a headless client that does multiple fdm/autopilot sims on behalf of a server which may itself be handling several planes in addition to the net connections -- no graphics at all -- though a side effect will be to have a user controled plane + one or more AI planes -- it may not get used that way -- but someone might what I'm asking is "everything looks like it works through globals rather than discrete instances of aircraft+fdm+autopilot -- am I looking at a serious architectural change to get multiple independent ac+fdm+ap simulated concurrently ??" wether or not the discrete aircraft code gets used in a single user, or server only environment isnt relevant :) how much work am I looking at to make it happen :) ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett wrote: > In the current code -- there is just the single airplane being > simulated on the display ?? or where could I find a list/array of a/c > that are being managed so I can register each plane with the server > and have the server relay updates for all of them ?? Um, isn't that the hard part? If FlightGear was all set with a clean interface to plug multiple animation-ready aircraft models, I dare say someone would have plugged it in already. :) Erik Hofman wrote: > > For the MultiPlayer module this is handled in the MPPlayer class > > located in FlightGear/src/MultiPlayer/mplayer.[ch]xx > > It just occurs to me, you want simulated aircraft (with each have it's > own FDM) instead of updating the portion every frame don't you? > > I thank that needs a bit more thought. Most FDM's are just too heavy > for having a lot of them work together. I think we need a NULL FDM > with autopilot support for that. Exactly. It seems to me like we're swimming in half-finished multiplayer/multiaircraft/network-data/network-interface implementations. What we need really isn't another one to plug into the mess, it's someone to *finish* the whole project and (if possible) throw out all the old junk that isn't used anymore. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Property Heirarchy
Is there any designed rhyme or reason to the layout of the properties from the top down in FlightGear? Any particular conventions? I think there ought to be something written down if there is not in order to allow the FDM authors (and others) to splice in nicer. Jon ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
Andy Ross wrote: Erik Hofman wrote: I think that needs a bit more thought. Most FDM's are just too heavy for having a lot of them work together. I think we need a NULL FDM with autopilot support for that. Exactly. It seems to me like we're swimming in half-finished multiplayer/multiaircraft/network-data/network-interface implementations. What we need really isn't another one to plug into the mess, it's someone to *finish* the whole project and (if possible) throw out all the old junk that isn't used anymore. I vote for pushing NetworkOLK to the bitkeeper by now. Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] a FIXME in fg_props.cxx
code:
static const char *
getDateString ()
{
static char buf[64]; // FIXME
struct tm * t = globals->get_time_params()->getGmt();
sprintf(buf, "%.4d-%.2d-%.2dT%.2d:%.2d:%.2d",
t->tm_year + 1900, t->tm_mon + 1, t->tm_mday,
t->tm_hour, t->tm_min, t->tm_sec);
return buf;
}
Why the FIXME in the declaration of buf? Is there a better way of doing
that? Is there a buffer overrun concern or something?
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
Erik Hofman writes: > I vote for pushing NetworkOLK to the bitkeeper by now. Yes, I'll second that, with appropriate thanks to Oliver for being the first one forge his way down that path. Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
On 11/11/03 at 6:55 PM Seamus Thomas Carroll wrote: >I have the timings you asked for. The output from my GroundActivity >class is as follows: >1) Total Time: 221.99 >2) total calc of lon, lat: 0.52 >3) total calc of elev: 116.74 >4) total model placement time: 0.95 > >1 is the total time flightgear has been running. >2 is the total time it took to calculate a new lon, lat. >3 is the total time to caluclate the elevation for the new lon, lat. >4 is the time to place the model at the new lat lon and elevation and set >it viewable. > >These timings were taken while 100 vehicles at 3 updates per second. > > >As you can see the time to calculate the elevation at a particular lat >lon is huge compared to the total run time. The method for >calculating the elevation was taken from FGAILocalTraffic::DoGroundElev(). >There must be a better way to calculate the elevation. Thanks for posting those. As you say, the time spent in DoGroundElev() looks quite frightening. I'm afraid I have no idea how to make the function call more efficient - walking hit lists and so forth isn't really my forte. However, it does look as though you are hitting it 300 times per second if every vehicle calls it every update. That 5 times per frame at 60fps. >From my point of view (taxiing aircraft) I could probably call it for the current position, and another position ahead, and interpolate between them, taking advantage of the fact that airports are naturally fairly flat and taxiing planes move fairly slowly, to keep it below one call per frame even with a number of aircraft. You might want to try something like this, although you may be handicapped by more undulations in non-airport terrain. Some sort of caching scheme might also be possible if your objects sometimes share or retrace paths. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
John Barrett wrote: > what I'm asking is "everything looks like it works through globals > rather than discrete instances of aircraft+fdm+autopilot -- am I > looking at a serious architectural change to get multiple > independent ac+fdm+ap simulated concurrently ??" Pretty sure, yeah. :) The last time I looked at FlightGear's "core internals" (most of my work, like the YASim FDM, is peripheral) was about a year ago, doing the 2D-panel-in-3D-cockpit hack. Lots of existing code was written to reference "The Panel" and some work had to be done to enable the notion of multiple panel objects. Likewise, there was no easy notion of "this aircraft" within the rendering tree (all you get is an ssg node walk back). I just hacked around this one and put in a global array of panel objects with a (hopefully obvious) comment that these should be per-aircraft when that capability arrived. FlightGear is an old code base, and lots of the old assumptions (like a single aircraft) need to be teased out of the code before progress can be made on new features. This kind of work isn't glamorous, and often requires more effort than the new development does. But it's not brain surgery either. The problem with some great new features is that they show up with code that is "ready" to integrate, but without the integration work done. So they languish in the CVS tree until everyone forgets about them. I can recall at least one occasion where a unused module got replaced by a simpler (and arguably less functional) one precicely because the original never got integrated very well and the replacement actually worked. The extreme programming cult manages to get this idea right (every religion has a kernal of truth, right?) with their insistence on constant refactoring and integration. Features are useless in isolation. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Repost] Simulating ground activity (fwd)
Dave Luff wrote: > Thanks for posting those. As you say, the time spent in > DoGroundElev() looks quite frightening. I'm afraid I have no idea how > to make the function call more efficient - walking hit lists and so > forth isn't really my forte. > > However, it does look as though you are hitting it 300 times per > second if every vehicle calls it every update. It could be worse. Every *gear* should call it every update. Right now, YASim handles the ground as a single plane for the whole aircraft, which is essentially a bug. It can't respond to small-scale bumps in the world geometry. In the FDM world, this isn't so strange at all; compared to the rest of the work involved in the simulation, it's peanuts. :) But for simply animating aircraft taxiing on a flat surface, it's overkill. I think your suggestion of interpolating between posts is a much better one. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Missing files or old docs?
in ..src/Main/README: fgfs.cxx fgfs.hxx This module defines FGSubsystem, the abstract base class (or interface) for subsystems in FlightGear. Most of the important subsystems already extend this class, and eventually, all subsystems will. Have these files been removed or did they go missing? I've been trying to find the "shutdown" portion of the main loop so that I might try to resolve the question posed in fg_props.hxx: extern void fgInitProps ();// fixme: how are they untied? A grep -R shows me that none of the properties that are "tied" in fgInitPorps() are "untied". g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
Jonathan Richards writes: > listgeo gives a whole shedload of information about the mapping, > too much to report here unless anyone's interested, in which case > mail me. I'd just like to take another opportunity to express my appreciation to the U.S. government for making so much geodata available free -- without their resources and (enlightened) policies, it would be awfully hard to do any free GIS work, much less a Flight Simulator (even the international projects are often mainly U.S.-led and -funded). FlightGear users who are Americans need to remember how important this kind of free information is. Those of us who are not Americans need to press our own governments to follow suit. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
On Wednesday, 12 November 2003 16:36, David Megginson wrote: > Those of us who are not Americans need > to press our own governments to follow suit. Bwaahahaha! Over here that would be like the ant asking an elephant to not step on him. Even our constitution get's changed without any consultation to suite the ruling party. The USGS is unfortunately a rare example of good governance. Where I live the tax payers pay to get the government to do surveys and then the government sells us the data. :( It's a pity spatial data is so damn expensive to purchase and full of copyright restrictions. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Scanned sectional charts online
David Megginson writes: > > Jonathan Richards writes: > > > listgeo gives a whole shedload of information about the mapping, > > too much to report here unless anyone's interested, in which case > > mail me. > > I'd just like to take another opportunity to express my appreciation > to the U.S. government for making so much geodata available free -- > without their resources and (enlightened) policies, it would be > awfully hard to do any free GIS work, much less a Flight Simulator > (even the international projects are often mainly U.S.-led and > -funded). Hear hear ! I downloaded one of the charts and yes undeed these are the real thing, to include many introduced colors due to the scanning process. I am not positive but I believe these are originally produced with either 16 or 20 distinct colors only. It is probably worth while finding out, but in any case I managed to produced a significantly smaller disk image by running an adaptive color reducer that recolored the map to use 16 colors and then remaped the white replacement color back to white This reduced the disk size to 17 megs from 40 with very little or no loss in percieved image quality. Note one should be able to get a moving map display out of these by setting up a mapserver http://mapserver.gis.umn.edu and having fgfs output a simple http request at fixed intervals. Of course Atlas could be modified too but it's probably less work to use mapserver since the geotiff support is already builtin Regardless the toughest part of getting this going should be 'collar clipping' the charts so as to get a seamless display :-) Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Geo formulae
I'm not sure how to compute this : If I lay out a runway in an unprojected view (flat) and then convert it into FG format (projected) how much will the runway be distorted at latitudes of 60 degrees? i.e How much distortion could I expect over a distance of 2-3 km at latitudes of 60 degrees? Obviously the worst case is for runways aligned in the East-West direction (90/270 degrees) If only the world was flat ... Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
Paul Surgeon writes: > I'm not sure how to compute this : > > If I lay out a runway in an unprojected view (flat) and then convert it into > FG format (projected) how much will the runway be distorted at latitudes of > 60 degrees? > i.e How much distortion could I expect over a distance of 2-3 km at latitudes > of 60 degrees? > Obviously the worst case is for runways aligned in the East-West direction > (90/270 degrees) > > If only the world was flat ... FlightGear goes to great lengths to map the airports correctly on the curved surface of the earth at any latitude. If I recall, the procedure converts each runway corner to an angle and distance from the center point, then it feeds this in as input to calculate the correct position on the surface of the wgs-84 world using full out wgs-84 ellipsoid math. (We don't even stoop to a spherical approximation, not that the relative difference over 5000' or less would be noticable.) So the answer is that you should see zero distortion in runways or between multiple runways at any latitude and at any alignment. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
On Wednesday, 12 November 2003 21:22, Curtis L. Olson wrote: >FlightGear goes to great lengths to map the airports correctly on the > curved surface of the earth at any latitude. > > If I recall, the procedure converts each runway corner to an angle and > distance from the center point, then it feeds this in as input to > calculate the correct position on the surface of the wgs-84 world > using full out wgs-84 ellipsoid math. (We don't even stoop to a > spherical approximation, not that the relative difference over 5000' > or less would be noticable.) Holy cow! About 25% of that passed right over my head. :) When you said that FlightGear goes to great lengths to map airports correctly I assume you mean that the TerraGear scenery building process does that? Am I correct in thinking that the data in the scenery files has already been projected correctly into WGS-84 format by TerraGear? If I laid a FG scenery tile out on a flat surface the runways would look pretty straight but the data defining them would be curved. Correct? Got more questions but let me take one step at a time. I'll go try find some info on the WGS-84 datum in the mean time - this stuff can be very confusing. Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
Paul Surgeon writes: > Holy cow! > About 25% of that passed right over my head. :) Good, you are doing better than me then. :-) > When you said that FlightGear goes to great lengths to map airports > correctly I assume you mean that the TerraGear scenery building > process does that? Yes. > Am I correct in thinking that the data in the scenery files has > already been projected correctly into WGS-84 format by TerraGear? Yes. > If I laid a FG scenery tile out on a flat surface the runways would > look pretty straight but the data defining them would be > curved. Correct? The FlightGear world preserves the shape of the wgs-84 ellipsoid, so if you draw things far enough out, you will see the actual curvature of the earth's surface. You would have all the same problems and issues flattening a section of the FlightGear world as if you would if you tried to lay the same section of real world out onto a flat surface. I should point out that wgs-84 is just another approximation of the actual shape of the earth and isn't exactly exact, but it is a *lot* better than a spherical approximation, and it is a ***lot*** better than any flat approximation/projection. > Got more questions but let me take one step at a time. I'll go try > find some info on the WGS-84 datum in the mean time - this stuff can > be very confusing. Yes it can be. There is some basic information on coordinate systems here: http://www.flightgear.org/Docs/Scenery/CoordinateSystem/CoordinateSystem.html And the following might be useful, up through section 2.3, after that you get into information about our previous ascii file format (which is similar to our binary structure.) http://www.flightgear.org/Docs/Scenery/SceneryGeneration/SceneryGeneration.html Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
On Wednesday, 12 November 2003 22:28, Curtis L. Olson wrote: > Good, you are doing better than me then. :-) What? I thought you wrote this stuff. > The FlightGear world preserves the shape of the wgs-84 ellipsoid, so > if you draw things far enough out, you will see the actual curvature > of the earth's surface. Yes you mean it actually wraps the data around an ellipsoid not on a flat plane like some simulators. It's a very nice accurate system although a bit complex to calculate mathematically (makes my head spin). > You would have all the same problems and issues flattening a section > of the FlightGear world as if you would if you tried to lay the same > section of real world out onto a flat surface. You have a good point there - now it's making sense. However it's just a lot easier to design/draw straight lines on a flat surface than a curved one, especially when writing scenery tools. > I should point out that wgs-84 is just another approximation of the > actual shape of the earth and isn't exactly exact, but it is a *lot* > better than a spherical approximation Well it's about the best and most common if I'm not mistaken. I doubt that if I fly around the equator I'm going to notice the extra 67.16km but it's nice to know that I won't have to fly that extra 15 mins. :) However it's good to know that FG does things "properly". Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
On 11/12/03 at 10:16 PM Paul Surgeon wrote: >On Wednesday, 12 November 2003 21:22, Curtis L. Olson wrote: >>FlightGear goes to great lengths to map the airports correctly on the >> curved surface of the earth at any latitude. >> >> If I recall, the procedure converts each runway corner to an angle and >> distance from the center point, then it feeds this in as input to >> calculate the correct position on the surface of the wgs-84 world >> using full out wgs-84 ellipsoid math. (We don't even stoop to a >> spherical approximation, not that the relative difference over 5000' >> or less would be noticable.) > >Holy cow! >About 25% of that passed right over my head. :) > >When you said that FlightGear goes to great lengths to map airports >correctly >I assume you mean that the TerraGear scenery building process does that? >Am I correct in thinking that the data in the scenery files has already >been >projected correctly into WGS-84 format by TerraGear? > >If I laid a FG scenery tile out on a flat surface the runways would look >pretty straight but the data defining them would be curved. Correct? > >Got more questions but let me take one step at a time. >I'll go try find some info on the WGS-84 datum in the mean time - this >stuff >can be very confusing. > Hi Paul, I'm not entirely sure what you're trying to do, or where in the world you're trying to do it to, but from some of your previous comments it sounds like you might be trying to overlay satelite or aerial photo images onto the scenery. I've had a slight play with overlaying aerial photos in the past. Some of this might be of interest. The first thing I did was to get code working to convert the UK coordinate system (OSGB36) to and from the World Geodetic System that FlightGear uses (WGS84). The code for that is in osgb36.[ch]xx in TerraGear, you should be able to find similar equations for the coordinate system used for the images you have for whatever part of the world you are working on (I believe some of the UTM projections might be implemented in fgsd). In general, the larger the area you are handling with a single projection system, the more the distortion (of the images) will become at the edges. I then chopped the images up along osgb36 grid lines (easy since that corresponds with our national mapping), so I added an alternative texture coordinate generation routine to Terragear (UK_calc_tex_coords, in osgbtc.[ch]xx) which is called in preference to the native Terragear texcoord routines in genobj.cxx for polygon files ending in .osgb36 if the --useUKgrid argument is passed in on the command line at build time (that's an area type polygon, not an actual 3D model polygon). By defining a polygon with the right UK coords and an existing material type (a few don't get used in the UK much, so I 'borrowed' them), and then altering that material type in the materials file (in the FG base package) to point to the image file of the same coords, I was able to seamlessly lay down a few aerial photo textures in *exactly* the right place. This also meant that the textures could be laid seamlessly across the whole UK, instead of having a step every so many degrees of latitude. The big problem is the hackery with the materials file which results in a small finite number of aerial photo tiles being available. I think I added extra materials to it named by their UK location and added textures up to the memory limit of my graphics card (32 meg at the time), but got no further. There needs to be some way to page the textures in and out as needed, but I haven't got as far as that yet (and this was a couple of years ago at least!). I'm hoping you'll find some of the answers and make it easy :-) If anyone who understands this is still reading, am I right in thinking that FG loads up all of the possible scenery textures mentioned in the materials file at startup and keeps them until shutdown, but only loads the 3d object textures as needed, and unloads them when the tile is unloaded, or am I mistaken here? Hope some of that rambling helps, it was a while ago so there might be some memory errors in there. I'm certainly not saying that you should attempt to do it the same, but it may give some ideas... Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
Paul Surgeon writes: > What? I thought you wrote this stuff. Yes, I wrote a lot of it, but I'm not claiming perfect memory. :-) > Yes you mean it actually wraps the data around an ellipsoid not on a > flat plane like some simulators. It's a very nice accurate system > although a bit complex to calculate mathematically (makes my head > spin). Fortunately, we can encapsulate all the messy math so you don't have to worry about it too much. > > You would have all the same problems and issues flattening a section > > of the FlightGear world as if you would if you tried to lay the same > > section of real world out onto a flat surface. > > You have a good point there - now it's making sense. However it's > just a lot easier to design/draw straight lines on a flat surface > than a curved one, especially when writing scenery tools. If you are looking at smaller, localized areas, you could probably do some hacks/approximations that would work reasonably well. You are right though, that for a scenery editor, this could get a little tricky. I'm not sure what the best answer is. If you are editing airport sized areas, you could probably get away with flattening it out during the interactive editing phase, then convert all the coordinats to (angle/distance) and use that to map them back to the wgs-84 world for FlightGear. > Well it's about the best and most common if I'm not mistaken. I > doubt that if I fly around the equator I'm going to notice the extra > 67.16km but it's nice to know that I won't have to fly that extra 15 > mins. :) > > However it's good to know that FG does things "properly". We try ... :-) Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Electrical system work..
In part of my learning the ins and outs of how FG really works, I found another space I can contribute - the electrical system. The current system has no way of handling circuit breakers or measuring a load across a whole bus. The system now expresses a bus like this: ... /systems/electrical/outputs/device /systems/electrical/outputs/device2 . . . What I propose is something like this: ... ... capacity_in_amps /systems/electrical/outputs/device /systems/electrical/outputs/device2 . . . At this point, the bus can be organized into multiple breaker protected circuits on a single bus. The only part of missing data is the Ampere draw of each device. This could be done within the electrical system definition like this: /systems/electrical/outputs/device load=n.n This would be the "easy" way to supply the data. However, I think it might be better if the power draw figure was part of the instrument definition itself. This would require 2 new tags added to the xml files that are used to define each instrument - I'm referring to the configurationd data found in data/Aircraft/Instruments. The first tag would be . This would be something like "nav-radio" or "avionics-fan". It would be used by the load calculator to locate the load value associated with a particular device. The second tag would be or or something similar. It would be a double value containing the total draw for the device. When the load calculator comes by, this is the number that gets added to the total (obviously). The idea is to allow custom devices to hold their own power draw values independant of the "wiring". For instance, you could change out the "stock" nav radio for some fancy unit that combines more than one function but has a higher power draw. The device would still be of the class "nav-radio" but would contain an updated power draw figure. The change would only occur within the instrument panel file and would make sure that no matter the unit installed, the power draw value would follow the device and not the "wiring harness". The circuit load would be calculated each time the electrical system's update method is called. If the total load exceeds the circuit capacity for longer than 2 seconds, the breaker would "pop" and power for that circuit would be cut off. If this is something that you think should be implemented, let me know and I'll start working on the code for it. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
On Wednesday, 12 November 2003 23:04, David Luff wrote: > Hi Paul, > > I'm not entirely sure what you're trying to do, or where in the world > you're trying to do it to, but from some of your previous comments it > sounds like you might be trying to overlay satelite or aerial photo images > onto the scenery. Close - same concept. :) > In general, the larger the area you are handling > with a single projection system, the more the distortion (of the images) > will become at the edges. Unless you project the textures properly onto a wgs84 ellipsoid. Will end up with some wasted space in the textures on the edges. > There needs to be some way to page the textures in and out as > needed Yes, I realised that FG does not do this yet and that some work will have to be done in that area to support aerial/satelite photos properly. > If anyone who understands this is still reading, am I right in thinking > that FG loads up all of the possible scenery textures mentioned in the > materials file at startup and keeps them until shutdown I get a strong feeling that this is the way it works (haven't stuck my head in the code to make certain). Ideally there should be two scenery texture directories. One for global/generic scenery textures One for scenery specific textures (each 1x1 or 10x10 tile has it's own texture directory) That will help keep area specific textures out of the global texture directory and facilitate with the dynamic loading and unloading of textures when the code get's written. If everything goes into a global folder and you have 1 aerial images the naming/numbering is going to get hairy and could lead to conflicts if someone else adds scenery but uses the same texture names. > 3d object textures as needed, and unloads them when the tile is unloaded, > or am I mistaken here? > Hope some of that rambling helps, it was a while ago so there might be some > memory errors in there. I'm certainly not saying that you should attempt > to do it the same, but it may give some ideas... I don't plan to hack/add to TerraGear since I want to keep my code separate/standalone because it's very specific and I want to do some proof of concept testing first. Thanks for the input though - I'll look through those files and see what I can gleen(steal) out of them. ;) Paul ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] C++ Terror!
On Wed, Nov 12, 2003 at 11:07:48AM +0100, Erik Hofman wrote: > Manuel Bessler wrote: > > > I've thrown together something similar with the plib js and net examples > > and changed the joyclient on fgfs side. This allows you to use a > > joystick port on another machine via the network. > > > > One thing I'd like to change is to make it configurable via the property > > tree what is being controlled by the remote joystick. I'm not sure if > > that'll work. > > > > I imagine something like this: > > fgfs --jsclient=socket,in,10,192.168.1.2,16759,udp > > --prop:/jsclient/axis[0]/binding="/controls/engines/engine[0]/throttle" > > --prop:/jsclient/axis[1]/binding="/controls/engines/engine[1]/throttle" > > > > > > Currently the protocol assumes 4 axes, 4 buttons. If less than 4 axes > > are installed on the joystick server, the unused axes will read zero. > > No provision for endian-ness yet. > > Okay, this is committed to CVS. Changes and updates are always welcome. OK, thanks. I'll send you the stuff when I get back to work at it. Regards, Manuel ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
Paul Surgeon writes: > > If anyone who understands this is still reading, am I right in thinking > > that FG loads up all of the possible scenery textures mentioned in the > > materials file at startup and keeps them until shutdown > > I get a strong feeling that this is the way it works (haven't stuck > my head in the code to make certain). FlightGear has a library of textures that are preloaded. However, if a scenery tile references a texture name that isn't in the library, it will attempt to load it on the fly from the current directory. However, once loaded, it stays resident forever. Like you say, to do this well, we would need some way to efficiently page texture data in and out. We'd also want to be able to load lowres mipmaps for distant stuff and hold off loading the full resolution version of the textures until they are close enough to actually be used. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing files or old docs?
Gene Buckle wrote: in ..src/Main/README: fgfs.cxx fgfs.hxx This module defines FGSubsystem, the abstract base class (or interface) for subsystems in FlightGear. Most of the important subsystems already extend this class, and eventually, all subsystems will. Have these files been removed or did they go missing? They moved over to SimGear/simgear/structure/subsystem.[ch]xx Erik ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Missing files or old docs?
> Gene Buckle wrote: > > in ..src/Main/README: > > > > fgfs.cxx > > fgfs.hxx > > This module defines FGSubsystem, the abstract base class (or > > interface) for subsystems in FlightGear. Most of the important > > subsystems already extend this class, and eventually, all subsystems > > will. > > > > > > Have these files been removed or did they go missing? > > They moved over to SimGear/simgear/structure/subsystem.[ch]xx Thanks Erik. g. ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Scanned sectional charts online
Paul Surgeon writes: > The USGS is unfortunately a rare example of good governance. > Where I live the tax payers pay to get the government to do surveys and then > the government sells us the data. :( Ditto for Canada. Fortunately, the U.S. is making more and more data free for our countries as well. All the best, David ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
Curtis L. Olson writes: > > Like you say, to do this well, we would need some way to efficiently > page texture data in and out. We'd also want to be able to load > lowres mipmaps for distant stuff and hold off loading the full > resolution version of the textures until they are close enough to > actually be used. One way todo this is to always use the same size texture so as to be able to use glTexSubImage2D() to control the level of detail and mipmaping ourselves. Easiest todo this if the scenery is laid out so when you go to a lower level texture it covers 4 times the area and visa versa This works with SimGear's latitude adjusted tile 'bands' as they are broken into 8x8 sub grids :-) Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
On 11/12/03 at 5:36 PM Norman Vine wrote: >Curtis L. Olson writes: >> >> Like you say, to do this well, we would need some way to efficiently >> page texture data in and out. We'd also want to be able to load >> lowres mipmaps for distant stuff and hold off loading the full >> resolution version of the textures until they are close enough to >> actually be used. > >One way todo this is to always use the same size texture so as to >be able to use glTexSubImage2D() to control the level of detail and >mipmaping ourselves. > >Easiest todo this if the scenery is laid out so when you go to >a lower level texture it covers 4 times the area and visa versa > >This works with SimGear's latitude adjusted tile 'bands' as they are >broken into 8x8 sub grids :-) > I'm not entirely clear on this - are mipmaps pre-built and available on disk for FG to load, or are they built from the main texture at runtime? Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
David Luff writes: > >One way todo this is to always use the same size texture so as to > >be able to use glTexSubImage2D() to control the level of detail and > >mipmaping ourselves. > > > >Easiest todo this if the scenery is laid out so when you go to > >a lower level texture it covers 4 times the area and visa versa > > > >This works with SimGear's latitude adjusted tile 'bands' as they are > >broken into 8x8 sub grids :-) > > > > I'm not entirely clear on this - are mipmaps pre-built and available on > disk for FG to load, or are they built from the main texture at runtime? This can get to be a really complicated subject if we let it. But, as it works now, a single full res texture is stored on the disk. It is loaded at run time, and the mipmaps are generated using a simple 2x2 -> 1x1 averaging scheme. (I think this is called a box filter.) This generally works ok, except for textures with an alpha component. (The alpha compenent also get's averaged, so an increasingly disproportionatly large portion of the texture becomes partially translucent as the lower level mipmaps are generated.) As each mipmap level is created in memory, it is submitted to the on-video-card ram. There is a glu function that does this I believe. For paging textures it might make sense to pregenerate and store all the mipmaps ... this would increase on-disk texture space by a factor of 2. But it would mean generally less disk I/O I think, since many areas on the fringe perpendicular to your flight path would never need more than the lowest level mipmap loaded. But, we could always just do the internal mipmap generation as we need it. That would mean keeping a copy of the full res texture in main ram though. Regards, Curt. -- Curtis Olson HumanFIRST Program FlightGear Project Twin Citiescurt 'at' me.umn.edu curt 'at' flightgear.org Minnesota http://www.flightgear.org/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
David Luff wrote: > I'm not entirely clear on this - are mipmaps pre-built and available > on disk for FG to load, or are they built from the main texture at > runtime? The latter. I believe in our case it's done by plib, but there's a standard gluBuild2DMipmaps() routine in OpenGL too. The time it takes to generate the mipmaps with the CPU is much less than the time it would take to read them off the disk. Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of David Luff > Sent: Wednesday, November 12, 2003 5:39 PM > To: FlightGear developers discussions > Subject: RE: [Flightgear-devel] Geo formulae > > > On 11/12/03 at 5:36 PM Norman Vine wrote: > > >Curtis L. Olson writes: > >> > >> Like you say, to do this well, we would need some way to efficiently > >> page texture data in and out. We'd also want to be able to load > >> lowres mipmaps for distant stuff and hold off loading the full > >> resolution version of the textures until they are close enough to > >> actually be used. > > > >One way todo this is to always use the same size texture so as to > >be able to use glTexSubImage2D() to control the level of detail and > >mipmaping ourselves. > > > >Easiest todo this if the scenery is laid out so when you go to > >a lower level texture it covers 4 times the area and visa versa > > > >This works with SimGear's latitude adjusted tile 'bands' as they are > >broken into 8x8 sub grids :-) > > > > I'm not entirely clear on this - are mipmaps pre-built and available on > disk for FG to load, or are they built from the main texture at runtime? Currently FGFS blindly lets PLib / OpenGL take care of the mipmaps The method I mention is a way for FGFS to take over control. Note this would require some restructuring to implement. But its *very* doable Cheers Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Geo formulae
Curtis L. Olson wrote: > This can get to be a really complicated subject if we let it. But, > as it works now, a single full res texture is stored on the disk. > It is loaded at run time, and the mipmaps are generated using a > simple 2x2 -> 1x1 averaging scheme. (I think this is called a box > filter.) Yeah. This is considered the "naive" way to do it because it's easy to get aliasing artifacts if notable features in the input image are aligned on power-of-two boundaries. I know that Steve Baker likes the idea of FFTing the data first and chopping off the high frequencies in fourier coordinates. This *also* has aliasing artifacts, but they look different. Sharp edges in the input data get "ringing" structures around them, not unlike what you see with JPEG decompression. I've heard of "jittered" averaging too, which tries to avoid aliasing artifacts statistically by picking slightly random offsets during the averaging (this is sort of the opposite of the jittered supersampling that gets done with CG rendering). Needless to say, which algorithm you choose is going to depend in very sensitive ways on your texture image. And then, of course, your choice of LOD bias and texture anisotropy needs to be factored in. My $0.02, obviously, is to forget the whole issue and spend your time on image quality issues that matter, like fancier Airplane models or the distracting pixelation on the current A-4 textures. :) Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
Curtis L. Olson writes: > > But, we could always just do the internal mipmap generation as we need > it. That would mean keeping a copy of the full res texture in main > ram though. Not necessarily. i.e. glTexSubImage2D() actually replaces the texture content so as to have it cover 4 times the area. You want to update the Geometry too so as to coordinate this of course but with collapsible vertex lists such as terrafit produces this isn't to tough Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
Andy Ross writes: > > David Luff wrote: > > I'm not entirely clear on this - are mipmaps pre-built and available > > on disk for FG to load, or are they built from the main texture at > > runtime? > > The latter. I believe in our case it's done by plib, but there's a > standard gluBuild2DMipmaps() routine in OpenGL too. The time it takes > to generate the mipmaps with the CPU is much less than the time it > would take to read them off the disk. True enough but once you run out of card memory you have lost. With the method I described you are covering 4 times the area with the same amount of on card memory every time you do a LOD step Norman ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
> In the current code -- there is just the single airplane being simulated on
> the display ?? or where could I find a list/array of a/c that are being
> managed so I can register each plane with the server and have the server
> relay updates for all of them ??
Look in the src/ATC directory. There you will find an FGAIMgr class that
instantiates aircraft. The aircraft themselves are derived from FGAIEntity
via FGAIPlane. Presently the only AI airplane in the base package is a
cessna flying out of KEMT (in the Los Angeles basin).
> (if its just the one plane, once I get it to fly multiplayer, my focus will
> be to add multiple/AI plane support to the code, so comments towards
> achieving that goal will be welcome also)
You can add more AI aircraft to the FGAIMgr's list:
// Activate AI traffic at an airport
void FGAIMgr::ActivateAirport(string ident) {
ATC->AIRegisterAirport(ident);
// TODO - need to start the traffic more randomly
FGAILocalTraffic* local_traffic = new FGAILocalTraffic;
//local_traffic->Init(ident, IN_PATTERN, TAKEOFF_ROLL);
local_traffic->Init(ident);
local_traffic->FlyCircuits(1, true);// Fly 2 circuits with touch & go in
between
FGAITanker* tanker = new FGAITanker;
tanker->Init();
ai_list.push_back(local_traffic);
ai_list.push_back(tanker);
activated[ident] = 1;
}
Here I've added another AI plane, a KC-135 called FGAITanker, that orbits over
the LA basin. Presently the AI traffic's FDM is contained within the class
derived from FGAIPLane. So the Cessna and the tanker use entirely different
FDMs. A more generalized approach would be to move the FDM into FGAIPlane.
I started working on a generalized and scriptable version of my tanker, but
have been sidetracked by other stuff. Let me know if you want the tanker
code and I'll send it to you.
Dave
--
David Culp
davidculp2[at]comcast.net
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
- Original Message -
From: "David Culp" <[EMAIL PROTECTED]>
To: "FlightGear developers discussions" <[EMAIL PROTECTED]>
Sent: Wednesday, November 12, 2003 7:51 PM
Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ...
> In the current code -- there is just the single airplane being simulated
on
> the display ?? or where could I find a list/array of a/c that are being
> managed so I can register each plane with the server and have the server
> relay updates for all of them ??
Look in the src/ATC directory. There you will find an FGAIMgr class that
instantiates aircraft. The aircraft themselves are derived from FGAIEntity
via FGAIPlane. Presently the only AI airplane in the base package is a
cessna flying out of KEMT (in the Los Angeles basin).
> (if its just the one plane, once I get it to fly multiplayer, my focus
will
> be to add multiple/AI plane support to the code, so comments towards
> achieving that goal will be welcome also)
You can add more AI aircraft to the FGAIMgr's list:
// Activate AI traffic at an airport
void FGAIMgr::ActivateAirport(string ident) {
ATC->AIRegisterAirport(ident);
// TODO - need to start the traffic more randomly
FGAILocalTraffic* local_traffic = new FGAILocalTraffic;
//local_traffic->Init(ident, IN_PATTERN, TAKEOFF_ROLL);
local_traffic->Init(ident);
local_traffic->FlyCircuits(1, true); // Fly 2 circuits with touch & go in
between
FGAITanker* tanker = new FGAITanker;
tanker->Init();
ai_list.push_back(local_traffic);
ai_list.push_back(tanker);
activated[ident] = 1;
}
Here I've added another AI plane, a KC-135 called FGAITanker, that orbits
over
the LA basin. Presently the AI traffic's FDM is contained within the class
derived from FGAIPLane. So the Cessna and the tanker use entirely different
FDMs. A more generalized approach would be to move the FDM into FGAIPlane.
I started working on a generalized and scriptable version of my tanker, but
have been sidetracked by other stuff. Let me know if you want the tanker
code and I'll send it to you.
Dave
--
David Culp
davidculp2[at]comcast.net
Sounds good -- like most of what I'm looking for is there -- would definitly
like to look over the code and see how much work to hook it into my network
setup
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
RE: [Flightgear-devel] Geo formulae
On 11/12/03 at 4:45 PM Curtis L. Olson wrote: >David Luff writes: >> I'm not entirely clear on this - are mipmaps pre-built and available on >> disk for FG to load, or are they built from the main texture at runtime? > >This can get to be a really complicated subject if we let it. ...snip lots! Thanks Curt, Norman, Andy, for the explanations and various viewpoints. Its something to think over! Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] [Multiplayer] Oh where Oh where .......
On 11/12/03 at 8:08 PM John Barrett wrote: > >Sounds good -- like most of what I'm looking for is there -- would >definitly >like to look over the code and see how much work to hook it into my network >setup > Sorry - I thought you were looking for an fdm-autopilot based solution, else I'd have mentioned this! It would actually be very useful for the AI logic development if Atlas could then work as a client and display all the traffic. Could be the basis of the human ATC station as well, by adding altitude labels to the display in Atlas. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
- Original Message - From: "David Luff" <[EMAIL PROTECTED]> To: "FlightGear developers discussions" <[EMAIL PROTECTED]> Sent: Wednesday, November 12, 2003 8:20 PM Subject: Re: [Flightgear-devel] [Multiplayer] Oh where Oh where ... > On 11/12/03 at 8:08 PM John Barrett wrote: > > > >Sounds good -- like most of what I'm looking for is there -- would > >definitly > >like to look over the code and see how much work to hook it into my > network > >setup > > > > Sorry - I thought you were looking for an fdm-autopilot based solution, > else I'd have mentioned this! > > It would actually be very useful for the AI logic development if Atlas > could then work as a client and display all the traffic. Could be the > basis of the human ATC station as well, by adding altitude labels to the > display in Atlas. > > Cheers - Dave > Yes I would prefer an ac+fdm+autopilot solution strictly for realism purposes -- but anything that instances planes controled by FG needs to be hooked into my network code so that ac status updates can be made visible to all other participants. AIPlane definitly meets some of my needs based on the descriptions and a quick peek at the code. The main area where AIPlane falls short IMO is the hard coded AI functionality -- so here we go: I would like to request your ideas and wishes for an aircraft AI scripting language sufficiently generic in scope to handle piloting any aircraft running on FG. I can see right off that it must be event driven, able to interupt its current procedure/task in response to external inputs, able to process complicated nested procedures with completion of a "statement" based on the current aircraft state or external inputs such as radio message or radar. It must span every level of interaction from "turn the plane to a specific heading" or "change altitude to a specified level" at the low end, up to extremely abstract commands like "fly the plane to to a specified airport and land" which would encompass all the procedures and interactions neccessary to take off from one airport and land at another, including all standard interactions with ATC and other planes along the way. At the bottom end, the script module should generate commands suitable to feed to an autopilot, AIPlane or, if desirable, directly to the plane being simulated (I havent looked at how kb/stick inputs interface to the simulation - do they feed into the fdm ??) -- this may end up requiring multiple "output" interfaces for the scripting engine. The reason I was looking at ac+fdm+ap is the autopilot provided out-of-the-box low level code to manuever the plane without the AI code needing to know the specifics of how to make the plane perform a given manuever. Adding low level capabilities to the autopilot would the expand the range of capabilities for the AI scripts. (think of the autopilot as the hardcoded manuevers that form the core of the AI language -- anything more complicated than that would be handled by scripted AI procedures based on the core manuevers) Another thought just hit me -- the engine will have to handle the idea that different planes may have different low level routines, for instance, how you setup and perform a takeoff is different for every plane, so a generic script in common use by many planes must use the low level routines for the specific plane being controlled, wether or not that low level routine is hard coded or scripted (i.e. aircraft specific commands/procedures override more generic code in any shared command/procedure library) Any other ideas and suggestions of what such an aircraft scripting/AI language/engine might need ?? ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] ACScript RFC (or FGScript ??)
> I would like to request your ideas and wishes for an aircraft AI scripting > language sufficiently generic in scope to handle piloting any aircraft > running on FG. My generalized AI airplanes were originally going to be defined in preferences.xml (like the ai-tanker), something like this for each instance desired: prop-transport Aircraft/DC6/Models/DC6-model.xml 2.00 Scripts/ai_script01.xml The above would instantiate the plane (or truck, boat), assign it a visual model, indicate how many minutes into the sim session it should appear, and indicate the path to this object's script. The script would look like:
Re: [Flightgear-devel] a FIXME in fg_props.cxx
* [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
> code:
>
> static const char *
> getDateString ()
> {
> static char buf[64]; // FIXME
> struct tm * t = globals->get_time_params()->getGmt();
> sprintf(buf, "%.4d-%.2d-%.2dT%.2d:%.2d:%.2d",
> t->tm_year + 1900, t->tm_mon + 1, t->tm_mday,
> t->tm_hour, t->tm_min, t->tm_sec);
> return buf;
> }
>
> Why the FIXME in the declaration of buf? Is there a better way of doing
> that? Is there a buffer overrun concern or something?
We should at least be using snprintf() here.
Pardon me while I gripe a moment. It's usually a good idea to put a
description next to a FIXME comment for precisely this reason. It would
be a great help to people who are looking for something to do.
It's also usually a good idea to keep a constant CVS repository so we
can go back and see who added this code and if they said anything in the
cvs-commit message about what is broken. All of the CVS history prior
to Flightgear-0.9.0 is gone. :-/
gripe_mode=0;
--
Cameron Moore
[ I'm ashamed the lead singer of the Dixie Chicks is from Texas. ]
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
On Wed, 12 Nov 2003, Cameron Moore wrote:
> * [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
> > code:
> >
> > static const char *
> > getDateString ()
> > {
> > static char buf[64]; // FIXME
> > struct tm * t = globals->get_time_params()->getGmt();
> > sprintf(buf, "%.4d-%.2d-%.2dT%.2d:%.2d:%.2d",
> > t->tm_year + 1900, t->tm_mon + 1, t->tm_mday,
> > t->tm_hour, t->tm_min, t->tm_sec);
> > return buf;
> > }
> >
> > Why the FIXME in the declaration of buf? Is there a better way of doing
> > that? Is there a buffer overrun concern or something?
>
> We should at least be using snprintf() here.
>
So what makes snprintf() a better choice than sprintf()?
g.
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
On Wed, Nov 12, 2003 at 09:54:34PM -0800, Gene Buckle wrote:
>
> On Wed, 12 Nov 2003, Cameron Moore wrote:
>
> > * [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
> > > code:
> > >
> > > static const char *
> > > getDateString ()
> > > {
> > > static char buf[64]; // FIXME
> > > struct tm * t = globals->get_time_params()->getGmt();
> > > sprintf(buf, "%.4d-%.2d-%.2dT%.2d:%.2d:%.2d",
> > > t->tm_year + 1900, t->tm_mon + 1, t->tm_mday,
> > > t->tm_hour, t->tm_min, t->tm_sec);
> > > return buf;
> > > }
> > >
> > > Why the FIXME in the declaration of buf? Is there a better way of doing
> > > that? Is there a buffer overrun concern or something?
> >
> > We should at least be using snprintf() here.
> >
> So what makes snprintf() a better choice than sprintf()?
>
snprintf(buf, buflen, format, ...) will not write more than buflen
characters (including the trailing '\0') - this protects you against
a possible buffer overflow . . .
It probably isn't necessary in this case, but it's a Good Habit To
Get Into(tm).
Simon
--
PGP public key Id 0x144A991C, or http://himi.org/stuff/himi.asc
(crappy) Homepage: http://himi.org
doe #237 (see http://www.lemuria.org/DeCSS)
My DeCSS mirror: ftp://himi.org/pub/mirrors/css/
pgp0.pgp
Description: PGP signature
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] a FIXME in fg_props.cxx
On Thursday 13 November 2003 06:54, Gene Buckle wrote:
> On Wed, 12 Nov 2003, Cameron Moore wrote:
> > * [EMAIL PROTECTED] (Gene Buckle) [2003.11.12 10:35]:
> > > static const char *
> > > getDateString ()
> > > {
> > > static char buf[64]; // FIXME
> > > struct tm * t = globals->get_time_params()->getGmt();
> > > sprintf(buf, "%.4d-%.2d-%.2dT%.2d:%.2d:%.2d",
> > > t->tm_year + 1900, t->tm_mon + 1, t->tm_mday,
> > > t->tm_hour, t->tm_min, t->tm_sec);
> > > return buf;
> > > }
> > We should at least be using snprintf() here.
> So what makes snprintf() a better choice than sprintf()?
With snprintf, you can make sure buf will never overflow. Though I guess
it's impossible to overflow buf with the format-string that's used now.
--Ivo
___
Flightgear-devel mailing list
[EMAIL PROTECTED]
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
[Flightgear-devel] Re: [Flightgear-users] My screen shot.
Jim Howarth wrote: > Ahhh... Well.. I got to it.. Started to fly under it and flightgear > crapped out.. No. It just flagged a collision. The FDMs can only ask FlightGear "how high above sea level is the ground at this location?". This is fine for doing ground handling on runways. But the problem is that this models the whole world as an elevation field -- there's no notion of "under" in such a data model. So the second you flight into an area where the tallest scenery object is higher than you, you appear to hit a wall. The existing hit list code works well and runs fast, so it hasn't been tinkered with to try to fix this. The "right" interface would be a way for the FDM to hand a bunch of line segments (not points; landing gear can compress) to FlightGear and get back an indication of where along that line an intersection occurred. Something like: // Just in case someone is interested in writing this. :) // // Returns true if the line segment intersects. The intersection // point is returned in "isect", where a value of 0 indicates point // a, and 1.0 indicates b. bool fgGetSceneryIntersection(Point3D a, Point3D b, float* isect); Andy ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
