![]() |
Stumped by my own code (ratio & epoch-time calculation). - Printable Version +- Python Forum (https://python-forum.io) +-- Forum: Python Coding (https://python-forum.io/forum-7.html) +--- Forum: General Coding Help (https://python-forum.io/forum-8.html) +--- Thread: Stumped by my own code (ratio & epoch-time calculation). (/thread-31723.html) |
Stumped by my own code (ratio & epoch-time calculation). - MvGulik - Dec-29-2020 How to explain this ... In a nutshell. I have done something weird in my code/calculations. And now, a few days later, I can't figure out why its actually working as expected. (blocking me from adding other stuff). Target purpose of the code: It calculate a game related date+time. Where the game clock is running 3.29 times faster compared to real time clocks. Other than having different length for years and months, its day clock is the same as normal clocks (just 3.29 times faster). The problem I'm running into is that I can't figure out why the current ratio usage is actually working.Its only used ones, in the otherwise static variable one_year_rsec .And although the tick function start of with a real-time related epoch, it end up running at game speed after one_year_rsec is used.What em I not seeing ? (I probably should put it aside for the moment, to give that last part an alternative try ... after a good night sleep) (Generally minimalize'd code, except for my own troubleshooting remarks) #! /usr/bin/python3 ## (Python 3.8.5) import time import math def main(): print('>> main()') ##[debug]## ## date-time speed between game-clock and real time clock. (game = real*ratio) ratio = 3.29 ## epoch point in real-time where the game clock started (game-epoch zero) target_epoch_rsec = 1582415683.8844986 target_epoch_rsec -= -(60*34 / ratio) ## some correction in game clock time. print('--- '+'target_epoch_rsec', target_epoch_rsec) ##[debug]## ## setup some time/clock related stuff. season_days = [30, 105, 30, 15] game_year_days = sum(season_days) seconds = 60 minutes = 60 hours = 24 ## pre-calculate some fixed value, used in time-loop. (game year in real seconds). one_year_rsec = (game_year_days / ratio) * hours * minutes * seconds print('--- '+'one_year_rsec', one_year_rsec) ##[debug]## def tick(): print() ##[debug]## real_epoch = time.time() ## real time epoch. print('--- '+'real_epoch', real_epoch) ##[debug]## offset_rsec = real_epoch - target_epoch_rsec ## subtrackt fixed real time epoch point. print('--- '+'offset_rsec', offset_rsec) ##[debug]## modf, year = math.modf(offset_rsec / one_year_rsec) ## divide by game-year lenght, in real seconds. print('--- '+'modf(secs)', modf * game_year_days * hours * minutes * seconds) ##[debug]## ## !!! here the time is apparently returning in jumps of 3 seconds, ergo: its game-time related at this point. ## Ratio was (only) used in the "one_year_rsec" var, but can't figure out why it would be working correctly with that. for i in range(3): tick() time.sleep(1) print('<< main()') ##[debug]## ## START MAIN ## if (__name__ == '__main__'): print() main()
RE: Stumped by my own code (ratio & epoch-time calculation). - jjc385 - Dec-29-2020 First you calculate how many real seconds are in a game year, and then you use this value to calculate how many game years have passed. (real seconds elapsed) / (real seconds per game year) = (# game years elapsed) Imagine instead you were calculating how many weeks have elapsed. You would take the number of days and divide by the number of days in one week. This is basically the same thing, just with the less familiar time-unit of game seconds. RE: Stumped by my own code (ratio & epoch-time calculation). - MvGulik - Dec-30-2020 After reading that, and a bit of thinking (with some math chalking on a blackboard help) I now realize why it works. (real seconds elapsed) / (real seconds per game year) = int(number of full game-years) + fraction(of rest of current game-year) Its that last fraction part that make it work. But I had not realized it was turned into a game-year fraction. I initially started with a somewhat different approach, which probably got in the way of seeing this. Thanks for putting me back on track. |