How do I delete an entity if its controlling interface script is stopped suddenly?


I’m having an issue where my pet entity is created and controlled by an interface script, but when I log out or crash, the interface script is stopped suddenly and cannot delete my pet entity. It looks like the scriptEnding callback is not called.

I’ve tried a few different approaches. My last one was to put an entity script on the pet that would self delete if a method wasn’t called in the last 10 seconds. This does not work when run with multiple avatars in the room since only my interface script was calling the method on the entity script.

Any ideas or solutions you guys are already using?


Ok, I found a way that works, but feels really hacky. My pet starts witha lifetime of 10 seconds. My controlling interface script increases that lifetime while it’s running. When I log out or crash the lifetime will stop increasing and the pet will dissappear in ~10 seconds. I think this will still cause my pet to despawn after the max 3600 second lifetime.

I’d much rather see interface scripts call the scriptEnding callback on close (if they are able to) but that would still leave crashes as a problem.

I’d love a cleaner solution, so if anyone has one, please let me know!


I’ve come across this today as well, I also tried setting the lifetime. I was hoping it would restart the timer.
It would seem all entities can only persist for an hour at the moment.


Lifetime setting is probably the best way to do it. Just note that there was previously a bug however which forced 3600 s regardless what the lifetime was set to.

I just get the age of the entity and add a 2-3 seconds to it each throttled update tick. The reason why this should be throttled is to avoid a collision where you update the entity at 60 fps, only which updates the server in large packages.

Secondary thing to do is to add a safeguard that if the entity that is being controlled disappears then a new one is created. This makes sure that incase the timer fails to update the server in time, or if you reach the 1 hour mark, a new version of the object is created while in control.


All these time consuming hacks are OK as alpha workarounds, but we need something that scales for production use. Remember that when an entity has a script assigned to it, it cause all clients in proximity to the entity to run that script. Imagine if instead of one entity it was 3000 of them. Now multiply that by however many clients are in proximity to those entities. This is how MB/sec of bandwidth gets eaten with worthless transactions.

I suggest implementing a dead man switch for entities but done so smartly, It becomes clear to me, given such low level implementations in HF, that there is a need for administrative or lifetime management of entities. This still can be something provided by world builders. One possibility is to add a new “run-in-AC” property with a uuid which selects an AC script to manage the entity. It can then do whatever it needs to do to handle things like lifetime management or the no-observers case.


The discussion here is about interface based scripts which only run on the client side and are not run by other clients (controlling interface script), not the entity scripts, if you read the discussion title properly. Because the issue here is that if the client teleports, or crashes, the control is lost and the entity is just left sitting there where it last was controlled at.

But yes, a deadman switch for entities should be tied to the physics simulation: if a temp object is controlled by someone, it should automatically clean it self up if the session expires. I discussed this with philip during the last meeting.


I understand the discussion is abut client scripts running, and my point is that this is a truly messy situation.demonstrating a lack of proper architecture. This is exactly the issue I have been hammering at fro many months. It is time to stop hacking and start thinking architecture.


If the pet is a child of the avatar, it will be deleted when the avatar leaves the domain. This might, however, have some other unwanted consequences.

Another option is to make the pet be associated with the avatar (it doesn’t have to be a child of the avatar, though it may make sense to do this) – do this by putting an extra boolean “true” in the arguments of addEntity, something like:

    type: "Sphere",
    position: Vec3.sum(MyAvatar.position, { x: 1, y: 0, z: 0 }),
    ignoreForCollisions: 1,
    dimensions: { x: 0.6, y: 0.6, z: 0.6 },
    color: { red: 0, green: 255, blue: 0 }
}, true);

These “avatar-entities” are sent to other interfaces via the avatar-mixer rather than via the entity-server. This will also have some consequences – the thing will follow you around between logouts/logins and domain changes (they are kept track of in your local settings file).

Let me know if I should talk more about either of these options.


Thank you for mentioning those options. I think using the second option would have helped.

I don’t want to sound whiny and I realize that Hifi is in a constant state of flux, but this parameter is not documented in the addEntity() docs and it would have saved me hours of tinkering around if it was.

Until the documentation is updated is there a place I can parse through myself to see the actual code for these APIs?



yeah… specifically


Thanks very much, this will help a lot!


Hi Seth, this seems like a more useful approach for designing a pet, if your intent is to have it follow you around consistently, You say they are kept track of in the local settings file. So if I understand correctly the properties of the entity will be serialized into the interface.ini to allow persistance during disconnection?

I also had noticed when the script ending callback is called on shutdown any further procedures seemed to complete, yet deleting an entity during the sequence of events will not seem to be successful, maybe it was something I did wrong.


Normal entities are kept track of by the entity-server and rebroadcast to interfaces. Avatar-entities are not sent to the entity-server. They are serialized with avatar identity packets and sent to other interfaces via the avatar-mixer. So, when the interface that is broadcasting an avatar-entity disconnects from a domain, that avatar-entity will also vanish. The avatar-entity is also serialized into the local interface settings file. When the interface reconnects to a domain, it will begin broadcasting that avatar-entity again.

The idea was to allow for worn entities (hats, watches, etc), but it seems appropriate for scripted pets, also. The pets wouldn’t be proper children of the avatar, but could be scripted to stay near the avatar.

It’s true that attempting to delete an entity from a script shutdown will generally fail. The problem is that, by the time the script is stopping, the interface may not longer have a connection to the entity-server. With no connection to the entity-server, it can’t send a “delete this” edit packet.