Custom area - actors bunched at the far left

[cmorgan]

Well, I have a head-scratcher. Very occasionally I have had reports that revisiting my custom Inn on the Promenade finds the .cre bunched up against the wall. It sounds like something is not saving the spawned .cre locations after the first visit. 

I have not not been able to reproduce this locally on BG2 or BG2EE, so I can’t see what is wrong. Any ideas on what would cause this behavior?

[Jarno Mikkola]

Do they have RandomWalk() in their scripts ?

Maybe they were all created from the same .cre file and thus inherit the very same .cre's 0x0010 flags at 24 - 30, which could theoretically just send the one creature, in this case all of them, to the same location. ...so just remove the RandomWalk() .

[Guest amellg]

I have met the same problem while playing Aran mod. It happens like this:

Start a new game > enter the inn > exit the inn and take a rest at somewhere else > re-enter the inn, and find NPCs gathering in the corner.

[cmorgan]

Well, they all have definitely been created from the same .cre - I do

/* Area C-AW01 Tavern Keeper - Orrin */
COPY_EXISTING ~kpgrd01.cre~	 ~override/c-aw01tk.cre~
	REMOVE_CRE_ITEM ~rndtre02~
	LAUNCH_PATCH_MACRO ~support_cre_cleanup~	
	SAY NAME1 @142
    SAY NAME2 @142

The support_cre_cleanup is supposed to clear the creature - but perhaps it doesn't clear the flags.

 

The biggest challenge - all of the area .cres have no actual script (the name is assigned to the cre to blank out reference to any old ones, but no new script is compiled or needed).

 

I will recheck and see if I can replicate and troubleshoot using Amellg's procedure above - thanks!!

Edited January 2, 2019 by cmorgan

[cmorgan]

Hmmm. Masterasre.2da, .wed, and .tis for C-AR01 found - but NI says there is no area C-AR01. Which is odd, because it exists. Checking with DLTCEP. Perhpas something is going odd with the game storage.

 

 

....and DLTCEP says some odd things. Like "Destination 0 0" . Have to go spelunking.

 

Edited January 1, 2019 by cmorgan

[Ardanis]

5 hours ago, cmorgan said:

"Destination 0 0"

That sounds familiar. Actors will appear at their destination coordinates rather than current ones when the game is saved and reloaded. Namely, JumpToPoint() can cause that, as unlike MoveToPoint() it only updates the current coordinates but not destination.

Are your actors spawned via scripts, or embedded into ARE? Any scripted positioning involved?

 

[cmorgan]

Heh. Apparently, both .

So looking at the current code, apparently I decided to create the creatures using the above code, but the area uses both a script added joinable and a .cre handle in the .are

For Aran himself, in C-AR01.BCS

/* create Aran, cue up scenery dialogs */
IF
  Global("c-aranspawn","C-AR01",0)
  !Exists("c-aran")
THEN
RESPONSE #100
  CreateCreature("c-aran7",[976.306],6)
  SetGlobal("c-aranspawn","C-AR01",1)
  RealSetGlobalTimer("c-scenery","GLOBAL",60)
END

(Mike1072, +500 points if you can attach .d and .baf syntax highlighting to the code box!!!)

But it looks like I decided to create the creatures using the above and to add the references to the actual area file. It has the .cre reference, a facing, and a position, but the destination is 0 0 (which may be me thinking back in the day that there was no destination, so it should be 0...)

DLTCEP opening the uninstalled original resource shows that I have added the actors to the area but not embedded them, I assume because they are created on install by copying and modifying original resources based on platform.  In that uninstalled file there are several of the 0 0 entries; there is a button next to it that says something like "stay in place". Hitting that populates the boxes with the same actor positions. Hopefully this was the modder error that is causing this.

 The area .bcs does simple calls, no JumpToPoint() or RandomWalk() - just some blocks like this:

/*  smalltalk, randomized blocks, cyclical */ 
IF
  AreaCheckObject("C-AR01",Player1)
  RealGlobalTimerExpired("c-scenery","GLOBAL")
  Global("c-smalltalk","C-AR01",0)
THEN
RESPONSE #20
  SetGlobal("c-smalltalk","C-AR01",1)
  RealSetGlobalTimer("c-scenery","GLOBAL",60)
RESPONSE #20
  RealSetGlobalTimer("c-scenery","GLOBAL",60)
  SetGlobal("c-smalltalk","C-AR01",1)
  Wait(2)
  DisplayStringHead("C-AW01W1",@12970)
  Wait(2)
  DisplayStringHead("C-TORAN",@12971)
RESPONSE #20
  RealSetGlobalTimer("c-scenery","GLOBAL",60)
  SetGlobal("c-smalltalk","C-AR01",1)
  Wait(2)
  DisplayStringHead("C-AW01W1",@12972)
  Wait(2)
  DisplayStringHead("C-AW01TK",@12973)
  Wait(2)
  DisplayStringHead("C-AW01W1",@12974)
  Wait(2)
END

 

Thanks for the check-in and ideas on this. I will test this tomorrow - I really hope this is just as simple as me not understanding  using DLTCEP to modify areas... either way i will be back to report!

[cmorgan]

....and ok, I think this was area creation messup. Thank you @Jarno Mikkola, @Ardanis, @amellg assistance

Repaired distributed C-AR01 to have corrected "stay in place" values using DLTCEP,  test installed on BG2EE, rechecked using above procedure and did not have actor movement. Rechecked installed area in NI and DLTCEP and manually wandered around triggering dialogue and letting the area script dialogues run, exited and rested and re-entered - everyone still in the right area. 

https://github.com/cmorganbg/Aran-Whitehand/commit/e01d6ffbc555994b99e5d1b18eec155aced1a211

https://github.com/cmorganbg/Aran-Whitehand/commit/0d1f290b7bc30a13631de4606cf91dcca871aec4

https://github.com/cmorganbg/Aran-Whitehand/commit/7799a9c3441046646eddee0ff600dac087329806