Error:Version Check failed

This article has been nominated for deletion since 16 November 2024. To discuss it, please visit the talk page. Do not remove this tag until the discussion is closed. Reason for the nomination: This article either contains out of date information and/or may not meet the quality standards of the wiki.

Note  In the unlikely event of receiving a version number mismatch error message for fgdata, please tripple check that you have compiled simgear AND flightgear AND have the latest fgdata. — Torsten Dreyer (Jan 5th, 2016). [Flightgear-devel] Release preparations. (powered by Instant-Cquotes) If you are compiling from the next branch(s) you need to also pull FG data from git to make sure it matches your binaries. — hvengel (Sep 29th, 2014). Re: fgdata problem. (powered by Instant-Cquotes)

Background

An explanation of what happened: FG changed version number; specifically, we went from 3.7 to 2016.1.0. The version number is hardcoded in FlightGear as well as in FGData. Whenever the simulator is run, it checks whether those numbers match, so that you won't experience problems caused by incompatibilities between old FG versions/new FGData or vice versa. In your case, you probably had an older nightly build installed/built (which had version 3.7 hardcoded in). By pulling yesterday's FGData, you pulled in the change in version number as well, so that FG will now - legitimately - refuse to start due to the mismatch. The latest nightly FG build on the build server should fix the problem. — elgaton (Jan 6th, 2016). Re: can't make flightgear work form git. (powered by Instant-Cquotes)

All that is needed is a fresh git pull of simgear, flightgear and fgdata, followed by cmake and compile and install of simgear , then cmake and compile and install flightgear to get everything back in sync. — Alant (Jan 6th, 2016). Re: can't make flightgear work form git. (powered by Instant-Cquotes)

Workaround

there's too many changes which are correlated across binary and FGData. For instance, the runway lighting being exposed has affected the binary, but the effect declarations needed reside in FGData. TorstenD's ATIS changes are across both. Typically, I can't even start FG when getting a new binary without also updating FGData - it just crashes. So I don't think this would be desirable - and if you must, modifying the version file is easy enough. — Thorsten (Mar 12th, 2014). Re: . (powered by Instant-Cquotes)