"This" and "Query" Gadgets - for working with groups of entities
So I have had this idea for a while and there is a ton of scope for features beyond this description. The idea is there is a new gadget called This. You place it in a chip or attach it to an object. It then provides an interface to information about This. A bit like the puppet interface. It would have the following:
- (input/output/tweak) group A (see below)
- (input/output/tweak) group B
- (input/output/tweak) group C
- (input/output/tweak) group D
- (input) signal to emitter (see below)
- (output) unique id that is instantly and automatically generated
- (output) detected by laser
- (output) detected by zone
- (output) decteted by collision
- (output) value A from emitter at creation time
- (output) value B from emitter at creation time
- (output) value C from emitter at creation time
- (output) value D from emitter at creation time
- (output) current scene space transform
- (output) current speed
- (output) current acceleration
- (output) signal from query gadget (see below)
So now we have a way to read/write information related to This. There would then be some improvements to the emitter object. The emitter object would have the following:
- (input) value A
- (input) value B
- (input) value C
- (input) value D
These inputs would be transmitted into the This gadget immediately upon the object being emitted. After this the values would remain unchanged, even if we changed value A on the emitter. It is a bit like constructor arguments in programming. I want to create an Item and I want its starting health to be 34 so I input "34" to value A.
The emitter would also have:
- (output) singal from emitted
This would allow the emitted object to send a signal back to the emitter it was originally emitted from. This could be useful for a lot of things!
The final piece of the puzzle is the Query gadget. This clever little gadget lets us specify certain filters and then send a signal to all This gadgets that match. The Query gadget would have:
- (input/tweak) group
- (input) value to send
- (output) number of This matched
So we would tweak the Query gadget and specify which groups to send it to. Then when we feed a value into the Query value input. Every this gadget that matches those filters would receive a signal!
As I said at the start this is the basic idea. There are more inputs/outputs/tweaks/filters I could suggest but I thought I would just keep it to the minimum!
-
Hey mate.
I don't think I fully understand what you're looking for. But some of it you can do already. Maybe some of it you can't, but I thought I'd mention the parts that may already do what you're looking for. Maybe those could be extended with the features you're looking for.
You can link a chip to an "affected object." Any gadget inside that chip will apply to the chip's affected object. Surface-snapping auto-hooks-up that link. So as an example, you could get the current acceleration by then adding a movement sensor and using its acceleration output.
You can set a value on an object-to-emit or a store a value in a node in the object-to-emit, by "looping the wire." Then whatever value was being sent into that setting the moment the object is actually emitted will be stored forever in that setting. So you're effectively setting some initial state, as you were describing. Here's my tutorial on the effect: https://youtu.be/JFOPhpa7TP4
-
TAPgiles To store a different value in each emitted object from a single emitter, you don't even need looped wires and nodes - you can make changes to the emitter's template object using "keep changes" keyframes and tweak the emitter to emit without wires. Each emitted object will then have the values set by the keep changes keyframes, and future changes to the power of those keyframes will have no effect on already emitted objects - and no extra logic is replicated per emitted object. That's how I created Langton's Ant (https://indreams.me/dream/mXEdQJExiCj) and 512 Byte Sculpt Label Encode RAM (https://indreams.me/element/oVKJvnTdgcv).
-
Oh I didn't see that there had been a responses to this thread. Whoops!
So basically yeah you can already achieve some of what this suggestion asks for but not everything. In programming languages we have so many ways to generate, categorise "objects" and then do stuff with. loops, lists, arrays, maps, trees, lookups hell even full blown sql/databases! So my suggestion was to provide a few gadgets to acheive some of this kind of stuff.
If we can categorise a sculpt in its "this" chip then the query object can send a signal to all sculpts that have that category. Imagine categorise some emitted sculpts as "item". Either by assigning it a number which your logic knows means "item" or maybe Dreams This/query lets you specify labels for groups. You can then have some logic that very very very easily signals all this chips that match "item". Of course we can kind of achieve this with wireless signals.. but think then what if you wanted to put an "item" in 4 sub-cateogires. Weapon, edible, etc. Your going to have to start using even more logic or thermo per category!
Another important factor is the logic overheard when we start duplicating many copies of an object. Keeping everything in a simple "This" gadget would drastically reduce the overhead! Imagine if you needed to save 8 values with an emitted object. Power, color, type, cost, weight and so on! To do this your going to have to have that logic for emit values into sculpt repeated 8 times per item. Theres are also then the 8 wires attached to the emitter logic. Then what if an item needs to report a signal back to where it was emitted from. More gadgets and wires! (on top of any logic the item needed internally).
TheBeardyMan oh wow does that really work? I have followed your creation and will have a look next time I am on Dreams. So how fast can that work? Is it limited to the one change per port per update?
-
Had a play with your 512 byte storage chip. Really impressive technique! I wouldn’t have thought to use labels as bits!
Unfortunately it still has a one operation per update (well it would take up to 2/3 updates for an operation because of laser/zone/emit speeds).
But really clever way of doing it!
iniciar sessão para comentar.