Download

Spawning at moving location is not accurate?

Hi

I am trying to generate a track for an endless runner, the way it should be done, with the track moving towards the player so there will never be any out off bounds issues.

I got my testing track piece with an arrow component used as a spawn location for the next piece ready. Basically the construction is the same as it is in the Epic’s tutorial. But my track pieces are moving towards the player and this makes a huge difference. The Engine is unable to spawn the new piece at the exact location of the Spawn Transform provided.

The operation seems fairly simple. The reference for the spawn point is stored in the variable. Once my track piece passes the -5000 location on X:

ZPQQyYG.png

The spawn event is triggered:

fnzLTzS.png

Yet it can not do it precisely. I can easily see where the new pieces are spawned as there are artifacts on the connecting edges. And the pieces aligned manually fit perfectly of course.

Any ideas?

I really doubt this is a precision issue :stuck_out_tongue: the spawn location should be exactly at the coordinates given.

It’s probably a timing thing (maybe you are spawning a frame later or something like that)… try to debug your transform values, that might give you a clue.

Well, by precision I mean both location and time, because of the animation. The problem as I see it now is that it can’t really be done in a more simple and straightforward way. This method, as it uses a single dedicated node, should simply work, shoudn’t it?

Are you increasing speed over distance?

Are all the track pieces misaligned or just some?

Narg

The speed is constant, at least for now, I do want to increase it later on (with time), but at this stage of testing it is still a constant value. However a complete solution should work with the speed increasing.

And yes, it looks like all of the pieces are misaligned, with a varied offset.

So

I did a small debug… I am printing out the spawn point world transform:

  • at the beginnig of the spawn procedure
  • and at the end

Both values are identical, yet the segments are still misaligned. This doesn’t make much sense…