kjeron

According to that tp2, you're not setting strings on any of the items.

It works - to reduce the number of spells available below the first 50. Raising the number above 50 does nothing however.

It will work for familiars if you patch the CRE directly with an op232 effect, just not when using the op177 filter. Or you can still use the op177 filter, but set it's Special Field to '102', rather than op232's (still set it to HP% < though).

The op177 filter is only necessary when applying through spells, directly patching a CRE file can bypass it, since it can also use V2 effects. It shouldn't make a difference, yet again it's something wrong with Familiars: for reasons I cannot fathom, they ignore the 'Special' field of the contingency opcode when applied through op177, so none of these work properly: HP<, HP%<, SPLSTATE=, STATE=, Target in 'Special' Range, Time of Day. Works fine for other creatures, but familiars just have to be special.

There is no charge maximum (aside from the field size - 65535). The charge value on an item ability indicates how many it will have after being recharged, but it can be spawned with any amount of charges. Items are not designed to have both charges and stack sizes. The first ability charges and stack size share the same field in CRE/ARE files, with stack size taking priority. Each item ability independently defines what happens when it's charges are depleted (remain, vanish, replace) - it doesn't matter what other abilities it has or how many charges they have remaining.

https://www.gibberlings3.net/forums/topic/28611-itemtype2da/?do=findComment&comment=252100 It hasn't changed (well, less crashes). Only item types 0, 8, 9, 11, 13, and 35 have a hardcoded default access to all 3 slots.

The ADD_CRE_ITEM patch doesn't support any flag combination that contains both "stolen" and "unstealable", making it necessary to run ADD_CRE_ITEM, then ADD_CRE_ITEM_FLAGS, an extra step which isn't necessary for other flag combinations. I'd say an oversight on weidu's part.

Timer's don't change value once set. When you call SetGlobalTimer(), it's sets that variable to the current (gametime + given value, in ticks). The timer is 'expired' if gametime has passed that new value, or 'running' if it has not.

No, it's BIT17. The first 2 bytes (BITS0-15) determine the type of heal value (Increment, Set, Set %).

0-Power effects CAN be dispelled, provided they are flagged dispellable, like any other effect. Opcode 17, BIT17 of Parameter2 will remove all effects with a limited timing mode (not equipped(2) or permanent(9)), but also any item in the Magical Weapon slot. Opcode 321 with an empty resource field will remove level-up Proficiency effects. I don't think Local Variable effects can effectively be removed, since the game reapplies them when you save.

Yes, just like effect duration's, it converts gametime to ticks when storing the value, so a 15x multiplier.

You can use "IncrementGlobal()" with positive value to extend a timer, or a negative value to shorten the timer, so long as the script that checks for the (expired) timer hasn't already fired (usually, really depends on how the script is setup and what safeguards it has). Death variables are just another global variable, can easily be set to 0 (unset) with SetGlobal().

The only difference between SetGlobal and SetGlobalTimer is that "GameTime" is added to the value of the latter, but they both set variables in the specified scope.

The "View" tab lists effects/abilities/etc... in Alphabetical order, the "Edit" tab lists them in their actual order.

SET is also necessary for Array constructs, probably for the same reasons as EVALUATE_BUFFER SET $name(~key~) = 1