Bubb

If you're looking for a hard cap, spell abilities store the number of effects present as a word - so technically a spell can have 65,535 effects in a single ability without crashing. Game will probably lag out hard if you cast a spell with that many effects though.

53 minutes ago, Guest anon said:

When doing all of this, I can get the .spl for the spell, and the Strref through the game by turning StrrefOn() ... (wasn't sure what you meant by finding it in the +0x8 area)

I meant opening the spell's resref in a program like Near Infinity, and finding the name strref by looking at offset +0x8 from the start of the file, (that's where it is stored). The way you're doing it is easier, so that's all good.

53 minutes ago, Guest anon said:

So could you explain on what exactly a spell 'id' is and how you can add new ones please?

In the context of these hotkeys, a spell 'id' is the first number in the hotkey definition. The engine stores these definitions internally using an array of 500 allocated indices, with the spell 'id' being the position where the definition is stored.

The reason why <id> = 501 doesn't work is because it exceeds the valid maximum, (500). This is a hardcoded cap, you cannot expand the number of hotkeys the engine will keep track of. When adding a new hotkey you need to use an id, between 1-500, that isn't already used. It appears the unused range in EET is 68-180, so use a number in that range for your new hotkey. Note that even though the different hotkey types are defined with sequential id values, this isn't required. Using <id> = 68 for the spell in your example would work just fine.

If you know the spells you want to add to the list, you can do it manually.

1) Open up BGEE.LUA in Near Infinity and search for "keybindings =".

2) You should see a whole bunch of hotkey definitions. Scroll down until you see definitions containing "SPPR" or "SPWI", (based on if your spell is priest / mage).

3) Copy a line from the relevant category, and paste it at the top of that category's definition block. Your line should be something like this, (with the brackets being placeholders):

{ <id>, 6,  "<resref>",					<name_strref>,	"",		0,	0},

(the '6' in the above example is the hotkey type; 5 for priest spells, 6 for wizard spells)

4) Change the placeholders according to your spell:

• <id> should be a number unique from the rest of the definitions. The unused id range for each game is currently:
  • BG:EE => 68-188
  • BG2:EE => 68-180
  • IWD:EE => 68-141
• <resref> should be the spell's resref.
• <name_strref> should be the spell-name's strref, located at +0x8 in the .SPL. And yes, this field is required for the hotkey to work.

After doing all that, the spell should appear in the game's hotkey list. It's definitely not convenient, but it does the trick if you are so inclined.

The "Current Difficulty Level" field is bugged. The engine populates this field with the average party level, which is found by calculating the average CLASSLEVELSUM stat value across the party. This value is updated whenever an area goes from being unloaded to loaded. However, on initial savegame load the engine doesn't yet have the party initialized - it ends up populating 1 as a fail safe in this instance.

Try loading a savegame, transitioning to another area, and then checking that new area's current difficulty field, (at offset 0x56). I've observed it holding the correct value.

Also, I've investigated CheckAreaDiffLevel()'s asm; here's some equivalent pseduocode:

if (trigger_int_1 == 1)
{
	return current_are_diff < area_diff_2;
}
else if (trigger_int_1 == 2)
{
	return current_are_diff >= area_diff_2 && current_are_diff < area_diff_3;
}
else if (trigger_int_1 == 3)
{
	return current_are_diff >= area_diff_3;
}

trigger_int_1 being the trigger parameter, area_diff_2 being the byte at 0x54, and area_diff_3 being the byte at 0x55.

The trigger seems to work as expected after an area transition has occurred, (because the current difficulty field finally gets populated).