z2

I have managed to fix a fairly major and commonly occurring bug in a game I am making through the use of #lock. This is good, but in certain (consistent, known, repeatable) circumstances, it leaves the player-controlled object that serves as the game's main character locked and frozen to the spot, effectively ending the game. A few questions that will hopefully help me solve this:

------

1. Is the state of being "locked" binary (IE you are either locked or not), or is it possible to stack 'locks'. EG

Does
#lock
#lock
need
#unlock
#unlock
to clear it, or will
#unlock
suffice?

------

2. Am I right in thinking that there's no way of getting another object to unlock a locked one?
IE
@unlockingObject
#send lockedObjectName:unfreeze

@lockedObjectName
#end
:unfreeze
#unlock
#end

or anything using "built in" terms like,

#send lockedObjectName:unlock

I've tried both of these and neither seem to work. I know it'd sort of defeat the point of locking, but I can see a way of doing it from just one object that would acceptably solve this problem without interfering with the reason the locks are there in the first place.

-------


Any help much appreciated.

...and I thought my locking worries were over the day I moved away from DBA work in MSSQL. ;)

Ceri JC wrote:Is the state of being "locked" binary (IE you are either locked or not), or is it possible to stack 'locks'.

I believe an object's "#lock"edness is binary and does not stack, but I'm not entirely certain.

Ceri JC wrote: Am I right in thinking that there's no way of getting another object to unlock a locked one?

Yes, you are right in thinking that.

Please address any additional questions to Bart.

You are able to #lock an object as many times as you like, one #unlock command will undo the object's isolation. I'm not well-informed about ZZT's code, but when running the game in Dosbox, stacking up code will generally slow things down. Making an object #lock many times seems to do nothing.

The best alternative for a #lock that doesn't shut the object off from external stimuli would probably be to #zap certain :labels, allowing one object to reach the object with a different :label.

Both #unlock and #clear will undo all previous #locks and #zaps, though #zaps are definitely stacked.

There are a couple of really clever ZZT'ers hanging around, who'd be able to tell you more about the workings of ZZT's code (both the lines of code in pascal as the finer mechanics of ZZT-OOP).

They often look like this.

I've certainly seen things happen in ZZT that I still haven't figured out, in particular the work of WiL.

re: rob's signature: i have not seen that film but the book was great + i read it at a time when i related to the author's disillusionment and aimlessness a lot, even though i am not an iranian woman and have never spent three months living on the streets

the edition i bought was kind of awful though, standard paperback production values do not translate well to comic books

this doesn't answer anybody's questions but as you may have noticed by now i just like to talk about whatever i want, you can't stop me. i can't be stopped.

Lock is binary. You could try using another object like this Or use zap like this
Also posting your code might help

#lock is indeed binary. As far as I can tell, there's nothing wrong with #locking multiple times and then #unlocking -- it doesn't stack at all.

What RobertP said about using #zap is probably your best bet (although the command for un-#zapping a #zapped label is #restore, not #clear).

Oh shit, my mistake.

#clear is the command that removes a #set condition, which you could also use to lock an object (#if lockedup then #end, or, in a negative sense, #if not open then #end) #zap and #restore would probably be better to simulate the effect of a #lock, though, since it makes the object ignore the signal, rather than terminate it's loop before it starts.

Risking sounding sentimental: It's nice to see ZZT'ers involved.

you can also send zaps and restores from other objects which you can't do with a lock

#zap object:touch

I've sorted the problem now. Having looked at it carefully, I still couldn't determine why the lock was occurring, but I did see where. I realised, however, that the bit of code where the lock was occurring was (conveniently) one of only two bits that weren't affected by the problem that required the lock, so I removed the lock and it worked fine. Still, this thread was useful to learn more about the way locking works, so thanks for your help everyone.