You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The game kept waiting 12 seconds instead of the desired 60 due to BonusTime() not returning a 0, despite the "actual" bonus time being 0
Using ns.print(ns.bladeburner.getBonusTime()), I can see that the function returns a 0, a 1000 or a 2000 when I have no bonus time shown in the UI and the game is fully open and active. Further testing via spamming the stop/start scrip button shows that it appears to return 0 or 1000 50/50 of the time with 2000 being non-recreatable. Maybe the game just lagged unnoticeably or something when it showed 2000 idk
Apparently this is caused by the game approximating 3-4 stored cycles into 1000ms, and 0-1-2 cycles into 0ms
I have proposed using one of the following solutions on the Discord:
Make the function return 0 if it detects that the value is at an update's worth, or better if the UI isn't showing bonus time then the function should return a 0. If you don't have any bonus time that you can see then it shouldn't return a "true" if you check for bonus time.
Change the description to state that the function can return small values below [value]ms due to how the game updates. This would let the players know to test for specific time lengths (eg: Check for 60000ms bonus time when testing if there is enough bonus time for "diplomacy")
OK, I caught up on that lengthy thread. I think there are two issues here:
The documentation should certainly be improved to explain "bonus" time better. It's not something that only happens offline, but also a natural part of the mechanic processing. Explaining this properly would reduce confusion, and also reduce people trying to use it for what it's not for (which is most things).
The use of round in the return is very bad. It was probably put there to try and hide that bonus time accumulates online, but as you saw the rounding exposes 1000 on ticks 3 and 4. It should either be floor, or removed entirely (return 0, 200, 400, ... on ticks 0, 1, 2, ...)
I'll write a new documentation page for bonus time. It'll take a while, though. I want to write about bonus time for many cycle-based mechanics, not just Bladeburner. I'll also update TSDoc of all getBonusTime functions after that.
About the use of Math.round, I think removed entirely (return 0, 200, 400, ... on ticks 0, 1, 2, ...) is the better choice. If you allow a breaking change, I'll implement that change.
I was using the getBonusTime() function to check if there is bonus time or not as shown below:
The game kept waiting 12 seconds instead of the desired 60 due to BonusTime() not returning a 0, despite the "actual" bonus time being 0
Using ns.print(ns.bladeburner.getBonusTime()), I can see that the function returns a 0, a 1000 or a 2000 when I have no bonus time shown in the UI and the game is fully open and active. Further testing via spamming the stop/start scrip button shows that it appears to return 0 or 1000 50/50 of the time with 2000 being non-recreatable. Maybe the game just lagged unnoticeably or something when it showed 2000 idk
Save file can be found here: https://discord.com/channels/415207508303544321/415213413745164318/1332247235223748679
Apparently this is caused by the game approximating 3-4 stored cycles into 1000ms, and 0-1-2 cycles into 0ms
I have proposed using one of the following solutions on the Discord:
Make the function return 0 if it detects that the value is at an update's worth, or better if the UI isn't showing bonus time then the function should return a 0. If you don't have any bonus time that you can see then it shouldn't return a "true" if you check for bonus time.
Change the description to state that the function can return small values below [value]ms due to how the game updates. This would let the players know to test for specific time lengths (eg: Check for 60000ms bonus time when testing if there is enough bonus time for "diplomacy")
Bug report and discussion on Discord: https://discord.com/channels/415207508303544321/415213413745164318/1332239717143543830
The text was updated successfully, but these errors were encountered: