subtledoctor

All of this discussion makes a lot of sense for IR proper as well as IRR. I don't know the best way to package it: In IR itself As an optional component in IR As a component of a different tweaks mod like my SD Random Tweaks As an independent little hotfix ...but it should be trivial to write up something to patch them and Gorion, to add/remove the robes respectively. Frankly I lean toward #1 - as noted, Demi made IR for BG2, when even things like Tutu and BGT were not really stable or widely used. There are many instances of things not lining up quite right with BG1 filenames - e.g. a bunch of BG2-only strings, or the handling of the Ring(s) of Wizardry. I think he would approve of adjustments that make the mod work better on BGT/BGEE/EET.

I don't remember which bugs you are talking about. There are some pretty major bugs in the 5E casting conversion mod. I believe I have fixed them all (and then some) and those fixes required modifications to, like, five other mods. (MnG, FnP, SoB, NPC_EE, and this one). They will also require a change to CDTweaks, for which I'll have to set up a pull request. The 5E changes require serious testing... I just don't have much time to do in-depth testing these days. (If you - or anyone else! - have the time and inclination to run tests, I could send you the latest versions of everything.)

@Bartimaeus You don't happen to have a list of those .CRE filenames, do you? (Narcilicus, the Thayvian guy, and the guy in SS)

Ya. It’s basically all 8 innate cantrips (with 1 or 2 substitutions) from a single item. Benefits: 1) you get all 8; 2) the mini missile is cast as a weapon attack instead of a spell, so you can “set it and forget it;” and 3) it doesn’t gum up your innate abilities bar.

Yes, it would. I think there’s a way in NI to add a new string there, but I’m not very familiar with it. No, that one’s on me. Probably the string changed in a game update, and I haven’t looked at that code in like 5 years. The 2 newer cantrip options seem so much better to me, I’m always surprised at how many people opt for the junky innate version... sorry!

Works just fine with 2.5

Ah, I understand better now. Thanks!

@Grammarsalad wrote that component, IIRC when the game was on patch 1.3. It’s not my code to change, and I wouldn’t know how in any event. Might need to just skip it unless/until it gets updated...

Uh, since when is Caelar an SoD NPC? Edit - okay I see, you can sometimes recruit her for the last six minutes of the game. Still, AFAIK nothing in SoB messes with character levels. It’s been a while and I do recall being concerned about that, once upon a time. But I have updated the mod (a lot) and now I make NPCs comport with the proficiency system via dialogues and innate abilities. I’ll take another look to be certain, but I think Roxanne is describing an obsolete version of the mod from like 2 or 3 years ago... This. This gives you a peek at how Roxanne bases decisions on incorrect information, for no good reason other than that she refuses to have simple conversations with modders. Instead we have to engage in this ridiculous game of Telephone to solve problems. Seriously, that old BWS rip-off is a bad habit that you should kick. And her forums are a morass of misinformation. Embrace PI, it’s more up-to-date and AL|EN works really hard on it.

I have not heard of any such incompatibility... sounds like nonsense. I have played SoD with comp 122, it worked fine; it was standalone SoD, not merged in EET, but I can’t think what the difference is. Seems like another instance of Roxanne being wrong; or else another instance of Roxanne finding a bug but not telling modders about it, and thus preventing it from being fixed. I would ignore it unless you find more concrete information.

Scales of Balance. There is still some MR, here and there. But not as much. SCS should be fine, as it’s a purely passive attribute. The actual spell is left in, so players and SCS can still use it.

Correct me if I'm wrong, but does this refer to what mages do after they've run out of spells? Because if so, I still maintain that 1) I don't think I've ever seen an enemy mage run out of spells;* and 2) if an enemy mage runs out of spells you can give them the most amazing script in the world, they are still a dead man walking. So who cares how fast or in what direction they walk? * EDIT - although now I think about it, I use a mod that gives all wizards unlimited 1st level spells, so they can pelt you forever with Magic Missile or Larloch's Minor Drain etc. Upon reflection, this seems to be a much better solution than scripting them to charge my heavily armored fighter with a dagger...

Dammit, this is making me want to fire up Morroblivion...

And of course this very much includes Bethesda. I actually still play Morrowind semi-regularly (though, in the Oblivion engine ) and while it is pretty dense, a lot of its density comes from packing in fetch quests. Literally "go collect muck from the edge of a pond, and bring it to me." You fetch muck.

