Closed GoogleCodeExporter closed 9 years ago
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 packetOriginal 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 nesesaryOriginal 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
Original issue reported on code.google.com by
staticz@uoquint.ruon 4 Jul 2012 at 11:13Attachments: