subtledoctor

Neither here nor there but there are actually three invisibility-dispelling opcodes. 47 and 116 are identical, while 136 is slightly weaker. Plus you can dispel the ILLUSIONARYPROTECTION sectype with opcode 221. And for good measure, there is opcode 160 to remove Sanctuary.

It's something that I've thought about for a while. At some point I went through and looked for what is dispellable but not breachable (e.g. Fire Shield, Acid Sheath, Blade Barrier) and what is breachable but not dispellable (e.g. Moment of Prescience). Those may be the only ones; I don't really remember but they are the ones that stick out in my mind. Fire Shield/Acid Sheath are an interesting case because they have characteristics of both specific protections and combat protections. Further, they plus Prismatic Shield/Blade Barrier are admittedly different from other combat protections in that they are not really "protections." More like passive offenses. But Moment of Prescience IS a traditional combat protection... OTOH I get why it shouldn't be dispellable because it is not a magical effect covering the caster, but simply knowledge in their head. Fire Shield/Acid Sheath/Blade Barrier all currently have the "OFFENSIVEDAMAGE" sectype... I don't know whether that is needed for some purpose or scripts or something. That would at least explain the weirdness. But IMHO they should all be both dispellable and breachable. TBH given Moment of Prescience's description as a divination, and given its spell level and short duration, I kind of think it should NOT be either breachable or dispellable. In a real sense there is nothing to be "breached." EDIT - in any event you can expect to see these changes added to my "SD's Random Tweaks" mod very soon. EDIT2 - @morpheus562 that may have been a typo from me copying/pasting the macro... it works fine in my mods but of course that's where I put more time into checking the syntax and testing the results... anyway good to see you've got it running.

My mods will be using marker files forever, as I’ve seen nothing that can replace their functionality. But I guess I will be using marker files and LABEL and DESIGNATED. Sigh.

IIRC Blade Barrier is not Breachable either. You’re just supposed to tank it or bomb from range. (I hate that too.)

Huh. I never knew how that worked in SCS, and even now that I know what I'm looking at, I can't really follow DavidW's code. So a subspell is created for each spell with an animation to be suppressed, and the spells with animations to be suppressed is taken from a static list? How then does he handle stuff like the vanilla Spell Shield and Spell Deflection, with hardcoded animations? Looking at this, man it would be nice if there were an opcode to cancel animations instead of just to protect from them. (Though I guess we said the same thing about canceling spells for 15+ years, and here anyway we can use the workaround of running animations through subspells...) So I guess if SCS is already installed, then we can simply make our own subspells with animations for each of our changed spells, and simply hook our subspells into DW#bldha and DW#hdani. Should be doable. TBH I'm not sure that's true... or at least I'm not sure the descriptions written up recenly by Mike should be the authority as to the mod's intent, and we should be changing the mod's function to match those descriptions. It's going to take some digging through forums threads to answer these questions definitively, but: I believe the descriptions of Spell Thrust/Secret Word stating that they will remove Dispelling Screen are in error, and that Demi/Kreso intended DS not to be taken down by MAGICATTACK spells I'm pretty sure Demi/Kreso intended for Fire Shield & Acid Sheath to be unbreachable, and in fact not removable by anything except Dispel Magic (I hate this, I think they should be breachable, but that's my recollection of the modder intent) I vaguely recall that allowing PfNW and PfMW to stack was intended, and in fact Demi talked a lot about turning PfMW into a straight "Pro. from All Weapons" spell... though I don't remember how that discussion ended up. Generally the whole "you can wack a PfMW mage with a simple stick" tactic is something only the player can do, and Demi wanted to preclude such imbalances, which argues in favor of PfMW blocking unenchanted attacks Neither here nor there, but temnix did something quite interesting in teasing apart weapons' "+x" characteristic from their "enchanted" status; this allowed adding +x values to monster claws based on hit dice, per PnP, while bringing PfMW closer to its PnP function by only protecting against magical weapons. Quite clever, and a nice buff to e.g. shapeshifted druids... but unfortunately it means monks and mid-level summons would rip right through all but the highest level SCS mages, making them pushovers. If PfNW were to include animal claws then stacking the two defenses would suddenly become an interesting proposition... but I don't think SCS would stack them in any event so that's out the window. The whole PfMW quandary is still a thorn in my side, all these years later. I hate that spell so much.

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.