About checking the current tick

[Thralni]

Hey all,

 

I've been a little confused about the passage of time in BoA. Ina  thread in the forum, Ephesos posted the following schedule for the passage of time:

0 - Dawn

250 - Full Light

3750 - Dusk

4000 - Night

4250 - Twilight

4750 - Daybreak

 

But, then the manual says:

There are 5000 ticks in a day. The first eighth and last eighth of every 5000 tick period are nighttime.

...which suggested that ticks 625 through 4375 are day, the rest is night, which is different form what Ephesos posted

 

And further:

short get_current_tick() - Gets the number of ticks (i.e. turns/combat rounds) that have elapsed since the scenario began. This will be a number from 0 to 29999, and wraps around to 0 when past 29999. 

 

So here's my question: how does all this really work, and how can I reliably check for whether it's day or night? I'm attempting for a mission to only start if it's night, but if the amount of ticks can go beyond 5000, and it's unclear when the night starts and ends, I'm a little stuck. Any suggestion would be much appreciated!

[keira]

wouldn't that be as easy as (roughly) time_of_day = get_current_tick() % 5000 ?

 

i'd imagine, if you need get_current_tick() for ticks beyond 30k, you could probably just have a script run periodically to check if the tick count is less than it was last time you checked (ie it overflowed?) and increment a global or SDF or whatever.

 

then you can basically just do (times overflowed*30000)+get_current_tick() to get a better tick value as well, i suppose?

Edited July 23, 2017 by sylae
as far as the times of the day things happen, it might be a good idea to just do the avernumscript equivilent of var_dump(get_current_tick()) every tick or so and see what lines up

[Kelandon]

Yeah, I'm not sure that anyone who knows will respond, so you should probably just test this yourself. Create a testing scenario (on the surface), put something like

print_num(get_current_tick());

into the START_STATE in the scenario script, and walk around for a while to see what happens. I wouldn't be at all surprised if Eph was right and the manual was wrong, but it would be good to check to be sure.

 

Let us know what you find out!

[nikki.]

I used day/night cycles in TV, so I went back and looked at my code. There's a bit more going on in the script (twilight.txt if you wanted to take a look), but here's the stuff that should let you track whether it's day or night. Setting a flag lets you track it scenario-wide, of course. 

 

ticks = (get_current_tick() % 5000);   

if((ticks > 3750) || (ticks < 250)) {  
	//time = night    
  	set_flag(250,0,1);     
} else {  
  	//time = day            
  	set_flag(250,0,0);  
}

 

I remember starting the day at 250 because that's when it's fully light, I guess that makes Ephesos right.

[Thralni]

Hey all, thanks for the replies!

 

So, "%" is what I needed... I knew from the start there was a simple, one-symbol way of doing this, but I've forgotten so much of my BoA scripting days (and some of the maths involved) that I couldn't for the life of me remember.

 

Nikki, that code looks awesome! I'll repurpose it a little bit for use in my scenario, but otherwise it's perfect.

 

Kelandon, I might just re-test this, as you suggest, to make sure, though it looks like if Nik's code works fine we should have the answer

 

Thanks again all!

 

 

One more question. I've implemented the code, but was wondering about something. the call "tick_difference" allows to find the difference between two time points, and the manual specifies that there is an order in which you have to supply the call the two time points, namely the earliest first, and then the later one. Does that mean that, if you give, say, tick_difference(3000,1000), it will return 4000? In other words, is it going to wrap around the day? I can test this myself of course, but given my lack of time currently, if anybody has an off-hand answer, that'd be much appreciated!

Edited July 23, 2017 by Thralni

[Celtic Minstrel]

14 hours ago, sylae said:

i'd imagine, if you need get_current_tick() for ticks beyond 30k, you could probably just have a script run periodically to check if the tick count is less than it was last time you checked (ie it overflowed?) and increment a global or SDF or whatever.

 

then you can basically just do (times overflowed*30000)+get_current_tick() to get a better tick value as well, i suppose?

 

I wonder if you can really rely on something like this. I wouldn't be that surprised if it turns out that numbers in AvernumScript are 16-bit signed integers, which would mean that 2*30000 overflows. Is it known or documented what the size of AS integers is?

[Kelandon]

As far as storage, the problem is that variables are sometimes (always?) reset when you reload from a save. So you really would have to store it in an SDF, not a scenario script variable.

 

As far as doing math, yes, the docs say:

Quote

Numbers in scripts can have values from -32767 to 32768. If your numbers go out of those ranges, strange things will happen. That is just how computers store numbers.

So you would have to be a bit careful doing math with numbers well over 30,000. You can still do it, but it requires some convolution.

 

But I don't think any of this is relevant to what Thralni is trying to do, really. Nik's script should work well enough.