bugfix: wait for loading screens to finish before doing initial buff #722
Conversation
internal/action/buff.go
Outdated
| @@ -48,6 +48,7 @@ func Buff() { | |||
| } | |||
|
|
|||
| // Check if we're in loading screen | |||
| ctx.RefreshGameData() | |||
There was a problem hiding this comment.
Are there downsides to this besides a few more CPU cycles? Is there a better way?
There was a problem hiding this comment.
You can selectively update just what you need from GetData() .
ctx.GameReader.GetData().OpenMenus.LoadingScreen
Or ctx.GameReader.GetData().OpenMenus
For all OpenMenus
Full refresh data is on a 100ms ticker already, the less we call it the better it is for cpu
| time.Sleep(100 * time.Millisecond) | ||
| ctx.RefreshGameData() |
There was a problem hiding this comment.
Hello , can you make sure the removal of the last refreshgamedata after loading screen is completed doesnt create issue with tinymod when creating new game. . Is perfect to only loop the loading screen until loaded but unsure if we dont need one full refresh after to sync.
it was in place because it would try to move/identify items without everything loaded with tinymod . Thanks
There was a problem hiding this comment.
I haven't used tinymod before, I'll just add a final refresh back in with a comment.
I did a brief look through closed issues and PRs; are there reproduction steps for the tinymod issue so that someone could check if this refresh is needed? When/if I get tinymod set up, I'm not confident I'd be able to say that the refresh isn't needed. Putting back the refresh is safer but potentially redundant.
Fix for #714
By refreshing the game state before checking for a loading screen, the bot successfully identifies the loading screen and waits for it to complete before running through the Buff routine, avoiding the problem identified in issue 714