I found an error:

I get assertion failed: internal error: attempting to set body's angle to NaN: line 52 col 3.

When I tried to add a dampened rotary joint between to physics objects.

Both objects had their rotation disabled. I enabled one object's rotation and the error went away.. So maybe it doesn't need fixing since having a rotary joint between objects that shouldn't rotate wouldn't make sense anyways.

Thought I would mention it though.

Isn't the monitor refresh rate different than fps?

"FPS = Frames per Second = How many distinct images a GPU outputs, per second

Refresh Rate = Number of times a screen is capable of DISPLAYING, per second"

Shouldn't the physics simulation run exactly the same if both are running at 60fps, except one monitor is 60Hz while another is 120Hz?

There are various ways you can do it. You could set them all stopped, and then pick the objects based on their instance number or some other evaluation, and then start their movement. Or if object is down a certain amount, pick next instance, and start its movement.

Look into how to pick objects/instances, etc.

Use <> instead of !=

So, GUIbackground.Type<>"Static"

Ashley ,

Is it possible to mark where an instance was created, then skip every event until it gets back to the place is was originally? That way it would have the instances updated, but nothing will have changed, so it can then continue with the new instance. I would imagine that skipping everything would be quicker than having everything check the lists.

Maybe start picking from closest to first node?

here's a bit more experimenting I did: http://1drv.ms/1KJjNL5

It probably isn't optimized as well as it could be, but it might give you some ideas. There still needs to be a way to prioritize which unit goes first when two or more are competing with each other, but this example has a movement that works better than the previous example.

If you create one object that is part of a container, every other object that is a part of the container will have been created at the same time. You won't have an issue where something wasn't created yet, unless I'm misunderstanding your situation.

You need to create an order. I think something like this might be a good start.

You need boolean that will lock the unit from picking. You also need a variable Order. This is for units that player has selected.

Repeat "selected" count, pick nearest Units to MouseTarget, units boolean Ready = false. Then set that boolean to true and varOrder to loopindex. Now every unit has it's order number, so it might be easier to figure out how to get them pass trough.

Maybe that will help. Also,have a look at Ro0j example.

The issue I see with this is that the nearest unit may not be the one that needs to move first.

Whenever you click to create a path, it removes the previous nodes, so if the units are following the nodes, and you click again in the same location or nearby, the previous nodes disappear and you get one or so nodes at the place where you clicked.

You would have to store/save/update each path nodes in some way so that they all connect and go to the destination from the perspective of each unit.

I don't know how much processing would occur to create a path for each unit- but that is one way to ensure each unit has a node to go to (you could put the path-following sprite in a container with the unit so that each unit has a path-following sprite).

Maybe at that point, you could find which unit has a shorter path, and move them in that order (short to long). If there is any congestion, pause the longer path units that are behind the congested area/unit.

edit: this is also why I suggest a dijkstra, because those take less processing, and you get data that an unlimited number of units can rely on. I made a dijkstra plugin in the past for something I was working on and I never released it because it wasn't meant for public use. I'd have to clean it up and figure out a way to make it more user friendly.. Maybe I'll do that in the future, but I have other things to focus on.

Using paths for each unit might be a workable solution, but you would have to test it out.

If you move one item in a container, it shouldn't move any others. If it is, then something else is causing it (are they pinned together?).

When an item in a container is created, it will create all the other items in the container as well. You can create one item, and then create an event: On created, where you can position the other items relatively.

I get about 20 fps on the first one. It'd be better if you had a side by side comparison.

I experimented a bit, but didn't find any solutions. The issue I was facing is how to manage which unit attempts to go through the pathway first so that units don't compete with each other.

This would require more work to figure out than I'm willing to invest, since it basically means designing a way to store where each unit is, and how to process all of it so that they work with each other to get through.

One thing that comes to mind is using a dijkstra map instead of pathfinding, since that creates data that multiple units can use to move through a level. That way, each unit would have their own way of finding a path to the destination without generating one for each unit.

edit: also with a dijkstra map, the units would be moving towards the next tile rather than being pulled by something that could be currently behind a wall, so the flow of forces would be more accurate. You could also stop other units from trying to get to a tile if that tile is already occupied by another unit.

megatronx , I would probably try to cycle through the nodes, finding the node closest to the destination that is in the line of sight with the unit.

So I would check the last node to see if it is in sight, then continue with each consecutive node until it gets to a node it can see. I'd only do this if the object collides with a wall. Apply a force towards the node that is in sight.

If two units are fighting over a node, I would somehow apply force to only one of them (maybe the one closest to the destination)..

I'll try experimenting a little, but it might be something that requires more time to get right, and not sure if I can do too much.