-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[WIP] Forge 1.7.10 support #7
Conversation
deathcap
commented
Feb 19, 2016
- Handle the ModIdData packet ([1.7] Accept the ModIdData packet in Forge 1.7.10 #3)
- but not parsing all the fields (out of scope, see Parse all fields of the RegistryData (1.8+) or ModIdData (1.7-) packets #2)
- Cleanup the version check (not hardcoding '1.7.10' string)
- Update to minecraft-data with 1.7 plugin channel data buffers are length-prefixed minecraft-data#117
- Test on large modded server pack http://www.feed-the-beast.com/modpacks (infinity evolved?)
- varshort [1.7] varshort for node-minecraft-protocol-forge #1
- Custom packets
Status: works with PrismarineJS/minecraft-data#117 against forge-1.7.10-10.13.4.1614 server (not tested with other 1.7.x versions, or any server with any mods installed), and also maintains compatibility with 1.8.9+ |
Tested with http://www.feed-the-beast.com/projects/ftb-infinity-evolved/files/2275596#additional-files FTBInfinityServer-2.3.5-1.7.10.zip
this is #1, the plugin channel packet: d2 c8 0f 3f 06 46 4d 4c 7c 48 53 e4 47 07 03 e4 42 1a 01 41 67 72 69 43 72 61 66 74 3a 63 72 6f 70 42 6f 74 61 6e 69 61 4c 69 6d 65 88 15 1c 01 68 61 ... 0xe447 is the 'short' length, readInt16BE() = -7097, negative, which is not used in vanilla but in Forge indicates the next byte (0x07) is also part of the length (high 8 bits, short is lower 15 bits):
|
Progress: with ProtoDef-io/node-protodef#52 + PrismarineJS/minecraft-data#120, able to connect to FTBInfinityServer-2.3.5-1.7.10.zip server. Receives a ton of custom payload messages, gets further. But then it crashes:
trying to read an unrecognized packet type! What to do with custom packets? (note: not "custom_payload" plugin channel messages, these are completely custom packets with their own IDs). Seeing what other projects do: PaperMC/Waterfall@312b3a7 Don't attempt to rewrite negative packet IDs Since the packets are all length-prefixed (at least in 1.7 and after), even if unknown they could be read in their entirety, just as opaque blobs. |
Looks like -26 (unsigned 230) is the only custom packet in FTB IE, at least on the initial connection. If I make this change to minecraft-data data/1.7/protocol.json:
then the client_forge example can login. According to http://forum.industrial-craft.net/index.php?page=Thread&postID=28216 "BadPackedID 230 = ModLoader MP isn't installed (properly)", but that's from 2011. Wonder what mod is using it still... Looks like its caused by: mods/CoFHCore-[1.7.10]3.0.3-303.jar - reproduces with only CoFHCore installed, nothing else. On the wire:
|
Packet -26 is definitely CoFHCore. Found the CoFHCore issue tracker: https://github.com/CoFH/Feedback/issues/415 Bad packet id -26 server https://github.com/CoFH/Feedback/issues/453 Use plugin messages rather than packets (?) [seems like a good idea..], "It's confirmed as a bug that negative ID packets were slipping past the guards on packet id. They [BungeeCord] should have a release out covering it soon." .. following the trail SpigotMC/BungeeCord#1437 [Forge] Bungee errors with CoFH packet, developer explains (& why it isn't using plugin channels):
https://github.com/CoFH/CoFHLib/blob/737cf7aee0a6de2559143ed63a8077fe40196813/src/main/java/cofh/lib/util/helpers/SecurityHelper.java#L237-L280 - [registered here](registered here https://github.com/CoFH/CoFHLib/blob/737cf7aee0a6de2559143ed63a8077fe40196813/src/main/java/cofh/lib/util/helpers/SecurityHelper.java):
|
This works decently well with PrismarineJS/minecraft-data#121, merging |