subtledoctor

For other reasons, I once asked about this possibility. In my case, I was actually willing to make the player give up all of the kit abilities already gained, truly wipe the slate clean and then to dual-class. Unfortunately, even in such case, the UI cannot trigger such a renunciation. All the UI can do is, upon hitting the dual-class button, take you to the class-choice screen and then the kit-choice screen. And if you already have a kit, it won't take you to the kit-choice screen. The UI has no mechanism to remove your kit in the middle of that process. What you could do, is create an innate ability and give it to every single-class character, which wipe away your kit in preparation for dual-classing. But it cannot be rolled together with the dual-class process itself. And for the effort, you could as easily just do it in EEKeeper.

It's been solved. I'm not aware of any remaining bugs along those lines. (The only issue I'm aware of at the moment is: I need to look at how these HLAs work depending on whether the player sets their HLAs to be spellbook spells vs. innate abilities. It's been in the back of my head for a long time but I haven't heard any complaints from users, and it's been working well for me. Plus, you know, RL issues have kept me from putting much time into this stuff. The long and the short of it is, apart from a few fixes I've made, the individual abilities work exactly as they did in v3.31. Everyone has always seemed happy with them so I have not messed with them.) (EDIT - the only other thing I want to look into is trying to improve SCS compatibility, seeing as the latest versions of SCS do not include overt changes taking Refinements into account.)

Sure thing. And even if it doesn't work, then we can conclude that it is something inherent to the status of having invisibility detection by script. Which would be bad, but still a very good thing to be aware of!

TnB has a bunch of abilities for specialists, described in the new and improved Readme, that are similar in tone but different from the 5E abilities (because those are designed for tabletop narrative game, while ours are designed for BG). If you have suggestions for more/better specialist abilities, we are certainly open to hearing them! TnB specialists can also convert their spell slots to spontaneously cast any spells from their chosen school. Specialists in the 5E system will get free access to their school spells without having to prepare them, which is basically the same as spontaneous conversion but with a much easier UI mechanism.

Proposal for alternative implementation of the Weapon Proficiency Overhaul: How about if you get combat bonuses for specializing in weapons, and the APR bonuses operate from specializing in fighting styles? This way, for instance, fighters could be competent in a lot of weapons, and be expert with a couple - say, long sword and bastard sword. If they are in a position where they have to use a morning star, they will not be as proficient but they will at least keep their nice fighter APR because it is a 1-handed weapon. (Dual-wielding style could be an exception: you could get APR bonuses from single-weapon style, and points in dual-wielding could improve the style's defensive benefits. Maybe also differentiate DW thac0 penalties by weapon size, and specializing in the style would allow you to 1) effectively dual-wield heavier weapons, and 2) get a bette defensive boost from doing so.) Not sure where that leaves ranged weapons... Thoughts?

@DavidNYC I glanced at the stuff, this is practically already written! I'm inclined to break it down so that one component is just animation changes, and exclude the functional tweaks (e.g. whether Dispelling Screen gets removed by MAGICATTACKs, etc.) to a separate component. That way someone can get the benefit of the animations but still choose whether to use your functional rules, or the SR one, or the SRR ones, or the SDRT ones. As far as SCS stuff... I think if this is installed before SCS, then it should all fall into place. SCS will clone spells that already have these modified animations, and will apply its invisibility function to these new .VVC/.BAMs. ...Right? EDIT - here's my rough plan: Component 1: 'Make Magical Protections More Distinct and Recognizable' PfNW PfMW Prismatic Mantle Moment of Prescience Absolute Immunity ProMissiles NonDetection Deflections/Trap/SotA Dispelling Screen MGOI/GOI Fire Shield/Acid Sheath Spell Shield Storm Shield Mind Blank Disable Ioun Stone animations so as not to conflict with these Probably set all these animations in a single go. (NB there is a bit of a conflict between SR's "Storm Shield" and SCS/IWD's "Storm Shell." Both can coexist, but it seems like they should be collapsed into one spell. I will probably handle this separately in my own mod, though.) I know you have this geared toward SR+SCS, but at least some of these could be independent. I'll think about how much effort it's worth to support non-SR games. Component 2: 'Varying Color Glows & Pulses' I see what you're doing here, but I'm not sure how extensive this needs to be. I might leave it aside until I have wrapped my head around the extent of it. Component 3: 'Bubb's Mirror Image Transparancy' EEex-only, so broken out into its own component so players without EEex don't need to worry about it. In an effort to avoid using READLN, I would probably just offer a couple optional SUBCOMPONENTs, with 51% transparency and 80% transparency, or something like that. Component 4: 'DavidNYC's Functional Tweaks' Nondetection: Prevent Nondetection from stacking Nondetection add 206 vs. True Sight, Detect Illusion, and Faerie Fire Set power level of Nondetection so it can be removed by MAGICATTACKs Make Nondetection dispellable Set MSD spellstates for Nondetection Dispelling Screen Set Dispelling Screen to SPELLPROTECTIONS sectype Set Breach/Dispel Magic to 321 remove Dispelling Screen Fix dispel-on-hit items to work with this version Fire Shield/Acxid Sheath: Set to SPECIFICPROTECTIONS sectype Moment of Prescience: rename back to Improved Mantle

While I definitely see this as a valid option and some people like it, in the context of SR having True Sight apply 'Invisibility Detection by Script' is a MAJOR design decision, which would be undercut by this change. I really think it's worth figuring out whether the issue you discovered is something about the interaction between opcode 193 and opcode 69, or inherent to opcode 193. If it's not too much trouble to set up a test, install my Revised Invisibility component from Tome & Blood on top of SR. My mod eliminates opcode 69 from the equation but otherwise works the way SR does. Then see if a mage with True Seeing will correctly target invisible enemies with your scripts.

I don't know what they are...

Don't really see the point. Your STR stat is still 18... why should one person with 18 STR be able to carry 398 lbs, and another person with 18 STR only carry 202 lbs? 18/exceptional STR is just a dumb rule, end of story. If anything I regret making two categories within the 18/__ range. It should just be, plain 18 is this, 18/anything is this plus a little more, and then 19+ progresses beyond that normally.

If the Tweaks components were broken out into proper functions in their .tp2 file, I could just call those functions as long as the Tweaks mod folder was in the game directory at the time; but as it is, it would require copying and pasting a bunch of code that 1) I didn't write; 2) I don't have permission to copy; 3) I don't necessarily understand; and 4) may be subject to changes and fixes in that mod, and then the code in this mod would be out-of-date and buggy, and I may not even know that or be equipped to fix it. It's not a route I'm comfortable going down. The best solution would be for someone to take a long hard look at the stuff in Tweaks Anthology, as far as whaat component need to be installed when, and maybe break it down into two or more mods that can be set at different places in people install order lists. Or Tweaks could incorporate more code that specifically looks for and works with aspects of this mod. I can write that code (it's only 8 lines) and make a pull request, but Tweaks would have to vet it and accept the request and publish a new release. Don't hold your breath. I'm working on an ad-hoc solution. But there's only so much I can do. If players really want to get things right when installing lots of mods, ultimately they're going to have to pay close attention and jump through a few hoops. If they don't, it's going to be their problem.

