Secondary effects

[Chacal]

About rolling back changes (uninstalling).
What to do with changes that have secondary effects?

Let's say I add a new Relto page to Teledahn.
This Relto page adds a chair to my Relto.
So I distribute my changes: objects in teledahn and Relto, SDl variables added to sdl files, maybe some Python code.

The player goes to Teledahn, gets the new Relto page, now there's a new chair in his Relto.
Then he uninstalls the distro. Teledahn goes back to normal, so does Relto.

But what about the page in his Relto book? There's a value in the Vault that says he sould have it, but it doesn't exist anymore.
Would this value be deleted from the vault when we "delete" the SDL variable (i.e. add a new VERSION in the SDL file without this SDL variable)?

[Paradox]

You cannot remove SDL variables in a new version! It is pretty much guaranteed to cause problems.

[D'Lanor]

Actually you can remove an SDL variable in a NEW version, but only if the previous SDL version is still present in the SDL file. This has been confirmed for both UU and Alcugs.
But why should you? This would be the worst reason to crank up the SDL version. An SDL variable which is no longer used can do no harm at all. The vault or the age state does not care what it was used for. There just won't be anything in the game files calling it.

That being said, Offline (which is where this tool will be used mostly I guess) SDL versions don't matter that much.

[diafero]

I do not know how the UAM plugin knows which Relto pages are available, but if you revert the change that makes the book know about the page (for the original pages, there is a hard-coded list in some Python file), it will no longer show up in the book.
Handling and reverting and merging SDL will generally be quite complicated with UruDistro, I suppose. Even worse, if you apply the patches in a different version than someone else, you will end up with a different SDL file (and maybe even a different order of those options in the file).

You cannot remove SDL variables in a new version! It is pretty much guaranteed to cause problems.

What D'Lanor said - why do you think it causes problems? I actually already did that in Offline KI.

That being said, Offline (which is where this tool will be used mostly I guess) SDL versions don't matter that much.

How that? The game does not need old SDL versions for reading the current state, as it has a copy of the SDL in the age state, but if you increase the version in the file, the game will notice and upgrade to the new version. So, there are less ways to break the game using SDL, but if you want to add a new variable, you have to do the same as online.

[Paradox]

You cannot remove SDL variables in a new version! It is pretty much guaranteed to cause problems.

What D'Lanor said - why do you think it causes problems? I actually already did that in Offline KI.

Ah, okay... It must have been the "removing variables in an existing version" scenario that I was thinking about.
I recall SDL in the Vault being stored in sequential order of variable definition in the .sdl file, and if those get out of sync then bad things happen.

For offline use, this actually sounds like a case where storing a list of pages in a chronicle would be a valid argument.
Online, the SDL is configured by the shard admin, which should ensure that everyone has matching state definitions.

[D'Lanor]

That being said, Offline (which is where this tool will be used mostly I guess) SDL versions don't matter that much.

How that? The game does not need old SDL versions for reading the current state, as it has a copy of the SDL in the age state, but if you increase the version in the file, the game will notice and upgrade to the new version. So, there are less ways to break the game using SDL, but if you want to add a new variable, you have to do the same as online.

Offline I have been adding SDL variables to the same version and they work fine (even without deleting the age state/sav file). And I suspect most age writers do it that way. As a rule I only update the SDL version for official releases because they will be used on shards. And only if one or more variables were added (or deleted) of course.

[diafero]

Offline I have been adding SDL variables to the same version and they work fine (even without deleting the age state/sav file). And I suspect most age writers do it that way.

Ouch, that really works? Weird.

[Chacal]

Handling and reverting and merging SDL will generally be quite complicated with UruDistro, I suppose.

Actually it is quite simple.
Adding or modifying SDL variables is done the same way as we do it manually, which I think is the way Cyan intended:
1- copy the last version
2- increment the version number
3- add variables or modify values

Removing SDL variables (which make sense only when undoing changes) is actually the same thing:
1- copy the last version
2- increment the version number
3- remove variables

Thus UruDistro should cause no problem even when removing variables, even though, as D'Lanor said, it is not essential to do so.

Even worse, if you apply the patches in a different version than someone else, you will end up with a different SDL file (and maybe even a different order of those options in the file).

Precisely. What could cause a problem is an application that replaces the whole SDL file, or adds a new version, without first looking at the contents of the existing file.
I think this should never be done for off-line Uru, because you cannot presume the SDL file has not been modified by its owner.
If everyone does the same thing as UruDistro does, there should never be a problem.

[diafero]

Yes, it should work in theory, with the only side-effect being the SDL files getting *really* large. And since SDL seems to be much less critical offline, it seems a little mistake is not that bad. It still leaves a somewhat bad taste though, since the SDL system is... the way it is
That is, it will work unless packages start to modify files that Offline KI (or other packages) also contain. I can of course not compensate for all possible versions people have out there.