17 replies to this topic

[Miloch]

(continuing from this thread to avoid spamming the SCS2 forum)

So I ran your code, GeN1e, but it didn't appear to patch any spells. Maybe I'm not doing something right... this is what I used:

OUTER_SPRINT path ~ascension/ds~
OUTER_SET khelben_broken = 0 //This you can include in the setup macro
//(otherwise not initialising it will raise an error)

INCLUDE ~ascension/ds/ds.tph~

LAUNCH_ACTION_MACRO ~setup~ //This you could probably call from the main DS macro rather than the tp2
LAUNCH_ACTION_MACRO ~detectable_spells~

//Fixes Kelsey if installed (also could be called from the DS macro)
ACTION_IF FILE_EXISTS_IN_GAME ~j#ceara.bcs~ BEGIN
  INCLUDE ~ascension/ds/ds_oldscript.tph~
  OUTER_SPRINT ~oldswapfile~ ~ascension/ds/oldds_swap.2da~
  OUTER_SPRINT ~marker~ ~dw#fixkelsey.mrk~
  OUTER_SPRINT ~oldfiles~ ~ascension/ds/oldfiles_kelsey.2da~
  LAUNCH_ACTION_MACRO ~fix_old_DS_scripts~ 
END

The only file it modified was Ascension's spdetect.spl, by stripping all but three of the #282 opcodes out of it. The original Ascension has a huge host of files with these opcodes added - I can generate a list if you want, though you could probably do so even quicker. Also, I had to include a fj_spl_itm_eff_v2.tph to get it to run, which I swiped from Level1NPCs (it is defined as a function there, but that's the most recent version I know of).

Some comments:

//first, special patches. We need to remove melis02's existing script state modifier

What about other such spells, like the balth* series? Even before Ascension, I think these have a load of script state modifiers.

// set the only difference between ITM and SPL files.
    READ_ASCII 0 first_chars (3)
    PATCH_IF ~%first_chars%~ STRING_COMPARE_CASE ~SPL~ BEGIN // if it's an ITM (_not_ a SPL)
      SET extended_size = 0x38
    END ELSE BEGIN
      SET extended_size = 0x28
    END

Why not use (~%SOURCE_EXT%~ STRING_EQUAL_CASE ~itm~) instead?

[GeN1e]

Sorry, I was busy.

Check this package. Everything appears to work, expect fixing old scripts - I better check for those mods actually being installed, rather than patch blindly. Will do today evening.

Usage - insert this into installer

INCLUDE ~path/ds.tph~
LAF detectable_spells_setup STR_VAR path = ~path~ END // launch it once
LAF detectable_spells       STR_VAR path = ~path~ table = ~cddetect.2da~ END
//LAF detectable_spells       STR_VAR path = ~path~ table = ~mytable.2da~ END

'Path' is obvious. 'Table' - whichever one you want to use, CDDETECT being the universal one. Several tables can be used.

Table.2da:
FILE - the file
OPCODE - new opcode to insert, usually 233 or 282
PAR1 - value for OPCODE
PAR2 - stat for OPCODE
CLONE - which opcode to copy from
TICK - if CLONE is ticking (Khelben), set it to a value; if set to non-zero, it will be added to the max duration (may come in handy for BP)
PATCH_WHAT - 'G' is global effect, 'A' is ibility header, value is a specific header (starting from 0)



Lists of files - yep, I have them.
Vanilla

BHAAL3A.SPL - 282 2 1
BLAKBLAD.ITM - 233 90 5
HAERPROF.SPL - 233 90 2
HAERPROF.SPL - 233 91 2
HAMM10.ITM - 282 2 1
HAMM11.ITM - 282 2 1
MELIS02.SPL - 282 9 1
SHAKTI1.ITM - 233 91 2
SPCL152.SPL - 282 2 1
SPCL741.SPL - 282 2 1
SPIN854.SPL - 282 0 1
SPPR409.SPL - 282 1 1
SPPR413.SPL - 282 2 1
SW1H61.ITM - 282 2 1
SW1H69.ITM - 282 2 1

Ascension

BALSWD.ITM - 282 2 1 #
BALTH02.SPL - 282 1 1 #
BALTH02.SPL - 282 2 1 #
BALTH02.SPL - 282 0 5 #
BALTH11.SPL - 282 4 1 #
FOCUS.SPL - 282 0 1 #
MELIS02.SPL - 282 1 1 #
MELSPL01.SPL - 282 4 1 #
MELSPL03.SPL - 282 0 1 #
MELSPL11.SPL - 282 2 1 #
NABPARA.SPL - 282 0 1 #
POOL1A.SPL - 282 1 1 #

