IC Script fork: Briv not getting into formation fast enough
Closed this issue · 6 comments
Script Version v3.21, 01/14/2022
Periodically I will experience Briv failing to get back into the formation fast enough to be present when the area is completed, resulting in progressing slightly forward and operating on the x2 or x3 zone instead of the x1 zone. I'm currently using a 750 zone farm, and this typically happens multiple times during the run. This forward creep ends up being a problem on Temporal Rift in the Goblin Halls as the x3 zone has a lot of barricades that slow down progress.
I've attached a slow-mo video showing the incident occurring, but is there any additional data I can provide?
skip-fail_Trim_Slomo.mp4
I'm on Win 10, CPU: 3800X, GPU: 5700 XT, desktop resolution 5120x1440 if any of that is useful. I have noticed the issue is more pronounced at lower resolutions, including both 1366x768 and 1280x720, but still occurs infrequently at 1600x900 and above.
We have had a few users report this issue but are unable to reproduce it on our end. Currently there are too many variables and unknowns for us to understand why this is happening. We are going to need to develop tool(s) to turn the unknowns to knowns. In the meantime, we have recommended removing Hew from the 'e' formation.
Thanks for the recommendation.
I having a similar issue, but in my case it's Briv staying in the formation too long. My Briv currently jumps 3 areas 70% of the time, 4 areas 30% of the time, so he's not allowed to skip on x1 and x6 areas. But occasionally, he's still in the formation when the x1 or x6 area completes.
I can not offer any reliable statistics on this, but it appears to me that this happens more likely when a "half" fast transition occurs and even more so when a "full" fast transition happens.
Some explanation to the non-standard terms: I am playing (or, rather IC Script Hub is playing, an excellent product by the way) Tall Tales. Without Briv, a fast transition happens when the background between two areas stays the same; the animation of the champions moving our of the screen to the right and back into the screen from the left is omitted.
With Briv, things are a bit more complicated (sort of). When Briv jumps (eg. z2), and the next area (which he skips, eg. z3) has the same background than the one he's leaving, the "champion exit to the right" animation is not played. When Briv lands in the target area (eg. z6), and the background is the same as in the area preceding the target area (eg. z5), the "champion enter from the left" animation is not played. Only when both conditions are true, both animations are omitted - that's what I call the "full" fast transition. When only one condition is met, one animation players, the other does not, and that's what I call a "half" fast transition.
Normally, even when doing a "full" fast transition, Briv appears or disappears correctly before the wipe is completed. I see that IC Script Hub reports a "current area time" sometimes as low as 0.20 seconds when the transition occurs. I have just watched a full run (up to the Briv stacking area) with several occurrences of very fast areas (0.20 - 0.22 seconds) and, naturally, in classic Heisenbug tradition, the issue happend not a single time. Yuk.
On the next run, I popped a small and a medium speed potion (in addition to the Shandie speed bonus and the Modron core speed bonus, of course). I saw IC Script Hub occasionally reporting a "current area time" of 0.00 seconds and it even appeared to me that IC Script Hub didn't start the timer again until another (very fast) area had passed. Three Boss Hits on that run, btw.
It looks like the "current area time" timer is updated in intervals ranging from 0.20 - 0.25 seconds (source code confirms 200ms). So it might that IC Script Hub has an internal polling interval of 0.20 seconds. It also appears not to be constant, maybe being influenced by how much CPU load is on the machine (obviously, when Briv stacking happens and 100 enemies are on the screen, everything's sluggish and IC Script Hub updates it's statistics very infrequently).
My suspicion is that the polling interval of IC Script Hub is, only sometimes, just not fast enough, and possibly influenced by factors outside IC Script Hub. Source code tells me that SetBatchLines is -1, so the script already runs at full speed.
Dropped another CPU core into my machine, it now has three cores, set processor affinity to core 0 for AHK, cores 1+2 for IdleDragons.exe, popped my speed potions again...and the game now hits bosses even more often. Significantly more often! It seems that the additional core allows the game to run even faster now while AHK runs at the same leisurely pace...yes, leisurely pace. The timer seems to update still at the 0.2s intervals, and core 0 is running at below 25%, with occasional peaks going up to 50%. The AHK process with priority "high" (that should be the gem farm process) stays below 10%. That is...not what I expected.
Looked into https://github.com/mikebaldi/Idle-Champions/blob/main/AddOns/IC_BrivGemFarm_Performance/IC_BrivGemFarm_Functions.ahk where I found a Sleep, 20 which I naturally immediately changed into a Sleep, 5. Still hitting bosses, but not as frequently now (again under the influence of speed potions). I can also still visually confirm that Briv appears/disappears a zone too late in these cases.
Next up: Sleep, 2, again with speed positions. Now everything is broken, formations are no longer swapped at all! So, the script can get too fast for the game it seems.
Sleep, 10 appears to roughly perform as well or as bad as Sleep, 5. The sweet spot appears to be Sleep, 8...at least for, today, with the current CPU load and moon phase. I can now see that Briv gets swapped out of the formation before he lands in a new area, and gets swapped in too late sometimes. Which is less of an issue the way my jump areas are configured.
The real solution would be to get Briv to 4 area jumps. However, if the script still swaps him out on every jump and back in once the target area is determined, this can still lead to issues. With a "4-jump Briv" (possibly with the Wasting Haste feat), that should not be done as he'll jump 4 areas reliably in that case. I do not know if the script queries that feat and 4th item ilvls.
So adjusting the Sleep, 20 appears to help in some edge cases. As i suspect that it depends on hardware, machine load and whatever, it would need to be a setting which the user can tinker with himself, and without warranty of any kind. And if the script doesn't check for the "perfect 4-jump", another checkbox might be an option to prevent Briv from getting swapped out when he'll get swapped in right away again.
Other that that...I'd be inclined to say it's possibly a limitation of Idle Champions.
Correction to my previous comment:
I mentioned that Briv gets swapped out unnecessarily. That's not true, as this is done to speed up the game by eliminating the Briv jump animation.
Addendum to my previous comment:
I also have the suspicion that the game has a limit to how fast it can process keystrokes. Even if I stop the farming script, the game sometimes continues to process keystrokes for a few seconds. This is especially noticeable when I stop the script in the early level-up phase (in the very first areas). Note that my formation consists of ten champions, so there are a of of F-keystrokes going on.
So I disabled the "Level up with F-keys" option, placed familiars on my champions to level up them up, restarted the farm, popped my two speed potions again and got a perfect run, zero boss hits!
So, apparently, when several level-up F-keystrokes are being sent to the game, followed by a formation switch, the game cannot process the keystrokes fast enough and it's the game which does a bad job, not IC Script Hub.
Oh well. There might be a possibility that the script could limit the number of F-keystrokes it is allowed to send per second (maybe only activated after the initial "power leveling" in area 1, which in turn might result hitting a boss early on...whatever). And maybe, additionally, F-keystrokes could be queued by the script and sent only after a formation switch keystroke. But not sure whether this is worth the effort, as it also means a lot of time-consuming testing, and it's also a "statistical" thing - some runs may also hit bosses because the machine (CPU, RAM, HD) is busy doing other things.
Note that while trying all this out, the Sleep, 8 was still in place. Sorry, my bad.
Edit: After a few runs without F-key leveling , I saw a few boss hits again. Only one single boss hit per run, always in the first areas (possibly the boss in z5). "Dash wait" is disabled, btw. These were runs without speed potions. Looks like the game also lags when familiars are leveling up. Still an improvement!
Yes, with the improved setup (familiars doing the levelling), Briv hits the boss in area 5 with a jump from area 1. Despite not being allowed in the formation on area 1, he's there and jumps. Not sure what's going on there - but yes, my Modron starting formation is the Q formation, which includes Briv (naturally with a familiar leveling him up). Also, my E formation (which, of course, has Briv on the bench) still has a familiar in his bench slot (I figured it would be beneficial if he levels up as quickly as possible, even when on the bench).
So when the script switches to the E formation before Briv is unlocked by the familiar, then the first click of the familiar will place him back in the formation. Removed the familiar on Briv from my E formation, then set the E formation as my Modron start formation. Dumb idea. Once the script switched back to the Q formation, I had to click the Metalborn specialization manually. Ouch. Also noticed a strange effect: the "Calculated Target Stacks" went from somewhere around 2800 to above 8000. So Briv stacking naturally failed (or rather the script thought so; he actually collected way more stacks than needed - somewhere above 4000 stacks). Whatever. I just stopped the script, started it again, and everything was fine again
So, back to the Q formation as the Modron start formation and another run. This time everyting worked perfectly! The Q formation stayed quite some time on the screen in area 1 but got swapped out just before the change to area 2.
So the fix was just to omit the familiar on Briv in the E formation.
Side note: I then also noticed that I had no familiar on click damage (I wouldn't have had enough familiars anyway), but the script does the right thing automagically and levels it up for me. Nice!
Still running with Sleep, 8, so I changed it back to Sleep, 20. Next run with the original code (and the Modron core popping a small and a medium speed potion in area 1 for me). Not so good. In one area, I saw that Briv was swapped into the formation too late, and on the next run, Briv was not swapped out fast enough in area 1 so he jumped directly to area 5. Oh well, the area 5 boss goes down fast enough, so that's a minor issue.
Still would like to see a configuration option to change the Sleep time. Maybe not in the GUI, but in a JSON configuration file. For expert users only, since I've seen that mucking around too much with that value will seriously screw everything up.
Thank you Klaws-- for your detailed reporting. Your testing looks to mirror what we have seen on our end as well.
The TL:DR of it is that I am not convinced that there is a universal fix for the issue, just tweaks that can help reduce the occurrences as it appears to be a combination of system dependent problems and the nature of running multiple processes with their own limitations and not being able to directly influence each other's command flow.
As you noticed, there appears to be some kind of rate limit to the amount of keystrokes that can be sent form the script to the game over a given time period. When building the script there was a lot of effort put into to finding efficient values for the rate at which those keys were sent. Admittedly these values are likely system dependent but the script seems to be working fairly well across systems as far as I'm aware. The DirectedInput function in SharedFunctions is a good place to investigate tweaking your key press rates (such as adjusting the timeout or repeating keystrokes that fail - but watch out as re-sending failed keystrokes could back up that key press queue).
Regarding Sleep, 20, since the script runs in a loop it will become unresponsive without any code that gives it breaks. The GUI will become unresponsive and the main Script Hub window would be unable to poll the gem farm script for data due to it being busy, which will freeze the Script Hub window as well. The value 20 was chosen mostly because according to the documentation for sleep, the delay can be rounded up to the nearest 10 or 15.6 ms and the OS can even "typically" require 20 ms when the CPU is under load. So because that seemed to be are more universally usable number, that was the value that was used.
One thing that may help reduce issues with jumping is to just run the Gem Farm script without running script hub. The polling it does to the gem farm script is fast but not 0. If the bad party switches are more of an issue for you than not being able to see stats, it may be worth trying.