DONOTUPDATE logic

[Dimon]

Is there any FAQ how to deal with it or some sort of practical example?

Thanks

[virtuali]

No, because I'm firmly against it, so it's intentionally undocumented, hoping only advanced users that know *exactly* what they are doing will use it, so we won't lose effort to support someone that didn't fully understood where and how to use the DONTUPDATE feature that would report a problem that happened only because he placed that file everywhere and prevented our updater to do its job.

It's not so difficult: every folder that has a file named like that, will be skipped by the updater. What's in the file doesn't matter. The type of the file doesn't matter. The size of the file doesn't matter. The only thing that matters is the name so, it can even be an empty file.

If you just want to protect your AFCAD modifications ( which is also something we don't suggest, because we can modify them at any time, and they usually *must* go together with a GSX customization ), don't use the DONTUPDATE method, because AFCADs will be overwritten only on request and a backup will be made.

Don't use the DONTUPDATE, except in *exceptional* cases. And even in these cases, it would be much better if you simply told us which kind of modification you made and we might consider adding it as a permanent fix.

[Dimon]

I'm more worrying AFCAD modifications. With all due respect FSDT is a way far behind in terms of proper coding, taxiways allocation, parking types and radiuses and too many other small items to mention. I'm not blaming anyone, just suggesting to leave that area to the users (if they want to)

[virtuali]

I'm more worrying AFCAD modifications

Then you don't need the DONTUPDATE at all, as I've said.

With all due respect FSDT is a way far behind in terms of proper coding, taxiways allocation, parking types and radiuses and too many other small items to mention. I'm not blaming anyone, just suggesting to leave that area to the users (if they want to)

Are you referring to old sceneries ? Because, all our recent sceneries have proper coding, proper taxiway allocation, proper parking types and proper radiuses and, in fact, the reality is exactly the opposite and, while working on GSX, we found most of the problems you are reporting, are happening with *other* sceneries, which are full of error.

And "far behind" compared to what ?

To what other scenery developers do ? I don't think so, just have a look at the GSX sharing forum how many things Cartanya have to fix in *other* sceneries.

To what you could do by yourself ? In this case, if you have something to say about an FSDT AFCAD, please post it in its appropriate section, indicate each and every problem, post your considerations on why you think it's wrong, and we'll go through them, one by one, fixing what really needs to be fixed.

[p3dx3]

No, because I'm firmly against it, so it's intentionally undocumented, hoping only advanced users that know *exactly* what they are doing will use it, so we won't lose effort to support someone that didn't fully understood where and how to use the DONTUPDATE feature that would report a problem that happened only because he placed that file everywhere and prevented our updater to do its job.

It's not so difficult: every folder that has a file named like that, will be skipped by the updater. What's in the file doesn't matter. The type of the file doesn't matter. The size of the file doesn't matter. The only thing that matters is the name so, it can even be an empty file.

If you just want to protect your AFCAD modifications ( which is also something we don't suggest, because we can modify them at any time, and they usually *must* go together with a GSX customization ), don't use the DONTUPDATE method, because AFCADs will be overwritten only on request and a backup will be made.

Don't use the DONTUPDATE, except in *exceptional* cases. And even in these cases, it would be much better if you simply told us which kind of modification you made and we might consider adding it as a permanent fix.

Can you update the updater to not remove inibuilds Dynamic lights bgl files named ____DL.bgl

[virtuali]

Can you update the updater to not remove inibuilds Dynamic lights bgl files named ____DL.bgl

Sorry, no. We cannot possibly tweak the updater to take into account each and every possible modification that is out there. What if another set of mods would use a different naming convention ? What if we release an update that might not work with those mods ?

There's the DONTUPDATE, and that's it.

We are looking into a kind of GSX cloud service, in which users can share their additions to GSX, and will likely do something like an automatic installer so, this is the correct direction to take in the future, not constantly crippling our own update system, in a way that it would become impossible to support anyone, because we cannot possibly sure what has been added.

[p3dx3]

Can you update the updater to not remove inibuilds Dynamic lights bgl files named ____DL.bgl

Sorry, no. We cannot possibly tweak the updater to take into account each and every possible modification that is out there. What if another set of mods would use a different naming convention ? What if we release an update that might not work with those mods ?

There's the DONTUPDATE, and that's it.

We are looking into a kind of GSX cloud service, in which users can share their additions to GSX, and will likely do something like an automatic installer so, this is the correct direction to take in the future, not constantly crippling our own update system, in a way that it would become impossible to support anyone, because we cannot possibly sure what has been added.

I read your comment "And even in these cases, it would be much better if you simply told us which kind of modification you made and we might consider adding it as a permanent fix." I understand if you are not going to do this just gave a suggestion in the future so dynamic lights files I do not have to continue replacing after the auto updater since like your post said it is not ideal to use this command.

[virtuali]

if you are not going to do this just gave a suggestion in the future so dynamic lights files I do not have to continue replacing after the auto updater since like your post said it is not ideal to use this command.

Than why you don't simply use the DONTUPDATE method in the folder you have the DL modifications, which is usually the same as the AFCAD ?

The Live Update now tells you exactly what is trying to do so, if it finds you had a DONTUPDATE, it will tell you that so, by checking the updater window at the end of the process (it won't close unless you press the "Completed" button), if you see anything that had an update but was prevented by that file, you know something has changed in the scenery, and only at that time you'll have to temporarily copy your modifications, and decide if you want the update. Not every time. Only sceneries recently released are updated often