jmerry

The mechanism there ... in the base game, the Black Pits has a special override script for PCs (BPPLOT.BCS) that does the "fall asleep at 1 HP, wake when raised" part, and the non-removable "Slave Ring" with a min-HP effect and immunity to instant death (But only the opcode 55 "slay" kind, because that's the only kind that comes up in that adventure). Area scripts handle the "if everyone goes down, you lose" part. This already has the potential to do some bad things. If you export a Black Pits character and import them to the main campaign, they'll keep the script and any equipment they have - including the "Slave Ring" if you did so before victory. Put that into a campaign that's not designed for it, and trouble ensues. Shoal's kiss on the protagonist is a soft-lock, for one - they go down, you can't raise them in the field because you don't have the levels, and you can't leave to reach a temple because of "You must gather your party before venturing forth". If you still have the ring, it's also impossible to kill that character for a proper Game Over, and your only recourse is to quit out. So you can take that mechanism as inspiration, but it needs a lot of tweaks to actually function outside its original context.

Good to know. And that projectile change looks like a sensible thing to do here.

The limitation on protection items and enchanted armor isn't anything on the item itself; it's based on ITEMEXCL.2DA. You just need to add a row for your item to that table.

Mechanically, I think what's going on is the old mechanism for leveling NPCs - they get replaced based on NPCLEVEL.2DA whenever you enter their area. This has been largely defanged by setting all of the entries to be the same and putting triggers in their scripts for when they first join, but the mechanism is still there. So a global character that isn't in that file shouldn't be affected...

Evil NPCs not joining at high rep varies somewhat by character, and Viconia is notably complicated in BGEE. The first time Viconia asks to join, in Peldvale, she doesn't check reputation. All subsequent times, she'll only join if you're already at or below 18 rep.

The symbols are a bit tricky in general; the versions of the three normally available to players in the BG series are party-unfriendly, but there are NPC versions of the spell that are party-friendly. This distinction is entirely handled through the projectile: ICEGLYP for the party-unfriendly versions, TRAPGLPN for the party-friendly versions. There's an enemy-only version of Pain in the BG series already; it uses a different (party-friendly) projectile SPARMANP. And it doesn't have a proper description. This, however, is a spell copied directly from IWD by the SCS/IWDification spells component. It uses the ICEGLYP projectile. The description is also copied directly from IWD. So, I see two possibilities here: - The projectile has different properties between the two games. - The description is inaccurate in IWD. (I don't have IWD, so I can't test this) There's another symbol spell copied over; Hopelessness. That one has a party-friendly description, and a new projectile not already in the BG series ... which is party-friendly. I'm leaning toward the description being inaccurate in IWD.

Let's see - how do the pieces here work? The spell shield portion of ISoM is a tweaked clone of Spell Shield; one level of deflection against the MAGICATTACK sectype. The vanilla version of the wand ability has the ABJURER and MAGICATTACK types. So that would run into the effect, use up the deflection, and then the shield gets removed. (This part required a fix in v35, because the cloning process didn't update everything it needed to) SCS, in the spell tweak for Breach, externalizes the effects of the wand to actual spells. The "Pierce Magic" spell becomes a clone of Pierce Magic, modified to always reduce MR by 20 instead of depending on caster level. And ... oh. That's the catch. In the process of externalizing the spell, the wand's Pierce Magic ability ends up with exactly one effect. That's a "cast spell" effect, newly created, with power 0. And since the ability still has the MAGICATTACK sectype, the spell shield deflects this carrier effect. The subspell never gets cast. And that drains zero levels of deflection, because that's based on the first effect in the ability being deflected. The spell shield is not used up. Have you tested the wand's Pierce Magic ability against the original Spell Shield? If I'm right, that should have the same issue. And so should the Breach ability; that ability also has the ABJURER and MAGICATTACK types, and its content gets replaced by a "cast spell" effect. Recommended fix: remove the types of the carrier abilities when editing the Wand of Spell Striking in modify_breach.tpa. The subspells interact properly with spell defenses, so the carrier abilities should pass through everything. As for the description - that's not something SCS changes. The wand uses abbreviated versions of the descriptions of Breach and Pierce Magic, and the level limit for Pierce Magic happens to be omitted here.

Some mod probably adds something, but there's no innkeeper in Gullykin in vanilla.

Which is less interesting than it sounds; while the bag item is duplicated, the contents aren't - they still point to the same .STO, so the bags are just portals to each other. When a character leaves the party, any critical items they were carrying (which includes the Flail of Ages and all containers) are removed from their inventory and sent to player 1. Apparently, trying to process this twice in the same tick for the same character leads to the items being sent twice, because the game hasn't updated that they're not in the inventory anymore. Why does a double Imprisonment in a Time Stop trigger this? Imprisonment has a projectile, so it doesn't land during the Time Stop. But it's touch-range, so there's basically no travel time; that mage walks right up to you before casting, and then casts their next spell without any further movement. So both spells land at exactly the same time, and the bug happens. What can be done to avoid this? Tweaking mage AI so it doesn't cast Imprisonment twice on the same target during a Time Stop - after all, it's not only what triggers the bug, it's also obviously dumb.

