Hello,

these members are new (to me) and while testing the the newest core I tried to read the values every minute. The character was inactive, client minimized, nothing from me (will be auto logged off after 10 minutes with our configuration).

Now - whats the 'POL Clock' ??

...
last_activity_at Integer POL clock when last activity has been made r/o
last_packet_at Integer POL clock when last packet has been received r/o
...

There is a POL Gametime (can be read with ReadGameClock(), increments every second). There is a MilliSecondClock (can be read with ReadMillisecondClock(), increments every millisecond). The values in both of the new variables are different and make not really sense to me.

Additionally the value of .last_packet_at makes not much sense, since it ever increments, even when the client is idle. It obviously also counts packets send _to_ the client, and there are many (weather, "You see..." messages, and so on). So what use is this value?
last_activity_at looks good in the way that it does not increment over time, when the client is idle. And if one does something (moving something in the backpack, talking,...) it increments itself (to a value near the value of .last_packet_at), so the values obviously make some sort of sense, but there is no comparison value, or is there a method to read the current POL clock? I expected both values to be in GameClock, but they aren't.

It seems sort of a 10 ms clock, since the last_packet_at value increments by approx. 6000 (a bit less, mostly around 5900) every minute, and the script which reads the values should run every minute. The script I used for testing runs in an endless loop with a sleep(60) inside. So I would _guess_ that the value in last_activity_at divided by 100 is the last activity in seconds. But which connection does it have to the _current_ POL clock? Can I read it somewhere?
I also tried polcore().uptime - there seems a connection, the POL clock seems to be counted from zero to uptime * 100, in 10ms steps, and rounded.

But the usability of the values is low, if they are undocumented - or did I overlook the definition of 'POL clock'? And I need a method to fetch the _current_ POL clock, to be able to determine a period (from last activity to now).

My intention is to use them for a feature, with the auto logout disabled. We want our players to be able to idle, but we need to switch off certain things and we want to change the name with a marker, so that others know the player is afk.

Again - what is the POL clock? I could experiment further but maybe the developer of this feature (Bodom from the Changelog) is present and would care to explain?

Thank you

OWHorus

Maybe it was not the best unit used for these two members I can understand your problem.
It's the internal clock used to schedule stuff, but the good news is it's the same clock used for ReadMillisecondClock() just multiplied by 10.
Your second point about the use-ness, both members get only updated for received packets. But, and that is why I think you thought last_packet is also updated on send, the client has several "spam" packets these get not counted for the inactivity kick and not for the last_activity member. But since they are packets of cause they update this member. Thus the member is likely completely useless.

Hello Turley,

thank you for your answer - I already suspected that MillisecondClock has to do with the POL clock.

I have now a working solution for the 'last activity' of a character:

SysMessage(char, "Letzte Aktivitaet vor "+CStr(polcore().uptime - CInt((char.client.last_activity_at+50)/100)+" Sekunden"));

Uptime is the time the core is running in 10 ms steps (jiffys?), and increments 100 times per second, similar to ReadGameClock(), but starting at zero at every server boot. This way one can clearly see the time since the last activity.

The returned value with the script fragment above works quite well.

OWHorus

Turley wrote: <...>
But, and that is why I think you thought last_packet is also updated on send, the client has several "spam" packets these get not counted for the inactivity kick and not for the last_activity member. But since they are packets of cause they update this member. Thus the member is likely completely useless.

After thinking a bit about this: If last_packet_at would ignore the spam packets it would contain the same information as last_activity_at. So it may not be useless - it could - maybe - used to find out clients where the connection is hung somehow. In rare cases we see characters hang in the world, but the player has no control anymore. We verified this several time with ICQ, when the player reported a connection hang/loss but the character still was present. The character will then disappear (logged off) after a connection time out - but maybe we can see this before, when the last packet from the client is a while ago. It would be hard to test, since such problems are internet problems and not easy to simulate...

But I would leave it as it is, because otherwise we would have the same information twice.

OWHorus