nydehi / fluorescence

Automatically exported from code.google.com/p/fluorescence
GNU General Public License v3.0
0 stars 0 forks source link

protocol version? #15

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
I can't understand what version of protocol you use... At fist sigt it's SA 
7.0.0 - 7.0.8 but you use packets that was depricated scince 7.0.0. I think 
it's nessesary to work on this or even to make the description of using 
protocol to be able to implement it on server. I think it's more easy and way 
to make own extended protocol and simply put patch of runuo core for 
implementing it or description... 

If no don't think so ii will be useful for you:

1. I geted table of packets length from client 7.0.16.3 and is valid for 
7.0.13.0 + and for all 7.0.0+ client excepte some packets (char creation). 
0xFFFF is data that client have no any value. Packet 0xF0 is also used by some 
servers for negotiate razor features and razor extensions.
{{{
    0x0068, 0x0005, 0x0007, 0x0000, 0x0002, 0x0005, 0x0005, 0x0007, // 0x00
    0x000F, 0x0005, 0x000B, 0x0007, 0x0000, 0x0003, 0x0000, 0x003D, // 0x08
    0x00D7, 0x0000, 0x0000, 0x000A, 0x0006, 0x0009, 0x0000, 0x0000, // 0x10
    0x0000, 0x0000, 0x0000, 0x0025, 0x0000, 0x0005, 0x0004, 0x0008, // 0x18
    0x0013, 0x0008, 0x0003, 0x001A, 0x0009, 0x0015, 0x0005, 0x0002, // 0x20
    0x0005, 0x0001, 0x0005, 0x0002, 0x0002, 0x0011, 0x000F, 0x000A, // 0x28
    0x0005, 0x0000, 0x0002, 0x0002, 0x000A, 0x028D, 0x0000, 0x0008, // 0x30
    0x0007, 0x0009, 0x0000, 0x0000, 0x0000, 0x0002, 0x0025, 0x0000, // 0x38
    0x00C9, 0x0000, 0x0000, 0x0229, 0x02C9, 0x0005, 0x0000, 0x000B, // 0x40
    0x0049, 0x005D, 0x0005, 0x0009, 0x0000, 0x0000, 0x0006, 0x0002, // 0x48
    0x0000, 0x0000, 0x0000, 0x0002, 0x000C, 0x0001, 0x000B, 0x006E, // 0x50
    0x006A, 0x0000, 0x0000, 0x0004, 0x0002, 0x0049, 0x0000, 0x0031, // 0x58
    0x0005, 0x0009, 0x000F, 0x000D, 0x0001, 0x0004, 0x0000, 0x0015, // 0x60
    0x0000, 0x0000, 0x0003, 0x0009, 0x0013, 0x0003, 0x000E, 0x0000, // 0x68
    0x001C, 0x0000, 0x0005, 0x0002, 0x0000, 0x0023, 0x0010, 0x0011, // 0x70
    0x0000, 0x0009, 0x0000, 0x0002, 0x0000, 0x000D, 0x0002, 0x0000, // 0x78
    0x003E, 0x0000, 0x0002, 0x0027, 0x0045, 0x0002, 0x0000, 0x0000, // 0x80
    0x0042, 0x0000, 0x0000, 0x0000, 0x000B, 0x0000, 0x0000, 0x0000, // 0x88
    0x0013, 0x0041, 0x0000, 0x0063, 0x0000, 0x0009, 0x0000, 0x0002, // 0x90
    0x0000, 0x001E, 0x0000, 0x0102, 0x0135, 0x0033, 0x0000, 0x0000, // 0x98
    0x0003, 0x0009, 0x0009, 0x0009, 0x0095, 0x0000, 0x0000, 0x0004, // 0xA0
    0x0000, 0x0000, 0x0005, 0x0000, 0x0000, 0x0000, 0x0000, 0x000D, // 0xA8
    0x0000, 0x0000, 0x0000, 0x0000, 0x0000, 0x0040, 0x0009, 0x0000, // 0xB0
    0x0000, 0x0005, 0x000A, 0x0009, 0x0003, 0x0000, 0x0000, 0x0000, // 0xB8
    0x0024, 0x0000, 0x0000, 0x0000, 0x0006, 0x00CB, 0x0001, 0x0031, // 0xC0
    0x0002, 0x0006, 0x0006, 0x0007, 0x0000, 0x0001, 0x0000, 0x004E, // 0xC8
    0x0000, 0x0002, 0x0019, 0x0000, 0x0000, 0x0000, 0x0000, 0x0000, // 0xD0
    0x0000, 0x010C, 0x0000, 0x0000, 0x0009, 0x0000, 0x0000, 0x0000, // 0xD8
    0x0000, 0x0000, 0x000A, 0x0000, 0x0000, 0x0000, 0x0005, 0x000C, // 0xE0
    0x000D, 0x004B, 0x0003, 0x0000, 0x0000, 0x0000, 0x000A, 0x0015, // 0xE8
    0x0000, 0x0009, 0x0019, 0x001A, 0x0000, 0x0015, 0x0000, 0x0000, // 0xF0
    0x006A, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, 0xFFFF, // 0xF8
}}}

