DavidW

A few questions:

Q: What does this do?

A: A certain number of creatures (7 in the classic option, 11 in the expanded one) are potential lens-bearers. The game gives up to 3 lenses to creatures that you haven't killed yet. (If you've killed all of them, there are no lenses and you won't notice this mod at all.)

Q: Which creatures?

A: In the classic option: Torgal, Mae'Var, Mekrath (it's actually in his treasure chest, you needn't kill him), Samia (in Firkraag's lair), a troll in the Troll Mound (near the druid grove), the Shade Lord, and the Unseeing Eye. In the expanded option: also Kangaxx, Layene (the Twisted Rune mage), the Alhoon in the mind flayer sewer hideout, and Koshi (in the Guarded Compound).

Q: How is it decided which creatures have the lenses?

A: At random. (This is about my only modification from the original version, which had a preferred order.)

Q: I hate one of those quests! What can I do about it?

A: Set 'skip_[that quest]' in dw_lanthorn.ini, before installing.

Q: When do I install it in my mod order?

A: Whenever you like, I think.

Q: Do I need to start a new game?

A: Yes, definitely. (If you want to hack it into an existing game, count up manually how many lens-holders you've killed and set the global variable 'LensPlot' to that number.)

Q: Which versions of the game does it work with?

A: All my testing is on BG2EE, but it probably also works on BGT, EET and BGII-ToB.

Q: Install time?

A: About fifteen seconds (in a welcome change from SCS).

Q: Any compatibility problems?

A: It's conceptually incompatible with the 'restored Lanthorn' component of Oversight, and with Roxanne's 'broken Lanthorn' quest. Other than that, not as far as I know: it's pretty compatibility-friendly, since it just reactivates code already in the game.

Q: Wait - Oversight already restores the Lanthorn quest? Why bother with this, then?

A: The oversight version doesn't really restore the cut Lanthorn quest so much as write a new quest inspired by the cut quest. (No dialog lines are reused, the mechanics are different, up to eight lenses might be present, Elhan doesn't mention the lenses, and the actual locations are different.) There's nothing wrong with the Oversight quest, but I was interesting in restoring the original one as faithfully as possible.

Q: Is this actually a good idea? Or did Bioware remove it for a reason?

A: I don't actually know. I was more interested in the technical puzzle of restoring it than anything else, to be honest. 

(I've written a very small mod that restores the extended Rhynn Lanthorn search from the beta version of Baldur's Gate II. I'm probably eventually going to roll it into either SCS or another of my projects, so I won't create a full forum space for it yet - I'll just put details here.)

The beta version of Baldur's Gate II contained a mechanic to expand Chapter 6 (the one where you are looking for the Rhynn Lanthorn). As well as the Lanthorn itself, the thief would have stolen several lenses and hidden them in areas around the game. The player would be given clues to where the lenses were, and would have to retrieve them before the Lanthorn could be used to enter Chapter 7. The lenses were actually placed in several of the stronghold quests that the player can explore in Chapter 2 (and if the player had already done all of those quests, no lenses would be placed). The idea, presumably, was to introduce a mechanic to bind the stronghold quests into the main plot of Chapter 6, just as the need to gather gold binds them into the main plot of Chapter 2.

This expanded Rhynn Lanthorn quest was removed from Baldur's Gate II before release (at a guess, because the clues leading to the lenses were a bit too gnomic for casual players, and there wasn't time to fill in the details.) But almost all the machinery of the quest is still present in the game - the scripts that place the lenses, the lenses themselves, and even the dialog lines that give the clues to where the lenses were. That makes it possible to reconstruct almost exactly how the quest worked.

This mod simply restores the quest. There are two options. The first ('classic') is almost an exact restoration of how the original version of the quest would have gone. The second ('expanded') increases the number of locations in which lenses may be found, to include four extra side-quest regions in the original game not tied to a stronghold quest. You can also customise the installation (via the 'dw_lanthorn.ini' file in the mod folder) to deselect any possible lens location you don't want to use.

Download links

Readme

Do it at the TIS level, not the PVRZ. In NI: export TIS to PNG, edit the PNG in photoshop, re-import to TIS. 

Did turning the AI on solve the problem permanently, or did it recur when you turned it off again?

Before. (Doesn't it say so in the readme?)

Noted.

I've just tested it quickly and on my install it's turned the traps off normally. So I'm not sure what's going on there. Possibly it didn't install properly? Check the 'weidu.log' file in your game folder and check that 'no locks or traps' is listed.

Thanks for this. Looking through it:

Summoned AI: noted, thanks. This is a bit of a mess, to be honest, and needs some systematic attention at some point. (EE changed the script assignments to summons in a big way and my fixes are pretty ad hoc.)

Class assignments: of those four you list, one (arngrl01) is a thief on my SCS install (and my unmodded BG2EE install). The others are all fighters in unmodded BG2EE, and I don't really see any reason to change them - yes, they're members of the Shadow Thieves, but that's an organization, not a class description - I don't see any reason that a thieves' guild couldn't employ non-thieves in some enforcer roles.

Mage/thieves: intended behavior in SCS is that if a mage/thief has one of the standard mage scripts, their thief AI is removed and replaced with a bespoke mage/thief script generated by Smarter Mages. You can see this for, e.g., Maevar or REPTHF1.cre. The behavior you're describing would occur if a mage/thief was using a mage script that I hadn't identified for swapping. Actually I can see one example of this: ISHADMT1, who you meet in Irenicus's dungeon, has WTASIGHT and also a spellcasting script, SHADMT01, which is missed by SCS due to a typo (it has 'SHADMT1' instead). Will fix.

Druids: they're working fine on my install.

HLAs: it's supposed to be sequential. Pick a row at random, then assign sequentially from the row.

If you like, I can check for your component and leave the traps in place if it’s installed!

Well, the trigger blocks in library.slb are fairly self-explanatory - SpellProtectionTargetSpellThrust checks if the creature is a good target for Spell Thrust, etc. SpellProtectionTarget is shared by Ruby Ray, Warding Whip and Spellstrike, and so I think I use Warding Whip even against 9th-level protections if there's nothing better, but that's a bug.

The MinorGlobe bit is deliberate, though, IIRC - Spell Thrust can't remove a full Globe of Invulnerability, and there's no convenient way to distinguish them - and it didn't seem worth using up a splstate just to label them. (But I could just be misremembering, or could have made a mistake coding this.)

As a quick note, Turning isn't quite useless in SCS. SCS mages will try to burn through Spell Deflection by casting lower-level spells at it (if they haven't got any better options), but they won't try that against Spell Turning. (This is new as of v32 and I haven't had much reported as to how it's working out in practice.)

