Skip to content
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

A LagCompensator Revamp #3770

Open
wants to merge 9 commits into
base: master
Choose a base branch
from

Conversation

Amph1dian
Copy link

@Amph1dian Amph1dian commented Feb 26, 2024

Current Lagcompensator:

Supports box colliders,
Supports position & scale compensation.
Supports primitive movement systems.
Uses performance intensive methods. (addcomponent, destroy, instantiate, raycast)
Easy to script.
Very easy to implement.

Revamped Lagcompensator:

Supports any 3d collider type, including ragdoll rigs.
Supports position, rotation, and animation compensation.
Supports complex movement systems.
Optimized.
Easy to script.
May need refactoring to implement.

Animation Tracking & Compensation has been added. Note that it doesn't track or compensate for Blend Tree variables, that would be very hard to automate. you would have to manually set these in the compensated animator via script. OR edit the Lagcompensator to implement & interpolate these in Capture3d.

Usage is pretty simple, create dummy player with only trigger colliders. parent said dummy and the actual player under a main player GameObject. (may need refactoring). There's probably be a way to do this without parenting, not sure. Make sure to disable this by default, as it will be enabled when necessary by the server.

then just fill in the "tracked" fields with your actual player, and "compensated" fields with dummy player. the separated position / orientation variables are there for more complex player movement systems.

Animator compensation is optional.

Now you have 2 options for implementation, The first and easier version, await UpdateColliders(). you just put this before you Raycast in your servers Fire function. This also awaits a task inside of the function, not sure if its redundant.

Second and more performant option, UpdateTargetCollider() and DisableColliders() work together. DisableColliders() goes at the end of your servers fire function. Then UpdateTargetColldier gets called if the client hits a player with their local raycast. NOT the server. i think the best way to add this is to add a NetworkConnectionToClient target to your servers fire function, then calling await UpdateTargetColldier(target) before your servers raycast, if the target is not null.

@Amph1dian
Copy link
Author

Amph1dian commented Feb 26, 2024

This could work in a similar way as mischa's version, only updating if the client hit the collider on their screen. it would decrease firing overhead, as your not always hitting a player, and thus dont need to update the colliders every time you shoot. however it would require more scripting from the user, as the user would need to add a different command to the clients fire function to update the collider.

^ added as UpdateTargetCollider() and DisableColldiers().

Only thing left to do is add 2d support, I think that would warrant a different script? like LagCompensator2d?
Although maybe it doesn't matter if its in 2d or 3d, if you set it up the same.

Amph1dian and others added 5 commits February 26, 2024 10:33
…end trees. This is impossible to automate, and has to be added manually by the user.
…mpensatorrevamp

# Conflicts:
#	Assets/Mirror/Components/LagCompensation/LagCompensator.cs
…sed if you want greater perf at the cost of more manual scripting.
@TUTTIK-FRUTTIK
Copy link

I suggest using [ServerCallback] for Update()

@Amph1dian
Copy link
Author

I suggest using [ServerCallback] for Update()

Wouldn't [Server] be better? Only difference on the docs is that it doesn't throw an error if a client calls the method, but all of the methods shouldn't be called on the clients anyways? I've only ever used [Server] myself, so I'm not sure.

@MrGadget1024
Copy link
Collaborator

MrGadget1024 commented Mar 15, 2024

I suggest using [ServerCallback] for Update()

Wouldn't [Server] be better? Only difference on the docs is that it doesn't throw an error if a client calls the method, but all of the methods shouldn't be called on the clients anyways? I've only ever used [Server] myself, so I'm not sure.

Have to use [ServerCallback] for Unity methods because Unity will call them in all contexts and we don't need the warning flood.

@Amph1dian
Copy link
Author

Amph1dian commented Mar 15, 2024

Have to use [ServerCallback] for Unity methods because Unity will call them in all contexts and we don't need the warning flood.

Ah that makes sense. For some reason I thought the original guy meant swapping [Server] to [ServerCallback] on the Update methods I added, and not unity's one.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants