Shin

Great news, looking forward to this one for the next playthrough.

That's been known to happen as well, yeah.

It's directly to the left+north of where the stone stairs start , by the little grove of mushrooms.

Hmm, yeah, I mean like with BG1/SoD, even without mods the BP1 resources are included and you can essentially just teleport your party to the BP starting area and the scripts will kick in. Is it the same with BP2?

Been away from the game for awhile, but really cool to finally have it all available as a single, comprehensive and moddable install. Only Black Pits 2 missing now.

This is a bit of a longshot, but just in case the answer is obvious to someone: My current 2.5 EET multimod install has started off well with the exception of one small bug with the journal: every quest I acquire gets added not to the part of the journal that keeps track of quest progress but to the general info tab where all other updates and chapter summaries end up. Switching the UI.menu file to one from an older but somewhat similar install that doesn't have this issue doesn't do anything to solve it, which leads me to believe the problem lies somewhere else. Also there doesn't seem to be any difference in the dialogue/triggers that create the journal entries. Grateful for any ideas on where to look.

This is quite similar to an install I got going just the other day, plus/minus a few mods. As you may know already, with that many mods and EET on top, even if there are no hard incompatibilities you are exceedingly likely to run into various bugs and issues throughout the playthrough. I'd only recommend such an endeavour to someone fairly used to how the engine works.

That's colossally disappointing if so, after all this time and the issue by all accounts having been introduced by an update to begin with. I don't recall noticing it back in the beta, but maybe wasn't thorough enough.

I thought this was brought in at some point to have the end result work much like imprisonment in practice but prevent certain consequences of the actual imprisonment effect, like the game ending if Charname gets imprisoned, or NPCs just disappearing. Maze is more forgiving.

I'm leaning toward the opposite camp here. For me, the main upgrade with 2.6 (that you can't do anything about through modding/editing) is the pathfinding -- but I'm not sure that's worth the risk of having your playthrough diminished by malfunctioning mods/compatibilities. EET on 2.5 has been stable for a long time afaik -- even during my last playthrough more than a year ago, the relatively few issues I had were caused by other things.

You think? It doesn't seem that way as long as there's still access to 2.5-compatible versions of the mods - those multi-mod installs were pretty stable.

Thanks. So still a pretty risky endeavour then it seems, especially for a trilogy install.

With any bigger update usually being followed by a period of mod adaptation and, somewhat simultaneously, a period of uncertainty regarding what works and what doesn't: what's the rough status of 2.6 plus mods today? Can you expect a stable trilogy multi-mod install (eg EET, SCS, EEex, Ascension, Spell- and Item Revisions and various quest, NPC, kit and tweak mods) or is it still too early? Sorry for asking without doing any research myself; just want a general idea before deciding whether to plan a playthrough (in 2.6, at least).

@jastey I'm running an EET and EEex game on the Beamdog version 2.5.16.6, Windows. It's a completely new and different install from my last report, and also the mod was updated since. My mod setup however is rather similar. Anyway, when investigating this the only suspicious thing I found was in SPCL721.spl itself, the storm shield ability given to priests of Talos. Unlike their other kit ability SPCL722 (lightning bolt), SPCL721 is designated as a priest spell rather than innate ability, and also has exclusion flag 30 (cleric/paladin). My hypothesis was that this could cause issues when the game attempted to add it as an innate ability as part of the kit, hence why it might have caused a loop adding it over and over. I'm not sure if this is vanilla behaviour or brought on by something else in my install, though -- seeing as no one else seems to have run into this issue, it could well be the latter. And also if that ability is indeed the problem it should cause the same issue for all NPC priests of Talos.. not that I've had any others than Dave in my game. At any rate, as far as I could observe the behaviour started after I had picked up Dave into the party and then kicked him out again. He essentially stands inside the Friendly Arm and amasses thousands of memorizations, to a point where his spell list takes up more space than everything else in the save file put together. By the time this became noticable (slowdowns when loading a game), several weeks of in-game time had passed, and a fair amount of travel and resting done by me. To soIve the issue I ended up replacing Dave's script with one that auto-casted a spell to erase all his memorization, which worked well. I then switched back to his normal script + edited SPCL721 to be innate and with no exclusion flags, and so far he seems to be ok.

Quoting myself as after a new install I'm having the exact same issue with Dave; for some reason he keeps amassing copies of SPCL721 inside his .cre file until it bloats the save and causes slowdowns. Still can't really find a good reason for this: nothing that seems to explain it in his script, items or dialogue. The ability in question is from his kit, but can't see how that would cause it either.

Again thematically I'm also against retaining spellcasting ability while shapeshifted, on the notion that it's a transformation a bit like Bruce Banner and the Hulk, or Jekyll and Hyde. Even if it's not as drastic a rewriting of the personality, it still seems suitable that at least impulses would be harder to control, maintaining concentration would be difficult, and reagent manipulation/hand gestures would be pretty much impossible. Druids in bear form should likely have better control of their behaviour than your ordinary bear in the wild, but also shouldn't 100% retain their human-form way of thinking and reacting. In a more detailed mod this could of course be handled by giving various animal forms suitable spell-like abilities. In a more modern game a bear would likely have various mauling and knockback attacks, maybe a stunning roar, etc. It's more a 2E thing that fighter-like classes pretty much just have their regular attacks.

