-
-
Notifications
You must be signed in to change notification settings - Fork 310
Proximity Checks when multiple objects are owned by the server #314
Comments
This feature is usually used to reduce overall networking-load by reducing the amount of packets that need to be send based on proximity. From my perspective tho it clashes a bit with this Networking Library as Forge instantiates everything automatically so the client always will have at least ALL This is hard to handle generally - moreso for people coming into networking. Even worse: those new people are tending to become confused when coding with Forge as they see the word "Proximity" in every corner of the library - even tho it is a specialized feature for a certain use-case. My suggestion would be to take a different route:
This would create less maintenance and dependencies for the core-library and with every new feature we wouldn't need to feel scared to "break that certain proximity-feature again". It also allows for more customization of Proximity - rather than dictate the feature via the core-library we can simply provide a "Proximity Example" that can be changed by the user/programmer. |
Happy for you to make those changes @k77torpedo 😉 |
Version Number and Operating System(s):
Latest master and develop
Currently proximity checks are done based on the sending and receiving player's proximity location.
This setup works fine if the server only owns one object. Eg. in a listen server setup where each client has one network object it owns.
This setup on the other-hand would not work if the server would own multiple objects as there is no easy way to set the correct proximity location in this case.
The text was updated successfully, but these errors were encountered: