UO:HSA

[Tomi]

I was taking a look at the HSA support that is in the core already.
- Packets with changed lengths are fixed
- there is a support for max tile id 0xFFFF

The problem comes with the max tile id because:
- Pol uses Multis as max_tile + 1 -> max_tile + 0x2000
- Core required stuff ( trade containers and such ) 0xF000 -> 0xFFFF
- Custom all there between

- with ML tiles up to 0x3FFF -> Multis up to 0x5FFF and so on
- with SA tiles up to 0x7FFF -> Multis up to 0x9FFF and so on

wih HSA tiles up to 0xFFFF and because graphic is an unsigned short there is no more room for multis and such

Just asking here if anyone is planning on looking at this ? Or if not all ideas are welcome what should be the best approach to fix this

[Tomi]

What I was thinking was extending objtypes to int not a short because objtypes are never sent to the client.
And then make a separate graphic table for multis not using the same.

But I should want to know what devs think about this ?

[Tomi]

I looked a bit more into this....

For multis the Graphic in itemdescs and boats.cfg for houses and boats are never sent to the client ( its just the multiID that get to be sent )

in packet 0xF3 ( used since client version 7.0.0.0 ) sent like this

Code: Select all

msg->WriteFlipped(multi->multidef().multiid);

so the 0x1A should be changed to that instead of

Code: Select all

u16 graphic= multi->graphic | 0x4000;
msg->WriteFlipped(graphic);

That way the graphic should not be needed for multis = one problem less

Then for item graphics there are no problem they still stay in the range of 0xFFFF

So to fix this what should need to be done is.....

- Remove the graphic from itemdesc and boat.cfg for multis just use the MultiID
- Extended objtype from unsignedd short to int or unsigned int
- move SecureTradeContainer, WornItemsContainer, Tillerman, Gangplank, Hold and stuff like that what the core requires to a higher objtype ( for example starting with 0x10000 and customs after that.

[Terciob]

I've testing HSA too with version 4.0.18.0 and just to report, seems like login packets was changed:

[10/05 11:29:59] Client#1 connected from 189.26.155.168 (1 connections) on interface 189.1.169.20
Client#1 i/o thread starting
Client#1 i/o thread past initial lock
Client#1: Unexpected message type 25, 62 bytes (IP:189.26.155.168, Account:None)
0000: 25 4c 0d a6 73 9c 06 7c c1 9f b0 a7 2c e9 0b 7a %L..s..| ....,..z
0010: c2 1e f0 07 7c c1 9f 30 67 cc 99 b3 26 ec 09 1a ....|..0 g...&...
0020: 42 de 10 f7 84 3d 61 4f 58 53 56 54 55 d5 95 b5 B....=aO XSVTU...
0030: a5 2d 69 cb 1a f2 06 7c c1 9f b0 a7 2c e9 .-i....| ....,...

So, i change the login hook to handle this packet instead 0x80 and i got

[10/05 11:35:57] Client#1 connected from 189.26.155.168 (1 connections) on interface 189.1.169.20
Client#1 i/o thread starting
Client#1 i/o thread past initial lock
Client#1 (189.26.155.168, Acct unknown) sent non-allowed message type 25.

[Tomi]

Login Packet for 2D clients changed from 0x00 to 0xF8 with client 7.0.16.0

Same packet structure just 2 more bytes for the fourth skill

[Turley]

Sadly the current svn is somewhere between beginning and end of hsa support. I left an unfinished version when I started a new job and now I have almost No time to finish it. The big thing left is the multi id vs objecttype. Sadly its a big thing, so nothing for a few hours.. if anybody has the time to think over the whole and create a patch I would very appreciate it

[Tomi]

I will take a look at this and see what can be done.
What Im planning is to remove the graphic totally from multis and just make use of the MultiID so it doesnt break other graphic entries and then if someday the max tiles are rased again there will no problem about it.
Another stuff Im doing is changing the objtype from being u16 to u32 and also moving the core required stuff up to something like 0xFFFFF000 -> 0xFFFFFFFF

After that the objtypes for 0x0 -> 0xFFFF are always reserved for normal items and multis only driven by MultiID ( and some objtypes in itemdescs that doesnt matter aslong as they are 0xFFFF +

[Tomi]

http://forums.polserver.com/viewtopic.php?f=41&t=3534

[Terciob]

Actually i was using enhanced client, i'm not sure if this is considered 2d or 3d.

And congratz on your promotion to Pol Dev

[Tomi]

Enchanced clients are 3D classic clients are 2D.

Are you sure you had the encryption removed from the client and pol encryption settings set to nocrypt.
Because login server packet 0x80 should show with cleartext the account name atleast and I have not seen that packet being changed to something else even with version 7.0.18.0 and in your case there is no cleartext in that packet and the only correct things seems to be the length.

Other case could be that EA has changed the encryption in that version for Enchanced clients and the encryption removal program doesnt work anymore.

[Terciob]

Good point about, i've not found any "cript removal/loginserver changer" program working properly (like UOSA Loader), i got raw client and hex edited loginserver with ultra edit, so, client sholud be cripted yet.

[Tomi]

iirc UO:SA Enchanced is using the same encryption as classic clients ( they removed the AES what they used in UO:KR )
But t he problems are with the login keys, I have for now no clue how they are calculated/used with the enchanced clients.
In other words if somehow find out how the loginkeys works for Enchanced clients there should be ready encryption support even for Enchanced clients in Pol. But that is not something I even find important right now as there are alot of other things to do.