#6 testing, checking, incl.documenting
first, thats not easy - but nothing is easy without a try-
documenting: not only save it in ones brain, write it
down, so other can understand it, thats what you are
doing in the game, whats happening, sometimes a
screenshoot may be necessary to show hard to reproduce
effects.
checking: never believe a already solved bug, could not
happen again. Its hard to notice things, best way is a
list like in game-playing (you know? ever check the
fire-mode of your weapon or you cry cause it was
single-mode ..)
testing: - write down the "cheats" (=debug-features)
how to start:
et +set sv_pure 0 +set fs_game otc6
you need to load the map manual:
/devmap radar
for checking server-bullet-shooting:
/cg_railTrailTime 1000000
/g_debugBullets 1
how to check the client bullets (thats the one shown on
the players screen ... but not the one to count hits -
whats the diff. between client-server?)
/cg_debugPosition 10
how to check the animations:
player: /cg_debugAnim #
# = a number
for example animation-bugs dont need to be in the
source-code - some are only in the model-scripts!
and i dont want to explain how to make screenshots, how
to check how big such a file is and so on. there are
already a lot of debug-Vars - check the code, try, and
document.
how to communicate, to whom to tell whats wrong ...
