Bartimaeus

Thanks. I do have it written down in my to-do list.txt along with a few other items, so it should eventually get done...eventually. End of summer is a busy time of year for me.

Also, most of the Infinity Engine file types are relatively simple but proprietary: files taken from other games, even if they have the same file extension (e.g. ".eff") are not actually going to be the same file type or be in any way compatible with the Infinity Engine games (or vice versa). File extensions are helpful indicators of what a file is supposed to do, but they do not have anything directly to do with what the file actually is or its intended use. I could change a .jpg to a .txt and opening it up with an image editor would still open it as a .jpg image file because that's what it is regardless of what the file extension says, and so you can see how many different file types formatted in completely different ways for distinct intended purposes can use the same file extensions.

I don't play on the EEs, but noted, will remove (though that abbreviated install list is really just more meant to be examples of different kinds of mods and where they should be placed and not any kind of definitive list or anything). I personally still use the following components and don't feel as though I've run into substantial issues with oBG2: ~POLYTWEAK/POLYTWEAK.TP2~ #0 #85 // Corrected Vampire Stats: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #100 // Anomen: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #150 // Cernd: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #202 // Jaheira -> dual wielding: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #300 // Keldorn: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #401 // Minsc -> Keep Minsc as ranger: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #500 // Nalia: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #600 // Valygar: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #700 // Viconia: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #60 // Improved (less buggy) trolls: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #70 // Improved Umberhulks: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #80 // Improved Yuan-Ti: v2.00 BWP Fix ~POLYTWEAK/POLYTWEAK.TP2~ #0 #83 // Improved Minotaurs: v2.00 BWP Fix Regarding the topic at hand, I really don't think IR or IU should ever be used together in the first place due to some pretty grave conceptual incompatibilities. Not really terribly different from using IR and Improved Anvil together - they just don't mix and you're going to get some pretty wacky results if you nevertheless try to do so.

From what I can see, SCS more or less implemented the fixes I suggested, it's just that the component is still disabled in setup-stratagems.tp2. While I haven't had issues with it in my setup, DavidW clearly thought there still were and which that needed to be ironed out first, so I make no guarantees of its efficacy if you re-enable it.

Eh, not really - it's kind of a useless warning, to be honest. If a user can't combine the folders, they'll have to post in the thread for help; if a user doesn't realize the folders didn't combine correctly, they'll have to post in the thread for help. Pretty much the same result either way, and it's usually pretty obvious what the issue is as soon as I see the actual error that some essential file is missing entirely. Still, I figure the warning there is good to have nevertheless. Oh, cool, glad to know there is a way to do it. I know Luke here at G3 at one point ran into the same issue but was able to start solving it themselves, perhaps they figured it out the same trick. Thanks, I'll provide a link to your comment in the original post.

Yeah, it's why the original post has this warning near the top: "If you are on a non-Windows OS, make sure that the two folders are combined: if the "change-log.txt" file still exists in "(game directory)\item_rev\", then you should be good - if it doesn't, post in the thread for help." I am kind of against having a pre-combined folder easily downloadable as the default option, as there have already been issues of users mistakenly posting issues about IRR/SRR in regular IR/SR threads and not realizing there's any difference between the two; a pre-combined folder that doesn't make users go through this annoying process of downloading both and combining them would only make that worse. I am okay with mildly annoying users and manually providing combined folders when needed if it means a higher likelihood of IRR/SRR-related discussion staying localized to these threads and the relevant GitHub pages. I realize that's a bit of an odd stance, since usually you want to make ease of installation as easy as you can for both current and prospective users, but in this particular case where my mods unofficially "hijack" the official versions, I think it's appropriate and necessary.

The file "item_rev\lib\descriptions.tpa" does not come with IRR, but rather the base IR package. That file being missing would probably suggest that your IR and IRR folders were not combined correctly, but rather the IRR folder completely overwrote the IR folder. Here's a pre-combined folder that should solve the issue: https://dl.dropboxusercontent.com/s/jrv5ufx44mk7gsq/IRR for MacOS.zip

@pochesun Yes, probably, but I'll need to put aside some time for testing myself at some point.

