Re: [Flightgear-devel] suggestions/questions regarding multiplayer
On Mon, 1 Aug 2005 18:59:21 +0100, David wrote in message <[EMAIL PROTECTED]>: > Harald JOHNSEN writes: > > > Oliver Schroeder wrote: > > > > > >2) chat messages > > >[...] > > >protocoll supports chat-messages and the ATC-module has functions > > >to queue and display them on screen. So it should'nt be too hard > > >to combine them and enable chat-messages. Somebody willing to give > > >it a try? > > > > > > > > As Pigeon said, make that a separate window, because the ATC line is > > > > allready nearly impossible > > to read ;) It should not be hard to code but the atc code is not > > good for that (anyway it does not > > queue messages). > > > > Correct - it's not intended to queue messages. Messages transmitted > at the same time end up displayed on top of each other and appear > garbled, much as messages transmitted at the same time probably sound > garbled, screeched, or one non-existant in real life. All the message > collision logic is in the ATC and AI units, which attempt to speak > only when the frequency is clear. There are a few bugs in there, so > sometimes garbled speech occurs! ..garbled speech occurs in RL too. Bug in RL, feature in FG. ;o) > I do agree though that the basic ATC display can be nearly unreadable > under some colour conditions - it's very much a quick hack ;-) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Harald JOHNSEN writes: > Oliver Schroeder wrote: > > >2) chat messages > >[...] > >protocoll supports chat-messages and the ATC-module has functions to queue > >and display them on screen. So it should'nt be too hard to combine them and > >enable chat-messages. Somebody willing to give it a try? > > > > > As Pigeon said, make that a separate window, because the ATC line is > allready nearly impossible > to read ;) It should not be hard to code but the atc code is not good > for that (anyway it does not > queue messages). > Correct - it's not intended to queue messages. Messages transmitted at the same time end up displayed on top of each other and appear garbled, much as messages transmitted at the same time probably sound garbled, screeched, or one non-existant in real life. All the message collision logic is in the ATC and AI units, which attempt to speak only when the frequency is clear. There are a few bugs in there, so sometimes garbled speech occurs! I do agree though that the basic ATC display can be nearly unreadable under some colour conditions - it's very much a quick hack ;-) Cheers - Dave ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
And remember that a robust implementation can get big speedups by handling Mostyn Gale wrote: > Andy Ross wrote: > > "The best way to do this is actually dynamic: the server gets to > > send the X "most important" objects to each client per update. > > Importance can be defined in screen space -- think of it as the > > number of "pixels" of error that the receiving client would have > > if the update were not sent. > > Also a consideration is the detail of the updates. A plane > 10km away can be have an accuracy of 1m but you would like a > plane in formation to fly have about 1cm accuracy. That's why the accuracy is specified in "screen space", not distance. Basically, divide by the distance from the observer and that is your priority. > Sending velocity and acceleration data can also smooth make > flight smother, but only for nearby aircraft. They're useful for everything, actually. Consider a jetliner in a steady turn. A single packet is enough for many seconds of extrapolation if it includes acceleration, but will rapidly become incorrect > But how will the server calculate this? There will be 2^N-N > relationships for the computer to work out which levels of > reports to send to each client. For 20 players that is over a > million calculations that the computer must perform every > cycle. I'm not sure where you get the exponential there. There are N^2/2 distance calculations required to get all the inter-object distances. A naive implementation (this can actually be optimized pretty well) would then need to do another N priority calculations for each client, for a total of O(N^3), or around 8000 computations per "cycle". Really, it's going to be done per packet received (which are O(N), of course), so it's really more like 400 per packet for 20 clients. Not so bad at all -- computers are really fast these days. Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Wednesday 20 July 2005 10:46 schrieb Vivian Meazza: > Oliver Schroeder > > I *think* that the flightgear client is kind of to big and this kind of > > program (lets call it "injector") does not need all of its functions. Eg. > > there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe > > a stripped down version of the flightgear client would be just what we > > need. > > Yes FG is big, and would have unused functions. Against this has to be > balanced the time and risk in developing and maintaining a stripped down > version. I don't have a handle on the size of that task or the risks > involved. I didn't mean to develop or maintain another version of FG, i guess an appropriate configure can do the trick. Something like "configure --without-opengl --without-ATC ..." > I suggested some time ago that the first player's system might handle all > the admin tasks - that way you get the AI traffic, carrier movements etc. > virtually free. However, there are significant questions surrounding that > idea: in particular what happens when the first player leaves. It ought to > be possible for the 2nd player to take up the task, because both systems > should be aligned. There is also the load on the individual client to be > taken into account. I guess this will raise more problems then it will solve. That's why I thought of "injectors". They are (read: would be) player independent. > I'm not sure exactly what you mean by a scriptable client. Does this mean > that it has pre-scripted AI traffic, carrier movements, weather etc.? Something like that, yes. > If you are saying that the server should have as little "knowledge" as > possible, then I would go along with that. I think the server probably > needs to coordinate the network time but beyond that ... there is a case > for the server to filter by range, but this could also be done by the > client. The idea is to disburden the clients as they will already have enough work to do with rendering etc, especially with a gowing number of additional clients at the scene. > I have no strong view on how this should be achieved. We should build on > what we already have in order to achieve a fully coordinated environment. > We should not be re-inventing wheels, flaps or anything else :-) Dacor, I'm always a friend of recycling ;) Oliver ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] suggestions/questions regarding multiplayer
Andy wrote: "The best way to do this is actually dynamic: the server gets to send the X "most important" objects to each client per update. Importance can be defined in screen space -- think of it as the number of "pixels" of error that the receiving client would have if the update were not sent. This way your wingman always gets updated, and a burning/turning dogfighter will get frequent updates, but a jetliner moving in a straight line is nicely optimized and receives very few updates." Also a consideration is the detail of the updates. A plane 10km away can be have an accuracy of 1m but you would like a plane in formation to fly have about 1cm accuracy. Sending velocity and acceleration data can also smooth make flight smother, but only for nearby aircraft. Also you might want to see moving parts, lights, smoke etc on nearby planes. Likewise the same goes for radars, which need to know nothing about moving parts or which lights are on. But how will the server calculate this? There will be 2^N-N relationships for the computer to work out which levels of reports to send to each client. For 20 players that is over a million calculations that the computer must perform every cycle. The load would be distributed more evenly if individual computers decide which data they want and send requests to the server. This would be good for accommodating the programs like radars as the server does not need to know anything about the client. Then the computer needs an N by N matrix to store this information. And needs to search through it to find which data to send. I guess the solution to this would be to have specific matricis for each level of report and just cycle through them. Andy wrote: "Also, I'd suggest defaulting the callsign to the USER (unix, cygwin) or USERNAME (winnt) environment variables where available, to avoid the problem of zillions of identical "flightgear-user" planes flying around. Sane defaults are always good." Or you could just have no default call sign an force people to choose one before logging on. Cheers, Mostyn ___ 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: > Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: > >>Oliver Schroeder >> >>>3) artificial life at airports >>>[...] >> >>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). > > > I *think* that the flightgear client is kind of to big and this kind of > program (lets call it "injector") does not need all of its functions. Eg. > there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a > stripped down version of the flightgear client would be just what we need. > > >>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. > > > There are arising some questions about it. > First of all: what can and what should be handled by the server? > Currently it knows only very few things about what it is actually serving. It > knows a little bit about callsigns, will know a bit about distances and > different kinds of clients in the near future. > Adding "knowledge" to the server adds lines of code which have to be changed > in order to improve things (code changes have to be done in the client _and_ > the server). > What about letting a scriptable client (i.e. a striped down version of fgfs) > do most of such things? > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Wouldn't it be easier to just have a switch in fgfs that tells it to skip the bits regarding the FDM and rendering? That would cut out most of the CPU usage. Josh ___ 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: > > I don't think it's a good idea to handle chat messages in another way then > messages from ATC (or any other type of "conversation"). There should be one > interface for all types of messages and every "module" (currently ATC and > maybe chat messages in the near future) should use it. > > Oliver > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > I agree, we already have to model radios, so if people want to talk, let them talk on the radios. Type a message and whoever is on your freq gets that text the same way they would get it from ATC. The only problem I see is that inexperienced players might not have their radios set properly. Perhaps a hint from the server about what the local ATC freq is would be enough to solve that. Josh ___ 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 > Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: > > Oliver Schroeder > > > 3) artificial life at airports > > > [...] > > 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). > > I *think* that the flightgear client is kind of to big and this kind of > program (lets call it "injector") does not need all of its functions. Eg. > there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a > stripped down version of the flightgear client would be just what we need. Yes FG is big, and would have unused functions. Against this has to be balanced the time and risk in developing and maintaining a stripped down version. I don't have a handle on the size of that task or the risks involved. I suggested some time ago that the first player's system might handle all the admin tasks - that way you get the AI traffic, carrier movements etc. virtually free. However, there are significant questions surrounding that idea: in particular what happens when the first player leaves. It ought to be possible for the 2nd player to take up the task, because both systems should be aligned. There is also the load on the individual client to be taken into account. This is beginning to look like some of the NATO data links where there was no central server, but each unit contributed to the whole environment. Hmm ... > > 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. > > There are arising some questions about it. > First of all: what can and what should be handled by the server? > Currently it knows only very few things about what it is actually serving. > It > knows a little bit about callsigns, will know a bit about distances and > different kinds of clients in the near future. > Adding "knowledge" to the server adds lines of code which have to be > changed > in order to improve things (code changes have to be done in the client > _and_ > the server). > What about letting a scriptable client (i.e. a striped down version of > fgfs) > do most of such things? > I'm not sure exactly what you mean by a scriptable client. Does this mean that it has pre-scripted AI traffic, carrier movements, weather etc.? A little crude perhaps, but effective, but see my comments above. On the other hand we could tell each client what the AI traffic should be and let the client do all the updating. Less bandwidth required, at the trade-off of a build up of errors. Good enough for AI traffic, but perhaps not for the carrier. Of course, this is what happens with the player aircraft - they must already exist on the client system, and this could also be the case for the AI traffic flightplan. If you are saying that the server should have as little "knowledge" as possible, then I would go along with that. I think the server probably needs to coordinate the network time but beyond that ... there is a case for the server to filter by range, but this could also be done by the client. I have no strong view on how this should be achieved. We should build on what we already have in order to achieve a fully coordinated environment. We should not be re-inventing wheels, flaps or anything else :-) 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
Am Tuesday 19 July 2005 18:05 schrieb Vivian Meazza: > Oliver Schroeder > > 3) artificial life at airports > > [...] > 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). I *think* that the flightgear client is kind of to big and this kind of program (lets call it "injector") does not need all of its functions. Eg. there is no rendering, ATC(?), Autopilot, Audio and others needed. Maybe a stripped down version of the flightgear client would be just what we need. > 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. There are arising some questions about it. First of all: what can and what should be handled by the server? Currently it knows only very few things about what it is actually serving. It knows a little bit about callsigns, will know a bit about distances and different kinds of clients in the near future. Adding "knowledge" to the server adds lines of code which have to be changed in order to improve things (code changes have to be done in the client _and_ the server). What about letting a scriptable client (i.e. a striped down version of fgfs) do most of such things? ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] suggestions/questions regarding multiplayer
Am Tuesday 19 July 2005 19:27 schrieb Harald JOHNSEN: > Oliver Schroeder wrote: > >1) "out of reach" > >[...] > I think the range should be user configurable. So it's possibly a good idea to include a similar check in the flightgear client. The server does a precheck, i.e. does not send packets from clients which are for sure out of reach, and flightgear decides for itself if it is worth building up a property tree and display the other client or not. This would mean that flightgear is capable of building a property tree on the fly. But that way we can improve the multiclient capability of flightgear. It does not need to do any rendering of clients which are not in sight, but can bravely display them eg. on radar. The other way would be to implement special network packets which tell the server the, erm, "range of reach" of the client (and possibly other values which might be usefull). But for these packets we need a data-received-confirmation mechanism to make sure the server really got that value(s). > >2) chat messages > >[...] > 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 don't think it's a good idea to handle chat messages in another way then messages from ATC (or any other type of "conversation"). There should be one interface for all types of messages and every "module" (currently ATC and maybe chat messages in the near future) should use it. Oliver ___ 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
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
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] 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
