Change how SBL files are updated

[x87]

Terminology (now):

• update is the process initiated by the program or user, during which the program connects to GitHub and downloads files into the Sanny Builder folder, replacing existing files.
• update can be triggered automatically (automatic update) on program startup, if the user selected this option in the update menu (in statusbar)
• update can be triggered manually by the user at any time, which involves two steps:
  • checking for updates. if current mode is found to be behind upstream (a version in local JSON is lower than one in the file on GitHub), this mode is marked as ready for update. Green border turns into orange.
  • downloading the update. Files are downloaded from GitHub to local folder, replacing existing copies.

Manual update only affects currently selected mode. To update another mode, user has to switch to it and then repeat the process.
Automatic update updates all modes at once.

Proposed changes.

• eliminate the difference between automatic and manual updates. Regardless of the trigger, the tool always updates all modes (that are outdated).

  • manual trigger still includes two steps: check for updates and download the update. The tool checks if any of the modes is outdated and signals it by rendering an orange border and enabling the option to download the update. The download option updates all modes, including those that are not currently selected.

• Only update files that are explicitly marked as allowed to update. Use new attribute autoupdate="yes" to mark those files, that can be updated (either via automatic or manual trigger). In those cases where multiple elements are allowed in the same mode (e.g. ) it's up to the mode author to ensure correct use of this attribute. Example:

<mode id="sbl">
   <library autoupdate="yes">sa.json"</library>
   <library>other.json"</library>
   <classes>classes.db</classes>
</mode>

sa.json will be updated from SBL other.json will not.

If mode extends other mode, the same rules apply

<mode extends="sbl">
   <library>more.json"</library>
   <classes autoupdate="yes">classes.db</classes>
</mode>

more.json will not update because it does not have autoupdate="yes" attribute. classes.db will be updated in the current mode.

[x87]

Introduce Base modes (extension-only).

<mode id="gta3_base_sbl">
   <library autoupdate="yes">gta3.json</library>
   <classes autoupdate="yes">classes.db</classes>
</mode>

this mode does not have a title attribute, so it won't appear on the edit mode list. But it can be used to create other modes, e.g.

<mode id="gta3_sbl" extends="gta3_base_sbl">
   <examples>opcodes.txt</examples>
</mode>

it uses gta3.json and classes.db from the parent mode.

[x87]

Edge cases (out of scope).

1. base mode and child mode both define <library> element.

<mode id="a">
   <library>a.json</library>
</mode>

<mode id="b" extends="a">
   <library>b.json</library>
</mode>

There is no concept of merging both modes' files, so when mode B is selected, its library (b.json) is used, and parent's library (a.json) is ignored. The same is true for any multi-element declarations, e.g. <opcodes>.

2. Two modes reference the same file, one with autoupdate="yes", the other one without.

<mode id="a">   
   <library autoupdate="yes">..\mode_b\b.json</library> // this is bad
</mode>

<mode id="b">
   <library>b.json</library>
</mode>

The file b.json will be updating. Ideally, modes should not assume presence of other modes other than via extends attribute.

[MiranDMC]

I find it weird that files inside custom user mode can be automatically updated (replaced).
How is local file recognized as equivalent of one on the server? Just by matching filename? Can files with non unique names like "classes.db" be updated at all?
When building extension of already existing mode actual base mode extension mechanism should be used. In more specific cases files can be cherry picked from other mode(base) by using relative paths as you shown.

This kind of smart update complicates whole concept from point of implementation, configuration and user understanding.

• When user like to make backup snapshot of the mode he will just copy entire mode directory and change mode name/id in json file. His copy will be updated anyway (if he does not manage to see autoupdate properties).
• It makes impossible to manual update/revert version of modes. Extracting files from archive will replace base modes, but will not affect files that were auto updated in custom modes.

[MiranDMC]

Having 3 mode identifiers at once is also bit problematic.
There is display name and id in json, plus we have directory.
I have feeling that all these three should be just based on mode's directory name.
Creating backup/starting new mode would be just as easy as creating copy of the directory.
It also solves problem of modes including files from other modes via '..' in file path.

[MiranDMC]

Now it becomes apparent that modes should probably work in same way as $USE directive works.
Base modes just provide game's opcodes and game directory setting, then CLEO plugins have their own extension modes.
We faced that problem with SAMP. Instead just creating new extension mode with new opcodes we struggle how to combine it with base mode.

[x87]

autoupdate="yes" is proposed to update only selected files (the idea is that only base modes will use it). User files won't be modified (unless they use same attribute).

[x87]

implemented in 4.1