[code] Code fixes, aka stuff we can't fix

[Bubb]

9 minutes ago, argent77 said:

For some reason the result of this action was picked up correctly in the same script round in my tests.

Never mind, I was only looking in the inventory, not the ammo slots. I misremembered the globals behavior – subsequent triggers in the current script pass can't see the results of actions, (as the actions haven't run yet), but subsequent actions obviously can.

[Luke]

24 minutes ago, argent77 said:

For some reason the result of this action was picked up correctly in the same script round in my tests.

 

You could run the actions in two script passes:

IF
  OnCreation()
  !Global("DoIt","MYAREA",1)
THEN
  RESPONSE #100
    SetGlobal("DoIt","MYAREA",1)
    Continue()
END

IF
  Global("DoIt","MYAREA",1)
THEN
  RESPONSE #100
    SetGlobal("DoIt","MYAREA",0)
    // Your actions...
    Continue()
END

*The Continue()s are not strictly needed but recommended for compatibility reasons.

It seems it does not work the very first time it triggers... Weird... I fear I'm still missing something...

Tested with "FIREB1.CRE"... The first time the inn is visited the script runs fine, but when I CTRL-Q him in the party, he has nothing in his inventory... However, if I exit the inn and renter, then when I CTRL-Q him in the party, he has the specified amount of arrows...

Spoiler

APPEND "rndtres.2da" "GTTEST AROW04 AROW08 AROW09"
  
COPY_EXISTING "FIREB1.cre" "override"
  REPLACE_CRE_ITEM "gttest" #99 #0 #0 "identified&unstealable&undroppable" "quiver"
BUT_ONLY
  
  // The script itself

IF
	OnCreation()
	!Global("DoIt","MYAREA",1)
THEN
	RESPONSE #100
		SetGlobal("DoIt","MYAREA",1)
		Continue()
END

IF
	Global("DoIt","MYAREA",1)
	HasItemEquiped("arow04",Myself)  // Acid Arrow +1
THEN
	RESPONSE #100
		SetGlobal("DoIt","MYAREA",0)
		SetGlobalRandom("gtcount","LOCALS",1,10)
		CreateItemGlobal("gtcount","LOCALS","arow04")  // Acid Arrow +1
		Continue()
END

IF
	Global("DoIt","MYAREA",1)
	HasItemEquiped("arow08",Myself)  // Arrow of Fire +2
THEN
	RESPONSE #100
		SetGlobal("DoIt","MYAREA",0)
		SetGlobalRandom("gtcount","LOCALS",1,10)
		CreateItemGlobal("gtcount","LOCALS","arow08")  // Arrow of Fire +2
		Continue()
END

IF
	Global("DoIt","MYAREA",1)
	HasItemEquiped("arow09",Myself)  // Arrow of Ice
THEN
	RESPONSE #100
		SetGlobal("DoIt","MYAREA",0)
		SetGlobalRandom("gtcount","LOCALS",1,10)
		CreateItemGlobal("gtcount","LOCALS","arow09")  // Arrow of Ice
		Continue()
END

 

 

Edited July 29, 2023 by Luke

[Luke]

@jastey

Could you please move the last posts about CreateItemGlobal() into a separate thread in the modding Q&A subsection? Thanks.

[jastey]

Starting where?

[argent77]

11 hours ago, Luke said:

It seems it does not work the very first time it triggers... Weird... I fear I'm still missing something...

Tested with "FIREB1.CRE"... The first time the inn is visited the script runs fine, but when I CTRL-Q him in the party, he has nothing in his inventory... However, if I exit the inn and renter, then when I CTRL-Q him in the party, he has the specified amount of arrows...

It looks like you stumbled upon another bug. The item from the first call of CreateItemGlobal() is created in the magical weapon slot, and only subsequent calls to CreateItemGlobal() will create the item in accessible inventory slots (starting in the last inventory slot). You can test it by adding duplicate CreateItemGlobal() calls to the script blocks in your example script, save the game and inspect Firebead's inventory in NI.

[Luke]

2 hours ago, jastey said:

Starting where?

Nevermind, It turned out to be and engine bug... As a result, It should remain in this thread...

[Luke]

4 hours ago, argent77 said:

