progfx.2da

Visual Effects using "programmed effects" can now be changed (outside of engine edits) using progfx.2da. This was added in patch 1.80.8193.14.

Note there is no "custom programming" this is a file of parameters for what the engine will understand when using a particular "type" of programmable FX (1 through 13).

You use the visualeffects.2da columns ProgFX_Impact, ProgFX_Duration and ProgFX_Cessation to reference lines in this 2da:

• ProgFX_Impact - Run once when the VFX is applied
• ProgFX_Duration - Run continuously while VFX is active
• ProgFX_Cessation - Run once when VFX is removed

Previously, all the values for these columns were hardcoded. With 8193.14, a new 2DA, progfx.2da is added which contains the definitions for these values.

The progfx effects are grouped by Type. Each progfx Type has different handling within the engine, and the meaning of the parameters depends on the type. Note the Type ID by default is tied to a row number (eg; Type 3 starts at 300) but that no longer has to be the case.

Some Beamdog documentation available here: https://gist.github.com/mtijanic/97f309b8d9262f0cf4f7dfba6618ea6a mostly translated here.

progfx.2da Exceptions

progfx.2da only applies to visualeffects.2da. The problem with this is that vfx_persistent.2da cannot make use of it (this also defines models to use for visuals). There is one line that has a programmed effect - line 7 - blade barrier - applies environmental mapping as per id 2 below. No other lines can have this added, or any other progfx.2da changes.

2DA Contents

Types Documentation

1: Skin Overlay (barkskin, stoneskin, etc)

This will set the texture of the creature to the given model texture, along with some altering of impact effects.

Example progfx.2da lines:

2: Used for environment mapping

Sets an environment map file to be used by the VFX. The default lines do not actually seem to be used by the default game visual effects, and there doesn't actually appear to be any vdu_envmap_XXX files in the game files. Presumably the default lines are there just in case/show what the game would do by default.

Example progfx.2da lines:

3: Static Glow effects.

Sets a static glow effect to the model affected.

Commonly used for VFX_DUR_AURA_XXX visualeffect lines as ProgFX_Duration, although can be used in ProgFX_Impact as well.

Example progfx.2da lines:

4: Lighting addition or removal

Lighting models to provide lighting (or remove it - like if blinded!). There are likely a lot of hardcoded relations to these lines used by the game feats like Darkvision or certain effects like Ultra Vision.

The normal ones appear to be used for ProgFX_Duration

The Fade ones appear to be used for ProgFX_Cessation

Note there are references to the default visions like Dark Vision here, therefore if you alter the progfx.2da or visualeffects.2da line references these effects can apparently be altered when loaded by the engine. May be worth testing.

Example progfx.2da lines:

5: Alpha transparency modifiers.

These are used to apply VFX_DUR_INVISIBILITY, VFX_DUR_GHOSTLY_VISAGE, VFX_DUR_GLOW_ and a few others as ProgFX_Duration.

Since there is no model mentioned it's just a alpha and colour change.

Example progfx.2da lines:

6: Pulsing Aura glows - fades between 2 colors

Pulses two colours on the given model. This is used for VFX_DUR_BLUR and VFX_DUR_AURA_PULSE_XXX_YYY visualeffects.2da lines.

Example progfx.2da lines:

7: Beams

Within original content, beams are used solely for EffectBeam which adds nwscript parameters for the "source" and "target" (so you can do a penagram on the ground if you wanted).

What this actually does is more useful than it sounds. One type of emitter is a point-to-point emitter (P2P) which moves a visual effect along a track from source to target point. There are three types of P2P emitter available within NWN.

1) Bezier

2) Gravity

3) Lightning

Beams within original content use the lighting emitter type in which a series of lightning decal graphics is placed along a line from source to target. The number of decals placed is dependent upon the builder, but the number must be a binary number (2, 4, 8. 16, 32, 64, etc.). Each decal is overlapped slightly, and options within the lighting type allow you to kink the lightning by skewing each decal in the line. No kink produces a straight beam appearance.

The other two P2P effects toss out emitted decals or chunks at the source, and they migrate toward the target point. Normally, the target point is defined by an AuroraRef dummy within the MDL file (the position of the  dummy is often backward from where the emitted particles will go). However, with the Beam progFx, what you're doing is having the engine detach the beam target from that AuroraRef and place it on the location of the target object. This allows you to now use both Bezier and Gravity "beams" in P2P ways with the target object being the actual target. You're no longer confined to lightning type emitters.

Note: the AuroraRef node is NOT being moved to the target object. If you parent parts of the mesh to the AuroraRef dummy, they will remain where they were in the original MDL layout. What is actually happening is the target point is being removed from the dummy and placed on the target object.

The main thing here is the model is now unhardcoded - go mad adding your own (by editing the existing even).

Example progfx.2da lines:

8: Stops models rendering

This would obviously remove the model from view, there appears to be no parameters so there is likely no reason to create duplicates of this line, but reference ID 700 to use it.

Used on visualeffects.2da line 120 - VFX_COM_UNLOAD_MODEL with the entry being tied to ProgFX_Impact. It's unknown if the game uses this VFX line or the 700 progfx.2da line at all (VFX_COM_ are instantly applied "combat" effects...but what would make a model disappear?).

Presumably a good one to use if you want another VFX to apply such as "blowing up a target" where if the model was still there it'd look weird.

The lexicon suggests this does nothing however. Possibly it only works in certain circumstances? Also how would you remove the fact the model is now gone? (possibly some SetAppearance calls may work but better be sure if using this!).

Example progfx.2da lines:

9: Chunk Model

