Skip to main content

Report this content

We want the Dreams coMmunity to be a safe, diverse and tolerant place for everyone, no matter their age, gender, race, sexual orientation or otherwise. If you believe this content to contradict these principles, you can file a report for our coMmunity teams to investigate.

Note that misuse of the reporting tool will not be tolerated.

Item being reported:

A forum post by Skn3--

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!

Oh dear! Your browser is either unsupported or there has been a problem loading the page.