Reasoning

There are many bugs in the game that would create an unfair advantage or server-client desyncs. If I was to implement these fixes, I would want this to be explicit permission from server owners.

How it'd work (subject to change)

• Server owners would have to enable these set of bug fixes explicitly, one by one.
• Server would send a packet to the client. NOT the other way around. Only then would the client send any packets to the server (if necessary, probably not) This is to prevent servers from blocking the mod for whatever reason. (Verification could be the other way on Forge, as the client sends a mod list anyway)
• If the client receives one of these packets it would contain each individual bug fix to whitelist for the client. This would be stored till world switch where rules may change. (Though this alternate behaviour would not be implemented in debugify.
• Most if not all of these fixes would be disabled by default.

Concerns

• Increases scope of the project quite substantially. This mod turns from a large library of small (mostly) gameplay independent fixes to big, potentially controversial fixes.
• Would require Fabric API. Debugify (on the server at least) boasts no dependencies. Is it worth getting rid of this?

Potential Alternatives

Maybe a sister mod debugify-gameplay (name subject to change) could include these features (with server verification) as to not pollute the base mod.

I would love some feedback on this. As it's quite a big change.

Everyone uses fabric API, not a big deal

Sister mod sounds like a better idea than controversy
What would these "gameplay modifying fixes be" so much that it could be an advantadge? Could you give examples? Isn't the whole point of the mod to fix "obscure" and "forgotten" bugs, not big game changing ones that could ruin reputation

"Server would send a packet to the client. NOT the other way around. Only then would the client send any packets to the server (if necessary, probably not) This is to prevent servers from blocking the mod for whatever reason. (Verification could be the other way on Forge, as the client sends a mod list anyway)"

This just sounds messy, and it's debatable whether a server would support this rather than just blocking it, they might not even know this feature exists, and just block the mod that's doing weird shit on their server

I didnt realize github did > like that so pretend that was all nicely formatted

Everyone uses fabric API, not a big deal

Sister mod sounds like a better idea than controversy What would these "gameplay modifying fixes be" so much that it could be an advantadge? Could you give examples? Isn't the whole point of the mod to fix "obscure" and "forgotten" bugs, not big game changing ones that could ruin reputation

"Server would send a packet to the client. NOT the other way around. Only then would the client send any packets to the server (if necessary, probably not) This is to prevent servers from blocking the mod for whatever reason. (Verification could be the other way on Forge, as the client sends a mod list anyway)"

This just sounds messy, and it's debatable whether a server would support this rather than just blocking it, they might not even know this feature exists, and just block the mod that's doing weird shit on their server

For example:

• MC-2071 - For some clients to do this while others don't would be an unfair advantage (server verification required)
• MC-1133 - This fix would need to be implemented on both the client and the server and would be a slight unfair advantage (server verification required)

Why would I not just use Carpet-Fixes? It has more fixes that are made for the server environment and made by a technical Minecraft player. There's no point if you can't offer anything better.

The bug fixes that Debugify would address would be different. While carpet-fixes purely fixes server-side bugs, Debugify could fix a client-only bug that may cause an unfair advantage (hence verification from server.)

It would indeed make sense for the server to tell, which client-server bugs can be fixed, otherwise only apply those on singleplayer.

I think requiring Fabric API server-side is okay, and so is splitting a separate mod out of Debugify if desired (perhaps current one becomes Debugify Client and the new one Debugify Server?).

Increases scope of the project quite substantially. This mod turns from a large library of small (mostly) gameplay independent fixes to big, potentially controversial fixes.

I don't see how this change on its own increases the scope of the project. It only increases it if you decide to add such new bugfixes?

Why would I not just use Carpet-Fixes? It has more fixes that are made for the server environment and made by a technical Minecraft player. There's no point if you can't offer anything better.

I am going to create a new branch and develop an implementation for this. I am going to use the idea of the sister mod for this.

Why would I not just use Carpet-Fixes? It has more fixes that are made for the server environment and made by a technical Minecraft player. There's no point if you can't offer anything better.

Does it fix all the bugs that Debugify does?

Actually, you wouldn't need Fabric API, as always, you could just do some Mixin magic.
Or, you could shade in the networking module somehow, but I don't know much about architectury loom.

Server would send a packet to the client. NOT the other way around.

One thing to note: if you register a listener on the client, FAPI will tell the server that it can receive that message

Server would send a packet to the client. NOT the other way around.

One thing to note: if you register a listener on the client, FAPI will tell the server that it can receive that message

Ah that's annoying. I guess there is no need for secrecy.

Hm, if that's a problem, the mixin thing could work. Although I don't understand why it would be.