Here's what I have: https://www.mediafire.com/file/g19jt89vxo62z52/infinityanimations-b5.7z/file It comes with the animations I use already in the correct folders (hence why it's so big), but if you use options that I don't, then it may be missing something and I'm not certain where to get them. The options that I use...

@pochesun My understanding of curses is that they are supposed to be relatively immutable (i.e. their effects are not able to be overridden). So while I don't disagree that this should be implemented differently, I unfortunately don't believe that there's really any avenue for doing so. I can have drinking the goblet "protect" the character from the various sources of Resist/Remove Fear, but I can't do anything about a Cavalier's immunity to fear, or immunity to fear given by an item, or about a character having cast Remove/Resist Fear before even using the goblet. Full immunity to the opcode used for morale break is given out by many sources, and there's not really anything you can do to get around it. Also, I find it a bit odd that this "curse" only lasts for 12 hours instead of being active until broken by Remove Curse, though admittedly, if I were changing how this goblet works, I would ideally want to make it so that the effect matches the description: instead of simply being "your character runs around in circles the moment you use the goblet", it would be "you have control of your character...until they get into a fight and then they go run around in circles until the fight is over". With regards to Melf's Acid Arrow, in my opinion, Protection from Acid should not protect against the physical damage of the arrow. That is, after all, the point of including a physical damage component and treating the spell as if it were a real projectile shot at the target (even subject to the effects of Protection from Missiles and other sources of missile deflection). I wonder if the same issue applies to Flame Arrow and Protection from Fire? Given that Melf's Acid Arrow is a single target spell, it is not really necessary for Protection from Acid to explicitly protect against it in the first place - providing immunity to the acid damage via acid resistance is adequate. Most likely simply an oversight on the part of IR if this issue only applies to the green scrolls that IR modifies. With regards to where bugs are reported, I do not mind if bugs that are actually IRR's fault are reported in the SRR thread or vice versa, especially if it's not immediately clear which one is at fault, and this was obviously one such case. Really, all I ask is that people report them here in one of my threads so that I can actually see it in a timely manner, as opposed to e.g. GitHub, where if someone makes a proper Issue thread for something, it might take me weeks or even months to notice it. Thanks, about fully back now. It's been a while since I got a booster, but it ended up being less worse (although still pretty unpleasant) relative to the first time I got it which was shortly after having received a booster. Viruses be wack, yo.

This is more or less what the process should look like on Windows: https://dl.dropboxusercontent.com/s/ei6s6w4v88tw1hm/firefox_dBdZ4pjqvb.mp4 Some .exes can be opened as archives (as they are actually just archives themselves with some embedded self-extracting executable), and that includes the (majority of) .exe downloads from G3 and Spellhold Studios. However, you can substitute that with just "installing" the .exe normally if you wish.

I am currently dying of covid, I'll return to this in the days to come (or if I forget, go ahead and re-ping me).

Yeah, for IR items that already started with damage reduction before installing Revised Armors (e.g. Orc Leather), I specifically made hacky workarounds for them, but if using Revised Armors with other mod-added armors installed that do the same, I wasn't sure how to fix it. @Alywena I tested it out while removing my hacky workaround stuff and it seems like Orc Leather and the Drow armor now correctly update, though there's still the peculiarity of the descriptions double-stating their distinct physical resistance bonus. That could probably be fixed by some regular expression hackery after the fact for at least items installed by the main component, though... Thank you for identifying and fixing the core issue!

Thanks! I apparently fixed this on June 4th, so luckily it's already taken care of. The spell was getting its string updated, but it had been set to update to the wrong .tra string (23002 instead of 23004). As for Melf's Acid Arrow, I can't confirm what you're experiencing on BG2EE: https://dl.dropboxusercontent.com/s/43ud5yzzs35pgol/Baldur_ZHz2JblnR6.mp4 Not pictured here, but I also set it to max (instead of just 101) and had Jan Jansen cast it as well, same result.

Assuming you have ToBEx installed, it works the same way as it does in the EEs. Helmets always grant critical hit protection, unless they have the critical hit protection toggle flag enabled; other item types never grant critical hit protection, unless they have the critical hit protection toggle flag enabled. In other words, if you want an ioun stone or the Mask of King Strohm to protect against critical hits, make sure the toggle flag is disabled.

