ClonesGame.com Forums

[CCX]

This is not necessarily a bug, but unintuitive enough that I thought it's worth calling out.

I have a level (attached) where a stream of clones from the entrance all encounter a clone-triggerable proximity trap linked to activate a decoration trap (gives the clone a touque), but the link has a delay set, and moreover, the delay is such that the next incoming clone will trigger the proximity trap before the current clone's link delay has finished elapsing.

The intended effect is that each clone will get their touque one by one, N seconds after they come out.

However, if you try it out, what instead happens is that the next clone triggering the proximity trap will effectively reset the delay for all the previous triggered clones as well. So no one gets their touque while there are still clones coming out. Then after the last clone come out, and then N seconds more, and suddenly everyone gets their touques all at once. If you lower the entrance's spawn rate enough so that the link delay elapses before the next clone's triggering, then you'll get the intended effect.

Again, not necessarily a bug per se, but it took me by surprise enough to lead me to point out the behavior here (for v1.29 anyway).

A possible mitigation I'm going to try is to make duplicates of the proximity trap, and have it such that triggering one will disable itself and then enable the next one. Basically spread out the triggerings over several traps so that each copy has enough "breathing time" between triggerings to avoid the effect described above. Of course, in a multiplayer level since both the entrance spawn rate and the number of clones released are configurable, there will be some practical limit beyond which the workaround will break down (ie. the higher the spawn rate and/or the more number of clones released, the more duplicates you'll have to use).

[rt]

Good job nailing down this strange situation. Each new clone that triggers the trap will reset the count for that delayed action. The problem is that the proxy trap is not spawning new actions to count down independent of the trap, there is only that one action. But it does keep track of which clones have trigged it so that when the delay expires it finally sends out the Activate() message for each clone that had triggered it.
Your solution to temporally space out action by having multiple proxy traps would work well if the release rate was fixed. I can't immediately think of another workaround.

[CCX]

Perhaps it's worthwhile to think about adding a new contraption that implements per-triggering delay-activate behavior? It would avoid the need to modify the current proximity trap behavior, or the need to resort to somewhat unwieldy workarounds involving massive duplication of proximity contraptions. The idea is that the proximity can activate this new contraption w/o any delay itself. The contraption has a setting for how long to delay, and basically keeps a queue of pending activations [and the clone(s) linked to each activation]. For each activation, after the delay since activation time has elapsed, the contraption will activate its target, passing on the clones linked to the original activation as the target clones.

===============

For background information, the reason I'm interested in this has to do with a multiplayer concept I'm thinking about, whereby each clone emerging from the entrance has a set amount of time before something bad happens to the clone. My current candidate options for what the "something bad" is include the following:

- the clone nova after a set amount of time
- the clone atomize after a set amount of time
- after a set amount of time, the clone changes color in a manner consistent with encountering a swap trap [not sure if I can actually implement this option with existing contraptions--I don't think you can swap on demand by linking a proximity trap to a swap trap]
- after a set amount of time, the clone changes to a color not playable by anyone on the map, in effect you lose control of the clone. Furthermore, there are a few variations on this scheme:
a) the clone changes to a color such that if it hits a swap trap, it will swap back to its original color before the change
b) the clone changes to a color such that if it hits a swap trap, it will swap to a different color from its original color before the change (in effect your opponent would gain control of it)

While I can (and plan to, if I have time) create specific levels featuring these modes of play, I'm actually thinking that this could be potentially an interesting option to apply to any multiplayer level in general (as long as the admin/host take care to set the parameters carefully so the level remains playable, of course).