R Soul on 9/7/2025 at 18:58

---

If you can already trigger one event, it sounds like you're most of the way there. The trick is to get the gist of what each receptron and object does, and work out what's specific to that FM and what you need to copy. But each FM is bound to have one or two steps which are specific to that setting, so it'll always be easy to get lost when following links etc.

In general this setup should work:
1st Receptron: Destroy object: this source (which effectively takes it out of the player's inventory if the player frobbed it onto the other object like a key, and also stops a 'dropped' object from being picked up again).
2nd Receptron: Teleport object. The target would be some hidden object that looks like the 'dropped' object, but without any properties that allow it to be picked up (Engine Features > FrobInfo), or with that property set to None. 'Edit effect' allows you to set the location/orientation relative to the 'Agent' object. For the Agent you can select 'me' and some positive Z value depending on the sizes of the objects.

If your equivalent of the 'plate' object can be frobbed, then a 3rd receptron can be used to truly finish things off:
Remove Property, target 'me', Edit effect: FrobInfo
(assuming this object doesn't inherit FrobInfo from the hierarchy)

Some attention may be needed with physics. If the telported object can move, there's a chance of it being disturbed at some point, either deliberately or by accident. Look at its Physics > Model > Controls property. If it doesn't already have Location and Rotation selected in the button at the top, select them.

R Soul on 10/7/2025 at 14:50

---

A few small changes need, all using existing properties you've added:
Bread object:
The Scripts property needs 'Don't Inherit' to be checked. That stops the scripts further up the hierarchy from being inherited by this custom bread archetype.
The 'AA' archetype seems to be superflouous. The script property could go on the parent 'A' archetype instead.
FrobInfo needs to be changed: All three 'buttons' should just have 'Move' selected (Inv action: Move allows it to be thrown).
The property 'can't drop this' seems unnecessary. Dropping is a reasonable action for the player to attempt.
Inventory > Type: Item is definitely unnecessary. That value is inherited from the Food archetype.
It also needs the property Engine Features > Combine Type, delete 'bread'. This will stop it combining with other bread objects.

The Source on MyObjToDropA:
You need to edit the one you've added, go to Edit Shape. Add 'Frob in Inv -> World' to the existing selection. That will allow the Stim to be 'transmitted' to any object the bread is used on, in addition to dropping or throwing it.

MyPlateA:
This has a spehere phys model. I think OBB is better:
Pysics > Model > Type: OBB
and
Physics > Model > Controls needs Location and Rotation selecting from the button.

With the Receptron, right now it frobs a button which then does everything else. That works, but it's using more objects than you need.
In fact, none of them are needed; you can just have multiple Receptrons:
1. Destroy Object. Target: 'source' [this will delete the first bread object]
2. Teleport Object: Target: 6 [the current ID of the second bread object]. Agent object: 'me'. Edit Effect: change Z to some small number, e.g. 0.2, whatever looks best. Set the Heading if necessary.
3. Set Property: Target: 'me', Agent: -1 [this is the root of the object hierarchy and it has a FrobInfo property with suitable values], Edit Effect: FrobInfo

(actually number 2 can be 'create object', and you point it to a custom archetype with a blank FrobInfo, and any other properties you want).

An additional thing:

There seems to have been a misconception about naming objects. I notice you've made a 'Start' archetype in the hierarchy then placed it in the mission. Same goes for the teleport traps and destroy traps - they each have their own archetypes which have then been placed in the mission. And the two plate archetypes. They're doing nothing.

The Start object is definitely done wrong. Correct process: Create a Marker in your mission, use the Properties button at the bottom, double click where it says A Marker (#) and that's where you'd put the Start name. Then, re-add the PlayerFactory link from this object to Garrett. The other ones won't break anything but they'll just add clutter to the hierarchy.

I've attached an edit with unnecessary archetypes removed. The plate and the bread just default items with the properties added to the concrete objects*, assuming this is a one-off setup. The only custom archetype is the final bread object. The latter helps to keep the mission free of hidden objects.

(https://drive.google.com/file/d/1xdrQBOTmRydVwUSAcGcdXbcmx2YW1ji6/view?usp=drive_link)

*It's personal preference. You can still have these as custom archetypes if you want. The main benefit to using custom archetypes is when you want multiple instances of them, or you want it to pop into existence at some point during the mission.

AnotherGarrett on 10/7/2025 at 16:53

---

Found the mistake:

Such a silly oversight cost me 3 days :D

AnotherGarrett on 12/7/2025 at 16:58

---

You're a really bad person for this. Now you've forced me to play your mission, or actually, the whole series. I'm not quite sure yet, but i think i might hate you ;-)