These are okay. To be more specific, I am trying to replicate the inability to cast arcane spells in armor, with my 5E casting conversion mod. The way the mod works is: there is an innate ability corresponding to every arcane and divine spell. You select which spells to 'memorize' and the next day the innate abilities corresponding to those memorized spells inhabit your spellcasting button, in a number determined by your 'spell slots' - which is tracked via a stat value. When you cast one of those innate abilities, it: casts the appropriate spell reduces the stat value to mimic expending a spell slot casts a subspell with 172 effects that remove every innate ability in the system casts another subspell that grants you the innate abilities corresponding to your memorized spells, in a number matching the new 'spell slot' stat value While a bit processor-heavy, the system works well, essentially allowing you to prepare spells like a mage but cast them like a sorcerer. However, opcode 145 can no longer be used in armor, because I would have to block innate abilities with it - which would be bad. Instead I'll hook into the casting system: when you equip armor, it casts the 172 spell to remove all innate abilities corresponding to arcane spells it will carry a 206 equipping effect blocking any arcane-related innate abilities from being given to you in step 4 above (in the event that, say, a cleric/mage in armor casts a divine spell) when you remove the armor, we want the innate abilities relating to your memorized arcane spells to reappear under the spellcasting button. That last part is the tricky bit, because the engine does not generally register removing an item. We don't have to worry about which innates reappear; that is already handled by the spellcasting system. (Specifically, removing the armor should cause all innates to appear... but the ones that you don't have memorized are blocked by 206 effects.) And we don't have to worry about recharging the abilities, because that is already handled by the system that tracks your spell slots. A single uniform spell will be enough to be triggered by all armors, and will correctly handle all casters with all possible combinations of memorized spells and all possible current spell slot values. All of that works wonderfully. The issue is simply, how best to trigger the casting of that spell by removing a piece of equipment.

I'm pretty sure those are additive. The Proficiency Overhaul gives fighters extra 1st-level proficiencies if they are smart (only for simple proficiency, not specialization - the idea is, smart fighters can use lots of weapons tolerably well); the Stat Bonus Overhaul gives fighters more opportunities to increase their specialization (not just proficiency) in more weapons, over time. This also lets you specialize at level 1, which is an advantage over dumb fighters if you use the Proficiency Overhaul. I think.

Hey!

Is this basically a Windows version of symlinks? (Btw I don't mean that to sound critical - MacOS also (needlessly?) has its own version, called "aliases." Sigh.)

Is there a best way to do this? Let's say, for instance, that I want certain items to remove an innate ability. Say, if a paladin equips an item, it will remove your Lay On Hands ability. But if you unequip the item, you get it back. Off the top of my head, the item could: op172 remove the innate ability, timing mode 1 op206 vs. spellB, timing mode 2 repeating .eff applying effA effA uses op146 with delayed/permanent timing to cast spellB after ~3 seconds SpellB uses op171 to give you Lay on Hands So the item keeps trying to give you the ability back, but you are immune while you wear the item. But a few seconds after you remove the item, the spell successfully fires and you get your innate ability back. I think that should work, but am I overthinking it? Is there a better way? EDIT - boy, I'm rusty with this stuff...

...then consider that the prior generation said the very same things about you. Try to catch pieces of your brain as the force of the sudden perspective explodes your head. Face it, these things peaked with Kid Icarus Pitfall.

Nope - enemies can see you when you can see them. As a fun (?) experiment, make a “Close Your Eyes” mod that applies blindness whenever you use an innate spell. You will be able to ‘close your eyes’ and then sneak right up next enemies. Or, as I said, you can ‘close your eyes’ while in melee and then hide, and your enemy will lose track of you - because you can’t see them.

The fog of war is there for the sake of showing the player what can be seen; it is of no use for the AI. If the concern is “when is the player visible to enemies,” I think the answer is “when enemies are visible to the player.” At least for some mechanisms. So e.g. if you reduce a PC thief’s vision or blind them, then they can Hide in Shadows right in front of an enemy. Alternatively, if you extend a PC thief’s vision, they will be unable to hide, and can trigger enemies to attack from well beyond what we normally think if as the enemy’s range of vision. If the concern is how to determine the distance at which enemies react to this or that, my guess is it will largely come down to how they are scripted (see SCS’ “Better Calls For Help”), but if the scripts involve the See() trigger it will likely depend on the visual range of the PC being seen - not any characteristic of the enemy itself.

Do you think Wes Weimer wrote that warning though it didn’t happen once? Yes, I’m making an assumption, but it’s one I’m comfortable with. If I needed to modify with INNER_ACTION a file currently being patched, I would. But if there was a way to code it that avoided even the slim possibility of this problem, and it otherwise works as well or better... then I would write it that way.

Yes. Sometimes. Look at me rejoicing.

I vaguely recall this being a general issue, because EET cannot actually modify the MacOS executable. So the solution is not necessarily to direct it to the proper app executable, but rather to simply skip the .exe patching when installing on MacOS. (Or maybe it can modify the MacOS executable, but it definitely cannot modify the iOS executable... I had a version of RC11 or RC12 with appropriate code commented out such that EET could be run on iOS, but that was over a year ago, dang if I can find it now... )