jmerry

Looks like the mistake is in the documentation. The spell and its description are copied from the version in Siege of Dragonspear, which is an AoE spell. It's not identical - the SoD version uses color-setting effects that target the whole character at once, and those need to be split up to work in non-EE games. But it's basically the same in the ways that matter.

Dread wolves are definitely supposed to be undead. The BG2(EE) version is the one that's mistaken. As for editing the LUA, you open it up in WeiDU and use the text-parsing capabilities. Search and replace, with special characters escaped: REPLACE_TEXTUALLY ~HATED_RACE_TITLE = \"Racial Enemy\",~ ~HATED_RACE_TITLE = "Favored Enemy"~ If you want to do this in more languages than just English, it gets more complicated, of course. You read the "Racial Enemy" and "Favored Enemy" equivalents from a tra file, and you also switch up which file you're editing based on which language you're working in.

Running through the files, here are some other races that appear on undead creatures in BGEE: - SPECTRE. Ashirukuru. The Durlag's Tower ghost is also a spectre, but isn't undead. - WOLF. Dread and vampiric wolves. - HUMAN. Summoned skeletons. And of course, if you include SoD, you get stuff like wraiths, liches, goblins, shadows, vampires, and even a troll. Maybe ... don't use race when you want to target undead in general?

Some items become more difficult to pickpocket. Algernon's cloak is not one of them, because it's initially in a quick slot and the component interprets that as already equipped. It won't move items out of "wrong" slots.

Not the most informative changelog there; the initial component just fixes up creature THAC0 and saves to fit with their levels. No, the real change - if there is one - is somewhere else. Like the creatures' AI scripts. Which should have the same names as they do in the unmodded game, but may have different content.

Actually, I just noticed something about the ranges. The description says "6 feet" for the armor and "5 feet" for the standard fireshield spell. In patch 2.5, they appear to have had the same range. There's no good reason for the armor to have a shorter range in 2.6. And then I run a quick test. Give a fighter-mage both the armor and a fireshield spell. Have a partner walk up and attack them. Staff (range 2) - no retaliation. Club (range 1) - no retaliation. Dagger (range 0) - no retaliation. What? Retry that with only the armor. Staff hit gets retaliation. Club hit gets retaliation. Dagger hit doesn't get retaliation. Uh ... All right, only the spell, then. No retaliation on any of the hits this time. All of this was on an essentially vanilla BGEE 2.6 installation, with fresh characters created in ToB. The more I test, the less I think I know. Fireshields appear to be inconsistent, in a way I just don't understand.

So, looking at how my collection interacts with some of these... EET Tweaks: no problem with most components, in either order. We're just not touching the same things. The XP scaling components, though, will interact with lots of things in ways that make order matter. I have two components that interact with quest XP scaling. - "Candlekeep XP Boost". Increases the XP for each Candlekeep chore from 50 to 400, so that a lone player can usually reach level 2 before venturing out. And in the current version, that's a straight text replacement, so the order matters. If my component is installed after any version of the quest XP scaling component, it will do nothing because the text I'm replacing isn't there. At least, in the current version; I think I'll tweak how that interacts for the next version. - "Noober's Game". Completing this dialogue-based text adventure game grants XP. A pretty trivial amount for when it comes in ToB, but it's there and it'll differ based on the order. Random Graion Tweaks: should be fine in either order. I don't see any likely interactions in the component descriptions. aTweaks: I've had an issue once; a case in which aTweaks combined with two other mods to mis-index a spell file, which my mod then choked on reading and errored out of an unrelated component. Some interactions are likely, though I couldn't tell you how it would go off the top of my head. Also, note that many components of aTweaks are for older game versions and are no longer relevant to an up-to-date EE install. If you want to "Prevent Mislead Clones from singing Bard Songs", you can - but patch 2.6 already does this by disabling the button for them. I would recommend using the fork that's actively maintained instead of the original author's version that hasn't been updated in six years. That mis-indexing bug I mentioned has been fixed, for one. (Link for that newer fork: https://github.com/TotoR115/aTweaks)

Ideally, it shouldn't matter. A tweak mod like these will alter lots of existing resources including stuff that other mods add, and shouldn't add new stuff that other mods will want to tweak. In practice, it comes down to specific interactions that the mod authors likely didn't plan for. I certainly didn't plan around any of the other mods on the list in designing mine, for example. There are quite likely to be individual component combinations that are incompatible, in either order. If two tweaks are trying to do the same thing, you probably shouldn't install both of them.

Which game version? And what, exactly, did you observe? Like other fireshield effects, this should only work against sufficiently close targets. And in patch 2.6, that failure from longer distance is silent. Also, it's a rather short distance - shorter than most fireshields. In my quick tests, the retaliation failed against a full-reach staff attack but succeeded against a dagger attack. And a double-mirror short sword attack (Imoen with the armor and a short sword attacked a Dragon Disciple who had cast Fireshield Red; the feedback loop dropped her to minimum so she left.) The 2.6 version of the fireshield mechanic uses projectiles to define the range. Trap size 42 for the projectile that the SLoT uses, trap size 59 for the projectile that most fireshields use, trap size 85 for the projectile that a few "big" effects like the balor fireshield use.

