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