Agree with this. It seems more likely given the circumstances that a ranger should fall for allowing the guard to kill Viconia than for saving her.

In terms of literal shapeshifting (i.e. turning into an actual bear rather than assuming more metaphysical aspects of the bear nature) I thematically prefer the first option with set stats. At least the way I imagine it, the quality of druid shapeshifting ought to be determined more by their mental or spiritual qualities than by their physical strength. Ideally if anything a druid with high wis and int would turn into a stronger bear than a druid with high str, but that might be overcomplicating things compared to just having set sats. The same reasoning seems even more true for mage polymorphing where very little of the caster's own physicality can be assumed to remain.

This isn't a bug I've seen before, but I doubt it's related to the mod per se. As it is, installing SoD mid-playthrough will generate a separate and new install of BGEE+SoD. Doing this and attempting to carry on with your old save sounds like it's almost guaranteed to cause problems. My best guess is that your installation process scrambled parts of the dialog.tlk file so that the generated save names come out wrong; in this case with text from this particular mod, but if you had other mods installed it could likely have been from any one of them. From there, I believe your guess about the long save names causing problems is correct. If everything else seems to work fine in your game, maybe this can be worked around by editing the dialog entries involved (or possibly by uninstalling the mod). If there's other kinds of weird behaviour, I'd recommend finishing your original BGEE game, then installing SoD, starting a new SoD game and importing your character from BGEE.

Spontaneously, if that was within the range of possibilities, probably remove it or reduce its efficiency for multi- and dualclassed thieves, while keeping it as is for singleclassed thieves; the pure class most of all.

Yeah, I don't doubt that at all. The thing was more that this didn't seem like it would be complicated -- just a little more so than e.g. a potion of explosions, when I first thought about it.

That seems to have done the trick for the animation, thanks. Edit: for posterity, I've seemingly gotten it all into place with some convoluted workarounds. In the end I put the graphical effect into a separate cast from the ITM as per temnix's advice; the gas cloud graphical effect into the original projectile that I turned into an aoe; the ticking/repeating gas cloud spell effects into a secondary spell cast by opcode 146 at preset target(2), and the one-time explosion damage into a tertiary spell cast by opcode 146, also at preset target. This tertiary spell also contains a short-term opcode 206 immunity to itself so its damage won't apply every time the motherspell ticks. The net result is that the graphical parts (explosion and gas cloud) now always display no matter if targets are present or not, whereas the (non-graphical) damage and gas effects will only be applied (or rather be cast at all) if there are nearby targets, which of course is fine. I also can't quite believe the effort that ended up going into something that seemed so simple when I first came up with it. Grenade-like items that are targeted on creatures rather than on the ground seem a whole lot easier to work with.

That did the trick indeed, thanks.

I've tried that too, but the issue is that I want the boom to be aoe damage (applied once), so it has to be an aoe projectile, but I don't want the graphical effect to display on top of every target the way aoe projectiles tend to do. Any other way to bake an animation into an aoe projectile file, but have it only display at the target point, regardless of whether there are targets in range or not? I then apply the gas cloud with a secondary aoe spell. Edit: after more testing it all seems to come down to irregularities in opcode 148, that is used to deliver the spell effects: if this opcode is targeted to none(0) or preset target(2), the spells will fire correctly, but only as long as there are actual targets within range, but the timing will be correct as they fire only after the initial projectile arrives. If targeted to self (1), the spells will fire correctly everywhere (even without targets in range), but here the timing will be off as they will always fire instantly at the target location rather than after the travel projectile arrives. So. Is there a way to make all of the effects always play at the target location, regardless of whether any actual targets are there, and only after the initial travel projectile hits?

I'm noticing that spells and projectiles with 'any point within range (4)' as target can lead to some quirky behaviour. Essentially I have an item working a bit like a grenade, that is able to be thrown anywhere on the ground, displaying a travel projectile, displaying a central fire animation similar to a melf meteor on the point where it lands, and then spreading a gas cloud around it. The problems arise seemingly as a combination of targeting: if I use opcode 215 to display an effect at the target point and designate the target within that opcode as 'self (1)', the animation will display before the travel projectile reaches the target point. If I use 'preset target (2)' as target the animation displays correctly once the travel projectile gets there, but only if there are eligible targets within range. If no targets are nearby, the animation again won't display. These issues are of course solved if I make it so the item has to be targeted on a specific actor rather than being cast anywhere on the ground, but that's also not optimal. Any obvious solutions for this? I feel a bit like there's a specific combination of targeting and projectile use that would solve the issue and make the item castable anywhere and still display all its effects only after the initial travel projectile hits. Another seeming quirk with 'target anywhere' items that cast spells seems to be that if you target them out of range, rather than the PC moving into range to cast them, the item will simply deplete or use up a charge without anything happening.