FSDreamTeam forum
December 08, 2019, 01:49:38 PM *
Welcome, Guest. Please login or register.

Login with username, password and session length
News:
 
   Home   Help Login Register  
Pages: [1]
  Print  
Author Topic: DONOTUPDATE logic  (Read 507 times)
Dimon
Sr. Member
****
Posts: 475



« on: August 13, 2019, 03:04:38 PM »

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

Thanks
Logged

i7-6700k@4.6Ghz, Z170 Delux, 980Ti-6GB5700, 2TB EVO850, 16GB DDR4 RAM Win7/64 PRO.
virtuali
Administrator
Hero Member
*****
Posts: 36978



WWW
« Reply #1 on: August 13, 2019, 08:16:39 PM »

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.
Logged

Dimon
Sr. Member
****
Posts: 475



« Reply #2 on: August 13, 2019, 08:30:00 PM »

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)
Logged

i7-6700k@4.6Ghz, Z170 Delux, 980Ti-6GB5700, 2TB EVO850, 16GB DDR4 RAM Win7/64 PRO.
virtuali
Administrator
Hero Member
*****
Posts: 36978



WWW
« Reply #3 on: August 13, 2019, 11:07:23 PM »

I'm more worrying AFCAD modifications

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

Quote
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.
Logged

413x3
Sr. Member
****
Posts: 487


« Reply #4 on: August 29, 2019, 03:07:14 PM »

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
Logged
virtuali
Administrator
Hero Member
*****
Posts: 36978



WWW
« Reply #5 on: August 29, 2019, 03:23:17 PM »

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.
Logged

413x3
Sr. Member
****
Posts: 487


« Reply #6 on: August 29, 2019, 03:53:07 PM »

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.
Logged
virtuali
Administrator
Hero Member
*****
Posts: 36978



WWW
« Reply #7 on: August 29, 2019, 05:14:34 PM »

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
Logged

Pages: [1]
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.21 | SMF © 2015, Simple Machines Valid XHTML 1.0! Valid CSS!