My Take on .spl files Options

[Galactygon]

I. Introduction

I am intending this lecture/essay for those who are fairly comfortable going in and editing .spl files. Therefore, I am not going over the definition of an extended header or an effect. For now, I am making a single post. If I have the time/energy/motivation, I will make additional posts. I hope this first post is readable, I made amendments after amendments.

So why bother with .spl files, even if you are not interested in spell-related mods? I have worked for years with .spl files, and people have seen the stuff they could do - there is practically no limit.

At a first glance, .spl files seem relatively limited - there are extended headers and then there are effects slapped onto extended headers. These effects can do all sorts of stuff, and the extended headers tell you what effects are called. Opcodes determine what each of the effects do, and there are only so many of them.

In .spl files, there is no straightforward way to check for conditions like you do in .bcs blocks. A typical .bcs block goes like this:

IF
A is true
B is true
THEN
C happens
D happens

Wheras a typical extended header looks like this:

A happens.
B happens.

Once you start figuring how to manipulate .spl files to mimick certain "IF" blocks, it is easier and more reliable to mess around with .spl files than .baf files. You can use other .spl files to exclude A or B, but this isn't always trivial. I will explain how to do this in some later post.

You should notice that in scripts, the game engine is continuously checking what blocks are true before executing them, while in extended headers, a whole bunch of stuff is executed at once with only one check (level required to call the extended header). This difference has a major impact on game performance. In addition, .bcs blocks aren't always executed smoothly - the timing might be off by one AI framerate who knows. On the other hand, extended headers are executed completely mechanically - you can always rely on them. Through a string of .spl files, you can mimick opcodes from other game engines, or even construct your own! This is not even remotely possible in .bcs files.

For example, you can construct an opcode that grants bonuses to saving throws that is not cumulative with itself, and allows the player to renew them. For example, I can construct a spell that grants a bonus to saving throws, is not cumulative with itself or similar effects, and allows the player to renew the effects rather than wait for them to expire.

Another example might be to mimick critical hit rolls, and apply an effect on the creature hit when a critical hit is rolled. I could have Silver Sword kill a creature upon a critical hit rather than have an effect that always triggers with a percentile dice, and pray for the best.

All of these examples require some thought, and especially the latter is not strightforward to figure out. As mentioned earlier, I have strings of .spl files execute these tasks, it is not uncommon for me to employ 10+ subspells to execute a single task. In fact, I sometimes have more than 50 .spl files in what looks like a single spell or effect (see Shroud of Flame component of SpellPack). This can sometimes be overwhelming, but after a few spells you start to realize you can keep track of what each .spl does. Organizing them helps.

Groups of .spl files can appear very complex when flipping through .spl file after .spl file in NI or DLTCEP, but from an ingame point of view they are extremely simple to handle, and unlike scripts, you can barely notice all the hundreds of effects at work.

This does not mean that we should forsake .bcs files - there are things .bcs files can do what .spl files don't and vice versa. What those things are, I cannot list them, you have to know what you're doing in order to handle them. I end up working with both where .bcs files do one check (such as an INT check), where .spl files do the rest.

If you flip through my .spl files, you will notice there is a swath of opcodes that appear in practically every single subspell. They are my best friends, I know their numbers by heart.

The opcodes are:
#101 [Protection from Opcode]
#102 [Protection from Spell Levels]
#146 [Cast Spell at Creature]
#148 [Cast Spell at Point]
#148 [Cast Spell at Point]
#177 [Use EFF File]
#205 [Protection from Secondary Type]
#206 [Protection from Spell]
#221 [Remove Secondary Type]

And sometimes you will see:
#232 [Cast Spell on Condition]
#248 [Set Melee Effect]
#249 [Set Ranged Effect]

These opcodes are crucial as they allow effects and .spl files to interact on the level that you can mimick "IF" blocks in script files. Most of these opcodes appear only in Baldur's Gate II, therefore this level of control is not possible in some of the other games.

Expect an update very soon.

-Galactygon