I've been trying to manually create a trail for a very fast projectile. If I just attach an emitter, it only releases emissions at the positions its at each frame, which are really far apart since it's going so fast. So what I'm doing is tracing ahead using the projectile's current velocity and creating a trail at several points along that vector, so the trail looks more continuous.

The problem is, I've discovered that in CC the velocity of something doesn't measure how far it will travel in pixels in one frame. If you measure the change in position versus velocity, the change in position is a much smaller number, about 1/4 or 1/5. So does anybody know the proper conversion between an objects velocity and how far it actually means the object will go? I could just approximate it probably, but it'd be nice to know some exact numbers.

I'm afraid I can't help you with a number, only a suggestion.
You could potentially derive it experimentally with a projectile... Perhaps every frame output Δposition/velocity, then on destruction, the average of all of them? There is a "dump console to file" command, isn't there?

I've found that generally, movement in pixels due to velocity is about 1/3 of the actual number. So, for instance, if self.Vel is (3,3) and self.Pos is (0,0), next frame self.Pos will be (1,1).

Yeah, this is what I've discovered as well. Good enough I guess.

@TLB and Darlos

Just out of curiosity, what are the DeltaTime's in your Settings.ini?

I was working on similar thing just during last week.
How about drawing the trail after the projectile? Store the position at the end of one cycle and draw trail from it to actual position in the begining of the new one? It worked fine for me:


By the way maybe you would find something useful here or even give me some advice as more experienced Lua modders.

This is what we know: Velocity is expressed in m/s. The time between updates are defined by delta time. The size of one meter is defined by PixelsPerMeter.

I suspect it works like this: PixelsPerMeter*DeltaTime -> 20*0.0167=1/3. This would mean that the "movement factor" can be calculated like below to avoid problems with players using custom delta time.

Good to know! I will use this.

yeah, was going to mention pixelspermeter, but the fact that 1/3 works perfectly threw me off a bit. nice to know its an interaction with the deltatime.

I love threads that talk about how bad Data is at modeling physics.