I was going to post and say this is a bit over my head, but I just came up with a real-world instance of what I don't like about this. I am working on a 5E ruleset conversion thingy. Right now it has one function covering each spellcasting class. There is a single component in the .tp2 file, which looks like this: BEGIN ~Convert Everyone to 5E Spellcasting Rules?~ DESIGNATED 100 LAF 5E_mages END LAF 5E_bards END LAF 5E_clerics END LAF 5E_druids END LAF 5E_paladins END LAF 5E_rangers END Now, as I iron out the kinks and make it possible for parts of this system to coexists with or without other parts of the system, I would like to add more optional components: BEGIN ~Convert Mages to 5E Spellcasting Rules~ DESIGNATED 200 LAF 5E_mages END BEGIN ~Convert Bards to 5E Spellcasting Rules~ DESIGNATED 300 LAF 5E_bards END BEGIN ~Convert Clerics to 5E Spellcasting Rules~ DESIGNATED 400 LAF 5E_clerics END BEGIN ~Convert Druids to 5E Spellcasting Rules~ DESIGNATED 500 LAF 5E_druids END BEGIN ~Convert Paladins to 5E Spellcasting Rules~ DESIGNATED 600 LAF 5E_paladins END BEGIN ~Convert Rangers to 5E Spellcasting Rules~ DESIGNATED 700 LAF 5E_rangers END Now, I want to make Faiths & Powers compatible with this. So I want to add a check: are clerics in this game using a 5E spellcasting system? That can be implemented by either component 100, or component 400. If I could add a single LABEL to each class-specific component, and add all six LABELs to component 100, that would be helpful. As it is, that will not work. I have to have a different LABEL for clerics being modified by component 100 vs. clerics being modified by component 400. Now, I get that LABEL will be reliable and static even if the DESIGNATED numbers change. And that's an advantage. But, it is the only advantage, and LABEL doesn't let me omit DESIGNATED numbers - I still need those to control component install order. So LABEL is extra work, with only the slightest bit of extra utility. And I keep coming back to this: marker files seem like they accomplish everything LABEL does, and they let me simplify the compatibility check. So... why would I not use marker files again? Clutter? My override directory has over 100,000 mod files in it... a few dozen marker files that ensure cross-mod compatibility does not really add meaningful clutter. Sorry to re-hash that, I know it's been discussed before. I'm just still not sold, I guess. As for how to name LABELs: seems pretty clear to me: Weidu cannot and should not enforce particular unique naming practices. For any modder who cares about what they are making, using your modding prefix in your LABELs is an obvious way to guarantee it won't conflict with any others. Some modders may not do that - some jerk may add "unnerfed_spell_tables" to his thrice-redundant tweak mod - but if you use your modding prefix in your tweak mod, you will protect yourself from such jerks. (And needless to say, if any asshole uses someone else's modder prefix in their LABELs, then their shitty mod will be banished to the hinterlands of Baldur's Extended Butt.

No worries! I didn't realize what you were talking about, I didn't think about what the spells were doing with stats. (I think some of the stat stuff doesn't show up on my installs, because I am on the EEs and some of the spells might be using spellstates instead there. Maybe. Anyway, NBD. If your scripts are targeting the EEs, you can patch the spells with spellstates, instead of messing with the stats that may be used by Detectable Spells. There is an "add spellstate" macro here at line 55: Add that somewhere early in your .tp2, then you can do this: LAF resolve_spellstate STR_VAR new_state_id = ~dispel_screen_state~ RET new_state_ind END COPY_EXISTING ~spwi510.spl~ ~override~ LPF ADD_SPELL_EFFECT INT_VAR opcode = 328 target = 1 special = 1 parameter2 = %dispel_screen_state% timing = 0 duration - 120 END ...repeated for each relevant spell. Then add checks for the spellstate in your scripts to avoid casting the spell when it is still in effect. (There is room for about 100 mod-added spellstates, and various mods add about 20-30 in total, so of course don't do this a hundred times. But if doing it 10 times or helps to improve your scripts, then there's no reason not to.) EDIT - you can also do this with old-fashioned stats, using higher values in some of the Detectable Spells stats, but 1) that means using opcode 233, which is a bit more finicky, and 2) some Detectable Spells scripts treat the stats as binary and use dumb checks like "IF stat > 0" (which is immensely wasteful because those stats can have several billion numerical values or 128 bit-equality values, but that's a different conversation), so if a Detectable Spells spell sets the stat to 1 and your mod sets it to 9, they may get confused. Spellstates are limited in number, but cleaner and more reliable in application.

That is an index finger, sir. We don't wag middle fingers around here.

Ah, it's a mistake of terminology. Detectable Spells has nothing to do with spellstates, the DS library was written before spellstates were invented in the EE engine. Spellstates only cover one byte, with 255 possible values, each assigned to a single spellstate. Each spellstate can thus be set, or not set. They have no numerical values. Detectable Spells uses various proficiencies, which can be set to different values. I would NOT mess with SR's Detectable Spells stuff, without the advice of someone knowledgeable like Mike or Ardanis or DavidW. I just glanced at the scripts thread, and it already has a Weidu installer. So there's no reason it shouldn't patch things there to make its own product work better. Just a question of ACTION_IF (FILE_EXISTS_IN_GAME ~dvsrv4here.mrk~) BEGIN COPY_EXISTING [dispelling screen] ~override~ LPF ADD_SPELL_EFFECT INT_VAR opcode = [et cetera] END

Spellstates are binary - they only have a value of 0 or 1. So I'm not sure what he meant by the 9. But as far as setting that spellstate: it could either be perfectly harmless, or it could slightly mess with SCS if SCS AI scripts detect and react to it. (Because, as we've said, the appropriate reaction to SI:Abj is different from the appropriate reaction to DS.) Honestly, I don't think it's worth changing things or setting spellstates in this mod for the sake of the tiny fraction of people who might use those player scripts. No offense intended! It's just a question of who should bear the burden of compatibility, and adding code to SR that will be largely useless to most players and when we're not 100% sure of the consequences, seems a mistake to me. I mean it should be simple enough to wrap those player scripts in a simple Weidu installer, and then little tweaks can be added for the sake of compatibility, like patching Dispelling Screen and Mage Armor to set a spellstate. Nothing is standing in the way of that happening.

