Note that this is not a new discussion/idea, for some background info refer to the atlas project on sourceforge: It is already unfortunate that the navcache is not a true subsystem and that its internal data dependencies are not formalied, so the whole thing could just as well be moved to simgear, so that OpenRadar/ATC-Pie can more easily reuse it (either as a binary library or via standalone program/networking (IPC)).
#FLIGHTGEAR WIKIPEDIA CODE#
There are so many similar programs that need to access this very data, that it is simply inefficient to copy/paste code and adapt that, and in a MP/VA or ATC scenario, you would also want to ensure that all "players" (clients) are using the same underlying database, which is why I believe that it would be better to have a true server/client model, where fgfs would only connect to a locally running database - which in the fg case, could even be running in a backgound thread (e.g. We'll need the capability to to have two clients access the NavDB concurrently - I've hit lots of errors trying to do this See High-Level Architecture for the main article about this subject. If you can find the suspect navcache, please upload it to: and let James know. Of course, there could be multiple issues. This has led James to think the issue is permissions, not corruption of the DB. When the cache needs to be rebuilt, startup will take a bit longer than before, but when the cache is valid, startup is much faster, especially for debug builds - because all the usual parsing/processing will be skipped, and the corresponding data will be read from the binary cache instead.Ī copy of your navdata.cache would be appreciated (the broken one), since of the two copies James was sent so far, neither were corrupted - they both passed the SQLite integrity check. The cache is stored in $FG_HOME/navdata.cache, and is rebuilt if the timestamps on any of the data files change ( apt.dat, nav.dat, fix.dat and so on). There is a version field of course, and we're not planning or expecting any changes, but we really don't want to be tied to the current scheme if we discover problems or want to add something else in the future. There are no guarantees made about the format of the file, the SQL scheme or anything. The internal format of the cache (for example the fact it's a SQL DB) is deliberately opaque.
#FLIGHTGEAR WIKIPEDIA VERIFICATION#
We /do/ also run a Sqlite verification check on the DB at launch time - this should catch many kinds of file-/index- level corruption (bad commit, etc), and in any case where we detect an issue, the solution is again to drop the cache and rebuild. The naming scheme is why the first run of a new stable release of FG always does a cache rebuild - which means you can run stable and dev versions side by side without continual cache rebuilds of course. The DB schema version is tracked internally in the file, and if the schema changes during a development version (3.3 or whatever) it will force a drop and rebuild. The nav-cache is versioned, it will be wiped when the cache schema version changes, but right now it’s not wiped when the flightgear version does. We should absolutely stop telling anyone to edit preferences.xml in FG_ROOT any documentation or advice which says to should be changes ASAP. This means when the search paths or order changes, we have to completely rebuild, because there's no way to restore the unmodified (prior to XML overlay) version. When the scenery paths change, we have to rebuild, because Airports XML data (from the /Airports/ tree) is overlaid into the cache, replacing the data from apt.dat. Perceptions, but many applications do additional work on their first launch after an install, so it's not a top concern for the time being. Shipping the binary data improves first-launch Touching the navdata files will cause a rebuild, so rebuilds need to take a 'reasonable' amount of time.
#FLIGHTGEAR WIKIPEDIA SIMULATOR#
Usually, the navdb will only be compiled once during the first start of the simulator - however, some changes may require rebuilding the cache on disk (see below for details). (Parsing 20MB of text data each launch is still kind of crazy, though) Collecting it from many XML files would also be slow, but there's a general point that we should be decoupling availability from loading. Parsing it from apt.dat and nav.dat is 'slow', but has been optimised over the years. We need a lot of data available at startup for position init. Screen shot showing several navcache (SQLite) files in $FG_HOME for various fgfs versions
0 kommentar(er)
