Up to Main Index Up to Journal for June, 2020
JOURNAL FOR MONDAY 29TH JUNE, 2020
______________________________________________________________________________
SUBJECT: More problems (and solutions!) for the respawn issue
DATE: Mon 29 Jun 18:52:16 BST 2020
This weekend has been spent exclusively working on the container spawn bug: If
you pick up a spawnable container and then take a spawnable item from that
container it causes a nil pointer panic in the reset code.
I’ll stick with my example of a ball that is in a pouch and the pouch is in a
chest for illustration purposes. All three items are spawnable.
If we pick up the chest in its initial state a copy is made and given to the
player. The original is removed from play and scheduled for a reset so that it
can respawn. The copy given to the player has the Reset attribute removed so
that if the chest is put down and picked up again it won’t trigger another
respawn. The origin — where the item will respawn — is cleared for the chest
and all of its content. This makes the items collectable, that is the player
can keep them.
The problem arises when we then go to take the pouch from the chest. It still
has a Reset attribute but no origin. As before we make a copy of the pouch and
remove the original from play for a reset, but the reset has no origin to
reset at — and we then panic.
The correct fix here is to reset the origins of the copies. Then the copied
ball will respawn in the copied pouch and the copied pouch will respawn in the
copied chest. For the chest we still want to clear the origin so the copy
doesn’t respawn. If the copied pouch is removed from the chest then a copy of
the copy is made and the original copy is removed from play and scheduled for
a reset. As far as I can reason this is what we expect to happen — we expect
to have a chest that respawns pouches — picking the chest up and taking it
shouldn’t change that behaviour.
Would junking, or dropping and have a cleanup occur, on the copied chest cause
problems with the copied pouch? It shouldn’t as the copied pouch is always in
the copied chest — either in play or out of play. Only a copy of the copied
pouch is ever removed. So when the copied chest is junked or cleaned up the
copied chest will be reclaimed as well.
There is another issue I found while debugging. If you take the pouch from the
chest, in its initial state, you get the copied pouch and the original pouch
is put out of play for a reset. If you then take the chest the out of play
copied pouch in the copied chest does not copy the in-flight reset event — the
copied pouch just stays out of play and is reclaimed when the copied chest is
disposed of. This is due to the Reset event — also the Cleanup and Action
events — not copying in-flight events. The problem here is that you cannot
query a time.Timer to see how much time is left before it triggers.
I think I can solve this by storing when we expect the event to trigger. If
the time is 18:15:00 and we set a Reset event to happen in 30 seconds we can
record the event is due at 18:15:30. In the chest example if we pick the chest
up at 18:15:15 we can work out that the copied pouch should have a Reset set
15 seconds from now and create the missing in-flight event. This could mean
that an event may be delayed by a second or two due to scheduling, system load
and other delays, but it’s the best solution I’ve come up with so far :(
As you can probably tell this problem of spawning, copies and copies of copies
takes a lot of thinking and reasoning to sort out! Programming is not always
just about sitting at a keyboard and banging out some code.
There is also one more bug I found. If the chest is in its initial state and
anything is put into it the copying duplicates items. For example there is a
curious brass lattice, currently found in the pawn shop, that is supposed to
be unique. If it is put into the chest and the chest then taken the chest will
respawn with another lattice in it *sigh*
A fix for this would be to take the spawnable out of play and junk any content
it may have before scheduling the reset. The JUNK command and cleanups already
recurse into containers, so this problem is specific to resets when spawning.
That’s three problems and three solutions — not bad. Just need the code and
then what? I need to get the fixes out to people. I could make the fixes on
the dev branch and cut a new release. However, the dev branch has work in
progress for combat as well as other improvements. Combat isn’t finished yet,
but is it in a stable state where players could use clothing and such? The
alternative would be to fork a hotfix branch specifically for these fixes,
create a release from that and merge those fixes back into the dev branch.
Which would probably make a mess of my git repository which has been quite
clean up to now.
So the question is what do people want? A hot fix release or a release with
the fixes plus the new bodies, clothing, HOLD WEAR & WIELD commands plus a few
improvements made along the way? Drop me a comment: diddymus@wolfmud.org
--
Diddymus
Up to Main Index Up to Journal for June, 2020