Checking that referenced component ... what it does is wipe out favored enemy selection for all rangers, making the only possibility at character selection a dummy entry that doesn't provide any bonuses against actual enemies. Obviously incompatible with any ranger kits that use favored enemies, though it won't touch NPCs that already have a favored enemy selected. The alternative would be to allow normal favored enemy selection at character creation, and then have a script wipe it out once you start playing. Detect that kit in the party, set their favored enemy to NO_RACE. Which is even more of a kludge, but at least you can use it alongside the vanilla ranger kits.

So, the first fundamental issue you'll run into is that the racial/favored enemy system is heavily hardcoded. You can change what races are options - that's HATERACE.2DA - but the core mechanics are out of your reach. It will always be a "race" that's the target, and any ranger will have the choice at character creation. The first part - changing the game text to "favored enemy" - is probably the simplest. And even that is a bit tricky, because it's not just in dialog.tlk. There's also an element of L_en_US.LUA (or the equivalent for another language), specifically line 324: For the strings that are in dialog.tlk, you can run a search in Near Infinity. I find string 15897 "RACIAL ENEMY" (unused in the EE), string 15982 "Racial Enemy" (referenced in ENGINEST.2DA, GUICG.CHU, and GUIREC.CHU), string 24317 (description for the class feature, referenced in ENGINEST.2DA), and string 17256 (unused, identical to #24317). So that's two strings to overwrite, replacing "Racial" with "Favored" and "racial" with "favored". Best done in WeiDU with the STRING_SET action. On race consolidation, the things to watch out for are other effects that already care about race. Like Kondar, which checks for the LYCANTHROPE and DOPPLEGANGER races. Or the Sword of Balduran, which only checks for LYCANTHROPE. Or scripting bits. Or stuff mods create that you won't be able to predict in advance. Consolidating races could unexpectedly undermine assumptions and break things; you can predict and handle some issues, but not everything. Honestly, this one's sneaky enough that I just don't know. For a kit based around the favored enemy, I don't think you can mess with the choice at character creation, at least without serious UI modding. But what you can do is change that stat once gameplay begins. There's no opcode for it, so you have to do it with a script action (ChangeStat). For a class name change based on the favored enemy choice? Actually, that shouldn't be too hard. Opcode 290; look up SPIN722 GREAT_DRUID_TITLE for reference. Build a spell for that, then have a script to apply it when appropriate (Player N is a ranger, not one of the recognized kits, and their favored enemy stat matches).

