# How do I predict an orbiting object's trajectory and draw it

Get help using Construct 2

### » Sun Jan 11, 2015 5:15 am

Hey again @McDonald,

Sorry, my explanation, may have been a bit vague in places.

So, here's what should happen in a single tick:

[TICK START]

// First we advance the RealShip by one time-step.
Every tick: RealShip.state = updateFormula( RealShip.state )
// The ship's "state" information is its XY position, and XY velocity.
// Given the current "state", the "updateFormula" computes the new state for the next time-step.
// // I'm using updateFormula as a shorthand here, in your actual code it may be a block of two or more events.

// Now we prepare the ghost ship to execute a simulation of several future time steps.
// First we set the ghost ship to match the real ship's state, (XY position, and XY velocity).

Every tick: Ghost.state = RealShip.state

// Now we're ready to start the simulation.
// We'll run 100 iterations, and with each, the ghost will advance 1 time-step into the future.
// (Note that the tick has not ended yet.)

Loop from 1 to 100
:
// We update the Ghost, just as we would update the real ship.
// Critically, we feed the Ghost's state to the updateFormula, and NOT the RealShip's state.

[sub] > (always): Ghost.state = updateFormula( Ghost.state )
[sub] > (always): Ghost spawns a dot object.
// The ghost has now plopped down 100 dots.

[TICK END]

Essentially, you'll be triggering the same time-advancing code that Construct would trigger each tick (frame-draw), but you're not waiting for Construct. You're manually triggering the code 100 times before the tick ends and the frame is drawn. You're just doing it with a ghost copy of your ship.

As for working with player controls, when the simulation is updating the ghost ship, you can have each loop iteration update the ghost as if the player is continuously holding down the same controls that were used when updating the real ship.

Hope that helps out.

Variation
As an alternative variant of the above approach, you could conceivably run the simulation with your real ship, and not even bother using a ghost ship.

You would need to store the state of the real ship after its update, but before starting the simulation, so that you could recall the real ship back to its proper pre-sim state, before executing any remaining code in the tick.

Thus, even if during the simulation the real ship collides with a lethal object, you'll still be inside the sim loop, and none of your collision handling or ship-exploding code will be running yet. So as long as you put the real ship back, by the time your collision handling code runs, it will never know the ship "time traveled" into a future hazard.
... And witnessed its own death! D:

Also, dang it @R0J0hound, how are you always using a newer version of construct than me.
I probably need to enable beta updates, huh.
B
30
S
20
G
8
Posts: 350
Reputation: 6,479

### » Sun Jan 11, 2015 1:46 pm

@fisholith
Well, I still have a problem - I update the real ship, then update the ghost ship, then loop it 100 times, but the ghost doesn't update and stays in the same place as the real ship, spawning 100 dots every tick. My every tick event looks like this:

>Start tick
>Do physics stuff and update real ship
>Set ghost's state to ship's state
>>(sub-event)Repeat 100 times
>>Do physics on ghost
>>Spawn dot on ghost
>End tick

Yet the ghost doesn't update and spews dots in the same place.
B
3
Posts: 9
Reputation: 193

### » Mon Jan 12, 2015 2:15 am

Hm...
I suspect one of two things is happening.
A: The ghost ship is not actually being updated inside the loop.
B: The ghost ship is being updated inside the loop, but to the same spot 100 times.

If the buggy ghost ship is always exactly on top of the real ship, then it's likely that it's situation "A".
If the buggy ghost ship is always exactly 1 time-step ahead of your real ship, then it may be situation "B".

The most likely cause of situation B is that, inside the loop, each loop iteration is setting the ghost.state to
updateFormula( RealShip.state ),

It's hard to say exactly without seeing the events though.
If you can post a screen grab of the events in question, I might be able to figure it out from that.
(In the event sheet, if you select a bunch of events and right-click on the very left edge of an event block, one of the menu options should be "Screenshot Selection.")
B
30
S
20
G
8
Posts: 350
Reputation: 6,479

### » Tue Jan 13, 2015 3:54 pm

I cut out some irrelevant actions.
B
3
Posts: 9
Reputation: 193

### » Thu Jan 15, 2015 11:04 am

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. :)
B
30
S
20
G
8
Posts: 350
Reputation: 6,479

Previous

### Who is online

Users browsing this forum: Ironic Chef and 4 guests