Leave both alone. Or convert Ascension's to 'table.2da', if you've got some time to kill
The huge load of 282s in SPDETECT is also completely useless. Can safely be killed.

Also, check FINMEL.BCS

IF
  Allegiance(Myself,ENEMY)
  !HPLT(Myself,20)
  !GlobalTimerNotExpired("Spell","LOCALS")
  !GlobalTimerNotExpired("LockTarget","LOCALS")
  Global("Draw","LOCALS",0)
  !CheckStatGT(Myself,0,SCRIPTINGSTATE2)
  Range(NearestEnemyOf(Myself),<img src='http://www.shsforums.net/public/style_emoticons/<#EMO_DIR#>/cool.gif' class='bbc_emoticon' alt='8)' />
  Global("CloseCombat","LOCALS",1)
  !DifficultyLT(EASY)
  !GlobalTimerNotExpired("GlobeOfBlades","LOCALS")
THEN
  RESPONSE #100
    SetGlobalTimer("Spell","LOCALS",ONE_ROUND)
    SetGlobalTimer("GlobeOfBlades","LOCALS",FIVE_ROUNDS)
    ForceSpellRES("melis02",Myself)  // ~Blade Barrier~
  RESPONSE #100
    Continue()
END

Change ~!CheckStatGT(Myself,0,SCRIPTINGSTATE2)~ to ~!CheckStatGT(Myself,0,CLERIC_BLADE_BARRIER)~.

Why not use (~%SOURCE_EXT%~ STRING_EQUAL_CASE ~itm~) instead?

Copypaste of old code, there probably was not SOURCE_*** variables back then.

Attached Files

•  ds_v3.zip   8.32K   335 downloads

Edited by GeN1e, 04 April 2011 - 09:17 PM.

[Miloch]

Ok, will check it out.

Leave both alone. Or convert Ascension's to 'table.2da', if you've got some time to kill

How and why would one do this? Remember, I'm still not terribly familiar with this code and probably won't be - too busy on updating other things for the mod, so I'm just looking for a working DS standard (no doubt it will come up in the BP update too though).

[Miloch]

I better check for those mods actually being installed, rather than patch blindly. Will do today evening.

Heh. Maybe you did but it's not in the version above, which copies a marker file without checking if the mod files are actually present. But for that matter, you have the entire body of the old_scripts macro commented out. For Kelsey and Kiara-Zaiya, it should be easy enough to add a FILE_EXISTS_IN_GAME ~j#ceara.bcs~ or whatever in addition to the marker check. In fact it could probably just do something like a FILE_CONTAINS to see if the change has already been done. Otherwise we'll have to think of some way to check for the new Ascension vs. the old one. (Edit: probably INDEX_BUFFER would suffice - see here for an example.)

Not sure if we need "Eradicate older Ascension's version of DS" either, but I guess it doesn't hurt?

Change ~!CheckStatGT(Myself,0,SCRIPTINGSTATE2)~ to ~!CheckStatGT(Myself,0,CLERIC_BLADE_BARRIER)~

Ok, but I have to change it to !CheckStatGT(Myself,0,121) or it raises a parse error during compile. Either that or compile the scripts after DS goes in, but then that raises a whole bunch of other errors (things like SCRIPTINGSTATE7 not being present). I could change all scripts to compile with numeric values for everything, but that's confusing as some values get swapped.

Other than that, it installs without error. For the main component of Ascension anyway - I haven't gotten to the subcomponents yet... I suspect they'll be parse errors like the above but I guess I can fix those as they occur. I didn't check if all the changes to spells etc. are valid, but at least it seems to patch them this time.

Ascension uses stats 173, 186 and maybe others, for what I don't know. Would be nice to have a better description than "DMWW_SLOT_173" etc. For that matter, is there a description of what SCRIPTINGSTATEs 1-6 are used for anywhere?

Looks like detectable_weapon_enchantment is a blank function - were you going to do something with that?

Edited by Miloch, 18 April 2011 - 05:47 AM.

[GeN1e]

Not sure if we need "Eradicate older Ascension's version of DS" either, but I guess it doesn't hurt?

That in fact is very necessary, at least until there're no longer mods around that use older version.

Change ~!CheckStatGT(Myself,0,SCRIPTINGSTATE2)~ to ~!CheckStatGT(Myself,0,CLERIC_BLADE_BARRIER)~

Ok, but I have to change it to !CheckStatGT(Myself,0,121) or it raises a parse error during compile. Either that or compile the scripts after DS goes in, but then that raises a whole bunch of other errors (things like SCRIPTINGSTATE7 not being present). I could change all scripts to compile with numeric values for everything, but that's confusing as some values get swapped.

Well, you sure can go either way if you know what you're doing... But in general DS is installed first, then AI gets compliled - that way you can keep descriptive stat entries rather than mere numbers. Also, albeit not a matter of significant importance, this ensures that should ever the DS map be changed in a future, BAFs themselves will not have to be re-written.

I'm not sure where SCRIPTINGSTATE7 comes from... It should be WIZARD_SPELL_IMMUNITY or WIZARD_SPELL_TURNING. How did you obtain BAFs? Decompiled with Ascension installed, decompiled with no DS installed, something else?

Ascension uses stats 173, 186 and maybe others, for what I don't know. Would be nice to have a better description than "DMWW_SLOT_173" etc. For that matter, is there a description of what SCRIPTINGSTATEs 1-6 are used for anywhere?

DMWW is more like a unique regexp for replacement, rather than anything else. What stands for what is stated in "oldds_swap.2da".

Now, scripting states can not be renamed - because these identifiers are from vanilla, and nobody wants to break an occasional mod without big need. What they mean, however, I can teel.

Vanilla:
SCRIPTINGSTATE1 - no idea what it does in vanilla (SPIN854.SPL), but Ascension, being the first, makes an exclusive use of it for timestop immunity, as well as something else
SCRIPTINGSTATE2 - immunity to death (vanilla SPPR409.SPL)
SCRIPTINGSTATE3 - immunity to level drain (quite widespread in vanilla, SPLs and ITMs)

DS:
SCRIPTINGSTATE4 - combat stance, various abilities from the innate bar and some spells too
SCRIPTINGSTATE5 - AC boosting spells (Armor, Barkskin, etc.)
SCRIPTINGSTATE6 - combat boosting spells (Tenser, etc.)

[Galactygon]

[slightly off-topic]
Could I make a slight easy-to-implement request? I'd like DS to add the new effects not at the very beginning of the effect list, but right after the effect it would clone. Some of my stuff patch spells to exclude certain creature types by placing effects (opc 101, 206) at the beginning of the effect list.
[/slightly off-topic]

-Galactygon

[GeN1e]

Right now it appends to the end of effect list (due to similar consideration). Is it sufficient, or you want DS added exactly next to the cloned effect?

[Galactygon]

There will be serious issues where the last effect is a 206 with SOURCERES as its resource - I'd like the effect to be added right after the cloned one.

-Galactygon

[Miloch]

I'm not sure where SCRIPTINGSTATE7 comes from... It should be WIZARD_SPELL_IMMUNITY or WIZARD_SPELL_TURNING. How did you obtain BAFs? Decompiled with Ascension installed, decompiled with no DS installed, something else?

Decompiled the original mod's BCSes without the mod (or any mod) installed I believe. Wanted to make sure they were decompiling and compiling cleanly. Just copying BCSes over wasn't checking for errors, several of which you have already noted. So hence why they decompiled to SCRIPTINGSTATE7 since that's a vanilla stats value. Would it make more sense to decompile with the revised DS installed?

I suppose it would be stupid to rename the SCRIPTINGSTATE texts, as a lot of mods would probably fail to compile. Though maybe the list is rather small. At least we could put the descriptions in some sort of DS readme.

Re: clone spell effects, it might be best to do this via a standard function, but ADD_SPELL_EFFECT function only has a parameter to add it at the beginning or end. I think I did a macro that inserts it after the cloned effect (t-spl_eff_copy.tpp in PnP Free Action but it has been a while since I looked at it. I am going to need this sort of code to update a lot of older mods so it makes sense to make it a WeiDU standard function.

[Galactygon]

Re: clone spell effects, it might be best to do this via a standard function, but ADD_SPELL_EFFECT function only has a parameter to add it at the beginning or end. I think I did a macro that inserts it after the cloned effect (t-spl_eff_copy.tpp in PnP Free Action but it has been a while since I looked at it. I am going to need this sort of code to update a lot of older mods so it makes sense to make it a WeiDU standard function.

I wrote a bunch of macros a few years ago that allows dynamic searching/adding/deleting/changing of effects in extended headers. They work very nicely with SpellPack, but I feel they are exceedingly slow and need to be updated; my coding skills are less than optimal, and some of the code in there is just messy even though everything works. If someone recodes them, they can serve as a standard for the community.

Here is what I mean (taken from a tweak pack I'm working on) :

ACTION_DEFINE_ASSOCIATIVE_ARRAY ~single_IWD_graphics_conversion~ BEGIN
        ...
        ~SOURCE=DEMOCHM.spl;RESOURCE=SPNWCHRM~ => ~CHANGEOPCODE;OPCODE=141;RESOURCE=BLANK;PARAMETER1=GENERIC;PARAMETER2=0~
        ~SOURCE=SPCL311.spl;RESOURCE=SPNWCHRM~ => ~CHANGEOPCODE;OPCODE=141;RESOURCE=BLANK;PARAMETER1=0;PARAMETER2=GENERIC~
        ~SOURCE=SPCL311.spl;OPCODE=141~ => ~ADDOPCODE;OPCODE=50;TIMING=1;DURATION=0;RESOURCE=NONE;PARAMETER1=GENERIC;PARAMETER2=983040~
        ~SOURCE=SPCL721.spl;RESOURCE=ICRMPARI~ => ~CHANGEOPCODE;OPCODE=141;RESOURCE=BLANK;PARAMETER1=0;PARAMETER2=GENERIC~
        ~SOURCE=SPCL731.spl;RESOURCE=SPFLMBLD~ => ~DELETEOPCODE~
        ~SOURCE=SPIN608.spl;RESOURCE=SPPROTEC~ => ~CHANGEOPCODE;OPCODE=141;RESOURCE=BLANK;PARAMETER1=0;PARAMETER2=GENERIC~
        ...
END
OUTER_SPRINT action_lceffect "single_IWD_graphics_conversion"
LAUNCH_ACTION_MACRO ~ACTION_LCEFFECT~ // reads associative array defined by action_lceffect

-Galactygon

[Miloch]

Not sure if there's been any progress on this, but any idea if there's a way to detect a movement speed stat? I tried 78 PHYSICALSPEED but this seemed to be either zero or not set at all when I tried it in a test script on the PC.

[GeN1e]

I thought PHYSICALSPEED was for weapon speed factor?

[Miloch]

Well, I had a staff equipped at the time, so it should have been reporting 4 for that, no? But it was on zero. Unless it only registers when it's swinging but that seems a bit silly. But anyway, I guess there's nothing for movement speed outside of looking for haste/slow, which doesn't really tell you how fast something's moving. Maybe something for TobEx?

[aVENGER]

I thought PHYSICALSPEED was for weapon speed factor?

If I recall correctly, PHYSICALSPEED is actually Speed Factor Bonus i.e. the param1 value of opcode #190.

[Miloch]

If I recall correctly, PHYSICALSPEED is actually Speed Factor Bonus i.e. the param1 value of opcode #190.

I think I tested this (a month ago now) and can probably confirm that.

64 MINORGLOBE would obviously detect Minor Globe (spwi406) as well as "Major" Globe (spwi602) and maybe some other spell immunities that set that stat (opcode 155 I'm guessing). Any idea what (if anything) sets 64 SHIELDGLOBE? I would like to guess Spell Shield, but that isn't evident (we can detect that with a host of similar effects with HasImmunityEffects() though at least).

[aVENGER]

Any idea what (if anything) sets 64 SHIELDGLOBE?

IIRC, anything that uses opcode #156 (Protection from Normal Missiles Cylinder) sets SHIELDGLOBE to 1 (hardcoded).

Edited by aVENGER, 01 September 2011 - 09:09 PM.

[i30817]

Would it be possible to implement as part of the standard cloud detection?

I know they are offensive spells, and thus, not normally part of the "detectable spells". However since they are not instant offensive spells, they can be counteracted by moving away, not attacking if destination in radius, etc and all of that is useful for all AI mods.

Basically, clouds detectable, "Range"-able and also their type since that would allow a meele char protected with free action to wad in a web, protected from acid into death fog etc. Moreover some have friendly fire effect, some not, etc.
Zone of sweet air would need to cancel the creatures (if using the creature trick to find the range).

They would also need to use a invisible creature to use range. Well at least you only need to care about the nearest so [] constructs work well enough to find range.

Edited by i30817, 10 December 2011 - 10:09 AM.

[GeN1e]

Uploaded into Modding Tools - http://www.shsforums...ectable-spells/

Should now be fully compatible with ToBEx and spell-altering mods.