jmerry

If the items are identified before even looking at them, a mod changed those items by either applying the "identified" flag or lowering the lore requirement to identify them to zero. (Aside from items that were already like this, such as mundane weapons and armor) If the items become identified when you inspect them, the character looking at them has a high lore score, at least compared to those items' lore requirement. In the standard rules, bards have very high lore scores (10 per level base, and nothing requires more than 100 to identify), thieves and mages have decent lore scores (3 per level base), and all other classes have poor lore scores (1 per level base).

It should be. The "world map" structure uses exactly the same format across all games, so it should just be a matter of inserting the strings and editing that one file. ... and I've already written a component to do exactly this. My tweak mod is EE only as a whole, but I could extract this component as a stand-alone. Here it is, extended to work on any game that includes BG1. Hopefully. j8-map-names.zip

And if it didn't work this way, you could reach STR 20 by simply taking off the girdle before you rest and re-equipping it after. Stat-setting always comes before stat-incrementing when calculating how effects combine, and anything like an "only if STR <= 18" test is only checked when the effect is initially applied. Would you wear all your gear to bed? In flavor terms, it makes sense to use the before-equipment baseline here.

It would still make a difference; a stat increment with timing mode 1 interacts with a stat-setting effect very differently than an increment with timing mode 9.

So the action here happens in ability/make_str_payload.tpa; that's where the tables for what strength does are updated. For lock-bashing and weight limit, this is the actual update: PATCH_IF VARIABLE_IS_SET $bend_bars("%str%") BEGIN SET_2DA_ENTRY row 3 5 $bend_bars("%str%") END PATCH_IF VARIABLE_IS_SET $weight_limit("%str%") BEGIN SET_2DA_ENTRY row 3 5 $weight_limit("%str%") END Update the lock-bashing value, using a previously-defined array of lock-bashing values. Then update the lock-bashing value again, using a previously-defined array of weight limit values. Which are much higher. Oops. That second SET_2DA_ENTRY should change entry 4 in the row rather than entry 3. That definitely accounts for strength 11 through 18; those are the values in the 2DA file used to build the bend_bars and weight_limit arrays earlier in this tpa. I'm not sure where things go wrong for strength 10, though... [Added in edit] What does STRMOD.2DA look like for you? It should be in the override, and that's a human-readable text format - no special tools required to read it.

The difference between those timing modes is sharpest with stat-modifying opcodes. For those, timing mode 1 changes the base value of that stat for the creature, and does not leave any sort of effect behind that can be reversed. The Manual of Bodily Health applies +1 CON with timing mode 1. Timing mode 9, on the other hand, leaves a permanent stat-altering effect in place. That effect will endure even through death and resurrection, but can still be removed. The Dragon Disciple's CON bonus at levels 5 and 15 applies +1 CON each time with timing mode 9. So if a (non-protagonist) DD leaves the party, their kit abilities are removed and they lose that CON bonus. Bring them back, and the abilities are reapplied. Neither of these effects would work properly if the timing modes were swapped.

Looks like the current version of things doesn't work for levels taken during the character creation process. I'm not sure why; abilities associated with those levels should just be applied when you enter the game. But that's what it is. Anyway, what's different about the actual spells here from older versions? - The applicator now removes its ability before applying it. This prevents multiple instances of a given sequencer/contingency stacking up when an NPC leaves the party and returns. - There is now a "wrap" layer which filters through a class check. This was clearly added in an attempt to exclude (unkitted) sorcerers, but doesn't actually do that because sorcerers apparently count as mages. Does removing that wrap layer fix this bug? It should be testable in a game with the component already installed by replacing instances of dwsqwr (the wrap spells) with dwsqds (the applicator spells) in the kit CLABs. [Disclaimer: I do not currently have any instances of the games with SCS installed]

Except now, with the v35 version of this tweak, sorcerers can't use sequencers and contingencies at all - the spells are hidden and can't be taken with a spell slot. Which is a substantial penalty for them. Can't have it fair either way.

Ah. And that's implemented in how the applicator spell is built; it filters using opcode 177 so that only mages (including multiclass) and bards actually get the innate. Unkitted sorcerers have the applicator spell in their ability table, but it does nothing for them. So actually, you'd have to change more than just the code I quoted above if you wished to extend this tweak to sorcerers. Verdict: deliberate change working as intended, nothing to see here.

