Question about character.clientinfo member

[Tomi]

I tried to use this to check some information from the client, but it always just shows 0 in all everything, no matter how I try to check, during login or later.

Anyone knows more about this ? I assume this could be hooked by packethooks now too, because the prechar selection packets have the struct member "account".

[Tomi]

I just did some tests, and it seems like the client 6.0.4.0 doesnt send this packet 0xD9 at all. I tried with character.clientinfo member, and also wrote an own packethook to check if it gives any info at all. but it doesnt.

[OldnGrey]

Hmm
Clientinfo isn't available during the logon script. I do a loop waiting for it in a non critical script so I can make decisions based on their client version.

However I do make use of clientinfo in scripts and it works just fine. However, I don't use past client 5.0.9.1 so it looks like you are right.

clientinfo was fixed in the last core - it used to have a trailing non character thingy.

[Tomi]

I checked the packets sent and received with UOLog, and there was no packet 0xD9 sent during many login and reconnects, so I assume they removed the Hardware info sending somewhere around client versions 6.x.x

Should be nice if someone with a version 6 client could confirm this too, so that we should know if the problem really is with the client versions or something else.

[Pierce]

I checked the packets sent and received with UOLog

Did you have a newer clients.cfg for UOLog? My keys for the 6.x clients
don't seem to work.

[Tomi]

47167aae: "6.0.4.0 2d" 41a8f0 5 1 434a50 7 6

thats for the version 6.0.4.0 that I'm using. And it shows all the other packages nicely.

I tried also to be sure with SpyUO and the result was exactly the same.

[Tomi]

and some client.cfg entries for version 6.x clients

#6.0 series
46b268f2: "6.0.1.10 2d" 41a90d 5 7 434a80 7 6
47167aae: "6.0.4.0 2d" 41a8f0 5 1 434a50 7 6
47421201: "6.0.5.0 2d" 41a980 5 1 434ad0 7 6
47a982d6: "6.0.6.0 2d" 41aae0 5 1 434df0 7 6
47ba0617: "6.0.6.1 2d" 41a980 5 1 434ad0 7 6
47e19075: "6.0.6.2 2d" 41c5e0 5 2 435ba5 7 6
4810abbb: "6.0.7.0 2d" 41c610 5 2 435cd5 7 6
483c9caa: "6.0.8.0 2d" 41c610 5 2 435cd5 7 6
4874efec: "6.0.9.2 2d" 41c610 5 2 435cd5 7 6
48c0023d: "6.0.10.0 2d" 41c610 5 2 435cd5 7 6

[Pierce]

Very strange. Nearly all values are exactly the same as the ones i have, but UOLog doesn't recognise them and therefor the clients. Not my day

[Pierce]

I did some research cause i am interested in this one, too.

6.0.4.0 does send the 0xd9 packet. Like the the other clients before, it doesn't
send this packet all the time. It seems you can't force this one from the server
side. But you can force it on your own computer by editing the registry:

Code: Select all

HKEY_LOCAL_MACHINE/SOFTWARE/Origin Worlds Online/LastHarvestTime

If you set this time to e.g. 0x12 or whatever the client sends 0xd9 to the server
after you start the client and connect to your server. After that the value is set to
a value that stops the client sending 0xd9 for a period of time. I don't know how long, perhaps a day or more until your computer has a higher "timestamp".

[Tomi]

so you found out the client 6.0.4.0 is sending the 0xD9 packet. Nice I really should make use of the width and heights for the screensize, because the screensize 0xBF subpacket takes only the size of UO screen.

but.... how does it actually send it ?? Can only be forced to send by registry editing or the client send it sometime without that editing too ?

That registry editing is no problem for me... but I can see the picture of trying to make a player on the shard understand how to do that editing, and Im not planning to pack a new image of the whole UO for players to download just because of this one.

That's why I really need to know when the client actually send this packet, because I tried several logon / reconnect / logout and the character.clientversion showed "0".

I tried to hook the packet and that just stopped the lconnection to server ( not on a static basis, but always now and then )

And even after all these tests, I did never actually see the client sending the 0xD9 packet, not even once.

[Pierce]

That's why I really need to know when the client actually send this packet,

That's what i tried to explain above
I try it another way. My client has sent the 0xd9 packet yesterday. The value
for LastHarvestTime is in my case 1231759589 which was set directly after sending
the packet. If i divide this value by 60, 60, 24 and 365 it gives a 39 as result.
That's why i think that this is a timestamp started as usual 1.1.1970 in seconds.

The client checks the actual system time (Time) against the LastHarvestTime like that:

Code: Select all

if(Time >= LastHarvestTime + x)
 send packet 0xd9;
 set new LastHarvestTime := Time;
else
 do not send packet 0xd9;
endif

I don't know after how many seconds (x) the client will send the packet again.
But if you set LastHarvestTime with regedit to a value of e.g. 5 the client will
send the packet the next time you connect to a server. The packet 0xd9 comes
right after the SendShardList packet (0xA8) if the client sent it.

[Tomi]

okay I see now, I just made a registry patch to change that LastHarvestTime to 5, I will add it to the installer which players will have to download, and have it automatically to be launched from there.

This way I will get the information during their first logon.

[Nando]

And just for information: yes, LastHarvestTime is saved as the number of seconds since 1.1.1970 (called Unix epoch)