Rewriting effects

The drivers

• refactoring (​http://c2.com/xp/RefactorMercilessly.html, #1041, #1124, #1403)

• improve message handling (#1376, #1502)

• bugfixing (#623, #726, #859, #1573, #1578)

• increased flexibility and configurability (#57, #234, #418, #488, #578, #692, #992, #1276, #1279, #1408, #1437, #1459)

What we have now

Triggers leading to effects:

• item use (quaff, read, aim, zap, use, eat, activate)
• casting spell (includes all ranged monster attacks)
• on-hit effects (monster confusion and monster blow effects)
• on-move effects (triggering trap)
• on-expiry effects (SHROOM_SPRINTING)

Potential targets of effects:

• player
• monster(s)
• object(s)
• grid(s)

Parameters potentially affecting effects:

• originator level
• target level
• dungeon level
• object level
• spell level
• feature level (trap / door / lock)
• relevant skill (devices, mainly)

Variables potentially affected:

• amount (e.g. of damage, or healing)
• range
• duration
• saving throw
• random outcomes (polymorph, wonder etc.)

At the moment only certain parameters affect certain variables for certain effects.

At the moment certain amount variables are conflated with durations (cut, stun, poison).

Most area affects are handled by the project() code, but separate functions exist for:

• earthquake and destruction
• detections
• mapping, lighting and disarming
• aggravation, probing, banishment and mass banishment

Obviousness / learning is handled by various mechanisms.

There are no effects which are conditional on the outcome of a previous effect, I think.

The vision

Most list-*.h files turned into !lib/edit files:

list-effects.h and list-blow-effects.h and list-spell-effects.h combine into effects.txt

list-gf-types.h becomes projections.txt

list-mon-spells.h becomes mon_spell.txt (and eventually list-blow-methods.h into mon_blow.txt)

It is not necessary to make a fully generic system. Something which replicates the current effects using editable text files would be a fine start.

Progress

Thinking

Effects should be atomic, with monster attacks, player spells or item activations specifying as many as they need.

As much as possible should be adjusted before the effect is called, e.g. range and damage. These are properties of the item, spell or trap, not of the effect.

All area effects could be done with project(). It's quite possible that all non-area effects could also be delivered via project(), if this is helpful. But this will mean passing variables into project (amount, duration, saving throw) because different targets may need those amounts adjusted differently.

Current mental block is which adjustments which need to be passed into the effect(s) and how to manage them.

Files

effects.txt - started

mon_spell.txt - format and syntax done, just needs populating and parsing. At the moment the distinction between projected and non-projected spells is retained, but I think it may not be necessary, since project() can deal perfectly well with delivering an effect directly to a single target.

projections.txt - half done (the breath elements), just needs the map effects sorting