Ardanis

Sounds like a definite improvement over the old all-or-nothing prebuffing routine (thumbup) On that note, rather than duration you could try segregating buffs by their type instead. In SoD I grouped them like this: 1) Buffs against physical attacks, further split into: - Decremental defenses (Stoneskin, Mirror Image) - Immunity to weapons (Protection from Weapons/Missiles, Physical Mirror) 2) Buffs against spells, split into: - Immunity to spells by level (Spell Turning, Globe of Invulnerability) - Invisibility - not really an anti-magic defense with SCS+SR, but nevertheless so in SoD 3) Partial protections (Pro Evil, Fire Shield, Armor of Faith, Blur, Spirit Armor) and combat enhancements (DUHM, Blade Barrier, again Fire Shield). On Normal difficulty AI would randomly select a subgroup for both anti-attack and anti-magic protections and cast the strongest buff it has available there. If the wizard had no spells in selected subgroup at all, there'd be no buffing in that category. This effectively reduces the amount of buffing by 50%. On Core there'd be no random rolling, and the strongest buff from each subgroup would be precast. In addition, any extra buff from the third group would also be applied. For high-level BG2 caster with access to wider array of spells the grouping can be further refined and extended across difficulty levels (the SoD buffing routine was mostly for low to mid levels, and I readily admit I was too lazy to spread it across more than three difficulty levels).

When I played some years ago BGT with SCS, Revisions and UB, I ended up finishing BG1 with nearly 400k XP, and I hardly noticed any difference during first steps into BG2 with my previous BG2 SCS playthroughs. This in fact was the main argument during SoD development to not worry much about importing 500k characters into BG2EE, as the difference would be negligible. So, for just 500k I wouldn't bother much either, but I thought EET wasn't forcing any XP caps? So it'd be actually about 700k, even without any quest mods. Pretty sure it should only be an option for trilogy installation, not an introduction for a new BG2EE playthrough And a transition from the brutality of insane SoD into gentle early stage of BG2 SCS as what I suggested for adjustments would be more appropriate for an SoD dungeon on normal/core.

I was assuming EET playthrough, i.e. without XP caps. So, you'd have about 300k-400k from uncapped BG1, and as much from SoD. Compared to BG2's starting 89k, that's about three extra levels.

About 300k XP per party member if you don't grind too much. No stat boosts. With about 250k extra from BG1 part (assuming we're talking about EET here), that would be starting BG2 at about +3 levels compared to vanilla. PS Also no level 6 wizard spells in SoD for party to find, unless I'm forgetting things.

I think this would more or less suffice: 1) Replace lesser golems with normal versions 2) Add a bunch of various slimes to the Otyugh room 3) Replace mephits in the plane of air with air elementals (normal and greater) 4) Replace some goblins with aerial servants and/or invisible stalkers (instead of duergars) 5) Add a couple fighters and a mage to each vanilla duergar encounter 6) Add a couple levels to enemy thieves 7) Increase number/frequency of mephits spawning from the portals Cambion, vampire and doppleganger are probably ok.

No difference that I'm aware of.

I believe he's on phone/tablet most of the time.

I suppose it does have more to do with individual encounter design, i.e. a lot more hand-craft work compared to general AI, but since you already have the tactical challenges group of components I would still encourage you to give it a shot. Judging by the insane playthroughs posted on Beamdog forum, particularly Temple of Cyric, Coalition Camp and Dragonspear Basement, the extra numbers were about as fine a challenge as insane-specific AI, and a good change of pace too.

- Click on the icon- Select "Remove the difficulty control from my Special Abilities." - Control the difficulty either by 'C:CreateCreature("dw#diffi")' or directly through the difficulty variables. (I find objects more immersion-breaking than special abilities.) You can also bind it to hotkey. This is from Player1's SoD script: IF HotKey(B) OR(2) INI("QAMODE",1) Global("BD_QAMODE","global",1) THEN RESPONSE #100 ActionOverride(Player1,StartDialogOverride("bddebug",Myself)) END It does require a script assigned to Player1, though it may or may not be possible to TriggerOverride(Player1,HotKey(X)) from baldur.bcs.

If I understand correctly, the "widget" is a dialog file where you can select desired options. Should be simple to find all the variables you need and put them into new "my setup" option you can install/copy over SCS' file.

Sounds a lot like how difficulty is treated in SoD - very limited spell/item/ability usage on easy, partial prebuffing and more spells on normal, full prebuffing and all spells including Fireballs on core, with some select per-encounter improvements on hard and insane. Also, SoD makes extensive use of difficulty slider to control the number of enemies you encounter, e.g. more grunts on core and an extra mage on insane, and finally allows AI to target AoE damage without hitting its allies. Are these things making their way into v32?

The most intelligent AI doesn't necessarily equal to most enjoyable to play against. While a designer may see it as a challenge to write the best AI possible, the player experience may dictate otherwise. If you play as a dwarven defender, then chances are you're doing so to take advantage of his tanking ability. Except it ends up completely wasted if AI just starts targeting other characters, so you might as well have taken a kensai instead. Best solution that I'm aware of - randomize targets, so that if you have half party members e.g. protected from charm, then half the casts of it will be unsuccessful. This is the math at its simplest. And you don't need lengthy triggers for this to work either.

