High-Level Architecture

1,404 bytes added, 09:26, 26 January 2016
no edit summary
| date = Nov 19th, 2015
| added = Nov 19th, 2015
| script_version = 0.23
|1= HLA is really intended to operate at a much higher level of granularity and pass objects around a distributed simulation. The use-case I'm working on at the moment passes an AI instance as an object (with position, velocity, accelerations, model to be displayed). How a HLA Federate maps that data internally is an implementation decision. There shouldn't be any race conditions because no assumptions are made about how the data is used or mapped. At present, I'm not thinking that HLA will be used as a mechanism to provide a shared property tree across multiple Federates. I think that's the wrong way to use HLA. Instead you make explicit decisions about the data models you will communicate. The other reason HLA isn't a good choice is to do with simulation clocking. I'm still getting my head around this properly, but the overall model is one where the simulation clock is advanced, and the instance the updates and publishes changes to the RTI that will be picked up by other instances at the next clock advance.
|2= {{cite web
| url =
| title = <nowiki>Re: [Flightgear-devel] Designing a thread-safe property tree API
(was Re: A FGPythonSys implementation: ...)</nowiki>
| author = <nowiki>Stuart Buchanan</nowiki>
| date = Jan 26th, 2016
| added = Jan 26th, 2016
| script_version = 0.23