2. I implemented two HS packets (see attachment), soo now I'm able to connect 
to my HS server, but I still have a lot of problem's I can continue for making 
compatibiliti with HS if my updates will be uploading to trunk. I also put 
there updated solution for vs2010, because old one again looks like trash..

3. It's very hard to navigate in protocl directory. In future it will contain 
up to 500 files!!! I think it's nesessary to add packet ID at the start of file 
name or wraite all them at one file or smth else, because now it's very hard to 
work with hundreds files...

Original issue reported on code.google.com by staticz@uoquint.ru on 4 Jul 2012 at 11:13

Attachments:

GoogleCodeExporter commented 9 years ago
4. Client doesn't send it's version to login server. it's hard to detect and 
change client version due to make uniq network logic for it.

Original comment by staticz@uoquint.ru on 4 Jul 2012 at 11:26

GoogleCodeExporter commented 9 years ago
So far, I was not really aiming for a certain protocol version. But you are 
correct, this should be consistent! One problem might be that I don't know how 
good the support for SA and HS is with Sphere and POL. Do you (or anyone else) 
have some information on this?
Maybe we should provide two different protocol versions (can be set in config): 
one for pre-SA, and one for the 7.0.16 HS. I think this should be safe for all 
emulators. 

1) Thanks. I'll integrate this for the HS packet version. Maybe we need another 
table for the pre-SA. I don't think that Razor stuff should be part of the 
client; but the new movement packets are currently not supported by RunUO 
anyways

2) Thanks again. I'll do some HS testing myself soon, but I'm happy to get some 
help. I'm sorry about the solution file, my VS Express seems to not like the 
filters stuff and overwrite it all the time.

3) You are right, that got a bit out of hand. I will rename the files soon.

4) I do not use the new login seed yet, but plan to. At the moment, the client 
only sends its version in the 0xBD packet

Original comment by spin@fluorescence-client.org on 5 Jul 2012 at 7:02

GoogleCodeExporter commented 9 years ago
Okay, I implemented a config switch to set protocol version to either HS or 
pre-HS, I think that should be sufficient, considering how long SA is already 
out. HS protocol is not really working now (new character list!), but pre-HS is 
default and seems to work fine, except compressed gumps. I'll implement 0xDD 
later today.

I also implemented the 0xEF seed, and changed a few packets to conform to the 
latest pre-HS protocol version as described by Wyatt. Seems to work fine on my 
RunUO home server.

Also, the packet files were renamed.

Thanks for implementing the packets, they are already in the main branch. I 
also committed your Visual Studio files, but due to the packet renaming they 
are already outdated again ;) 

Original comment by spin@fluorescence-client.org on 5 Jul 2012 at 4:33

GoogleCodeExporter commented 9 years ago
Ok, thanks. I'll continue to work on supporting HS expansion and clients up to 
7.0.23.1 (last uo version that use *.mul not *.uop). The problem in fact is 
that differnt clients sometimes have different packet sizes of same packets. 
Also I don't now where to look for old packets, but if you want to support 
sphere it's nessesary to emulate 2.0.3 clients, because most of sphere server's 
prefer this clients, though new versions of sphere supported even SA features 
(garg race and soo on). I think the best way is to make support for this 
clients: 2.0.3, 6.0.13 (ML), 7.0.23 (HS). Also UO have packets with features 
suport that change clasic client protocol features, maybe it will be good idea 
to overwrite it and add  some more FLUO extended features?  Extended protocol 
is very useful and nesesary

Original comment by staticz@uoquint.ru on 6 Jul 2012 at 7:37

GoogleCodeExporter commented 9 years ago
Are people really still using 2.0.3? That version is 12 years old now. I'm not 
sure it would be really worth the effort to support such an old client. But if 
there is demand, it would be possible.
SA was released almost 3 years ago. I think that should be enough time for 
people to update their stuff. SA is (as far as I know) supported by RunUO 2.0. 
So I'd focus only on SA/HS for now. Let's see if people request support for 
older versions.

Original comment by spin@fluorescence-client.org on 6 Jul 2012 at 8:01

GoogleCodeExporter commented 9 years ago
I agry with you but sphere servers and players prefer 2.0.3 clients. At least 
in Russia nobody use sphere to create SA, ML shard. only 2.0.3 or not often 
2.0.3 with supporting 6.0.x client. Most of RunUO server's steel use ML, but 
again some people prefer AoS... Supporting SA and HS are made only by new 
servers or OSI emulating or dynamicly developed... As for me i think it's more 
better to use HS (because when client will be finished HS will become rather 
old) or even custom protocol. But if you want to make client for anybody than 
it's nessesary. Also some RunUO players are crazy on AoS and prefer it. I don't 
thin that any body request it becase such client is interesting first of all to 
server staff that whanted to change original cient to implement some their own 
crazy features. But in any case I agre with you that now more better whould be 
to focus on SA/HS, or even better on HS only (it's difficult to make support of 
HS on SA server)

Original comment by staticz@uoquint.ru on 6 Jul 2012 at 8:35

GoogleCodeExporter commented 9 years ago
I mean it's NOT difficult to make support of HS on SA server.. :=)

Original comment by staticz@uoquint.ru on 6 Jul 2012 at 8:49