SSE Dwemer Dynamo Core Activator problem... Bethesda's doing!

[cumbrianlad]

Hi.

 

I've used 3 of Bethesda's dynamo core activators (DLC2dweDynamoTrigger01) to open doors to 3 dwarven ruins. In testing them I found a glitch that I'd not noticed playing the game (although I went into Fahlbtharz where the activators are used and hey presto, same glitch!). Apparently it's a known bug.

 

To use them, you are supposed to have a centurion dynamo core in your inventory. If you try to use one without that item you are told that you lack the required item. However, if you back away from the activator, approach it again (still with no core in your inventory) and try to use it again it activates and adds a dynamo core to your inventory, to boot.

 

Does anyone know if there is a way to fix this?

 

I'm just not good enough with papyrus to see what's wrong with Bethesda's script.

 

I'd just have used another way to lock the doors to the ruins, but I've made 3 different coloured dynamo cores and referenced them in several books in the mod... that's a fair bit of work to throw away, plus all the time spent finding each of the book references, changing quest objectives, quest aliases etcetera.

 

 

[cdcooley]

Yes, there's a very glaring and obvious error in the script on those objects. I can't believe that that the USKP team didn't fix it when they were making other changes to that script.

 

The problem is that whether you have the required item or not the code is recording that the door is open.

 

Here's a version of the script provided by the Unofficial Patch team which should fix the problem. (The actual change I've made is on line 117.)

Scriptname DLC2defaultSlottedItemActivatorScript extends ObjectReference  
{This is a generic script for slotted item activators like the DweDynamoTrigger}

import debug
import utility

bool property isOn = false	auto conditional
{set to true to start open}

bool property itemIsNotRemovable = false auto
{if this item cannot be removed once slotted set this to true
	default = false}

bool property playerOnly = false auto
{If this is true, this sets no favor allowed on this
	default = false}

bool property silenceContainerMessage auto
{if this is set to true, do not display item added/removed messages
	default = false}

bool property doOnce = false auto
{set to true to open/close on first activation only}

bool property doesNotRemoveItem = false auto
{if this is set to true, this requires an item but does not remove it from your inventory
	Default = FALSE}

bool property isAnimating = false auto Hidden
{is the activator currently animating from one state to another?}

string property onAnim = "on" auto
{animation to play when opening}

string property offAnim = "off" auto
{animation to play when closing}

string property startOnAnim = "startOn" auto
{open event name - waits for this event before considering itself "open"}

string property doneEvent = "done" auto
{close event name - waits for this event before considering itself "closed"}

message property itemNeededMessage auto
{if set, this message is shown when the player activates this and does not have the required item}

message property busyMessage auto
{if set, this message is displayed if activated while busy}

miscObject property requiredItem auto
{This is the object to be slotted into the activator}

int property myState = 1 auto hidden

float property waitTime = 0.0 auto
{wait this amount of time while changing states to allow child to finish animating
	NOTE: this is not 100% safe, but is good enough in many cases
	default = 0.0}

bool property noItemRequired = false auto

EVENT OnLoad()
	blockActivation()
	if playerOnly
		SetNoFavorAllowed()
	endif
	if isOn
		playAnimation(startOnAnim)
		goToState("On")
		if itemIsNotRemovable
			setDestroyed(True)
		endif
	endif
endEVENT

Event OnReset()
	reset()
	setDestroyed(false)
EndEvent

auto STATE off	; waiting to be activated
	EVENT onActivate (objectReference akActivator)
		goToState("busy")
		if akActivator.getItemCount(requiredItem) >= 1 || noItemRequired
			if !doesNotRemoveItem
				akActivator.removeItem(requiredItem, 1, silenceContainerMessage)
			endif
			playAnimationandwait(onAnim, doneEvent)
			self.Activate(self, true)
			isOn = True
			if itemIsNotRemovable
				setDestroyed(True)
			endif
			;This statement is currently not functional, but meant to handshake with
			;2stateActivators or doors to ensure state agreement

			;USLEEP 3.0.8 Bug #14933: added the following lines to replace the removed code below:
			objectReference currentLink = getLinkedRef()
			while currentLink
				if (currentLink as default2stateActivator) || (currentLink.getBaseObject() as door)
					currentLink.setOpen(true)
				endif
				currentLink = currentLink.GetLinkedRef()
			endWhile

			wait(waitTime)
			if DoOnce
				goToState("Done")
			else
				goToState("on")
			endif
		Else
			if akActivator == game.getPlayer() && itemNeededMessage
				itemNeededMessage.show()
			endif
			;; nothing was opened, so return to the off state!
			goToState("off")
		endif
	endEVENT
endState

STATE busy
	event onActivate(objectReference akActivator)
		if busyMessage
			busyMessage.show()
			utility.wait(1.0)
		endif
	endEVENT
endSTATE

