tickrepeats property assertions misrepresent functionality

update property sets by adding global_vars.tick_count as reference for realtime calls.

[Ayuto]

Sorry, I don't quite understand what you mean. Could you please elaborate this a little bit more?

at least the following attributes mention time, but seem to return time only as fixed intervals, rather than absolute time as count only gets called once every loop, if i read the code correctly? (didnt test it)

@property
def timeleft(self):
    """Return the remaining time till the end of the repeat.""" -> same issues as above. will probably return only the time from next loop start to end of tickrepeat. its useless, if you need realtime values..

@property
def elapsed(self):
    """Return the elapsed time since the repeat started.""" -> same issues as above. time calculates in intervals, not in realtime.

@property
def total_time(self):
    """Return the total time it will take to complete the repeat.""" > same issues as above. time calculates in intervals, not in realtime.

adding a fixed local value of global_vars.tick_count could make use of realtime calls to get accurate time properties.
this could be done by adding two local values to the attribute system:

self._start_tick_loop = global_vars.tick_count # set every loop start
self._start_tick_repeat = global_vars.tick_count # set once when repeat starts

additionally properties can now be added/changed to something like this: ( taking respective servertick into account )
personally i would prefer a two way system:

1. loop properties
2. tickrepeat properties

one possiblity would be to add a subproperty like this:
.timeleft -> returns timeleft for repeat
.elapsed -> returns elapsed time for repeat
.loop.timeleft -> return timeleft for current loop
.loop.elapsed -> return time elapsed in current loop

these other, already existing, properties are useful and can stay too:
.loop.count -> already made loops, function for this already works i think
.loop.remaining -> remaining loops, function for this already works i think
.limit -> maximum loops, function for this already works i think

@property
def loop_timeleft(self):
    """Return time as ticks left for current loop."""
    if not self._interval:
        return float("inf")

    return ((self._interval * 1/global_vars.interval_per_tick) - (global_vars.tick_count - self._start_tick_loop)) / (1/global_vars.interval_per_tick)
@property
def loop_time_elapsed(self):
    """Return time as ticks for elapsed time in current loop."""
    if not self._interval:
        return float("inf")

    return self._interval - ((self._interval * 1/global_vars.interval_per_tick) - (global_vars.tick_count - self._start_tick_loop)) / (1/global_vars.interval_per_tick)
@property
def timeleft(self):
    """Return time as ticks left for entire repeat."""
    if not self._interval:
        return float("inf")

    return ((self.limit * self._interval * 1/global_vars.interval_per_tick) - (global_vars.tick_count - self._start_tick_repeat)) / (1/global_vars.interval_per_tick)
@property
def time_elapsed(self):
    """Return time as ticks for elapsed time in entire repeat."""
    if self.limit == 0:
        return float("inf")

    return self.limit * self._interval - ((self.limit * self._interval * 1/global_vars.interval_per_tick) - (global_vars.tick_count - self._start_tick_repeat)) / (1/global_vars.interval_per_tick)

( didnt test the math, might need rework)

for the record i have renamed the properties this way, hopefully this will help and give some more clarity:

.timeleft -> returns timeleft for repeat
.timeelapsed -> returns elapsed time for repeat
.loops_limit -> maximum loops, function for this already works i think
.loops_finished -> already made loops, function for this already works i think
.loops_remaining -> remaining loops, function for this already works i think

.current_loop.timeleft -> return timeleft for current loop
.current_loop.timeelapsed -> return time elapsed in current loop

[Ayuto]

Sorry for the late reply. I still had no chance to really take a look at this.

What exactly is the problem with absolute time? Moreover, the whole delay implementation is based on time.time(), so the repeat implementation shouldn't use tick counts as well.

you may have misunderstood my concern. im not trying to change time.time() to global_vars.tick_count. ( i only assumed time measurements were using "global_vars.tick_count")

instead, im trying to have additional time properties for the single loops, that are made within a tickrepeat.
if a tickrepeat executes 10 loops, i want to get property of 1) timeleft, when the current, single loop exactly ends ( by some time reference, time.time() or tick, both work) and 2) time elapsed, how long this current loop is already running ( in terms of time )

this is actually an enhancement, not really a bug or anything. everything else should be understood from my previous posts. the current problem: the method of timeleft is using intervals, and only returns those, if im correct.

[satoon101]