VFX_COM_GIB uses this for it's ProgFX_Impact. This is likely the engines hardcoded high violence chunking - when like EffectDeath is used with bSpecacularDeath or similar (see notes here).

Since there are no parameters presumably we cannot force a particular chunk to be used. Using VFX_COM_GIB in EffectVisualEffect may also be buggy and it might be just only usable by theg game.

Example progfx.2da lines:

10: MIRV (projectiles like Magic Missile)

Magic Missiles and Acid Arrows! The models can now be changed/new ones be added and the speed and projectile type can be changed. The MIRVs are randomised in direction if using certain projectile types.

This allows you to have fireballs throw from the ImpactScript for instance instead of being part of the spells.2da line definition or using wonky ActionCastSpellAtObject parameters (which miss a lot of projectile types).

Note: After testing even the slowest speeds here (log) tends to be much too fast - especially for "Spiral" (used for Hellball) where it messes up entirely. Needs more speeds to be effective for longer duration projectile types.

log nwscript code (magic missile, the slowest):

    float fDist = GetDistanceBetween(OBJECT_SELF, oTarget);
    float fDelay = fDist/(3.0 * log(fDist) + 2.0);
eg: fDist = 20.0f: 3.38 seconds

llnear nwscript code (will do a linear distance calculation. This is modified from acid arrow twice but is twice as fast):

    float fDist = GetDistanceToObject(oTarget);
    float fDelay = (fDist/50.0);

linear2 nwscript code (acid arrow, linear half speed):

    float fDist = GetDistanceToObject(oTarget);
    float fDelay = (fDist/25.0);

Note these are used in the ProgFX_Impact (eg; VFX_IMP_MIRV) it is an "instant" effect but with a visual that goes on. So you have to delay each hit by a certain amount to get the right "impact time" to, say, do damage.

const int PROJECTILE_ORIENTATION_TYPE_NONE    = 0;
const int PROJECTILE_ORIENTATION_TYPE_TARGET  = 1;
const int PROJECTILE_ORIENTATION_TYPE_PATH    = 2;

const int PROJECTILE_PATH_TYPE_DEFAULT                = 0;
const int PROJECTILE_PATH_TYPE_HOMING                 = 1;
const int PROJECTILE_PATH_TYPE_BALLISTIC              = 2;
const int PROJECTILE_PATH_TYPE_HIGH_BALLISTIC         = 3;
const int PROJECTILE_PATH_TYPE_BURST_UP               = 4;
const int PROJECTILE_PATH_TYPE_ACCELERATING           = 5;
const int PROJECTILE_PATH_TYPE_SPIRAL                 = 6;
const int PROJECTILE_PATH_TYPE_LINKED                 = 7;
const int PROJECTILE_PATH_TYPE_BOUNCE                 = 8;
const int PROJECTILE_PATH_TYPE_BURST                  = 9;
const int PROJECTILE_PATH_TYPE_LINKED_BURST_UP        = 10;
const int PROJECTILE_PATH_TYPE_TRIPLE_BALLISTIC_HIT   = 11;
const int PROJECTILE_PATH_TYPE_TRIPLE_BALLISTIC_MISS  = 12;
const int PROJECTILE_PATH_TYPE_DOUBLE_BALLISTIC       = 13;

Example progfx.2da lines:

11: Variant MIRV with sound and impact sound (Only used for moo cows / cheat)

Not sure how useful this is since it's used by the engine for the cheat command, and it doesn't have the same parameters as the MIRV options.

The most useful thing may be Param2 which is a one-off "source" sound (from when the projectile starts) so could be a crossbow going off or something for a bolt to appear.

I'm not sure what the distance / time calculations if using this is. Cows move in weird ways...!

const int PROJECTILE_PATH_TYPE_DEFAULT                = 0;
const int PROJECTILE_PATH_TYPE_HOMING                 = 1;
const int PROJECTILE_PATH_TYPE_BALLISTIC              = 2;
const int PROJECTILE_PATH_TYPE_HIGH_BALLISTIC         = 3;
const int PROJECTILE_PATH_TYPE_BURST_UP               = 4;
const int PROJECTILE_PATH_TYPE_ACCELERATING           = 5;
const int PROJECTILE_PATH_TYPE_SPIRAL                 = 6;
const int PROJECTILE_PATH_TYPE_LINKED                 = 7;
const int PROJECTILE_PATH_TYPE_BOUNCE                 = 8;
const int PROJECTILE_PATH_TYPE_BURST                  = 9;
const int PROJECTILE_PATH_TYPE_LINKED_BURST_UP        = 10;
const int PROJECTILE_PATH_TYPE_TRIPLE_BALLISTIC_HIT   = 11;
const int PROJECTILE_PATH_TYPE_TRIPLE_BALLISTIC_MISS  = 12;
const int PROJECTILE_PATH_TYPE_DOUBLE_BALLISTIC       = 13;

Example progfx.2da lines:

12: Spell Casting Failures - model node attached VFX

Not sure where we can even make use of these. They are used in the VFX lines VFX_FNF_SPELL_FAIL_HEAD and VFX_FNF_SPELL_FAIL_HAND.

However the engine probably just calls these VFX lines and loads the approprite bits (so leave the default alone).

Possibly it allows some stuff with custom lines where a vfx model is tied, say, to a creatures head or arm or something similar, although it may not orientate it properly.

Example progfx.2da lines:

13: Freeze Animations

This would obviously just freeze animations. There are no parameters so there is likely no reason to create duplicates of this line, but reference ID 1300 to use it. The VFX line used by default is VFX_DUR_FREEZE_ANIMATIONS.

Example progfx.2da lines: