So basically, what I’m trying to do is to make both objects act solid and immovable and not have one move away from the other.
Also, I have an object group called “Enemies”. I have It set that when they collide, they move away from each other. Interestingly, only the same sprites move away from each other but they pass right through all of the other sprites of the Enemies group.
Any ideas what the problem may be? Thank you.
We’re going to need to see a screenshot(s) of the events you’re using to move and detect the collisions. While I love the image you posted, I can’t tell which objects you’re having trouble with. It could be as simple as needing a for each object but it’s tough to guess.
Hello Keith. Here’s the event I’m using. It’s constant and with no conditions. When I change it to “for each” collisions stop entirely, even among similar sprites.
Is “enemies” an object or a group? Events that reference instances of the same object usually don’t work, at least not consistently. The app can’t always tell the instances apart. We’re probably going to need a few more events. I don’t have a solution for you. Maybe someone else will.
What sort of movement are they using.
Enemies is an object group. I want them all to collide off each other and off the player. Currently, because enemy sprites only collide with the same type, they create an interesting “swarm” effect. If I had to live with it, it wouldn’t be the worst thing in the world. I will try to share a gif when I’m able to capture it.
Have you tried with a “Enemies is in collision with Enemies” condition before the action? I am just wondering if it is seeing one Enemies instance, moving it, but basically considering task completed until another sprite next in line in the Enemies group collides?
Yes, I’ve tried that. They still seem to only be colliding with the same sprite. I will post a gif of what’s happening. Had to compress it to get it small enough.
So just to be clear, the part where the “Enemies” swarm the player and kind of all converge on the player as one big mass right now is what you don’t want, instead you would like them to swarm around the player as a large mass, none overlapping. Do I have that correct?
Yes, each with their own area defined by their collision mask.
Well, this doesn’t help with your situation, but I made a mock up of your enemies code and I also had the same issue, with three sprites all in an enemies group, and they also only have collision with sprites only of their same sprite, making little clusters. Will think on it more tomorrow. 
IDK if this will help. I was playing around with a similar concept with the pathfinder behavior. Instead of targeting a position, I assigned each member a point around the target. If they’re given a target angle around the target, Im assuming this could be recalculated in realtime. Just a possible idea.
I made it more advance but this one had a project file and online version amd I’m not on my PC.
Click anywhere to place a target.
My project
Edit: I think part of the problem is when they start colliding it turns into a shoving match. One sprite pushing another then another one pushes back which triggers another one to push back and then chaos ensues. You need to create some order. Give them direction toward an empty space or priority over one another.
I’m not at my PC. Maybe if the collision tests were on separate lines or rotated through different frames.
I’ve used hidden sprites for collision and only moved the visible linked sprite if there wasn’t a collision and then moved the hidden sprite back to the visible sprite’s location. Thus preventing a collision with the actual sprite.
IDK if any of this helps. I’m just brainstorming. One concept might lead to another.
Thank you for the ideas, Keith!
When you use a separate collision object, what event would you use attach it to each enemy instance (I assume you would spawn it on enemy creation)? Do you think there would be a performance gain by doing that?
How would I type out the coordinate you’re speaking about above?
I tested it with the bounce expression. It kind of gave me eyestrain at this level and speed and zoom.
As far as performance, I have no idea. It would depend on the number of sprites. On the plus side, the real-time sprite wouldn’t be visible or drawn.
This does nothing but cause 2 balls to bounce. One regular. One on a grid.
Edit: I put in the inverted collision condition before the move because the ball was going into the wall. It turned out the wall wasn’t aligned to the grid. I’m not sure if it’s still needed. Aso, the hidden sprite is the same size as the visible sprite. (the walls still aren’t aligned to the grid. I didn’t think about that 
)
Last edit: I’m not sure if round or trunc would be the best. probably trunc.
I didn’t see the spawn part. Yes, I guess you could spawn both objects, and then link the objects together.
Click anywhere to spawn a ball
Thanks again, Keith. I will try the bounce behavior. Do you think there would be a performance loss or gain by spawning a separate collision sprite and attaching it to the enemies?
I have no idea. It’s a powerful system. I guess it depends on the number of sprites, resources and amount of movement. I think a lot of people use hidden hitboxes for collisions. IDK enough about that aspect.
I tried the bounce behavior of one of my sprites against the group “enemies” and it still didn’t detect the collision.
Is it possible to create group behaviors?
