Ah, okay. I think it may be the use of the "Physics" behavior.
I had been thinking you were using a home-made physics system that just did force, velocity and movement. This would mean that you could move an object each iteration of the loop as part of the update process. By contrast, the Physics behavior doesn't expose any kind of "update on command" functionality, to my knowledge.
Here's a deeper explanation of what I think is going on:
By default, C2's Physics behavior is handled by the Box2D physics engine.
(I'll refer to the Physics behavior as "Box2D" from here on, though C2 actually allows other engines as well.)
If I recall correctly, loosely, the way Box2D works in C2 is that, you tell Box2D you want to apply forces to an object, and Box2D will update (move) the object for you. Box2D is hard-coded to do that update after all your events, but before the next tick.
That right there is the problem.
You can't force Box2D to do multiple updates in a single tick. The C2 plugin doesn't give you the ability to force Box2D to update on command.
So, inside a loop, if you add a Box2D force to the ghost, for 100 iterations, it will just pile up the applied forces on each other into a larger and larger single force.
But Box2D won't update the ghost's position at all yet.
So each iteration, the ghost is still in the same place, and all the prediction path dots show up in the same place.
The problem is, Box2D will wait for the loop to end, and it will wait for all your other events to end, and then before the next tick, it will apply that one massive 100X force to the ghost, moving it to who knows where.
(It also doesn't matter where, because the ghost's position will be wrong, and it will also get reset next tick.)
It is theoretically possible to get this path prediction system working with Box2D, if the Physics behavior plugin was modified to provide an "update on command" action, but without being able to force an update, you can't use Box2D to move the ghost on each iteration of the loop.
Sadly, this means that, other things being equal, this prediction method just won't work with Box2D.
One possibility, (that doesn't involve modifying the Physics behavior plugin), is to recreate, in C2 events, the same update formula that Box2D uses. You can then use that to move the ghost ship, each iteration.
Fortunately for your purposes that update formula is probably the simplest part of Box2D to recreate. Basically just, apply force to an object, determine the new velocity, and move the object based on the velocity.
I think by default Box2D uses a frame-rate-dependant mode, so if you know what math Box2D does on each tick, you should be able to exactly recreate it.
As not-so-fun as that might sound, I think it's probably what I would try if I were in the same situation.
One tricky part may be figuring out what Box2D thinks the ship's mass is, because I don't think there's any way to get that info from C2 in the correct units. Though I have seen a few posts on the C2 forums talking about the pixel-to-mass conversion that C2's Box2D uses. I think it was either R0J0hound or Ashley I saw talking about it.
I wish I could offer more help, but I'm not that familiar with Box2D's internals, or how precisely it's integration into C2 affects the behind-the-scenes math.
If I think of something else, I'll let you know.
Best of luck. :)