## feature: Implement Apply Shader Packet

[RazorPlay01]

This commit introduces a new packet ApplyShaderPacket to manage shader application from the server.

• Adds a new ApplyShaderPacket record, implementing CustomPayload and including its codec for encoding and decoding.
• Registers the packet for both client-to-server and server-to-client communication.
• Implements the packet handling logic on the client side, allowing for applying and clearing shaders.

This addition allows for dynamic shader management from the client, enhancing the flexibility and responsiveness of the shader system.

[RazorPlay01]

I don't know why it appears to modify all the code of the SouperSecretSettingsClient class when I only added a new method

[Nettakrim]

this can largrly be acheived already using one of my other mods https://modrinth.com/mod/client-execution

[Nettakrim]

however once i do the complete rewrite of soup i have planned, a similar thing may be useful since shader stacks will have a lot more complexity

[Nettakrim]

it might be more elegant though if it was handled through a combination of resourcepacks and client execution

[RazorPlay01]

this can largrly be acheived already using one of my other mods https://modrinth.com/mod/client-execution

I noticed that with this mod you require that the mod be on both the server and client side. With the implementation that I make, you do not need anything specifically from the server, therefore you could use either a mod or a plugin, which was my case.

Ps: I already optimized the code a bit because it didn't support shader stacking

[RazorPlay01]

The idea for this to be complete would be to implement another packet which sends the list of shaders loaded on the client to the server in order to avoid the server applying an unloaded shader.

[RazorPlay01]

I will probably do it in the future, but currently with the modifications I made I am fine for what I need.

[RazorPlay01]

The idea for this to be complete would be to implement another packet which sends the list of shaders loaded on the client to the server in order to avoid the server applying an unloaded shader.

Well, it was free, I implemented the necessary code for it.

[Nettakrim]

client execution only needs to be on the server for the command, it should work on client for just the packets

but yeah it cant do anything client-to-server so for that youd want packets on soups side

[Nettakrim]

on one hand theres no reason for me not to merge this, but on the other hand, next week im going to completely rewrite soup, so this will become immedietly obsolete

ofc the rewrite will act largely the same, but i can forsee a few things that will make the packet require slightly different information, so i dont think it will really be backwards compatible

the main thing in favour of merging is the fact that the rewrite will be for 1.21.2, and likely wont be backported (due to the shader changes), so this wouldnt be obsolete for its version

[RazorPlay01]

I noticed that they made changes to the shaders for 1.21.2, but I'm still leaving the code free in case someone else needs it at some point.

[RazorPlay01]

I recommend you use my packet encode/decode because according to tests I did since the change that was made to custom payloads, the decoding of strings sent from bukkit does not work correctly.

[RazorPlay01]

This way you could continue using only the mod on the client but with the possibility of managing the shaders from the server, whether for plugins or mods, with which you simply send the necessary packets and the mod will take care of the rest.

[Nettakrim]

I recommend you use my packet encode/decode because according to tests I did since the change that was made to custom payloads, the decoding of strings sent from bukkit does not work correctly.

huh thats interesting, would that break both your and client executions packet?

or do you decode the shader name differently?

[Nettakrim]

This way you could continue using only the mod on the client but with the possibility of managing the shaders from the server, whether for plugins or mods, with which you simply send the necessary packets and the mod will take care of the rest.

the thing thats a bit weird is that the way soup is currently structured makes it fundamentally hard for multiple mods to be using its features simultaneously (i plan to fix this in my rewrite)

having a packet only implemented in a specific version that gives incomplete control over soup seems like bad practice

[Nettakrim]

thats not to say it wouldnt be useful, just that its weird to have such a feature with the rewrite on the horizon anyway

ideally client execution would be able to handle everything, if it cant currently that is an issue with it, not soup

[RazorPlay01]

I recommend you use my packet encode/decode because according to tests I did since the change that was made to custom payloads, the decoding of strings sent from bukkit does not work correctly.

huh thats interesting, would that break both your and client executions packet?

or do you decode the shader name differently?

code and decode both on the client and server side using getBytes of any string using the StandardCharsets.UTF_8 charset since after many tests trying to use the packetcodec that they added new with the networking changes it works well between the communication between mods but not between plugins and mods