After recent investigation into the OrionUO Client by Yukiko it raise my interest in some of these 3rd party clients/client injectors.
A few of them now support the server sending a custom packet to the client to disable certain client side features. OrionUO is a great example where it actually has a function that generates for you POL, Sphere or ServUO code to inject into your script base to support or disable certain functions of the server.
For POL it basically suggests injecting into the login and reconnect script a simple packet send function. Which got me thinking to sending a packet is something super simple that the core can do and could support easily with a config file.
My thoughts were along the lines of:
customclient.cfg
Code: Select all
Orion
{
option1 1
option2 0
}
Razor
{
option1 0
option2 0
}
Reasons For:
- Having native support might interest current OrionUO/Razor users towards POL(not so important)
- When you want to change a functionality you'd have to run the programs to get the packet data needed, update a script recompile and reboot. Native support would just require a CFG update and reboot.
- The cfg file is optional so if people want to script it or have it scripted already they won't be effected
- It can be done in scripts so the core shouldn't need to get involved.
- If items like OrionUO or Razor disappeared then the core is left with a functionality that is no longer needed.
- Core should mostly be to support OSI items and additional stuff should be done from script.
- A package could be written to do a script to inject the packets based on a config file.
- If OSI decides to use Orions packet for their own use the functionality is broken.
My responses to the Against arguments are below.
- It can be done in both, don't have the cfg file and you can code it into your scripts if you want.
- If they disappear then the old versions will still be aroudn and the core can still support them. Otherwise just delete the CFG file and drop support instantly.
- Core currently supports things like HTTPRequest, Aux Connections, JSON, SQL, all which aren't specifically OSI related?
- It could, and it still can, but core support with a single CFG file is easier to document and easier for noobs to implement.
- If OSI changed anything about the client the core is stuffed. We're constantly changing stuff in the code because of the way OSI functions, recent example is the opening of the paperdoll whilst mounted which now calls the double click macro rather than actually sending a click packet.
Thanks Again!