10-09-2021, 03:27 PM
(10-08-2021, 11:01 AM)SaT_Admin Wrote:(10-07-2021, 01:19 PM)ACR bug still present Wrote: I'm sorry i messed up the format in the last post.
Answer to your question;
When this part fails, is it the failure you describe above? Where the betbox does correctly get input, but the Bet/Raise button doesn't update?
Or does the new bet never get entered correctly into the box at all? And if so, what does get input there when it fails? Is it empty? Is it full 100% pot (as if no calc was performed and just the 4th betsize button was pressed)? Does a wrong % bet end up in there?
*No, the betbox does not get correctly filled, don't think its ever empty, just potsize filled.
I'm trying to work on this to see if I can make it more efficient
Another thing I notice, when I open up Task Manager in windows, I see that when the SAT highDPI version is running (pressed Start), I'm seeing an "Antimalware" process spool up to consume a bunch of CPU. As if Windows Defender is thinking that SAT is malware and constantly monitoring it...
yes, i have issues with windows defender as well since the last update. I have now completely disabled it.
On another note:
I have discovered this bug which may contribute to some of the issues we are facing. If I try to manually input 2.2 or 2.3 into the betbox pre-flop, the .2/.3 decimals are removed automatically, it seems the client forbids me from inputting these values whereas using the same values on our pre-flop bet buttons don't give any issues. It is specifically for .2 and .3. (the values 2.1 2.4 2.5 and so forth are fine to input). I have no clue why but there may be post-flop situations where something similar happens where the value can't be copy pasted back into the betbox because the client denies x input value? Just an observation. You have this same issue?
