Hi fellow wiki editors!

To help newly registered users get more familiar with the wiki (and maybe older users too) there is now a {{Welcome to the wiki}} template. Have a look at it and feel free to add it to new users discussion pages (and perhaps your own).

I have tried to keep the template short, but meaningful. /Johan G

Changes

Jump to: navigation, search

High-Level Architecture

802 bytes added, 23:06, 20 February 2016
m
Federate Object Model: +references
==Federate Object Model==
A key part of the design is writing the Federation Object Model (FOM), which defines the objects and updates that are published by the RTI. While it might at first glance seem a good idea to use the FOM to share the internal property tree across multiple federates, this is probably the wrong way to use HLA as the granularity is too low <ref>https://sourceforge.net/p/flightgear/mailman/message/34795859/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34803436/</ref><ref>https://sourceforge.net/p/flightgear/mailman/message/34794675/</ref> and it's likely to lead to synchonization issues. Instead, we'll need to make explicit decisions about the data models to communicate. One possibility suggested by Stuart on the devel list, would be providing certain subsystems with their own ''private'' property tree <ref>https://sourceforge.net/p/flightgear/mailman/message/34632142/</ref>.  For instance, certain subsystems are already well-behaved/encapsulated in that they're having their own dedicated branches in the property tree (e.g. think <code>/ai</code>, <code>/models</code>, <code>/canvas</code>), i.e. could be moved to a separate thread accordingly, which would be in line with similar ideas discussed in the past (see [[Property threading]]).
The FOM is a set of XML files in [https://sourceforge.net/p/flightgear/fgdata/ci/next/tree/HLA/ fgdata/HLA/]
18,205
edits

Navigation menu