Jump to content

SPELL.IDS coding discussion


Recommended Posts

EDIT by DavidW: split from SCS v32 RC8 testing thread.

On ‎1‎/‎18‎/‎2019 at 9:51 AM, DavidW said:

in the meantime, I don't recommend using Might and Guile's bard component along with ... IWDification.

Come now, let's not be hasty and give bad advice.  IWDification is installed before M&G, and M&G looks for the IWDification spells and uses them if they exist.  M&G and IWDification are perfectly, utterly, 1,000% compatible.

Now, if the player has not installed IWDification, I still want to give M&G bards access to the Shout spells, which are grouped with a few other sound/word-based spells and treated (for purposes of the mod) almost like a 9th school of magic: bardic magic.  This all worked perfectly well for plenty of time; in fairness, it all existed and worked fine well before SCS came along and started installing IWD spells.  (And tbh I'm still not totally clear on why SCS is suddenly doing that, rather than deferring to the players choice in adding them or not, by having installed IWDification beforehand... BUT I'm not asking you to justify that decision, I don't think it needs any justification.  It's fine.  It's just that it will necessarily create the need for adjustments elsewhere, since spell-adding mods like IWDification are generally installed looong before SCS in the load order, and a lot of mods heretofore have likely been assuming that order.)

The Shout spells need IDS entries because the array of spells available to bards operates via IDS names.  What the mod does is allow bards to cast spells spontaneously, using a casting system identical to the way sorcerers cast spells.  To do that, it needs to make innate clones of any wizard or priest spells that are available to bards.  It's been a while since I coded this but I think my rationale for making the spells innate rather than arcane is 1) if they were arcane I'd just have to make an innate clone anyway; and 2) given the assumption that spell-adding mods are installed before M&G, there's a decent likelihood that all of the available SPWI### slots might be taken, which would cause ADD_SPELL to fail and prevent the spells being added.  This is not a concern with SPCL### slots.

As for why I specifically used WIZARD_SHOUT: it's because the most likely event is that such spells will be added before M&G, not by M&G, and that's the spell that gets fed into the code that generates the spontaneous casting system.  I suppose that I could change it to BARD_SHOUT, but that would introduce the chance of bugs such as bards getting two different versions of the same spell.  At the time this was coded, there were no downsides or bugs resulting from calling it WIZARD_SHOUT.

So, that's the wall of text by way of explanation.  I have three thoughts going forward:

1) I'm not sure how SCS is adding these spells... but if ADD_SPELL is used shouldn't it just overwrite the IDS entry?  It's been a long time since I looked at this kind of stuff but my recollection is that "the last ADD_SPELL wins," if you will.  I don't think it would break M&G if SCS overwrote the spell; by using ADD_SPELL I thought I was allowing for the possibility that later mods might do so...

2) For players, notwithstanding that SCS now adds IWD spells and I fully expect, given the author, that it does an excellent job of adding them, my advice would be to continue to use IWDification for that purpose.  As I said, there are a number of mods (I can't say how many, I'd guess somewhere in between "several" and "lots") which expect spells to be added relatively early in the install order, and which may specifically look for whether IWD spells have been added early in the order.  SCS may do a fine job of adding them for its own purposes, but you may likely see issues from other mods if you decide something like "I don't need to use IWDification, I'll just let SCS add those spells."  Unless there's a specific, articulable reason not to use IWDification (such as the couple years when IWDification spells were not fully updated to IWDEE standards, during which time "B_Spells" stepped in to fill the gap)... then just use IWDification.  From what I've read SCS v32 is designed with IWDification compatibility in mind, it should not hurt anything to install both together.

3) I think it shouldn't break anything if I change the M&G version from WIZARD_SHOUT to BARD_SHOUT or something like that.  Not 100% on that - the spontaneous casting code is pretty complex (by my standards anyway) and I haven't looked at it in a while.  But assuming it doesn't break anything, or that it breaks things that are easily adjustable, then I'll make that change when I get a chance.

Link to comment

