search

Alpha-s-Stuff / TinkersConstruct

Tinker a little, build a little, tinker a little more...
MIT License
86 stars 31 forks source link

Causing Velocity to fail if TConstruct is present at backend #18

Closed Neubulae closed 8 months ago

Neubulae commented 2 years ago

Minecraft Version

1.18.2

Fabric/Quilt Version

0.14.9

Fabric/Quilt API Version

0.58.0-1.18.2

Tinkers' Construct Version

commit 33b3fef

Describe your issue

If TConstruct is present at the backend, Velocity fails to decode packet. Detailed here, with exactly the same log message.

Crash Report

No response

Other mods

Backend:

Frontend:

Tried reproducing with just Tinkers?

Yes

Performance Enchancers

Sodium

Searched for known issues?

Checked pinned issues, Searched open issues, Searched closed issues, Checked the FAQ

AlphaMode commented 2 years ago

The log you provided doesn't seem to state anything to do with tinkers or any of its dependencies

AlphaMode commented 2 years ago

Can you send the client log please

Neubulae commented 2 years ago

The client log doesn't supply any useful information as it seems, but here it is

unilock commented 2 years ago

Could you try using this build of CrossStitch with the following in a new file in your config directory, named crossstitch-overrides.json?

[
    "minecraft:slot_type",
    "minecraft:tool_stat",
    "minecraft:modifier",
    "minecraft:material",
    "brigadier:slot_type",
    "brigadier:tool_stat",
    "brigadier:modifier",
    "brigadier:material"
]

This is where TConsuct's command stuffs are registered, which should be correct given the resourceString() method. If the above JSON file solves the issue, though, then something's going wrong with those registrations. Well, as far as I can tell, at least.

Neubulae commented 2 years ago

@unilock It doesn't work, and from the dump provided on that issue these are succesfully registered as tconstruct:..., that's why this is so weird.

unilock commented 2 years ago

Could you provide your Velocity log of when you try to connect? ~~I'm thinking it's not TConstruct at fault here. Could you also provide your mod list?~~ Nevermind, I see you're testing with only TConstruct installed. Looking through your dump, I see no arguments incorrectly tied to the minecraft: nor brigadier: namespaces.

Neubulae commented 2 years ago

Could you provide your Velocity log of when you try to connect? ~I'm thinking it's not TConstruct at fault here. Could you also provide your mod list?~ Nevermind, I see you're testing with only TConstruct installed. Looking through your dump, I see no arguments incorrectly tied to the minecraft: nor brigadier: namespaces.

the log is exactly the same as yours provided, tho if you really want mine I'll provide one later

Neubulae commented 2 years ago

The velocity log and a newer dump with only TConstruct. Again, only TConstruct and necessities listed are present on server, and the client has only TConstruct.

Zensonaton commented 1 year ago

Can confirm this issue.

unilock commented 1 year ago

@Neubulae @Zensonaton If you're still having this issue, try this in crossstitch-overrides.json:

[
    "tconstruct:slot_type",
    "tconstruct:tool_stat",
    "tconstruct:modifier",
    "tconstruct:material"
]

It would be very strange if that worked, but I'm not sure what else to try.

If it doesn't work, we can try gathering and deciphering network packet debug logs from the client + velocity + backend server, but we'll cross that bridge when we get to it.

Neubulae commented 1 year ago

@Neubulae @Zensonaton If you're still having this issue, try this in crossstitch-overrides.json:

[
    "tconstruct:slot_type",
    "tconstruct:tool_stat",
    "tconstruct:modifier",
    "tconstruct:material"
]

It would be very strange if that worked, but I'm not sure what else to try.

If it doesn't work, we can try gathering and deciphering network packet debug logs from the client + velocity + backend server, but we'll cross that bridge when we get to it.

iirc this is tried a long time ago. I have sent logs to Discord server but never got a reply. I am using a self-compiled build of Velocity to circumvent this problem.

unilock commented 1 year ago

iirc this is tried a long time ago. I have sent logs to Discord server but never got a reply. I am using a self-compiled build of Velocity to circumvent this problem.

What changes did you make to Velocity? In case someone else runs into this issue in the future.

unilock commented 1 year ago

I think I found the root of the problem: slimeknights.tconsruct.shared.common.subcommand.GeneratePartTexturesCommand registers an argument "mod_id" of type net.minecraftforge.server.command.ModIdArgument, which apparently Velocity can't handle.

Relevant line: https://github.com/Alpha-s-Stuff/TinkersConstruct/blob/1.18.2-new/src/main/java/slimeknights/tconstruct/shared/command/subcommand/GeneratePartTexturesCommand.java#L31

I fixed this by swapping ModIdArgument.modIdArgument() with ResourceLocationArgument.id() and context.getArgument("mod_id", String.class) with String.valueOf(context.getArgument("mod_id", ResourceLocation.class)) (the latter under GeneratePartTexturesCommand#runModId).

https://github.com/unilock/TinkersConstruct/commit/6c0031ddb041b165a1df67620c78fbc83d40ceb9#diff-75d211aa94dbe5cdb94c7e1122ca3f93bc9ef48d30596373d893bc7d4d304f6d

I get the following in chat when executing e.g. /tconstruct generate_part_textures all tconstruct:amethyst_bronze:

[10:49:17] [Render thread/INFO]: [CHAT] Started generating part textures
[10:49:17] [Render thread/INFO]: [CHAT] No material's have generator info, nothing to generate

...but I think that's expected?

AlphaMode commented 8 months ago

This is actually a issue a upstream issue, and should already have been fixed