baritone
baritone copied to clipboard
cabaletta
`#mine deepslate` crashes game
Some information
Operating system: Java version: JDK 17 Minecraft version: 1.19.2 Baritone version: Whichever one comes with Meteor Client Dev Build 0.5.1 Other mods (if used): Live Overflow mod (look on github), a modded version of FUFU client (look on github), MultiMC, Appleskin (bug also happens without) and fabric API
Exception, error or logs
How to reproduce
Use #mine deepslate
Final checklist
- [x] I know how to properly use check boxes
- [x] I have included the version of Minecraft I'm running, baritone's version and forge mods (if used).
- [x] I have included logs, exceptions and / or steps to reproduce the issue.
- [x] I have not used any OwO's or UwU's in this issue.
Just drag and drop the file into the issue or paste the log into <details><summary>log</summary> paste log here </details>
<details><summary>log</summary> paste log here </details>
Ah, I'll do that
It's an OutOfMemoryError so you should definitely try the nobrainer solution and increase the heap size. I don't really expect that to work though. I just don't have a better idea.
Yeah, I realized that, I guess it was kinda stupid of me to want ALL the deepslate to be factored into the pathing, highlighting, etc.
No, you should be able to mine any block. Baritone should handle this (by only considering the closest dozen ores). Also really check whether another GB of memory fixes the OOME, maybe it's just your other mods not laving enough free memory. (when I wrote "I don't really expect that to work" I hadn't noticed you were mining a super common block and was expecting some bug which would easily fill up the extra space as well)
I did add another gigabyte of memory for another reason earlier, so I'll test it out and see if it works this time.
On Mon, Nov 14, 2022, 2:58 PM ZacSharp @.***> wrote:
No, you should be able to mine any block. Baritone should handle this (by only considering the closest dozen ores). Also really check whether another GB of memory fixes the OOME, maybe it's just your other mods not laving enough free memory. (when I wrote I didn't expect that to work I didn't notice you were mining a super common block and expected some bug which would easily fill up the extra space as well)
— Reply to this email directly, view it on GitHub https://github.com/cabaletta/baritone/issues/3726#issuecomment-1314461331, or unsubscribe https://github.com/notifications/unsubscribe-auth/ASOHVIMDA4VJB7F6PH7L36TWIKYYDANCNFSM6AAAAAAR6EXOAU . You are receiving this because you modified the open/close state.Message ID: @.***>
this is still happening in 1.20 release. when i do mine diamond_ore, ram is perfectly fine at 4 - 4.2 GB, when i do mine deepslate, somehow my ram fills up to 15.6 GB and my game crashes. this is driving me crazy it was just working, i will look into settings as i see a ton of green squares rendering below me, just wanted to comment my experience for now.
Same thing is happening to me and i have no clue how to fix it, does anybody here know? I put 10gb of ram to use but weirdly it still doesn't work, any solutions?
Does increasing
mineGoalUpdateIntervalhelp?
@ZacSharp I increased mineGoalUpdateInterval to a higher value and it resolves the issue, please see my summary below.
With mineGoalUpdateInterval set to 5, if I run the command #mine deepslate my game takes up an expected large amount of RAM / Virtual memory. This also happens with other ores which slows down my game but it is much less noticeable with anything other than deepslate in my experience, probably the sheer number of items being checked in the deepslate use case.
When this happens in my testing, I stop baritone, and my frame rate does not recover until I initiate the garbage collector doing #gc. Then my ram is clear and my frame rate is back.
In my personal case I set mineGoalUpdateInterval to 40 and I have zero performance issues now, this can likely be lower for most people. I also experience similar performance behavior when increasing builderTickScanRadius and this is to be expected, so this solution makes perfect since. This seems like it is due to the large number of blocks being cache naturally when selecting candidates for mining targets. Could possibly work around by limiting the number of candidates cached, I feel like this is already existent to some extent or there was a setting for this, I do not know enough about the code.
Thanks for the confirmation. I'm now pretty sure I know the problem and have a fix ready for half of it (with the second half not being a problem anymore if your CPU is good enough. I've yet to test whether a potato is good enough)
Thanks for the confirmation. I'm now pretty sure I know the problem and have a fix ready for half of it (with the second half not being a problem anymore if your CPU is good enough. I've yet to test whether a potato is good enough)
Thank you for taking the time to look at this issue, it is appreciated. Glad to hear you have likely figured it out! I aspire to contribute here more as my knowledge grows if it is possible, let me know if you need help testing anything.
You can try whether https://github.com/ZacSharp/baritone/commit/7e99455444c04a65cc69e03089d97254790d168a (actually the commit before it, I forgot to remove a testing change before committing) fixes it. When I tried on 1.20 I couldn't get the game to freeze and crash without the patch either so not sure.
I had the same issue when asking Baritone <#mine deepslate> and my game would freeze. I fixed this by digging down to Deepslate levels and running the command again and no freeze or lag.
