121 replies to this topic

[Jarno Mikkola]

You might have better luck on CLUAConsoling the creatures...

[OneEyedPhoenix]

You might have better luck on CLUAConsoling the creatures...

I'd rather fix the script if possible, so that it can be fixed in BGT1.08. (Haven't done a changelog yet, but I'm 95% certain that this is BGT)

[Miloch]

You might have better luck on CLUAConsoling the creatures...

Why would he? This would just kill them, and since there's no death check, it'd keep trying to kill them even after they're dead.

Will try adding "!Dead("Xzar")" as soon as I get the chance.

To be clear, I mean add !Dead("Montaron") to the Montaron block and !Dead("Xzar") to the Xzar block triggers.

[OneEyedPhoenix]

To be clear, I mean add !Dead("Montaron") to the Montaron block and !Dead("Xzar") to the Xzar block triggers.

Obviously, but at least you saved me the time of typing it out.
Didn't work though...

[Miloch]

Didn't work though...

Hmm, maybe Exists() doesn't work like it says it does, though that's unlikely. You could try doing a GetGlobal("SPRITE_IS_DEADxzar","GLOBAL") in the console - should be 1 if his death variable was set. One way to get around it is with a variable check, such as setting the DV manually.

IF
  GlobalGT("Chapter","GLOBAL",3)
  InActiveArea("Montaron")
  !InParty("Montaron")
  !Dead("Montaron")
  Global("SPRITE_IS_DEADmontaron","GLOBAL",0)
THEN
  RESPONSE #100
	SetGlobal("SPRITE_IS_DEADmontaron","GLOBAL",1)
	ActionOverride("Montaron",DestroySelf())
END

IF
  GlobalGT("Chapter","GLOBAL",3)
  InActiveArea("Xzar")
  !InParty("Xzar")
  !Dead("Xzar")
  Global("SPRITE_IS_DEADxzar","GLOBAL",0)
THEN
  RESPONSE #100
	SetGlobal("SPRITE_IS_DEADxzar","GLOBAL",1)
	ActionOverride("Xzar",DestroySelf())
END

Edit: DestroySelf() doesn't set a DV, so that could be the problem too, and another reason for setting it manually.

Edited by Miloch, 30 September 2009 - 04:30 AM.

[Wisp]

IF
  !Dead("Montaron")
  Global("SPRITE_IS_DEADmontaron","GLOBAL",0)

Those two triggers are identical, or rather, the global check is redundant.
Besides, I don't think this script was meant to kill them. It was meant to simulate them leaving the region once the troubles in Nashkel were taken care of (like Jaheira and Khalid also does).

[Miloch]

Those two triggers are identical, or rather, the global check is redundant.

Yeah, I figured it could be trimmed down a tad, but I don't suppose it hurts having a bit of redundancy until we rule out what's causing the loop.

Besides, I don't think this script was meant to kill them. It was meant to simulate them leaving the region once the troubles in Nashkel were taken care of (like Jaheira and Khalid also does).

In that case, EscapeArea() is probably more realistic. Deactivate() could work too, but CREs can still run scripts when deactivated.

IF
  GlobalGT("Chapter","GLOBAL",3)
  InActiveArea("Montaron")
  !InParty("Montaron")
  !Dead("Montaron")
  Global("BGTmont","GLOBAL",0)
THEN
  RESPONSE #100
	SetGlobal("BGTmont","GLOBAL",1)
	ActionOverride("Montaron",EscapeArea())
END

IF
  GlobalGT("Chapter","GLOBAL",3)
  InActiveArea("Xzar")
  !InParty("Xzar")
  !Dead("Xzar")
  Global("BGTxzar","GLOBAL",0)
THEN
  RESPONSE #100
	SetGlobal("BGTxzar","GLOBAL",1)
	ActionOverride("Xzar",EscapeArea())
END

[OneEyedPhoenix]

I am able to shed some more light on this now.
It appears that I left both Xzar and Montaron alive in this area. When I walk over to where I first encountered them I find Xzar alive and well, but no Montaron.
This means that "ActionOverride("Xzar",DestroySelf())" doesn't block the script. Alternate solutions?

[Miloch]

When I walk over to where I first encountered them I find Xzar alive and well, but no Montaron.

I suspect this is because the Montaron block is looping, making Montaron destroy himself repeatedly (whether he is or not) because there's no check to see if it's already executed. Thus the Xzar block won't fire, as I said above.

Change it to what I posted above. If you like, you can use DestroySelf() instead of EscapeArea(). The important part is having the variable checks in there to make sure the blocks don't loop.

[OneEyedPhoenix]

I suspect this is because the Montaron block is looping, making Montaron destroy himself repeatedly (whether he is or not) because there's no check to see if it's already executed. Thus the Xzar block won't fire, as I said above.

Change it to what I posted above. If you like, you can use DestroySelf() instead of EscapeArea(). The important part is having the variable checks in there to make sure the blocks don't loop.

Yup, my thoughts as well. Strange logic that "DestroySelf()" doesn't block "Exists" though...
Is there another code that would block "Exists"? Obviously we could put in a script block variable, but if there is a way to block "exists" it would be more neat.

