Core Expansion and Feature Handling

Archive of the older Feature Request Forum Posts

Moderator: POL Developer

Locked
MuadDib
Former Developer
Posts: 1090
Joined: Sun Feb 12, 2006 9:50 pm
Location: Cross Lanes, WV

Core Expansion and Feature Handling

Post by MuadDib » Sat Jan 03, 2009 6:23 pm

Nando and I have been discussing a major rewrite tonight. Something that you all should be made aware of, and have input on. A LOT of this is just Core changes, and won't affect Scripts and End Users, BUT.... it opens the possibilities for ALL KINDS OF CRAP!

We are looking at making part of the core treat the storage of Expansions and UOEnableFeature stuff differently. What that will let us do, is add some new possibilities.

We want to add a new entry (not required) to UOClient.Cfg. This entry would be something like:

Code: Select all

Expansion AOS
{
      Feature        0x20    # For Tooltips
      Feature        0x08    # Another example
}

Expansion T2A
{
      Feature        0x01
}
That way, you can control, PER EXPANSION on your shard. That way, your Classic Shard can support Tooltips if someone decides to log onto an AOS Enabled account, WITHOUT all the other people using T2A accounts being affected. This makes it easier to handle multiple expansions on a Per-Server basis without having to do 500 scripts or packethooks for handling client issues.

Another thing this opens the possibility for, is no more need (unless you CHOOSE to use this way!) the UOFeatureEnable setting in servspecopt.cfg. Since it affects ALL clients connecting, this gives you an alternate method if you so choose it.

We are also looking at (with this) adding members for specific features. If character Joe logs into his AOS enabled account, and tooltips are activated, you can find out if he has tooltips without checking expansion AND flags just by reading Character.TooltipsEnabled or something like that.

