Local Vars don't reset when a new save is loaded?

[Xaranth]

:wallbash:

 

Every time I think I've found the most ludicrous thing possible...

 

Now this. Is this a game bug, that if you load from the game menu, it doesn't reset localVars? Did I do some serious voodoo to make it do this?

 

Most importantly... How do I get around it?

 

Specifically. I have automatic lights going in my PH. Each room is bounded with a light switch trigger with the following script:

 

scn DARC07scptLightSwitch

ref rLink
ref rTrigger
short sInside

begin onTriggerEnter

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	Set sInside to sInside + 1
	if sInside == 1
		rLink.Enable 0
	endIf
endIf

end

begin onTriggerLeave

Set rTrigger to GetActionRef
Set rLink to GetLinkedRef

if rTrigger.isActor
	Set sInside to sInside - 1
	if sInside < 1
		rLink.Disable 0
	endIf
endIf

end

 

If I leave the common room and go to the kitchen, then reload the autosave... The lights in the kitchen and the common room stop working. The kitchen lights lock off, and the common lights lock on. ...Actually, that makes no sense at all. If the local vars were being carried across, shouldn't the kitchen lock on and the common lock off in that situation? ...Fuuuuuu I'm so screwed.

[Quetzlsacatanango]

I have seen something like that, in FO3 anyway.

Load cell

Walk through trigger, which enables baddie

Get killed by baddie

Reload autosave at beginning of cell

walk through trigger again, no baddie is enabled, doonce was not reset to 0

 

Game menu is not involved, but it is technically reloading a save.

[Xaranth]

After some more consideration and testing, I'm pretty sure what's happening is the TriggerEnter and TriggerLeave blocks are being triggered twice. Once pre-load and once post-load. Which also means I can't stick a prybar in there and use something with a wider scope so I have some finer control over the vars. But I can confirm that by sticking a debug quest in and using sqv. That I shall do. More reports soonish.

 

If I'm right about what's happening, getting around it is going to be... interesting. Maybe I can slap a warning in the readme, or is that cheating? :wallbash:

[Mishaxhi]

Definitely had this happen to me, but I was able to get them to set on command.

 

Was a var held in an actors object script and it seemed to reset after the first cell change when the save was loaded. I just said screw it and made it a global.

[rickerhk]

Yeah, I never quickload or reload from the menu, especially when testing.

[Xaranth]

Yeah, I never quickload or reload from the menu, especially when testing.

 

Well, if I HADN'T, this bug would have made it into the published version, sooo...

 

In any case, further testing indicates that there's some weirdness going on, but the enter/leave blocks are not firing, period. Which is as it should be.

 

Of course, a clean save load showed that the OnTriggerENter block of the light switch had been triggered 30 times by... something. Long before the cell was ever loaded. This. Makes. No. Sense. :wallbash:

 

And I could use a global, but then I'd have to differentiate the switch triggers for each room, which is something I was trying to avoid. I had enough of writing the same script over and over with my sorter. :)

 

Time for tobacco and more pondering. And I think I'll take a short break to fix the dishwasher again.

[Xaranth]

Revisiting.

 

Further testing has made me realize that this is what's happening.

 

FIRST: I was right about the load triggering the enter and leave blocks twice, once pre-load and once post-load.

 

SECOND: The reason I thought I was WRONG about this a post or two ago is because not only was it triggering those blocks twice for both triggers involved, it was also NUKING those triggers.

 

After the last test, I realized that for whatever reason, the game was eating my triggers when I loaded within the cell, so I set them to persistent. That didn't fix the whole problem, because my FIRST guess was also right and it is triggering each one twice. :wallbash:

 

Why do we like this game so much again?

 

Further developments as they come. I'm going to try adding an onLoad block to reinitialize all in/out vars and hope that a) It fires when reloading a savegame in the same cell and b) it fires BEFORE the onTriggerEnter block.

 

-X

[Quetzlsacatanango]

IIRC OnLoad works when loading 3d data, I do not know if a trigger box qualifies. I would like to know though!

[Xaranth]

Further developments.

 

The OnLoad block kludges around the issue. It's still PRESENT, but using onLoad means that it doesn't blow up permanently, at least.

 

onLoad doesn't trigger with a reload, but if I go off and run around long enough to unload the bunker cell, when I go back, the lights are working again. I wonder what would happen if I triggered the issue, killed the game, and reloaded from the desktop with the fault active. That'll be the next test.

 

I'm pretty sure now that this problem is caused by a load-accelerator. As to solutions, I'll figure SOMETHING out.

 

This problem needs a bigger pot of coffee.

Edited November 30, 2012 by Xaranth

[Xaranth]

IIRC OnLoad works when loading 3d data, I do not know if a trigger box qualifies. I would like to know though!

 

Triggers have 3D data: Origin and bounds. Just no meshes, textures or collisions.

 

...Now this is just WEIRD. Reloading from the desktop caused the Armoury's onLoad block to fire, but NOT the Common Room's, despite the facts that aside from using a different questvar, the trigger scripts are identical.

 

Wall, meet forehead. Again.