Ren'Py Resetting variables based on variable value issue

[CrimsonAxisStudio]

Working on a HUD display that changes the display of time based on a variable.

What I'm trying to do is use a variable that is basically hours, and once it gets to a certain point, it resets to 0, which i'll use to determine various scenes.

default dt = 0



# The game starts here.

label start:

    jump whatever1



label whatever1:
    show screen daytimeinfo

    $ dt += 1

    "Test"

    jump whatever2



label whatever2:
    show screen daytimeinfo

    $ dt += 1

    "label 2"

    jump whatever1







screen daytimeinfo:
    zorder 10
    if dt > 12:
        $ dt = 0


    text "Day [dt]" xpos 0.02 ypos 0.01


return

The DT variable just keeps ticking up, and never ends up resetting.

I've also tried..

default maxdt = 24

#samelabelsasabove

screen daytimeinfo:
    zorder 10
    if dt > maxdt:
        $ dt = 0

    text "Day [dt]" xpos 0.02 ypos 0.01

That doesn't seem to work either.

Anyone able to identify what I'm doing wrong?

Thanks!

 

[the66]

with

screen daytimeinfo:
    zorder 10
    if dt > maxdt:
        $ dt = 0

    text "Day [dt]" xpos 0.02 ypos 0.01

you simply set the screen variable dt to 0 if the global variable dt is bigger than maxdt.
and until the screen variable dt is created by your code, the global var dt is displayed and later the screen variable.
either use $ store.dt = 0 or perform this check outside of a screen.
and you have to show your screen only once outside of your "loop". it remains displayed until you hide it.

 

[79flavors]

You might also want to consider:

    $ dt = dt % 12

Which uses modulo to keep everything within the range of 0 to 11.

Modulus is the remainder after dividing one number by another.
7 % 12 = 7 / 12 = 0 reminder 7 ... Answer = 7
12 % 12 = 12 / 12 = 1 reminder 0 ... Answer = 0

What it doesn't do is advance any other numbers, which you might expect when dealing with time (like reaching midnight and advancing the day + 1).

What modulo is good at though is when you want to add a specific number of hours, rather than simply 1. It's really good for things like +6hrs or +4hrs, when you're dealing with morning, afternoon, evening, night style environments.

 

[CrimsonAxisStudio]

Thanks a lot. Threw it into a label for change time and it seemed to fix the issue.

I'll keep the module in mind for later. I plan to use this time variable for other things also.

 

