#LOCKing queries
Moderators: Commodore, Zenith Nadir
#LOCKing queries
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. ;)
------
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. ;)
- Schroedingers Cat
- We must invent teleportation!
- Posts: 721
- Joined: Mon Jun 19, 2006 11:35 pm
- Location: Idaho, Wisconsin
Re: #LOCKing queries
I believe an object's "#lock"edness is binary and does not stack, but I'm not entirely certain.Ceri JC wrote:Is the state of being "locked" binary (IE you are either locked or not), or is it possible to stack 'locks'.
Yes, you are right in thinking that.Ceri JC wrote: Am I right in thinking that there's no way of getting another object to unlock a locked one?
Please address any additional questions to Bart.
- RobertP
- gore Arnold
- Posts: 250
- Joined: Tue Dec 18, 2007 6:53 pm
- Location: Burning Oak retirement facility
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.
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.
My waste is my weapon.
- Zenith Nadir
- this is my hammer
- Posts: 2767
- Joined: Wed Mar 12, 2003 11:40 am
- Location: between the black and white spiders
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.
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.
he looked upon the world and saw it was still depraved
Overall: Rotton egg for breakfast
Overall: Rotton egg for breakfast
Lock is binary. You could try using another object like this
Or use zap like this
Also posting your code might help
Code: Select all
#cycle 1
:loop
#if any water #lock
#if not any water #unlock
#loop
:touch
Hello
?i
#loop
Code: Select all
#end
:touch
#if not blocked n water
#put n empty
#end
:water
#put n water
Code: Select all
#cycle 1
:loop
?rnd?i?i
#if any water FullHealth
#loop
:touch
:touch
:touch
#zap touch
Ouch
?i
#loop
:touch
#become fake
:FullHealth
#restore touch
Full Heal
?i
#change water empty
#loop
- Quantum P.
- Level 17 Accordion Thief
- Posts: 1433
- Joined: Fri Sep 12, 2003 1:41 am
- Location: Edmonds, WA
- Contact:
- RobertP
- gore Arnold
- Posts: 250
- Joined: Tue Dec 18, 2007 6:53 pm
- Location: Burning Oak retirement facility
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.
#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.
My waste is my weapon.
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.