Causing Velocity to fail if TConstruct is present at backend

Question

Causing Velocity to fail if TConstruct is present at backend

Neubulae opened this issue 3 years ago · 14 comments

Neubulae commented 3 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:

CrossStitch 0.1.4
FabricProxy-Lite 1.1.6

Frontend:

No plugin.

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 · Answer 1 · 2024-03-02T01:30:19.000Z

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

Neubulae · Answer 2 · 2022-08-16T20:32:17.000Z

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

AlphaMode · Answer 3 · 2022-08-16T20:29:27.000Z

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

AlphaMode · Answer 4 · 2022-08-16T20:30:05.000Z

Can you send the client log please

unilock · Answer 5 · 2022-08-17T00:14:43.000Z

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 · Answer 6 · 2022-08-17T06:02:26.000Z

@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 · Answer 7 · 2022-08-17T11:19:14.000Z

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 · Answer 8 · 2022-08-17T11:43:05.000Z

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 · Answer 9 · 2022-08-17T20:47:06.000Z

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 · Answer 10 · 2022-12-21T12:06:41.000Z

Can confirm this issue.

unilock · Answer 11 · 2023-02-08T19:34:38.000Z

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 · Answer 12 · 2023-02-08T17:24:47.000Z

@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 · Answer 13 · 2023-02-08T19:04:23.000Z

@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 · Answer 14 · 2023-02-09T16:16:54.000Z

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?

Share to