Skye

Ability header is fine, so is all the metadata. I went through it byte by byte. The problem seems to be with the way the macro determines the offset of the new effect. It works fine if the ability already has a pre-defined effect index, as an existing ability would have, but for a new ability, you need to set the effect index to the next available number. I was hoping I might be able to avoid these calculations but meh... Edit: It was actually more painless than I expected it would be. A simple equation to get the current number of effects and it worked like a charm. index = (SOURCE_SIZE - effects_offset) / effect_length ... WRITE_SHORT offset+0x20 index // first effect index Thanks for the help, guys. Gonna go tackle other issues now.

But that's an equipping effect (i.e. global effect). I'm trying to add a new extended effect to my item's new ability, it's got nothing to do with equipping effects. I guess I'll check the source code.

Hrm, alright, new problem. The effect is added to the file and the index where it's supposed to be is added to my new ability, but the effect is inserted at the base effects offset, rather than appended at the end, which completely messes up the effect indices. It seems to be an issue with me manually inserting the new ability prior to calling the patch function. I've correctly updated the effects offset and number of ability blocks in the item metadata prior to calling the function, so I don't see what could be causing the problem.

Ugh, I thought type was the resist/dispel type, not the header type that you wanna add the effect to. I completely missed it. Now I just gotta fix the insert_point and I'm golden. Thanks, you probably saved me a couple of hours.

I've decided to try adding some new abilities to items via scripting. So, to test that out, I've created a patch block that adds a new item ability (since there's no inbuilt function) and then tried calling ADD_ITEM_EFFECT to add an effect to that ability. Although the ability was added without any problems, the ADD_ITEM_EFFECT function seems to have had no effect whatsoever. There's no new effect blocks appended to the file, there's no overwritten blocks, nothing. No errors in the debug file either. I tried running only the ADD_ITEM_EFFECT function and append it to an existing ability and it makes no difference. I don't really mind creating the effect block from scratch, it just seems like a waste of effort if there's already a patch function for it. Here's the code: LAUNCH_PATCH_FUNCTION ADD_ITEM_EFFECT INT_VAR opcode = 0x39 target = 0x01 timing = 0x01 type = 0x00 power = 0x02 header = 0x01 STR_VAR resource = ~SPWI203~ END Any ideas?

Yeah, that was my next idea as well. It's better than editing my triggers, I guess.

I'm trying to make my life easier, so I was wondering if anyone knows of a clever trigger that would allow me to determine if SoD is installed while in-game. I know I can do it during mod installation, but I'd prefer to avoid having to override my triggers while I'm compiling the scripts.

Looks like the second one is hardcoded to opcode 324, yes. I tried it with opcode 206, but it seems to ignore the resource in that case, displaying an empty string where the resource name would be. A shame, I was hoping to make good use of this token in my effects.

I came upon these two strings in the TLK file today, but after playing around for a bit, I can't seem to get anything out of this token. Evades effects from <RESOURCE> Unaffected by effects from <RESOURCE> Anyone got any idea what <RESOURCE> resolves to and in what context? Only reference to these strings I could find was in ENGINEST.2DA.

To summarize: I never said this change would be trivial (although it wouldn't be dramatically difficult to implement either). So far they've made two major overhauls to the UI and both times they've decided not to tackle this. We know this clearly isn't impossible and they already have similar code required to implement it. It would drastically improve a major part of modding, which is what they need to keep the franchise alive. All of this simply adds to my disappointment regarding the matter. Obviously, this isn't as trivial as adding a simple 2DA table and reading from it since the actions triggered by buttons are also hard-coded to a degree (e.g. a sorcerer can't pick pockets even if you try to trigger that action via hotkey or script), but I've done a reasonable amount of UI coding in the past and I refuse to believe that this is something so complex that they couldn't have afforded to get it done. They simply chose not to. There didn't have to be any particular reason for it, no one's saying they chose to keep it hardcoded out of spite, but everything beyond that is pure conjecture. The simple fact is, it's currently not doable in the EEs. If they choose to tackle IWD2 after Ps:T and then after decide to backport the UI changes, it might be doable in the future. Or it might not, who knows. All I knows is this has been a major thorn in my side for over a decade and I was hoping things would have changed by now. I'll just have to work around it for the foreseeable future.

I find it highly disappointing that this functionality is still hardcoded in the EEs, especially after all the UI overhauling that's been done. I mean, IWD2 had customizable action bars 15 years ago, at the very least I was expecting a 2DA/IDS combo at this point or a LUA file or something. Frankly, this is one of the very few things still standing in the way of free kit design. I guess I'll keep waiting then...

I haven't approached this particular issue in many years, but seeing as the GUI is a lot more exposed now, I was wondering if there's any way to change the default action bar buttons used by a class/kit? I've scoured the files, but I've only been able to find the definitions of menu buttons inside UI.MENU, which isn't particularly helpful. I could potentially rewrite the code block so that it overrides the buttons if the creature is of a particular class, but that's far too dirty a hack for my taste.

There was no question, I'm just reflecting on how things are done in the game. Defaulting on hardcoded mechanics and adding new effects to bypass them seems like an odd approach, when these things could be much more elegantly handled via scripts. Nothing really breaks my mod, but this generic reputation-based happiness and hardcoded breaking points didn't mesh well with how things should realistically work with companions. Anyway, adjusting HAPPY.2DA and HAPPY.IDS solves all issues, I just didn't really want to resort to such a heavy-handed approach.

I don't know, maybe that's the case in BG2:EE, but in BG:EE, Imoen does have a breaking point (confirmed just recently by one of my friends). Also, most of the joinable NPCs' (sans the EE ones) breaking point is apparently handled by the game itself and not by a script. It's possible that these things were hardcoded before and they changed the happiness values in the 2DA or something to avoid unnecessary checks in the script round or maybe they just didn't copy everything right. Either way, I'll be trying to sort this mess out on my own since it's interferring with my mod. If you want something done right...

Which is fine, but I still think party member morale should be handled entirely via scripts.

So, they hardcoded the reputation responses and then added an opcode as a workaround? I don't think I'll ever understand the reasoning behind some of their design choices... On the upside, I guess taking a yearlong break resolved some of the issues I was having.

That sounds unfortunate. I might have to get creative then.

I'm guessing that list is exhaustive? There's only ever gonna be normal and celestial summons? If so, how is a celestial creature/spell defined? Hardcoded race value for planetars and solars (0x9c, 0x9d, 0x9e, and 0x9f)? Or is there a flag somewhere? I was always making workarounds for summoning limits before EE. Now I find myself wanting to put more limits on them.