If it's happening when the creature dies, it's not the random treasures. Random treasure tokens are resolved (or fail to resolve) when the item is created; either the creature holding it spawns in, or the area with the container is first entered.

Already in. // tbd, cam (from jmerry) // npcs spawning/moving on impassable terrain (see also baerie.dlg, aeriej.dlg, ar1000.are) COPY_EXISTING ~ar0800.are~ ~override~ // Graveyard District, Stein LPF ALTER_AREA_ACTOR INT_VAR y_coord=1071 STR_VAR actor_name=Stein END BUT_ONLY

A very odd decision, given the existence of LICH_FEAR and its significantly different effects than DEMON_FEAR in the unmodded EE. SCS ignores LICH_FEAR in favor of its own clone of DEMON_FEAR (identical except for name) entirely. Also, if you install the mage component (which builds dw#licfi) before/without the fiend component (which builds DEMON_FEAR) on a game that this bug applies to, there's nothing to copy. That can't be good; the best possible result is a spell that does nothing. So that's an internal dependency that needs to be cleared up... ... but yes, the "dump in override after installation" option doesn't really work. The file I uploaded needs to overwrite the one in the stratagems folder before installation in order to handle this bug.

Which ... demon fear already exists in unmodded BGEE and BG2EE, and it has four effects. None of which are EE opcodes - just panic and the cosmetics. OK. So what does SCS do to that spell? First, if the spell isn't already present, install it. Copying from the resource folder for the fiend component. Next, it sets a "don't be cumulative" effect. Opcode 206 immunity to this spell, for 5 seconds (Original fear duration = 12 seconds). This is irrelevant, since there aren't any effects on the spell that could stack anyway. And that's it. Well, looks like it's the fault of that one resource file SPIN890.SPL. Which is new in v35; it didn't exist at all in v34. That SPL has the four effects of the original. Slightly modified, to make it hit as level 9 instead of level 0. Then it has an instance of opcode 324 at the beginning, to grant brief immunity to this spell if the creature has spellstate 129. And then it has 58 identical instances of opcode 328, setting spellstate 181 for 144 seconds. Just ... what? This nonsense has to be the work of runaway code. All of these added effects are EE-only opcodes. For something that will never come up in an actual EE game, because EE games already have the spell. So ... uh, here's a simple fix for the demon fear crashing bug: just use the version of the spell that's in the base EE. Attached here; overwrite the instance in stratagems/fiend/resource before installing. Or overwrite the file in your override folder after installing Incidentally, demon fear is relatively mild as these effects go. Two round duration, no extra effects beyond the fear (so stacking isn't a problem), and no save modifier. Lich fear and demon fear are worse, with ten-round durations, THAC0 penalties, and -4 save modifiers so they're more likely to hit. SPIN890.SPL

Well, your second block should definitely have InParty(Myself) as an additional condition; if you dismissed him after the first block ran but before the second (which, since they won't run on the same pass through that script, is at least possible), you'd stutter-bug him with forced dialogue that didn't change the conditions for its activation. Wait, APPEND? Oh, that's your problem. That command simply appends your BAF script to the BCS file. Which makes that part of the file complete nonsense; here's what last few lines of rasaad.bcs look like before mods: 36OB 0 0 0 0 0 0 0 0 0 0 0 0 ""OB OB 0 0 0 0 0 0 0 0 0 0 0 0 ""OB OB 0 0 0 0 0 0 0 0 0 0 0 0 ""OB 0 0 0 0 0"" "" AC RE RS CR SC BCS and BAF are not the same formats. You need to compile the BAF code as you add it in, not just stick it on unmodified. Use EXTEND_BOTTOM instead, which compiles the code as it adds it in. Now, why did your first block appear to work? That, most likely, is an indication, that you didn't actually use "OWR_phaere" in the conditions for the addition you made to the dialogue file. You might need to look closer at that part too.

SCS doesn't create new difficulty levels; it merely renames the existing difficulty levels. And the old bonuses/penalties for those difficulties remain in place. The damage scaling can be disabled in the options menu, but everything else sticks around because it's hardcoded. Easy/Basic: Party gets +6 luck, hit die rolls are maximized, spell learning rolls automatically succeed. Normal/Improved: Hit die rolls are maximized, spell learning rolls automatically succeed. Core Rules/Tactical: Nothing. Hard/Hardcore: Nothing. Insane/Insane: Nothing. Legacy of Bhaal: Insane, plus everyone outside the party gets massive boosts to level, HP, saves, THAC0, and AC. Cannot be switched to or switched away from in gameplay. Story Mode: Easy/Basic, plus the party gets 25 STR, their attacks hit as +5 and deal additional acid damage, and they're immortal with a bunch of immunities. These bonuses actually aren't hardcoded; they're applied in scripts through the use of the "OHSMODE" family of spells. If you want some level of SCS difficulty without the accompanying hardcoded difficulty effects, you can use the fine-tuning option for that.

I don't know what bears were like before. In the unmodded EE, their base speed is approximately the same as a standard humanoid's. With this component, the base speed of bears is approximately half that of a standard humanoid's, but that speed doubles either when they get mad (for wild bears) or permanently (for bears that don't change allegiance, like summons or Wilson. The net effect is that most situations you deal with bears will see them at about the same speed they are in the unmodded EE; this component's main effect in the EE is to reduce the speed of wild bears when they're not hostile. (The bug this thread is about: the permanent speed-boosting effect placed on Wilson is cleared by death and resurrection, so he comes back slow) There are no circumstances in which a bear will outrun a humanoid PC, unless that PC is slowed somehow.

Exactly. The standard procedure for making a Mac installer creates two files; a tiny text file with a .command extension, and a no-extension binary file which is a copy of the WeiDU executable. For context, the *nix operating systems store information about file types in metadata, rather than an extension - so those extensions are optional. I only care about the extension of something I create if I intend to share that file.

The warning is harmless. However, you should uninstall that component; it's meant to fix minor issues with the vanilla shapeshifts, and you have a much more thorough overhaul already installed (SCS #2040 for wizard shapeshifts, SCS #4030 for druid shapeshifts) which fundamentally changes what those spells and abilities do. With my component installed over that, you'll have inaccurate descriptions and likely worse. ... You know, I think I'll add a "forbid" condition and enforce the incompatibility for the next version.

Balancing. It would be far easier to include sorcerers than to exclude them, as trueclass sorcerers and trueclass mages use the same ability table. As it is, it requires some complicated ability design to grant the abilities to mages without also granting them to sorcerers.

So the empty step script is unnecessary; you can just run the EXTEND_ operation without checking for whether there's a script there already. But you should still read what's in that script field rather than blindly overwriting it.

Areas may, under some circumstances, have scripts that don't match their resource ID. It's not usual, but it does happen; the four elemental rooms in Durlag's Tower all share the same script AR0507.BCS, for example. Your best bet here: - Open up the area file and read what's already there in the script field. - This may be empty or not be a valid script. For example, AR0165 in BGEE (a generic tavern in the big city) has AR0165 in that field, but there is no AR0165.BCS script in the game. And I don't think EXTEND_TOP works on an empty script. So we run a FILE_EXISTS_IN_GAME check, and create a new blank script if the area doesn't already have a script; here's some code from a component of mine that does this: // The "script" variable is defined earlier by reading at 0x94. PATCH_IF (NOT (FILE_EXISTS_IN_GAME ~%script%.BCS~)) BEGIN WRITE_ASCII 0x94 ~%areaID%~ #8 SPRINT script ~%areaID%~ INNER_ACTION BEGIN COPY ~jtweaks/resource/baf/empty.bcs~ ~override/%script%.bcs~ END END // If no area script exists, create an empty one. Use area ID as resref. WeiDU has a CREATE action, but it doesn't support BCS files. So I built an empty BCS file (6 bytes); I'll attach it to the post. - Now that you have a script file - either one that already existed, or a new empty one - you run your EXTEND_TOP on it. Also note: when extending the top of a script with unknown contents, it is strongly recommended that you use Continue() in all blocks of your extension. Failing to do so will break any blocks using the OnCreation condition. Alternately, you could just extend the bottom of the script instead and not worry about this. empty.BCS

Right, a bit of testing. For bears that get a permanent speed boost, it's done with timing mode 1. So, I rigged up something to test opcode 126 with timing modes 1 and 9. Second round. First time I created the effects without a target, so they didn't do anything. Anyway, the effect with timing mode 1 was cleared by death and resurrection. The effect with timing mode 9 remained after death and resurrection. So, to cover the circumstance of bears that can be resurrected because they're in the party or something, this component should use timing mode 9 instead of timing mode 1 for those bears it permanently boosts the speed of. That's the actual bug here.

So, the thing about that component? The very first thing it does, in the current EE, is to approximately halve the base movement speed of all bear animations. Once that's done, it applies effects to double their speed; always for shapeshifts and bears that are always friendly or always hostile, only in combat for bears like the wild ones in BG1. So, basically, it doesn't actually make any bears faster than they are in the unmodded game. It makes non-hostile wild bears slower, and that's it. Wilson should get a permanent effect that sets his base movement speed to 8. Which is close enough to the party member standard. But if he somehow loses that effect, he'll revert to the reduced base speed (4) of the animation. Recommended solution: don't install the "faster bears" component in the current EE. It just doesn't do anything worthwhile.

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.