rob9315 / mcproxy

a minecraft proxy library powered by mineflayer

Hi there 👋

I'm a german student interested in programming.

mcproxy's Issues

World caching problems

(originally by @etiaro)

Hi,
I'm experiencing bugs with chunks caching:
blank textures: I found this one pretty interesting, as client knows where are blocks(and their types), just refuses to show textures for some reason. Sometimes enabling and disabling x-ray shows the textures, but when go to neighbour chunk and look away, the corrupted chunk becomes blank again. Also, mods like chest-ESP are showing positions correctly

Shifting chunks: on 2b2t's spawn, or the nether(so probably on chunks filled with much blocks), some of the chunks are getting shifted down. Seems like always y is subtracted by multiply of some number(I didn't count tbh). It's best visible in the nether, as the roof is flat bedrock. Almost all of broken chunk's roofs are on the same level, and a few looks like they've got shifted twice. Sometimes there's just one corrupted chunk, and sometimes there is whole line(2x8 was largest i saw), in some cases they're completely random, I can't see any pattern there.

I am running proxy on really low-cpu and low-RAM(1gb ram raspberry pi, arch linux) so maybe it somehow causes the problem.

[answer by @rob9315]

blank textures: I found this one pretty interesting, as client knows where are blocks(and their types), just refuses to show textures for some reason. Sometimes enabling and disabling x-ray shows the textures, but when go to neighbour chunk and look away, the corrupted chunk becomes blank again. Also, mods like chest-ESP are showing positions correctly

Ah yes, I know this one. This happens because of the way mineflayer calculates/caches light information, which gets out of sync whenever you change something and relog.

Shifting chunks: on 2b2t's spawn, or the nether(so probably on chunks filled with much blocks), some of the chunks are getting shifted down. Seems like always y is subtracted by multiply of some number(I didn't count tbh). It's best visible in the nether, as the roof is flat bedrock. Almost all of broken chunk's roofs are on the same level, and a few looks like they've got shifted twice. Sometimes there's just one corrupted chunk, and sometimes there is whole line(2x8 was largest i saw), in some cases they're completely random, I can't see any pattern there.

I have no clue though, what causes this.

I am running proxy on really low-cpu and low-RAM(1gb ram raspberry pi, arch linux) so maybe it somehow causes the problem.

I don't think that has anything to do with it, but good that you use arch BTW 1st_place_medal

TLDR: The lighting issue can be fixed, the PrismarineJS team was working on that already at some point, breaking a block should also fix it. The chunk shifting problem i have no clue why it happens or how to fix it, sorry.

[answer by @MrGeorgen]

related issues to the lighting problem:
PrismarineJS/mineflayer#591
PrismarineJS/prismarine-world#46

multi-version support

(originally by @czho)

Been using this library for a little while for one of the projects and cant for the life of me get it working on 1.16, like the 2b2t test server is on.
gives me this error when the proxyclient is connected:

TypeError: Serialization error for play.toClient : SizeOf error for undefined : Cannot read property 'length' of undefined at eval (eval at compile (/root/skynet-proxy/node_modules/protodef/src/compiler.js:245:12), <anonymous>:1069:39) at Object.packet_login (eval at compile (/root/skynet-proxy/node_modules/protodef/src/compiler.js:245:12), <anonymous>:1074:9) at eval (eval at compile (/root/skynet-proxy/node_modules/protodef/src/compiler.js:245:12), <anonymous>:2292:50) at packet (eval at compile (/root/skynet-proxy/node_modules/protodef/src/compiler.js:245:12), <anonymous>:2346:9) at CompiledProtodef.sizeOf (/root/skynet-proxy/node_modules/protodef/src/compiler.js:77:14) at e.message (/root/skynet-proxy/node_modules/protodef/src/compiler.js:84:40) at tryCatch (/root/skynet-proxy/node_modules/protodef/src/utils.js:50:16) at CompiledProtodef.createPacketBuffer (/root/skynet-proxy/node_modules/protodef/src/compiler.js:84:20) at Serializer.createPacketBuffer (/root/skynet-proxy/node_modules/protodef/src/serializer.js:12:23) at Serializer._transform (/root/skynet-proxy/node_modules/protodef/src/serializer.js:18:18) { field: 'play.toClient' }

and this error on the client side:

[answer by @rob9315]

