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.
While in baseq2 monsters had the abillity to duck it wasn't used
often. The same goes for medics, there are only a few throughout the
whole single player campaign. In rogue things are differed. Due to
some AI changes like support for dodging monsters duck more often and
there a a lot of medics and even it's improved version, the medic
commander.
When a monster dies it's mmove_t is set to the death animation and
it's AI flags are left as they are. When a monster is resurrected by
a medic, the AI flags are reset to 0 and it's spawn function is
called again. Normally this is totally save. But when there're two
medics and both try to resurrect there monster there's a small window
for the monster being respawned without the AI flags reset.
In this case the mmove_t is set to the monsters standard animation,
while the AI flags may be still contain AI_DUCK. When AI_DUCK is set,
but the current animation is not one of the duck animations, the
monster may get stuck. There's even a comment in the code for that
case. ;) Solve this problem by resetting AI_DUCK as soon as the
monster dies.
With this change applied I was unable to reproduce any problem in
regard to medics, medic commanders, resurrection and spwaning of new
monsters.
This closes issue #6.
When the monster was already killed by another monster or a coop player
some references may be NULL and the game was crashed. This was observed
by maraakte, who reported it in issue #164. I've just merged his fix
from q2dos.
teleport_time has nothing to do with teleports, it's just the time
since the last player sound. Rename it accordingly. This was suggest
by maraakate in yquake2 issue #162.
In ai_checkattack() is a check against AI_SOUND_TARGET. If the player
made a noice and the the monster noticed this noise it's true. If
that noice was more than 5 seconds ago the monster forgets that event
and continues with it's search for the player. Otherwise it informs
the surrounding monsters that something interesting has happened and
then returns false. So the problem is: Even if the monster heard the
player and can see him, it aborts at this point.
Fix this by adding an additional visibility check. Do the sound
checking only if the player is not visible, otherwise just continue.
This was reported by shoober420 and debbuged by maraakate. This fix
was DanielGibons idea. This commit fixes yquake2 issue #162.
On most implementations atof() is just a wrapper around strtod().
Calling strtof() saves one cast. For the sake of cinsistency change
atoi() to (int)strtol(), it's a noop. Reported by maraakate in yquake2
issue #160.
I don't think that this has a visible effect, because there shouldn't be
any unknown entities in maps creates with the official entities.def.
This was reported by maraakate in quake2 issue #160.
I don't think that this has any visible effect, but it's saver than
assume that in multiplayer all clients enter the intermission at the
same time. This was reported by maraakate in yquake2 issue #160.
To fix some bug, in baseq2 and xatrix
if(coop->value)
{
if(FindTargeget(self))
{
return;
}
}
was moved from ai_run() to ai_checkattack().
Do the same here, but without the bug from yquake2/#151