This method will let you even set up Ports to enable only certain features (so ppl using AOS accounts, who don't want the tooltips, can log through a seperate port configured in a UOClient.cfg which DISABLES tooltips). And So on. All with just one POL running, on 1 shard.

Input People, and let me know what you think.

Nando
POL Developer
Posts: 262
Joined: Wed Sep 17, 2008 6:53 pm
Contact:

Re: Core Expansion and Feature Handling

Post by Nando » Sat Jan 03, 2009 6:37 pm

Just an addition, my idea is more on the way of:

Code: Select all

Expansion AOS
{
      EnabledFlags       0x20       # For the login (0xA9) packet's flag, summing with the flags defined in UOFeaturesEnabled
      UnlockedFlags        0x801B     # for the unlock client features (0xB9) packet
}

Expansion T2A
{
      UnlockedFlags        0x01
}
That way, we could have an expansion-based UOFeaturesEnabled flag, besides allowing people to define expansion-based flags for the now hardcoded values of the 0xB9 packet, without the need for a packethook.

What do you guys think? My idea is to get UOFeaturesEnabled as a global default value, that would be summed (OR'ed, for those who know bitwise operations) with the EnabledFlags of the acct expansion before being sent in the login/starting location packet (0xA9).

The default behavior would be to use the UOFeaturesEnabled and the hard-coded flags for the 0xA9 and 0xB9 packet, unless there are flags defined in uoclients.cfg

User avatar
OldnGrey
POL Expert
Posts: 657
Joined: Sat Feb 04, 2006 6:26 pm

Re: Core Expansion and Feature Handling

Post by OldnGrey » Sun Jan 04, 2009 12:15 am

Actually what might help me get my head around this is just what features each client does support. I am not at all adverse to adding bits together to produce a number - I'm actually using UOFeatureEnable=0x1a8 right now but to me a lot of this seems like trial and error stuck together with an occasional mystery thrown in for good measure.

Do I know what UnlockedFlags are? Um, nope. I've just got used to npcpopups and have no idea what a single characte seige could be (0x04). In fact if it's all bits, then it should be possible to put together a full list of all of them and what they do for every client type. I see above that 0x801 does something in AOS but in T2A it's 0x01. Huh?

I am pretty sure I don't have the complete picture - um what is IGR anyone? Is AOS 0x20 the same as tooltips? What does flag 0x01 do in AOS and not T2A? And the SE and ML flags seem to use more than 1 bit - just what is enabled and can we selectively turn off stuff like the fight book?

I like your idea, I'd just like the opportunity of asking for an understanding of what stuff does.

Yukiko
Distro Developer
Posts: 2728
Joined: Thu Feb 02, 2006 1:41 pm
Location: San Antonio, Texas
Contact:

Re: Core Expansion and Feature Handling

Post by Yukiko » Sun Jan 04, 2009 4:56 am

I'm with OldNGrey on having features per client version listed and those features explained.

As for the enabling of features I have no problem ANDing the hexadecimal values (or binary bits for that matter) to come up with the required "feature enable byte" value but, for simplicity's sake, wouldn't it be more desirable to have something like the following:

Code: Select all

Expansion AOS
{
      TooltipsEnabled = 1
      Feature2Enabled = 1 
}

etc...
That's more like the usual syntax of a configuration file rather than using hex values for internal bits.

Tomi
POL Developer
Posts: 477
Joined: Tue Feb 21, 2006 5:08 pm

Re: Core Expansion and Feature Handling

Post by Tomi » Sun Jan 04, 2009 5:18 am

Should be a nice feature yes, and the possibility to add features and not have to count the bits together should be nice too. Lets say, you want in 0xB9 packet enable AOS and SE, you can put as MuadDib showed earlier on 2 separate lines those entries. And same change to 0xA9 FeatureEnable in servspecopt.cfg should be nice too. This should make the life whne playing with these packets alot easier.

OldnGrey the single siege or whatever the name was what you mentioned, is a way for client to stop people from using more than 1 character / account.

and IGR was some kind of old login system to OSI, which was used to enable playing from some internet coffe shops or similar, can not remember exactly, and I have no idea if that is still used to something or what it does nowadays.

coltain
Grandmaster Poster
Posts: 159
Joined: Tue Mar 20, 2007 7:17 am
Location: Poland

Re: Core Expansion and Feature Handling

Post by coltain » Sun Jan 04, 2009 5:42 am

ORIGIN web site:

Code: Select all

1. The Ultima Online License.
Ultima Online is an Internet-based online fantasy role-playing game service that allows you to play the "Ultima Online" computer game when you subscribe and pay a fee, or when you participate through an [b]Internet Game Room (IGR)[/b] pursuant to the IGR's rules. As part of the Ultima Online service, EA.com maintains a site on the World Wide Web with a URL address of "www.uo.com" (the "Web Site"). Throughout the remainder of this Agreement, the Ultima Online service (including the Web Site) will be referred to as the "Service", if you have purchased the the Ultima Online game CD-ROM published by EA.com Inc.it will be referred to as the "CD" and the software programs contained on the CD and provided to you through the Service will be referred to as the "Software". EA.com grants to you a limited, non-exclusive license to use the CD, the Software and the Service subject to all of the terms and conditions of this Agreement, and the additional terms set forth in the documentation of the CD.
link:
http://www.uo.com/agreement.html

bleh, I can`t bold a font in

Pierce
Forum Regular
Posts: 420
Joined: Thu Feb 02, 2006 8:33 am

Re: Core Expansion and Feature Handling

Post by Pierce » Sun Jan 04, 2009 7:32 am

@OldnGrey:

Siege is the short form of a special OSI/EA Server called Siege Perilous Shard.
The most important feature is, like Tomi said, that there is only 1 character/account.
Look here: http://uo.stratics.com/content/basics/siege.shtml

The IGR message is sent by the server when the login is denied (0x82 packet):

Code: Select all

0x00 - Incorrect name/password.
0x01 - Someone is already using this account.
0x02 - Your account has been blocked.
0x03 - Your account credentials are invalid.
0x04 - Communication problem.
0x05 - The IGR concurrency limit has been met.
0x06 - The IGR time limit has been met.
0x07 - General IGR authentication failure.
If you set the MinCmdlevelToLogin=2 (e.g.) all clients with CmdLevel 0 or 1 get the message that the IGR time limit has been met and they can't login.

@topic:
For changes in the future which are not named yet or even in the client i think it's important to at least allow also the "hex way" of editing the cfg file. Otherwise the core
devs must name the feature first before we can use it everytime they change the client ;)

tartaros
New User
Posts: 28
Joined: Tue Mar 27, 2007 6:30 am
Contact:

Re: Core Expansion and Feature Handling

Post by tartaros » Sun Jan 04, 2009 7:42 am

just out of curiosity, what can be the point of making a diference between aos-enabled accounts and aos-disabled accounts?
I mean, you either want an AOS shard or you want a non-AOS shard, isn't that so?

Nando
POL Developer
Posts: 262
Joined: Wed Sep 17, 2008 6:53 pm
Contact:

Re: Core Expansion and Feature Handling

Post by Nando » Sun Jan 04, 2009 8:16 am

Well, let me comment a little.

For OldnGray, the bits are here:
http://docs.polserver.com/packets/index.php?Packet=0xA9 (For 'EnabledFeatures')
http://docs.polserver.com/packets/index.php?Packet=0xB9 (For 'UnlockedFeatures')

As you can see, there's no easy way to separate between some functions. It'd be more like: "AOSTooltipMonstersSkillsMap = 1". So, I think
what could be better is a list of the flags and their effects. (Maybe along with when it started accepting those flags, if possible) in the comments
of a default config file (or the docs). Maybe distribute POL with a default uoclient.cfg for the expansions, who knows?

I'm fond of the idea of hex bits, as there are two different values to be sent: the one in A9 (that is now UOFeaturesEnabled), and the one in B9 (that is hard-coded according to the acct expansion). If a new flag appears, you would be safe to apply it.

Is it possible to add some names for the features? Of course. But as you can see, they're too interconnected and I can't see much gain in it. The idea is to be able to distribute along with POL core a list of flags for the expansions, which almost no one would like to change, so it'd work with no need to fiddle around with UOFeaturesEnabled. Lots of bugs are caused because of setting client expansion to "AOS" or upper without sending the correct UOFeaturesEnabled flag.

The idea of having AOS and non-AOS clients in the same shard would be to allow different client versions interacting. Some shards need this.

Which features names should be made, considering that they're all a group under the same flag bit? They could be just flags OR'ed together both to the Unlocked and Enabled flags, keeping the ones I've already said as a fall-back when a new feature is implemented and core still doesn't have it.

Tomi
POL Developer
Posts: 477
Joined: Tue Feb 21, 2006 5:08 pm

Re: Core Expansion and Feature Handling

Post by Tomi » Sun Jan 04, 2009 10:27 am

The idea with hex numbers instead of hardcoded constants would be much better, this is something I have been requesting as a change to the UOExpansion entry in accounts.txt and .uo_expansion() member as well, because as for now we need to wait for the poldevs to add there a new entry such as "T2A", "LBR" and so on. with hex numbers we could put there the bit value most suited and what we want without having to wait for devs to do changes to core when a new expansion of UO or new features are added.

Nando
POL Developer
Posts: 262
Joined: Wed Sep 17, 2008 6:53 pm
Contact:

Re: Core Expansion and Feature Handling

Post by Nando » Sun Jan 04, 2009 11:48 am

We don't think of allowing custom expansions (I mean, a name different from T2A, ML, SE, AOS, ...) by now, because of the way it's handled internally. But yes, Tomi, hex allows to enable new features without dev intervention or packethooks. If a new expansion is out, just pick an unused one and place the correct flags.

tartaros
New User
Posts: 28
Joined: Tue Mar 27, 2007 6:30 am
Contact:

Re: Core Expansion and Feature Handling

Post by tartaros » Sat Jan 10, 2009 7:06 pm

Nando wrote:...setting client expansion to "AOS" or upper...
what do you mean by "setting client expansion"? there's some packet that does this or what?

Nando
POL Developer
Posts: 262
Joined: Wed Sep 17, 2008 6:53 pm
Contact:

Re: Core Expansion and Feature Handling

Post by Nando » Sun Jan 11, 2009 2:01 am

tartaros wrote:what do you mean by "setting client expansion"? there's some packet that does this or what?
The client knows it's in a different expansion according to the B9 packet and it's flags. It also needs flags in A9 to show that the server has the new features.

What I meant by "setting client expansion" is this:

Code: Select all

set_uo_expansion(string expansion)
It's a method from the Account object (POL Docs, Acct Object) that sets the "uo_expansion" property. That's used internally to create the 0xB9 packet with flags according to the expansion: T2A (default), LBR, AOS, SE, ML.

Locked