DavidW

3 hours ago, InKal said:

try this https://baldursextendedworld.com/Broken-Lanthorn/

 

Again, that’s a completely different quest. Oversight’s version, Roxanne’s version and my version are all different quests around the same underlying idea. (Mine is a pretty conservative restoration of the original cut content; Oversight’s has the same idea as the original cut content but a quite different implementation; Roxanne’s is a new quest loosely inspired by the cut content.)

Is it actually that unreasonable? (I've not really played with it). You need to take along a thief (probably a slightly underpowered class tactically speaking), to invest in the skills to use it effectively, and then don't you have to sit around for a couple of seconds waiting for it to trigger? (Correct me if I'm wrong; like I say, not much experience). And then you've taken down mages' illusion defenses, which isn't nothing, but isn't the most critical part of their defensive layering.

On the purely technical side, opcode 276 modifies Detect Illusion. If you want things like SI:Abjuration or Nondetection to interact with thief DI, you could probably do it aura-style with a bit of thought.

1 hour ago, subtledoctor said:

Maybe... maybe not.  I'm  not sure if the current value is exposed to the UI when you're in the level-up screen. 

You can see it when leveling, so I assume it must be!

4 hours ago, subtledoctor said:

On the thief class side of things, the only way to achieve such a thing would be to limit how many points certain kits or multiclasses could put into it.  Limit multiclasses and most kits to ~50-60 points, while allowing the trueclass thief and maybe certain detection-focused kits to go higher.

I don't think such limits are possible  though, even in the new EE engines that let us mod thief skills in all sorts of ways. 

Can't you do it via the UI?

No apology needed. But I don't really mind that Kahrk can be more powerful than Sarevok (there's a very long tradition of optional bosses being tougher than the main boss) and if I did, I'd probably respond by nerfing Kahrk. Consensus seems to be that SCS Sarevok is already powerful enough.

2 minutes ago, Guest Ront said:

Please, make Sarevok haste undispellable. 

Can you explain why?

2 minutes ago, Guest Ront said:

And if possible, it would be cool if abazigal lair was to be added back on bgt. Or was it added already?

Not yet. It's on my to-do list, but lowish priority (sorry).

2 minutes ago, Guest Ront said:

Also, would it be possible to add the rope back via an .ini setting so I dont have to fight the dragons?pretty please?find the fight cheap, they got no loot at all.. compare with the yellow dragon that has good dialogues too..

I think you can just summon the rope via CLUA. (It's bazplo05.)

I don't actually single out Kahrk for special treatment, so this is just the automated code messing with him. But he's listed as 12th level, and SCS keeps him that way - and since he's an ogre-mage, he gets treated as a fighter/mage. That gives him another APR, which probably is double-counting since he's already given 3 - I might tweak that later. He'll be specialized with his weapon and have two pips in one-weapon style, and his ability scores are awesome. He has 18 Dex and a base AC of 1, so that's AC -3 before his defensive spells kick in - again, that's just the vanilla game. And of course he's 12th level, which is pretty high level for BG1. I don't give him anything special to make him immune to MM - could he have had Shield running?

So: with the arguable exception of that extra APR, this is just an already-pretty-tough BG1 creature that gets horrendously tough when SCS gives him level-appropriate spells and proficiencies. So, on the one hand I can see the case for toning it down, since that 12th level flag is mostly nonfunctional in the baseline game but creates a hellishly dangerous SCS opponent. On the other hand, this is a completely optional fight which you get into only after a conversation that goes something like this:

CARSA: this jar caused all my companions to die; it wants me to open it; I won't.

PC: Give me the jar.

CARSA: No, if I give it to you we'll all die. Run now.

PC: Give me the damn jar!

CARSA: No! Get away or I'll release the thing in the jar and it'll kill you.

PC: We're taking the jar by force.

CARSA: KAHRK!

To be honest, I think if you let Kahrk out you get what you deserve

If you're adding new spells that enemy AI ought to detect, very possibly. I can talk you through it if you want.

As discussed here, the version of DS used in SR (and SRR) creates some (fairly edge-case) bugs due to removing duplicate entries from stats.ids. The more up-to-date version of DS in SCS avoids that (and has other minor advantages) but wasn't previously compatible with SR because it required AUTO_EVAL_STRINGS (which is part of my standard modding environment but breaks SR).

The new version of DS I've just coded (see link here) doesn't require AUTO_EVAL_STRINGS, so you might want to update.

1 hour ago, subtledoctor said:

Ah yes, it has that feel. 

Sure. It’s a bit on the artificial-feeling side of things, but there us definitely a balance to be struck. This jumped out at me, mostly because it surprised me. But, as an indication of my overall judgment of it, I would certainly install that component again. (And now I’m really wondering where and when I’ll see more of its changes...)

& yes, checking the code (and SCS's readme) that section is a verbatim copy from Tactics' "Improved Druid Grove", untouched in SCS since 2011 (and even that was just to fix a namespace problem).

This is a fairly belated comment, because I mostly did it a year ago, but I've coded a new version of Detectable Spells (v4.0.1). You can download it from the SCS github repo (it's not in the most recent live release of SCS). Just put ds.tph somewhere in your mod folder structure, INCLUDE it, and then run the 'detectable_spells' function. It works on the EE games (though it's not all that sensitive to IWD) and on the classic ToB engine, with or without ToBEx.

This was a recode from scratch so I can't that easily describe fine-grained changes, but I think it's pretty solid (it's been loose in SCS and Ascension for a year or more without any bug being traceable to it). 

One of the main changes in this version is that it's radically easier to add detection effects to new spells, over and above the baseline ones included in ds.tph itself. But the use cases for that are relatively niche so ask me if you want them.

I can reproduce this - it shows up in classic BG2 but not in BG2EE, because an opcode is interpreted differently. Thanks for catching it.

I'll sort it out next time I do an update. (May not be imminent, sorry.)

On 8/1/2020 at 3:21 AM, Bartimaeus said:

As a test, I once summoned probably like 40 hobgoblin archers and had them fight against spellcasting-triggered SCS Cowled Wizards, and the Hobgoblin Archers pretty easily won. Overwhelming numbers can sometimes be just that: overwhelming.

Although it's also true that SCS's AI assumes it's fighting level-appropriate adventurers - I suspect I could write anti-Hobgoblin AI for the SCS wizards that would do a lot better against large numbers of low-level mooks.

I suspect it's mine ('improved minor encounters') though I have a feeling I might have borrowed it from Tactics. 

I don't think artificiality bothers me: if there are hostile plant creatures on the route to Faldorn, my working assumption would be that the Shadow Druids placed them deliberately.

2 hours ago, jastey said:

I still recall - faint as the memory is - someone saying some time ago that the EE aim not break compatibility of old mods and will be far easier to mod in general. As it turned out, compatibility got broken for mods adapted to EE from one patch to another, and this sounds as if it won't be any different this time.

To be fair, they delivered on the ‘far easier to mod in general’ promise, at least by the time IWDEE came out. The EE engine is way beyond classic BG2 now, even with ToBEx.

2 hours ago, Moonboy187 said:

Another thing I noticed is that sometimes when an NPC is casting a spell, if you pause the game, for whatever reason the spell they were casting gets interrupted. I don't know if this is a bug or maybe something to do with a script, but it is incredibly frustrating to deal with.

Back in 2004, when I was first messing with AI for the BG games, I discovered exactly this issue in BG1. So far as I can see it's a hardcoded feature of the engine and can't be worked around. It's the main reason I stopped trying to do AI for BG1 and moved to TUTU.

PfMW, almost certainly. I don't know why you didn't see it being renewed in the log.

4 hours ago, subtledoctor said:

EDIT - regarding description text: it seems to me that both IR and EEs misuse the term “thac0.” (Or, “THAC0” if you prefer.) A bonus to hit is not a “thac0 bonus” - it’s a to-hit bonus. It’s been a long time since I looked at the original books, and I don’t have any nearby... anyone know if the 90s 2E source material used it that way? Or is that kind of item description an invention of Bioware in BG?

Officially, in 2nd edition AD&D, 'bonus to THAC0' and 'attack bonus' are basically synonymous - they're used that way by the text in the 2nd edition Players' Handbook that explains THAC0, certainly. But the spell descriptions in the Players' Handbook don't, on quick inspection, refer to THAC0 - they talk exclusively about 'attack bonus'. At a guess, that's because the text is in most cases taken over with little or no changes from the 1st edition AD&D Players' Handbook, which doesn't have the THAC0 concept. Later sources do use it - for instance, the spell descriptions in the 2nd edition Forgotten Realms Adventures hardback describe various spells as giving attack rolls 'at the caster's THAC0 with a +2 bonus'. 1990s-period TSR almost certainly didn't have the established style rules that (I would bet) WotC or Paizo have, so things are a bit inconstant from product to product.

My own feeling, FWIW, is that it's better to talk about 'attack bonuses' than 'THAC0 bonuses' because of the pre-3rd-edition awkwardness that lower THAC0 is better. Strictly, '+2 to THAC0' is a penalty, but it reads so weirdly to talk about a -2 bonus that in practice, +2 is used to mean a 2-point bonus. (Similar problems arise for AC, of course - a ring of protection +2 gives -2 to AC.)

Polygons are part of the illusion of three-dimensionality. Character, and some spell-effect, pixels inside a polygon are dithered, i.e. drawn faded out, to indicate that the sprite is behind something. A tree, for instance, needs a blob on the search map (marking the region that you can't stand in because the tree is there) but also a polygon (marking the region where the tree is in front of you.

It's the smallest rectangle you can draw around all the object's vertices. Presumably the engine checks if a sprite is in the bounding box (which is trivial) before bothering to check if it's in the area itself (which is calculationally harder).

At a guess, your version of BG2EE needs updating.

I do understand (I think) but it might take a few days before I have a chance to address it.

On 7/22/2020 at 11:39 AM, NdranC said:

EDIT: Minor question, I killed the shadow dragon but it didn't drop "Crom Faeyr Scroll". Is this something that IR or maybe SCS changes? I guess nothing I can do about it but just asking around.

It's not SCS (well, not intentionally anyway, and I can't see a way it could happen accidentally).

As for the clash between SR and AUTO_EVAL_STRINGS... I guess in hindsight it was antisocial for me to code the latest ds.tph to assume it. I'll see if I can work out a version that doesn't require it (it may be difficult; I've been coding with AUTO_EVAL_STRINGS for seven years...)

50 minutes ago, Angel said:

Yes, had it from practically day one.  Got tired of having to put EVAL everywhere.  And I don't think SFO will work without it, actually.  (The version I use is from SCS v30 or so, with a bunch of bug fixes and a few tweaks of my own.)

SFO definitely doesn't work without it, in that it does a sanity-check for it:

///////////////////////////////////////////////////////////////////////////////////////////////////////////////////
// Sanity check for AUTO_EVAL_STRINGS
///////////////////////////////////////////////////////////////////////////////////////////////////////////////////

 OUTER_SPRINT var testers
 OUTER_SPRINT players var
 ACTION_IF !"%%players%%" STRING_EQUAL testers BEGIN
      FAIL "AUTO_EVAL_STRINGS is not set (you need to include it in your tp2 preamble to use SFO)"
 END