DavidW

I say again: You can do it at the console: check the readme.

Noted, thanks. Will check.

It's unintentional. It shouldn't be showing up in-game, though.

It's not intended, and I'm a little unsure how it's happening. I'll take a look and see if I can reproduce it.

You're right, of course. Fixed locally.

That icon is just the generic Identify icon (spwi110c.bam), it's not anything specific to SCS.

No more info to offer, sorry. Those were my offhand thoughts on the subject, not the abstract to a well-worked-out thesis. My main concern about reliability is that I don't really trust people to reliably work out the preferred install order for mods, including their own mods, so I'm unconvinced this will converge on truth rather than ending up messy or self-contradictory. But I'll be happy to be proved wrong.

It's just the Water Weird model, not a new one.

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.