TimeDelta value of 5.e-002?

I've got an issue where I'm trying to increase a value over time,

and from everything I've read it's best to multiply it by timedelta

so that it increases evenly instead of relative to refresh speed/etc,

however it increases far too much in specific moments so I wanted

to see how high the TimeDelta value reaches, and 5.e-002 was recorded.

Is this a permanent bug that I can't do anything about, is there

a workaround? Because it's breaking my gameplay because of these jumps

of TimeDelta value.

I would be extremely grateful for anyone that can give me advice about

this topic or let me know the cause or any possible workaround/fix?

There are a few threads about timedelta, which should be helpful. But in short:

timedelta is the time that has passed between the last tick and the current one.

5e-002 means 0.05

That means, that your game's speed was 20 fps at that moment.

timedelta is always relative to the current framerate. If at times the processor doesn't have much to do and the framerate is e.g. 500 fps, then timedelta will be 0.002, at other times, when the framerate is only 10 fps, timedelta will be 0.1

Timedelta assures to do something over time, if (and only if) used on every tick.

If you do something like "a = a + 10 * timedelta", then a will raise by 10 per second, no matter the frame rate. But it does not evenly raise "a" per tick. It's just the opposite: it raises by whatever value is needed to get to a total of 10 per second, which may be a lower portion or a higher one, depending on the actual time, that passed between any two ticks.

Ahhhh, thanks a lot for explaining that so well and so quickly ^^;...

I didn't have any idea that it would equal to 0.05, because I thought

logically if it was a smaller number it should say it specifically.

I guess it was valued as a higher number recorded was because it had

5 at the beginning, rather than getting it's actual value

(I had a variable to set itself to delta value only if it was higher

than the current value).

I guess the strange bumps of values must be something else that I can't

see that I have to deal with =_=; why Dx

Anyway, thank you very! much for explaining all that for me so quickly,

means I can move on to look for other reasons without much delay ^^;

It might be (never tested it) that the scientific notation is interpreted as a string. If it is, then any try to calculate with such a string would lead to a simple conversion (without further explanation for now :) ). In result the number would be 5 instead of 0.05 and could cause such unecpected jumps.

If you're willing, post your cap or send it via pm, and I will have a closer look at it.

I went to build an example file to send to you with the major parts I thought may have caused the issues, however it wasn't working.

Then with further testing in other areas thanks to ruling them out,

I was able to find the answer so thank you very much :D

I discovered that it was an annoying bug.

It seems that, when you multiply a 'Clamp' number, it automatically sets

it to the maximum value multiplied by that number.

So, '(Clamp(value)+(10*TimeDelta), 0, 500))*5)' would always be 2500,

however I didn't realize this because the max value I had was based off

other variables that were always changing.

So thank you very much for leading me to the solution, this one was

really killing me and I didn't think I'd find it, thank you so much :)!