IWDification is installed before M&G, and M&G looks for the IWDification spells and uses them if they exist.  M&G and IWDification are perfectly, utterly, 1,000% compatible.

The problem I have in mind is when IWDification is installed after M&G. IWDification will do what SCS does: look for WIZARD_SHOUT, find it, and erroneously conclude that the spell is already present and so needn't be added.

Granted, you can work around that by install order (and I should probably have said so). But (a) install-order requirements should be kept to a minimum, and (b) while M&G's install instructions say to install it after item/kit mods, they don't mention spell mods.

And tbh I'm still not totally clear on why SCS is suddenly doing that, rather than deferring to the players choice in adding them or not, by having installed IWDification beforehand... 


Because

(a) there are a number of choices about how to integrate that IWD and BG2 spell systems where I prefer my choices to IWDification's. (Notably: Mordenkainen's Sword, Monster Summoning, Conjure Elemental, Chant - there are others.)

(b) I much prefer having an implementation that autoconverts the IWDEE resources rather than doing it manually: better for translations, more future-proof, and probably more reliable in the longer term. 

(c) It is very valuable for QA to have direct control over the spellsystem.

(d) SCS has more visibility and is used even by people who don't use mods much; since a big chunk of SCS now responds to IWD spells, I have an incentive to improve their visibility to players.

(The issue of 'deferring to players choice' is a red herring: these are optional components.)

As for why I specifically used WIZARD_SHOUT: it's because the most likely event is that such spells will be added before M&G, not by M&G, and that's the spell that gets fed into the code that generates the spontaneous casting system. 



Hang on: so if WIZARD_SHOUT is already present you're adding it, cloning it, and not having WIZARD_SHOUT point to the innate clone; but if WIZARD_SHOUT is *not* already present you're adding a new *innate* spell called WIZARD_SHOUT? I don't at all see the need to do that. Why not just check if WIZARD_SHOUT is present; if it is, clone it; if it isn't, add your own innate spell directly?

I think the answer is that your code is written to require it. But it doesn't need to be. (Following post will elaborate.)


At the time this was coded, there were no downsides or bugs resulting from calling it WIZARD_SHOUT. 


I don't think this is the optimal approach to compatibility, which ought to include attention to the conventions rather than just auditing the presently-available mods. WIZARD_SHOUT, both by general conventions and by the precedent of IWDEE itself, refers to a *wizard* spell: learnable by sorcerers, provided with scrolls, in the SPWI spellspace, etc. 


1) I'm not sure how SCS is adding these spells... but if ADD_SPELL is used shouldn't it just overwrite the IDS entry?  It's been a long time since I looked at this kind of stuff but my recollection is that "the last ADD_SPELL wins," if you will.  I don't think it would break M&G if SCS overwrote the spell; by using ADD_SPELL I thought I was allowing for the possibility that later mods might do so... 


IWDification and SCS both demur from overwriting existing spells, on the assumption that the player chose to install those spells and presumably knows what they're doing. But frankly, if you did tell either one to overwrite (and both have an ini option that tells them to) I think it would make a mess: they'd find WIZARD_SHOUT in spell.ids, get back something like SPCL423, and overwrite that slot - which would confuse both your bard kit and the spell-allocation system (e.g. sorcerers wouldn't get access.)


3) I think it shouldn't break anything if I change the M&G version from WIZARD_SHOUT to BARD_SHOUT or something like that.  Not 100% on that - the spontaneous casting code is pretty complex (by my standards anyway) and I haven't looked at it in a while.  But assuming it doesn't break anything, or that it breaks things that are easily adjustable, then I'll make that change when I get a chance. 


Meantime, the next version of SCS can map it across to BARD_SHOUT if it detects it's in the wrong corner of namespace.

 

Link to comment

In any case, you don't need spell.ids entries for M&G. Unless I'm missing something, the *only* reason you need them is so that your code can parse the spell.ids entries in d5brdspl.2da. That's not a good reason to occupy valuable real estate in the SPCL namespace.  Do something like this instead. (Not checked.)

(1) Around line 2075 of 210_revised_bards.tpa, instead of doing

