20,741
edits
Emesary: Difference between revisions
Jump to navigation
Jump to search
→Background
| Line 5: | Line 5: | ||
== Background == | == Background == | ||
We all agree having a good IPC mechanism for distributing the simulation state across threads/processes/network is critical<ref>{{cite web | |||
flight dynamics. | |url = https://sourceforge.net/p/flightgear/mailman/message/34794675/ | ||
somewhat non-trivial to capture all the data for all the AI objects and | |title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API | ||
replay them as well. We'd have to decide if the recording and playback | (was Re: A FGPythonSys implementation: ...) </nowiki> | ||
mechanism should be part of the AI object or something external that | |author = <nowiki> James Turner </nowiki> | ||
grabs the data and then somehow can force the AI object back through | |date = Jan 25th, 2016 | ||
|added = Jan 25th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Properties are much too fine-grained for exposing via HLA. Properties, and subsystems communicating using them, are implementation details of particular HLA federate, not something we’d expose across the federation.<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/ | |||
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...) </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jan 25th, 2016 | |||
|added = Jan 25th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Most solutions that don’t involve fine-grained locking of each property ultimately equate to '''message passing''' anyway<ref>{{cite web | |||
|url = https://sourceforge.net/p/flightgear/mailman/message/34794675/ | |||
|title = <nowiki> Re: [Flightgear-devel] Designing a thread-safe property tree API | |||
(was Re: A FGPythonSys implementation: ...) </nowiki> | |||
|author = <nowiki> James Turner </nowiki> | |||
|date = Jan 25th, 2016 | |||
|added = Jan 25th, 2016 | |||
|script_version = 0.40 | |||
}}</ref> | |||
Besides, there's the '''ownship''' assumption hard-coded all over the place - for example, right now subsystems like the replay (flight recorder) system only record and replay your "own" aircraft flight dynamics. | |||
It would be a significant change/addition and somewhat non-trivial to capture all the data for all the AI objects and replay them as well. | |||
We'd have to decide if the recording and playback mechanism should be part of the AI object or something external that grabs the data and then somehow can force the AI object back through | |||
it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref> | it's original path during playback. <ref>https://sourceforge.net/p/flightgear/mailman/message/8980739/</ref> | ||