Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

world:getTime returns the wrong value #93

Open
brightrim opened this issue Oct 25, 2022 · 5 comments
Open

world:getTime returns the wrong value #93

brightrim opened this issue Oct 25, 2022 · 5 comments
Labels

Comments

@brightrim
Copy link
Member

world:getTime() has suddenly started returning negative values

Discovered via this recent report.

I looked into it and found via a log(world:getTime("day") where it returned -4 (which matches the current login message of -4th of Mas) that it is the server function itself that is returning faulty values all of a sudden.

@brightrim
Copy link
Member Author

I tested with "unix" which seems to be working fine, returning 1666721659.

"month" returns 16, as in Mas, even though it should return 2, as in Tanos.

Not sure if this breaks any scripts. Could potentially be urgent, as searches for world:getTime("day") and world:getTime("month") provide a lot of results, though most scripts appear to be using the still working world:getTime("unix") for timestamp purposes.

@brightrim
Copy link
Member Author

So far the following scripts have shown up in the script error log as having been broken due to this:
oldSlimeFeeding - seems to affect the text meant to be shown on a sign
herbgathering - seems to affect the regrowth of plants as next_regrow_ itemData is not set as it can not figure out what season it is

@estralis
Copy link
Member

Hrm, it isn't even 2038 yet...

A quick fix could be to move the time logics to a script function and see if the error can be reproduced. But of course, a proper fix of the server function is preferred.

Any hint on the root cause?

@estralis
Copy link
Member

estralis commented Nov 8, 2022

Root cause is likely in this line:

auto illaTime = (int)curr_unixtime;

Using int here results in a variable overflow later on. Illarion time passes 3x as fast, so as Illarion time started in RL year 2000, we accumulated more than seconds of game life than can be stored in an int variable.

A solution would be to change the variable type to long or long long - given this does not break stuff further down the line

@brightrim brightrim added the bug label Nov 19, 2022
@estralis
Copy link
Member

This needs to be reverted once the time function works properly again:

Illarion-eV/Illarion-Java@1c13ef4

estralis added a commit to estralis/Illarion-Server that referenced this issue Mar 5, 2023
@estralis estralis linked a pull request Mar 6, 2023 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants