Bubb

EEex crashes almost always generate a .dmp, a freeze with no crash report is usually the engine entering an infinite loop. Would be strange if EEex is causing these stalls, but since there's no generated .dmps for me to look at I can't tell if it's EEex or not. If you do ultimately narrow it down to EEex I'll gladly try to reproduce the bug and squash it. An interesting thing to try would be to manually install EEex on top of your working install. If it starts crashing, totally EEex. You can always uninstall to get everything back to working order.

@subtledoctor Here's an updated B3Identify.tph that should be compatible with lefreut's wonderful UI, (and all of its skins)!

Yep, the relevant spells will probably bring up a broken contingency screen instead of redirecting to the identification menu, since that part of the code failed to get inserted. @Cahir Most likely it's Lefreut's that's conflicting, I'll try to update my utility to support it.

@Cahir A user on the Beamdog forums alerted me to a crash that occurred when the Extended Skills component was installed, (it actually was an engine bug, not EEex, but I digress). You should probably make sure your install is using EEex v0.8.6-alpha, or you might experience a rare crash now and then.

@subtledoctor You're correct, the engine only exposes the icon stored at +0x3A. Any attempt to access the stone variant of the icon is guesstimation of the resref. Many UI mods either do resref + "B", or replace the icon's last character with a "B" - depends on the mod. @lefreut Something like this is possible: function checkForResref(checkResref, checkExtension) for _, entry in ipairs(Infinity_GetFilesOfType(checkExtension)) do if entry[1] == checkResref then return true end end return false end -- Called like local resrefExists = checkForResref("SPWI112B", "BAM") Edit: I ninja'd lefreut, oops!

EEex v0.8.5-alpha has since been released that gets rid of the error-causing entry, so this shouldn't be an issue moving forward.

Yes, Opcode #204 lets an incoming effect through if the effect source and the target are the same, (I.E. the creature applied the effect to itself).

Indeed I would. @Quitschi The game should be generating a crash .dmp in the game's base folder every time it goes down. Could you please attach / link one of those files here? (This lets me track where the engine crashed). Also, a fresh EEex.log from right after a crash might have some info in it.

Apparently the engine really wants the resref to be registered as all uppercase... the IE is so fun sometimes. Here's a tph that automatically uppercases any resref being registered, (Lua side, not the actual file). See if this works: B3Identify.tph

This mechanic is completely vanilla - unless there was a Lua error in a vital engine call the game shouldn't crash. I can't get it to crash in BG:EE 2.5.17.0, so, uh, weird. Could you please upload the SPL file in question, and perhaps the .dmp it generated from the crash? Edit: Actually, if you don't use B3Identify_RegisterResref("<resref>", useCount) in either a M_*.lua file or by calling B3_IDENTIFY_REGISTER the game would crash. Just to verify, you are doing this, right?

It contained a single spell header with an Opcode #234 effect; Opcode parameters don't matter, timing mode / duration doesn't matter. The only requirements are: 1) The spell resref is registered, and 2) It fires an Opcode #234.

EET uses this block in K#FAMSUM.BCS to detect if the summoner was the protagonist: IF TriggerOverride(Player1,Summoned(Myself)) THEN RESPONSE #100 SetGlobal("K#FAMPRO","GLOBAL",0) END Looks like you are changing the alignment of the protagonist for a split second before you invoke the summon. The problem lies in Summoned(), and how the engine processes "reactionary" triggers. The engine saves a snapshot of the summoner's object selector values (plus a few other things) when it summons the familiar, and since you change the character's alignment right before the summon, it saves the altered value. The Summoned trigger runs late enough that the protagonist's alignment has already reverted. It's basically asking the trigger, "Does Player1 match the snapshot I saved earlier?" - and that fails, since the alignment is different. I don't know how to fix the mechanism, that's just what I've found from inspecting the engine.

