You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The way Nitrox uses the game code is for both functionality and to know when the game does something (to then signal the interesting parts of data to the server). This however becomes a problem when Nitrox causes game APIs to be called instead of the original game flow, leading to wrong/redundant signalling to the server.
To fix the problem PacketSuppressor<TPacket> API was created. This blocks the client from sending a packet type by wrapping (patched) game APIs in a using block. But packet suppression is easy to do wrong, so an automated way would be a good Quality of Life feature for development.
Implementation steps
Generate a call hierarchy of the game functions via an MSBuild task using cecil or dnlib.
Find patched game function symbols from Nitrox code.
Group results of step 1 and 2 so that for every call to game code we know which packet types are being send.
Generate interceptors on the calls to (patched) game code to be replaced with a wrapped packet suppression block of every packet type that could be called based on context.
Tools to use for each step
MSBuild task to generate a file with the entire game call hierarchy. Only needs to be generated once if game DLL isn't changing.
Source generator to inspect our code for patches and which game function they patch. But only if they are sending packets. The generated file from the MSBuild task should be included in this source generator as "additional text files"
Within the same source generator, group the results so we know which packets are being send in the entire call hierarchy of the game.
Within the same source generator, generate interceptors on calls made on patched game functions. The interceptor should redirect it to a wrapped call using a PacketSuppressor which will suppress the appropriate packets. Note that only the Nitrox Client project should have packet suppression.
Issue
The way Nitrox uses the game code is for both functionality and to know when the game does something (to then signal the interesting parts of data to the server). This however becomes a problem when Nitrox causes game APIs to be called instead of the original game flow, leading to wrong/redundant signalling to the server.
To fix the problem
PacketSuppressor<TPacket>
API was created. This blocks the client from sending a packet type by wrapping (patched) game APIs in ausing
block. But packet suppression is easy to do wrong, so an automated way would be a good Quality of Life feature for development.Implementation steps
Tools to use for each step
PacketSuppressor
which will suppress the appropriate packets. Note that only the Nitrox Client project should have packet suppression.Resources to help with implementation
The text was updated successfully, but these errors were encountered: