Bartimaeus

1. Protection from Missiles is also way more powerful than vanilla's version of the spell, since it grants total immunity to all missiles rather than simply unenchanted ones. Still, one turn is pretty short...it's actually not the AI I'm worried about abusing it, but rather the player. Setting it to something like 5 rounds + 1/round level will make it last for quite a while if players use it at later levels, and once again, blanket immunity to missiles can be pretty strong when used for the right encounters. 2. Yeah, the waking on hit part of Greater Command isn't likely to change, since that's simply how the sleep status is supposed to function. 3. Uh...what makes you think the Cause Wounds series of spells offer a saving throw? 4. Slay Living: You really think a 5th level instant slay spell that's not subject to magic resistance should have no saving throw? It has additional damage if it fails. Contrast with Feeblemind, also a 5th level spell, which needs a -2 vs. spell saving throw and *is* subject to magic resistance.

Use the "Remove Disabled Spells from Spell Selection Screen" subcomponent to fix this. That's what it's there for, after all.

Those are disabled. See here: https://dl.dropboxusercontent.com/s/e7yj7nd5ujzlwfp/2019-07-17_02-53-02.mp4 ~SPELL_REV/SETUP-SPELL_REV.TP2~ #0 #0 // Spell Revisions: v4 Beta 16 (Revised V1.1.0) ~SPELL_REV/SETUP-SPELL_REV.TP2~ #0 #50 // Remove Disabled Spells from Spell Selection Screens: v4 Beta 16 (Revised V1.1.0) If they are not disabled, either you did not install the "Remove Disabled Spells" subcomponent or something else has re-enabled them somehow (overwrote hidespl.2da?).

Erik(.cre) uses AROW13, which are, as you said, dummy arrows. Still do zero damage with IR installed (including Weapon Changes). However, if you have Weapon Changes installed, then a Long Bow will give a damage bonus of 1. How much damage is he doing with those arrows?

Thanks! Seems relatively straightforward, actually. Much easier to manage than the web browser client.

Windows. That's the problem: Windows is case insensitive, github isn't, so when a github file is sw1h01.itm and I update a file from my machine that is SW1H01.ITM, instead of overwriting it, it creates a duplicate. If Windows wasn't case insensitive, I would notice locally that there is a duplicate, but I don't go through the item_rev\itm folder on github every time I update something to make sure there aren't any duplicates (especially seeing as there are a thousand plus files in that folder and it doesn't even render them all on the browser client). And since I do everything through the ever so painful browser client...

Thanks for the explanation. That's pretty cool, although...so I guess with that installed, Non-Detection does absolutely nothing against the mage/cleric with opcode 193, but continues to act as invisible (i.e. untargetable via spells or attacks) for everyone else?

A bit off-topic, but could you expound upon this point? I opened up the Tome and Blood readme pdf real quick to see if it mentioned improved invisibility and possibly see what you meant by this, but it did not.

I see somebody opened up an "issue" in github like two weeks ago, but I didn't notice because I guess there are no notifications for such. Thanks and merged. Now if only I could replicate the same thing on desktop so that this doesn't happen again, seeing as this isn't the first time this has happened...

