Re: [Flightgear-devel] New super/turbo MP code is in
On Tuesday 19 July 2005 12:29, Vivian Meazza wrote: > Peter Stickney > OK, so what we have here is a 2 stage supercharger. The first stage is the 2 > turbos and the second stage is the single stage gear-driven supercharger. Right. That will hold for any other turbosupercharged airplane, other than some of the light airplanes, that you'll come across. > I have enough data now for a reasonable simulation, but to make it more > accurate, I wonder if you could describe the action of the supercharger > pressure regulator? I can model it as just controlling the manifold pressure > between 0 and full. I interpret 0.8 (#8 on the dial) as being the setting > for full throttle height (military power). Settings 9 and 10 are emergency > settings. Did the controller act on the throttle, or a control a wastegate > to adjust the turbos, or just dump pressure, or? The controller used the Manifold Pressure at the engine inlet manifold to control the turbo's output. If you opened the throttle, you got more output from the turbo. If you increased the RPM (Prop to Full Increase), the turboregulator noted the higher pressure coming from the engine-stage blower and cut the turbo back. (With a controllable pitch prop, especially a constant speed prop, the throttle and the RPM are decoupled. The prop conrols RPM by changing its pitch. The throttle controls torque, which is indicated as MAP or BMEP settings. The turbo's output was controlled via the wastegates in the exhaust end. It really wasn't that much of an issue - airplane engine power settings don't get changed much, or in any great range, even for fighters in combat, so any lag wasn't a big deal. Somebody mentioned having a "Failure Mode" if you turned the boost up to 11 for too long. My experience with turbosuperchargers (I haven't blown up any airplane turbos, but I've killed a few on cars) is that the usual failure mode when the bearing is overtemped (Which is what you'd be doing) is for it to freeze. It doean't block inlet of exhaust flow much, but your Critical Altitude will suddenly drop from 25,000' to 7,000', and you might also get a fire going. > > But that's not the only way to do it. I've been preparing a series of > > articles on supercharging reciprocating engines. Is there any > > interest for me to pull some of it out and present it here? > > Probably not here, but personally I would be _most_ interested in anything > you have on this subject. I'll be in touch. Jon Berndt suggested the JBSSim Newsletter. I'm looking into that, and a few other things. > I have been struck by the lack of detailed information on the web on the > R3350, a stark contrast to the Merlin/Griffon. Rolls has always had good press agents :). Actually, it's rather hard to find good data on most engines. (Including Merlins) It's one of those areas where details can count. > Thanks > > Vivian > > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
Pigeon wrote: >>So, basically you get an invisible UFO and don't show up as a player, right? > > > Hmm I would imagine the server doesn't need to broadcast these > observers to others. It's not an actual player. > > I suppose using an invisible aircraft would work now as an observer. > If the server could handle something like if someone connecting with a > callsign "observer", then it would simply send packets to the observer > about other real players, but don't need to get another info from the > observer itself, except, perhaps, logging on or off. That will also mean > the server needs to be happy with multiple connection with the same > callsign. So I'd say it might be better to just treat them as a special > class of clients. > > > Pigeon. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Right, it would be silly to send all that data to the server when all it needs to know is where your are and what you can see. Plus the position data could be sent at low resolution. Either way the server would have to be able to handle multiple instances of the same callsign. Otherwise an invisible observer could silently prevent a flier from connecting. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Re: suggestions/questions regarding multiplayer
> So, basically you get an invisible UFO and don't show up as a player, right? Hmm I would imagine the server doesn't need to broadcast these observers to others. It's not an actual player. I suppose using an invisible aircraft would work now as an observer. If the server could handle something like if someone connecting with a callsign "observer", then it would simply send packets to the observer about other real players, but don't need to get another info from the observer itself, except, perhaps, logging on or off. That will also mean the server needs to be happy with multiple connection with the same callsign. So I'd say it might be better to just treat them as a special class of clients. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: suggestions/questions regarding multiplayer
Pigeon wrote: > Got a little further suggestion with the multiplayer. It's probably > just a server side thing though. > > It might be worthwhile for the server to accept "observer" client. > You can connect to the server as an observer, i.e. no aircraft. You get > information about players online, where they are, etc. Could be useful > for doing things like an online map on a webpage to show who's currently > online and where they are on a graphical map. Would be cool when later > atlas supports showing multiple aircrafts. > > > Pigeon. > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > So, basically you get an invisible UFO and don't show up as a player, right? Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: suggestions/questions regarding multiplayer
Got a little further suggestion with the multiplayer. It's probably just a server side thing though. It might be worthwhile for the server to accept "observer" client. You can connect to the server as an observer, i.e. no aircraft. You get information about players online, where they are, etc. Could be useful for doing things like an online map on a webpage to show who's currently online and where they are on a graphical map. Would be cool when later atlas supports showing multiple aircrafts. Pigeon. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Couple of Windows-related questions
Thank you very much. That's exactly what I needed. Drew On 7/19/05, Frederic Bouvier <[EMAIL PROTECTED]> wrote: > Quoting Drew : > > > Hi, > > > > I'm wondering if there is a way to run FlightGear without the 'command > > prompt' window opening, or at least to have it minimized when it > > opens. Is there a way to do this? > > > > Also, I've looked for a 'borderless window' option in the OpenGL > > commands with no success. Is there a way to create a borderless > > window that *isn't* full-screen mode? > > > > Thanks for any help you can give. > > Do you mean for your own compiled version, or for the released win32 binary ? > > We found that hidding the console for the release may seems pretty but was > highly unpractical when it comes to help users that are unable to see the > errors messages printed on the console. So it was filed as a false good idea > and now the console of fgfs is shared with the one of fgrun. > > If you want to do it in your own project, you just have to change a link > option. > Replace /subsystem:console by /subsystem:windows and relink > > -Fred > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] suggestions/questions regarding multiplayer
Ampere K. Hardraade ... snip ... > > > As Pigeon said, make that a separate window, because the ATC line is > > allready nearly impossible > > to read ;) It should not be hard to code but the atc code is not good > > for that (anyway it does not > > queue messages). > I agree. That ATC line is horrible. > > Use a Nasal-generated transparent window instead. One will then have > control > over the font size, font style, font color of the displayed text, as well > as > the number of lines that can be displayed. As for the message buffer, a > queue can be used. There is a queue written in Nasal already: > http://cvs.flightgear.org/cgi- > bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?r > ev=1.3&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup > I don't think we want competing methods for essentially the same function. If the ATC line is unreadable - (it's just about OK if you toggle the menu) - then that needs fixing up as well. Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
On July 19, 2005 06:33 am, Oliver Schroeder wrote: > 1) "out of reach" > . . . This will need to apply on chat messages as well. > 3) artificial life at airports > . . . There is a traffic manager in FlightGear. May be you can make use of that. On July 19, 2005 01:27 pm, Harald JOHNSEN wrote: > For VFR we have a nearly hard coded limit of 10 NM from the metar, and > at that range I don't think > one can really see another aircraft. > If your plane has some TCAS instrumentation then you will need perhaps > 20 to 40 nm. I do not think there is a need to make a special case for TCAS capable aircrafts. > As Pigeon said, make that a separate window, because the ATC line is > allready nearly impossible > to read ;) It should not be hard to code but the atc code is not good > for that (anyway it does not > queue messages). I agree. That ATC line is horrible. Use a Nasal-generated transparent window instead. One will then have control over the font size, font style, font color of the displayed text, as well as the number of lines that can be displayed. As for the message buffer, a queue can be used. There is a queue written in Nasal already: http://cvs.flightgear.org/cgi-bin/viewcvs/viewcvs.cgi/data/Aircraft/A380/Systems/AFDX/Switch/queue.nas?rev=1.3&cvsroot=FlightGear-0.9&content-type=text/vnd.viewcvs-markup Ampere ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder > some of you may already have taken notice of my multiplayer server for > flightgear (http://www.o-schroeder.de/fg_server). It's working quite well > in > sane environments but I want to improve it and therefor have some > questions > you may be able to answer. > ... snip ... > > 3) artificial life at airports > The server gives a lot of opportunities. One of the first things which > came > to my mind was artificial traffic at airports. It should be fairly easy > to > write clients in any (network capable) language which do simulate a > client. > This can be simply a helicopter standing near a hangar or even a plane > flying > around an airport. This would disburden fgfs itself (since it does not > need > to create AI traffic itself) and allow an arbitrary number of artificial > clients, each serving it's "own" airport (or whatever area), bringing life > to > many areas of the world without manipulating fgfs itself. > Would a dedicated instance of FlightGear running all the AI traffic needed and passing them to the server for distribution to all players do the trick? (filtering by range if that's how you decide to do it). We would like something like this for the carrier in any case. We should be aiming for the server to co-ordinate the whole environment - traffic, weather, time. We need to be clever about bandwidth though - and only send this kind of background data strictly when needed. The client FGFS will have to do much of the work, I suppose. Regards, Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
> > > So the question is: How can I easily calculate the distance and how
> > > many nautical miles are "out of reach" (thinking of e.g. radar systems)
> > > ?
> >
> > You can compute distance at an altitude using SimGear functions
>
> Ack, don't even *think* about doing the math in a GIS datum.
I agree. You don't need overkill here. A simple check of the bounding square
should work fine. Something like this:
/* Check if position 2 is within a square of side R nautical miles that has
position 1 at a corner. This is a fast approximation of checking the distance
between them, avoiding the use of trigonometric or sqrt functions. This
assumes latitude in the range (-90,90) and longitude (-180,180).
*/
bool IsWithinRMiles( double lat1, double lon1, double lat2, double lon2,
double R ) {
double nm_per_deg_lat = 60.313;
double nm_per_deg_lon = 60.109 - fabs(lat1 * 0.66788);
double lat_diff = fabs(lat1 - lat2);
double lon_diff = fabs(lon1 - lon2);
if (lon_diff > 180.0) lon_diff = 360.0 - lon_diff;
if ((lat_diff * nm_per_deg_lat) < R) {
if ((lon_diff * nm_per_deg_lon) < R) {
return true;
}
}
return false;
}
This should be good enough for deciding if object2 should be visible to
object1, as long the range you're checking for isn't too small. I would use
20 nm for a visibility test.
To get a more accurate distance check (for instance, radar range) you'll need
to call a sqrt function in the test:
if ( sqrt( (lat_diff * lat_diff * nm_per_deg_lat * nm_per_deg_lat) +
(lon_diff * lon_diff * nm_per_deg_lon * nm_per_deg_lon)) < R) {
return true;
}
To get even more accuracy you can use trigonometric functions in the
nm_per_deg calculations (see AIModel/AIBase.cxx for the feet_per_deg
formulas).
Dave
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Oliver Schroeder wrote: 1) "out of reach" [...] So the question is: How can I easily calculate the distance and how many nautical miles are "out of reach" (thinking of e.g. radar systems) ? I think the range should be user configurable. For VFR we have a nearly hard coded limit of 10 NM from the metar, and at that range I don't think one can really see another aircraft. If your plane has some TCAS instrumentation then you will need perhaps 20 to 40 nm. If you are a traffic controler you want more than that. 2) chat messages [...] protocoll supports chat-messages and the ATC-module has functions to queue and display them on screen. So it should'nt be too hard to combine them and enable chat-messages. Somebody willing to give it a try? As Pigeon said, make that a separate window, because the ATC line is allready nearly impossible to read ;) It should not be hard to code but the atc code is not good for that (anyway it does not queue messages). 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's "own" airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. The idea is interesting, but at the same time FG allready include the infrastructure to spawn entities and animate them, and when we will add new animations like trains, forest fire or gates I would like to have them even in the standalon version of FG. If you want to 'inject' new entities via the server you could just launch a copy of FG without rendering near your server and choose an ai scenarii to load. Harald. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] fgfs hangs loading scenery objects (some AC and airports but not all)
This bug showed up when I updated from CVS last weekend. Description follows: (1) With the default c172, fgfs hangs with the "loading scenery objects" is displayed if --airport= (any airport from w110n40) It does not hang for the j3cub or the pa28-161. (2) With (atleast som) airports outside w110n40 and the default c172, it does not hang. Here are some examples: [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=j3cub Failed to find runway 28R at airport KLBF RenderTexture Error: Couldn't find a suitable pixel format. Reading xml electrical system model from /usr/local/FlightGear/Aircraft/j3cub/cub-electrical.xml WARNING: Legacy engine definition in YASim configuration file. Please fix. (ran fine) [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=c172 Failed to find runway 28R at airport KLBF RenderTexture Error: Couldn't find a suitable pixel format. (I killed fgfs by closing the window after it hang) fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion `fgState.Initialised' failed. Aborted [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KLBF --aircraft=pa28-161 Failed to find runway 28R at airport KLBF RenderTexture Error: Couldn't find a suitable pixel format. Reading xml electrical system model from /usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml WARNING: Legacy engine definition in YASim configuration file. Please fix. (ran fine) [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=pa28-161 Failed to find runway 28R at airport KBJC RenderTexture Error: Couldn't find a suitable pixel format. Reading xml electrical system model from /usr/local/FlightGear/Aircraft/Generic/generic-electrical.xml WARNING: Legacy engine definition in YASim configuration file. Please fix. (ran fine) [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KBJC --aircraft=c172 Failed to find runway 28R at airport KBJC RenderTexture Error: Couldn't find a suitable pixel format. (I killed fgfs by closing the window after it hang) fgfs: freeglut_cursor.c:86: glutSetCursor: Assertion `fgState.Initialised' failed. Aborted [EMAIL PROTECTED] FlightGear]$ ./bin/fgfs --fg-scenery=/usr/local/Scenery-0.9.8 --airport=KDSM --aircraft=c172 Failed to find runway 28R at airport KDSM RenderTexture Error: Couldn't find a suitable pixel format. Initializing Nasal Electrical System (ran fine) [EMAIL PROTECTED] FlightGear]$ The scenery is from 0.9.8 on www.flightgear.org. I did an update of plib, SimGear, and fgfs source as well as the contents $FG_ROOT using "cvs update -dP" and did a "make clean" before recompiling all before the above examples were run. Was running great from cvs before last weekend update. System: Athlon 3200+ XP with 512 MB of PC3200, NVIDIA FX 5600 ultra. MB Biostar M7NCD Ultra Wierd bug? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Couple of Windows-related questions
Quoting Drew : > Hi, > > I'm wondering if there is a way to run FlightGear without the 'command > prompt' window opening, or at least to have it minimized when it > opens. Is there a way to do this? > > Also, I've looked for a 'borderless window' option in the OpenGL > commands with no success. Is there a way to create a borderless > window that *isn't* full-screen mode? > > Thanks for any help you can give. Do you mean for your own compiled version, or for the released win32 binary ? We found that hidding the console for the release may seems pretty but was highly unpractical when it comes to help users that are unable to see the errors messages printed on the console. So it was filed as a false good idea and now the console of fgfs is shared with the one of fgrun. If you want to do it in your own project, you just have to change a link option. Replace /subsystem:console by /subsystem:windows and relink -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] New super/turbo MP code is in
Peter Stickney > On Monday 18 July 2005 18:25, Josh Babcock wrote: > > > All the 3350s had this turbo/super setup. You can see it in some of > > these images: > > > > > ... snip ... > > There were 3 flavors of the R3350. One was the engine used on the > B-29. It had a single-speed gear driven blower. The > turbosuperchargers (The B-29 used 2 per engine - basically the same > model used on the B-17 and B-24 - with twice the displacement, and > about the same RPM, it needed twice the mass flow, and using the > paired turbosuperchargers meant that they could deliver a working > system without having to interrupt production) fed air at what were > essentially sea level conditions to the engine's mechanical blower. > The production versions peaked out at about 2200 HP, and a useful Full > Throttle Height of around 25,000'. OK, so what we have here is a 2 stage supercharger. The first stage is the 2 turbos and the second stage is the single stage gear-driven supercharger. I have enough data now for a reasonable simulation, but to make it more accurate, I wonder if you could describe the action of the supercharger pressure regulator? I can model it as just controlling the manifold pressure between 0 and full. I interpret 0.8 (#8 on the dial) as being the setting for full throttle height (military power). Settings 9 and 10 are emergency settings. Did the controller act on the throttle, or a control a wastegate to adjust the turbos, or just dump pressure, or? > But that's not the only way to do it. I've been preparing a series of > articles on supercharging reciprocating engines. Is there any > interest for me to pull some of it out and present it here? Probably not here, but personally I would be _most_ interested in anything you have on this subject. This list is a great place to learn, and this can lead to more realistic simulation. If you like, send me anything you feel like off-list, or point me to a website. I have been struck by the lack of detailed information on the web on the R3350, a stark contrast to the Merlin/Griffon. Thanks Vivian ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Frederic Bouvier wrote: > Oliver Schroeder wrote: > > So the question is: How can I easily calculate the distance and how many > > nautical miles are "out of reach" (thinking of e.g. radar systems) ? > > You can compute distance at an altitude using SimGear functions Ack, don't even *think* about doing the math in a GIS datum. Convert, store and process everthing in cartesian coordinates where it's vastly easier (the conversion routines are in the same sg_geodesy interface). The only advantage to lat/lon/alt is that I can see is that it can be packed slightly smaller in the packet, because the altitude coordinate needs less precision. But even that is questionable, because the same would be true of plain spherical/euler coordinates, which are still much easier than doing WGS84 stuff. Honestly, I'd suggest keeping as much GIS knowlege out of the server as possible. It only complicates things there. The one that I was working on didn't link against SimGear at all. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Couple of Windows-related questions
Hi, I'm wondering if there is a way to run FlightGear without the 'command prompt' window opening, or at least to have it minimized when it opens. Is there a way to do this? Also, I've looked for a 'borderless window' option in the OpenGL commands with no success. Is there a way to create a borderless window that *isn't* full-screen mode? Thanks for any help you can give. Drew ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
> So the question is: How can I easily calculate the distance and how many > nautical miles are "out of reach" (thinking of e.g. radar systems) ? It could be that VFR-equipped planes (esp. those w/o radar) only need things within the visibility range. I don't know about airborne radars, never flew with one, either :) http://www.faa.gov/ATpubs/AIM/Chap4/aim0405.html gives a pretty good coverage of the existing ATC radars in the US and their capabilities. The question is whetheer you have the capability to map all the enroute (ARTCC) radar installations and other range-extending radar installations around busier airports, i.e., not on the field itself. Also, you have to take terrain in consideration when talking about the radar reach. > 3) artificial life at airports > The server gives a lot of opportunities. One of the first things which came > to my mind was artificial traffic at airports. It should be fairly easy to > write clients in any (network capable) language which do simulate a client. > This can be simply a helicopter standing near a hangar or even a plane flying > around an airport. This would disburden fgfs itself (since it does not need > to create AI traffic itself) and allow an arbitrary number of artificial > clients, each serving it's "own" airport (or whatever area), bringing life to > many areas of the world without manipulating fgfs itself. Great idea. It's probably a good thing to coordinate this with the server, otherwise there will be a lot of artificial life burdening the server at the fields noone actually is flying at! ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Quoting Oliver Schroeder : > 1) "out of reach" > The server receives position information of clients and thus should be able > to calculate the distance of two given clients (measured in nautical miles, > disregarding height) so it is able to decide if it has to send packets to a > client or not. In case it is "out of reach", i.e. all actions of client A do > not affect anything for client B, the server can stop sending packets between > those two clients. So it is possible for the server to handle hundrets of > clients even though each client does only see a couple of them (at least if > the clients are scattered around the world). > So the question is: How can I easily calculate the distance and how many > nautical miles are "out of reach" (thinking of e.g. radar systems) ? You can compute distance at an altitude using SimGear functions : #include double az1, az2, distance; geo_inverse_wgs_84( altitude, lat_1, lon_1, lat_2, lon_2, &az1, &az2, &distance ); distance = | (lon_1,lat_1), (lon_2,lat_2) | -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 13:43 schrieb Pigeon: > Also I'm wondering if the server should take control of who's logged > on and off. At the moment the client is taking care of that by adding a > player if it gets udp packets that it doesn't already know about, and > removing player if it hasn't got anymore packets from a player with a > timeout. I thought of the server generating a chat message like "Player1 joined the at KSFO" or something, spreading it to the clients which display it to the user. And possibly other messages which reflect the state of the server. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: suggestions/questions regarding multiplayer
Would it be good if both ATC and chat message could be in some sort of text area box so you have the history and you could scroll back and stuff? Also I'm wondering if the server should take control of who's logged on and off. At the moment the client is taking care of that by adding a player if it gets udp packets that it doesn't already know about, and removing player if it hasn't got anymore packets from a player with a timeout. I was thinking that way we could show logon/logoff message in the multiplay window. Now it's some sort of a multiplay event window, rather than only for chat messages. > 2) chat messages > The server (in fact every client) should be able to send messages to clients > which get displayed on the screen (i.e. the flightgear window), just like ATC > messages. So the server can send state information to the client. After > reading some source code and discussing this on the irc channel I've noticed > that the necessary infrastructure is already there but not used. The network > protocoll supports chat-messages and the ATC-module has functions to queue > and display them on screen. So it should'nt be too hard to combine them and > enable chat-messages. Somebody willing to give it a try? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Hello, 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's "own" airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. I'm very far from knowledgeable about the respective source structures in FlightGear and just thinking out loud, but perhaps it would be possible to extract the AI-code already being developed inside FlightGear to an external software package which could take the task of injecting such AI clients in the network? If the code is modular enough, the AI module could be plugged into such a multiplayer-bot as well as into the main FlightGear code, where in the latter it would be used for single player mode. Alternatively FlightGear could startup a local multiplayer "network" on localhost if the user is not participating in a multiplayer session and wants to have AI planes flying and taxiing around. As I said: I'm thinking out loud and I have no idea of the AI/ATC-code, so bear with me *duck* ;-) Regards, Ralf ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] suggestions/questions regarding multiplayer
Hello List, some of you may already have taken notice of my multiplayer server for flightgear (http://www.o-schroeder.de/fg_server). It's working quite well in sane environments but I want to improve it and therefor have some questions you may be able to answer. 1) "out of reach" The server receives position information of clients and thus should be able to calculate the distance of two given clients (measured in nautical miles, disregarding height) so it is able to decide if it has to send packets to a client or not. In case it is "out of reach", i.e. all actions of client A do not affect anything for client B, the server can stop sending packets between those two clients. So it is possible for the server to handle hundrets of clients even though each client does only see a couple of them (at least if the clients are scattered around the world). So the question is: How can I easily calculate the distance and how many nautical miles are "out of reach" (thinking of e.g. radar systems) ? 2) chat messages The server (in fact every client) should be able to send messages to clients which get displayed on the screen (i.e. the flightgear window), just like ATC messages. So the server can send state information to the client. After reading some source code and discussing this on the irc channel I've noticed that the necessary infrastructure is already there but not used. The network protocoll supports chat-messages and the ATC-module has functions to queue and display them on screen. So it should'nt be too hard to combine them and enable chat-messages. Somebody willing to give it a try? 3) artificial life at airports The server gives a lot of opportunities. One of the first things which came to my mind was artificial traffic at airports. It should be fairly easy to write clients in any (network capable) language which do simulate a client. This can be simply a helicopter standing near a hangar or even a plane flying around an airport. This would disburden fgfs itself (since it does not need to create AI traffic itself) and allow an arbitrary number of artificial clients, each serving it's "own" airport (or whatever area), bringing life to many areas of the world without manipulating fgfs itself. so far, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Overhaulling the networking code (was: Multiplayer crashes with unknown aircrafts, any solution?)
Am Friday 15 July 2005 23:34 schrieb Ampere K. Hardraade: > I think it will be more flexible if the networking portion of FlightGear > can be modified to exchange properties. For starter, the > nodes /accelerations, /positions, and /surface-positions can be exchanged > among users. Properties under /accelerations can allow one client to > interpolate the position of others, thus eliminating jitters. Properties > under /position are basically what being exchanged right now. As > to /surface-positions, the properties inside this node can allow one to see > the animations of others correctly. The existing code only needs some minor modifications to allow any kind of property to be send over the wire. There are only a couple of functions to modify in order to do this. That way it is possible to "configure" the network protocoll via XML-files and let NASAL do the logic (as suggested by hfitz on the AVsim forum, see http://forums.avsim.net/dcboard.php?az=show_mesg&forum=198&topic_id=913&mesg_id=934&page=) NASAL "only" has to fill a message structure and let the network-code send it over the wire. There are, however, some issues with networking. To actually send diefferent kinds of properties over the wire, you have two possibilities: 1) "chain" properties in one packet 2) send each property in its own packet In case 1) it may be possible to blast the capacity of packets (MTU) in which case the packet becomes splitted. And it may be difficult to handle splitted packets. In case 2) you possibly interfere with the "frequency" used to send packets and thus make it very difficult to keep clients in sync. > To cut down the amount of data being sent/received, a client only have to > broadcast the above nodes once, and resend individual properties when > needed. In general you don't want to send large amount of data using UDP. You will eihter have to deal with lost data (which is getting worse with every additional client) and have to calculate approximations for values in the property tree or have to use some kind of "data-received-confirmation" machanism producing overhead. And it may be unnecessary to broadcast the tree. Assuming a normal startup of clients, every client can be initialized as they were local. This should give already a good approximation of its status at startup. And as packets arrive with updated property values, the data becomes more and more "right". And calculate approximations for the property tree of other clients is necessary anyway to 1) deal with lost packets, 2) deal with low frequency rates of network packets and 3) temporary performance leaks of the local instance of fgfs. just my 2c, Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
