[Briv] maxOnlineStackTime leads to hard to diagnose resets
Closed this issue · 6 comments
When StackNormal() aborts because maxOnlineStackTime has been reached, the GUI shows a normal "Game is stuck" restart reason. This, however, is misleading---being "stuck" in one area while stacking is expected. Also, the user doesn't know that there is a time limit for stacking without reading the source code.
I'd suggest at least showing the reason as "stacking took too long" and exposing maxOnlineStackTime in the advanced settings, but ideally, that check should be changed from a simple timeout (that is easy to hit with a Briv who's not iLevelled into the thousands, especially when initially tuning the settings and not having speed potions active) to e.g. a "stacks acquired per second" minimum.
Edit/PS: Also, the normal stuck check can fire after stacking if the stacking zone wasn't cleared during stacking. My guess is that g_PreviousZoneStartTime isn't reset by the FallBackFromZone() in StackNormal() nor the auto-advance into the stacking area? Not too sure about this one, so I'm just adding it as a remark to this ticket.
Edit 2: Watching the "Current Area Time" in the GUI confirmed my suspicion; the time keeps going after stacking has ended and the main loop is active again.
Thanks for the feedback.
It does appear that g_PreviousZoneStartTime is not being reset after StackNormal() and I can see that causing resets that should not occur when stacking.
As for the stacking taking too long reset, 5 minutes is extremely generous for stacking so it wasn't really expected to need explicit error messages. I'm wondering in what cases someone would need 5 minutes of stacking? Generally if stacking is taking 5 minutes the stacking should be done offline as it is significantly more efficient.
5 Minutes is fine once you have tuned the system, but it is easy to reach when first starting. I created my saved formations, put in eye-balled area targets and left target stacks at auto---exactly what I expect every new user to do. But it's kinda hard to tune a system when it doesn't run a full cycle in the first place.
And BTW, that calculated stack value really is so pessimistic (for me: auto said >16k, but I only need 5050 and still have plenty of safety margin) that I see no reason to ever use it as a setting to turn on. It's at best a starting value for manual tuning (i.e. a button that shows the value and puts it into the field when pressed). Having it as a checkbox that's on by default is "a trap for young players" as some people like to say.
And PS: I changed the timeout locally and it worked fine, allowing me to tune it. It would be nice if the "last run" statistics would show how many stacks would have been enough to finish the last run (i.e. calculate how my jumps the remaining stack could have done and then remove that many jumps from the stack the run was started with). I did that manually, but the math is annoying. (And, tbh, this would work as an auto value if it was updated over a couple of runs, I suppose.) I also added resetting g_PreviousZoneStartTime to StackNormal, and I never had another "stuck reset" again, but I'm not sure if my change did something or if it was just luck and me changing my stacking area soon after to be closer to my reset area to avoid hitting that "collect 1 item" stage after stacking.
I also changed the "reset for running out of stacks" area range. Running through 5 areas without jumps is way faster than restarting the game. It's another thing that won't (shouldn't) happen after tuning the system, but those over-eager restarts are annoying when using the computer for something else.
It seems a lot of this discussion revolves around design choices rather than intrinsic design problems. As such I'd like respond with why the script is set as it and get your feedback on it before I go ahead and make significant changes.
Getting "stuck" before 5 minutes when online stacking is a bug. That will be fixed.
5 Minutes is fine once you have tuned the system, but it is easy to reach when first starting.
The script is designed around utilizing the efficiency of offline stacking. Online stacking is a niche use case and not intended to be used by new users. What was your reason for circumventing that in the starting configuration?
5 minutes is arbitrary and can be changed but is there as a safety measure. Generally any loop in the script that can potentially go on forever (in this case waiting for stacking) has a timeout to avoid being stuck in perpetuity.
calculated stack value really is so pessimistic
Yes, it is. It is a "better safe than sorry" approach. It's not feasible to regularly calculate a more accurate value for non-100% jump values due to the nature of the calculations requiring simulations. Unfortunately it's also the most inaccurate at low jump % values.
With online stacking at low jump values I can see how the inefficiency is a significant time loss, but with offline stacking it should be less of a hit, or not hit at all. If you can get 5k stacks from offline stacking once then I'd expect you can get 16k stacks from offline stacking once as well. Admittedly it has been a long time since I have had a new player experience and there have been a number of changes to offline stacking so I'm not sure how accurate that expectation is anymore.
Having it as a checkbox that's on by default is "a trap for young players" as some people like to say.
There are two main purposes behind the setting. First, to give a feasible introductory value for new players to ideally let them be able to just press start and have the script work, albeit inefficiently. It has always been the intention for players to use manual stacks as one of the first configuration changes in the tuning process. Perhaps this is not conveyed well, in which case I'd like to know how to better show that intention.
Secondly, the auto-calculate has benefits in the script's efficiency for 100% jump values, particularly with early stacking.
i.e. a button that shows the value and puts it into the field when pressed
The checkbox toggle is used since when auto-calculate is enabled it regularly re-calculates the value when running the script since different factors play into the calculation (e.g. leftover stacks from a run, changing the modron reset area, opening chests that affect Briv's jump %).
Running through 5 areas without jumps is way faster than restarting the game.
Generally that's true, but this is another case of better safe than sorry. 4 areas was the most I was willing to have the script walk without jumps because some of the more popular maps used for farming have armored bosses which will cause the script to get stuck.
StackNormal()
restarts are annoying when using the computer for something else.
It sounds like you are prioritizing not losing window focus much higher than gem farm efficiency. Fixing the bug with restarting when stacking takes less than 5 minutes should help with that.
Since you would likely notice, are there other instances of restarts that you feel should not be happening for you?
Just to share an update specific to "trap for young players":
Uffdah added an API at ic.byteglow.com that IC Script Hub can use to automatically calculate target haste from using in game information (shiny/item levels/rarity/metalborn/modron reset area).
I'm working on adding that to the script to help simplify setting up that setting the first time. You can see the progress in the Byteglow-Stacks branch.
Sorry for the late reply, but your comment sent me down a rabbit hole. So let's see if I can get that into words in a somewhat structured manner:
The script is designed around utilizing the efficiency of offline stacking
Big point that the documentation never conveyed. While it is extremely good in the "initial setup, follow here" department, offline stacking is just mentioned in two places in the gem farm setup document, both in a "for offline stacking" manner. There's no explanation of what offline stacking is, how it works, how to set it up, how to tune it, etc.
I had a general idea (been with the game for long enough) but wasn't aware of how it actually works (i.e. the side effect of offline stage survivability time calculation producing phantom stacks). As I didn't purposefully "circumvent[...] that in the starting configuration", I decided to dive into the code to look at what was going on there instead of bugging you. Luckily I quickly found the .md file in the gem farming plugin folder, and that one gave a very good explanation. It seems offline stacking got lost when I turned off all the optional behaviour at the very beginning.
So I dove for the default value in the code, copied it into the config and let the thing run. Three hours later, I found it in an endless loop of killing the stuck client:
It didn't happen again, and I have no idea what triggered it, so let's call it a fluke. Other than that, offline stacking worked flawlessly until tonight's update. But more about that later.
However, one thing is clear: Offline stacking is unusable while I'm using the computer. Even when the IC window pops up just for a moment, there are enough programs that don't like losing focus at all (e.g. go out of fullscreen, auto-pause, etc.), and that's even ignoring keystrokes sent to the wrong program and the annoying effect of having something pop up in the middle of a movie every 5 minutes. So I made two profiles and now simply switch to the online one whenever I turn my monitor on.
In the meantime, I also dropped some blacksmithing contracts on Briv to get him to do farther jumps. I had him specced for Jimothy runs using my own script (that's quite easy by just reading the colour of two pixels) and concentrated on Hew Maan. But now, after the nerf (did I mention I was away for a year and a half?), that at least got me a big stack of blacksmithing contracts. (75% for 3-jump, from ~20% for 2-jump)
efficiency of offline stacking
Now here, I must still be doing something wrong. When running to my click wall, I see a 20-second difference between online and offline stacking---and I just noticed I was still stacking ~500 stacks more than I actually need now. Sure, that is a high percentage of a 5.2m loop, but the 6+-hour downtime due to today's update makes up for that easily. (In case you're not aware: While EGS silently updates games that are not running, when you start a game that has a pending update, e.g. because it was running, you get a "game will be updated now, please wait [OK] [OK, but cancel the start]" screen.)
However, writing this down reminds me of one thing I'm doing wrong: I haven't done a Jimothy run since the ban wall was raised from 1400(?) to 2000(?). This should raise my click wall and the number of Briv stacks I need in one run.
Update: I lowered the target stacks, bringing online stacking to be only 10 seconds slower than offline. The last run still ended with 72 stacks left, so in theory, I could go down another 500 stacks there. Still not low enough for offline stacking to produce enough stacks for two runs, though.
It has always been the intention for players to use manual stacks as one of the first configuration changes in the tuning process. Perhaps this is not conveyed well, in which case I'd like to know how to better show that intention.
As I said, a button "calculate worst case" instead of the checkbox is what comes to my mind first. Alternatively, "[_] use calculated worst-case value of %d stacks". Or maybe:
(X) Use calculated target stacks
Calculated: %d stacks (worst case)
Manual Offsets: [__0] % and [__-100] stacks
Effective target: %d stacks
(_) Use fixed target stacks
Stacks: [_____0]
(_) Use fixed number of jumps
Jumps: [_____0]
Effective target: %d stacks
In regards to making the calculation more useful, only counting the areas that actually have jumping enabled and targeting (minimum_zone + modron_target / 2 come to mind. The latter will be more useful once the devs deliver the promised button to restart the foreground adventure, as the script can then just farm stacks anywhere when running out and restart after farming (which, atm, is two game restarts).
Since you would likely notice, are there other instances of restarts that you feel should not be happening for you?
So far, I haven't noticed any extra restarts when running online. And yes, those I would notice, as I was only running online while I was using the computer.
BTW: It would be nice if the stats would be saved once per run and reloaded when the script is started. I had to restart my computer earlier and would have liked to refer to those values just now. It's very minor, with those stats not being that detailed anyway, so maybe writing a "last hour stats" entry into a CSV file might make more sense. This would also give you a history to track your progress. (CSV so it can be thrown into Excel/Numbers/Sheets/OO for a quick graph.)
Sorry if this turned into a blog post, but I guess it's better to write too much than to base things on wrong assumptions---and I certainly had some of those when setting the script up.
Sorry if this turned into a blog post.
No worries. I appreciate all the feedback you have given. You've clearly put a lot of time and thought into your replies. It's certainly given me cause to look at a new user experience a bit closer. It's certainly more painful to tune than I realized. I had plenty of favor to go deep, but with offline stacking I was getting < 3000 stacks, while I was needing > 35000. That's a lot of offline stacking attempts when you should be shooting for just 1 restart per run. It can be very awkward, but it does get simpler with higher Briv ilvls.
I found it in an endless loop of killing the stuck client:
It's very unusual to have offline progress take so long. Do you have more than just Briv in the offline stacking formation? The script will terminate the game if offline progress takes too long (>90s). If that happens the failed offline dialog will pop up on next start. That should also timeout after 90s, but unless something changed recently, it should load the game without offline progress. However you'll have no stacks so it'll likely attempt to offline stack again. The script should inch forward in zones when stacking fails in an attempt to avoid problematic areas for stacking, but I honestly am not sure how it behaves when it times out.
If this is a recurring problem you can try adjusting the timeout in WaitForGameReady in IC_SharedFunctions_Class.ahk.
However, one thing is clear: Offline stacking is unusable while I'm using the computer.
From what I've seen in discord most people don't have issues watching movies on their computer as long as they have the RestoreLastWindowOnGameOpen setting enabled in advanced settings. It causes a flicker every few minutes when it restarts for stacking but unless you are particularly sensitive to it, it's easy to ignore.
If you are playing a full screen game, I agree, restarting IC is a huge problem. That is what online stacking was originally intended for but obviously it still has its flaws. You may want to look into running the game/script in a Virtual Machine (VM) if your system has the resources for it.
the 6+-hour downtime due to today's update.
Unfortunately the forced updating is an EGS specific problem. Other platforms will let you run the game without updating and you can update on your own schedule. Judging by the time of your posts and the fact that it was a 6 hour downtime for you, it sounds like you are not in the same timezone as CNE and are unlikely to catch an update as it happens. I know some people use the heroic/legendary launcher as a workaround for this exact problem.
As I said, a button "calculate worst case"
This should be going in the next update, and it should be more accurate since it would be utilizing byteglow's calculations which uses simulations.
still stacking ~500 stacks more than I actually need now
For fine tuning stacks you get offline ImpEGamer wrote a popular addon called BrivGemFarm LevelUp. There should be a link to it in the Addons.md file.
It would be nice if the stats would be saved once per run.
I have a policy of avoiding adding this kind of thing to the script. I do my best to avoid features that can perpetually increase memory or disk space usage. I also believe byteglow fulfills this purpose well enough for the typical user.
There is a lot of information in this post and replies. Not all of it is from my direct experience. If you haven't already, I'd highly recommend checking out the #scripting channel in the official IC discord. There are a lot of very knowledgeable and helpful people there to answer any questions you have.