Even better (and also more helpful if you've completely biffed your game), take renal.cre from your item_rev\backup\1030 folder and stick it in your override. That'll revert him to the last version of himself immediately before he got corrupted. Yes, he is fixed. His inventory was getting screwed up by an incorrect length text replacement that I actually already knew shouldn't be used like that, but simply overlooked from when I did it years ago and forgot to fix. I also looked for any other instances like that and believe there are no more.

It's a one-off speedbump for the character with Detect Invisibility/True Seeing, yeah, but nobody else. I think that makes it a pretty interesting protection vs. the other "harder" style of protections and counters that dominate the game, and it makes intuitive sense for something to do with sight - just because one character can see something doesn't mean everyone else should. If you want to reveal that character for the rest of your party, you have to dispel the Non-Detection/SI:Divinity, at which point the system becomes similar to the SCS system but in the reverse order.

Presumably to make it so that the spell system works. Before SR's usage of opcode 193 to allow an affected character to bypass the improved invisibility effect, a character affected with improved invisibility + SR Non-Detection or vanilla Spell Immunity: Divination was essentially invulnerable to normal spellcasters outside of a lucky Dispel/Remove Magic. You can't remove the improved invisibility because of immunity to divination spells, and you can't remove the Spell Immunity: Divination because of improved invisibility making it so you can't target them with anti-magic. It was a broken combination. So SCS made spells have an AoE effect that was often janky but allowed you to penetrate improved invisibility, and then the flag to penetrate improved invisibility altogether was discovered/made (...was this a ToBEx feature?) which made the AoE effect unnecessary. Doing it this way also made it fair for players if SCS spellcasters happened to use the same combination. I reverted it because I agreed with you, SR's way of doing it is better. But David didn't know about that opcode when writing SCS, and he says it would take way too much to change it now, which means SR and SCS are mildly inconsistent on this point. I tested a few different spellcasters with SR & SCS installed and, if I remember correctly, SCS makes them do the same amount of steps but in the opposite order. The player has to cast Detect Invisibility/True Seeing first and then use an anti-magic spell like Secret Word to dispel Non-Detection/Spell Immunity: Divination and consequently the improved invisibility; the AI will instead cast something like Secret Word first and then use an anti-invisibility spell. The advantage for the player is that they don't strictly need to dispel the Non-Detection since the Detect Invisibility/True Seeing allows them to start attacking the improved invisible character immediately with any kind of spells if they wish; the advantage for the AI is that they are not bound to the duration of Detect Invisibility/True Seeing, and can also use other spells like Detect Illusion and Oracle to remove the improved invisibility. So it is currently inconsistent, but kind of fair, I guess? On a side-note, I would not necessarily be against patching *all* spells to penetrate improved invisibility to be rid of this silly "you can't target characters with improved invisibility" mechanic once and for all. I've always thought it was a terrible mechanic especially given the inconsistency of single target vs. AoE spells.

Thanks for the heads up, fixed.

I think we had a discussion about it in the IR Revised thread a while back. I think I liked giving it either the strength bonus or like +1/2 APR, but nobody seemed to care that much probably because slings, after all, are supposed to be a weak category of weapons, so I didn't end up bothering.

Yeah, I wrote that in the SRR description with the specific intent of shedding light on the Improved Invisibility + Non-Detection mechanics (since Non-Detection's description in current SR is inaccurate in describing what it does and even more unhelpful in explaining how everything interacts), but people do actually have to notice that the description has been updated and read it, haha. On a side-note, I actually originally had it so that anti-magic spells all penetrated improved invisibility a la SCS...but @subtledoctor helpfully informed me of how things were *supposed* to be working in SR, and I ended up reverting it and rewriting a number of the relevant spell descriptions instead. Perhaps I should also provide a settings.ini switch or subcomponent that makes them penetrate again so that if you want it perfectly match SCS behavior, the option's there.

Glad to hear you solved it. Makes sense that it'd be Solaufein, given the age of that mod and the infancy of weidu modding when it was made!

Yeah, the BG Wiki does list it as Transmutation/Alteration, so that's not changed by SR, I guess.

@amitlath Uh, AR2000.bcs is the Trademeet area script. Don't possibly see how your game could be lacking it, seeing as how a whole lot of vanilla quest stuff in that area would be broken without it (including the Skinner, Mazzy Fentan, and Dao Genie questlines). My copy of BG2:EE certainly isn't lacking it. I'm unsure of what the "ERROR: cannot resolve trigger 0x40de" error pertains to. Doing some Googling, it seems like the two errors might be related, and that a critical identifier file, trigger.ids, may have been corrupted by a mod you installed, leading it to do...something. My quick and dirty suggestion would be to move trigger.ids from your override folder to somewhere else and test installing it again - if it installs correctly, then another mod would indeed seem to be the problem with it and I'd probably suggest doing a changelog on it to figure out the culprit.

The latest version of SR has it as Enchantment as well, and it's probably been that way for a while. Not an SRR change. Spell Thrust is Abjuration, Secret Word is Enchantment, Pierce Magic is Abjuration, Ruby Ray of Reversal is Transmutation, Khelben's Warding Whip is Evocation, Pierce Shield is Abjuration, and Spell Strike is Abjuration. If I had to guess, the rationale for changing Secret Word, Ruby Raby and Reversal, and Khelben's Warding Whip was probably loosely related to their concept, but more to do with balancing the specialist mages out a bit (...and making it so that Transmuters weren't completely anti-magic-less).

I've used that sort of setup for spells, but I hadn't considered that items with more than one extended header (or none at all) might also change the location. That #8 for 8 bytes is also very helpful to know. Thanks!

That's because I'm a dummy and didn't convert between a...variable(?) and...hex-text. Yeah, like I said, I'm not the best with weidu. Also, as mentioned in my edit above, it's probably not even a good idea to pursue my idea anyways due to the length being different. I am sure somebody who actually knows how to cleanly do it will help you - anything I know of is probably going to be a little hacky (and actually I want to know how a person who knows what they're doing would do it for my own future reference).

ACTION_IF (FILE_EXISTS_IN_GAME ~scrlw801.itm~) THEN BEGIN // SR Wraithform COPY_EXISTING ~scrlw801.itm~ ~override~ PATCH_IF (SOURCE_SIZE > 0x71) THEN BEGIN // protects against invalid files WRITE_BYTE 0x76 "ISCRL1R" END END This should write your icon directly to the file in what I think is the correct spot. (e): Although perhaps this won't work, because the "write_byte" command will only overwrite what you put in (I think), and since "ISCRL1R" is only 7 characters long vs. "SPWI603A", which is 8 characters, I imagine the "A" might be left at the end and effectively make your field "ISCRL1RA". I'm not sure how you define a blank space for that byte. A replace text command might suffer the same issue...except it might destroy the entire file as a bonus? I'm certain there's an easy way to do it, but I'm probably too much of a dummy with weidu to do it.

@grodrigues Fixed, thank you!

@Hoverdawg Apologies for the delay in response. ring30.itm is the Ring of Human Influence, and it seems you have the BG1 NPC Project installed, but are not in a BGT/EET setup, which I apparently did not foresee. Fixed and thank you!

Nice spot and it has been fixed, thank you! Also have fixed what @DavidW described here, so a thanks to him as well.