58 replies to this topic

[Ascension64]

A STATS.ids fix to handle more stats.

Here is the description of a working implementation of expanded stats. What exactly do you want to do with new stats? At the moment, new stats are generic without any hard-code.


-----Expanded Stats [M]
Allows modders to extend STATS.IDS to use opcodes 202-SHRT_MAX (32767)
Features of new stats:
-New stats can be set using effect opcode 318 (0x13E) with description below
-New stats can be checked correctly using CheckStat(), CheckStatLT(), and CheckStatGT() script triggers
-New stats are not permanent, they require an ongoing effect opcode 318 in order to keep their values
-In order to make a new stat semi-permanent, you can set an extremely long duration for the effect, or use timing mode 10 and set duration to INT_MAX (2147483647)
-New stats will only be saved in saved games if stored as an effect opcode 318
-Actions cannot directly set the value of new stats (they will not keep); use an action to trigger effect opcode 318 if actions are required
-New stats have no effect on the game unless you specifically script in; for example, use scripts to CheckStat() and apply appropriate actions

Description
#318 (0x13E) Stat: Set stat [318]
Parameter #1: Statistic Modifier
Parameter #2 low: Stat Opcode
Parameter #2 high: Type

Description:
Applies the modifier value specified by the 'Statistic Modifier' field in the style specified by the 'Type' field to the opcode specified by the 'Stat Opcode' field.
Known values for 'Type' are:
0 Cumulative Modifier -> Value = Value + 'Statistic Modifier' value
1 Flat Value Modifier -> Value = 'Statistic Modifier' value
2 Percentage Modifier -> Value = (Value * 'Statistic Modifier' value) / 100
3 Multiplicative Modifier -> Value = Value * 'Statistic Modifier' value
4 Divisive Modifier -> Value = Value / 'Statistic Modifier' value
5 Modulus Modifier -> Value = Value % 'Statistic Modifier' value
6 Logical AND Modifier -> Value = Value && 'Statistic Modifier' value
7 Logical OR Modifier -> Value = Value || 'Statistic Modifier' value
8 Bitwise AND Modifier -> Value = Value & 'Statistic Modifier' value
9 Bitwise OR Modifier -> Value = Value | 'Statistic Modifier' value
10 Inverse Modifier -> Value = !Value

Note: You cannot set any stats with opcode < 301 with this effect. New stats 202-300 are reserved for new hard-coded stats.

Options:
-0: disabled
-1: enabled

Edited by Ascension64, 15 January 2011 - 02:21 PM.

[Galactygon]

Here is the description of a working implementation of expanded stats.

So far it sounds really nice. This one is going to bug us, though:

-New stats are not saved in saved games

Isn't it possible to reapply the stats when loading a game from the .cre effect list?

What exactly do you want to do with new stats? At the moment, new stats are generic without any hard-code.

The only effects that deserve them are those in which their amount, or expiry aren't easy to control, or are hard to detect in scripts, namely the various decrement opcodes or damage suffered. Since they use multiple parameters for level and amount, there needs to be multiple stats.

Here's a list off the top of my head:
FIGHTERLEVEL, MAGELEVEL, CLERICLEVEL, etc. for each class (useful for multi/dual classes)
AMOUNTOFDAMAGESUFFERED (maxhp - currenthp) (doesn't go over 255) IIRC DamageTaken() only works for Myself
MOVEMENTRATE (default is 9, set by opcodes 126, 176, haste, and slow opcodes)
Opcode 18: MAXHPMOD
Opcodes 129,130,131,132,137 -> These have states, but stats would suit them more, with whatever amount is set by those opcodes
Opcode 145: SPELLDISABLEMAGE, SPELLDISABLEPRIEST, SPELLDISABLEINNATE (set to 0 or 1)
Opcodes 119, 159: MIRRORIMAGENUMBER (how many images there are left)
opcode 200 (we need stats for each power level, up to like, 10) : BOUNCEPOWERLEVEL0, BOUNCEPOWERLEVEL1,...,BOUNCEPOWERLEVEL10 (set to whatever number of spell levels are left)
Opcode 201: same as 200 except DEFLECTPOWERLEVELx
Opcode 216: there is already a LEVELDRAIN stat for this. Does it work, or is there an engine bug?
Opcode 223,226,227,228 -> I'm completely lost on these. I think these opcodes should be changed for more customization instead.
Opcode 231: TIMESTOP -> sets how many seconds there are left until it ends (useful for timing actions without setting various timers)
Opcode 235: WINGBUFFET -> whatever type it is (0-3)
Opcode 259 same as 200 except SPELLTRAPPOWERLEVELx

-Galactygon

[Ascension64]

Isn't it possible to reapply the stats when loading a game from the .cre effect list?

Oh, of course. If effect opcode 318 is stored on a creature during save, then the new stat values are kept. I'll fix the text up above.

The only effects that deserve them are those in which their amount, or expiry aren't easy to control, or are hard to detect in scripts, namely the various decrement opcodes or damage suffered. Since they use multiple parameters for level and amount, there needs to be multiple stats.

Here's a list off the top of my head:
FIGHTERLEVEL, MAGELEVEL, CLERICLEVEL, etc. for each class (useful for multi/dual classes)
AMOUNTOFDAMAGESUFFERED (maxhp - currenthp) (doesn't go over 255) IIRC DamageTaken() only works for Myself
MOVEMENTRATE (default is 9, set by opcodes 126, 176, haste, and slow opcodes)
Opcode 18: MAXHPMOD
Opcodes 129,130,131,132,137 -> These have states, but stats would suit them more, with whatever amount is set by those opcodes
Opcode 145: SPELLDISABLEMAGE, SPELLDISABLEPRIEST, SPELLDISABLEINNATE (set to 0 or 1)
Opcodes 119, 159: MIRRORIMAGENUMBER (how many images there are left)
opcode 200 (we need stats for each power level, up to like, 10) : BOUNCEPOWERLEVEL0, BOUNCEPOWERLEVEL1,...,BOUNCEPOWERLEVEL10 (set to whatever number of spell levels are left)
Opcode 201: same as 200 except DEFLECTPOWERLEVELx
Opcode 216: there is already a LEVELDRAIN stat for this. Does it work, or is there an engine bug?
Opcode 223,226,227,228 -> I'm completely lost on these. I think these opcodes should be changed for more customization instead.
Opcode 231: TIMESTOP -> sets how many seconds there are left until it ends (useful for timing actions without setting various timers)
Opcode 235: WINGBUFFET -> whatever type it is (0-3)
Opcode 259 same as 200 except SPELLTRAPPOWERLEVELx

I can have a look at these later. Let's say we reserve new stat opcodes 202-300 for hard-code use if required.

[GeN1e]

Let's say we reserve new stat opcodes 202-300 for hard-code use if required.

Things past 300 are free for DS then? Woo-hoo!!!

[Ascension64]

I guess we can either set up a reservations area for certain stat opcodes, or you can make WeiDU do absolutely everything dynamically based on the next available opcode slot. The latter is a lot more trickier (you would have to variabl-ise all your CheckStat[GT/LT]() triggers as well as the effect Param2 low, and wouldn't be compatible with saved games if people re-install. The former is a lot easier, and seeing that we have more than 30000 new stats, we shouldn't really run out.

[the bigg]

Shouldn't be too hard to have an ADD_STATS command to dynamically add new entries to stats.ids (like ADD_MUSIC does to music.ids, etc). CheckStat() will work correctly since the IDS will have the reference to your stat, and adding a WRITE_LONG to your spells isn't hard. Of course, you lose save game compatibility.

[fearless]

-New stats are not permanent, they require an ongoing effect opcode 318 in order to keep their values
-In order to make a new stat semi-permanent, you can set an extremely long duration for the effect, or use timing mode 10 and set duration to INT_MAX (2147483647)
-New stats will only be saved in saved games if stored as an effect opcode 318

Just throwing an idea out here, but couldn't you save the new stats to another file, that can be loaded with ToBEx? say a creature extension file, lets call it .crex. So that player character 'bob' will have a bob.crex file that is loaded at start? not sure if you can hook an event to detect game has just loaded. Or perhaps you have a script run that checks for bob in the party, loads bob.crex, then set the long duration.

[Ascension64]

Yes, it is possible, and does require some work. Nevertheless, the majority of existing stats aren't stored directly in the CRE file anyway, so I don't see exactly how these new stats are actually disadvantaged.

[Ascension64]

Update.

202 FIGHTERLEVEL - true fighter level (does not include monk)
203 MAGELEVEL - true mage level (does not include sorcerer)
204 CLERICLEVEL - true cleric level
205 THIEFLEVEL - true thief level
206 DRUIDLEVEL - true druid level
207 RANGERLEVEL - true ranger level

The question with 202 and 203 are whether they should include monk and sorcerer, respectively? I think they are best not, because
a) if you plan on using these only to check for level in multi-class and dual-class characters, then there is no point in including monk and sorcerer
b) for AI scripts in tactics mods, you would have to use two blocks to check that the 'fighter/monk' level is > 7.

IF
  CheckStatGT(NearestEnemyOf(Myself), FIGHTERLEVEL, 7) //good for FIGHTER, FIGHTER_*, FIGHTER_*_*, BARBARIAN
THEN
  RESPONSE #100
    TomatoSauce()
END

IF
  Class(NearestEnemyOf(Myself), MONK) //good for MONK
  LevelGT(NearestEnemyOf(Myself), 7)
THEN
  RESPONSE #100
    TomatoSauce()
END

...further blocks if you want to check RANGER, PALADIN, use RANGERLEVEL for CLERIC_RANGER...

The other question is whether it would be worth implementing an EFFECTIVECLERICLEVEL, which essentially determines the 'casting level' of the respective class (a cleric level 1 is equivalent to ranger level 8 and paladin level 9 in cleric spell progression).

An EFFECTIVEMAGELEVEL is equivalent to checking MAGELEVEL, BARD level, and SORCERER level in three script blocks.

[Galactygon]

The question with 202 and 203 are whether they should include monk and sorcerer, respectively? I think they are best not, because
a) if you plan on using these only to check for level in multi-class and dual-class characters, then there is no point in including monk and sorcerer
b) for AI scripts in tactics mods, you would have to use two blocks to check that the 'fighter/monk' level is > 7.

