Ardanis

Haha, FINALLY!!! Conjure Elemental is next

Cone of Cold vs Fire Shield I don't think it will underpower FS, rather it'll make CC more appealing in a competition for precious 5th level slots. Although I might be behind the train now, as far as per-level choices should go... However, it does mean we'll then start considering the same for Ice Storm vs Incendiary Cloud, ADHW vs Entangle, etc.

Since when was my position anything but that? As for why I play exclusively humans, that's because I like to be as pretty and good-looking in a game as I am irl Certainly not because they got better scores. FWIW I deliberately don't even take 18 in any stat when generating new character, and play with 16-17 instead. I dunno about the so-called illegal... PC, fresh out of Candlekeep, can bump their WIS up to damn +3 over the racial max during the course of BG1 campaign, but a seasoned adventurer like Coran or Kagain couldn't have managed to raise theirs by +1?

Revised table makes sense, however what would be the benefit? Lowering values seems more like artificial restriction to me, because if you agree with them then you don't play a DEX 18 dwarf in the first place, and if you don't then why install the component. Also a number of characters, joinable and not, may end up with illegal stats with this revision, unless patched manually.

SoD added generic versions of magic items to prevent duplication of unique backgrounds. If it makes things easier on technical side, then you have my blessing to use a single filename for duplicates. I personally don't care any bit at all about backgrounds, as I never read those walls of text Do make sure to check the scripts/dialogue for filename references though, as some may have those being checked for. This item was very specifically designed to balance the allied and enemy squads in camp defense battle. To make it effective against the troll wave, but not as much against the others as regular Arrow of Fire was.

IIRC we've already been using this approach in some component for years (Shield Bash perhaps?). I distinctly remember reading the name, enchantment and actual armor value from an item and then printing out a warning if they didn't match up. I agree it would make a fine backup solution for items missing from the hand-made list (in fact, our armor list was built from extracted game data containing the item name and description and its AC modifiers, which I then manually reviewed and made judgement calls in ambiguous cases). The downside is we'd need to test it extensively, to make sure the inclusion of additional heuristics won't accidentally fubar something unrelated (hint - it can). This would only be an issue for shields and armor types, though, I think? Maybe helmets too. The store component automatically sorts the items by type, price and name. If there're two swords +1, that means either someone added another item into a store, or modified an existing one. Beyond that, I can't tell much.

