These bugs are related to time of access, where fields of e.g. a
player or monster struct is accessed upon missile impact (instead
of missile launch), and at this point, the monster may be dead, or
the player may have left the game, resulting in accessing garbage
data that may have been overwritten by other data (e.g. new monster
spawn or new player joining).
One way to resolve this issue is to store e.g. the damage in the
missile struct when lanuching the missing. This way, the missile
would have all information required to know its damage on imact
instead of having to rely on outside sources that may no longer
be present.
If `dObject[dx][dy]` is zero, then `pn = -1`, which causes an
out-of-bounds access to object. If the memory `object[-1]._otype`
is either 84 or 85, then the player is randomly teleported to the
location of the Vile Betrayer quest. This can be triggered either
by interacting with a holy shrine or by casting phasing.
"Wherever you go, there you are"
- Add file documentation to about 1/4 of the files in Source
- Copy over a lot of the documentation from the sanctuary/notes repo
- Standardise all the existing documentation
- Create a configuration for Doxygen
- Add more documentation (engine.cpp is now fully documented)
Now diablo.h is treated in the same way as all other header files of
Source, as it only contains the declarations of global variables and
functions of diablo.cpp.
Besides consistency, this also enables mods to include diablo.h just
like any other header file without having to include every header file
(and without having to include C++ specific aspects of the now all.h).
qndel
Robin Eklind
Anders Jenbo
pionere