Report this content

Would be useful... Below I discuss the topic, what's possible now, and potential issues Mm would need to resolve in implementing such a feature.

As you say, most of this can be done currently. My favourite is to use a looped wire, *without* emit with wires. This basically stores whatever value was being sent at the moment it was emitted. So you can pass values to the emitted object like that. Has its caveats, but it's very easy to use at least for straightforward uses--and expands the usefulness of emitters a ton once you know how to do it. [Tutorial]

I also have other tutorials on how to emit logic to perform some operation and report back--so then you can have that logic only exist while it's needed. In this playlist, check the "Emitting and Destroying Logic" and "Communicating with Emitted Logic" videos. [Playlist]

If the source is moving around, you could have a tag. And in the emitted object have a block/chip that teleports to that tag so it's always in contact--something like that. As long as another same-named tag doesn't wind up closer somehow (theoretically impossible if it's inside a collidable object, eg. a puppet) then the teleporter will continue to follow that tag, and stay in communication through wifi or whatever.

When an object is emitted from a possessed object, it is "owned" by the same player. That's what all the "consider players" stuff is about; detecting that ownership of possessed objects and objects those possessed objects emitted. [Docs] So the bullet example is very easy currently.

I think a potential issue would be normally you will emit may of the same object from the same emitter. And so they'd all have different message values being sent back at all times (even if it's 0 most of the time). So those values would be blended in some way, I assume?