search

ArVdC / TimeManager

Bukkit plugin for time management and display
https://dev.bukkit.org/projects/mc-timemanager/files
Eclipse Public License 1.0
7 stars 3 forks source link

Speed issue: 1.6.1 update #17

Closed mrcoffee1026 closed 1 year ago

mrcoffee1026 commented 2 years ago

Seems to have worse functionality after this update than after. As far as I can tell, daycycles are lasting about half as long as they should (10 minutes for day+night when setting speed of day and night both to 1.0). However, no amount of adjusting to the speed value can restore vanilla behavior: while setting both speeds to 0.5 should restore vanilla behavior, it does not. In fact, the closest I was able to come to vanilla was to set both day and night speed to 0.0002. Any setting smaller than that actually resulted in a shorter day/night. The longest combination of the two I was able to accomplish was 19 minutes which is still a minute shorter than it's supposed to be. Since 0.0001 results in a longer day+night than 0.0002, there appears to be a lingering bug in the math in regards to how speed is handled, but using 4 place decimal to achieve vanilla speed shouldn't be necessary either.

mrcoffee1026 commented 2 years ago

My best guess is that instead of doing something like current_day_speed * set_multiplier = resulting_day_speed It's doing something like current_day_speed(current_day_speed + set_multiplier) = resulting_day_speed So regardless of set option, it's always running faster than a normal day unless both values are 0 since 0 stops the time entirely. Seems to function fine when running on windows, fails as described above on Ubuntu.

World with speed 0.1 set for day and night: about 18:10 minutes in length (instead of expected 20:00). (set to 0.1 since all other values resulted in days much shorter than 20:00 which was the expected and desired length for a speed of 1.0).

mrcoffee1026 commented 2 years ago

Side issue: on server restarts, Config file preserves only the default three worlds and clears all additional worlds from the config file. Changes must be placed and plugin reloaded after each restart.

ArVdC commented 2 years ago

I have never tried with Ubuntu before, I will see if it creates the same malfunction as you describe. Give me time to do some testing. By the way, did you enable the 'sync' option or not?

mrcoffee1026 commented 2 years ago

sync option no, just the sleep sync.. pretty much every world like this:

  world:
    start: 1000
    daySpeed: 1.0
    nightSpeed: 1.0
    sleep: linked
    sync: 'false'

Also, I'll need to test some more but there's a CHANCE that the worlds are saved if a language is chosen for default in lang.yml. Also: I'm using 0.1 as the speed setting for day and night since doc said 'choose a number between .1-.9 for slower than normal' or something to that effect, there may be some cutoff on the decimal I'm not aware of since it got pretty sketchy trying stuff like 0.00002 for a speed and not really gaining much time out of it. And yeah, don't know why it would handle differently in Linux but I couldn't duplicate this issue on my local windows copy of the server.

ArVdC commented 2 years ago
mrcoffee1026 commented 2 years ago