Edit: Changing "Exists" to "InActiveArea" prevented the blocks from firing more than once (and removed the duo from the area). The stutter didn't go away though, unlike when I removed the blocks completely... Will do some more testing.

Edited by OneEyedPhoenix, 30 September 2009 - 08:15 AM.

[Miloch]

Is there another code that would block "Exists"? Obviously we could put in a script block variable, but if there is a way to block "exists" it would be more neat.

No, it wouldn't... trust me, the variable is the best way to go for something like this. Scripts cycle so fast it has the chance to lag or stutter otherwise, because the CREs may not have finished executing their last commands.

[Hoppy]

Is there another code that would block "Exists"? Obviously we could put in a script block variable, but if there is a way to block "exists" it would be more neat.
Edit: Changing "Exists" to "InActiveArea" prevented the blocks from firing more than once (and removed the duo from the area). The stutter didn't go away though, unlike when I removed the blocks completely... Will do some more testing.

Will a Continue() work on one of those? The original BG script has continue after the Monty block. Probably the same could be done with Miloch's edit. That won't keep the scripts form looping but it may keep them moving instead of sticking on one block. Also the original looks a little different but the Continue() may help clear the lag.

IF
	GlobalGT("Chapter","GLOBAL",2)
	Exists("Montaron")
	!InParty("Montaron")
THEN
	RESPONSE #100
		ActionOverride("Montaron",DestroySelf())
		Continue()
END

IF
	GlobalGT("Chapter","GLOBAL",2)
	Exists("Xzar")
	!InParty("Xzar")
THEN
	RESPONSE #100
		ActionOverride("Xzar",DestroySelf())
END

Edited by Hoppy, 30 September 2009 - 09:53 AM.

[OneEyedPhoenix]

Hm, changing "exists" to "InActiveArea" so far seems the most effective and least intrusive solution.
The stutter didn't go away completely, but the remaining stutter wasn't caused by a looping script.
No other solution, except leaving the area, removed the stutter completely.
Haven't been able to pinpoint the source of the remaining lag so far. Suggestions?

Edit: The strangeness continues! Importing my savegame into ToB now leaves three of my party standing in ar6600, while the other three show up where they are supposed to... But it did nothing for my stutter.

Edited by OneEyedPhoenix, 30 September 2009 - 11:11 AM.

[Miloch]

Will a Continue() work on one of those? The original BG script has continue after the Monty block.

Continue() is rarely desirable - probably why it was removed. If none of the triggers evaluate to True, it won't execute and parse to the next block anyway, which is what you want here.

Suggestions?

You've had suggestions. Did you *try* the script blocks, exactly as I posted (the 2nd edit above)? In other words, with the variables?

Also, did you try editing, compiling the script and then entering with a saved game from before you entered the area (in the current chapter anyway)? You could have some leftover funk, since areas get saved in save games (but not scripts).

You might also want to post or attach the full area script if you haven't.

[OneEyedPhoenix]

You've had suggestions. Did you *try* the script blocks, exactly as I posted (the 2nd edit above)? In other words, with the variables?

Also, did you try editing, compiling the script and then entering with a saved game from before you entered the area (in the current chapter anyway)? You could have some leftover funk, since areas get saved in save games (but not scripts).

You might also want to post or attach the full area script if you haven't.

I didn't try the blocks exactly like you posted, no, but i did try to put in blocking globals and they worked in just the same manner as "InActiveArea". I even tried removing the blocks completely, which left the duo and the stutter.
I tried changing the script before entering in the current chapter, but it made no difference from a save in the area.
All I have to go on so far is that the remaining stutter is not caused by a looping script, that it's area specific and that it seems to go away when I move towards the left edge of the map.

Edited by OneEyedPhoenix, 30 September 2009 - 09:50 PM.

[OneEyedPhoenix]

No need to worry about the remaining stutter. It was caused by non-existing ambient sounds.

[Hoppy]

No need to worry about the remaining stutter. It was caused by non-existing ambient sounds.

How did this happen?

[OneEyedPhoenix]

How did this happen?

I had somehow missed the "disable all ambient sounds" option, so it had been enabled up to this point. No problem with it up till now though.
After I fixed the script and disabled these sounds everything runs smoothly.

Edited by OneEyedPhoenix, 30 September 2009 - 09:49 PM.

[Miloch]

No need to worry about the remaining stutter. It was caused by non-existing ambient sounds.

I thought BGT fixed all the non-existing ambients - at least that's what some code plainab/Sasha and I wrote seemed to indicate, except for just a couple mods. Do you know which ones were causing the problem?

[OneEyedPhoenix]

No need to worry about the remaining stutter. It was caused by non-existing ambient sounds.

I thought BGT fixed all the non-existing ambients - at least that's what some code plainab/Sasha and I wrote seemed to indicate, except for just a couple mods. Do you know which ones were causing the problem?

No, I just know that i had the problem in this area and ar8800 (cloackwood2). How would I go about pinpointing the problematic sound?