There's a sound commander_sound_hook_retract, it even get's precached,
but it wasn't refrerenced. Analysed and fix suggested by @BjossiAlfreds.
Closes#21.
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.
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 and fixbots 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.
Make the disruptor and it's ammo available by 'give disruptor' and 'give
rounds'. If g_disruptor is set 0 (the defaults) neither the weapon, nor
the ammo is spawned in, if set to 1 it behaves like a normal weapon.
Based upon an idea by @NeonKnightOA submitted in PR #18.
This was requested in issue #17.
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.
The problem was that its head was too close to/in the wall, so the trace
towards the player (to decide if he's reachable) started *in* the wall,
so the wall itself wasn't hit/detected.
Now the trace start is 8 units behind the head and it seems to work.
Fixes#9
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.
This was one of those stupid brainos where you know it better and still
do it wrong... In standard C the return value of a non-void function is
undefined if the closing } is reached. MSVC++5 and 6 returned 1 for
functions with return type int. Since qboolean == int parasite_blocked()
and parasite_checkattack() should return true and not false.
BUT: The true in parasite_blocked() was correct, in the original MSVC++6
build parasites always thought that they're blocked and tried to free
themself.
In parasite_checkattack() the false was wrong, so change it to true. And
yes, the function is crap. The better part of it doesn't make sense and
just burns CPU cycles for nothing. But it's working now and everyone is
happy, so let's leave it alone.
This fixes yquake2 issue #359.
The gibs and debris per frame must be limited to prevent server mem
map overflows. Until now debris and gibs were handled the same, the
debris spawned by rockets and grenates could prevent the actual gibs
of the killed monster from spawning.
Before this change 20 entities were spawned at max. Now up tp 40
enties can be spawned. This needs some testings.
A long time ago in 2b4f223 I introduced a small logic change to the
handling of stacked entities. If two entities were standing on each
other the original code set the movement speed of the upper entity
to 0. It would be pushed or dragged by the lower entity. I changed
that in way that the upper entity got the same speed as the lower
entity. With that change it wasn't pushed or dragged but moving on
it's own. I hoped to fix some of the 'elevator hurts player or monster'
bugs.
That hope was wrong, at a later time we quirked all elevators that hurt
the player. Additionally the change lead to physics bugs if entities are
standing on high speed elevators (more than 200 units per seconds). So
revert it
When killing the enforcer with one shot (instead of damaging him first
without killing, which will switch to the bloody skin), the skin wasn't
changed. Now it is.
BjossiAlfreds
Yamagi Burmeister
Daniel Gibson
Angus Freudenberg
Scott