-
Notifications
You must be signed in to change notification settings - Fork 450
fix: remove auto-send animation parameters #1746
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
Conversation
3538bd7
to
01f0be5
Compare
01f0be5
to
c2e75b7
Compare
* get replicated on a regular basis regardless of a state change. The thinking | ||
* behind this is that many of the parameters people use are usually booleans | ||
* which result in a state change and thus would cause a full sync of state. | ||
* Thus if you really care about a parameter syncing then you need to be explicit |
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.
Unfortunately I can't ask Andrew what he meant by "if you really care", but apart from adding redundancy to cover unreliable delivery (which we don't use for this), the only scenario I can think of here is if you could go from state A to state B and back to state A all between 2 sequential FixedUpdate calls (and also not using our SetTrigger), in which case we wouldn't pick it up and the connected players would stay on 'A' missing the ultra-short 'B' transition.
{ | ||
if (m_CachedAnimatorParameters == null) |
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.
this can never be null
public override void OnInspectorGUI() | ||
{ | ||
Init(); |
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.
Doesn't seem worth it to me to go to the trouble of tracking init and not re-drawing. This isn't remotely performance noticeable, and makes the code harder to grok.
This autoSend parameter feature was a bit of a mystery. After doing some digging this turns out to be something inspired by HLAPI. The best I and folks like @larus can tell, this "force parameter sync unconditionally" option might help were we to be transmitting this in an unreliable fashion, which we aren't (and even if we were, we'd use some other mechanism).
All things considered I can't find a good reason for this feature to live on / update. It has confused users who understandably but wrongly conclude the NetworkAnimator checkboxes mean "if you want this parameter, sync this"
Even more info is found in MTT-2530