So, a bit more in-depth on how this works. The file for the innate sequencers tweaks those spells, builds the "grant ability" spell, and then adds them to the ability tables with this: // apply the wraps to the CLAB files kit.edit_all[mage|clab_only:i=1] [ k.kit_apply_powers{%string_mage%} ] kit.edit_all[bard|clab_only:i=1] [ k.kit_apply_powers{%string_bard%} ] All mage kits and all bard kits, including CLABMA01 and CLABBA01 which apply to the "base class" version. And here's the old version: // patch innates into kits and update the class text to describe the new innate powers // mages OUTER_SPRINT seq_desc_string @1000 LAF edit_all_kits STR_VAR parent_class=mage editstring="%kit_edit_mage% patch_description_strref=>seq_desc" END ACTION_IF enhanced_edition BEGIN LAF edit_kit STR_VAR kit=dragon_disciple editstring="%kit_edit_mage% patch_description_strref=>seq_desc" END END // bards OUTER_SPRINT seq_desc_string @1001 ACTION_IF VARIABLE_IS_SET $spell_level_to_caster_level("bard" "7") BEGIN OUTER_SPRINT temp @1002 OUTER_SPRINT seq_desc_string "%seq_desc_string%%temp%" END ACTION_IF VARIABLE_IS_SET $spell_level_to_caster_level("bard" "8") BEGIN OUTER_SPRINT temp @1003 OUTER_SPRINT seq_desc_string "%seq_desc_string%%temp%" END LAF edit_all_kits STR_VAR parent_class=bard editstring="%kit_edit_bard% patch_description_strref=>seq_desc" END Basically the same, except that it also specifically calls out dragon disciples. Any sorcerer kits added by other mods are out of luck. So, what's up with sorcerers, and what's new? Well, unkitted sorcerers use the same ability table as unkitted mages. They're going to get the abilities regardless. But sorcerer kits aren't picked up by the call for all mage kits, so they get skipped. The Dragon Disciple is the only one in vanilla, but now ToF adds a bunch more sorcerer kits that should be supported. It looks like just adding another kit.edit_all call for sorcerer kits should work. Unless that doubles up on CLABMA01 - testing recommended.

Checking the code ... that version of the tweak takes whatever table is already in place (normally the BG2 values) and multiplies every value by the entered percentage. With a floor of 1 XP each, if any XP was granted before; if you enter 0, that drops it to 1 XP per trap/lock/scroll instead of zero. The "Disabled" component is functionally identical to entering 0 in the "Custom Value" component.

Yeah, that looks right. The full death ward package includes a bunch more immunities, some of which you may also want. (For example, the "vorpal hit" string) As for the "unused" segment of the effect block, it's just that - unused. Whatever's in there can be anything, as it's not read in an opcode 101 effect. That segment is used for a resource name when the effect refers to some specific resource, as in the opcode 206 effects that ring also have.

Vorpal hits are opcode 13 "kill" effects. Basically the only stuff out there in vanilla that blocks that are death ward effects and full immortality effects. No items grant just the death ward part without other side effects, so you'd have to either add effects to the creatures directly or modify the general "dragring" immunity item. And yes, earlier versions of SCS did give dragons immunity to instant death. Here's a snippet from v34's dragon_shared.tph: ////////////////////////////////////////////////////////////////// //// Baseline patch for dragons ////////////////////////////////////////////////////////////////// DEFINE_PATCH_FUNCTION dragon_general BEGIN LPF check_ini STR_VAR ini=bypass_dragon_immunity_changes RET value END PATCH_IF value=0 BEGIN PATCH_MAKE_PATCH delete_effect=>~opcode=193~ add_effect_inline=>~opcode=>193 parameter2=>1~ immunity_to_opcode=>~74 13 55 211 19~//immunity to blindness/slay/death/imprisonment/Mind Flayer immunity_to_string=>~1474 32089 14674~ // blindness, devour brain immunity_to_spell=>~%WIZARD_IMPRISONMENT%~ END PATCH_IF !is_iwd BEGIN SPRINT $patch_data("immunity_to_spell'") "%DRAGON_WING_BUFFET%" END LPF apply_patches STR_VAR edits=patch_data file_ext=CRE END END PATCH_MAKE_PATCH class=>"if enhanced_edition then no_change else FIGHTER_MAGE_CLERIC" strip_scs_scripts=>null END LPF apply_patches STR_VAR edits=patch_data file_ext=CRE END END ////////////////// And in v35 ... no changes to this section at this time. Which means that the likely cause here is changed library functions requiring different syntax for the same effect. Either that, or this particular SCS-added dragon didn't get the function applied for some reason.

Well, if this is part of a BCS script, that's not a problem; the engine only sees the compiled code, which wouldn't have the named constant anyway. DLG files, though, have the BAF-format code in their raw forms. So there ... the engine loads the IDS files and uses them to interpret any constants that show up in the code.

