Closed Sonic2423 closed 2 weeks ago
Velocity enforces the vanilla limit for known packs. You can set your own limit using this system property. This is to prevent overloading Velocity. View #1303 for details.
That solves the issue for me. My suggestion would be a log message to increase max-known-packs to the read amount, a config option or referring to a section in the docs, if the backend server is modded, because it is not immediately clear to the velocity admin/user what exactly went wrong without enabling packet decode logging and looking into the velocity source, if they are even capable to do that. This would be a common occurence for modded servers behind velocity and has lead to a bug report on my project.
As it's a vanilla limit, I doubt this will be made into a config option and will likely remain hidden behind an system property. Additionally, because it's a "protection", I don't think it should be logged without debug parameters. However, I believe adding a page for hidden system properties to the documentation would be a good addition.
True, as Velocitys main goal is not modded support and this bahaviour is intentional. I will take care of future related issues by trying to educate the user on my side as i am the cause for them and the docs have been made availaible.
Expected Behavior
Successful config phase.
Actual Behavior
"too many known packets" (213 packets with ATM10)
Steps to Reproduce
1.21 ATM10 NeoForge Server and Client No forwarding (for testing) Try to login
Plugin List
None
Velocity Version
Velocity 3.3.0-SNAPSHOT (git-00ed2284-b415) Copyright 2018-2023 Velocity Contributors. Velocity ist lizenziert unter den Bedingungen der GNU General Public License v3. velocitypowered.com - GitHub
Additional Information
When removing the limit it seems to work fine (haven´t tested extensively, but it gets past the config phase). When running with NeoForwarding (CrossStitch embedded) i can then also login with modern forwarding and play.