8 replies to this topic

[Turambar]

In the most recent WeiDU versions, new functions such as ADD_SPELL have appeared. I believe there is something which we should consider about them:

I think that ADD_SPELL is a very useful tool, as it prevents spells added by mods (which can't be prefixed, if you want to allow priests, sorcerers,... to have them) from overwriting each other.
In particular, this command grants a unique number in the ids file, and this is an important thing for some other .ids files as well.
I believe that all mods should do something similar whenever they patch any .ids file (for instance, my tweakpack has to append one line to specifics.ids, and looks for a 'free line' instead of using a fixed number); the .ids I'm refering to are stats (which is, though, completely used by BP, so I believe that it's impossible to still modify it), specifics, spells, and those which can be changed without problems to the game (other .ids, such as GTimes, have a unique meaning).
Problems could arise, though, if a mod, written before that function existed, is installed after a new mod: the old mods used places which were known to be unused, but with the new functions they could be automatically occupied, if their number is low enough.
I think that the installation order should be modified to reflect these issues, but there are still some mods (for example, the megamods) which have to be installed quite early, and this means that they can never be moved to the new system...
So, I think that there should be an index of all old-style mods (those which change .ids files without reading them), which have to be installed first, and every modder, whose mod has no specific order requirements, should turn to the new system, for evry kind of ids patching. For example, I believe that BP and SCS, which come quite late in the order, should turn to the new functions, otherwise they'll prevent quite many other mods from being updated (I'll suggest that to them on their own forum).
Finally, as the ids files can only have a limited number of rows, I'll suggest to avoid using them, if you can: if you can use a prefixed local variable instead of setting a new state, or if a spell desn't need to be learned by sorcerers or removed via opcode or script and you can use a prefixed resource without the SP**### form (every cast spell action has its RES version, in scripts), I'd suggest that you use it.

Do you think that such a 'behaviour code' can be applied? I posted my thoughts here because I think we should chose a behaviour to follow in future mods; otherwise, we will meet serious compatibility issues; if you have any other suggestion, I'll thank you very much.

[Jarno Mikkola]

In the most recent WeiDU versions, new functions such as ADD_SPELL have appeared. I believe there is something which we should consider about them:

