KL-666 wrote:That brings me to a question. Would it not be possible to also push these airports to terrasync? Because i do like the download on the go aspect of terrasync, so that i do not need to download a whole country at once.
Kind regards, Vincent
If you are talking about "technical" possibility is way too easy to do. If you are talking about executive possibility the answer is no. Not possible. Terrasync repository is closed and someone lost the key. The only thing possible to add up to terrasync is new models, but even this case scenery is much in the grey area.
Models need to have a very specific, and frequently inconvenient format, and the smart usage of tiling and texture sharing used, per example, in chubu is not acceptable. I did a good amount of work making Chubu compliant with terrasync forms and submitted Chubu to terrasync. Due to being me who submitted it, Chubu was vetoed. The argument of "why not" was fabricated, and left a clear point that Chubu was not going to be uploaded to terrasync any time soon.
Other situations, include the smart use of OSM buildings and Roads, constructed in places like Narita (RJAA) and Chitose(RJCC), and even Kansai Cargo area (RJBB) where they produced, with the proper methodology a radical change of appearance and rapidly improved scenery without the need of making too many custom 3d buildings. In addition to be more accurate depiction of reality, than merely filling blanks on shared models (like your dreary tower). But still, what's interesting here is that OSM buildings are not acceptable submissions for terrasync.
Continuing with the Project 3000 shared models, whose many locations enriched Japan, and these are now available to be installed worldwide in terraGIT, but these will just output Model not found errors if pushed to Terrasync. Same situation with the shared models by J. Maverick, which are useable in terraGIT but rather of no use to be pushed to terrasync.
Furthermore, Jetways and Groundnet specification files are not acceptable to terrasync.
Finally, terrain layouts: This is also not acceptable in general form, since to update, terrain needs to be patched with partially built texture, which breaks the Core developers policy that world needs to be generated in a single run. [url]Our method of tile patching does produce visible tile boundaries that look sometimes like a thin breakage in the terrain. In the core developers view this is a totally unacceptable situation[/url], and thus KHAF and TNCM will remain underwater, SGAS will remain under Grass, and OMDB will remain under sand until a new scenery WS3.0 comes around. Many of these fixes had been pushed to terraGIT, as we deal with a world that takes small patches with ground corrections, on the expense of having sometimes some stitching evidence.
For this last reason, the layouts in Japan were updated in many --many airports, but they remained being either 810 specification, underwater in the island, or single default runway layouts, for terrasync users.
As it stands, the current situation is that the exquisite control over scenery development that is needed to finely control scenery development is lacking on the terrasync business model, and thus, making necessary the creation of an FGMEMBERS affiliate scenery repository for both: the development and distribution of new scenarios.
On the last point here: FG is moving terrasync from its historical protocol (subversion) towards a more classical transfer protocol (the good old http). Reality is that we will eventually be able to offer an http mirror for terraGIT. This would allow users to modify the configuration files in FGDATA to fetch terraGIT in a purely automated (on the fly) way: Just redirecting the http server from the official servers to the TerraGIT mirrors, thus, providing a final solution to the problem that concerns you right now.
IH-COL