Especially after savegame load not all slots in the edicts array may be
used. Check if the current entity has a classname string. This is
another part of yquake2/yquake2#430.
It's unclear were this comes from, maybe it's a bug in the collision
detection. Because the collision detection is ununderstandable for
people without 'special brain type game programming' like me and even
bugfixes to it have a very high chance to break things, work around
it. Save current position, perform move, check if we're in the world
model. If we are revert to old position.
Debugged and work around suggested by @BjossiAlfreds. Fixes
yquake2/yquake2#443.
This is another code inconsistency, we must not clamp the current health
to the client max health (which apparently is always 100) but to the
current max health of the player entity.
Analyzed and fix suggest by @BjossiAlfreds, fixesyquake2/yquake2#441.
This is another corner case. Parasites have a bbox height of 24,
walkmonster_start_go() hardcodes a viewheight of 25. Therefor most
traces in other functions like visible() overshoot the parasite.
Fix this by not overriding the monster viewheight.
Analyzed and fix suggested by @BjossiAlfreds. Closes issue
yquake2/yquake2#440.
This rather sophisticated command prints all entities of one or more
given classes and their coordinates. Possible classes are:
* ammo
* items
* keys
* monsters
* weapons
Classes can be combined into one command, e.g. `listentities ammo keys'
would print all ammunition and all keys. The special class `all` prints
all entities, regardless of their class.
The command is protected by `cheats 1`.
This is part of issue yquake2/yquake2#430.
A command that teleports the player to abitrary locations was often
requested and may be helpfull for debugging, so finally add it. It works
like a normal teleporter: It moves the player to the requested location,
clears all movements, tells the server and clients that the entity just
teleported and telefrags everything that's in the target location.
The implementation does not verify if the requested location is save,
the player may teleport into the world model or even the void. But the
requested Z coordinate is elevated by 10 units to prevent the player
getting stuck in the floor.
The command is protected by sv_cheats.
This is part of issue yquake2/yquake2#430.
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.
Don't know if this has any noticeable impact, but it looks like the
commit was wrong... Revert this in an own commit and look here if there
problems with the gekk.
@DanielGibson missinterpreted the code, the negation must be applied to
target->svflags only. Otherwise the codition is always true and the
homing rocket never aquires a target.
This is not strictly necessary since the main executable should provide
the symbols, but it may increase compatibility with other source ports
and underlinking is never a good idea.
This fixed bug #357 - the problem was that
client->resp.coop_respawn.weapon and .lastweapon (pointers to gitem)
were not properly initialized when loading a savegame. Now those fields
are saved (=> we had to bump the savegame version) and for old savegames
client->resp.coop_rewspawn is initialized from client->pers, as a hack
for backwards-compatibility.