STATE on
	EVENT onActivate (objectReference akActivator)
		goToState("busy")
		if itemIsNotRemovable
			;doNothing
			goToState("on")
		else
			if !doesNotRemoveItem
				akActivator.addItem(requiredItem, 1, silenceContainerMessage)
			endif
			playAnimationandwait(offAnim, doneEvent)
			self.Activate(self, true)
			isOn = False
			;This statement is currently not functional, but meant to handshake with
			;2stateActivators or doors to ensure state agreement
			;Sanity checks added by UDBP 1.0.4, UDBP 2.0.1 because not all of these seem to have linked refs
			if( GetLinkedRef() != None )
				if (getLinkedRef() as default2stateActivator) || (getLinkedRef().getBaseObject() as door)
					getLinkedRef().setOpen(false)
					objectReference currentLink = getLinkedRef()
					if( currentLink.GetLinkedRef() != None )
						while (CurrentLink.getLinkedRef() as default2stateActivator) || (CurrentLink.getLinkedRef().getBaseObject() as door)
							CurrentLink.getLinkedRef().setOpen(false)
							CurrentLink = currentLink.getLinkedRef()
						endwhile
					EndIf
				endif
			EndIf
			wait(waitTime)
			if DoOnce
				goToState("Done")
			else
				goToState("off")
			endif
		endif
	endEVENT
endSTATE


State done
	EVENT OnLoad()
		blockActivation()
		if playerOnly
			SetNoFavorAllowed()
		endif
		if isOn
			playAnimation(startOnAnim)
			;goToState("On")
			if itemIsNotRemovable
				setDestroyed(True)
			endif
		endif
	endEVENT

endState

[cumbrianlad]

Sorrry for the delay in replying, cdcooley.

 

I'll try that right away!

 

Thank you ever so much for that. Have yourself a beer or whatever else strikes your fancy.

 

If I ever get this finished and publish the mod, you'll be added to my growing list of thanks! (It's going to look like an Oscar acceptance speech at this rate!)

 

I'll add this version and try it. If it works, I'll also add a comment into the script acknowledging your part in sorting the mess out. I see what's been done but I'd never have figured it out.

 

Thanks again.

[cumbrianlad]

Unfortunately, this script didn't work.

 

Now the activators function correctly once, give the item required second time and then seemingly at random either close or open the doors.

 

I've tried having the door as a linked reference from the activator and having the door's activate parent as the activator, set to 'parent activate only'.

 

The result was the same.

 

it seems closer but not quite there.

 

I got impatient and added new buildings with Blackreach doors to them with a standard dwemer lever in the underground portion that opens after the correct item is used. This works fine and never fails.

 

I've used my nice dynamos to 'resurrect' three dwemer animunculi to act as followers as in the DLC2 Kagrumez quest. The player transfers the appropriate dynamo core to a defunct animunculus and it revives. I only need to get the hiring and firing dialogue to work now and I'll be happy... new post relating to that coming up!

[cdcooley]

It sounds like your tests were actually running both the old and new versions of that script at the same time. Do you change that script or did you try to add a second version of that script to your activators? Were you testing with a brand new game or continuing from an already saved game?

 

In any case, I submitted that bug to the Unofficial Patch team and Arthmoor flagged it as fixed for USSEP 4.1.5. And more importantly you found a way around your problem.

[cumbrianlad]

hi.

 

I removed the original script from the activator. I then made a new script with a unique name using the code above. I added that to the activator which is a renamed duplicate of the original activator.

 

I always test from clean saves that have never seen the mod. When testing I have all auto saves turned off and never manually save while testing. I have a set of saves up to level 60 that have been made with no mods running other than usleep. I've added my own scripts, edited them and tested this way before and the changes to the scripts always take effect

 

I think that the best way to rule out any possibility that the old script was still running is to start a new game, as you suggest. It's worth trying to get this to work, so I'll make a small test esp with just the basic components in a small cell. That way I can quickly try all the possible ways that the activator can be used.

 

So I'll have a simple activator and door with the activator as the activate parent, set to parent activate only, then a set of pole gates, traplinker and activator. This way we can be certain that there's nothing of the original script burnt into the save

 

I'll report back when I get that done.

 

Edit: I didn't need to go past putting a test cell into the original mod and coc-ing into it. It worked perfectly exactly as intended. I set it up exactly as before using the activators with the new script that I'd already made. I placed the 3 required items into the cell and used them to check the operation with the required item after I'd repeatedly tried and failed to get the activators to work without them. The correct 'lack item' message was displayed each time the correct messages were displayed when the item was removed and returned to the player inventory.

 

This test was done from a new game, so that proves you were right about my save point being the problem.

 

It worked with two different doors and a traplinker plus port gate set-up.

 

Opening the doors then dropping the required items and trying to close them again correctly reverted to the 'lack item' message being displayed again and the doors/port gates did not operate.

 

I'd say that's pretty conclusive and that the save I was using has somehow got corrupted.

 

Any way, thanks again for the solution. I noted your comment about USSEP 4.1.5. I'll make sure that I have the correct version and remake the things, once I've seen that the vanilla script is now correct.