Speed of ticks after timescale change?

Hello, I'd like to ask a quick question if possible.
I'm trying to workout if ticks is effected by timescale,
so for a test I had it create an object every 300 ticks.
I counted to 10 while timescale was at 1 to try and get
the rhythm, then changed timescale to 0.2, and it seemed
to then only take myself to count to 7 before a new
object was created.....How does that work?
If it is affected, shouldn't it slow down, not be faster?
Is there any way to stop it being affected, or a method
I can use to make events occur based on time in an easy
manner, unchanged between timescales?
Because I want to use timescale as part of the game, but
I want some events to occur after the same amount of time
without scaling because of timescale,
I'd greatly appreciate any help I can get for this.

The tickrate not affected by timescale.

Counting is not very accurate. Here is an example that measures the time over 180 ticks with switching timescale between 0 and 1:
profiling.cap

While the tickrate is not affected by timescale, it is affected by your system, by anything that detains Construct from getting processing time, and by a huge amount of events/tasks (e.g. drawing 20000 lines in the canvas object per tick, or creating 30000 sprites per tick, etc.)

Thank you very VERY much for taking such time to create such a fantastic
example for me, it really helped clear things up and I greatly appreciate it.
I wouldn't have a clue make an example such as that so all I could do
was try and estimate by counting.

So would running an event 'every x miliseconds' be more accurate if I
were trying to have something run consistently (say every 20 miliseconds),
or would that be affected by the timescale, or would ticks be fine for
something like that?sparkfeather2011-09-04 08:19:50

"Every X ms" would certainly be affected by timescale.

I think tulamide or Ash or someone said before not to use "Every x ms" since its not actually accurate.

[zenox98]

Can't find it on here, but there is THIS interesting thread regarding 'Every X ms' issues from the old forum.zenox982011-09-04 12:53:38

These 2 pages from the wiki are probably essential to read as well:

Time scaling

Time deltaalspal2011-09-04 13:14:08

Thank you very much for all your additional replies with further help.
It's just a shame it has to be so complicated to run games successfully
across different computers with different framerates/refresh rates,
and that timedelta confuses the hell out of me.
It makes it more 'programmer-skill-memory-independent',
and I've read the wiki link about it multiple times and I still don't
really understand how it's used/where it's used.
If timedelta is FPS independent, how do I do something simple like I would
with ticks, where I want to make an object after 100 ticks,
an amount of time that would be consistent across varying framerates?

Also in this example,
"Note that at 100 FPS, TimeDelta = 0.01 and 200 * 0.01 is 2: that's the 2 pixels per tick we needed. And at 50 FPS, TimeDelta = 0.02 and 200 * 0.02 is 4. In general, to move an object at a rate of pixels per second, simply use:
Set X to .X + (r * TimeDelta) "
What is the "r" in "(r * TimeDelta)"?

Also from what I understand, if TimeDelta becomes necessary to swap with
all my events currently using ticks, what would be the best way to have
things consistent in their time when I'm using timescale? Have seperate
trees with different times set based on the timescale at the time?sparkfeather2011-09-04 13:57:22

[Arima]

Every ms is not accurate at small levels, like 10 ms. For larger values, like 1000ms, it's plenty accurate, so using an every 1000 ms event to create something will work fine.

Timedelta is a measurement of time. It returns, in seconds, how long the previous frame took to calculate and render. So if you're getting 1 frame per second, timedelta returns 1. If you are getting 10 frames per second, it returns 0.1, as each frame is taking a tenth of a second for the computer to make.

Set X to .X + (r * TimeDelta)

So at 1 fps, to the computer, it becomes:

Set X to .X + (r * 1)

At 10 fps:

Set X to .X + (r * 0.1)

r is the rate. That's the value you choose for the speed. 100 will move it 100 pixels per second, regardless of the frame rate.

Set X to .X + (100 * TimeDelta)

If the current x position is 0:

At 1 fps:

Set X to .X + (100 * 1) = 100

At 10 fps:

Set X to .X + (100 * 0.1) = 10

Then after one second, the sprite will be in the same position regardless of the framerate.

Did that make sense?Arima2011-09-04 16:48:10

Arima described TimeDelta perfectly, which should help you get started with time-based developing.

Just make sure, you stick to one method, either time based or pixel based. Trying to combine those will only give you headaches.

[QUOTE=sparkfeather]If timedelta is FPS independent, how do I do something simple like I would
with ticks, where I want to make an object after 100 ticks,
an amount of time that would be consistent across varying framerates?[/QUOTE]If working time-based, you have to remember that the shortest interval you have still is one tick. If your game runs at 60 fps v-synced, the fastest your code is triggered is every 16.67 ms (1/60). Every time-based condition will trigger either exactly at the given time or as close as possible to it afterwards. For example, every 1 milliseconds will trigger at tick 1, tick 2, tick 3, etc., because the game doesn't run at 1000fps (which would be needed for 1ms).
To have an object being created after a certain amount of time, there are several methods:
- You could use the wait object, delaying the creation
- You could use timer (a system expression). Set a variable 'timestamp' to timer, and compare 'timestamp' against timer and the desired timespan. For example, to create an object 2 seconds after 'timestamp' was set to timer:[code]+ 'timestamp' less or equal timer - 2000
+ Trigger once[/code]
- You could use the timeline object

[QUOTE=sparkfeather]Also from what I understand, if TimeDelta becomes necessary to swap with
all my events currently using ticks, what would be the best way to have
things consistent in their time when I'm using timescale? Have seperate
trees with different times set based on the timescale at the time?[/QUOTE]That confuses me. The whole purpose of timescale is to have an easy way to change the timing behavior of all time-based code at once. So why would you want to change timescale, without wanting to change the behavior of the time-based code?