jmerry

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:

Quote

    HATED_RACE_TITLE = "Racial Enemy",

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.

1 hour ago, TwiceTested said:

Greater Deathblow seems too strong.  5% chance to kill Irenicus is VERY funny, but seems too much.

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.

59 minutes ago, cdx said:

Would be great to be able to set their store price to something like 1gp per 1 arrow, or custom amount per stack.

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.

5 minutes ago, Jarno Mikkola said:

Thing is, the game doesn't really have a good system for adding icons to the portrait as effects. As they are all tied to the opcodes... it's an engine limitation..

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:

     MAKE_PATCH
         say_name=>3
         add_basic_ability=>null
         add_effect_inline=>"opcode=>101 target=>2 timing=>9 parameter2=>17"
         add_effect_inline'=>"opcode=>296 target=>2 timing=>9 resource=>CLWOUNH"
         add_effect_inline'0=>"opcode=>296 target=>2 timing=>9 resource=>CMWOUNH"
         add_effect_inline'1=>"opcode=>296 target=>2 timing=>9 resource=>CSWOUNH"
         add_effect_inline'2=>"opcode=>296 target=>2 timing=>9 resource=>CCWOUNH"
         add_effect_inline'3=>"opcode=>296 target=>2 timing=>9 resource=>HEALH"
         add_effect_inline'4=>"opcode=>296 target=>2 timing=>9 resource=>SPHEALIN"
         add_effect_inline''=>"opcode=>267 target=>2 timing=>9 parameter1=>14022"
         add_effect_inline'''=>"at_end=>1 opcode=>324 target=>2 timing=>9 resource=>dw#mumcw"
     END
     LAF make_spell STR_VAR spell=dw#mumcw edits=patch_data END

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:

DEFINE_ACTION_FUNCTION iwd_divine_spells_postproduction BEGIN

  LAF array_read STR_VAR file=iwd_spells_installed.txt path="%data_loc%" RET_ARRAY IWD_spell_installed=array END
  LAM data_spells_by_level // needed for scroll
  LAF make_physical_mirror_level_5 END
  LAM data_spell_resrefs // load in new physical mirror as well as new IWD spells

  ACTION_IF VARIABLE_IS_SET $IWD_spell_installed("CLERIC_ENTROPY_SHIELD") BEGIN
    LAF entropy_shield_flame_strike END
  END  
  
  LAF monster_summoning_divine_cosmetic END
  LAF no_chant_spell_failure END
  LAF patch_cures_into_stores END
  LAF cre_set_joinable_priest_spells END
  LAF clearair_divine END
  LAF surplus_cleric_protections END
  LAF run STR_VAR file=summoned_monsters_divine location=lib END
  LAF run STR_VAR file=dealign_cleric_spells version=1 location=lib END
  ACTION_IF !MOD_IS_INSTALLED "spell_rev/setup-spell_rev.tp2" 0 BEGIN
    LAF bg2ify_cure_moderate_wounds END
    LAF hide_old_cause_wounds END
  END
  INCLUDE "%MOD_FOLDER%/%component_loc%/lib/cd_divine_post.tpa" // just in case Cam's code isn't SFO-sugar-compliant
  LAF cd_divine_post END
  ACTION_IF !enhanced_edition BEGIN
    OUTER_SPRINT obg2_res_path "%MOD_FOLDER%/%component_loc%/obg2_res"
    INCLUDE "%MOD_FOLDER%/%component_loc%/lib/obg2_divine.tpa"
    LAF obg2_divine END
  END
  ACTION_IF MOD_IS_INSTALLED "spell_rev/setup-spell_rev.tp2" 55 BEGIN
    LAF run STR_VAR file=sr_nwn_spelldeflection location=lib version=sr_nwn_arcane END
  END
  

END

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.

Balors are vulnerable to +3 weapons. Immunity to +3 weapons is very rare in the game; it only happens for a very few enemies or as a short-duration spell. Now, that Mantle thing might be something ... but do note that the vanilla version of Mantle doesn't block +3 weapons either. That's a specific tweak in SCS, and it's possible that wasn't part of your install.

Now, on liches and spell attacks...

Spell Thrust, while it's a level 3 spell by memorization, hits as a level 4 spell. That lets it go over and remove Minor Globe of Invulnerability, for example. And liches, which still have blanket immunity to level 4 and below spells even after the tweak, are fully immune to it.

Secret Word, while it's a level 4 spell by memorization, hits as a level 5 spell. Post-tweak liches no longer have blanket immunity to level 5 spells, and instead have specific immunity to the various level 5 attack spells. Secret Word is not on the list of spells that this immunity applies to. Which makes sense in a way; you're not really targeting the lich itself, but instead the magic around it.

Now, about that lich/Spell Thrust/Spell Shield interaction ... deflection effects such as Spell Shield are "outside" immunity effects such as the lich's innate defenses. So you throw the spell, and the first defense that gets in the way is that one level of deflection from Spell Shield. That absorbs the Spell Thrust and is used up. Spell Thrust can break a Spell Shield even if the target is immune to Spell Thrust. That's just the way the system works.

Short summary of the state of things: The initial list for Monster Summoning 5, on first installing the IWD spells, is a troll and a minotaur. The ininitial list for Monster Summoning 4 is an ogre mage and a yuan-ti. The initial list for Monster Summoning 3 includes an ogre mage. Your list for Monster Summoning 5 is the ogre mage from the MS4 list, a typoed version of the yuan-ti from the MS4 list, and the ogre mage from the MS3 list. While all of these are wrong, it's the typoed yuan-ti that causes the crashes you've been seeing.

So, that changelog. Nothing outside SCS. I've looked at the IWD spell component, and didn't see anything wrong there. Now, the spell tweaks... that would be spell/adjust_monster_summoning.tpa. And I've spotted it.

That file starts at high levels and goes down. For MS5, it edits the minotaur slightly, creates a greater yuan-ti (dw#ms5yt), and rebuilds the table with the minotaur, troll, and greater yuan-ti. Then for MS4, it edits the yuan-ti (dw#ms4yu), edits the ogre berserker (ogregrsu), and rebuilds the table with the ogre mage, ogre berserker, and yuan-ti. Only there are two typos in this line - it rebuilds the msummo5 table instead of msummo4, and it puts in the nonexistent dw#ms4yt instead of the correct dw#ms4yu.

The problem (line 145):

LAF spl_make_summoning_2da STR_VAR monsters="OGREMASU OGREGRSU DW#MS4YT" filename=msummo5 END

The fixed version:

LAF spl_make_summoning_2da STR_VAR monsters="OGREMASU OGREGRSU DW#MS4YU" filename=msummo4 END

For a hotfix without reinstalling everything, edit the MS4 and MS5 tables as follows:

msummo4:

2DA V1.0
0
     RESREF	Hit 	AreaHitAnimation
1 OGREMASU msumm1h msumm1x
2 OGREGRSU msumm1h msumm1x
3 DW#MS4YU msumm1h msumm1x

msummo5:

2DA V1.0
0
     RESREF	Hit 	AreaHitAnimation
1 MS5MINO  msumm1h msumm1x
2 DW#MS5TR msumm1h msumm1x
3 DW#MS5YT msumm1h msumm1x