I agree with you, it's best to leave them seperate. Who knows what modder xyz will say.

The other question is whether it would be worth implementing an EFFECTIVECLERICLEVEL, which essentially determines the 'casting level' of the respective class (a cleric level 1 is equivalent to ranger level 8 and paladin level 9 in cleric spell progression).

An EFFECTIVEMAGELEVEL is equivalent to checking MAGELEVEL, BARD level, and SORCERER level in three script blocks.

I'd give it a try.

Another interesting stat might be: SPELLCASTING, which is set to however many seconds the .cre has left before attempting to launch a spell, and continuously counts down. Useful for the AI, if it wants to quickly interrupt characters with a counter-spell.

-Galactygon

[Ascension64]

Please remember that new stats must either be derived from stuff stored in a CRE file, or kept in place by an effect that does not purge immediately. Anything else should deserve a separate trigger opcode.

For example, something like AMOUNTOFDAMAGESUFFERED won't be too useful as a stat because the damage effect always purges immediately on application. One can try and set such a stat immediately on initialisation of CDerivedStats, but then updates won't be maintained until the next refresh of the creature. Therefore, it is better as a separate trigger.

Anyway, the existing DamageTaken() trigger is kind of dumb because:
1. It is not saved, so whenever you load a game, it is reset to 0.
2. Once damage is taken, the damage amount sticks until the next time damage is taken, so it will always be possible after the first hit with positive damage.

Other stats like WINGBUFFET could be useful, because it does not immediately purge, meaning that for the duration of a wing buffer, the stat can be set. Any other time, the stat will be zero.

For SPELLCASTING, this is weird because spell casting isn't an effect opcode. I am reluctant to use this as a stat because we can get undefined behaviours. It is probably better of as a separate trigger as well.

Just a heads up really, I'm looking into each potential stat as I go.

Edited by Ascension64, 28 January 2011 - 02:47 AM.

[Galactygon]

Please remember that new stats must either be derived from stuff stored in a CRE file, or kept in place by an effect that does not purge immediately. Anything else should deserve a separate trigger opcode.

For example, something like AMOUNTOFDAMAGESUFFERED won't be too useful as a stat because the damage effect always purges immediately on application. One can try and set such a stat immediately on initialisation of CDerivedStats, but then updates won't be maintained until the next refresh of the creature. Therefore, it is better as a separate trigger.

Isn't this possible by comparing the .cre's current hitpoints and max hit points each time damage is suffered/.cre is healed? This effectively makes DamageTaken() obsolete.

For SPELLCASTING, this is weird because spell casting isn't an effect opcode. I am reluctant to use this as a stat because we can get undefined behaviours. It is probably better of as a separate trigger as well.

The engine could calculate the casting time of the spell/ability that's being cast, convert it to seconds, and then have a staggered set stat effect applied that effectively counts down to whenever the spell is meant to set off. If concentration is broken, or the spellcast action is overridden, the staggered effects are cleared, and the stat is set to 0.

