DavidW

Not sure why I said 'arcane casters'. SCS arcane and divine casters use IWD spells (and SR spells). I don't use every added spell, but then I don't use every vanilla spell either.

Cool, thanks. I'll look at it.

OK, got it... no, probably not. The combinatorics just gets too demanding.

I don’t understand this, sorry.

You can do it at the console: check the readme. if the button has vanished, probably there’s a UI mod you’re using that it’s not compatible with. (If so, I’d appreciate knowing which one.)

Their spell choices are generated dynamically and will be different on the OP's install than on mine, and their scripts likewise. (Though it's unlikely there's a corrupt SCS script: that would show up on installs more generally.) S/he could look at their memorized spells in NI. (I guess, actually, that it could also be a LoB thing. SCS isn't much tested on LoB. But there are lots of people on the Beamdog forums who play SCS+LoB, so again, I doubt it's a straight SCS bug rather than a compatibility issue.)

This doesn’t happen with SCS alone (I’d have heard about it) so this will be some kind of compatibility issue with your other mods. (Maybe a broken spell; maybe a broken creature file.) You have a LOT installed, which makes it a bit tricky to give suggestions though.

Looks pretty useful. A couple of comments: -SR doesn’t include (most of) the the IWD spells - IWDification isn’t listed. - SCS does let arcane casters use IWD spells, but that’s not really part of its added spells exactly. It supports several spell systems: its own version of the IWD spells, IWDification’s version, SR.

Advancing level-by-level is fairly systematically built into the component (that was actually the original purpose of building it). Dual-classing a character part-way through the levelling process is going to cause some trouble though. It's just very hard to handle inside this framework. I'm not 100% sure what would happen to be honest (unless they're one of the specifically marked-for-dualling characters, like Imoen or Anomen.)

There's quite a lot of auto-levelling in the unmodded game (especially in EE) - but it's a bit ad hoc, and I'm not sure how it works systematically. On your suggestion, do you have in mind that NPCs level to your own level when originally recruited, then just gain XP normally? That's probably achievable. I'll think about it, it's a good idea. (In the development of the component, I did the auto-levelling first and then added the customization quite late after I realised it would be quite an easy addition, so I haven't really thought much about getting the customization without the auto-levelling.)

The restrictions are entirely about technical limitations, not balance. This is a horribly complicated component under the surface (there are more than 400 spells being silently applied in various places to make it work) and it's already the case that most of that complexity is there because of the complications caused by dual-class characters. I'm not sure what you're after is even technically possible but at the least it would require another huge increase in technical complexity, and I'm not interested in the amount of work it would entail and the inevitable bugs that would arise. I'm not sure what you mean by 'multi-classes can already be boosted in levels for free' - they should be being boosted to about the total same XP level as the PC. If that's not happening, it's a bug. But as for 'unintended use', it's not 'unintended' on moral grounds, it's 'unintended' because it will break the levelling system. Dual-classed characters like Anomen carry specific flags telling the system that they're really dual-classed; those flags will get badly confused if you don't follow the dual-classing instructions. (Though the Sarevok example shows that this isn't the whole of the issue, and there may be no really satisfactory solution here.) Incidentally, I'm interested why - putting aside dual-classing issues - you think the component breaks balance? (You might be right, but it doesn't do it intentionally.) I suppose it permits illegal race/class combinations, but those are there as an idiosyncracy of 2nd edition AD&D, not for more systematic balance reasons.

If you recruited Anomen, did not change his class using the customize option, but also did not dual-class him to cleric as you're told to on-screen, you will break the levelling system. (I'm still not quite certain if that's what you did, but it sounds like it.) Likewise Imoen (whether or not you apply a kit to her before levelling her.) That's not an intended use of the system: it's there to let you choose the features of the character that they had before dual-classing. If you ignore the instructions, it's on you, though I accept that the instructions could be more insistent and that it would be nice to actually enforce the requirement that you dual-class them in-game

Sensibly robust code on an EE install ought to be checking for 319... but I don't know if it actually does in extant mods.

There's nothing wrong with it as a playstyle, but it won't work technically. Anomen and Imoen are set up as dual-classed characters: the autoleveller is just giving you the chance to choose their original-class abilities before dual-classing them. (It auto-levels their original class up to the level at which the original-game character dual-classes.) If you ignore the in-game instruction to dual-class them and just keep advancing them, you're going to see exactly the problem you describe, because the auto-leveller wants the class that's active at the start of the game to be adjusted to match your own level. If you actually want to customize them so that they adventure with you for a while as their original class before dual-classing, use the customizer option to delete their dual class and respec them as a single-class character. In any case: the issue with Anomen and Imoen isn't a bug, then, though I'll see if I can make the 'you must dual-class' instruction a bit more clear and/or compulsory. The issue with Sarevok is a bug, though.

On EE, can't you use opcode 319 to disable weapons that you don't want thieves to use, but which can be used to backstab? I haven't checked, but I doubt the engine checks 319 when seeing if backstab is possible.