[anne O'nymous]

default maxdt = 24
[...]
    if dt > maxdt:
        $ dt = 0
[...]

The store part being already addressed, there's another problem with your code. Like this, the value of dt will goes from 0 to 24, which imply 25 hours by day.
Either you assign 23 to maxdt, use if dt >= maxdt, or use 1 as minimal value for dt.

You might also want to consider:

    $ dt = dt % 12

It works, and the hours don't goes further than expected, but there's still a flaw : The hours will goes from 0 to 11, instead of 1 to 12.
Internally it's not a problem, but the display need to be updated :

default maxdt = 24

screen daytimeinfo():
    zorder 10
    $ store.dt = store.dt % maxdt

    # The increment apply only for the display, the value
    # of /dt/ stay unchanged.
    text "Day %d" % (dt + 1 ) xpos 0.02 ypos 0.01

This said, there's also a solution that don't need to rely on the screen to limit and reset the value of dt.

It's to use dt = ( dt + 1) % maxdt in place of the basic $ dt += 1.
It will increment dt, then limit it at maxdt, and finally assign the result as new value for dt.

if dt = 0, then dt will be 1 % 24 = 1
if dt = 1, then dt will be 2 % 24 = 2
[...]
if dt = n, then dt will be n+1 % 24 = n+1
[...]
if dt = 22, then dt will be 23 % 24 = 23
if dt = 23, then dt will be 24 % 24 = 0

 

[79flavors]

    $ dt = dt % 12

It works, and the hours don't goes further than expected, but there's still a flaw : The hours will goes from 0 to 11, instead of 1 to 12.

Yeah. It was bugging me as I typed it - but since the original example included if dt > 12:, my brain decided that using the existing number was better than the alarm bells telling me to rethink it.
I'm not being defensive here, just explaining my thinking so the OP understands the sort of mental processes that you go through when thinking about code like this.

In hindsight, I was thinking about a twenty-four hour clock using $ dt = dt % 24 - with the time going from 0:00 to 23:59. I got carried away explaining modulus.

As I say, it's only part of a solution anyway. Since a dev would still need to check for if dt > 23 before doing anything else anyway in order to advance the date along with the time... Unless... hmm...

init python:

    def advance_time(adv_hr):

        store.day_count = store.day_count + int((store.hour_count + adv_hr) / 24)
        store.hour_count = (store.hour_count + adv_hr) % 24
        store.day_name = days[store.day_count % 7]

        return

default day_count = 1
default hour_count = 8
default day_name = "Sunday"

define days = ["Saturday", "Sunday", "Monday", "Tuesday", "Wednesday", "Thursday", "Friday"]

label start:

    scene black with fade
    "Start:.... "

    "01: Hi. Today is [day_name] and it is [hour_count]:00."

    $ advance_time (1)
    "02: [day_name] and it is [hour_count]:00."

    $ advance_time (4)
    "03: [day_name] and it is [hour_count]:00."

    $ advance_time (8)
    "04: [day_name] and it is [hour_count]:00."

    $ advance_time (12)
    "05: [day_name] and it is [hour_count]:00."

    $ advance_time (24)
    "06: [day_name] and it is [hour_count]:00."

    $ advance_time (53)
    "06: [day_name] and it is [hour_count]:00."

    "*** THE END ***"
    return

Since the integer (int():) of the current hour plus additional hours divided by 24 would advance the correct number of days and the modulus would sort out the rest... that could be the starting point for a day/time tracker... Even when adding a really oddball number of hours like 53.

I'm prefixing stuff with store. to remove any doubt whether the function should be using the local level variable or the global one. (Local variables only existing within the function, global ones exist everywhere and are the norm for RenPy scripts).

It would need some additional work to get things working with a 12hr clock instead of a 24hr clock. Also you'd need some additional logic to add day_count to a real calendar in order to get dates like "May 16, 2019", etc. Maybe even some localization functions to display the date according to the country the game is being played in (US=MM/DD/YYYY, Europe/etc=DD/MM/YYYY, China/etc = YYYY/MM/DD). All of which is getting way out of hand compared with the original question.

So... *cough*, yeah... modulus is your friend when dealing with moving dates and times forward.

 

[anne O'nymous]

I'm not being defensive here, just explaining my thinking so the OP understands the sort of mental processes that you go through when thinking about code like this.

Don't worry, if I wasn't the last one to answer I would probably also have missed this.

As I say, it's only part of a solution anyway. Since a dev would still need to check for if dt > 23 before doing anything else anyway in order to advance the date along with the time... Unless... hmm...

init python:

    def advance_time(adv_hr):

        store.day_count = store.day_count + int((store.hour_count + adv_hr) / 24)
        store.hour_count = (store.hour_count + adv_hr) % 24
        store.day_name = days[store.day_count % 7]

        return

Setting a default value in the function header (def advance_time(adv_hr=1):) would be good improvement, since generally the increment will be of one hour.

    $ advance_time (53)

I don't recommend this. Not only the risk to have messed the computation of the hours is high, but it can also totally break the coherence of the story since you don't have the control of the moment when the game will restart after this break.

Lets say that the MC goes on a date with a girl, then decide to pass the week-end with her. If you go with a ( 24 * 2 ) + 13 = 61 advance, assuming that the MC will goes on the date at 19h, it will make the game restart the Monday morning at 8h.
But what if the player decided to goes on the date at 16h or at 23h ? The game will restart at 5h or 12h. The first one would let 3 hours where the player have nothing to do (and can possibly mess with everything if you have a tiredness value), while the second will make him miss all the morning.

In place, if you need an advance of more than 24 hours, it's better to force the date and hour :

    $ hour_count = 8
    $ day_count += 3 # Friday + Saturday + Sunday

Maybe even some localization functions to display the date according to the country the game is being played in (US=MM/DD/YYYY, Europe/etc=DD/MM/YYYY, China/etc = YYYY/MM/DD).

This is something rarely addressed, but a real problem. While the Asian format is obvious to notice, I don't count the number of games where I need to reach the 13th day before knowing if the date is in US or European format.

The easiest way to solve this problem is to display the month in letters. Then, whatever if it's wrote Jun 02 2020 or 02 Jun 2020, there will be no place for confusion.
And doing it is just a variation of the code you used for the day

define monthsByName = ["Jan", "Feb", "Mar", "Apr", "May", "Jun", "Jul", "Aug", "Sep", "Oct", "Nov", "Dec" ]
[...]
      $ month_name = monthsByName[month-1]
# or
      $ month_name = monthsByName[month % 12]

 

[79flavors]

+53... Yeah. I was only proving it was possible... not necessarily a good idea

The last time I wrote example code like this, I included a flag to impose limits on what happened when you went forward a day, whether to advance the requested amount of time, or force the day to start at a more reasonable time (8am for example).
But it seemed so far off topic from the original post... I figured I'd just push the code a little beyond what was asked, but stop before things went too off on a tangent.

As for the default value... it was there in my original incarnation of it - then I got a dumb error and removed it temporarily.