Blackreach Lock Scripting Help

[SoLoMaGiK]

Hey all, I've been messing around with the CK for a bit now and want to add the "Dwarven Mechanism" or BlackreachLock as it's called in the CK.

It works perfectly, except the stairs that the lock is referenced to stay in the activated position.

Scripting is beyond me and I'm sure the actual script that I'm looking for would be quite simple for a veteran scripter.

I'm looking for an add-on to the existing script (I guess) to make the stairs return to their original state (hidden) once I activate the "mechanism" again.

That way I can activate the stairs up or down at will.

 

I've already made my own attunement sphere to coincide with the newly created script just need a little help.

Thanks in advance!

[SoLoMaGiK]

It seems changing the sphere to something I renamed doesn't quite work right either. I'm guessing this is because of the script?

[PhillG]

I don't know if you ever found your answer or just moved on, but the scripts for the black reach lock set are written in such a way that they will only open once. I've rewritten them for you below. Just attach each one to the appropriate half of the lock and disable the existing scripts. Link the lock to the door and set each scripts properties. Keep in mind that the blackreachlock static only has one animation (opening) and for some reason the script won't play it a second time, so you won't get the lock animation when you close and reopen the door, but it works. As for your item, the only thing I can think of is that you didn't set it as the DwarvenKey property of the blackreachlockscript on the lock.

 

blackreachlocktoggle - attach to blackreachlock

Scriptname blackreachlocktoggle extends ObjectReference 
{Checks for Dwarven Key in inventory, animates, and activates the Blackreach door.}

import game
import debug
import utility

MiscObject Property DwarvenKey Auto
Message Property LackTheItem Auto
ObjectReference Property DweBREntranceStair Auto Hidden

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

string property openAnim = "Unlock" auto Hidden
{animation to play when opening}

;string property openEvent = "Unlock" auto
;{open event name - waits for this event before considering itself "open"}

auto STATE waiting	; waiting to be activated
EVENT onActivate (objectReference triggerRef)
	; if player has the dwarven key in inventory, the stairway will open
	if (getPlayer().getItemCount(DwarvenKey)>=1)
		SetOpen()
	else
	LackTheItem.show()
	endif
	
endEVENT
endState

STATE busy
; This is the state when I'm busy animating
	EVENT onActivate (objectReference triggerRef)
			; block activation
;				trace (self + " Busy")
	endEVENT
endSTATE

function SetOpen(bool abOpen = true)
; if busy, wait to finish
while getState() == "busy"
	wait(1)
endWhile
isAnimating = true
DweBREntranceStair=GetLinkedRef()
gotoState ("busy")
;	trace(self + " Unlocking")
playAnimation(openAnim) ; Animate Open
;	Wait(2)
DweBREntranceStair.Activate(DweBREntranceStair)
isAnimating = false
       gotoState("waiting")

endFunction

STATE done
; This is the end state, player should not be able to reactivate
endSTATE 

BlackReachDoorToggle - attach to door.

Scriptname BlackReachDoorToggle extends ObjectReference conditional
{Script to open the door to blackreach when activated by the lock.}

import game
import debug
import utility

bool property isOpen = false	auto Conditional
{set to true to start open}

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

string property openAnim = "Down" auto Hidden
{animation to play when opening}

string property closeAnim = "Up" auto Hidden
{animation to play when closing}

string property openEvent = "TransDown" auto Hidden
{open event name - waits for this event before considering itself "open"}

string property closeEvent = "TransUp" auto Hidden
{close event name - waits for this event before considering itself "closed"}

int myState = 1
; true when static or animating
; 0 == open or opening
; 1 == closed or closing

EVENT OnLoad()
if (isOpen )
	myState = 0
endif
endEVENT

auto STATE waiting	; waiting to be activated
EVENT onActivate (objectReference triggerRef)
	; switch open state when activated
	SetOpen(!isOpen)
endEVENT
endState

STATE busy
; This is the state when I'm busy animating
	EVENT onActivate (objectReference triggerRef)
			trace (self + " Busy")
	endEVENT
endSTATE

function SetOpen(bool abOpen = true)
; if busy, wait to finish
while getState() == "busy"
	wait(1)
endWhile
; open
;messagebox(self + " Current state is  " + isOpen)
isAnimating = true
	if  !isOpen
		gotoState ("busy")
		messagebox(self + " Opening")
		playAnimationandWait(openAnim, openEvent) ; Animate Open
;      		messagebox(self + " Opened")
	       isOpen = true
	      gotoState("waiting")
            isAnimating = false		
            else
                  gotoState ("busy")
		messagebox(self + " Closing")
		playAnimationandWait(closeAnim, closeEvent) ; Animate Close
;       		messagebox(self + " closed")
	       isOpen = false
	      gotoState("waiting")
            isAnimating = false		

endif

endFunction

STATE done
; This is the end state, player should not be able to reactivate
endSTATE 

[PhillG]

I forgot to comment out all of my messagebox diagnosis lines. Feel free to remove any lines that start with trace or messagebox, otherwise you'll get some popups.

[steve40]

The vanilla script is poorly coded. Those "while" loops look either redundant or rather dangerous, LOL. It looks to me that the "while" loop in the SetOpen function of both scripts is completely useless because SetOpen is ONLY called while in the "waiting" state, so the state will never be "busy" when the "while" loop is processed... On the other hand, if the script did happen to be in the busy state when the while loop was processed, the subsequent code would NEVER get executed (because it's looping), so the script would not be able to switch back to the "waiting" state and you would be forever stuck in the while loop! :wallbash: I could be wrong, but that's how it looks to me. Bethesda, what were you thinking? :mad:

[PhillG]

The vanilla script is poorly coded. Those "while" loops look either redundant or rather dangerous, LOL. It looks to me that the "while" loop in the SetOpen function of both scripts is completely useless because SetOpen is ONLY called while in the "waiting" state, so the state will never be "busy" when the "while" loop is processed... On the other hand, if the script did happen to be in the busy state when the while loop was processed, the subsequent code would NEVER get executed (because it's looping), so the script would not be able to switch back to the "waiting" state and you would be forever stuck in the while loop! :wallbash: I could be wrong, but that's how it looks to me. Bethesda, what were you thinking? :mad:

 

Not the first poorly coded script I've run across unfortunately. The goal here was just to get it to be multiuse, but if I had to write it from scratch it would be a little cleaner. You are right, I'm pretty sure that the while loop is unneccessary, and the gotostate("busy"), shouldn't that happen after the animation step? And while I'm on a small rant, why leave active debug code everywhere? There's definitely a bunch of cruft in the scripts. I've seen so many variables set and never referenced again and quite a few functions that absolutely don't do what their comments say they should. It works, I suppose that's one thing :) Gives me something to do.

[SoLoMaGiK]

Thanks for the info guys! I've taken a break from my mod (I just had to become satisfied with the open state of the stairs once activated), but now I can try it out again!

I appreciate you taking the time to create or "fix" the existing script. Kudos!