I think that ADD_SPELL is a very useful tool, as it prevents spells added by mods (which can't be prefixed, if you want to allow priests, sorcerers,... to have them) from overwriting each other.

So as you haven't linked to a tutorial on how this feature is used, you really should... or make a simple example. Speaking of experience, I don't know how it's used, so ?

Now, what comes to the "huge former BP" -mods, they are still modified primarily by Hoppy, so it's not set in stone that they need to be installed the first chance they get... as we can get them away from biffing the whole override folder with them, we can install them later.

[Galactygon]

I'll repost part of a summary I wrote some weeks ago:

ADD_SPELL right works the following way (copied from an earlier post from The_Bigg) :

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~

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.

So what we really need right now that ADD_SPELL does not break saved games at (un/re)installs are:
(i) a standardized list of spell ids symbols used by all of the IE mods, and someone who is willing to maintain the list as new mods are released.
(ii) conversion of all of the old mods (and scripts) to use ADD_SPELL using the standardized list.

(I have converted all my stuff in SpellPack B6 to use ADD_SPELL, but part of the reason for me refraining from a release has to do with a lack of a standardized list of ids symbols which we can all use.)

-Galactygon

[Turambar]

I think that ADD_SPELL is a very useful tool, as it prevents spells added by mods (which can't be prefixed, if you want to allow priests, sorcerers,... to have them) from overwriting each other.

So as you haven't linked to a tutorial on how this feature is used, you really should... or make a simple example. Speaking of experience, I don't know how it's used, so ?

The new feature is described in the WeiDU Documentation.

For examples, you can see how Galactigon described it (edit: see post above!), and here's an example of where I used it:

ADD_SPELL ~BPv180/Orcus/SPWI540.SPL~ //resource to be added
2 //wizard
5 //level 5
WIZARD_DARKNESS_15_RADIUS //name it will have in spell.ids
  //patch list, as you would write them if you added the spell with a COPY command:
  SAY NAME1 @383 
  SAY UNIDENTIFIED_DESC @384 
  SAY 0xce @385
//and you could put any other patch here

The spell will receive the name SPWI5## (the first number not already used, and the variable WIZARD_DARKNESS_15_RADIUS will be set to 25## :first number for spell type (wizard, priest, innate,..) second for level, and the spell number.
Thanks to the SP[class][level][number] resource name, the game will treat it as a normal spell, whereas if I had just copyed it as TUSPELL.spl, it would not have appeared in the known spell selection screen, nor would it be possible to remove it per script and so on.
I hope this description and these links are enough, otherwise, I'll try to explain it better.

Now, what comes to the "huge former BP" -mods, they are still modified primarily by Hoppy, so it's not set in stone that they need to be installed the first chance they get... as we can get them away from biffing the whole override folder with them, we can install them later.

Of course, allowing the megamods to be installed at any time would be great; still, I was thinking of DS and SoBH, which need BGT, but are apparently not supported at the moment (erebusant's not been connected for quite a long time).
Now, I don't know if BGT adds any spells; still, there could be other 'old-style' mod which need those mega-mods, which could cause problems

Edited by Turambar, 07 November 2010 - 03:20 AM.

[GeN1e]

if a spell desn't need to be learned by sorcerers or removed via opcode or script and you can use a prefixed resource without the SP**### form (every cast spell action has its RES version, in scripts), I'd suggest that you use it.

There's RemoveSpellRES() as well, and opcode only takes the resource name into account, so the only reason to ADD_SPELL is to make it appear automatically on spell selection screens.

So what we really need right now that ADD_SPELL does not break saved games at (un/re)installs are:
(i) a standardized list of spell ids symbols used by all of the IE mods, and someone who is willing to maintain the list as new mods are released.
(ii) conversion of all of the old mods (and scripts) to use ADD_SPELL using the standardized list.

Well, as I've said over PPG, patching saved spells is only 10% of ensuring any mod can be safely uninstalled. And in some cases it is outright impossible to 100% roll back.

(ii) - use mod's abbreviation (TDD, CTB) or mod author's prefix.

To be sure I understand you right - you only talk about mods that append to the 'spell selection' screen (or spins, for that matter), not just random scrolls with new wizard spells?

PS Gaaahhh, I've just realized the mod I'm worknig on copies over a number of un-prefixed spcls for, it would seem, no real reason.

Edited by GeN1e, 07 November 2010 - 09:02 AM.

[Turambar]

if a spell desn't need to be learned by sorcerers or removed via opcode or script and you can use a prefixed resource without the SP**### form (every cast spell action has its RES version, in scripts), I'd suggest that you use it.

There's RemoveSpellRES() as well, and opcode only takes the resource name into account, so the only reason to ADD_SPELL is to make it appear automatically on spell selection screens.

From IESDP:

#172 (0x0AC) Spell: Remove Spell [172]
Parameter #1: Irrelevant
Parameter #2: Irrelevant
Description:
Removes the spell specified by the resource key from the targeted creature(s) spellbook (but does not affect spells already memorised). Only affects spells with the SPPR/SPWI/SPCL/SPIN naming convention.
Both parameters should be 0 (zero).

Unless they're wrong, the opcode needs the SP[class] naming.
And anyway, sorcerers can only get them through spell selection screens and the corresponding scrolls must exist; otherwise, no-one will be able to use those spells; for priest spells, it would be necessary to add them via CLAB table.

Edited by Turambar, 07 November 2010 - 09:24 AM.

[Jarno Mikkola]

And anyway, sorcerers can only get them through spell selection screens and the corresponding scrolls must exist; otherwise, no-one will be able to use those spells; for priest spells, it would be necessary to add them via CLAB table.

Well, if it's a sorcerer only spell, you don't have to make a scroll, cause you really cannot... and the HLAs also give spells, and one can make other items that allow the learning of spells... so the scrolls are unnecessary for most functions.

[Turambar]

And anyway, sorcerers can only get them through spell selection screens and the corresponding scrolls must exist; otherwise, no-one will be able to use those spells; for priest spells, it would be necessary to add them via CLAB table.

Well, if it's a sorcerer only spell, you don't have to make a scroll, cause you really cannot... and the HLAs also give spells, and one can make other items that allow the learning of spells... so the scrolls are unnecessary for most functions.

What I mean is, it's for mages and sorcerers. If there are no scrolls and it's not in the screens, noone can get them in 'normal' ways.

Edited by Turambar, 07 November 2010 - 10:00 AM.

[GeN1e]

Unless they're wrong, the opcode needs the SP[class] naming.

Thanks, I sometimes forget to post corrections to IESDP forum when I ought to.