Lobbying for an ADD_SPELL improvement

[Galactygon]

A debate in the G3 workroom and the ensuing stalemate prompted me to launch this poll to convince The_Bigg of making ADD_SPELL more useful. We are trying to standardize spell mods so duplicate spells from mods use the same filenames and ids entries - ensuring they are all compatible with each other.

ADD_SPELL right now works the following way (copied from The_Bigg's post) :

Code: [Select]

ADD_SPELL ~mymod/spl/sunscorch.spl~
    1 // 1 = sppr, 2 = spwi, 3 = spin, 4 = spcl
    1 // 1st level
    SUNSCORCH // appended to spell.ids
    SAY NAME1 Sunscorch // list of patches applied to the spell file when copying to the override
    SAY DESC ~blah blah blah~
    // constraint list: stuff like BUT_ONLY. I don't know what I was smoking when I added it; it would cause the IDS to be altered and the file to NOT be copied. Will be completely ignored in 221+.

An important part of ADD_SPELL is if there is an existing ids entry that already is called SUNSCORCH, and it's a level 1 priest spell, then ADD_SPELL will overwrite the actual spell with the new one. With multiple mods adding their own version of Sunscorch, there will be duplicates in the priest scroll, which looks weird. Not to mention one mod's Sunscorch might overwrite another mod's Frost Fingers if they both use the same filename. ADD_SPELL would prevent duplicates from happening, and prevent mod spells from overriding other spells because ADD_SPELL looks for an empty ids if it doesn't find any duplicates.

This sounds really nice, but ADD_SPELLs got one flaw because of its adding-a-new entry nature: If midgame user x decides (s)he doesn't like spell y and uninstalls spell y, then ADD_SPELLs that install after spell y would be searching for and filling the empty slots in. Including the slot that was formerly taken by spell y. Not only that, but spells of the same type and level are also bumped up by one entry - since the next spell would take the entry of the spell that took spell y's entry and so on.

Saved games on the other hand store the RES of the spell. Reloading after uninstall of one component and reinstall of succeeding components will mean the saved game will look for the same spell resources - but now those are different spells! To be blunt, this means that uninstalling even one component that uses ADD_SPELL will break saved games if new spells already appeared in the game. Even a million warning signs won't prevent people from constantly reinstalling individual spells - because - "it's only a single spell".

I've proposed a workaround for this: At the very first ADD_SPELL, the installer would copy a blank text file in the override that will store all of the new entries produced by all the ADD_SPELLs. They key is that this text file would not change when uninstalling the components that use ADD_SPELL - when some of those components are reinstalled later, the ADD_SPELL entries could be recalled from the text file if possible.

The user wouldn't be stuck with the text file - it could be gotten rid of by uninstalling the first component that uses ADD_SPELL *and* exit the setup. The reason I'm saying this is in case the user uninstalls only the first component that uses ADD_SPELL. Then the rest of the components will be reinstalled and thus keep the text file.

I like the idea of this improvement, but it's hit The_Bigg snag - he's not convinced it's such a good idea. If you allow me to quote a part of this discussion from the G3 workroom:

I can't think offhand of what problems could happen, but I tend to trust my gut instinct on this type of issues.

All we're doing is storing information from ADD_SPELLs and recalling that information at reinstall. If someone fiddles/manually appends the SPELL.ids which is used by any of the ADD_SPELLs, that ADD_SPELL would work normally, taking a different slot and updating the stored information accordingly. There is no difference between this and storing the information in some other way

I'd buy into ADD_SPELL if this were implemented. More nods from the interested parties in the yes direction might convince The_bigg to do this.

Frankly, it's the idea of storing information across uninstalls thing that is scaring me, not the specifics of how this is done. Modders are way too good at breaking games by abusing corner cases in this sort of thing.

This is what the poll is for: with enough votes and yes nods we can maybe convince The_Bigg this idea is worth trying for ADD_SPELL.

-Galactygon

[DavidW]

I haven't voted (I'm unpersuaded of the virtues of democracy in this kind of situation), but here's my main worry about components that store information through UNINSTALLs: they create a hysteresis problem, whereby two installs that have the same WEIDU.log actually look different. This really isn't good news for debugging and testing. (Hysteresis already happens with the dialog.tlk file, of course, but there are very good reasons for it, and anyway we're all used to the particular issues it causes.)

[devSin]

I also rate this one a big "no way."

[the bigg]

I haven't voted (I'm unpersuaded of the virtues of democracy in this kind of situation)

Exactly - this isn't "this is hard to do, so I won't do it unless a lot of people need it", but rather "I can foresee this causing problems, so I won't do it even if I get 30 people asking for this".

[Galactygon]

This hysteresis problem is easily solvable by asking the bug reporter to post ADD_SPELL.log (or whatever its name would be), in which case the user's install could be replicated by downloading the ADD_SPELL.log and installing the components the way WeiDU.log dictates.

I feel this disadvantage of asking another .log file is outweighed by the advantage of ADD_SPELL not breaking saved games.

-Galactygon

[GeN1e]

1) Edit savegame upon uninstalling, if that much inclined.
2) People trying to load old saves in new install deserve their share of bugs. It is repeatedly mentioned everywhere not to do so.

[Galactygon]

This has been resolved. Mike1072 has developed some code that will preserve savegames by continuously comparing the SPELL.ids with external files when un/reinstalling individual components. The_Bigg said ADD_SPELL will do this behind the scenes starting v221.

-Galactygon

[GeN1e]

That's cool, but do you guys realise what's the problem's core here? It's not about ADD_SPELL in particular, but about adding new resource into game, storing a reference to it inside a savegame, then uninstalling the resource. ADD_SPELL is only one of the many, same happens if you uninstall kits, items, NPCs, etc. in the middle of your play.

[Turambar90]

I'm glad a solution's been found, as this new function will probably be really useful, considering the fact that spell names can't be prefixed easily.

Another thing I noticed in all ADD_KIT, ADD_SPELL, ... is that the name/ids number of the new resource is not returned by the function. For example, if I use ADD_KIT and then want to apply that kit, I have to read kitlist.2da again and read the last number, before writing it.
Wouldn't it be useful to be able to write a variable name, where the name automatically given by the function is stored?

[the bigg]

ADD_KIT ~C!Selune~ sets a ~%C!Selune%~ variable, etc.