different version support is theoretically planned, though i do not have much time right now. This still has the main purpose to be 2b2t compliant, and with that, 1.12.2 compliant. If you get it working, be sure to create a pull request. The problem is that there are major version differences between 1.12 and everything after it, it could be fixed with a lot of if statements somewhere or adding the option to select which version a server is running before connecting.

[answer by @czho]

oh ok, I get not having that much time, no worries. I was just confused, if I get 1.16 working on a fork of this, I will defiantly add it to this library. I get what you mean by major differences between versions, I've just seen alot of node-minecraft-protocol that automatically support newer version because of cross compatibility with that library.

Typescript compile issue

I'm having an issue compiling the lib for some reason. Its really confusing because this is the only lib like this that forces you to compile it instead of just including the /lib folder, why is it like this?

crash report:

> [email protected] postinstall C:\Users\3game\workspace\skynet-proxy\node_modules\mcproxy
> npm run build


> [email protected] build C:\Users\3game\workspace\skynet-proxy\node_modules\mcproxy
> tsc

../prismarine-item/index.d.ts:3:10 - error TS2724: '"prismarine-nbt"' has no exported member named 'Tag'. Did you mean 'Tags'?

3 import { Tag, TagType } from 'prismarine-nbt'
           ~~~

../prismarine-item/index.d.ts:11:10 - error TS2304: Cannot find name 'Tags'.

11     nbt: Tags[TagType] | null;
            ~~~~

../prismarine-nbt/typings/index.d.ts:52:26 - error TS7008: Member 'big' implicitly has an 'any' type.

52   export const protos: { big, little, littleVarint };
                            ~~~

../prismarine-nbt/typings/index.d.ts:52:31 - error TS7008: Member 'little' implicitly has an 'any' type.

52   export const protos: { big, little, littleVarint };
                                 ~~~~~~

../prismarine-nbt/typings/index.d.ts:52:39 - error TS7008: Member 'littleVarint' implicitly has an 'any' type.

52   export const protos: { big, little, littleVarint };
                                         ~~~~~~~~~~~~

../prismarine-nbt/typings/index.d.ts:63:19 - error TS7010: 'parse', which lacks return-type annotation, implicitly has an 'any' return type.

63   export function parse(data: Buffer, little: boolean, callback: (err: Error | null, value: NBT) => any);
                     ~~~~~

../prismarine-nbt/typings/index.d.ts:65:19 - error TS7010: 'parse', which lacks return-type annotation, implicitly has an 'any' return type.

65   export function parse(data: Buffer, nbtType: NBTFormat, callback: (err: Error | null, value: NBT) => any);
                     ~~~~~

../prismarine-nbt/typings/index.d.ts:67:19 - error TS7010: 'parse', which lacks return-type annotation, implicitly has an 'any' return type.

67   export function parse(data: Buffer, callback: (err: Error | null, value: NBT) => any);
                     ~~~~~

Weather caching

(originally by @etiaro)

After relog I don't see the rain. It would be nice to send it to client too

Crashing after reconnecting too many times

(originally by @MrGeorgen)

themoonisacheese/2bored2wait#269

[answer by @rob9315]

Needs a try statement somewhere to prevent crashing with (incomplete packets?)

[answer by @MrGeorgen]

mcproxy/src/conn.ts

Line 119 in be18df0

entityId: (this.bot.entity as any).id,

this is the line the error belongs to. However should not bot.entity always
be defined? And if it is not, I guess there is not really a way to send the
client proper data.

[answer by @rob9315]

It should always be defined, but it seems that when you call it too early or the client is being declined, it crashes. I think there needs to be a check in place to determine if the client isn't being declined, which I think is the case. (Or one try statement around sendPackets)

Loopback for multiple clients

When the linked client (or bot) send packets to the server, attached clients don't get the update. This is highly version dependent.

• position and view angle
• inventory (automatically through server responses?)
• more?

There is no caching of entity data

When joining the proxy, it doesn't cache entity data, pretty self explanatory.

Update to 1.19?

Hey, since 2b2t just updated from 1.12.2 to 1.19 I was wondering if you had plans/if you are able to update this to 1.19 as I have this as a dependency for my project? Thanks

cache craftbook unlock packets

(originally by @MrGeorgen)

Bigger API PleaZe!

It will make this more popular!

block actions not implemented (chests don't render etc)

Add examples

Add an example to the repo so people know how to use this in their projects.

• basic example
• multi-client example
• custom events example