Yeah, Imoen's Wand has its own item code distinct from the normal Wand of Magic Missile and thus may have different properties. IRR changes her wand to be the same as the normal Wand of Magic Missile, but I've never much loved this either. Perhaps the best solution would be to restore its ridiculous amount of charges (100?), change it back to one missile, and then change its name to "Imoen's Wand of Magic Missile" or maybe even just "Imoen's Wand" while specifying one missile in the description. I'm not too much of a fan of ToB myself, but I do like Watcher's Keep, so that tends to be the end of my playthroughs in recent years. I'm particularly sensitive to any issue of needing to rapidly pause/unpause many times for something to work after having played through all of BG1:EE in multiplayer recently and needing to pause a lot turning into a huge pain in the butt (that and the EE multiplayer being just kind of buggy and horrible in general).

I wouldn't install either IR or IRR to a game already in progress. When you go into a new area or open a store or come across a certain creature/character for the first time, an "instance" that saves the state of those objects is now included in your save file, and those instances will never be replaced no matter how many mods you install or uninstall, so proceeding to do so can be a dangerous affair. One example of this might affect you installing IR is that IR moves around a number of artifacts - if it takes an item from an area, creature, or store that you've already come across and puts it somewhere you haven't, it will result in duplicates. The opposite can happen as well: if it takes an item from something you haven't come across to somewhere you have, that item won't ever exist in your currently ongoing game. Well, it fires 3 missiles instead of 1 like it used to, if I'm not mistaken. Wand of Magic Missile's strength lies in the fact that it is usable by everyone. Firing 3 missiles can be e.g. a cheap and easy spellcasting disruptor used by someone who wouldn't have any spells/abilities queued up otherwise, probably a thief or fighter. Robe of "Vecna" (Larloch in IR) only gives a +2 bonus to casting speed already (and also relocates it to the tail-end of Watcher's Keep, on one of the seal guardians...Azamantes, I think is their name). You know, I kind of both like and hate the idea of wands being able to do multiple targets, but I think the fact is that the capability is simply not handled very well in the BG engine. Once you activate it, you have to stay on the character without selecting any other characters or accidentally clicking any other buttons while rapidly pausing and unpausing to use all of them. The effect being that you use it and then immediately unleash all of them in an obnoxious flurry of pauses anyways - this setup would really only make sense for Wand of Lightning and Wand of Magic Missile, I think, and if I were implementing it, I'd probably limit it to three bolts instead of six or whatever. Interestingly, it's only in BG2 that this multi-target Wand of Lightning exists - in BG1, the Wand of Lightning did the same 6D6 bolt that IRR uses (though not with as severe of a saving throw).

This reminds me of back in WarCraft 3, some modders would use an "optimizer" that stripped all indentation and comments while changing all their function and variable names to combinations of "i"s and lower-case "L"s, so everything would look like "function IIiliIliI" and "function illIiIlili" and so on. Was always a blast to trawl through such "optimized" code - losing just indentation seems quaint in comparison.

One bolt that does 6D6. It's the same as in vanilla. Actually, apparently I just set the property of these robes back to the exact same property as vanilla, as that's exactly what they did there. I never saw a great way of handling these "of the Apprenti" items. No, it basically hijacks the normal IR installer. Yes, I believe so - if ALMRP is installed before IRR. If IR is installed after said mod that changes the Rod of Lordly Might, yes. As for throwing spears/javelins, there are three such enchanted spears: Impaler, Talos' Fury, and Spear of Lordly Might. I intended to add javelins to stores at some point through Store Revisions, but...there's a number of things that are a work in progress with that. Go into item_rev\components\main\items.2da and delete the entire "ROD_OF_WONDER[...]" line before installing IR. To more closely match the spells they're imitating. Additionally, IR decided to limit wands' charges to 10 instead of the old...what was it, 50? So it makes sense to make them stronger, but I would agree that it can unfortunately be a little problematic for BG1. It can be a difficult balance to strike between the two games.

Are you sure? The poison opcode uses type 3 with the interval being 3, which should mean 1 damage per 3 seconds, i.e. 2 damage per round.

Doing it by sectype is how SRR has historically handled it as well. It's not the most graceful solution per se, but it's alright and does work across all games.

1. I don't believe it's specific to SCS. The AI can see invisible creatures when it has opcode 193 applied to it (exactly how it behaves as a result of being able to do so...may not always be consistent, but it can). This creates an awkward situation where the player expects Non-Detection to protect them from, well, divination spells used to detect invisible creatures as per the current description of the spell, and are not actually afforded that protection; meanwhile, if the AI casts the combination of Invisibility + Non-Detection, they are protected from the player's divination spells. So not only is the AI's behavior/reaction erratic at best, but the AI gets an advantage out of it that the player can't. I find this rather untenable and certainly very undesirable on both grounds, especially after having just tested BG2EE and being instantly smashed to bits by cheating AI. 2. In my opinion, Non-Detection should provide protection from detection. That is, after all, the name of the spell, and presumably what Demivrgvs intended when he left it called "Non-Detection" (as opposed to something like "Protect Your Other Non-Invisibility Illusionary Protections"...well, hopefully something much more concise and fitting than that) while specifically having it immunize the recipient against the effects of invisibility dispellers such as True Seeing and Detect Invisibility (not to mention having the description of Non-Detection explicitly say "[Non-Detection] makes the creature touched undetectable by divination spells such as Detect Invisibility, Oracle, and True Seeing, or by a thief's Detect Illusion abilities"). I do not personally know how much Demivrgvs tested opcode 193 or whether he was aware of it behaving unequally between player and AI (or if he believed it to be acceptable or not), but given that he is not presently here to argue for its case anyways, it truthfully matters very little to me at this exact moment. Though if someone wants to dig up his argument for it, if it survives to the present day somewhere publicly readable, then I would be very interested to read it. 3. However, SCS assumes installations with SR (and SRR) will require either Detect Invisibility or True Seeing to cast through improved invisibility (and does not use its normal "anti-magic spells can always pierce improved invisibility" setup), and thus I feel that my hands are tied, given the obvious importance of SCS in the BG modding ecosystem. Furthermore, in order to fix at least the AI being able to "cheat" seeing through your invisibility when the player cannot do the same to them, I would have to let Detect Invisibility and True Seeing actually dispel invisibility (but only invisibility, not improved invisibility or anything else!), which is not only a bit annoying to implement, but is also a change of how these spells function. The current situation is that only AI spellcasters who cast Detect Invisibility or True Seeing can see through invisibility, but if I were to attempt to make it 'fair' for both player and AI, Detect Invisibility and True Seeing (and maybe Invisibility Purge?) would actually reveal those invisible characters to everyone else. That's quite a bit of a change to mull over. And good lord, how the hell am I supposed to explain these mechanics in the descriptions of these spells so that players can have a possibility of actually understanding how any of this works? They're already pretty convoluted as it is, and apparently I need to add even more! 4. In effect, I think using opcode 193 is just kind of a bad idea and would prefer the SCS/EE approach at this point, but I cannot really do much about it unless the official version of SR decides to make a change as well, which I do not believe is going to happen. 5. ...Maybe it's possible to do a mass-scan/patch of all .bcs files looking for that particular condition and replacing it with the non-SR equivalent, but that's certainly not an ideal place to be. A lot of people use automated installs these days, and requiring people to add another random mini-mod way after SR/R is installed to fix broken behavior is really just not fantastic, even if it's not my fault. And that's assuming it's always going to be easy to replace, which I am not sure of either. I did try that, and anyone who's played SR/R should have run into this exact situation at some point and seen what happens. Even so, there is a very crucial difference between asking about how something works (i.e. asking me to test it, or explain it if I already had)...versus leaping to wrong conclusions about something which wasn't being discussed (no big deal, we all make mistakes in communication, both when we ourselves write and when interpreting others!), then suggesting that I was the one at fault for misspeaking and leading them to those wrong conclusions (I was not), and then shifting the goalposts as if the first option, that they were just 'asking' that it be tested, was what had actually happened in the first place...all the while making snide comments about how I was the one having some kind of attitude issue here. No, sorry, the conversation started out perfectly harmless, and I tried to be as inoffensive as possible given the circumstances, but I've had quite enough at this point. This is the absolute last I'll say of the matter.

Yeah, that's what I'm finding out now. Well, this really seems to be a "you made your bed, now lie in it" kind of situation. From that OR, it looks like the issue applies to both Detect Invisibility and True Seeing? Which would mean I can't implement my secondary idea either. Well...if I want it to be fully fair and functional, I guess the only thing to do is have Non-Detection...you know, protect everything except for the invisibility/stealth state. Which is like, the complete opposite of what one would envision the spell as doing. Sigh.

Yup, your version has the wrong line endings (CRLF instead of LF). But if it's the fault of your Git client, then that's a relief, as I was about to turn into the Joker. Can you easily work around it? Not sure what I could do on my end anyways. Non-Detection would continue to shield Invisibility, Improved Invisibility, Mirror Image et al. from being dispelled until Non-Detection has been stripped, but True Seeing and Detect Invisibility would lose the "you can target a semi-invisible character with any spell" ability; instead, yeah, anti-magic spells would just always be able to target through the semi-invisible state. A few people have complained about enemy spellcasters already doing this when SCS is installed over the years, so it's quite possible that this is how SCS AI already operates (in that it assumes anti-magic spells should always penetrate the semi-invisible state and forces them to do so even if it shouldn't be possible), and if that's the case, then it really only just makes sense that the same ability should be given to the player. This would also make Non-Detection being a spell protection make way more sense than it currently does, as anti-magic spells which strip spell protections are the only spells given the unique "can target through the semi-invisible state", which makes them a natural counter to Non-Detection when it's a spell protection. I'm making an install right now to see if that's exactly what happens when opcode 193 isn't given by True Seeing/Detect Invisibility, though, just to be sure. If it's not, then a different idea will have to be used for sure. Even if it is how it works, it's not impossible that the function of Non-Detection could change to something better nonetheless, but I'm viewing the current way as too big of an issue to just let it be as-is. One quick-and-easy alternative would be to let True Seeing retain opcode 193, remove it from Detect Invisibility, and then just always have True Seeing strip the normal invisibility state regardless of Non-Detection (but letting Non-Detection protect everything else): that would at least make the system fully functional and fair.