ADD_SPELL ~override/d5shout.spl~ 4 3 WIZARD_SHOUT

just do

OUTER_SPRINT WIZARD_SHOUT "d5shout"

(and similarly for the other spells you add.)

(2) Around line 2600 there is a chunk of code that goes

PATCH_IF (IDS_OF_SYMBOL ("spell" "%spont_spell%") > 0) BEGIN
    LPF RES_NUM_OF_SPELL_NAME STR_VAR spell_name = EVAL ~%spont_spell%~ RET spell_res END
    PATCH_IF FILE_EXISTS_IN_GAME ~%spell_res%.spl~ BEGIN
            [do some stuff]
        END
END


Replace it with something like

PATCH_IF (IDS_OF_SYMBOL ("spell" "%spont_spell%") > 0) BEGIN
    LPF RES_NUM_OF_SPELL_NAME STR_VAR spell_name = EVAL ~%spont_spell%~ RET spell_res END
END ELSE BEGIN
        SPRINT spell_res EVAL "%spont_spell%"
END
PATCH_IF FILE_EXISTS_IN_GAME ~%spell_res%.spl~ BEGIN
         [do some stuff]
END

That way, instead of putting the spell into spell.ids (which is visible to everyone and clogs up namespace) you've just put it into your own variable, which gets checked if there's no spell.ids entry present. 

Link to comment
59 minutes ago, DavidW said:

The problem I have in mind is when IWDification is installed after M&G.

But, that should never happen.

Quote

Granted, you can work around that by install order (and I should probably have said so). But (a) install-order requirements should be kept to a minimum, and (b) while M&G's install instructions say to install it after item/kit mods, they don't mention spell mods.

Not sure what game you've been playing ( ;) ) but in my experience install order is of the utmost, paramount importance, and I've created all of my mods from their very inception with very clear ideas of precisely where in the install order they need to be.  And I try to communicate that to players.  If the M&G readme doesn't make clear that IWDification should be installed first, that is something I should clarify. 

59 minutes ago, DavidW said:

Hang on: so if WIZARD_SHOUT is already present you're adding it, cloning it, and not having WIZARD_SHOUT point to the innate clone; but if WIZARD_SHOUT is *not* already present you're adding a new *innate* spell called WIZARD_SHOUT? I don't at all see the need to do that. Why not just check if WIZARD_SHOUT is present; if it is, clone it; if it isn't, add your own innate spell directly?

I think the answer is that your code is written to require it. But it doesn't need to be. (Following post will elaborate.)

Well, yeah, more or less: if the player has IWD spells installed then they will have IDS names, and I wrote the spontaneous casting code with the expectation that the subset of spells available to bards will have that characteristic.  The (subsequently-added) fallback for situations where Shout isn't installed by other mods simply attempts to create the environment that the spontaneous code expects to find.  I put them in the SPCL range specifically to avoid taking up far more valuable real estate in the SPWI space.

59 minutes ago, DavidW said:

IWDification and SCS both demur from overwriting existing spells, on the assumption that the player chose to install those spells and presumably knows what they're doing. But frankly, if you did tell either one to overwrite (and both have an ini option that tells them to) I think it would make a mess: they'd find WIZARD_SHOUT in spell.ids, get back something like SPCL423, and overwrite that slot - which would confuse both your bard kit and the spell-allocation system (e.g. sorcerers wouldn't get access.)

IWDification uses ADD_SPELL, and my (again, admittedly distant) recollection is that subsequent uses of ADD_SPELL will overwrite the IDS entry, not the referenced file.  So:

- M&G: ADD_SPELL ~override/d5shout.spl~ 4 3 WIZARD_SHOUT

...spell is created as SPCL319SPL (or whatever)

- IWDification: ADD_SPELL ~override/iwdshout.spl~ 1 3 WIZARD_SHOUT

...spell is created as SPWI342.SPL (or whatever); SPCL319.SPL still exists but scripts referring to WIZARD_SHOUT will now point to SPWI342.SPL

Maybe I'm mistaken about that. But in any event it's academic, this is a fairly minor conflict and there are several ways to cure it, I'll put them on my to-do list.

Edited by subtledoctor
Link to comment
1 hour ago, subtledoctor said:

if the player has IWD spells installed then they will have IDS names, and I wrote the spontaneous casting code with the expectation that the subset of spells available to bards will have that characteristic.  The (subsequently-added) fallback for situations where Shout isn't installed by other mods simply attempts to create the environment that the spontaneous code expects to find.  I put them in the SPCL range specifically to avoid taking up far more valuable real estate in the SPWI space.

But they don't need to be taking up space in the IDS namespace at all (even leaving aside the problems caused by having WIZARD_SHOUT point to something that isn't the Wizard spell 'Shout', or indeed a wizard spell at all). The only reason it's in that namespace is because you want to look it up by IDS entry, and you can code around the need for that.

 