IIRC they're used for PC targeting. Look at stratagems/ssl/library.slb.

10 minutes ago, Angel said:

Well, clearing these stray files did the trick, v33 is installed now.

I did however notice a bunch of parse errors due to references to non-existing entries in splstate.ids.  On my installation, splstate.ids is not changed by any mod other than stratagems.

[tb#_compile_eval_buffer/weidu_external/workspace/ssl_out/planet.baf] PARSE ERROR at line 1639 column 1-66
Near Text: )
        [CheckSpellState] argument [ENCHANTMENT_IMMUNITY] not found in [splstate.IDS]

[tb#_compile_eval_buffer/weidu_external/workspace/ssl_out/dw#solar.baf] PARSE ERROR at line 4807 column 1-61
Near Text: )
        [CheckSpellState] argument [ENCHANTMENT_IMMUNITY] not found in [splstate.IDS]

[tb#_compile_eval_buffer/weidu_external/workspace/ssl_out/dw#mg429.baf] PARSE ERROR at line 13077 column 1-96
Near Text: )
        [CheckSpellState] argument [ITEM_PSIBLAST] not found in [splstate.IDS]

 

Can you give me a WEIDU.log?

You most likely had the game open while installing.

Also have a look and see if there's a copy of msectype.2da just loose in your game file. Looking at your log, these are the crucial lines:

[stratagems/spell/modify_breach.tpa] loaded, 2666 bytes
Copied [stratagems/spell/modify_breach.tpa] to [weidu_external/workspace/modify_breach.tpa]
[weidu_external/lang/stratagems/english/spell.tra] has 94 translation strings
[weidu_external/lang/stratagems/ENGLISH/spell.tra] has 94 translation strings
[MSECTYPE.2DA] loaded, 717 bytes
[./override/MSECTYPE.2DA] loaded, 480 bytes
Stopping installation because of error.

So: the modify_breach function loads correctly (those are the first four lines). The first thing that function does is call ADD_SECTYPE. Then it loads 2 sectypes - one is from the override, but the other is (I think, from a little testing) just in the main game directory. And they're different (different lengths). On my successful install's debug, it just (twice) loads the override copy.

Wait, so it installs fine with 32.7, but not 33? That's very weird. I'll think further.

I think this will probably cause trouble, because SCS's various spell tweaks are sensitive to whether SR is installed, and if you fool it into thinking SR isn't there when it is, some files will get corrupted.

If you want to try this, a better way (at your own risk!) would be to edit lib/always.tph.

Firstly, find the block starting at line 140, that sets the variables base_folder_spells_mage and base_folder_spells_priest. Edit the logic so that it sets them to 'iwd' even if demivrgvs=1. (That controls which lists mage and priest spells are selected from.

Secondly, find this line, at line 400:

OUTER_SPRINT ~sslvariables~ ~%sslvariables%~^~&~^~Demivrgvs=True~

Comment it out. Then SCS's AI scripts won't know about SR.

2 hours ago, Arkie said:

You forgot to add new russian lines. 

So I did - sorry about that. I've amended 33.1 to include them.

Perfectly possible, in principle. You'd need to find someone who knew the game pretty well and was very keen on the idea (not me, I'm afraid, the idea is cute but a little whimsical for my tastes), or else learn a great deal yourself, and you'd also need an area artist. As a rule, ideas for mods greatly outnumber people willing to code those mods, so probably you'd need to learn yourself... and it would be a really large amount of work. 

I've updated to 33.1. The main change is a shiny updated French translation, thanks to Jazira and Gwendolyne. This release also fixes a problem with spell hotkeys for high-level mage spells, reverts the mistaken mapping of hotkey 'D' to 'Q", and blocks a rare circumstance where liches would use Summon Planetar on too-easy a difficulty setting.

Unless you play in French, it's probably not worth reinstalling in mid game for this one.

@JabberwockI can reproduce the Planetar problem; it's fixed locally. Thanks for spotting it.

@AngelIt looks as if some previous mod in your install order has done something odd to msectype.2da, and WEIDU's ADD_SECTYPE function is choking on it.  You have too many mods for me to guess which; could you post msectype.2da, and also do a change-log on it?

Thoughtful and helpful, thanks. I'll consider (and see if I can reproduce that Planetar).

Be warned: given how that bug works, you’ll need to go back to a save before you entered Torgal’s level of the keep.

I am reasonably confident that v33 will fix a bunch of v32 bugs without breaking anything in your current game. But I admit I can't be sure. It's a matter of relative risk preferences.