It's mostly set up that way, as far as I can tell. No components involved, just three functions that can be called after it is INCLUDE'd. It also already uses marker files for the two UI-patching functions, so it should be safe to throw into any mod and call B3_IDENTIFY_INSTALL. I have verified that the UI patching plays nice with EET; however, there was a bug in that previous tph which made opening the spell book impossible after casting the spell, (oops!). It's fixed in this one: B3Identify.tph You guys can totally use, modify, and host this however you want - that's why I made it! To be clear, this is briefly how it is organized: 1) B3_CONTINGENCY_REDIRECT_INSTALL is a helper function that installs the code necessary to redirect the contingency menu. This is automatically called by B3_IDENTIFY_INSTALL, you don't need to touch this. 2) B3_IDENTIFY_INSTALL installs the new identify menu / the code necessary to register a spell to use the menu. Both this function and the previous use marker files, preventing multiple calls to these functions from installing them more than once. 3) B3_IDENTIFY_REGISTER appends: B3Identify_RegisterResref("%resref%", %uses%) to M_B3IDEN.lua, the main file which controls the new Identify system. Note that if you can maintain your own M_*.lua file, appending the aforementioned line manually, that would be preferred, (rather than potentially having several mods altering the same vital file). This function does *not* make the resref completely ready - the spell still needs an Opcode #234 in order to be detected. As subtledoctor says, it uses REPLACE_MULTILINE, (I believe made by K4thos), to patch certain parts of UI.MENU. In particular, if a UI mod alters the wrong place in either the mage book, contingency screen, or inventory screen, it might conflict. It's possible to provide different patching cases to support specific UI mods, should it be requested. Any menu can be opened, the question is whether it is functional without it being invoked engine-side. What sort of things would you want to do with the HLA menu, for instance?

It writes out to M_B3IDEN.lua, which is the main file I use to hold the menu's functions, (my wording was bad here). Using your own M_*.lua when applicable is always preferable - keeps things organized and is a bit better with uninstalls, (nothing major, though). As for the original talk of UI.MENU, it's best to not touch the file unless you absolutely have to.

I'm by no means good at WeiDU, but here's a tph that I've thrown together that installs all the necessary code: B3Identify.tph B3_IDENTIFY_INSTALL performs the necessary UI patches - make sure to run this before subsequent tasks. A new identify spell that uses the menu has to be registered using a Lua function: B3Identify_RegisterResref("<resref no extension>", <use count>) You can use WeiDU to register spells by appending lines to a M_*.lua file, or you can use B3_IDENTIFY_REGISTER to throw the same definitions into the interface's main file, like so: LAF B3_IDENTIFY_REGISTER INT_VAR uses = 4 STR_VAR resref = ~B3IDEN~ END Once the spell is registered, any Opcode #234 originating from the resref will trigger the interface. Note that the Opcode has to originate from a *spell*, however, you can use the mechanism from an item by first passing it through an Opcode #326. (if you attempt to directly call from an item, the engine crashes) This is the small test tp2 I was using to install, as an example: INCLUDE ~bubb_test/B3Identify.tph~ LAF B3_IDENTIFY_INSTALL END COPY ~bubb_test\copy\B3IDEN.SPL~ ~override~ SAY 0x8 ~Bubb Test Identify~ BUT_ONLY LAF B3_IDENTIFY_REGISTER INT_VAR uses = 4 STR_VAR resref = ~B3IDEN~ END Edit: The above should work for vanilla BG:EE, BG2:EE, and IWD:EE. UI Overhauls will probably break the pattern matching.

What about a fully UI implementation? I found out it's possible to hijack the contingency opcode & menu to open whatever interface you want on spell completion. Additionally, the function the engine uses to identify a spell, Infinity_OnSpellIdentify, doesn't actually care if SPWI110 is memorized - it'll decrement the memorization count if it is, but it still functions if not. Check out this mockup, made in vanilla BG2:EE, (no EEex here): That interface instantly runs the lore check on every slot in the casters inventory, (instantly identifying spells that can already be identified), and allows you to identify an item by left clicking on its slot. It also supports variable identification uses, if you want a spell that can identify more than one item at a time.

The engine is hardcoded to perform the following check to determine if Hide In Plain Sight applies when entering stealth: KITIDS & 0xFFFFBFFF == 0x21 Effectively, this means that there are only two possible kits IDS values that will be treated as having Hide In Plain Sight - 0x4021 (used for Shadowdancer) and 0x21.

To clarify - some, if not all of these problems were caused by a bug in EEex. v0.7.1-alpha fixes these issues.

Great to see you're still around! You and your fantastic UI mods are what got me interested in the UI-side of the engine - glad to see these mods have a home once again.

ctrl-Q forces the given character to perform a standard JoinParty() scripting action, and, at least from my testing, it doesn't appear to clear effects. Opcode #278 shows its bonus under "Ability Bonuses", both in the inventory screen and the character sheet, (under the "Combat Stats" tab): If you aren't seeing those lines, the Opcode #278 might not be sticking for whatever reason. Also, looks like Param2 = 1 (Set) and Param2 = 2 (%) don't show the bonus, even though they are taking effect, (as in, thac0 is calculated correctly, but the bonus isn't present in the breakdown). Probably a moot point, I'm sure you know this already - but if you're using the % mode, make sure the creature already has a non-zero bonus, since that's what the opcode's working with, not straight thac0.

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.

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. 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).