FGAIS: Difference between revisions

Jump to navigation Jump to search
1,731 bytes added ,  30 October 2012
Line 39: Line 39:
=== Issues ===
=== Issues ===


* Use of std::map means that we are creating memory leaks whenever an aircraft with identical callsign is added, this applies especially to the various "z.NO-REG" aircraft, which we need to deal with separately.
Basically:
* bugs
* we should *never* iterate through the whole AI list in the main thread *never*
* runtime performance
* we definitely should not be doing that for each client (we do that now!)
* memory usage
* we should only maintain a vector/map of local clients (players!)
* sendAITraffic should then look at this list (which is only updated by the main thread, lock held)
* Using the positions of each local client, we should then traverse the ai_list once in the background thread
* i.e. in recompute() - and check if any of the ai aircraft is in range of a local player
* if it is, we need to check if we have previously computed a positionMap for that ai aircraft
* if we don't have one, we need to create it
* once we have a positionMap foreach aircraft in range, we need to update an vector with pointers to relevant aircraft
* this could be in FG_Player
* when the background thread is idle, it can update other aircraft
* it should prioritize aircraf that are going to be in range soon
* and then the remaining aircraft
 
Finally, our buffer of computed positions must not be equal to our request interval: When it only contains positions for 60 seconds, the fgms main thread inevitably needs to wait for the worker thread to fill the positionMap from scratch.
 
Thus, the positionMap should contain more positions.
 
 
The other problem is that our worker thread currently destroys previously computed messages stored in the positionMap.
However, it would make sense to "append" new positions to the buffer. Like a FIFO queue or a vector, so that we can:
 
1) fill the positionmap with messages for more than 60 seconds (e.g. 90)
2) or start the background thread much earlier than after 60 seconds (i.e. 30)
3) and merely create missing packets, without overwriting the old positionMap
 
That would ensure that the main thread has still enough data, even though our background thread is limited to run only at 1 minute intervals. Otherwise the main thread blocks, because it has to wait for new data from the positionMap.


=== Roadmap ===
=== Roadmap ===

Navigation menu