20,741
edits
(→Design) |
|||
| Line 50: | Line 50: | ||
So it would make sense to start moving the implementation to the fgms side of things - and away from the client. | So it would make sense to start moving the implementation to the fgms side of things - and away from the client. | ||
That would allow us to have a single fgms instance, just for aircraft/vessel traffic - without doing all the parsing at the client side. | That would allow us to have a single fgms instance, just for aircraft/vessel traffic - without doing all the parsing at the client side. | ||
I agree with your point of view. As you said the good solution is to use fgais like a server and not like a client in order to limit the number of request to the provider. | |||
I think that the good solution is : | |||
* fgais should send request to the provider every 20 seconds (the provider send new aircraft position every 20 seconds, if you send a request every 5 seconds you receive exactly the same result 4 times) | |||
* fgais should calculate the move of each aircraft in order to interpolate/calculate the position between each request to the provider. (We receive "real" position of aircrafts every 20 seconds but we calculate the new position every 4 seconds = 5 "fictive" position for 1 "real" position. | |||
* fgais should be able to send aircraft position only in area of the user (need to receive position of the client and calculate the "out of range" limit. This should be easy to use fgms implementation) | |||
* fgais should be able to send aircraft position as AI traffic instead of MP traffic (need to create a new "Magic Header" like it's already done in fgms for relay/tracker and add a filter in flightgear in order to make the difference between AI traffic and MP traffic. | |||
== Related == | == Related == | ||