This is partly show and tell, and partly a cry for help.

I've been looking into a way to get information from one clone of sprite A, to another clone of sprite B, and had the bright idea of passing information through color changing. 5 hours of pain later, I have a working proof on concept that:

1) Assigns each clone a clone id upon creation
2) Switches each player clone to a red costume, and sets the color effect based on the clone id
3) Has the ground clones keep track of what colors they are touching, and work backwards to find out what color effect, and then clone id they are touching
4) Tallies up how many ground panels are touching each player clone
5) Loops through each tally and averages out the angle
6) Sets list in the same order as clone id with the averages
7) Updates the player rotations and snaps them to the top of the ground

This system works much better than it has any right to, as long as you never have colors in your project that are 100% Saturation, and 100% Value.

Basically, while this is a fun concept, it is completely ridiculous, and I'm really hoping someone has a better system. (Yes I realize there are alternative systems to finding ground angle, this is just an example)

Please help end this misery

Just use two lists for each sprite.
Each item of one list will hold the contents of one clone.
Whenever a clone's content changes, broadcast a message to the other sprite, and indicate which clone IDs content changed in a global variable.

Much more simpler and practical.

Chiroyce,
Thanks for the suggestion! I’m having a bit of a harder time picturing how it would work. If I understood your idea correctly, would this be requiring it to just simulate the interactions mathematically instead of using touch sensors? If so, what suggestions do you have for irregularly shaped sprites?

Just to clarify again, the system needs to be dynamic for any number of sprite A’s and sprite B’s, not just a clone from each.

minekraftkid wrote:

Just to clarify again, the system needs to be dynamic for any number of sprite A’s and sprite B’s, not just a clone from each.

Ahh okay… my idea would only work if the number of sprites were fixed (clone count can be variable)

Yep! Thanks for the idea though.

<touching [ v] ?>

works with clones if you put the parent sprite's name in, so another way would be to hide all the clones and show each one in turn. It's a bit more efficient than TOUCHING COLOR? and might be a bit less troublesome in some cases, but I guess showing them each in turn probably won't be significantly better than what you've already got (with run w/o screen refresh of course).

Jonathan50 wrote:

hide all the clones and show each one in turn

This what I actually tried to do at first, but I was unable to get it all to run in one “tick”. I'm guessing there is some broadcast trickery that can make it work, but I couldn't get around the delay between getting each check. That's why I ended up messing with color, because we can check it all at once, even if it's impractical. Do you have any suggestions for eliminating the delay?