POL100 - 3rd Party Feature Request.

[DevGIB]

Firstly, there isn't a POL100 development board yet so this is going here.

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
}

This started a conversation between Yukiko and myself regarding the validity/need to add it as a core function rather than just leaving as a script based function.

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

Reasons Against:

1. It can be done in scripts so the core shouldn't need to get involved.
2. If items like OrionUO or Razor disappeared then the core is left with a functionality that is no longer needed.
3. Core should mostly be to support OSI items and additional stuff should be done from script.
4. A package could be written to do a script to inject the packets based on a config file.
5. If OSI decides to use Orions packet for their own use the functionality is broken.

My responses to the Against arguments are below.

1. It can be done in both, don't have the cfg file and you can code it into your scripts if you want.
2. 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.
3. Core currently supports things like HTTPRequest, Aux Connections, JSON, SQL, all which aren't specifically OSI related?
4. It could, and it still can, but core support with a single CFG file is easier to document and easier for noobs to implement.
5. 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.

Feel free to leave your own comments as needed, and you can change your vote if something on here changes your mind.

Thanks Again!

[bodom]

I know very little about the topic, but I have a feeling this should not belong to the core or, at least, have a very low priority: it still lacks support for some important native packets.

Also, as a general rule, I like the "recent" tendency of trying to move functionalities form the core to the scripts, when possible.

Anyway, the situation may vary depending on some factors:

• What prevents such "custom packets" from being incompatible with standard OSI packets?

• Do those clients identify themselves? Or just pretend to be the original client?

Maybe the packet could not be fully integrated into POL, but the script interface for it could be made easier, something like:

@login.cfg
if ( client.isorion )
SendOrionCustomSettings( op1, op2, op3, …);

This would be sort of "middle ground": leaving the final decision to the scripters, but making their life easier.

P.S. This forum should probably be renamed and the POL100 forum be created

[Yukiko]

The poll assumes that these third party clients and/or "injection like" tools provide a way of sending a packet from a script to enable or disable features provided by these third party programs, which Razor and Orion client do.I voted no. The Core should not be modified for these types of programs as long as they provide a means for disabling their features via scripts.

My vote might be different if there was not a way to enable or disable features via scripts.

Dev and I are at opposite ends on this issue and to his credit he expressed my points against Core support pretty well. So this post will focus on how scripts can support features of these types of programs.

I am only going to address the Orion client here because I am familiar with it. I haven't looked into Raxor but I know it has provision for enabling or disabling features.

Here are the panels for enabling or disabling features for the two parts of the Orion Client:
For the Orion Assistant:

And for the client:


As you can see there are checkboxes that allow the admin of a shard to select the features they wish to enable. On the right of the panel you will notice an eScript template. If you look at the Client configuration panel in the script example you will see the line:

Code: Select all

var res := SendPacket(who, "FC00090032000001FF");

As you select or unselect each checkbox the value "FC00090032000001FF" changes depending on which features are enabled. The same happens for the Assistant configuration panel as well. In this way the admin can easily change settings and decide what to enable through scripts. All that is needed to be done is create an optional package called OrionClient. Add those two script examples to a logon.src and reconnect.src file in that package and you have what you need. In fact I will create such a package and post it on the forums.

I see no need to go messing with the Core to provide something that can easily be done through scripting. This is easy to do in scripts, far easier than adding it to the Core.

Plus there are at least 2 Raxor like programs and I have lost count of how many third party clients have been created, I know of 4, Kyrios, Iris, XNA and now Orion. Are we, every time a new program appears on the scene go into the Core and add support for it?

The last thing I want to say is that I am all for updating the Core to enable features in the official Ultima Online(R) game. I also agree with Bodom that as much control as can be made available in scripts is a good thing. POL has lagged behind in official UO features for a long time, both in scripts and the Core. Should not our focus be on bringing those features to POL and where possible let others provide support for these third party programs in optional script packages?

[DevGIB]

My reply to that would be along the lines of, the clients only offer script base support because there isn't core based support.
Maybe you guys are correct and if it can be done in script then its easier to just do there.
Another pro which i don't think i had on that original list was that its ease of configuration if you just have to change a flag in a config file verses adding it into a script which needs to be injected in 2 places.

I see no harm in adding it to the core especially as i'm suggesting it should be an optional extra.

As for effort involved in adding it to the core, 1 person needs to make the effort to add it to the core vs everyone making the effort to adding it to their scripts if they want to support those clients. And secondly i don't think it would an overly hard addition.

Don't get me wrong i 100% agree that the main focus should be on adding OSI feature support, but these little things also help with ease of use for newbies which should also be part of our focus