Fixed, thanks! Did this actually full lock it out of scripted spellcasting, or just out of player-initiated spellcasting? Can't confirm, I just downloaded the live repository version, checked several .bcs files, and they all had the right line endings. I dropped the hobgoblin shaman script (spell_rev\spwi2##\dvhobsha.bcs) straight into my override, cast Monster Summoning II, and the shaman cast Resist Fear upon being summoned (which is what it's scripted to immediately do upon being summoned). Moved around, and all the hobgoblins automatically followed me. If none of that happens for you, could I have your dvhobsha.bcs so I can check it out? After re-reading my post, I just don't believe that I did. I'd be curious to see exactly what of was the key passage of issue in my recounting of events. My post specifically says my character cast Non-Detection and Invisibility (not Improved Invisibility, not Shadow Door) upon themselves, and that I had them stand next to Brother Pol with no mention of any hostile actions. Even if I had made any unmentioned hostile actions, again, only Non-Detection and Invisibility. I believe that would be because I wasn't speaking to you and it wasn't relevant to whom I was nor the issue at hand. The post to which I was responding to: The issue at hand being, "[...] the mage will cast Detect Invisibility or True Seeing, they'll gain the ability to see through invisibility, and they'll be able to target the invisible creature. Even if it's still fully invisible to everyone else. Whether it has Non-Detection active or not. Nothing protects against opcode 193, because it doesn't act on the creature being observed at all. For as long as that effect is active, that mage is equivalent to a creature that can naturally see through invisibility." The whole conversation gives some helpful context on what exactly was being tested here. But all of this is kind of irrelevant for SRR, which will be ejecting opcode 193 wholesale after I do some testing of SCS+SR behavior to ensure that the AI can dispel Non-Detection with anti-magic spells even when improved invisibility is active. If it can't, then some other measure will have to be taken.