Parts of this can be implemented by patching CFBs of spells, but there are problems:
a.) it's difficult to detect when concentration is broken (opcode 232 is the best solution)
b.) it's impossible to detect when the spellcast action is overridden
c.) it's impossible to account for the various casting speed modifiers (slow, Robe of Vecna, etc). Come to think of it, not even the engine manages to take these into account when calculating how long the casting graphics/sounds play, which looks really fugly in many places.

Just a heads up really, I'm looking into each potential stat as I go.

Thanks for all your work.

-Galactygon

[Yovaneth]

If you're extending stats.ids, is there any chance of fixing the Reputation check? It's foobar'd good and proper and has just caused me no end of grief. This works:-

	IF~CheckStatGT(Myself,14,CHR)~THEN REPLY @3275 GOTO 124
	IF~CheckStatGT(Myself,14,CHR)~THEN REPLY @3275 GOTO 123

and this causes a No valid links:-

	IF~CheckStatGT(Myself,14,CHR)
 CheckStatGT(Myself,7,REPUTATION)~THEN REPLY @3275 GOTO 124
	IF~CheckStatGT(Myself,14,CHR)
 CheckStatLT(Myself,8,REPUTATION)~THEN REPLY @3275 GOTO 123

-Y-

[the bigg]

Any reason why you can't use ReputationGT(Player1,7)?

[Miloch]

So is this aiming at being able to replace the various ways in which Detectable Spells/Stats is currently implemented?

[Ascension64]

So is this aiming at being able to replace the various ways in which Detectable Spells/Stats is currently implemented?

I don't know - I'm not aware of how Detectable Spells/Stats actually works.

[Ascension64]

If you're extending stats.ids, is there any chance of fixing the Reputation check? It's foobar'd good and proper and has just caused me no end of grief. This works:-

	IF~CheckStatGT(Myself,14,CHR)~THEN REPLY @3275 GOTO 124
	IF~CheckStatGT(Myself,14,CHR)~THEN REPLY @3275 GOTO 123

and this causes a No valid links:-

	IF~CheckStatGT(Myself,14,CHR)
 CheckStatGT(Myself,7,REPUTATION)~THEN REPLY @3275 GOTO 124
	IF~CheckStatGT(Myself,14,CHR)
 CheckStatLT(Myself,8,REPUTATION)~THEN REPLY @3275 GOTO 123

-Y-

Use a combination of InParty() checks and ReputationGT(). I think (needs confirmation) that characters in party use the global reputation check, while those not in party will use a local. I haven't had a look whether the stat itself gets updated on reputation changes, but I don't think they do.

[Yovaneth]

Any reason why you can't use ReputationGT(Player1,7)?

Because I hadn't thought about it?

-Y-

[GeN1e]

So is this aiming at being able to replace the various ways in which Detectable Spells/Stats is currently implemented?

For compatibility's sake, as well as less headache for new users, old DS obviously shouldn't go anywhere. But expanded IDS does allow for fine tuning DS, and I for one am going to take advantage of it.

[Ascension64]

Isn't this possible by comparing the .cre's current hitpoints and max hit points each time damage is suffered/.cre is healed? This effectively makes DamageTaken() obsolete.

It will not be consistent. CDerivedStats is reconstructed from scratch every time an instant/limited (e.g. STR increment) is applied and every time an effect expires. CDerivedStats reconstructs only from .CRE data, and effects that are permanent/still waiting to expire. Therefore, in order to keep a stat, you must either make a permanent change to .CRE data, or pop it in an effect.

I can calculate the amount of damage taken and pop it in a stat during construction of CDerivedStats, but that is not reliable, because you would have to wait for an effect to expire before the change is applied. I could certainly do it in both ApplyEffect and on construction, but then I would have to look up every effect that modifies HP and modify accordginly - not efficient. It is far more efficient to implement a completely new trigger. This might suck for compatibility reasons (forces people to use TobEx) but I think it is the most optimal way to implement such a trigger.

The engine could calculate the casting time of the spell/ability that's being cast, convert it to seconds, and then have a staggered set stat effect applied that effectively counts down to whenever the spell is meant to set off. If concentration is broken, or the spellcast action is overridden, the staggered effects are cleared, and the stat is set to 0.

A casting timer already exists in the CCreatureObject object that counts upwards until it reaches a calculation of casting time and mental speed. Again, the best way to sort this out would be a completely new trigger due to the above limitations.