Up to Main Index                               Up to Journal for May, 2018

                      JOURNAL FOR SUNDAY 13TH MAY, 2018
______________________________________________________________________________

SUBJECT: I still can’t count how many things I have
   DATE: Sun 13 May 20:12:17 BST 2018

A few weeks ago[1] I thought I had fixed a player loading issue. Further
testing has proven the fix to be incorrect and incomplete. I noticed something
was wrong when the stats Thing count started reading: 18446744073709551615.

That’s over eighteen quintillion Things… hrm…

Obviously the uint64 had gone negative and wrapped around. That indicated more
Things were being freed than created somewhere. This was similar to the issue
I had initially tried to fix. Finding the issue was simple, the Copy added in
the previous fix was wrong. Understanding exactly what had gone wrong and then
deciding on the correct way to fix the problem lead me on a trip deep into the
bowels of WolfMUD’s inner mechanics.

Needless to say, this has delayed the next release of WolfMUD :( The good news
is, my new fix seems to be working. I’ve been running batches of 10,000 player
bots at a time for hours now, and everything seems stable.

That was the state of play Wednesday/Thursday…

I wasn’t happy with the new fix. It required storage of an additional flag per
Thing and prevented the addition of warnings about Free being called multiple
times, which should not occur in normal use.

Since then I have refined my new fix. As a result Thing has a new method
called NonUnique. This will remove the UID from a Thing and allow references
to be used while building temporary stores — such as when loading zones or
players. It also decrements the Thing count by one to account for the initial
NewThing bumping the count up by one. A non-unique Thing can safely be freed
more than once, for a unique Thing a warning will be generated:


  Warning, already freed: 0xc420145b40 *attr.Thing #UID-4M


The point of all this is that the Thing count can be very useful for spotting
coding errors. Especially if the count goes very low or high. In normal
operation a Thing should be unique with only one instance of it in the World.
If a Thing is freed more than once it is a good indication that a reference
has been used somewhere, hence the warning being given.

However, temporary stores require the use of references. It allows Inventory
and Location keywords to be resolved when loading zones and players. It also
allows complex container in container scenarios to be resolved.

To take a simple scenario, in the Tavern there is a chest. The chest contains
a pouch. The pouch contains a ball. Using references allows for the Tavern,
the chest, the pouch and the ball to be loaded in any order. For example we
could load the ball first, put it in the pouch and then put the pouch into the
chest. We could also load the pouch first, put the ball into it and then put
the pouch into the chest. The end result would be the same. The trick is, we
build the temporary store first, using references. Then we use Thing.Copy
which does a deep copy of a Thing, including its Inventory. During the copy
new unique Things are created resolving any references with new unique Things,
including inventory, and can be placed into the game world.

If Things could not be loaded and resolved in any order then Authors would
have to be very careful about the sequence of records when writing zone files.
An idea and limitation I will not even entertain. I would rather make things
incredibly difficult for myself to make things even a tiny bit easier for my
users.

All changes are now on the public dev branch.

--
Diddymus

  [1] Journal for 19th April: ../4/19.html


  Up to Main Index                               Up to Journal for May, 2018