Exactly. There's nothing stopping you from adding lines to that table, or from using the literal number (120).

RESOLVE_STR_REF is suitable for this. It returns a number, which you save in a variable. Then in that script bit, you include that variable in %% signs and compile it with an EVALUATE_BUFFER. Just in case this compile-time string-saving doesn't work out for you.

Actually, the avenger's Sword Spider form, in vanilla (EE), already doesn't have poison. Lots of attacks per round and relatively high damage (2d6), but no poison.

SoD ties a lot of things to difficulty level. There are scripts for "despawn this creature below difficulty X", so lots of encounters are only at full size if you're playing at Insane difficulty. Some other creatures apply difficulty modifiers in other ways; the Shadow Aspect, for example, uses Mislead at Insane, Improved Invisibility at Core or Hard, and Invisibility at Easy or Normal. Basically, if you want the full strength version of everything, you play at Insane difficulty. SoD has its own combat scripts, which are a lot more complex than those in the rest of the series. But by the same token, I'm not aware of any mods that "improve" them; SCS leaves them alone. As for that free action ring and the shambling mounds, that effect does things in a tricky way. Just like the priest spell, it applies the Entangle cosmetic effects, multiplies movement speed by 0, and penalizes AC by 2. Now, a standard free action package includes immunity to movement speed modifiers and the entangle overlay, so it should still protect you ... and I checked the item in question. You should be getting that immunity. I don't know what went wrong, unless something else edited the item afterward.

With CLABPR01, it looks like the logic here trims any ABILITYN rows that don't have any ability entries. Which is harmless. Or at least, it's harmless as long as there's at least one ability row left (Have you checked CLABFI01 or CLABMA01? Those don't have any abilities at all). But at the same time ... is there any positive reason to do so? The only way trimming rows might matter is if you needed to make room, and I don't think there's a maximum number of rows in the format. With QDMAGUS, it's the already known issue with the table parser not recognizing rows that don't have the ABILITYN label. That will be fixed.

Ah, that makes sense. That effect uses the "curse" icon, but it isn't a curse in terms of mechanics. Also, it does nothing if you have any form of fear immunity active when you drink - you get the icon for twelve hours, but no other lingering effects.

This wouldn't matter; .bs scrips are never assigned to monsters outside the party, and can't be. This looks like another bug similar to the one that erased "talk to a PC" scripts from NPCs in earlier versions of v35; the new Carrion Crawler script is likely being removed after it has been assigned. With no replacement. And since that's their combat script, they just stand there doing nothing.

[ENEMY], used as an object identifier, looks for anything with the ENEMY allegiance - that is, another creature hostile to the party. Which means it won't do anything if this creature is alone. I recommend using something like NearestEnemyOf(Myself) instead. (Also, that extra empty line between the trigger block and action block is nonstandard. I don't think it does anything when this compiles, but it can't hurt to remove it.) Also, as that's a player-usable ability you're using, beware interference from other mods. The Tweaks Anthology "Shapeshifter Rebalancing" component changes that spell to create a paw token that can be equipped to cause the transformation, for example - it no longer directly transforms the subject. If you want a spell that will definitely work, I recommend making a clone of the base spell yourself and including it with your mod.

I don't see anything that could be mistaken for a curse in that fire salamander; all it has is an effect (on its weapon) that inflicts fire damage to everyone nearby once per round.

The "Remove Curse" effect does two things. It unequips items with the "cursed" flag, and it removes spells/effects applied with the "curse" opcode. The "Cursed" portrait icon is not either of those things, directly. Cursed items usually apply a "cursed" portrait icon as an equip effect, and curse spells usually have that portrait icon among their effects, but there's no intrinsic link. You can have an effect that "Remove Curse" will clear that doesn't have the portrait icon, and you can have something that applies the portrait icon but isn't affected by "Remove Curse". So, what effect exactly happened to you?

BGEE rest spawns definitely aren't using the same scaling as BGEE spawn points. My test referenced earlier used the xvart village with a full party at the campaign cap (sum of levels 51), and got ten xvarts (power level 4) whenever that rest spawn (difficulty 2, maximum number 10) triggered. If that were running on the same scaling that the spawn points use, it would have been one xvart (51*2/100 total power, divide by 4 and round up to one enemy). Most likely, it just isn't using that factor of 100 in the calculation. So that's ceiling(51*2/4) = 26 xvarts, truncated to 10 by the secondary cap. Working as apparently intended.