Iterate Tags in a loop
You know what would be cool? A way that we could pick a particular tag name and then send a signal to it one by one. I do this currently using exclusive gates and a whole dump of logic. It would be so clean to have this built into Dreams.
Add a new output port to tag called "signal".
Add a new gadget called "find". Let us choose what to find using same options as we have for collision zones.
In the "find" gadget we should be able to trigger a loop start the same way trigger a counter start. Each Dreams frame of logic, it will loop through the "find" results internally and send a signal to it. We should be able to pump in the signal we want to send via an input port called "signal". Naturally we should also be able to stop the loop. Plus maybe have manual next and previous controls!
There should be a new sculpt output port for "signal". Because if we are searching on "name" then the signal needs a place to go!
Just like the wireless chips are two way ("signal from reciever"), perhaps this communication could be two way also. The tag gadget could have a new "signal" input port. Each item (tag) that gets iterated in the loop can then also in the same frame of logic signal back to the "find" gadget. This could be used for doing something like searching the scene stuff!
E.g.
"find "weapon" tags"
[find] -> (signal to tag) -> "weapon cost > signal" -> (signal to find) -> [find] -> "do something then stop the find loop"
-
I tried making my own logic for this kind of behaviour, and managed to do it without too much setup. Until this is something built-in, I thought I'd leave links to it here, in case people find it useful.
https://indreams.me/scene/dWorUXrzRJp
My setup is... somewhat simple. But there are a couple of key aspects to this setup that may not be obvious, and may be worth knowing about if you have problems using it:
- The ex-gate for re-queuing will open only when the queued stuff has been run through. So it will only re-queue everything once the queue is all done.
- Also, each iteration (plus re-queuing) takes 1 frame.
- Technically the data comes out 1 frame after its iteration, but in practise that's probably not a big deal. You could use variables/keyframes to remove that delay if you needed to.
- Wiring the "active" signal into its own "close gate" can cause a condition where the gate doesn't close itself in some situations. Wiring the active signal through something else first can change the order things are processed and avoid that issue.
-
Nice, yeah worthy to post it here for other to look at. I'll take a peek when Im next on Dreams.
The frame delay bit is one of the reasons to have some of this stuff built in. Mm have more control of the logic which means they can work in the timing of things without the user having to waste a ton of thermo putting guards in.
Iniciar sesión para dejar un comentario.