mapartist print|set|get|clear
print: prints the map artist player ID
set: sets the map artist player ID to the currently logged in player
get: returns the current map artist player ID
clear: erases an existing map artist record in the current map
modeinfo list|get|clear|<modelist> <modeflags>
list: lists current modeinfo entries
get: returns list of current modeinfo entries
clear: erases current list of modeinfo entries
<modelist> <modeflags>: specifies flags for a list of modes
DOCREF modeinfo mapartist
The server keeps track of every player ID that ever connected successfully.
This database stores the last names and IPs used by the player and the
last countries the connections came from. Some stats are counted, like
"time connected" and "total tks". Most importantly, the database stores
rights (like admin) and restrictions (like ban). All rights and
restrictions are kept as dates (or timecodes), so, for example, if your
ban date is in the future, you are banned - and if it's in the past, you
can play. The collected stats are meant to help server owners at managing
players - especially, if they want to give someone admin rights.
The database is periodically saved to a file and read from that file on
startup. The default file is config/servervita.cfg and one backup is kept
in config/servervita_bak.cfg. During server start, if the regular file
can't be loaded, the backup is tried instead.
While the server is running, it checks periodically for a file named
config/servervita_update.cfg, and if the file exists, it is renamed to
a backup filename including a timecode and read and merged into the
database. The automatic rename makes sure, that a file is only read once.
Using such updates, a server owner can easily give several people admin
rights or for example, add clan tags for a whole list of IDs. (Yes, the
database also stores a clan tag for every ID...)
The database also stores two short comments for every ID. One can only be
read by server admins, but the other one is public. The public reason, for
example, can state a reason for a ban.
One database record takes up 264 bytes of RAM. During autosave, accounts,
that have not been used for a specified time (default 12 months), will
not be written. After a server restart, those old records will be gone.
Currently, there is no process in place, to also clean up old records
from RAM. Maybe, that'll be added later...
Uses own thread to actually write to logs, so the main thread can't be
blocked by a slow logfile. Log entries are buffered in two ringbuffers,
one for the main thread and one for all other threads. The main thread
will copy the second buffer to the main buffer periodically. The main
thread buffer is read from the log worker thread.
Since two buffers are kept, there are now several functions to add a log
entry:
mlog()
for main thread functions only: will never block
tlog()
other threads only: may block, until main thread copied some entries
xlog()
automatically determines, which thread it's been called from and
then writes to the proper buffer (will block accordingly)
To avoid improper usage, mlog and tlog verify, if they are used correctly.
(Only for debug builds. An assert triggers, if necessary.)
(to avoid casting IPs to signed integer)
also mute single number debug messages for compound data structures like
string and key: no longer print a debug message for every char of a string
Instead of a list of specific map+mode combinations the maprot now only
contains general rules for maps and game modes. The server then calculates
the list by itself when needed. The server accounts played maps and modes
(and map+mode combinations) and calculates the list specifically not to
overplay maps or modes.
May need further testing.
A list of parameters is read from config/serverparameters.cfg once per
minute and the values written to corresponding server data structures.
If the binary is compiled in debug mode, starting a dedicated server
will write a blank config file with all possible parameters and their
descriptions, sorted and grouped into chapters.
The name of the config file can be set with the commandline parameter -A.
So far, syntax errors are not reported. Instead, it's possible to dump
all current values to a file every time something changes.
"readserverconfigsthread" gets triggered by poll_serverthreads() once a
minute to check the filesizes of all server config files. Altered files
get loaded into memory.
poll_serverthreads() in the main thread then processes the buffered files
one at a time. During processing, a semaphore is locked, so that other
threads can use the data structures derived from config files - if they
use the semaphore to lock the ressource.
Using the data from main thread can be done without using the semaphore,
since _all_ changes are done in the main thread.
If the main thread wants to update data that is locked by a thread, the
main thread will defer the changes for a minute. The main thread will
never lock.
also:
* -Y now sets the private key for the server
* -m without argument uses default masterserver URL
* servers run LAN-only by default (set ms URL and private key to
register with the master)
* use generic locale "POSIX"
almost 3000 lines of "errors" contained one actual memleak, one actually
unused variable and three actual ambiguous code parts
from cppcheck website: "The goal is to detect only real errors in the
code (i.e. have zero false positives)." :)
thx for finding five problems in our code
- collect most sound infos in one table and use it to generate the menus
- no more sound category checks with ranges
- now only PAINx and FOOTSTEP* sounds use hardcoded index numbers
enumsounds <list of categories>
Lists sound index numbers and short descriptions for all sounds of one
or more categories. The argument should contain one or more of PAIN,
OWNPAIN, WEAPON, PICKUP, MOVEMENT, BULLET, OTHER, VOICECOM, TEAM,
PUBLIC, FFA, FLAGONLY. All sounds with at least one of the flags will
be listed. Flag names prefixed with "!" will exclude all matching
sound from the list.
Example: /echo (enumsounds "VOICECOM !PUBLIC") will list all voicecom
sounds that are for teams only.
DOCREF enumsounds
scriptcontext and isolatecontext now allow plain text mnemonics for
context level arguments (one of CORE, CFG, PROMPT, MAPCFG, MDLCFG)
also:
- cleanup (some dead code and dead prototypes removed)
- some stuff renamed
- script errors now show context levels
- conc is no longer thread-safe (but slightly faster)
DOCREF scriptcontext isolatecontext
The edit protocol now allows the following commands in multiplayer:
arch, slope, edittag, edittagclip, selectionrotate, selectionflip
also:
mapenlarge has been limited to size 10 in multiplayer
entitiy undelete in multiplayer has been fixed
SV_EDITS, SV_EDITD and SV_EDITE are to be cleaned up with a protocol bump
DOCREF arch slope edittag edittagclip selectionrotate selectionflip
same as looplist, but it automatically counts the loops in "i", starting
with 0.
Example:
a = [u v w] ; b = [x y z]
looplisti $a m [echo $m (at $b $i) $i]
u x 0
v y 1
w z 2
DOCREF looplisti
Check printf-like functions like conoutf, if format strings and argument
lists match.
This commit also fixes a lot of code parts that actually had mismatching
argument lists - or did things, that this check does not like.
numtime() was rewritten in an ugly but very portable fashion (it's
recommended to stay away from "long long" format entries, because errors
usually only come up at runtime).
(some code was copied from sauer)
Commit fixes broken "gonext" command, among other things reading time
from maprot, and it does random result of this command.
It also removes get_next() function, because it messes up the maprot,
so shouldn't be used.
* replaces filtertext() with a version with a dozen of single filters
that can be used in any combination
* defines classes of allowed characters for strings for various uses
(see protocol.h line 153ff)
* now the allowed charset of, for example, player names is defined
in one location only
* fixes issue #58
This commit establishes an extensible way of storing additional data in
map file headers. Those header extras can be permanent, like the embedded
config file or be used only once after map load like the undo/redo data.
Additional extra data can be easily added and will not break backward
compatibility, so this map format should hold up for quite some time.
To make things easier for mappers, maps can now be saved without invoking
the various optimisations. That, in combination with the stored undo data,
means, that editing a map can be picked up at exactly the same state, as
the map was saved in.
Maps will automatically be written in the appropriate fashion, depending
on the situation:
1) for sendmap: no optimisation, no undo data
2) savemap during editing: no optimisation, with undo data
3) savemap when not editing: optimised, no undo data
4) savemapoptimised: optimised, no undo data
(For savemap to save different maps during editing, the variable
preserveundosonsave has to be "1". It is "0" by default.)
All of the above map files can be played without problems - they only
differ in file size. (However, maps with undo data may be too big to send)
The new command "embedconfigfile" will load the config file, include it in
the map header and rename the original text file.
"extractconfigfile" will write an embedded config file to a separate file
and remove it from the map header.
Embedded config files take precedence over regular config files and
therefore make it harder for cheaters to play with modified config files.
further changes: cleaned up some debugging code; more ASSERTs
ac-stef