Emit With Values + Signal To Emitted + Respond To Emitter
I have had this concept idea for ages now, I suggested it as part of another idea before. I am trying again with a more concise explanation.
In the Emitter gadget, we should have multiple new input wires: "Argument A", "Argument B", "Argument C", "Argument D" & so on. Each should allow any wire type. We should have a new tweak option called "Emit With Arguments". When this is enabled, the current values feeding into the emiter "Argument A", "Argument B", "Argument C" inputs are sent along to the newly emitted object.
We should have a new gadget Emit Receiver. We can place this onto a sculpt. The Emit Receiver should have "Argument A", "Argument B", "Argument C", "Argument D" outputs. Whaterver the values from the Emiter were at the time of emitting, these are the values the Emit Receiver will output.
The Emit Receiver and Emitter should have pages of both inputs & outputs called "Message A", "Message B", "Message C". This provides a two way system of comunication between the emitter and the emitted. Feeding a value into "Message A" input on the Emitter will generate a value on the Emit Receiever's "Message A" output. Likewise, feeding into Emit Reciever "Message A" input will produce a signal on the Emitter "Message A" output.
This set of features would add the notion of constructors and return values to Dreams. It would add more power to create encapsulated logic. More "functional programming". It would allow us to construct event and messagining systems! We can achieve most of this already in some form or another, but there are issues. It requires lots of wasted logic. It can be hard to debug. It is not user friendly. It is messy with wires. If using "emit with wires trick", it hard codes the emitted object to the emitter. If using wireless signals we introduce complexity and lag with when values are and are not recieved!
Some use cases:
An Emitter attached to a gun fires balls. We want to color each ball depending on the color of the player the Emitter is attached to. We feed the color into "Argument A" of the Emitter and emit a ball. The ball sets its own color to whatever the Emit Receiever "Argument A" is outputting.
We use an Emitter to spawn multiple Zones. We send a random value to "Argument A". When the player stands in each Zone a counter increases slowly. When the counter reaches the value stored in "Argument A" it sends a the position to "Message A". The Emitter can check if it has receieved a value from "Message A" and react. Perhaps it could spawn a flag at the position it receieved. Why? This is just an example, used to illustrate the complex messagining between emitter and emitted!
-
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?
-
Some of the bits are doable quite easily. I think the benefit with a dedicated system is that MM could remove any form of lag/tag-detect/wireless/etc. A much easier to use feature for everyone. It’s akin to the new variable scope stuff. Instead of forcing us to deploy maybe 5-6 different techniques or widgets to make ”local variables”, we can now just scope variable chips! So much cleaner/cheaper. Easier for all people to understand.
The signals passing back is an issue yeah. But no more so then how we have to do it now. I had pondered since posting. I think in its current state, it could still be useful if it just had the same blending options. As long as the emitted logic only sends a signal back when needed. I’m sure there are better solutions to add new functionality to Dreams instead. Something like a message queue? Or list? All signals are queued in a new widget and then the logic has to manually pulse (next in list) to fetch the next value. A built in widget like that could really add power to dreams!
Vous devez vous connecter pour laisser un commentaire.