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
Opens up NTR for possible features such as network LOD/IM.
NTU already supports this.
Desynchronisation of position can happen if both sides have miss-matched values, but this PR at least is a step towards the right direction of the feature.
JesusLuvsYooh
changed the title
feat: NetworkTransformReliable to allow runtime changing of sendIntervalMultiplier
feat: NetworkTransformReliable to allow partial support of runtime changing sendIntervalMultiplier
Aug 8, 2024
Desynchronisation of position can happen if both sides have miss-matched values, but this PR at least is a step towards the right direction of the feature.
We can't merge this if it accidentally breaks people's projects
Desynchronisation of position can happen if both sides have miss-matched values, but this PR at least is a step towards the right direction of the feature.
We can't merge this if it accidentally breaks people's projects
It does not break projects, it won't do anything to previous or current users that do not intentionally try to change sendIntervalMultiplier during runtime.
Currently in master, if someone does change sendIntervalMultiplier during runtime, the entire movement just stops, and never works again.
(the counter variable has gone too high, and needs to be == to reset, we're just checking if counter is equal or higher to cover this >= )
With this PR, movement works again if changed during runtime, how well it works is spotty due to the nature of delta feature.
It does not break projects, it won't do anything to previous or current users that do not intentionally try to change sendIntervalMultiplier during runtime.
I agree to this too.
This change should logically prevent any accidental runtime changes to sendIntervalMultiplier from causing issues, without affecting existing projects. I haven't tested it myself, but it looks like it should only impact situations where someone intentionally modifies sendIntervalMultiplier during runtime.
How well it works might still be a bit hit or miss due to the delta feature idk :3
I mean the tests say its okay >.<
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
As discussed here:
https://discord.com/channels/343440455738064897/1270795122279186484/1271231586519486485
Opens up NTR for possible features such as network LOD/IM.
NTU already supports this.
Desynchronisation of position can happen if both sides have miss-matched values, but this PR at least is a step towards the right direction of the feature.