[bodom]

So it's down to sending a single packet to orion only in the end? That's a bit LOL, but let's play this game.

I see some problems with the cfg-based approach:

• Most shards only have a single client but some, like our, like to allow multiple client versions. Does the orion client qualify itself "hi, i'm orion!" when connecting? Can the packet be sent to orion only, or will it have to be sent indiscriminately to any client?

• What happens to the standard client when it gets the 0xFC packet? Does it crash or just ignore it? Did anybody test that with multiple client versions? Are we 101% sure that this does not conflict with anything? What if someday origin ill chose to start using the 0xFC packet?

• I see the orion guys made a nice GUI configurator tool. It does all the magic, then computes the final value for the HEX packet. If we add this to the config, then i suppose we will need to sync the options and keep them up-to-date every time the client evolves, since just writing "FC0090…" in the config seems to be pointless and add no value to the current situation. That's some extra maintenance work to account for.

• If we choose to add native Orion support, will they add the new tab into their configurator to generate the fancy cfg? It should become Sphere - RunUO - POL099 - POL100… otherwise all this discussion seems to be pointless.

[Nando]

While the idea is nice, my vote is no:

1) Many clients will eventually show up. They may be incompatible to each other. Do we really want the core to be doing complicated guessing of which assist is there? We already have enough problems trying to support the client APIs

2) There is an easy solution: a simple package could be created, which would read a config and define the packet flags. Escript is much easier to change than c++. Also more flexible: one could use different settings for different accounts, privs, etc.

While I'm not strict about what the core should support, a good guideline is that it should only do things which are complicated to get right or where the escript solution is not satisfactory. Anything else is an unnecessary burden on the dev team. Remember that these things need to be maintained.

If in the future this mod becomes standard, then we could reconsider it. At the moment, I'm more for a package and change the core just enough to support it. (For example, adding the packet definitions so hooks can work.)

[Yukiko]

For now I don't know if we need a hook. I am trying to get information from the Orion people to find out if there is a way to detect the Orion client. If we can query it and have it identify itself then we might have a need for a packet hook. For now all we do to disable features is SendPacket() the appropriate packet info. However adding the Orion packet info to the POL packet guide is probably a good idea.

Being able to identify the Orion client might be a necessity because my preliminary testing seems to indicate that sending the Orion feature packet to a non Orion client causes the client to freeze.

I am certainly enthusiastic about Orion and hope it continues to be developed.

[Nando]

[Just a quick note that we now have a forum for POL100, and I moved the topic there.]

[atreiu]

i guess that i don;t understand essence of problem because it's hard to read a lot text not on my native language. but as i see if Orion will send something to POL and/or if POL will see something typical for Orion client then he will do same he does for CLIENTTYPE_UOKR or CLIENTTYPE_UOSA etc

Code: Select all

else if ( client->compareVersion( CLIENT_ORION ) )
      client->setClientType( CLIENT_ORION );

i suppose thats not a big deal and then POL users can handle packets and do what they want with them if who.clienttype == "Orionblablabla"

[Yukiko]

The problem is that Orion looks like the official client to the server. It does not "announce" itself. It can be used on OSI. So it is not detectable, not yet anyway.

[atreiu]

changes in POL core for that is needed just 2-3 new lines like i wrote above. But you can do it without core changes by some kind ugly decision. we russians coders call it crutch or bicycle and sometimes this working well even with square wheels.

if user want say to POL that he use Orion then create for them scripts/www/setclienttype.elc with two options
* classic
* orion
and there they can declare themself to POL by account.setprop("orion_client",1) or setobjproperty(character,"orion_client",1)

or just player cmd .orion will do the same and his prop will be useful after player relogin. i guess main problem not here, if there some character problems and freezes then you should know exactly what packets should be proper/suitable for Orion client.

[Yukiko]

If I understand your solution I do not think it would be a viable solution. The Orion client offers special features similar to Razor. Some of these features can be disabled by a packet sent to the client. So asking a player to identify the client they are using would probably not work. Obviously the player would want all of Orion's features. So they would not want to tell the server they are using Orion.

[atreiu]

then maybe is possible to catch some Orion's feature behavior like

Code: Select all

if (who.clienttype == 1 and packet.getint8(0) == 0xC8)
	// suppose Orion 
endif

old clients cant send it but seems like Orion provide this feature for them. view range in old clients not related with 0xC8 its just example i mean strange combination clienttype and packets

[Yukiko]

Yes. We might be able to do a test like that? We do not know yet if there is a way to detect Orion but hopefully we will be able to find a way.