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

Compatibility w/ OldCombatMechanics #7

Open
lowercasebtw opened this issue Oct 4, 2024 · 9 comments
Open

Compatibility w/ OldCombatMechanics #7

lowercasebtw opened this issue Oct 4, 2024 · 9 comments

Comments

@lowercasebtw
Copy link

Is this compatible with the OldCombatMechanics plugin?

Side Note: I noticed that gravity was hardcoded in the math util class, why doesn't it use/take into count the server entity gravity attribute as gravity is a entity attribute now

@CASELOAD7000
Copy link
Owner

I have not tested the compatibility with the mentioned plugin, you're free to do so yourself. the gravity attribute edgecase is a good suggestion, although i'm unsure what pvp servers would change that

@Axionize
Copy link
Collaborator

Axionize commented Oct 5, 2024

I've added support for handling the gravity attribute in 1.20.5 and up.

#9

@TheobaldTheBird
Copy link

TheobaldTheBird commented Oct 5, 2024

/tick rate is another interesting edge case, looks like Spigot API doesn't have anything for it yet though

@Axionize
Copy link
Collaborator

Axionize commented Oct 5, 2024

It wouldn't be that hard to add support for /tick rate but if we're going to do it we might as well do it properly, and doing it properly means accountings for tick skipping. This of course would be a nightmare until 1.21.2 is released with the changes in https://www.minecraft.net/en-us/article/minecraft-snapshot-24w36a and even then we would have to support older clients.

To properly account for that you need a latency compensated internal model of the world per player

This would also allows us to solve

But that point you might as well just make the entire plugin a GrimAC module...

@lowercasebtw
Copy link
Author

Is the knockback code abstracted from the core of the plugin? If not, I think it should be allowing other plugins to change knockback if they want, because OldCombatMechanics has its own knockback (1.8 knockback) which could interfere with this code, but if it was abstracted, it would allow other plugins (OldCombatMechanics) to hook into it and modify the knockback logic, and or just addon plugins if (OldCombatMechanics) weren't to integrate it

@lowercasebtw
Copy link
Author

^

@Axionize
Copy link
Collaborator

Axionize commented Oct 16, 2024

After some testing and digging around in code I can confirm OldCombatMechanics overwrites the effects of KnockBackSync.

We would need to reimplement OldCombatMechanic's legacy Knockback behaviour and add our corrections on top of it with a config option to enable old kb.

@lowercasebtw
Copy link
Author

@kernitus
Copy link

After some testing and digging around in code I can confirm OldCombatMechanics overwrites the effects of KnockBackSync.

We would need to reimplement OldCombatMechanic's legacy Knockback behaviour and add our corrections on top of it with a config option to enable old kb.

In what way is this the case? OCM listens to the PlayerVelocityEvent on lowest priority, meaning it comes in and sets the velocity first - it looks like it's knockback sync which is overwriting the velocity.

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

No branches or pull requests

5 participants