this one will be greatly improved at some point to take into account DisplayStringWait action that is heavely used by Beamdog content (I will run each referenced WAV file with a tool that analyses the length of track and than add exactly as many SmallWait() ticks needed to not abort sounds triggered by this action). This is why the current tweak is not effective in SoD and other Beamdog's cutscenes. Although you can keep it installed for now since it will help with many vanilla BG2 cutscenes. That's not necessarily the case. DSW() waits for the sound to finish playing (it's supposed to, anyway), then proceeds to the next action. So I'd expect no difference between various FPS settings or languages when it's used. The problem would arise when cutscene does not use DSW(). That would be awasome but it seems to work differently for me. Let's take a look at CH1CUT01.BCS (Gorion cutscene) IF True() THEN RESPONSE #100 CutSceneId("Gorion") ... DisplayStringWait(Myself,31483) // Listen carefully! If we ever become separated, it is imperative that you make your way to the Friendly Arm Inn. DisplayStringWait(Myself,31484) // There, you will meet Khalid and Jaheira. They have long been my friends, and you can trust them. END IF True() THEN RESPONSE #100 CutSceneId(Player1) ... ENDthis part indeed waits for the voice to be finished before going to next action: DisplayStringWait(Myself,31483) // Listen carefully! If we ever become separated, it is imperative that you make your way to the Friendly Arm Inn.but next line: DisplayStringWait(Myself,31484) // There, you will meet Khalid and Jaheira. They have long been my friends, and you can trust them.doesn't wait for anything at all (I've also tried adding some action right after it - doesn't change anything). On 60 FPS whole next script block is finished while the sound is still playing, so it doesn't wait before moving to the next action / script loop. In this case sound is aborted somewhere in the middle. Due to this I thought that the command only works as intended on 30 FPS and on 60 FPS would need additional SmallWait lasting as long as the track, but after checking this cutscene I'm no longer sure what's up. Should it be reported to Beamdog or does it work as intended? Unfortunately, it does work as expected... When there're multiple CutSceneID() objects in the script, they run their local action queue simultaneously and independently of each other. So, while Gorion would wait for the audio to finish playing, Player1 is not bound by such obligations and proceeds straight to the next area. It could be alleviated by moving the area transition to the dedicated script file (transitions should only be done by Player1) and start it from Gorion's block, but, yeah, that involves more substantial re-structuring than a couple REPLACE_TEXTUALLY. Especially given it also includes skippable mode. PS to be honest, I don't know what can possibly be done to resolve the issue gracefully. For simple cutscenes it's possible with DSW() or additional Wait()s, but stuff like SoD's final battle intro is just too complex. We'd have to split it from string till next string, and even that would still mess up the synch in between, in some scenes (like in the hell bridge scene just before the tower). Even the looping sequence like in BDCUT11/BDCUT11A wouldn't solve it.

this one will be greatly improved at some point to take into account DisplayStringWait action that is heavely used by Beamdog content (I will run each referenced WAV file with a tool that analyses the length of track and than add exactly as many SmallWait() ticks needed to not abort sounds triggered by this action). This is why the current tweak is not effective in SoD and other Beamdog's cutscenes. Although you can keep it installed for now since it will help with many vanilla BG2 cutscenes. That's not necessarily the case. DSW() waits for the sound to finish playing (it's supposed to, anyway), then proceeds to the next action. So I'd expect no difference between various FPS settings or languages when it's used. The problem would arise when cutscene does not use DSW(). SoD (and some BG2EE) scenes differ from vanilla BG2 by having more action occurring while the sound still plays, i.e. the Wait() delay not always matches the sound length. And sometimes it's not even there at all, e.g. BDCUT15.BCS: IF !TimeOfDay(NIGHT) THEN RESPONSE #100 CutsceneID(Player1) ClearAllActions() DisplayStringHead("bdhepher",34556) // Curse you, Jayvis! Do you know what your cowardice has cost us this day? END IF TimeOfDay(NIGHT) THEN RESPONSE #100 CutsceneID(Player1) ClearAllActions() DisplayStringHead("bdhepher",35793) // Curse you, Jayvis! Do you know what your cowardice has cost us this night? END IF True() THEN RESPONSE #100 CutsceneID(Player1) ClearAllActions() SmallWait(10) ActionOverride("bdhepher",SetSequence(SEQ_ATTACK_SLASH)) ...

I think a mass LR would seriously diminish the value of magic resistance, which is hardly a good thing in my opinion. And it just so happens that enemy groups (drow, illithids) benefit from MR much more than player, who would normally had 1-2 characters resistant most of the time. Single target LR is enough against such party members. And then, if you go all the way to buff your MR as high as possible (e.g. with spells and potions), having AI waste all your efforts with a single spell is not entertaining - essentially the same problem as with Dispel Magic. That's just a poor AI, if it behaves like that.

Use spears and halberds, their range is extended in IR to safely bypass the fireshields from afar

You can block X levels of sectype Y. The only thing is, it's the opcode used by vanilla Spell Shield, and I don't remember how exactly it was bugged.

I would like protective spells (CC, DW, FA, NPP, the Armor spells, Pro damage, etc.) to last 8 hours, and other combat enhancements (Aid, Bless, Shield, Blur, MI, Fireshield, etc.) to not exceed the 5 turns limit.

I like the depleting NPP idea, though I'll vote for level-dependent formula to determine the number of protections it offers. Protection vs STR drain is quite fine, if you ask me - if I were to face multitude of undead types, I would certainly like my shield to not be wasted away by wimpy shadows - who cares if I lose a couple STR points for several turns, when I've got vampires and ghasts to deal with.

For the record, TriggerOverride(LastSeenBy(Myself),Range(FourthNearest([GOODCUTOFF]),20)) allows to target groups of enemies and !TriggerOverride(LastSeenBy(Myself),Range(NearestEnemyOf(Myself)),20)) to avoid hurting allies. This can be done with ToBEx.

I'd consider single-target DM, tbh - would be both distinct from RM and also much easier to script for.

The party-friendliness is just a part of the problem. The other issue is that you don't want to dispel debuffs on enemy or buffs on allies, and this is where player gains substantial advantage over AI - it's exceedingly impractical to try and calculate the buff/debuff ratio within target AoE with IE's primitive scripting syntax.

There was a bad typo in the earlier code, which prompted me to use different name in SR's version in order to avoid installation crashes. I have either missed the fact that SCS wouldn't notice the new 2da, or there could have been another reason to let the issue lay. Memory insists it was the latter, but unfortunately I can't recall or imagine any such reason other than having simply messed it. In any case, thanks for bringing it up, otherwise I would have forgotten completely. PS After some thinking, it appears the best solution is to make it auto-updating, like WeiDU and ToBEx. It will certainly prove useful for... a certain reason.

Strictly technical explanation of how DS functions.

Frankly, right now I am terribly behind the train and out of the loop on what needs to be done and where. What I fixed was the Whether something should be done with SCS, Kreso or somebody equally informed would know better than me.

Dispelling Screen Since we apparently keep its DS stats unchanged, kill this in the main component: LAF ds_altered_spell INT_VAR old_clone=142 new_clone=~-1~ STR_VAR file=~spwi590.spl~ END and instead add this (once is enough): APPEND_OUTER ~spell_rev/lib/ds_sr_extra.2da~ ~spwi510.SPL 282 1 6 142 n A~ Spell Shield Find spell_rev/lib/ardanis_spell_shield.tph file, open it in any text editor, and find near the beginning this piece of code // DW code to detect what the icon for Spell Shield is (this is Fixpack-dependent) COPY_EXISTING - statdesc.2da override COUNT_2DA_ROWS 2 rowcount FOR (i=2;i<rowcount;i=i+1) BEGIN READ_2DA_ENTRY i 1 2 stringnum PATCH_IF stringnum=26228 BEGIN READ_2DA_ENTRY i 0 2 spell_shield_icon_num SET i=rowcount END END BUT_ONLY Add this line OUTER_SET spell_shield_icon_num = (MOD_IS_INSTALLED setup-bg2fixpack.tp2 0 || GAME_IS "bgee bg2ee iwdee") ? 73 : 123 just before the above mentioned code: OUTER_SET spell_shield_icon_num = (MOD_IS_INSTALLED setup-bg2fixpack.tp2 0 || GAME_IS "bgee bg2ee iwdee") ? 73 : 123 // DW code to detect what the icon for Spell Shield is (this is Fixpack-dependent) COPY_EXISTING - statdesc.2da override COUNT_2DA_ROWS 2 rowcount FOR (i=2;i<rowcount;i=i+1) BEGIN READ_2DA_ENTRY i 1 2 stringnum PATCH_IF stringnum=26228 BEGIN READ_2DA_ENTRY i 0 2 spell_shield_icon_num SET i=rowcount END END BUT_ONLY

This is purely a writing issue, not technical. You can't possibly be allowed to kill a plot character prematurely, if doing so may break the following plot. What can be done, is to revise the scene to keep the player out of control while the plot character is around. Preferably in a way that doesn't focus the attention on a fact you're in cutscene mode and your PC might be doing something against your will. Or provide a legal way to shield the boss from player attacks. Or something else. This is nowhere as simple as it may sound, and can go a long, long, long way until all the issues are resolved - sometimes never.

On which game are you trying to install? This is the main question, I think. Crevs, if you wanna handle it, that variable needs default value, probably differing between game platforms. IIRC I mentioned it earlier at some point, but don't remember any details. There will be detection issues if Slow/Haste/Imp Haste do not set the relevant state. It's not limited to RR either, it would likely affect SCS and BP as well, and even original AI in vanilla/EE. I think we can live with Imp Haste acting as normal Haste, but STATE_SLOW and STATE_HASTE need to be preserved in some way. As for the stacking with Boots of Speed, maybe just set the fixed movement rate for Haste? Similar to how cleric STR buffs can lower (can they actually?) the value, if it was higher than what spell sets it to. PfMW I mentioned the concern about normal weapons to aVENGER, and he said it's not a big deal if SR changes the behavior - he's got Wisp to do the dirty work on enhancing compatibility That said, I do understand why some see normal weapons as a legal counter, but it still doesn't address the matter of AI blissfully ignoring the fact - RR is just a droplet in a sea, it doesn't change the AI response on a global scale. And worse, it's not just a matter of AI itself, but also the enemy equipment. And for the record, I personally find it weird to loot two sets of weapons, if they were to carry both normal and enchanted. Besides, as I said above, I don't advocate irreversible change, only the default/assumed behavior when it comes to balancing - the .ini settings can be easily updated to include the normal immunity option, like any other controversial change.

I am not exactly alone in my feelings towards PfMW/normal weapons, so it's not just me being an odd one. While alternative tactical options is always good, it is specifically PfMW/normal weapons that was a really bad example of old-school design. Besides I do have an idea what a good rule system is, and AD&D 2 in not a good rule system. A compilation of random rules thrown together, great for the feeling of nostalgia - sure, but never a system. It's not the strong point of early editions. Also you might have missed the smiley.

Guilty as charged That's what I get for abandoning forums for too long Have you any idea how OP that would be ? It would be the same as it always was, but full immunity will fix the issue with aVENGER's AI, which exploits PFMW's current vulnerability to normal weapons. It should never have been doing such a thing in the first place Normal weapons are just too far specialized to be a well-designed balance element. I think the frustration some people (well, me) have over "must keep vulnerable to normal weapons" thing, it prevents from going a simple route of make PfMW fully immune and forgetting about liches, monks, ToB PCs and other non-existent (to those like me) issues. Of course, I would most definitely add an .ini option for purist players to toggle it, before anything else. The problem is, I don't have enough quick slots when IR is installed