Multiple key objects
Posted: Thu Feb 23, 2012 6:13 pm
I don't know how useful this is, but here is a modification of DoLock and DoUnLock that allows for doors to have multiple key objects. I've tested it with up to four different key objects without trouble. You may notice that certain things are checked in a different order that with the original routine. I would like to know if this different order presents any problems or if I've forgotten anything important.
Also included are some new verb messages that had to be replaced and one global.
I've wanted to write something like this ever since I started Npcmove.h. Having npc's move logically in relation to locked doors, when the player is in possession of the only key object for that door, can be a problem. That's why npcmove.h doesn't stop npc's from moving through locked doors.
I've realized, however, that this doesn't make sense and should be changed; a locked door should work properly for both the player and characters.
If the above code passes the test, then a character can have a key to a door that the player or other npc's have a key to also. This should make coding logical behavior in npc's that much easier.
Also included are some new verb messages that had to be replaced and one global.
Code: Select all
global correct_key ! This is only used to print a couple of messages correctly
replace DoLock
{
local a, test_key, flag, not_xobject, not_in_player
if not CheckReach(object): return false
if object is open
{
VMessage(&DoLock, 2) ! "Have to close it first..."
return true
}
if object is locked
{
VMessage(&DoLock, 1) ! already locked
return true
}
while object.#key_object > a and flag = false
{
a++
test_key = object.key_object #a
if xobject
{
if xobject = test_key
{
flag = true
not_xobject = false
}
else: not_xobject = true
}
if not xobject
{
if Contains(player, test_key)
{
xobject = test_key
flag = true
not_in_player = false
}
else: not_in_player = true
}
}
if not_xobject = true
{
VMessage(&DoUnlock, 1) ! "Doesn't seem to work..."
return true
}
if not_in_player = true
{
VMessage(&DoUnlock, 2) ! no key that fits
return true
}
correct_key = xobject
object is locked
if not object.after
{
if not xobject.after
VMessage(&DoLock, 3) ! "Locked."
}
return true
}
replace DoUnLock
{
local a, test_key, flag, not_xobject, not_in_player
if not CheckReach(object): return false
if object is open
{
VMessage(&DoUnLock, 5) ! "The door is open."
return true
}
if object is not locked
{
VMessage(&DoUnLock, 3) ! already unlocked
return true
}
while object.#key_object > a and flag = false
{
a++
test_key = object.key_object #a
if xobject
{
if xobject = test_key
{
flag = true
not_xobject = false
}
else: not_xobject = true
}
if not xobject
{
if Contains(player, test_key)
{
xobject = test_key
flag = true
not_in_player = false
}
else: not_in_player = true
}
}
if not_xobject = true
{
VMessage(&DoUnlock, 1) ! "Doesn't seem to do the trick..."
return true
}
if not_in_player = true
{
VMessage(&DoUnlock, 2) ! no key that fits
return true
}
correct_key = xobject
object is not locked
if not object.after
{
if not xobject.after
VMessage(&DoUnLock, 4) ! "Unlocked."
}
return true
}
replace NewVMessages(r, num, a, b)
{
select r
case &DoLock
{
select num
case 3
{
if correct_key ~= 0 and object.key_object
print "(with "; The(correct_key); ")"
print "Locked."
return true
}
}
case &DoUnLock
{
select num
case 4
{
if correct_key ~= 0 and object.key_object
print "(with "; The(correct_key); ")"
print "Unlocked."
return true
}
case 5
{
print CThe(object); IsorAre(object); " open."
return true
}
}
}
I've realized, however, that this doesn't make sense and should be changed; a locked door should work properly for both the player and characters.
If the above code passes the test, then a character can have a key to a door that the player or other npc's have a key to also. This should make coding logical behavior in npc's that much easier.