Bubb

STATDESC.2DA looks up the entry based on the index number + column heading, so yes, in this 2DA it actually matters.

Correct - you can do something like this: Append to the very top of UI.MENU => Use WeiDU to replace this part of UI.MENU: with => This patch works for the vanilla UI, (it might break if a UI mod alters the wrong part of WORLD_ACTIONBAR). You can then, in scripts, check if Party AI is enabled with: Global("B3PartyAI","GLOBAL",1) Zero being disabled, of course. I always forget that PST:EE had some unique features; I agree, would be nice if some of those were merged into the normal EE branch.

I'm afraid it's impossible in classic games. The only place the engine exposes such information is to the UI in v2.0+ Enhanced Edition games, (to render the button on the worldscreen in the correct state). It would be possible to rig UI.MENU to toggle a GLOBAL according to the current state of the party AI, but that's about it.

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.