• News

• Industries

• Learning & Support

• Community

• Marketplace # Time based only on Distance?

Been looking at the S=D/T formula but realised I only have a Distance to work with. I’m using an Ease function so the Speed is not constant and Time is just a looping value updating “Get World Delta Seconds” so can be any length.

You can set a float to game time, and take a look at the end. Time it like that.

However, if you’re using tick to move objects ( without a timeline ), unless you multiple by delta time, the elapsed time will be different depending on system performance.

What you want to do is `speed = distance(lastFrameLocation, currentFrameLocation) / deltaSeconds`; delta seconds is the time that has passed between the last frame and the current frame.

Thanks but not sure how to do this in BP?

Also won’t it be affected by frame rate?

What are you trying to achieve in the first place?

You have a distance… between what, and what?
You update something based on this distance … what are you updating?
How would you want that update to happen if the distance when starting was 8 units?
How would you want that update to happen if the distance when starting was 8000 units?
Would it take the same total time in both cases? Or would the velocity be fixed, and it would take longer the further you go?

Trying to read between the lines, here:
You’re trying to move a `Thing` from a `Start Position` to a `Destination Position`
You’ll want the velocity of doing so to be constant, so it should take longer when it’s further.
You’ll want to use “easing” in and out for a smooth acceleration curve on the `Thing`.
You’re not using physical simulation, so you’ll just draw the `Thing` each frame.

The way to do this is:

1. When you determine that you want the move the `Thing` from `Start Position` to `Destination Position`, you calculate the `Total Time` as `((Destination Position - Start Position) / Velocity)`
2. You capture the `Start Time` (as game time) when you start moving the `Thing`
3. When you update the position in `Tick`, you calculate `Thing Time` as `Current Game Time` minus `Start Time`, alternatively you increment `Thing Time` by the `Delta Time` (no need to capture `Start Time` in this case)
4. If `Thing Time >= Total Time`, you’re done; the Thing should be at `Destination Position`
5. If `Thing Time < Total Time`, then you should make the position of the object be `(Start Position + smoothstep(Thing Time / Total Time) * (Destination Position - Start Position))` or, alternatively, `smoothstep(Thing Time / Total Time, Start Position, Destination Position)`, if you have three-value `smoothstep()`.

The `Velocity` is configuration information for `Thing` and you need a state all of `Total Time`, `Start Position` and `Destination Position`, so put those in actor variables.

You can also do this by playing a suitably scaled `Timeline`, if you’re wanting to lean into animation a little more.

If you want to do this with physical simulation, it gets harder – you need to solve a differential equation of arrival time relative to your maximum desired acceleration, and accelerate towards the goal, until such time as your travel-velocity integrated with braking-force over remaining distance gets (very close) to zero. If the target is also moving, then this gets even more exciting!

1 Like

Doing this on the default third person character while walking will give you a result of 600, which matches the character’s max walk speed: If your movement takes into account delta seconds (i.e. `offset * deltaSeconds`), the speed won’t be affected by framerate. By multiplying the offset with delta seconds, the offset becomes a velocity. In other words:

• `Tick -> AddActorWorldOffset( (1,0,0) )` means “move this actor one unit per frame”
• `Tick -> AddActorWorldOffset( (1,0,0) * deltaSeconds)` means “move this actor one unit per second”
1 Like