Closed FeldrinH closed 3 years ago
It's obvious that a singleton with process() could solve that easily. It's ok if the engine can provide it already, and it will be fine for 95% of games. But the pause mode makes it a bit more difficult than it sounds because it implies that the nodes being pausable are always the same ones. Not to mention requests for slow-mo :p https://github.com/godotengine/godot/issues/6885
For buffs I would use a Timer anyways because storing time as before+after is 1) programmatic way (as in more boilerplate), 2) wrong anyways because of what you said about pause 3) Is covered already by... Timer.
Or fixed frame counter, I can see it useful for syncing. Then if want to pause, the pause method can register frame number of pause and un-pause if needed.
You could just use OS.get_ticks_msec() and a couple of variables in a "Pause" singleton for that.
@RodeoMcCabe That's more complex than what @Zylann proposed, compare:
# Singleton that increments time
var time = 0
func _ready():
set_process(true)
func _process(delta):
time += delta
# Singleton that works with get_ticks_msec
var paused_time = 0
func _ready():
set_process(true)
func _process(delta):
if get_tree().is_paused():
paused_time += delta
func get_time():
return OS.get_ticks_msec() / 1000.0 - paused_time
Just call get_process_time() and get_process_fixed_time()
On Apr 24, 2017 3:52 PM, "Bojidar Marinov" notifications@github.com wrote:
@RodeoMcCabe https://github.com/RodeoMcCabe That's more complex than what @Zylann https://github.com/Zylann proposed, compare:
Singleton that increments timevar time = 0func _ready():
set_process(true)func _process(delta): time += delta
Singleton that works with get_ticks_msecvar paused_time = 0func _ready():
set_process(true)func _process(delta): if get_tree().is_paused(): paused_time += deltafunc get_time(): return OS.get_ticks_msec() / 1000.0 - paused_time
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/godotengine/godot/issues/6999#issuecomment-296675101, or mute the thread https://github.com/notifications/unsubscribe-auth/AF-Z28hTpw-pAxWoAn0299NYi6yV4MGFks5rzKkygaJpZM4KlWaC .
@reduz This issue asks for people to be able to use some function to get cumulative process/fixed_process time, and not delta time. So, just like you add up all _fixed_process
deltas so far.
(PS. They are actually called get_process_delta_time
and get_process_fixed_delta_time
)
@bojidar-bg Sorry, I was responding to @eon-s. Something like this (actually you don't need get_ticks_msec):
# Singleton with pause mode set to process (so this singleton is never paused)
var paused_frame = 0
var unpaused_frame = 0
var total_frames = 0
var run_time = 0
func _ready():
set_process(true)
func _process(delta):
total_frames += 1
if not get_tree().is_paused():
run_time += delta
func pause():
get_tree().set_paused(true) # can't remember exactly how to pause the tree
paused_frame = total_frames
func unpause():
get_tree().set_paused(false)
unpaused_frame = total frames
I could use this for my solar system simulator. All positions & velocities are calculated based on cumulative time (not delta) together with the body's Keplerian orbital elements. Currently, we have GDScript access to Engine.time_scale
, but that doesn't do me much good when I need to maintain my own cumulative time anyway. It would seem sensible to be able to access (and maybe even change) Engine.cumulative_time
. Or for brevity, call it Engine.game_time
.
Hi, I would like to work on this, So basically what is needed is to have 2 new functions in Node which gets the cumulative time as opposed to the existing idle process/physics time, and will get affected by the current Node's pause mode. Also, I would add 2 more functions in the scene tree that would allow getting the total processing/physics time regardless of the pause state of the root node. Is my understanding correct?
Reopening as reverted by https://github.com/godotengine/godot/pull/51979
Shouldn't this just be closed? @reduz already rejected the feature, and I agree with him - it's very easy to just do this in a script.
Apart of syncing this may be probably useful for some deterministic systems (some core ones), but is a (very old) feature request and will need a proper proposal with use cases now, I guess...
Closing per @aaronfranke's comment.
Would it be possible to add functions that return "processing" time and "fixed processing" time, which would return the value you would get (in principle, ignoring precision issues) if you added processing or fixed processing deltas to some accumulator every frame. A sort of "engine" time, affected by things like pausing, as opposed to "real" time.
This would be useful for instance to keep track of cooldowns without active processing, by simply storing the time the cooldown would end in a variable and then comparing that to the current processing time.
I would guess the engine keeps track of it anyway, so it shouldn't be too hard to simply expose it to GDScript.