It's eight characters by default, so unless you need different length (or to null-terminate) it's fine.

Regarding teleport, I had similar dilemma with neothelid, which I solved by having it sense the entire area via ESP and ignore people protected by Sanctuary and Chaotic Commands. While liches don't have innate ESP, they still could be presumed to possess divination powers, which are blocked by Non-Detection, SI:DIvination, Sanctuary and whatever else might there be.

It's fine, I don't either

I suppose you could make the installer automatically increment a wrong letter by one until it hits a free slot. But yes, it's not not exactly user friendly.

Yes, some of SoD's romance triggers have visibility issues. Dynamic objects like [PC] or [GOODCUTOFF] require them to be within script owner's direct line of sight to return true. With doors and ground triggers the script's coordinates are at the center of bounding box, so with very large triggers or obstacles over them it's possible for script to not see the entire trigger's area. Or for a door to be blind on its southern side. Use static objects, like PlayerX or death variable name. If you need it to be any friendly creature, however, then it might get complicated, because as David says you do need a wildcard to match them. I could suggest to split the trigger into few smaller ones, sharing the script. It might be possible to activate both parts of it simultaneously, so to avoid duplication you may need to move the desired action into area script and have the trigger only set the activation variable.

I may have mentioned it sometime ago, but - shouldn't BWS just make a guide about what tp2 input it can process, and then modders who wish to be part of BWS framework will take steps to ensure their code is compliant with its guidelines? I.e. why not just blacklist by default the mods that use of READLN? If their authors are actively interested in participation in BWS project, they can e.g. use some IS_BWS flag to toggle READLN on/off.

Ah, I see. Point taken. I meant it more like - if system's stability depends on plugging ten same holes in different places, then you should assume you'll miss some, or may forget to plug new ones when adding new stuff. Learned it hard way during SoD

Yes. It means you can't read in data in your ALWAYS that's to be used in any component. Example: SCS's ALWAYS block goes through every spell in the game and sets a variable with name equal to its ids reference, value equal to its spell file. It also goes through and finds a scroll for each wizad spell, and records that as the value of a variable. It takes 2-5 seconds and I'd rather not have those 2-5 seconds every component. At a more conceptual level, I'd like my encapsulation to be built in to the way the code is structured, not forced explicitly. One of the main points of FUNCTIONs is to deliver this; why not use it? Put another way: why not avoid defining variables with global scope in the first place unless you want them to have global scope, rather than just clearing out the global scope on a regular basis? I thought ALWAYS is supposed to run always, i.e. you'll spend 2-5 seconds re-reading data regardless of how you clean up the environment. And while I agree that wrapping the component code is a good habit to have, if you absolutely want to prevent rogue variables slipping into the next component, then always clearing everything *is* how you structure the code to eliminate the human error factor - with a single switch you ensure nothing will slip through even if you forgot to properly encapsulate a component or two - just like you used to forget cleaning up the backup folder. It's more like something to be aware of, than a real issue. Unless you do a great lot of stuff in multiple places inside your folder, or forget things easily. The idea was to control the input and output, using only what you want and removing anything else. It's perfectly normal to have no input/output whatsoever, especially if the code can be used across multiple mods/components (look at DS for example). Note that unless it was changed in recent years, functions still accept external input that wasn't forcefully set in function definition. DEFINE_ACTION_FUNCTION print INT_VAR a=1 b=2 BEGIN PRINT ~a=%a%, b=%b%, c=%c%~ END OUTER_SET a=10 OUTER_SET c=30 // you don't really want this to slip inside, but unless I'm mistaken it still does LAF print INT_VAR b=200 END // will print ~a=1, b=200, c=30~ No. Yes, you need to define it the same way you define macros. The only difference are the optional INT_VAR, STR_VAR etc.

What do you think of this instead? Way better!

The color scheme for "has new posts" and "no new posts" is counter-intuitive, actually. Seriously. Nah, the "right to be forgotten" is a violation of free speech and has to be outlawed. **** the all governments that endorse it

I wish you'd get rid of the living cancer that IPB calls "message formatting"...

I suppose then, depending on a mod, it boils down to the existence of two kinds of config options - one the players are actively encouraged to tweak, and another is unsupported and only exists for expert users who really know what they're doing. If so, then it could be as simple as formatting the former to be BWS-compatible on the modder's side and include it in case-by-case manner on BWS's side, rather than uniformly trying to read all settings files. That is assuming I understand Alien's intent correctly, obviously.

Yes it does, in the lib folder. It's not called "settings", but technically it's the same thing. My point is that while the ini file is more obvious, it's not the only place where users can fine tune mod's parameters before installing it. And neither is really meant to be tweaked by a casual user anyway. So, when it comes to BWS, the question is whether it's really a good idea to allow ini tweaks in the first place. Like, if it lets users to customize their setup beyond what the tp2 structure offers, then shouldn't it grant access to even more obscure settings, if the main concept is to not deprive users of any customization options they might have had with traditional install process. If it is, then it might just defeat the purpose of being a lightweight solution for those who simply want to play the damn game instead of messing with technicalities. If it's not, then why include inis at all.