cvar operations are special commands that allow the programmatic
manipulation of cvar values. 'reset' resets a given cvar to it's
default value, e.g. `reset r_mode' would reset `r_mode` to `4`.
'resetall' resets all known cvar with the exception of `game`.
The code is based upon q2pro.
This is part of issue #414.
44472722e added some sanity checks to the AI code. The checks in
ai_run() are likely wrong because the enemy entity might be already
NULL if we arrive their. By aborting early the code is unable to
determine a new enemy or return the monster to idle state, so the
monster will wait forever for an enemy that'll never come.
This happens only in monster vs. monster fights. Never in monster vs.
player, that game ends if the player dies.
In theory this change should be harmless, because if the enemy entity is
gone it won't generate sound targets now be visible. If the game crashes
by self->enemy being NULL we've got a problem elsewere.
This was reported by @BjossiAlfreds in #483. He also suggested the fix.
When searching for the player FinTarget() always goes after sound
targets and aborts as soon as it finds one. So if the player is
constantly generating sounds - for example firing the machine gun -
there's a high chance that monsters will only hear but never see
him. Work around this by adding a small timeout to player noises, make
sure that at least 3 frames passed since the last noise. This gives
monsters 2 frames to see the player.
This bug was present in the original code, this is a small gameplay
change.
The problem was analysed by @BjossiAlfreds in #436. He also suggested
the fix.
M_MoveFrame() calls first the AI functions that decide if a monster
should attack or not. After that the monsters think function is called
which walks through berserk_frames_stand[]. Even if the AI function found
an enemy and decided to attack, the monster is still standing for this
frame and berserker_fidget() is called. It may override the earlier
earlier decision, aborting the attack. Even worse this may let the
berserker stuck, because AI_STAND_GROUND may be cleared which prevents
further attacks.
This bug was present in the original code, so this is small gameplay
change. It's likely also present in both addons.
Reported and analyzed by @BjossiAlfreds in issue #433. He also suggested
the fix.
Like most other cvars 'sensitivity' allowes for float values. But until
now mouse events were handled as integers which led to some confusing
problems. This was especially noticeable at values lower than 1, small
mouse movements were cut to 0 and discarded. Since the clients movement
code is written in floats and we're already using floats for joystick
movement switch the mouse event handling over to them, too.
This should have any impact on configs were 'sensitivity' is ste to
integral values. If it was set to decimal values the behaviour is now
correct.
This fixes#419.
Check if we're in the requested mode after the fullscreen window was
created. If not: Try to switch again in the requested mode by calling
SDL_SetWindowDisplayMode(). If that's successfull set the new window
size with SDL_SetWindowSize(). That shouldn't be necessary, at least to
SDLs crappy doku, but without the subsequent SDL_GetWindowDisplayMode()
call fails with 'Invalid Window'. Use that call to check if we're now
in the requested mode. If yes, process. If not abort and trigger the
fallback magic. It'll set `r_mode 4` and `vid_fullscreen 0`.
Caveat: In the worst case this will switch the display mode 3 times.
To create the window, to work around the bug and to set a refresh rate.
No problem for flat panels, but my unforgotten Trinitron CRT would
have cried in pain.
* Normaly SDL chooses a sane refresh rate for fullscreen windows. Users
may want to override that, so provide a new cvar `vid_rate`. If it's
set to a value greater than 0, we're trying to get a mode close to the
requested resolution and refresh rate and switch to that.
* A bug in SDL may leave us in the wrong mode, detect that condition and
abort. See https://bugzilla.libsdl.org/show_bug.cgi?id=4700 for details.
This is part of issue #302.
Print a list of all available modes as soon as SDLs video backend
initializes and the real display mode after the window was created
or altered.
This hopefully helps debbuging problem with display mode selection, see
issue #302 for an example.
