[(BG1\2) BUG] nthNearestEnemyOfType objects (51-59) not working properly. (0813)

AndreaColombo

Originally posted by devSin in this thread. Since devSin won't beta test BG:EE, I thought I'd report his request here and atomize it for the devs' convenience.

CURRENT BEHAVIOR:

The nthNearestEnemyOfType objects (51-59) all return the nearest matching object.


EXPECTED BEHAVIOR:

They should correctly return the nth-nearest matching enemy of the caller.

SethDavis

nvm - a bit crazy in there for me

AndreaColombo

@SethDavis - Unfortunately, my IE expertise is too limited to even understand the contents of my post. I just barely cut&pasted what devSin said. You can either PM devSin and ask him directly, or... I could start dropping names like @cmorgan, @CamDawg and @Wisp to see if they can help you

CamDawg

Looks like @SethDavis may have gotten it already before I arrived. All of these objects:

51 SecondNearestEnemyOfType
52 ThirdNearestEnemyOfType
53 FourthNearestEnemyOfType
54 FifthNearestEnemyOfType
55 SixthNearestEnemyOfType
56 SeventhNearestEnemyOfType
57 EigthNearestEnemyOfType
58 NinthNearestEnemyOfType
59 TenthNearestEnemyOfType

all return the

50 NearestEnemyOfType

edited to EnemyOfType, since I can't read.

SethDavis

Well, it'll be educational at the very least

Wisp

@CamDawg
devSin says *EnemyOfType and you say *EnemyOf, which is it? I have never noticed any problems with *EnemyOf (and I certainly hope they are functional, as both SCS/SCSII and aTweaks make extensive use of them), but then, I can't say I have ever specifically tested this aspect of the objects.

CamDawg

I'm not sure this is an A issue, at least not right now. Fixing engine bugs is great, but these broken triggers are not currently used in BGEE at all, outside of Overhaul's mystery OH scripts.

CamDawg

Whoops, yeah, it's EnemyOfType. Still, this shouldn't be an A issue at the moment.

Cuv

dang you guys are fast... made a script to test this

   
IF
        See(ThirdNearestEnemyOfType([0.UNDEAD]))
THEN
	RESPONSE #100
		MoveToObject(LastSeenBy(Myself))
END

So I should be moving to the third zombie (which I am using as my example... but I am moving to the front zombie.

@Wisp it appears to be just the nthNearestEnemyOfType with the problems so far as I can tell

cmorgan

Late to the party. What they said. Might be nice to have it work, but unless there is a really fancy cutscene or someone is seriously messing with AI scripting, it seems not as pressing.

Avenger_teambg

Other than declaring these triggers officially broken

AndreaColombo

I agree. These engine bugs are probably better off in the "B" category.

Cuv

Okay, I have a more practical script you can use to test. This one just displays headstrings. Since there arent any debug strings (I would like to request some at some point)... it will display +3 vs lycanthropes sword name. I had a whole script with different names... but chopped it down because it always displays the string on the closest creature. If you can get it to display on the third creature... then it will be fixed:)

   
IF
        HotKey(D)
THEN
	RESPONSE #100
		ActionOverride(ThirdNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,6740))
		DisplayStringHead(Myself,6740)
END

Just assign this BS to your character, create some zombies and run around until you get them nicely spread out... then hit the "D" key. The string will display on your character and on one of the zombies.

Edit: @AndreaColombo also posted this which is similar and with minor changes you can use this script to test that also. http://forum.baldursgate.com/discussion/1674/bg12-bug-nthnearestmygroupoftype-objects-61-69-not-working-properly#latest

SethDavis

Potentially fixed - The nthnearestenemyoftype functions now check for enemy, rather than alignment cutoffs. Tested using @Cuv 's script and instruction.

Avenger_teambg

@SethDavis, does that still mean, enemy for an ENEMY is a PC?

SethDavis

@Avenger_teambg - That... is an excellent question....

Ok, PC's and Allies will now check for enemy while Enemies will check in reverse. Are there any Neutral battle scripts that would complicate this?

Avenger_teambg

Confirmed fixed - with note: If there are not enough enemies, it will be the last possible one.

Tanthalas

I have no idea how to test this one.

Cuv

LOL... I am about ready to post my findings and both of you post on something I never would have expected:P
I tried to get the screenshot as the headstrings displayed... but they were correct.

Confirmed Fixed!!!! Huzzah!

@Tanthalas You can use something like this for the other NTH objects... but I suspect they are also fixed.

   
IF
        HotKey(D)
THEN
	RESPONSE #100
	        ActionOverride(NearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~Nearest~))
		ActionOverride(SecondNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~SecondNearest~))
		ActionOverride(ThirdNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~ThirdNearest~))
                ActionOverride(FourthNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~FourthNearest~))
                ActionOverride(FifthNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~FifthNearest~))
                ActionOverride(SixthNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~SixthNearest~))
                ActionOverride(SeventhNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~SeventhNearest~))
                ActionOverride(EigthNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~EighthNearest~))
                ActionOverride(NinthNearestEnemyOfType([0.UNDEAD]),DisplayStringHead(Myself,~NinthNearest~))
END

@cmorgan, @jcompton or @camdawg - What is the WeiDU COMPILE command for a BS? I just used BCS and then manually changed the extension after it compiled. I needed the test strings.

Tanthalas

Well, with your confirmed fixed there's two already so I don't need to try and figure it out. \o/

Cuv

@Tanthalas Weren't there some other NTH bugs? Thought there were.

Tanthalas

@Cuv and @Avenger_teambg

Do you think this lingering problem mentioned by Avenger_teambg

If there are not enough enemies, it will be the last possible one.

Means this is still broken?

EDIT: Because then I'll move this to Confirmed not fixed.

Avenger_teambg

I don't know if it is a bug or not. I never used this object. I just noted this feature so it could be later documented in IESDP.

cmorgan

@Cuv - I'm sorry - I work with weidu and add a test.cre in. i never use .bs or assign keys; I want my "toolkit .cre" to remind me which thing I want to accomplish, and get confuced as to what script I want to run and what key it needs and what it does...

Cuv

@Tanthalas My headstrings showed the proper strings on each one.. will run another test with just six and see what I get.

Cuv

@SethDavis There still seems to be a problem with the last checked. I only have 6, the battle log showed all nine entries.. need to double check what else it keyed on. In the screenshot the first 5 are absolutely correct, but not that last one... the NinthNearest. Should return SixthNearest.

@Avenger_teambg I don't think anyone ever used this function as it never worked even close to this good in vanilla BG1 or BG2. It's certainly useable now though... and I can't wait to make use of it. If the Ninth nearest cant be fixed.... then we can adapt and just put that in as the default last possible.

Cuv

@cmorgan So there isn't a WeiDU command for compiling a BS? A player script?

SethDavis

Hmmmm, we shall see what I can do

cmorgan

Cuv, there probably is, but I don't see it in the docs. Better get a script-guru to say for sure. From what i see, compiling it as a .bcs and then renaming it looks like it would do the trick.

Cuv

Thankies:) Not a very big deal, just trying to stay sorta clean with my weidu bgee patching.

Wisp

@Cuv
There is nothing for compiling straight into BS, since BS is identical to BCS save for the extension. If you are concerned about leaving a BCS in the override, you can use MOVE. You can also juggle it in memory as an inlined file, but that may be more bother than it is worth.