k77torpedo
commented
4 years ago 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 NetworkBehaviors instantiated fully and only after that does the current Proximity-Feature reduce the amount of packets.
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:
- Remove the Proximity-Feature from the core-library altogether. It's simply clutter and creates too much confusion.
- Instead provide a new "Proximity Example" with simple
ProximityReceiver- andProximityEmitter-NetworkBehaviorsthat equally can do the job of the current system.
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.
phalasz
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.