Luke

I guess the main reason is that @DavidW hasn't found the time to play the game yet.... If you look at the scripts and compare them, you'll notice SCS ones are superior (generally speaking...)

@DavidW I think there's actually a tweak that could be made optional (or, rather, it should not be installed by default). I'm talking about "Make elemental arrows like BG2 (TUTU,BGEE)" Why is it installed by default? I mean, I don't think it is related to neither "Smarter Mages" nor "Smarter Priests" (i.e., the two components that mainly rely on the changes listed under "Universal Changes")... In other words: unlike the other tweaks, this one should break nothing (AI-wise), so I can safely ignore it... I find it similar to "Move or modify some overpowered magic items (BG2,BG2EE,EET)" or "Reduce the power of Inquisitors' Dispel Magic": as a result, it should be prompted to the user during the installation instead of being an ini option...

Please, enlighten me.... I mean, if you cannot damage the tank with your weapons, why should you stop from pelting the mage? Because in so doing the Mordekainen's Sword and similar would be useless? Mmmh...

I was not suggesting that... I was simply saying Beamdog should implement those two triggers, they'll (hopefully) eliminate the edge case (probably not so "edge"...) me and DavidW were talking about.... Moreover, they'll simplify the so called "weapon handling", i.e., it'll be easier to script enemies that have more than one type of ammo and so fourth...

Yeah, sorry, I meant BIT1 of the upper word of the 'Type' field...

You meant BIT1, didn't you?

Good point, but it remains exploitable => I can simply send in the Mordekainen's Sword and order everyone else to attack with a ranged weapon... These two triggers will hopefully solve this issue (provided they get implemented...) WeaponEffectiveVs(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*) WeaponCanDamage(O:Object*,I:WeaponNum*SLOTS,I:AbilityNum*) They are meant to return true if the active creature can hit/cause non-zero damage to the target object specified in the 1st parameter using the weapon located in the specified slot and considering the ability in the extended header specified by the ability parameter.

@temnix I don't think that will work... I'm fairly confident it's some hidden mechanics behind 'AttackReevaluate()' that is preventing my CRE from switching targets... I'd like to ask @Galactygon for some help... It seems he already bumped into this issue some time ago...

As you probably know, creatures currently executing an 'AttackReevaluate()' action won't switch target unless they're forced to move in order to attack their target. This is particularly relevant for ranged creatures (since unlike melee attackers they usually don't chase their target) => As a result, you need to execute a 'ClearActions(Myself)' command in order to stop 'AttackReevaluate()' and look for another valid target. The problem is that it doesn't seem to work in my case.... I'd like to summon @DavidW since he uses this technique quite often in SCS.... Sample script below: The problem is that the CRE in question keeps attacking always the same target, even if someone else is closer than the current target ('NearestEnemyOf(Myself)' is the most important target). It will switch target only after the timer "stayontarget" has expired... But SCS ranged creatures constantly switch targets (even if the timer has not expired yet). How do you manage to achieve that?

Well, fortunately there's a workaround

Even when editing existing resources? I mean, in this case I basically intend to edit just a couple of things regarding the existing descriptions.... And I'd like to avoid generating a new string for such a small change... But I'll probably reconsider this idea since many people are suggesting to create new strings...

But I cannot use that command inside a COPY_EXISTING_REGEXP or a patch..... In other words: how should I edit the aforementioned macro in order to use STRING_SET_EVALUATE in place of SAY_EVALUATED?

I'd like to know something about how you use these two triggers. Do you actually trust them? I mean, they're great if the CRE in question has only one weapon, but what if it has 2 weapons with different enchantment levels (offset 0x60)? For instance, let's consider DW2RP2GE.bcs (in particular a script block like the one in the spoiler tag below) and a CRE with ranged and melee weapons (e.g., ORC02.cre, BG2EE – its melee weapon 'SW1H07' is not magical, its ammunitions 'AROW02' are magical +1). If the currently equipped weapon is BOW03.itm with its corresponding ammo (AROW02) and 'NearestEnemyOf(Myself)' happens to be immune to normal weapons (op=120, param#2 = 2), then 'WeaponEffectiveVs(NearestEnemyOf(Myself),MAINHAND)' and 'WeaponCanDamage(NearestEnemyOf(Myself),MAINHAND)' will return true (because 'AROW02' is magical +1) => BUT its melee attacks will be ineffective (because SW1H07 is a normal weapon). To sum up: the problem is that these two triggers always refer to the currently equipped weapon and this weapon may have a different enchantment level from the one you're gonna equip – Am I missing something? If not, how do you prevent this situation from happening without using custom spell states?

I was talking about replacing this line SAY_EVALUATED index ~%new_desc%~ with something else so as not to generate a new string (e.g., via using STRING_SET_EVALUATE). But as @DavidW said, that command is an action command, not a patch one: that's why it's not working (and probably there's no alternative.....)

No. If a certain mod overwrites an existing string via STRING_SET (or STRING_SET_EVALUATE) and then you uninstall that mod, the original content of that string is restored.