The tweak does make a difference. For vanilla bards (such as Garrick), it allows their song to affect allies and summons in addition to the party. For skalds, blades, and the HLA "Enhanced Bard Song" (such as Haer'Dalis), it greatly increases the range of the song.

It's in Suldanesselar. And the only way you'll get illusionary rakshasas is if one of them casts a clone spell. Clones get clones of the equipment of the creatures they copy. Droppable equipment becomes undroppable. Undroppable equipment vanishes. And immunities like the rakshasa immunity to low-level spells are provided by undroppable items. So clones of rakshasas don't get that protection. Vanilla game mechanics, nothing to see here. This can be seen even in vanilla; there's one group of rakshasa fighting against elven mages that all cast Mislead.

Removing the impact of charisma and reputation on prices would remove the possibility of making a profit by buying and selling the same items repeatedly, yes. As for making a particular item unsellable, there's a flag on the item that will do that in original BG1. There isn't a flag for that in BG2 or the EE - at least, not without undesirable side effects. The other lever that can be used is item type; some stores won't buy arrows, for example. Of course, using this would shut off selling magic ammo too.

Irenicus (in Hell), along with many other quest bosses that have something to say before they die, is immune to instant death effects. The only way to beat characters like that is to bring them down to low HP so their scripts kick in and finish them. So, ironically, this form of Greater Deathblow would be absolutely useless against foes like that.

Game mechanics are a limit here; the base price must be per-arrow, and must be an integer. The standard value is zero, which means basic ammo can't be sold back to the store for anything and a stack of any size costs 1 to buy. If you increase that price to 1, then it becomes possible for a character with high reputation and charisma to make a profit buying and selling the ammo; this is already in the game for throwing axes and throwing daggers. The price you buy a stack gets discounted to something like 75% or 67% of the base price, and you're paying 13 or 15 gold for that stack of 20 arrows. Which you then sell back for 1 gold per arrow - you could always do it one at a time - and get more than you paid. If you increase the price to 2, that closes off the profit exploit. But that's way too much for basic ammo; a starting archer would have trouble buying any arrows at all. And it's the same as the price of a dagger, which is a lot more metal. (Incidentally, there are no enemies in the entire campaign that use slings and bullets. You'll only ever get a few bullets from pre-placed drops, and you'll always have to buy anything else. While enemies with bows and arrows are quite common, and you can supply even multiple archers in a party entirely from enemy drops for considerable portions of the game.)

Well, there's no icon attached to that spell ... but I wouldn't be surprised if there was an existing disease effect tied to mummy attacks; BG2 mummies have a disease effect that inflicts 7 poison damage per round for five rounds if you fail the save, for example. It's possible that you resisted the obvious disease and got caught by the insidious one.

The game flat-out has an opcode for adding a portrait icon (142). Sure, many other effects come with specific icons, like disease, but there's nothing stopping you from adding the disease icon to the spell. Or maybe a custom-named clone of that icon. And since this anti-healing effect is countered with "remove that spell" effects, any portrait icon will be seamlessly removed with it.

You cure it with a "Cure Disease" effect. Either that spell, or a more advanced spell that does the same thing (Neutralize Poison, Heal), or an item with the effect. But it really should have an icon so you can see what's going on.

So, your effects indicate immunity to the healing opcode. Which would likely be an effect on the character ... check save ... ah, there it is. Immunity to "current HP bonus", source = DW#MUMCW.SPL, duration permanent (mode 9), bypass resistance/undispellable. That source name looks like "mummy" to me, which probably means it's from "Revised Icewind Dale undead". A mummy's hit blocking healing - reasonable. Doing so permanently and undispellably - not reasonable. And here's the code that creates the spell, in undead/undead.tpa: A "mummy rot" spell, presumably attached to their attacks, that blocks healing. And it's permanent. How do you remove it? The next blocks patch all spells and items that cure disease to cure this. Recommended change: add a "disease" icon to the mummy rot spell, so that players can see the effect and have an idea of how to counter it.

Or you just edit the WILD_MAGIC_AREA spell to include the alteration you're looking for; that's what actually imposes the wild surges, at least in the Watcher's Keep areas. Unmodded, that spell does two things: force the target's next spell cast in the next 14 seconds to surge, and set the target's wild surge bonus to 1 for those same 14 seconds. Which, depending on how the wild mage surge bonus is implemented, might even override it so they don't get their usual +level to the check.

Do you mean Cause Serious Wounds? Because the IWD divine spell component of IWDification/SCS creates a new version of Cause Serious Wounds, rather than overwriting the old one. Then it hides the old one, adding it to hidespl.2da and flagging it unusable by both druids and clerics. But all versions of Anomen start with the 4th level cleric spells already in their spellbook. This includes (BG2) Cause Serious Wounds, because he's neutral. And just adding a spell to hidespl.2da and flagging it unusable doesn't remove it from spellbooks that already have it. So then, after installing the IWD spells, Anomen and BG2 Viconia will have both versions of Cause Serious Wounds. Higher level versions of those characters like the ones that join in ToB will also have both versions of Cause Critical Wounds (which has the same thing going on). Similarly for druids; Cernd will always have both versions of both Cause Wounds spells, and higher-level versions of Jaheira such as her ToB instance will as well. Now, that same file (iwd_divine_spells_postproduction) that hides the old Cause Wounds spells also runs a function "cre_set_joinable_priest_spells" that updates spellbooks for joinable NPCs with divine spellcasting. But it runs this function before it hides the old Cause Wounds spells, so it doesn't remove those spells from any spellbooks. Any joinable level 7+ non-good priests will have both versions of Cause Serious Wounds and any joinable level 9+ non-good priests will have both versions of Cause Critical Wounds. Relevant code: This issue applies equally to IWDification, which has exactly the same code here.

Wait ... I thought I reported this a while back. It's not a new issue at all; I noticed the flipped names back in my v32 playthroughs. Well, if it was ever fixed, it isn't now. Relevant code segment, with comment lines by me inserted: // From drow/drow.tpa // minor spellcasters MAKE_PATCH allegiance=>ENEMY say_both_names=>3101 script_override=>shout END LAF clone_creature STR_VAR creature=~dadrow1=>dw#drja2~ edits=patch_data END // dadrow1 is a level 12/12 fighter/mage. One of these added to area. MAKE_PATCH allegiance=>ENEMY say_both_names=>3102 script_override=>shout END LAF clone_creature STR_VAR creature=~drow05=>dw#drja3~ edits=patch_data END // drow05 is a level 10/10 fighter/cleric. Five of these added to area. // From lang/english/drow.tra // @3101 = ~Jae'llat Priestess // @3102 = ~Jae'llat Mage

Well, SCS certainly doesn't make that change. And your test show that the balor isn't actually immune to +3 weapons ... maybe the radar tool is lying to you? Because at this point, that's the element that doesn't fit the others.

It's a unique CRE (because its death matters), but I've never seen it be immune to +3 weapons. And from a game design standpoint, it shouldn't be. That balor is on the critical path, and +4 weapons are exceedingly rare in SoA. You can pick up a few in the Ust Natha sequence, but that's after that balor. Before ... there's only the +4 staff in Ribald's shop. Or a couple of options that drop from optional boss encounters you aren't expected to have done. Or Watcher's Keep, if playing a game that includes ToB. If that balor requires +4 weapons to hit in your setup, some mod is doing funky things. And it's not any mod I'd want.