Up to Main Index Up to Journal for December, 2021
JOURNAL FOR WEDNESDAY 29TH DECEMBER, 2021
______________________________________________________________________________
SUBJECT: Event logging update available
DATE: Wed 29 Dec 18:46:44 GMT 2021
So, Christmas eve I snuck out a v0.0.19-beta.3 treat. A few people actually
noticed :)
I’ve just pushed out some commits to the public dev branch for event logging.
Event logging can be very useful for debugging resets, spawning, mobiles and
triggers. It’s going to be especially useful when implementing combat…
For testing events I usually set up a simple quiet zone. The quiet zone has
one starting location and the minimal items for whatever I am testing at the
time. This cuts down on the amount of events generated — event logging makes
the server log very noisy. All other zones I disable except for the quiet one.
Re-adding event logging has been interesting as it threw up a few oddities. As
a result a minor nit was fixed along the way — a rouge event was scheduled
with no data and was harmlessly thrown away when delivered.
For testing event logging I set up a quiet zone with a frog and a jar that has
a bean respawning in it. If I take the bean from the jar a reset is scheduled:
Event schedule: Reset, for: #UID-9 (a bean), at: Dec 29 15:55:56, in: 1m6.2s
After a while the reset event is delivered and the bean in the jar re-spawns:
Event delivered: Reset, for: #UID-9 (a bean), at: Dec 29 15:55:56, in: 0s
Event cancel: Reset, for: #UID-9 (a bean), at: -, in: -
If the bean we took from the jar is dropped, then it is just laying around and
schedules for a clean-up:
Event schedule: Cleanup, for: #UID-8 (a bean), at: Dec 29 15:59:07, in: 1m9s
After a while, if the bean is not picked up, the clean-up event is delivered
and the bean is removed from play:
Event delivered: Cleanup, for: #UID-19 (a bean), at: Dec 29 15:59:07, in: 0s
Event cancel: Cleanup, for: #UID-19 (a bean), at: -, in: -
If the bean is picked up the clean-up event is just cancelled:
Event cancel: Cleanup, for: #UID-19 (a bean), at: -, in: -
It should be noted that a delivered event should be followed by the event
being cancelled as this also cleans up the event data.
Another example of events is mobiles doing random actions and moving around.
This is implemented by scheduling an action event. When the event is delivered
the action is carried out and another action event is scheduled:
Event delivered: Action, for: #UID-5 (a frog), at: Dec 29 16:06:59, in: 0s
Event cancel: Action, for: #UID-5 (a frog), at: -, in: -
Event schedule: Action, for: #UID-5 (a frog), at: Dec 29 16:07:29, in: 29.5s
If we pick up the frog we can see it’s current action event is suspended:
Event suspend: Action, for: #UID-5 (a frog), at: -, in: 9s
If the frog is dropped again its action event resumes:
Event re-schedule: Action, for: #UID-5 (a frog), at: Dec 29 16:10:31, in: 9s
When an event is delivered on time the ‘in’ value is zero:
Event delivered: Action, for: #UID-5 (a frog), at: Dec 29 16:13:31, in: 0s
If the event is delayed then the ‘in’ value will be negative:
Event delivered: Action, for: #UID-5 (a frog), at: Dec 29 16:18:01, in: -1ms
Minor deviations for ‘in’ are to be expected as an event can be delayed by a
number of things such as waiting for locks, scheduling or high CPU load. If
there are persistently large negative ‘in’ values for delivered events it
could be a sign the server/machine is struggling.
I can’t think of an instance where a large negative ‘in’ value would be a real
problem. Events will not start overlapping and run into each other. As a rule
of thumb, the ‘in’ value ideally should not go negative by more than 1 second
for a prolonged period of time. Otherwise, players may notice that things are
taking longer than usual to happen[1].
--
Diddymus
[1] Although if Jitter is specified to add randomness to the timing of
events this will be less noticeable unless there is a serious problem.
Up to Main Index Up to Journal for December, 2021