Up to Main Index Up to Journal for July, 2020
JOURNAL FOR SATURDAY 25TH JULY, 2020
______________________________________________________________________________
SUBJECT: Update on respawn, in-flight events and duplication issues
DATE: Sat 25 Jul 19:12:56 BST 2020
This has been a long week with some very late nights, and late mornings/early
afternoons to compensate :P
The server has successfully been running my new code for several days with the
quiet zone enabled and all other zones disabled. The quiet zone has one
location with several items, several containers and a Tester. The Tester’s job
is to randomly play with the items — examining, getting, dropping, putting,
taking, and junking them. It’s a very useful testing tool for breaking the
server[1], think of the Tester as being your friendly in-game fuzzer[2].
The new code rewrites the item spawning mechanics and implements a new way of
copying items. The Thing.Copy method has been renamed Thing.DeepCopy — which
makes a recursive copy going through Inventories. The Thing.Copy method has
been reimplemented and is now not recursive. Renaming the existing Copy method
then adding a new Copy method seemed a better idea than adding a LightCopy
method or something similar, although if anyone is running modified code they
will need to check if they need to change any Copy to DeepCopy calls. There
are also some supporting changes, fixes and corrections.
These changes address all of the issues with respawning, in-flight events and
unique item duplication for all of the scenarios I could think of — and a few
the Tester found that I didn’t.
It should now be possible to have any combination of unique, spawnable and
non-spawnable containers and items and have them work as expected.
You might be scratching your head wondering what is the difference between
unique, spawnable and non-spawnable items? Well…
Unique: There is only ever one of the item in the game world. If it
is junked or left lying around for a cleanup it gets reset to
its original starting position. If a player has any unique
items when they quit the items are automatically reset back
into the game world at their original starting positions.
Spawnable: You get or take the item and after a delay another one pops
up in its place. If junked another one will pop up after a
delay. The only way for a player to have a spawnable item is
for it to be obtained in a container. For example a quiver
with a respawning infinite supply of arrows.
Non-spawnable: The most common type of item player’s have. Once a player
gets or takes a spawnable item it becomes non-spawnable, but
may have spawnable content within it. If junked or left lying
around for a cleanup they are disposed of permanently and the
content handled according to whether it is unique, spawnable
or non-spawnable.
Oh bother… While writing the descriptions for spawnable and non-spawnable I
realise I have another issue to address :( When a player is saved I need to
record in-flight resets so a player can’t log out and in again for a quick
reset — or worse, lose the item that had a reset pending. I’ll also need to be
able to load such items and resume their events. *sigh*
Some of the differences between interacting with unique, spawnable, and
non-spawnable items are very subtle. For example if you put something into a
spawnable container before you get the container then the container has not
spawned a copy yet. It’s only when you get the container that it will spawn a
copy — and you expect to get the container with the content that is in it. If
you take a spawnable item from a container then that item should continue to
respawn in the container, independent of whether you took the item before or
after you took the container. And of course, you can have an arbitrary mix of
unique, spawnable and non-spawnable nested containers…
Luckily for authors of zone files this is all taken care of for you. You just
need to specify that A is inside B which is inside C or whatever and whether
each is spawnable or not.
These changes are still not public yet as I’m still testing and tweaking. I
also need to work on saving and loading in-flight events. Thinking about it,
loading in-flight events would allow zones to load items that are initially
disabled and then brought into the game after a period of time. Which could be
quite a nice and useful feature?
On another note, more people are now asking for these fixes to be released
with the body/clothing/health changes included. It’s a significant shift, I
originally planned to release just a hot fix — and all of my changes so far
have been based on the last v0.0.15 public release. There is still time to
sway me either way, just drop me an email at diddymus@wolfmud.org
--
Diddymus
[1] If you comment out ‘td = time.Second’[3] in event/event.go around line
88. Then in the data/zones/quiet.wrj zone file set the Tester’s Action
to ‘AFTER→0s JITTER→0s’[4] the poor Tester will work at full pelt! ;)
[2] Fuzzing: automated testing using random, sometimes invalid, sometimes
unexpected input.
[3] Usually events have a minimum delay of one second before firing.
[4] If you do this and log in the Tester will appear to be sneezing a lot
and not doing much else. This is because he can always sneeze. For other
commands the Tester has to wait for items to reset or he’s trying to do
something he can’t do — like put a ball in a bag when he has no ball
and/or no bag. If you change all of the Reset and Cleanup attributes for
the items to ‘AFTER→1s’ and ‘JITTER→1s’ then the poor Tester will be
much more productive.
Up to Main Index Up to Journal for July, 2020