5E-style spellcasting, not 5E-style multiclassing. And it does not affect druid/sorcerers at all because oh wait I see what you're saying. Well, the short answer is, this is only 5E casting for arcane spells (so far!) cast by bards or the Arcanist kit (so far!) and does not affect druids (so far!). And n one of this affects sorcerers at all; they still use fully spontaneous casting of a limited amount of known spells. This system is a replacement for the way Vancian casters cast spells. (Now, there may or may not be a multiclass cleric/mage sitting in one of my test savegames, who uses this system for both arcane and divine spellcasting. But we're not going to talk about that right now. Such a thing would be fairly complex, and would have to interact with various pseudo-sorcerer and pseudo-shaman multiclasses, which use a similar-but-distinct-but-parallel spellcasting system that lives under the same UI button. So the long answer is, it would take some time to work out the kinks in those sorts of interactions for a putative game-wide casting conversion mod.)

Sweet. I just finished major work on four of my mods. I'll take a look at this when I can. Should be pretty straightforward, unless I'm missing something.

Okay, I've made some major updates to the mod, mostly to the bard-related stuff. It is now at version 4.10. The code for the 5E-style casting system has been completely rewritten and turned into a series of portable functions, which can be used on a per-kit, per-class, or game-wide level. (More about that later.) This system is now much more robust for the MnG bards, with quicker installation, better compatibility, and better in-game reliability. You no longer need to "initialize" your bardic spellcasting in-game; instead you will see your spellcasting button go dark and then be reenabled within a few seconds of starting the game. (Some non-spellcasting bard kits like the Herald or Whistler might need to initialize their bard songs... but most bards will not.) If you do not want to deal with the 5E-style spell preparation and casting, then you can disable it in the "might_and_guile/d5_MnG_settings.ini" file. If you turn off 5E casting (which must be done before you install the mod!) then you will get the multiclass bards with the new bard song system, but normal 2E-style wizard spellcasting. Finally, if you don't like the new multiclass bards and prefer the normal 2E Bard class, but you are intrigued by the 5E-style casting system, there is a new component at the end of the mod that will let normal bards (including the MnG normal bard kits and all other normal bard kits, except for the one from Aionz's Shadow Magic mod) use semi-spontaneous 5E casting.

Okay I've made a relatively major update, to v0.9.6. First, the Readme is greatly expanded. Check it out, it has lots of important information, especially about the new stuff. Small stuff: There is now a settings file, "TomeandBlood/qd_TnB_setting.ini." The first use of this file is with the Improved Identify spell: it changes Identify to a 2nd-level spell by default, but you can edit the settings before installing to set Identify to whatever spell level you want. (Maybe you want to keep it at 1st level, etc.) The Revised Invisibility code is slightly changed, in ways you hopefully won't notice, apart from this: "Nondetection" is renamed "Protection from Divination" to better reflect its actual function. The new familiar choice icons are reduced and should hopefully look normal now. Bigger stuff: I have completely rewritten the back-end code for the Arcanist kit, turning it into a series of portable functions that enable 5E-style spellcasting on a per-kit, per-class, or game-wide level. (More about that later.) The Arcanist generally works more reliably, and will not require in-game "initialization" of its abilities, and will not have its memorization slots or casting slots messed up on leaving and re-joining the party. When you start the game just wait a few seconds, you will see your "cast spell" button go dark and then be reenabled. This will happen every time you rest, as well. Further, instead of having casting slots controlled by static code, the Arcanist's casting slots are determined by a normal-looking spell table, found at "TomeandBlood/data/arcanist/d5cstarc.2da." By default this table roughly matches a Dragon Disciple's casting slots, but you can modify the table before installing the mod, and the kit's spellcasting slots will follow suit. The same system governs the spellcasting slots for multiclass sorcerers, but they rely on the standard MXSPLSRC.2da table. So Multi Sorcerers can now have their casting slots match vanilla sorcerers - AS LONG AS and changes to that table get made BEFORE you install multiclass sorcerers. I know it's a pain to install a little bit of Tweaks Anthology before TnB and the rest of Tweaks Anthology afterward... but for best results, that is necessary. The "Make Bonus Spell Slot Items Work with Arcanist/Multi Sorcerers" component will now reduce all bonuses from each item to +1; so for example the BG2 Ring of Acuity will only give +1 2nd-level slot instead of +2. There shouldn't be many such changes, and they are minor; in return, these items will be consistent across all kinds of casters, whether traditional mages and sorcerers or multiclass sorcerers or new 5E-style casters like the Arcanist. The two "double spell slot" items I'm aware of - the Evermemory ring and IWDEE's Kontik's Ring - will have that effect replaced by an item ability that, once per day, restores all spell slots of the relevant spell levels. This ability, too, works consistently for all of these different kinds of casters.

Smallish update to v5.29: A bit of text updates, changing the "Fencing" style to "Single-Handed Style" since the former was a bit polarizing. And the ability score-based bonus spells are updated opn the back-end, to conform with the latest systems in Tome & Blood and Might & Guile.

All by itself? Maybe 20-30 minutes. With a hundred other mods installed beforehand? Could be upwards of 2 hours. Which is quick - back in the days of v28 and earlier, it was more like 6 hours. It’s no less true for time than money, you get what you pay for.

You could just remove all of the effects from ND, then load up a save and see what happens... that might suss out the issue.

And they are targetable with II but no ND? My gut says it's something to do with opcode 69, if that's the case. (Though I've been wrong before. This game engine is wacky.) Which would mean this problem is already solved by my mod. (Though, it could create other issues, like Nondetection becoming too strong... at least against priests. Their only counter would seem to be Faerie Fire. ) What happens in SRR with someone has Nondetection and you cast Invisibility Purge? EDIT - it might also be something wacky about the "invisibility detection by script" effect. IIRC this is generally applied in-game to enemies, and those enemies will generally make physical attacks. Maybe this only supports scripted targeting for physical attacks? Anyone recall whether there are enemies with scripted invisibility detection who cast spells? Maybe some fiends? Will they successfully target a player with II + ND?

With vanilla spells, you simply cannot target an enemy who has II + ND. (Heck, you can;t target an enemy who only has II - ND doesn't even factor into it.) So I'm not clear on what you are comparing here. I have definitely had occasions when I turned on player AI by mistake, and one of my characters started attacking an invisible enemy. So invisible enemies can definitely be targeted with SR installed. (In fact that is partly what caused me to go out and make my own invisibility tweak mod.) I don't know whether that enemy had Nondetection cast... probably not. So maybe adding Nondetection into the mix can screw with player scripts? But if so, it sounds like it is something, as you say, "at the opcode level." I can't see how SR could be causing it; SR doesn't really change Nondetection. The only thing SR does to Nondetection is add an opcode 282 effect, setting the value to 3. I have no idea what that is for - I assume it is something to do with Detectable Spells?

I should mention, if there is "going on at the opcode level preventing scripts from appropriately targeting enemies" with ND and II, then it is hardly an issue with SR. If that's really the case, then I would guess it is something hard-coded about Nondetection. The way the game treats invisibility and nondetection has always been screwy. If that's the case, then you might want to look at what I've done with Tome & Blood. It changes Nondetection into "Protection from Divinations" - closer to a true replacement for SI:Div. It does this by adding an opcode 205 effect, blocking spells with the DIVINATIONATTACK sectype. (It also adopts SR's use of opcode 193 for See Invisible and True Seeing, so a caster with True Seeing cannot remove the protected person's invisibility (or Mirror Image etc.), but can still see and target that person. With opcode 205 in place, I suppose there is no need for the vanilla "nondetection" opcode 69. So the lastest master of TnB, just uploaded now but not yet set as a "release," eliminates the opcode 69 effect. If opcode 69 was indeed interfering with player scripts, then maybe they will work better with the TnB tweaks.