Up to Main Index                            Up to Journal for August, 2020

                     JOURNAL FOR FRIDAY 7TH AUGUST, 2020
______________________________________________________________________________

SUBJECT: Saving/loading of in-flight resets and other updates
   DATE: Fri  7 Aug 20:25:06 BST 2020

TLDR; Shiny new update available on public dev branch…

Another week of late nights going into early mornings testing and working on
WolfMUD. As a result in-flight Reset events are now working properly when in a
player’s inventory and the player is saved and restored.

What does this mean? Assume we have a magical jar and once an hour it will
produce a bean, just because — it’s an example:


  %%
        Ref: JAR
       Name: a small pottery jar
      Alias: +POTTERY:JAR +SMALL:JAR
      Reset: AFTER→10M JITTER→10M SPAWN
    Cleanup: AFTER→10M JITTER→10M
  Inventory: BEAN

  This is a small, crudely made pottery jar. In fact it is quite ugly.
  %%
      Ref: BEAN
     Name: a small bean
    Alias: +SMALL:BEAN
    Reset: AFTER→1H JITTER→0S SPAWN
  Cleanup: AFTER→10M JITTER→10M
  OnReset: A soft plink emanates from the small pottery jar.

  This is a small, black bean of some sort.
  %%


You take the bean from the jar and a Reset event is scheduled to occur in one
hours time. After an hour you see the message “A soft plink emanates from the
small pottery jar.”, lo and behold the jar contains another bean! Magical?
Maybe ;)

What happens if you log out of the game world for a while and log back in
during the one hour you are waiting to get your hands on another bean?

This is where the saving and loading of in-flight Reset events come in. When
you log out any in-flight events for items in your inventory are suspended.
When you log back in the events are resumed. So no matter how much you log in
and out it will take an hour of actual game time before you can get your hands
on another bean…

To get in-flight events working properly has been ridiculously difficult and
time consuming — even though the end result is only a handful of commits :(

The Action, Cleanup and Reset events now have a Suspend and Resume method.
Resume was called Reschedule, but it’s since been renamed to compliment the
Suspend method. My initial attempt at recording when an event is due to fire
has had to be reworked — we actually need to record when an event will fire
when in-flight and how long until it fires when suspended. A new Reset.Unique
helper method has also sneaked its way in.

The meaning of what is a collectable item had to change. A collectable item
was anything that didn’t have an origin that wasn’t a player. This meant that
unique and spawnable items could not be collected by players. Now that item
spawning and resets are working it’s possible for players to have spawnable
items in their inventory, see the bean in the above example.

On top of that marshaling players to save them was not saving disabled items,
those items waiting to be reset. See bean again.

There is one semi-kludge in the code I’m not too happy with, well actually
two. The first is that I’ve added two methods, frontend.game.resumeResets and
cmd.quit.suspendResets to resume/suspend events in the player’s inventory.
However, I’m not sure they are in the right place. Maybe they should be added
to the Inventory or maybe Reset type? *shrug* It is what it is for now.

The second kludge is that for a given inventory we don’t know what items are
disabled when loading them from a .wrj file, like a player save file. Instead
all items are loaded initially enabled and we then look for a DUE-IN or DUE_IN
property[1] on a Reset field. If we find DUE-IN or DUE_IN we disable the item
and resume the Reset event.

Ideally we should be able to indicate a disabled item. For example:

  Inventory: A B !C

This inventory contains items A, B and C. Item C is disabled.

This would have the additional benefit of allowing authors to add items that
are not in the game world initially, but reset into the world after a delay.
At the moment saving and loading of in-flight events are only supported for
player files and not zone files.

The second kludge I’m working to fix, but took a break to write this and
release all my other changes onto the public dev branch.

--
Diddymus

  [1] You can write a *.wrj using either DUE_IN or DUE-IN but the server will
      always write files using DUE_IN.


  Up to Main Index                            Up to Journal for August, 2020