mineflayer
mineflayer copied to clipboard
PrismarineJS
1.21 support
Describe the solution you'd like
Add the 1.21 support to mineflayer
Describe alternatives you've considered
I tried changing the accepted versions in some files but i got some errors I saw on the node-minecraft-protocol that we need to wait for the 1.20.5 and 1.20.6 to be added so i guess we just need to wait
Just switch to writing bots in Fabric, their API is better, and you can probably learn Java in less time than it takes Mineflayer on average to update for a minor Minecraft version.
The project owners of Mineflayer have all but abandoned the project from what I can tell. They haven't really cared about keeping it updated for latest MC version for years. The project isn't dead yet, because a few people are still stuck with it as a dependency for their old legacy projects, so there's a small community of user-sourced contributors who will sometimes update it. But usually by the time Mineflayer updates to the current version, Minecraft itself is already on their next update.
well, i didn't know you can write bot in Fabric, like is it a mod that you install on a fabric client ?
I liked the Mineflayer thing because it was very light weight and didn't have to render the game. For that, there is the console-client in C#, but it's not updated yet.
a small community of user-sourced contributors
Yes, that's how open source projects work. PrismarineJS is not a company and does not hire anyone to work for the organization. It's a fully volunteer driven effort, and changes to code will only be made when someone was able to, and willing on their own accord, to write the needed code changes and open a PR to upstream their changes.
If you would like a specific change then you can...
- Open an issue in upstream (if it doesn't already exist)
- Make the changes yourself and PR or contribute to existing work (if it exists)
- See if there are other ways you can incentivize others to make the desired change (we have GitHub sponsors, if you'd like to put a bounty on an issue you can state your intention to do so, open to anyone to claim it)
You are of course welcome to use whatever tooling you want, there's no competition here. But being rude and entitled on volunteer projects about them not coding what you want them to on your timeline isn't nice. The people here generously taking time out of their days to work on and maintain software you get to use for free don't deserve to hear that, it's not incentivizing anything.
The project owners of Mineflayer have all but abandoned the project from what I can tell. They haven't really cared about keeping it updated for latest MC version for years.
Why the lies? Do you have financial interests into Fabric?
well, i didn't know you can write bot in Fabric, like is it a mod that you install on a fabric client ?
I guess so, but it would be nice to run the bot without the game window or somehow just in the background
I'm eagerly anticipating the 1.21 update! A big thank you to the development team for bringing this fantastic project to life.
Please send PRs to provide 1.21 support and then you should be able to figure out a date
On Tue, Jul 30, 2024, 20:12 Johnson @.***> wrote:
What time can update 1.21, please I very need this value.
— Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/mineflayer/issues/3406#issuecomment-2258928007, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437SA24N6THDENQPMIY3ZO7JQVAVCNFSM6AAAAABJYG4R2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENJYHEZDQMBQG4 . You are receiving this because you commented.Message ID: @.***>
You can start by helping there https://github.com/PrismarineJS/minecraft-data/pull/898 ; read the latest comment for more info
You can help by writing and publishing code to implement support for 1.21! :)
But usually by the time Mineflayer updates to the current version, Minecraft itself is already on their next update.
🤣 True. Minecraft Live is in two days. Soon players will be asking for 1.22 support.
Imagine how fast we would get 1.22 support if all the users in this issue spent 1h per day to contribute
Imagine how fast we would get 1.22 support if all the users in this issue spent 1h per day to contribute
Good idea! How can I help?
https://github.com/PrismarineJS/node-minecraft-protocol/pull/1309 https://github.com/PrismarineJS/prismarine-registry/pull/37 https://github.com/PrismarineJS/minecraft-data/pull/898 https://github.com/PrismarineJS/mineflayer/pull/3412
current state.
We need to debug failing tests there https://github.com/PrismarineJS/mineflayer/pull/3412
I'm not sure if I should be doing this tbh, but as a temporary stopgap, you can use my plugin:
https://github.com/GenerelSchwerz/mineflayer-viaproxy
I am not sending this in any attempt to dissuade people from contributing to 1.21, but for those who believe they are unable to contribute to updating 1.21, this can be used as a replacement.
You can use ViaBackwards on server, and Version argument in bot start: bot = mineflayer.createBot({ 'host': 'gn1.slicehosting.tech', 'port': 27527, 'username': BOT_USERNAME, 'version': '1.12' }) But some blocks and features will not work.
It seems the current failing exampleBee test case is not really failing?
I noticed it was trying to connect to the 1.20.5 server as a 1.20.6 client (I am still not sure why it does this). After setting version: '1.20.5' in the example file for all the exampleX tests it passes.
After which the raytrace starts to fail. This one seems to be a bit weird as well. Because when I just run that case it passed. I suspect the bot isn't reset as it should. Because the reason it failed is because it was starring at bedrock, while it should be nothing/NULL according to the test case.
The only remaining test case that is failing for sure is the trade one. But this one I haven't been able to figure out why.
Current error message it gives is:
Chunk size is 155 but only 132 was read ; partial packet : {"name":"trade_list","params":{"windowId":1,"trades":[{"inputItem1":{"itemCount":-91,"itemId":6,"addedComponentCount":1,"removedComponentCount":0,"components":[{"type":"max_stack_size","data":1111}],"removeComponents":[]},"outputItem":{"itemCount":0},"inputItem2":{"itemCount":0},"tradeDisabled":false,"nbTradeUses":0,"maximumNbTradeUses":16777216,"xp":201326592,"specialPrice":33554431,"priceMultiplier":-3.9316069277524514e+36,"demand":-855638016},{"inputItem1":{"itemCount":60,"itemId":805,"addedComponentCount":1,"removedComponentCount":0,"components":[{"type":"max_stack_size","data":854}],"removeComponents":[]},"outputItem":{"itemCount":0},"inputItem2":{"itemCount":0},"tradeDisabled":true,"nbTradeUses":-687341312,"maximumNbTradeUses":0,"xp":16777216,"specialPrice":201326592,"priceMultiplier":2.350988701644575e-38,"demand":0},{"inputItem1":{"itemCount":0},"outputItem":{"itemCount":0},"inputItem2":{"itemCount":0},"tradeDisabled":false,"nbTradeUses":10814977,"maximumNbTradeUses":113665,"xp":0,"specialPrice":1,"priceMultiplier":1.6815581571897805e-44,"demand":1},{"inputItem1":{"itemCount":0},"outputItem":{"itemCount":0},"inputItem2":{"itemCount":0},"tradeDisabled":false,"nbTradeUses":0,"maximumNbTradeUses":0,"xp":-1526333184,"specialPrice":28378624,"priceMultiplier":1.4816629312538453e-40,"demand":16777216}],"villagerLevel":0,"experience":0,"isRegularVillager":true,"canRestock":false}}; buffer :2d0104a506010001d70800000000000000010000000c00000001fffffffc3d4ccccd0000003ca506010001d606000001d708010000000000010000000c00000001000000000000000000000000a506010001bc0100000000000000010000000c00000001000000000000000000000000a506010001b1060000019d07010000000000010000000c0000000100000000000000000000000001000101
I am not really experienced with Javascript so I am not sure if I am looking into the right direction. If anyone knows why it is failing I would love to know how you found it out. Maybe I will be able to help a bit more next time :)
I dove a bit deeper today. When using the villager in the trade.js I get the following packed back:
{ "name": "trade_list", "params": { "windowId": 1, "trades": [ { "inputItem1": { "itemCount": 805, "itemId": 1, "addedComponentCount": 0, "removedComponentCount": 1, "components": [], "removeComponents": [ { "type": 1111 } ] }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 0, "maximumNbTradeUses": 16777216, "xp": 201326592, "specialPrice": 33554431, "priceMultiplier": -3.9316069277524514e+36, "demand": -855638016 }, { "inputItem1": { "itemCount": 60, "itemId": 805, "addedComponentCount": 1, "removedComponentCount": 0, "components": [ { "type": "max_stack_size", "data": 854 } ], "removeComponents": [] }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": true, "nbTradeUses": -687341312, "maximumNbTradeUses": 0, "xp": 16777216, "specialPrice": 201326592, "priceMultiplier": 2.350988701644575e-38, "demand": 0 }, { "inputItem1": { "itemCount": 0 }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 10814977, "maximumNbTradeUses": 113665, "xp": 0, "specialPrice": 1, "priceMultiplier": 1.6815581571897805e-44, "demand": 1 }, { "inputItem1": { "itemCount": 0 }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 0, "maximumNbTradeUses": 0, "xp": -1526333184, "specialPrice": 28378624, "priceMultiplier": 1.4816629312538453e-40, "demand": 16777216 } ], "villagerLevel": 0, "experience": 0, "isRegularVillager": true, "canRestock": false } }
Whats strange is that the itemCount and itemId are flipped for the inputItem1. Because the villager is asking for a emerald, which has Id 805, but according to the packed the itemId is 1.
The missing bytes is most likely because of the outputItem being empty, which should be filled with 1111 as itemId (pumpkin_pie). So I guess something is missing in the protocol. I am not sure why yet.
Check the definition of the packet providing that data. Sounds like some fields are missing there
On Sat, Oct 5, 2024, 11:13 Daan Smienk @.***> wrote:
I dove a bit deeper today. When using the villager in the trade.js I get the following packed back: { "name": "trade_list", "params": { "windowId": 1, "trades": [ { "inputItem1": { "itemCount": 805, "itemId": 1, "addedComponentCount": 0, "removedComponentCount": 1, "components": [], "removeComponents": [ { "type": 1111 } ] }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 0, "maximumNbTradeUses": 16777216, "xp": 201326592, "specialPrice": 33554431, "priceMultiplier": -3.9316069277524514e+36, "demand": -855638016 }, { "inputItem1": { "itemCount": 60, "itemId": 805, "addedComponentCount": 1, "removedComponentCount": 0, "components": [ { "type": "max_stack_size", "data": 854 } ], "removeComponents": [] }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": true, "nbTradeUses": -687341312, "maximumNbTradeUses": 0, "xp": 16777216, "specialPrice": 201326592, "priceMultiplier": 2.350988701644575e-38, "demand": 0 }, { "inputItem1": { "itemCount": 0 }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 10814977, "maximumNbTradeUses": 113665, "xp": 0, "specialPrice": 1, "priceMultiplier": 1.6815581571897805e-44, "demand": 1 }, { "inputItem1": { "itemCount": 0 }, "outputItem": { "itemCount": 0 }, "inputItem2": { "itemCount": 0 }, "tradeDisabled": false, "nbTradeUses": 0, "maximumNbTradeUses": 0, "xp": -1526333184, "specialPrice": 28378624, "priceMultiplier": 1.4816629312538453e-40, "demand": 16777216 } ], "villagerLevel": 0, "experience": 0, "isRegularVillager": true, "canRestock": false } }
Whats strange is that the itemCount and itemId are flipped for the inputItem1. Because the villager is asking for a emerald, which has Id 805, but according to the packed the itemId is 1.
The missing bytes is most likely because of the outputItem being empty, which should be filled with 1111 as itemId (pumpkin_pie). So I guess something is missing in the protocol. I am not sure why yet.
— Reply to this email directly, view it on GitHub https://github.com/PrismarineJS/mineflayer/issues/3406#issuecomment-2394991691, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAR437UWTGLQDRZNUQ5O333ZZ6UUNAVCNFSM6AAAAABJYG4R2KVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDGOJUHE4TCNRZGE . You are receiving this because you commented.Message ID: @.***>
Check the definition of the packet providing that data. Sounds like some fields are missing there
Yep I assumed the same. But as far as I can see nothing is missing.
I decompiled the 1.20.5 server jar and as far as my knowledge goes it should be correct. But I also didn't understand everything correctly in the code so it could be that I am wrong. I am truly at a dead end for me.
Best to comment issues with PR (#3412 ?) in the PR not this issue so it's easier to track where problems are
1.20.5 and 1.20.6 are protocol compatible, so they have the same protocol version. Since node Minecraft protocol resolves data by protocol version it will default to data from the top versionsByProtocol[version][0] version when loading data (yielding 1.20.6). This shouldn't be a problem since I added a data path mapping in mcdata for 1.20.6->1.20.5.
The item data format over the network changed so item handling may need to change.