I think the best idea would be to add a current_delay property on the TickRepeat object that will give access to the current Delay object used for the loop. Then, add a time_remaining property to the Delay class to allow retrieving the number of seconds remaining in the delay. Delays/Repeats are mostly set it and forget it structures until they execute after the delay or each loop of the repeat. But, I can certainly see times in which it might be beneficial to have access to that sort of information.

Or, actually, instead of giving overall access to the Delay for the repeat, we could add a property that returns the Delay.time_remaining value of the current delay. I'm not sure what to call that, but that would probably be a better idea. We could do the same for the time elapsed in the current loop. I wouldn't make them 'sub-properties' unless we are exposing the Delay itself as public.

yeah true. in my own tick.py i simply added a line right where the delay (re)starts, as a local reference. lets call the var stupidly: "global_starttime_of_current_delay = time.time()".
and via properties on the bottom, i could now call:

time.time() - "global_starttime_of_current_delay"

only that i did it via

global_vars.tick_count() - "global_starttime_of_current_delay"

btw, i think global_vars.tick_count() will return slightly off values, if it gets called outside of the "ontick" wrapper. so using global_vars.tick_count() as time reference might have been a bad idea here anyway.

to conclude: if someone adds these little timeleft,timeelapsed properties for the current_delay/current_loop , it will probably do it for me. i cant remember, but i felt like some of the properties in tick.py were a bit "useless", in terms of functionality, someone else could take a look at it

one other problem i encountered was this:
the code looked like the actual "tickrepeat" would only start after one interval time has passed, as .start() always calls the same delay? shouldnt the first Delay run with 0 time, Delay(0,function,args) ?

in this pattern : tickrepeat(3,3)
right now is doing this -> (0,wait) (3,loop),(6,loop),(9,loop)
and should become -> (0,loop),(3,loop),(6,loop)

if i misread the code discard this post please

[satoon101]

If you want your function to execute immediately, you should just call the function:

my_function(*args, **kwargs)
my_repeat = TickRepeat(my_function, *args, **kwargs)
my_repeat.start(3, 3)

This means that every 3 seconds your function will be called, and the repeat only happens 3 times. So, in total, because you called your function directly, the function is called 4 times. Perhaps we could add a keyword-only argument for executing immediately. But, if we did that, it would not use a 0 loop, as that waits 1 tick. It would just execute it immediately. But, the other functionality would remain the same, as in, it would still loop a total of 3 times, thereby executing the function a total of 4 times. I'm not saying that we are going to add that, just that it is a possible feature we could consider adding.

or in adding the keyword-only argument, you could also substract -1 from totalcount. ( to avoid looping 4 times )
my idea wouldnt hurt the performance, itll just modulate the way the tickrepeat works. right now it feels more like a delayed "delayrepeat", you know? tickrepeat by its name should start at tick (immediately), not delayed.

simply do sthn this: add a self.execute when the .start() function is called and change the totalloop count for the delayloop to -= 1.

sthn like this, but this is only my take for convenience, maybe you prefer the way it is working now. i only wanted to open this for discussion

[satoon101]

I definitely prefer the way it is now. I have used Repeat a lot since the EventScripts days. I even worked with XE_ManUp on the updated version that we used with GunGame51, which was never included in ES. The SP version is really a modified version of that repeat.

There are a few times in which I have wanted the function to be executed immediately and then also every loop of the repeat. But, primarily, I have only wanted to start executing on the first loop. I don't think we should count the initial execution as part of the loop count. If you want it to run 3 times instead of 4, just change your limit to 2. I don't think we should subtract just cause the plugin author wants the delay to execute prior to the first loop. To me, that would not be consistent.

The reason it is call TickRepeat is because the repeats use ticks and not threading to delay. In the early days of SP, a threading delay class was considered instead of using ticks because the ticks weren't executing when the server was hibernating. We quickly found that the same held true for threading, so the idea was abandoned, but the name for TickRepeat remained. The Delay class was once handled as listeners.tick.tick_delays.delay until we moved over to using the Delay class itself. I'm not sure why we didn't choose TickDelay instead of Delay, but we should probably change one or the other now to match the naming scheme.

well thats the point. my perspective comes from an outsider and tends to be less biased. ive never used any of the things youve mentioned, that you used and thus im not restricted to personal experience and preference, like you are.
i would simply call the current tickrepeat -> "DelayRepeat", as i have already suggested before, as the alternative to changing the class in my described manner. i think you should go one way or the other, but thats just my 2 cents

[satoon101]

I just pushed some changes to a different branch for testing. Let us know if you have any issues with it or any more suggestions.