Up to Main Index Up to Journal for March, 2017
JOURNAL FOR SUNDAY 19TH MARCH, 2017
______________________________________________________________________________
SUBJECT: Performance improvements + junking and resets
DATE: Sun 19 Mar 23:12:51 GMT 2017
Recently I’ve been making some more performance improvements to WolfMUD.
String concatenations have been eliminated in exits.List and the amount of
garbage it produces has been reduced.
There has also been a change to inventories. The Inventory attribute has a new
Move method. This allows the common operation of moving a Thing from one
inventory to another to be more efficient than an Inventory.Remove followed by
an Inventory.Add. Previously Inventory.Remove and Inventory.Add both called a
number of finders: FindLocate, FindNarrative and FindPlayer. These are all
quite expensive operations and the results could not be shared between Remove
and Add calls. The new Move method only calls the finders once.
As a side effect Inventory.Remove and Inventory.Add are now implemented using
calls to the Inventory.Move method. This helps reduce maintenance by having
the code in one place.
All currently implemented commands have been updated to use Inventory.Move
where appropriate. The state.AddLock method has also been updated to check for
a typed nil as well as an untyped nil due to the way Inventory.Add is
implemented and the way it calls the Inventory.Move method.
After doing all of that, I’m now back to working on object reset — and have a
prototype working.
The attr.Locate attribute has been updated with two new methods: Origin and
SetOrigin. These methods query and set the origin for a Thing — its initial
starting location (Inventory). The zone loader has been updated to set the
origin of a Thing when populating the world.
There are also two new commands: $RESET and JUNK. The scripting only command
$RESET places a Thing back into the world at its origin. Currently it has a
default, hardcoded reset message of:
“There is a gentle pop and <name> appears.”
The second command, JUNK, allows players to dispose of items they no longer
need. The JUNK command currently contains a lot of experimental code that will
eventually become a Reset attribute. While developing resets it’s been
convenient to have it in the JUNK command itself.
At present the JUNK command can junk and reset items. The items can even be
containers and the content junked recursively. It can also check for JUNK
vetoes on items in a containers recursively. To help with testing I’ve added a
small leather pouch to the Zinara zone:
%%
Ref: O4A
Name: a small leather pouch
Aliases: POUCH
Location: L1
Inventory:
This is a small pouch made of soft dark leather.
%%
This can be used to test recursive junking by placing items in it and then
placing it inside the chest and junking the chest. The lattice has also been
given a JUNK veto. This is useful for placing in the chest, or in the pouch in
the chest and then trying to junk the containers — which should be vetoed.
At the moment if you try and junk a container that contains a non-junkable
item it gives the message:
“<name> seems to contain something that cannot be junked.”
I’m wondering instead if the junkable should be junked while keeping the
un-junkable. For example, if we put the lattice into the pouch, then put the
pouch into the chest, then junk the chest — should we be left with just the
lattice? It could lead to some interesting situations. Imagine your player has
an expensive statue that they can sell for money or use to solve a puzzle to
gain something even more valuable or useful. However the statue contains an
un-junkable key that they can only gain by junking — and sacrificing — the
statue :)
Thoughts and comments in an email appreciated: diddymus@wolfmud.org
Until I implement the Reset attribute items reset after a fixed 1 minute plus
a 30 second jitter.
At the moment all items reset independently from each other. So if you create
a container that contains some initial items they will all reset independently
and could result in the items being reset into the container that a player
might have. What should happen is that the container does not reset until all
of its content is also ready to reset. This is being worked on already.
My initial thoughts on a definition for a Reset attribute are:
Reset: AFTER→5m JITTER→1m SPAWN→false WAIT→<ref ...>
This lets you specify how long to wait before an item resets — with jitter. It
lets you specify whether the item is a spawner. That is, does a new item
appear after the item is taken. An example could be an apple tree. When an
apple is picked another one will appear after the reset period. If the item is
not a spawner it will only reset when disposed of.
The WAIT is something I just thought of while writing. It could allow an item
to wait on other items before being reset, allowing for resets to be chained
together[1]. It might be possible that containers could use this mechanism
automatically so that they wait for their contents so that their contents
resets with them?
Once all of this is worked out and completed objects will be able to reset
when junked, sold, destroyed, killed or just left lying around.
Actually when an item is “just left lying around” brings me to another
attribute that will be needed. A CleanUp attribute that specifies when to
clean up after an item. I’m currently thinking:
CleanUp: AFTER→5m JITTER→1m
This simply says that after the given period — with jitter — an item will
automatically be removed and reset if left lying around.
Actually there needs to be another attribute — or two. There needs to be a way
of being able to specify messages for when an item is cleaned up or reset. I
had been thinking along the lines of ‘On’ messages. For example:
OnReset: You notice a small leather pouch on the ground that you could
have sworn wasn't there before.
OnCleanup: The small leather pouch slowly fades away and is gone.
It would also be nice to be able to specify custom enter and exit commands for
mobiles (creatures & critters) when we have them, OnEnter and OnExit. Maybe
what is needed is a general Message attribute using the recent keyed string
list format?
Messages: OnReset→You notice a small leather pouch on the ground that you
could have sworn wasn't there before.
: OnCleanup→The small leather pouch slowly fades away and is gone.
Again, thoughts and comments in an email appreciated: diddymus@wolfmud.org
Most of the above is updated to the public dev branch right now. But take care
as the object resets and junking is experimental and being actively worked on.
If you want to disable junking and object resets with the latest code simply
comment out the AddHandler line in the init function of cmd/junk.go and
recompile.
--
Diddymus
[1] I thought the Java version had this for the Scythe and that the Scythe
only reset when the shed key reset. However after checking the archives
this does not appear to be the case.
Up to Main Index Up to Journal for March, 2017