scarykitties on 29/4/2014 at 18:19

---

It's been a while, so I'm a bit rusty. I need a set-up so that I have a lockbox that:

1. When unlocked, will add a key to the player's inventory, change its model state, and send a TurnOn along its CD links.
2. When locked, will remove a key from the player's inventory, change its model state, and send a TurnOff along the CD links.

What would be the best way to implement this?

It'd be great to get a response for this, as this is for a class project that's due Friday, so I don't have a lot of time. Any suggestions that could make these effects happen will do.

scarykitties on 1/5/2014 at 01:43

---

Thanks for the quick reply!

I like your set-up, but there are a few problems when I try to implement it:

1. Judging by the sounds, it seems like the lockbox unlocks and then immediately re-locks itself from a single key-frob. This seems to be a problem that every lock-box is having, and I don't understand why.

2. I was a little unclear with what I wanted: the lockboxes should be able to be re-locked (and give you back your key) after being simply frobbed. In the context of its use, I'm creating fuse boxes that need a fuse to work, but then the fuse can be taken out again and the circuit will again be disabled.

Any advice on how to overcome these, particularly the first? The lockboxes were working earlier, but now are suddenly all on the fritz; even new ones. Hm...

R Soul on 1/5/2014 at 16:49

---

I suspect when you added NVNameOnCreation to the key archetype, you left StdKey in place and put the new script in the next field, and you left Don't inherit unchecked. If that's the case, the key has two copies of StdKey (one of which is inherited from Key-or-part) so the lock receives two 'used key' messages, the second of which locks it again.

Initially I thought this was the sort of thing you meant, but then I re-read your post and gave you what you asked for ;)

First, start from scratch (i.e. ignoring any changes from my last post and any other attempts you've made)

Create a new act/react stim, called FuseStim (object hierarchy, select Act/React... from the top menu)

Create a new archetype descending from one of the keys.
[INDENT]Add the model name of the fuse
Add the KeySrc property with the correct values.
Add FrobInfo and change ToolAction to Script,UseAmmo (so the fuse vanishes when used correctly)
Add a stim (Act/React > Sources)
[INDENT]Stimulus: FuseStim
Propagator: Contact (Edit Shape: Contact Types: Frob Inv > World)
Intensity: 1 (the value isn't important)[/INDENT][/INDENT]

Create a new metaproperty (object hierarchy, select MetaProperties from the top menu). This will be added to the fuse box when the fuse is used on it.
S > Scripts:
NVItemGiver
NVMetaTrap

Design Note:
NVGiveWhat="NewKeyArchetypeName";NVItemGiverOn="FrobWorldEnd"; NVMetaTrapOff="FrobWorldEnd"; NVMetaTrapMeta="YourMetaPropName"

Model Name: Fuse box model with the fuse.

If there is more than one fuse, you will also need to add a Receptron for FuseStim. No Min, No Max, Effect: Abort (This is so using other fuses won't affect things)

Create a new archetype for the lockbox (or edit the concrete object)
Add a Receptron for FuseStim
No Min, No Max
Effect: Add MetaProperty
Target: Me
Agent: YourMetaPropName

Finally, S > Scripts: replace LockSounds with TrigUnlock

Remember to put a KeyDst property on the fuse box.

This is what happens:
The fuse (a key) is used to unlock the fuse box (which is a lockbox) and it sends a FuseStim to it (and the fuse is deleted). The fuse box reacts by adding the new metaprop. The metaprop changes the fuse box's behaviour. It gets a new model name (box with fuse), and it now has two scripts that respond to the object being frobbed. One of the scripts gives you a fuse, and the other one removes the metaproperty, which shows the original model again, and removes the scripts.

Using the fuse again will repeat the above process.

The TrigUnlock script sends TurnOn when the fuse box is unlocked (the fuse is put in) and TurnOff when locked (the fuse is taken out).


Perhaps you added the suggested properties to the lockbox archetype instead of making a new archetype descending from lockbox (or instead of editing the concrete object).

LarryG on 2/5/2014 at 01:00

---

Add an NVRelayTrap to send a "Lock" message to itself (NVRelayTrapTDest="[Me]") in response to a "FrobWorldEnd"?

scarykitties on 2/5/2014 at 01:22

---

Alright. I fixed the above problem by creating a marker called UnlockTemplate with the property "Locked" set to false. Then, in the receptrons for the fusebox, I added a response to the FuseStim that sets the Locked property of the fusebox to that of the UnlockTemplate marker.

It seems to now correctly allow a fuse to unlock/send a TurnOn while fobbing locks and sends a TurnOff every time.

... Except there's still a problem when multiple fuses are used on the fusebox. If a fuse is used on an activated fusebox without first frobbing it, the fuse is lost and the fusebox's model doesn't properly change (although it IS properly re-locked and the TurnOff message is properly sent).

So I need a way for keys to no longer function/be consumed if the fusebox already has a fuse.

EDIT: I may be on the right track, but it's still not working right. Please feel free to weigh in if you have a better solution! I need to have this working by tomorrow.

What I tried doing is adding another receptron to the fusebox that will set the fusebox's KeyDst property to that of the UnlockTemplate object, which happens to be a RegionMask of 1 and a LockID of 0 (as opposed to the normal RegionMask of 1 and LockID of 1 that I'm using for the fusebox by default).

This works correctly and makes it so that fuses no longer work and are no longer consumed by being used on the fuse box. Then, to reverse this, I set up another NVRelayTrap script so the fusebox's design notes look like so:



I then limited all receptrons that already existed on the fusebox from no min limit to 90 (including for the abort on the metaproperty that is added when the fusebox is locked). Finally, I added another receptron to the fusebox that checks for a FuseStim of 95 to No Limit, which sets the fusebox's KeyDst property to that of another dummy object, this time called LockTemplate. LockTemplate has a KeyDst property with a RegionMask of 1 and a LockID of 1, just like the default fusebox.

HOWEVER, while this set-up successfully will disable the ability to use a second fuse on a fusebox that already has a fuse (i.e. it's locked), the fuses never work, even when the fuse is taken out of the fusebox again (i.e. it's unlocked). For some reason, it sets the KeyDst property once, but doesn't correctly set it the second time.

Any idea why? If I'm barking up the wrong tree and there is a better way to do this, please let me know!