I didn't see this discussion when it originally got posted (we had a new baby at the time). I have some doubts about whether this will really work, but putting them aside: my main thought is about the categories. As written, they're fairly player-focussed: 'kit', 'tweak', 'NPC', 'AI' and the like. But if you're writing a machine-readable system, I think you can do better than that. An illustration: AI mods. That's a perfectly sensible category for players: SCS falls into it, so does Tactics. But Tactics basically just dumps a bunch of BCS and CRE files into the override (I simplify, but only slightly) SCS needs to go at or near the end of an install order, but that's not because it's an AI mod; it's because it dynamically responds to resources already in the game. (e.g., it edits many CRE files according to what equipment they have, so trouble occurs if a mod gets installed after SCS and adds or modifies a CRE file). The minimal version of this is that you need a category 'dynamically-responsive'. Some mods that look quite different from a player's point of view will go in that category, and mods (or mod components) in that category will need to be installed after mods that aren't dynamically responsive. A more ambitious version would move from categories to tags: a mod with a responsive_to_kits tag would need to be installed after a mod with an add_kit tag. (I'm unsure if that's really viable though.) One other note: I don't think UI-Patch is a good category. UI patching is a technique mods use, not a feature of a mod. SCS patches the UI, for instance.

OK - no, that's definitely not intended. I'll have a look at how that's happening.

So, with Anomen: did you keep levelling him as a fighter once you joined the party? There's supposed to be text instructing you to dual-class him once he's finished levelling after being initially recruited (I can't enforce that you do so).

I realize this, but it's still live code, and it still makes WEIDU v246 sluggish on SCS.

Well, in that case I'm confused again. If LABELs carry the tp2 name of their parent mod, and that tp2 name changes when the component is moved, then I can't at al see what the point is. @AL|EN?

OK: I think I'm being confused by Lauriel's original post, which suggests that the mod tp2 name ought to be part of the LABEL. That was the bit I didn't understand, given that the tp2 name is inferrable anyway. If the point is just that you want global uniqueness and so a modder prefix, that makes more sense. Is this correct: PI is using LABEL as metadata PI's syntax is not restricted as WEIDU's is to checking LABELs only of a particular mod, so LABELs can follow a component even as it migrates between mods (and should not be changed when a component migrates). For that reason, it's helpful for LABELs to be globally unique. (And use of modder prefix is the standard way to do it.) In fact, it would be helpful if people use globally unique LABELs (hence modder prefixes) even for components that have no prospect of being migrated (e.g., SCS's 'Smarter Mages') because otherwise they might trespass on some completely different mod's LABEL namespace and cause PI to get confused. For modders with more than one mod, it would be helpful if they can make sure that their own LABELs are globally unique, and that they don't use the same LABEL in two mods. Modder prefix alone won't do that; including the tp2 name is one way to do it. BUT if you include the tp2 name in a component LABEL you should absolutely leave it unchanged even if you then migrate the component into a different tp2. OK, I think that's a reasonable ask. (It's mostly moot for me for the moment because v246 slowdown means I can't use LABELs with SCS.)

Let's see if I understand this correctly: your main character has around 4million XP. Sarevok is in the party You dual-class him He immediately jumps to 4 million XP, without having to work for it. Is that correct? If so, I think I can see how that could happen. (It's not terribly straightforward to fix but I can think about it.) I'm less clear how this could happen with Anomen, given that he starts dual-classed. Did you change his original class and dual-class him later? The time taken to uninstall is unavoidable: that's how all BG2 mods work. The components are installed in order; to uninstall one, all the ones installed later have to be uninstalled and then reinstalled.

I’m afraid I still don’t understand this. Even if you’re getting LABEL to double as metadata (which I’m not convinced is a good idea, given that it ties metadata to something that also has a functional role in WEIDU, but I can see the elegance) then you can perfectly well get PI to treat the metadata as the concatenation of tp2 name and LABEL entry. Why try to get global uniqueness through asking people to do it voluntarily, when it’s in your power to do it automatically?

Do you mean that Project Infinity is also using LABEL as metadata? Do you have a link to documentation? - I'm not sure how that would be supposed to work, and insofar as I can guess, I still can't see how a modder/tp2 prefix inside the LABEL would be helpful. (After all, PI could just add the tp2 explicitly if it wanted to - it's lifting the data from the tp2 file, after all.)

I think there's a reasonable best-practice case for using LABELs. (Indeed, LABEL is my idea - I originally suggested it to Wisp's predecessor as WEIDU maintainer, in the long ago of the world). Basically that it insulates against changing component number. It's somewhat complicated by the fact that WEIDU 246 has some runtime overhead with LABEL that's a bit painful in something as complicated as SCS, which is why I don't use it myself. (I coded it a couple of years ago and then reverted it when the runtime overhead got too annoying.) I believe WEIDU 247 may improve on this, in which case I might rethink. I don't think there's a best-practice argument why the naming format for LABEL needs to take any particular form. Any WEIDU-legal check for a label is a check for an ordered pair <tp2 name, label_name>, so label_name is, by design, inside a namespace local to your mod. And the reason for prefixes is to avoid naming conflicts within a shared namespace. So label_name doesn't need modder prefixes.