That being the case, we naturally aspire to allow for customizing what functionality is enabled on a per-server basis. The question now, is how we go about that. Thus I will pose some ideas, my thoughts, and then try to get opinions of others, along with other ideas.
While this certainly is a good thought for customizability. One important factor with utilizing the JS engine is speed. We take a noticable performance hit when running a JavaScript rather than keeping things in the core system. While I think that packets should be on their own layer and in some way seperated from the core, I wouldn't advise having them running in the JS engine.Put all JS functionality into JS
This is a quick fix, and a relatively easy fix, but in the long run, I believe it will fall short. It would require seperate entries for every feature we wish to make toggleable, which could make for a very large bulk of additional code in the UOX.ini loading routines, along with a mass of entries that most users would never touch. Additionally it's sure not to allow for all the desired functionality, and there will always be requests for more (once you've opened the door, it's tough to shut).Add toggles to the UOX.ini
While this is similar to the first idea, it is certainly not the same. In this case we rely on the built-in functionality for Packet Handling, only overloading on a per-server basis at the users will. This would allow for any type of modification to any packet we can overload (all?, most?, only select ones?) even disabling it alltogether. This, of course, does require another layer between the core and sending / handling a packet, which may impact speeds a bit. But it would be relatively easy to implement, and for the normal user, would be an almost transparent change.Allow Overloading Packets via JS
This point is where we need thoughts, suggestions, other ideas. Would you like this functionality? Hate it? Requests on its ability? Responses welcome.
