Timer and Performance Game

[Damonya]

If I put too much timer that executes at infinite, does it decrease the performances when I play on the game ?

I implements an overall system in my mod that requires that many timer runs every 0.1 seconds to infinity. I currently have 30 timer for only 1 level, but probably 100 (or more) when I will finish all levels of my mod. Hence my question.

My overall system can certainly run without this kind of timer, but it is quick and easy to build, for the desired effect.

[Ryeath_Greystalk]

I'm sure it will eventually slow down performance but I don't know how much. I think a larger concern which may or may not effect your mod is the timers will slow down the further you get away from them in levels.

For example on level 1 a timer set to 1 second will tick every second as long as the party is on level 1. When the party moves to level 2 the timers on level 1 will tick slower, maybe every 2 seconds. If the party goes to level three the timers on level 1 will only tick every 3 seconds etc, so forth and so on. I don't know if the time loss numbers I used are correct, but I do know for a fact the effect is true.

[Xanathar]

I think the problem is more related on what you do on timer ticks than the number or frequency of the timers themselves.
Just to horrify petri I'm currently using onDrawGui as a fast timer for fast things which needs to be processed fast, with no measurable performance impact. But of course if your code takes 1 second to execute even a single 1 second timer will completely kill the mod.
So, bottom line, I think the only way to know is to simulate the scenario by duplicating your current level 4 times and measuring the effect before and after.

[Damonya]

Ok so bad idea. Even if I need the timers run only near the player. In fact I could probably make more complicated system, but I'm lazy and with lot of timers infinity it's easier. ^ ^

My timers do only one thing, each timers reset their own counter every 0.1 seconds. Only this. Too bad I'll have to script a little more. I don't want to lose performance games, only for that => reset a counter.

[Xanathar]

I really doubt you'll lose anything performance-wise if it's just resetting a counter.

[Damonya]

You're right. Finally I'll keep, just because I can put at the end of my level an hidden_plate which deactivate all timers of the level as the player leaves. Thus it divides the number of timer running at the same time. About 20 or 30 by a level I think. I don't need reset counter when the player is not here.

I could use a variable with another lot of counter, but I should include this and change all functions of my scripts (a lot of function, the same number 30 by level). With infinity timer, not need to change script, this is why I prefer, I'm lazy.

In fact all this is to use a system with scripted spoiler help.

Very simple example of puzzle:
When a plate is on, it opens a door to reach a key. When the plate is off, the door closes. = Solution of the puzzle, put a stone on the plate for have time to open the door and take the key.

Spoiler scripted:
- Activate 5 times the plate without taking the key:
"I should find a rock"

The plate is connected to the counter "puzzle_1" and the function "puzzlealpha()"

puzzlealpha function ()
if puzzle_1: getValue ()> = 5 then
hudPrint ("I should find a rock")
end
end

Once the key taken in the alcove, the solution to the puzzle is solved, so I do: When alcove_key deactivate -> reset -> puzzle_1

The problem was that if I press again 5 times the plate, the phrase will again trigger. Hence the idea of the timer to not have to change my scripts.
When alcove_key deactivate -> timer_puzzle_1 -> activate
When timer_puzzle_1 activate -> reset -> puzzle_1 (0.1 seconds)

This is the easier way to reset the counter when the puzzle is solved. Otherwise, I must change all my scripts

[alois]

puzzlealpha function ()
if puzzle_1: getValue ()> = 5 then
hudPrint ("I should find a rock")
end
end

Once the key taken in the alcove, the solution to the puzzle is solved, so I do: When alcove_key deactivate -> reset -> puzzle_1

The problem was that if I press again 5 times the plate, the phrase will again trigger. Hence the idea of the timer to not have to change my scripts.
When alcove_key deactivate -> timer_puzzle_1 -> activate
When timer_puzzle_1 activate -> reset -> puzzle_1 (0.1 seconds)

This is the easier way to reset the counter when the puzzle is solved. Otherwise, I must change all my scripts

Why don't you change the >= to == in the line "puzzle_1: getValue ()> = 5" and do not reset the puzzle counter?

In this way the sentence is printed once (and only once) - the price you pay is that the counter will count up to infinity (if you continue to step up-step down the plate! ):)

alois

[Damonya]

I know but I think it is better if the player can see the message more often, as it can't find the solution. Only one hudprint is very short. I took a hypothetical example here, but of course my puzzles are a little more complex and messages are more sophisticated. I also put a system for disabled/enabled at will this type of assistance (with grimwidget onUsed item), so no problem with troublesome message to infinity. But the best way would be to write sentences in a book. Maybe in a future version of the mod ^ ^

EDIT:
Finally I want to take any risks with the performance of the timers, so I replaced the timer with a counter and adds an additional requirement to all my scripts. You are never so prudent with ingame performance.

[msyblade]

If you go with the pressure plate to deactivate the timer upon level exit, make sure to build another plate just before, that activates them all, so a player re-entering will trigger the activate plate last, and when exiting will trigger the kill pad last.

[petri]

I'm sure it will eventually slow down performance but I don't know how much. I think a larger concern which may or may not effect your mod is the timers will slow down the further you get away from them in levels.

For example on level 1 a timer set to 1 second will tick every second as long as the party is on level 1. When the party moves to level 2 the timers on level 1 will tick slower, maybe every 2 seconds. If the party goes to level three the timers on level 1 will only tick every 3 seconds etc, so forth and so on. I don't know if the time loss numbers I used are correct, but I do know for a fact the effect is true.

This is a common misconception. Timers don't run slower per se, it is time that runs slower in faraway levels. This affects everything: projectiles, monsters, animations, timers... So everything in a slowed down level works consistently. This is only a problem if you assume that all levels run at the same pace, e.g. when a timer triggers an entity on another level.