If an yml file resets, it's probably due to a special character that isn't recognized or any syntax error. : no -- reverted to original file, copied worlds exactly to add new ones. NAMES ONLY changed, no special characters, nothing accepted. : Vanilla 1.0 day / night speed are exactly 20 minutes for the full cycle: 10 minutes for day, 10 minutes for night. Anything under that is not normal (hence why setting speed to 0.1 day and 0.1 night and totalling 18 minutes for both is severely abnormal). Lag sure... but would only affect it by seconds one way or another... and make the days and nights even longer, not shorter, this is clearly internal math error. (reference: https://minecraft.fandom.com/wiki/Daylight_cycle#:~:text=Currently%2C%20each%20cycle%20lasts%20about,night%20each%20lasting%207.5%20minutes.&text=Daylight%20cycle%20now%20lasts%2020%20minutes.) Windows: java version "17.0.1" 2021-10-19 LTS Java(TM) SE Runtime Environment (build 17.0.1+12-LTS-39) Java HotSpot(TM) 64-Bit Server VM (build 17.0.1+12-LTS-39, mixed mode, sharing) Ubuntu: openjdk version "17.0.3" 2022-04-19 OpenJDK Runtime Environment (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1) OpenJDK 64-Bit Server VM (build 17.0.3+7-Ubuntu-0ubuntu0.20.04.1, mixed mode, sharing)

Ubuntu is even more updated than windows in this case, it's NOT Java.

Also found that absolutely NO value is accepted for "defaultLang" field in the lang.yml file. Tried "en_US" (clearly what the file is expecting) with or without double or single or quotes or follwing the documentation and pulling the "case sensitive value" from the url provided which would make it "en_us" with or without single or double quotes... all of which return the default message when attempting /timemanag now msg [myself] revealing that it was not working either. However, changing the value from "default" does appear to make it preserve the other set worlds, not sure why that would make a difference.

Also I'm not sure what "/tm set timermode true" does... it confirms it turns on but after that nothing seems to happen. I think I had better luck just checking /time and waiting 10-20 minutes and doing it more often as I approached the 20 minute threshold to verify no more than a day had passed. When times were set to 1.0, entire day cycles would complete in 10 minutes, there's just no method of achieving half-speed, as I've explained in the ticket.

* was able to set the language using commands instead of saving to the file. *** After getting the language setting to "keep"... the worlds stay saved in the file but the speeds reset on refresh. ***** Also able to keep the individual world settings if entering them all by command before a reload. Not certain but it may be resetting them over the "." and 's in the world settings, treating it like a special characters... maybe it was the same for the "_" in "en_US" in the lang.yml file as if those weren't escaped in the source when checking for valid input - just a guess.

ArVdC commented 2 years ago

The action of the timermode command is only visible in the console. When it works, it spams huge lines of text, but if nothing appears there, there is obviously a bug.

Also the debugmode generally makes it possible to visualize the actions carried out with the starting on the yml files, that can help to include/understand the exact place of the problem.

I will update the Java version of the project, maybe that will solve the compatibility problem. I haven't done that for a long time.

mrcoffee1026 commented 2 years ago

I ran it in the console it didn't appear to respond in any way, so yeah that might be a different bug entirely.

And yeah debug mode might have shown me what was going on with the files as it was happening but using the commands to set the values seems to have resolved the issue of them reverting to default settings or losing worlds so I won't see those issues going forward anyway. It might have something to do with character encoding but I'm not sure how since it looks like the default files come as Unix 1252 / UTF-8 (no bom) which is universally compatible as far as I know.

And sounds good I'll look for the update! Thanks so much, this plugin simplifies life for us on this server!

ArVdC commented 2 years ago

By the way, here are the recognized time slowdown ratios :

if (currentSpeed >= 0.9) timeRatio = 10/11
if (currentSpeed >= 0.8) timeRatio = 5/6
if (currentSpeed >= 0.7) timeRatio = 5/7
if (currentSpeed >= 0.65) timeRatio = 2/3
if (currentSpeed >= 0.6) timeRatio = 5/8
if (currentSpeed >= 0.55) timeRatio = 5/9
if (currentSpeed >= 0.5) timeRatio = 4/8
if (currentSpeed >= 0.45) timeRatio = 5/11
if (currentSpeed >= 0.4) timeRatio = 2/5
if (currentSpeed >= 0.3) timeRatio = 2/6
if (currentSpeed >= 0.25) timeRatio = 2/8
if (currentSpeed >= 0.2) timeRatio = 2/10
if (currentSpeed >= 0.1) timeRatio = 1/10
if (currentSpeed > 0.05) timeRatio = 1/15
if (currentSpeed <= 0.05) timeRatio = 1/20
if (currentSpeed == 24) timeRatio = 1/72
ArVdC commented 2 years ago

I updated the project to JavaSE-16 (jdk-16.0.1) and the Spigot API to 1.9, i hope it can change something. https://drive.google.com/file/d/1QnlemwddMrguOcT_RqBBSCeuBluoO0uS/view?usp=sharing

Le jeu. 9 juin 2022 à 16:41, mrcoffee1026 @.***> a écrit :

I ran it in the console it didn't appear to respond in any way, so yeah that might be a different bug entirely.

And yeah debug mode might have shown me what was going on with the files as it was happening but using the commands to set the values seems to have resolved the issue of them reverting to default settings or losing worlds so I won't see those issues going forward anyway. It might have something to do with character encoding but I'm not sure how since it looks like the default files come as Unix 1252 / UTF-8 (no bom) which is universally compatible as far as I know.

And sounds good I'll look for the update! Thanks so much, this plugin simplifies life for us on this server!

— Reply to this email directly, view it on GitHub https://github.com/ArVdC/TimeManager/issues/17#issuecomment-1151209081, or unsubscribe https://github.com/notifications/unsubscribe-auth/AEAENXUHQ66AUCTNHSGK7HDVOH67VANCNFSM5WTVOT6Q . You are receiving this because you were assigned.Message ID: @.***>

-- Arnaud VANDEN CLOOSTER

mrcoffee1026 commented 2 years ago

Yeah no there's still something up with the math, it's still running entirely too fast. No idea what the ratios were all about but 1.0 should be 1:1, since it is not, that breaks everything else too.

I still have to set all speeds to 0.1 to get as close as I can to an actual 1.0 speed since 1.0 is actually 2.0. 0.5 is unfortunately not 1.0 so that isn't a workaround, and 0.1 is only "the smallest I can set it to" without setting it to 0.0, which is obviously undesirable. Have you done something like hardcoded "real time" into this so that no matter what is set, vanilla behavior would be impossible? Since mc time is something like base 10 and real world time is base 4 or something like that?

ArVdC commented 2 years ago

What's crazy is that the plugin is supposed to do NOTHING when the speed is set to 1.0 at least if you don't use the sync option. If you activate it, then the ration will indeed be 1:1

Regarding the ratios, the first number is the number of ticks added. The second number is the time elapsed before adding these ticks. For example, if you set the speed to 0.3, the ratio is labeled 2:6 because two ticks will be added for every six ticks. The plugin's calculations are accurate, no one has reported any malfunctions like the one you described to me. The time calculation code has not been modified for several updates.

mrcoffee1026 commented 2 years ago

I don't think this is what is doing it since they seem to be interfacing with the time independently but I'll supply the .jar to you directly if it will help you test it: we are running RealisticSeasons which - via its "calendar" function has an effect upon time in the following ways: days are longer in summer and shorter in winter (a full day + a full night still == exactly 20 minutes [vanilla speed]). Could there be some interaction between the two plugins happening here since instead of setting a flat speed "1.0" as we would normally expect, you're instead adding so many ticks per so many ticks? If they change number of ticks that pass in a day or night, that might do it... although it should still average out to equate to the same number in my opinion but that's about the only other thing I can think of.

ArVdC commented 2 years ago

Of course, RealisticSeasons changes the length of days and nights according to the seasons. The speed and the duration of the day/night cycles are necessarily interdependent. I don't think their plugin does anything other than speed up or slow down time. If you send me the .jar, I'll install it on my server and get back to you more precisely afterwards.

ArVdC commented 2 years ago

I tried RealisticSeasons and did some tests, it seems that this plugin manages the flow of time well by speeding up or slowing down the flow of ticks. (By the way, it does it very well.) It seems to me both impossible and useless to simultaneously use two plugins that do the same thing, there will necessarily be conflicts. In this case, what exactly did you expect from TimeManager at the start? After all that has already been said above, I no longer really know what to look for.

mrcoffee1026 commented 2 years ago

I don't intend for Realistic Seasons to modify time for every world, just the main "world". All others should run at their normal pace always since RS isn't active in any others. The primary use I wanted out of TimeManager was the abilty to sync the sleep... so that players could sleep in one world at night and auto adjust all worlds to forward to day. I really don't want TM doing anything else with speed. I noticed - right away - that it automatically does SOMETHING with speed even when it's not desired: I have creative worlds which I have previously set to "noon" and set the gamerule "DoDaylightCycle false" which on restart, TM would switch this to "true" and change the speed to 1.0. I found I had to set the speed for the creative worlds to 0.0 and set the time there intead which was fine, but other than that, I wouldn't be using the speed feature at all.

Aside from keeping the time synched between worlds, the primary goal of my using TM was for another plugin we run: Werewolves. In this plugin, players can be transformed into a werewolf. If the worlds are not synched by way of moon cycle, a player can cheat in extra levels by jumping from one world to the next, experiencing the full moon and transformation in each. Yours is the only plugin I'm aware of - and the only command method I'm aware of - of setting the minecraft date for all worlds simultaneously. Without this plugin, I wouldn't even know how to go about doing it. RS doesn't seem to care about the "vanilla" date that TM manipulates in any way. It has some sort of tracking for days that have gone by, but this seems to operate independently (changing the date in RS has no effect on the current moon cycle, for example).

Hopefully that clears up what I'm trying to accomplish: and I think these two plugins can function well together as RS's final effect is still a day+night that is 20 minutes in length. It may adjust the speed of the day or night according to season but the final result is still a vanilla in length daycycle. Your speed 1.0 ... if it truly "does nothing" should then have no effect on the length of either night or day, and RS should function as expected.

ArVdC commented 2 years ago

Ok, I better understand your expectations, it all makes sense. But then to summarize, on Windows the speed works correctly and the issue is to understand why it does not work on Linux. I got a laptop on which to install Ubuntu, I have a lot of work at the moment but I will try to do that soon.

I don't know how the RS calendar works, but the TM calendar is based on the 'fullTime' value of the worlds which is a Vanilla characteristic, distinct from the daily 'Time' of 24000 ticks. The 'fullTime' increases to infinity while the 'Time' runs in a loop.

If the 'timermode' didn't display anything when you used it, it's precisely because the plugin didn't make any changes to the time calculation. Retry with a speed other than 1 and logically the console will show you all the calculations.

ArVdC commented 2 years ago

After much testing, I can't find any bugs using Ubuntu and OpenJDK. I'm very sorry, but I think there is something from your server configuration or another plugin than RS. Maybe try restarting it by gradually adding the plugins. Start with the basics: ProtocolLib, Vault, MVcore, ... then just add TimeManager and experiment. And then add RealisticSeasons (and don't add anything else yet) and try to check when the speed looks wrong to you. Maybe you could also try setting all day-length-in-min and night-length-in-min to 10 to undo any speed changes.

mrcoffee1026 commented 2 years ago

I'm probably not going to be up to testing removing several plugins at a time and restarting repeatedly in order to time the days in real time on my live server. All the same plugins with the same settings do not have the timing issue in Windows, it's only happening on the Ubuntu OS. If my server just goes completely dead quiet for days I may run a test like this while having the server in whitelist mode but otherwise it's just not practical and not likely to be plugin issue anyway since it's pretty obvious that whatever timing routine is in play behaves differently dependent upon the OS on which it is running, not the plugins that are installed (again, they are identical on both servers). Thanks for the help anyway, if you figure out anything new let me know and I'll run further tests on Ubuntu if possible though that's not likely.