1 hour ago, subtledoctor said:

IWDification uses ADD_SPELL, and my (again, admittedly distant) recollection is that subsequent uses of ADD_SPELL will overwrite the IDS entry, not the referenced file

IWDification explicitly checks if the spell is there, and ADDs it only if it's not there. It has lines like this before every spell:

ACTION_IF (!FILE_CONTAINS_EVALUATED(~spell.ids~ ~WIZARD_SNILLOCS_SNOWBALL_SWARM~) OR override_arcane) BEGIN
   

SCS has something similar (though the code is a bit more abstracted).

 

Link to comment

I missed this, sorry:

52 minutes ago, subtledoctor said:

in my experience install order is of the utmost, paramount importance, and I've created all of my mods from their very inception with very clear ideas of precisely where in the install order they need to be. 

Install order is often unavoidably important, to be sure, but it's not good practice to rely on it when you don't have to, because it's not automatically enforced and because different mods often (usually!) give contradictory advice as to which should be installed last. As far as I can see (I could always be missing something) there is no structural reason why M&G needs to be installed after IWDification, so why code in a way which requires it?

57 minutes ago, subtledoctor said:

If the M&G readme doesn't make clear that IWDification should be installed first, that is something I should clarify. 

It just says "Might and Guile should be installed after all other mods that add or change items or kits. It should be installed after the "WSPATCK for All" component of tb#Tweaks. It should be installed before Refinements and Sword Coast Stratagems." (It then goes on to give your 'personal install order' but there's no suggestion that's compulsory.)

 

 

Link to comment
4 hours ago, DavidW said:

But they don't need to be taking up space in the IDS namespace at all

This, this, and an extra this. There are only two reasons to insert spells into this namespace: if you need them to be accessible to sorcerer/shaman spell selections at level-up, or granted automatically to divine casters.

Link to comment
1 hour ago, CamDawg said:

This, this, and an extra this. There are only two reasons to insert spells into this namespace: if you need them to be accessible to sorcerer/shaman spell selections at level-up, or granted automatically to divine casters.

I wouldn’t go quite that far myself. SPPR and SPWI, yes, absolutely, but given the only benefit of a spell being in SPIN is that you can refer to it via spell.ids in scripts (and so it’s not as if we’re saving space for other purposes), I’ve been known to put spells in that namespace for scripting purposes. 

Link to comment
8 hours ago, DavidW said:

 As far as I can see (I could always be missing something) there is no structural reason why M&G needs to be installed after IWDification, so why code in a way which requires it?

In this case I merely assumed in M&G that IWDification, b_Spells, Faiths & Powers, etc. (i.e. every extant mod that adds IWD spells prior to the birth of SCSv32) would be installed beforehand, for the simple reason that every reasonable person I've ever interacted with on these and other forums installs them that way.  And rightly so!  It's not anything specifically to do with M&G and IWDification (well, at least, I didn't think it was until this was brought to my attention); rather, the issue is that M&G needs to be installed after various other particular mods, and some of those various other mods are meant to be installed after IWDification.

Almost every mod in someone's install order needs to be in a particular place in relation to several other mods; and the same holds true for those mods.  They are all interconnected.  People have gone to great lengths to figure out ideal install orders that allow lots of mods to work well together.  There's no reason not to respect that. 

4 hours ago, CamDawg said:

This, this, and an extra this. There are only two reasons to insert spells into this namespace: if you need them to be accessible to sorcerer/shaman spell selections at level-up, or granted automatically to divine casters.

I respectfully disagree.  I would never needlessly take up space in the SPWI/SPPR range, but the SPIN/SPCL ranges are fairly deserted.  I don't - presently - see much danger in adding an entry or two there.  There are only ~100 available spellstates; I declined to make a mod that uses 40 of them, but I have no hesitation using two or three.  The cleric kit usability flags were untouched forever because there are only three of them... but when I made a cleric kit mod and those three flags were useful in giving unique item restrictions to 65+ kits, the benefit started to outweigh the harm.  I have an alpha-ish psionics mod that currently uses the ammo3 item slot, which is a singular resource.

These games are two decades old.  There's no sense letting these things go unused forever just because they are scarce.

Edited by subtledoctor
Link to comment
On 1/13/2019 at 4:00 PM, TheLoneTremere said:

Hmm, it doesn't seem SCS iwdification comes with shout/greater shout.

 

13 hours ago, DavidW said:

in the meantime, I don't recommend using Might and Guile's bard component along with SCS's IWD spells (or with IWDification).

 

11 hours ago, DavidW said:

( these [adding IWD spells] are optional components.)

 

Not to harp on the load order thing, but if the SCS IWD spells are in a separate component, then perhaps an interim solution would be to simply install that component, then M&G, and then the rest of SCS

Edited by subtledoctor
Link to comment
32 minutes ago, subtledoctor said:

Almost every mod in someone's install order needs to be in a particular place in relation to several other mods; and the same holds true for those mods.  They are all interconnected.  People have gone to great lengths to figure out ideal install orders that allow lots of mods to work well together.  There's no reason not to respect that. 

Sure, respect install order, but don't needlessly code in a way that forces one install order rather than another. 

 

33 minutes ago, subtledoctor said:

I would never needlessly take up space in the SPWI/SPPR range, but the SPIN/SPCL ranges are fairly deserted.  I don't - presently - see much danger in adding an entry or two there.

I mostly agree (as I said above) though I think it's a little silly to do it if the only reason is to make your install-time lookup table simpler to code.

But the real problem isn't occupying the SPIN/SPCL range; it's doing it with an ids entry that falsely identifies a SPCL spell as the wizard spell Shout. That's just a dangerous thing to do, install order or no install order.

Scenario, just to make the point: in fact, SCS is coded to use spell systems in an all-or-nothing way. But a more piecemeal mod is perfectly possible, that checks, spell-by-spell, what's installed. A mod like that would look at the IDS file, discover that WIZARD_SHOUT is present, try to use it, and probably throw an install-time error when it turns out that WIZARD_SHOUT isn't what it would be expected to be.

I'm really quite perplexed to be having to have this conversation with you given you were actually part of the SR conversation about standardizing spell.ids entries!

Link to comment
7 hours ago, subtledoctor said:

The cleric kit usability flags were untouched forever because there are only three of them... but when I made a cleric kit mod and those three flags were useful in giving unique item restrictions to 65+ kits, the benefit started to outweigh the harm.

Right, and they (plus a few other flags) were being used by SPC since 2004. I'm not against using limited resources but I will ask--as should anyone--why they're being used when there are easy, equivalent methodologies available.

Link to comment
1 hour ago, CamDawg said:

Right, and they (plus a few other flags) were being used by SPC since 2004. I'm not against using limited resources but I will ask--as should anyone--why they're being used when there are easy, equivalent methodologies available.

The method used is based on old knowledge as there is 15 years between now and 2004. Of course there's things that are not compatible with across moding things.

Yeah, it might be a good move to move to the EE moding only. But that's only if you want to. And in there, the kit flags aren't the most comfortable to use resource either. 

Link to comment

Join the conversation

You are posting as a guest. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...