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

[llamaRCA]

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.

 

Ya, it's unreliable and what's worse, it's unpredictable (or at least that's what I found). I'd recommend going with something that gives you more control like switches so the player has control in the game so the performance can be relied on to be the same each and every time.

[Xaranth]

Ya, it's unreliable and what's worse, it's unpredictable (or at least that's what I found). I'd recommend going with something that gives you more control like switches so the player has control in the game so the performance can be relied on to be the same each and every time.

 

It was never going to beat the load accelerator, for sure. I can fix the thing fairly easily, at least in the sense of making it work again after a save load breaks it. But I'd REALLY like to beat the accelerator somehow. That's going to take some cleverness and more coffee. Right now I have no ideas at all, though I've gathered enough data to know what's wrong, and that's something.

[Xaranth]

There's not enough coffee in the world for this problem. :wallbash:

 

Progress report: I've been trying to implement a load detector, but apparently the only variables preserved across loads are the ones you don't want to be. Absolutely zero success trying to save the current time across loads. Then I had the bright idea to watch for successive block triggers, which derailed as soon as I realized that there are plenty of legitimate circumstances in which the enter/leave blocks might trigger sequentially.

 

I'll confess that I'm close to admitting defeat and throwing an activation trigger to reset all actor counters on cell exit.

 

But I'm not quite there yet.

[Xaranth]

I think I might cry.

 

So I got the brilliant idea to watch the enter/leave block triggers and make sure that the same reference wasn't triggering the blocks twice in a row. So I recoded the scripts to do that check.

 

...It didn't work. Well, it sort of worked. I loaded my debugger char, coc'd to the cell, quicksaved, then ran to the armoury, and quickloaded. When it loaded and I left the Common, the lights switched off, as they were supposed to. But when I ran into the armoury, the lights DIDN'T turn on as they were supposed to.

 

I said, all right, might be local scope biting me on the behind again, so I recoded the scripts to store/check against questvars instead of localvars.

 

Same thing. But then I reloaded the 'clean' debug save, and ran to the armoury, quicksaved there, then ran back to the common and loaded from there. . . .

 

BOTH ROOMS WORKED RIGHT :wallbash: :wallbash: :wallbash: :wallbash:

 

IDGI. I SERIOUSLY don't get it. The scripts are IDENTICAL save for the counter and refcheck vars.

 

scn DARC07scptLSCom

ref rLink
ref rTrigger

begin onTriggerEnter

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	if rTrigger != DARC07qstDebug.rComOldEnterTrigger
		Set DARC07qstDebug.sInCom to DARC07qstDebug.sInCom + 1
		Set DARC07qstDebug.rComOldEnterTrigger to rTrigger
		Set DARC07qstDebug.rComOldExitTrigger to 0
		if DARC07qstDebug.sInCom == 1
			rLink.Enable 0
		endIf
	endIF			
endIf

end

begin onTriggerLeave

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	if rTrigger != DARC07qstDebug.rComOldExitTrigger
		Set DARC07qstDebug.rComOldExitTrigger to rTrigger
		Set DARC07qstDebug.rComOldEnterTrigger to 0
		Set DARC07qstDebug.sInCom to DARC07qstDebug.sInCom - 1
		if DARC07qstDebug.sInCom < 1
			rLink.Disable 0
		endIf
	endIf
endIF

end

 

and

 

scn DARC07scptLSAry

ref rLink
ref rTrigger

begin onTriggerEnter

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	if rTrigger != DARC07qstDebug.rAryOldEnterTrigger
		Set DARC07qstDebug.sInAry to DARC07qstDebug.sInAry + 1
		Set DARC07qstDebug.rAryOldEnterTrigger to rTrigger
		Set DARC07qstDebug.rAryOldExitTrigger to 0
		if DARC07qstDebug.sInAry == 1
			rLink.Enable 0
		endIf
	endIF			
endIf

end

begin onTriggerLeave

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	if rTrigger != DARC07qstDebug.rAryOldExitTrigger
		Set DARC07qstDebug.rAryOldExitTrigger to rTrigger
		Set DARC07qstDebug.rAryOldEnterTrigger to 0
		Set DARC07qstDebug.sInAry to DARC07qstDebug.sInAry - 1
		if DARC07qstDebug.sInAry < 1
			rLink.Disable 0
		endIf
	endIf
endIF

end

 

EDIT: I wonder if I'm getting 'interference' from my quest completion trigger? Gonna test that.

Edited November 30, 2012 by Xaranth

[Xaranth]

Okay, I figured out why the armoury was breaking but not the reverse. Lightbulb moment. The exit trigger check var never got initialized. I think I can beat this now.

 

Edit: Nevermind, that lightbulb blew. I'm still no closer to figuring this out. It wasn't interference from the quest trigger, it wasn't the initialization state of the check var, it's not ANYTHING that makes sense. Cor, I wish I didn't have to pick this apart via observation.

 

I think I'd give my coffeepot for a proper debugger.

 

Edit 2: I had hoped using a non-null ref as my 'baseline' ref would make it work, but no joy there either. Out of ideas again, I think I'll go lay tile for awhile.

 

Edit 3: *Brainsplosion* I didn't really come up with anything genius, but I decided to add the library to my testing sequence, so once that was ginned up I went through all the iterations. Result: Quicksaving anywhere the auto-lights are set, then loading from either the armoury or library causes those rooms to end up with a base actor count of negative one. So, basically, quickloading spawns ghosts. W. T. F.

 

Any attempt I've made at controlling this fails gorgeously. I really have no idea what to do next. Other than the obvious, of course, which is stick a clean-up script on all exits from the bunker that will cull all the count vars back to zero. Which will preclude my hope-i-can-in-the-future add a Mr. Handy so that the item sorter doesn't work via pure magic. It would also prevent EVER making the bunker a companion home target, which is also a desire of mine. Actually, that would, I think, break the lights even if you just told your companions to wait in the bunker.

 

...

 

Oh FFS. I give up for at least the next three hours. Me and some awesome classic SciFi novels have an appointment.

Edited November 30, 2012 by Xaranth

[Xaranth]

Okay, spent some time with Gibraltar Earth and got my equilibrium back. Came back to the computer and had another data gathering plan. Whatever 'ghost' is screwing up my lights is a null ref. So cross your fingers, I'm going to try and filter nullRefs from the trigger code.

 

EDIT 01: No luck.

 

EDIT 02: AAAAAHAHAHAHAHAHAHA!!!! SUCCESS!

 

...I didn't actually beat the problem, as happens so often when working with other peoples' software.

 

But I figured out how to code around it.

 

scn DARC07scptLightSwitch

ref rLink
ref rTrigger
short bLightsOn

begin onTrigger

Set rTrigger to GetActionRef

if rTrigger.IsActor && (bLightsOn != 1)
	Set rLink to GetLinkedRef
	Set bLightsOn to 1
	rLink.Enable 0
endIF

end

begin onTriggerLeave

Set rLink to GetLinkedRef
Set rTrigger to GetActionRef

if rTrigger.IsActor
	rLink.Disable 0
	Set bLightsOn to 0
endIF

end

 

It's a bit kludgy, somewhat inelegant, and will probably result in a light flicker occasionally during gameplay.

 

But it makes the lights NOT BREAK when a quickload is done, and that's what matters. I win, game, you cannot defeat me!

 

EDIT 03: It's also not anywhere near efficient, since that ruddy trigger block is almost as bad as a GameMode block for sucking resource, but it works. I can give up some resource for things that work.

Edited December 1, 2012 by Xaranth