Had a brainwave: be tweak for node gadget. Set if attached wires should be emitted!
So I was experimenting with some logic and I wanted a situation where you could emit with some wires attached and some not. What if we could change a setting on each node gadget that says if the wire is emitted?
Example of where this might be used. Let’s say you have a main chip. It is responsible for emitting multiple copies of a another chips. It sends a signal to the emitted chips via wire. The emitted chip stores that signal using the “emit without wires” and a looping node trick. Now what if we want to feed a wire back out and back into main. You might want to do logic using exclusive gates or some kind of calculation. E.g. the emitted chip with highest exclusive gate feeds back the value into main chip. So at the minute if you emit without wires then the only possible way to speak to the main chip is to use a wireless signal. This has the massive downside of Dreams frame delay. So what if instead, we could enable “emit with wires” and then just manually disable some of the node gadgets!
There are other ways to solve the example above. It’s just an example. Adding the feature to Node Gadget would simply improve the flexibility of the emitter gadget!
-
That would be pretty cool! I've had this problem before too.
Something you could try for now, but may have some issues, is to emit with wires and have a wire -> normal node -> looped node. And a destroyer targeting the normal node. So frame 1: emit, node sends to looped node. Frame 2: node destroyed, looped node sends to itself to keep the value. That's how I've got around it in the past.
-
Good advice. I wish we could make a destroyer target logic inside a chip. I have a weird thing about emitting stuff not epcapsulated somehow lol!
-
If a chip is affecting an object, or surface-snapped to an object... then all gadgets inside that chip will also affect that object. Including destroyers.
-
Skn3-- Destroyers can target logic inside chips - I used that trick in "Unique ID Receiver" ( https://indreams.me/element/onpSSnmBuaz ) to clean up logic that was no longer needed after the unique ID was received. As TAPgiles mentioned, there can be issues with the Destroyer gadget inheriting an extra affected object connection from its parent microchip, but even if there's a reason why the microchip needs to be surface snapped, that can be worked around by moving the Destroyer gadget itself outside of the microchip - the affected object connection that you wanted will still work.
Войдите в службу, чтобы оставить комментарий.