It looks like you stumbled upon another bug. The item from the first call of CreateItemGlobal() is created in the magical weapon slot, and only subsequent calls to CreateItemGlobal() will create the item in accessible inventory slots (starting in the last inventory slot).

Indeed.

Well, It can be worked around with GiveItemCreate() and multiple response blocks... The only issue is that it is a bit inelegant...

Will add it to my to-fix list...

[argent77]

There is a bug in the INI processing mechanism for spawning creatures. The "events" key in the [spawn_main] section is supposed to accept a comma-separated list of group section names. However, only the last entry in the list is apparently considered by the engine.

Bubb confirmed this issue as a buggy implementation in the engine itself:

Quote

The engine is supposed to parse all sections listed in the events= key, but due to a bug it only parses the last one. (It reads the string correctly, but then fails to iterate the sections – it starts at the last section name and attempts to iterate forward, which is the wrong direction).

This bug currently impacts IWD:EE map AR8005 (Lower Dorn's Deep building, ground floor) where creature spawns are defined that are supposed to be triggered whenever the Shriekers detect an intruder. As it is currently scripted, the Shriekers are basically pointless since they don't do anything harmful (except maybe getting on the player's nerves with their constant shrieking).

[argent77]

On 3/19/2022 at 11:18 PM, CamDawg said:

I'll start with an oldie but goodie: using the auto-pause for 'spell cast' causes all sorts of issues. To replicate, start an IWDEE game with a druid and at least one other character. Memorize some Sunscorch spells on your druid, rest your party, and enable 'Spell Cast' on the auto-pause menu. Cast Sunscorch on the other party member.

Pausing on the moment the spell is cast causes each individual effect in the spell to be rolled separately for saves and probability.

The (auto-)pause feature also seems to affect area background animations that consist of multiple parts. They will eventually go out of sync when the pause feature is used frequently. A good example are the swinging chains in the PST Modron Maze boss room (AR13WZ).

[CamDawg]

The gift that keeps on giving!

[Galactygon]

I think @Sam. already recombined all the area animations, including the PST:EE ones.

[argent77]

1 hour ago, Galactygon said:

I think @Sam. already recombined all the area animations, including the PST:EE ones.

You're right, there is already an animation fix (#1, #2). But it looks like the commit lacks the code for applying the fix to PST:EE.

[Sam.]

5 hours ago, argent77 said:

You're right, there is already an animation fix (#1, #2). But it looks like the commit lacks the code for applying the fix to PST:EE.

I fixed all of the split animations @Galactygon and I could find in BGEE/SoD/BG2EE/PSTEE, except for AM3017[A-D] and AM6200[A-D]. Those are the Machine of Lum the Mad (which I don't think should be combined) and Melissan replenish (I don't understand the mechanisms of how/when these are played).  From PSTEE I believe I did:

Spoiler

A0508BL[2-4]
A0508TR[1-2]
A1201G1[LR]
A1201G2[LR]
A1201G3[LR]
A1202GB[1-4]
A13WZC2[AB]
A13WZC[AB]

It's always possible I've missed some, in which case if you get me a list I'll be happy to do them.

Edit:  I reread the last post for a third time and realized you may be saying the corrected animations for PSTEE have been committed but just aren't installed for that game yet, in which case nvm.

Edited January 5 by Sam.

[argent77]

9 minutes ago, Sam. said:

From PSTEE I believe I did:

  Reveal hidden contents

A0508BL[2-4]
A0508TR[1-2]
A1201G1[LR]
A1201G2[LR]
A1201G3[LR]
A1202GB[1-4]
A13WZC2[AB]
A13WZC[AB]

It's always possible I've missed some, in which case if you get me a list I'll be happy to do them.

Yes, the fixed BAM resources were already present in EEFP. However, they were not installed because the relevant WeiDU code was missing for PSTEE. This commit should fix it.

[argent77]

I have noticed another peculiar behavior of the PSTEE engine variant. It looks like the max. range of ranged spells or abilities is only considered by the engine after entering a new area. If you save and reload then the engine appears to limit the range to the visual range of characters in the BGEE engine (which is smaller than the visual range in PSTEE) until you enter a new area.

Edit: I think this is caused by the effective visual range of creatures which is reduced to the visual range of the BGEE engine after a reload. It seems to affect everything (even the scripting of creatures to detect enemies) except the range for clearing the fog of war which still works correctly.

Edited January 7 by argent77