-
Notifications
You must be signed in to change notification settings - Fork 421
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Avoid serializing object-based payload into PacketByteBuf
on the main thread
#3407
Conversation
Does this add a way to enable serialization for singleplayer, for example in dev? |
No, is it really needed? If you want to check for serialization you can always run the server. |
Not true anymore, it will now convert between the two accordingly. Still, should it really do so? |
I think by default it should always serialise when in dev, with a system property to control the behaviour. |
...g-api-v1/src/main/java/net/fabricmc/fabric/mixin/networking/CustomPayloadC2SPacketMixin.java
Outdated
Show resolved
Hide resolved
8cf5c72
to
3573e5a
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR is looking good now, I just want to test it out myself next. One small thing regarding the logging around the new system prop.
if (FORCE_PACKET_SERIALIZATION) { | ||
LOGGER.warn("Force Packet Serialization is enabled"); | ||
if (FabricLoader.getInstance().isDevelopmentEnvironment()) LOGGER.warn("This is the default on dev env"); | ||
LOGGER.warn("Disable it with -Dfabric-api.networking.force-packet-serialization=false"); | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Im not sure these need to be warning levels, or logged at all in development tbh.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How does one know to disable the serialization then? I guess most devs won't need to be concerned about this but still.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would imagine that 99% of people wont care about this. A single .info log line would be fine, people see warnings and think they have done something wrong. Whats here makes it sound like it should be disabled not that it can be disabled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why would one want to disable it in the first place? ... ;)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To make sure it doesn't bug on singleplayer, because of improper/not using copy of an object?
I will initally release this as a beta, many thanks for sorting this. 👍 |
Resolves #3335
On local connection (singleplayer),
ResolvedPayload
instances will be used directly, bypassing the serialization altogether.On remote connection, the sender sends a
ResolvedPayload
instance. The receiver then receives aPacketByteBuf
that gets retained and wrapped intoRetainedPayload
. This doesn't create a new buffer, unlike the current implementation.Then the receiver checks for instance of
ResolvablePayload
and resolves it intoResolvedPayload
if it's not yet as such.TypedPayload
,PacketType#read
will be called.UntypedPayload
, the buffer fromRetainedPayload
will be copied into a new one.Then the handler for the payload will be called as usual.