jmerry

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.

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.