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 #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 arounf suggested by @BjossiAlfreds. Fixes#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, fixes#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 #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 #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 #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.
Otherwise the entities origin might be in the surface, which causes it
to be rendered in full black. This fix is a port from KMQuake2, reported
by @m-x-d. Closes#407.
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.
In src/backends/unix/network.c:
* line 181: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
* line 276: The scope of the variable 'tmp' can be reduced.
* line 665: The scope of the variable 'mcast_addr' can be reduced.
* line 665: The scope of the variable 'mcast_port' can be reduced.
* line 666: The scope of the variable 'error' can be reduced.
* line 775: The scope of the variable 'i' can be reduced.
In src/backends/windows/network.c:
* line 186: Assignment of function parameter has no effect outside the function. Did you forget dereferencing it?
* line 287: The scope of the variable 'tmp' can be reduced.
* line 707: The scope of the variable 'mcast_addr' can be reduced.
* line 707: The scope of the variable 'mcast_port' can be reduced.
* line 1049: The scope of the variable 'err' can be reduced.
* line 1163: The scope of the variable 'i' can be reduced.
In src/client/menu/menu.c
arrayIndexOutOfBounds:
* line 1921: Array 'creditsIndex[256]' accessed at index 256, which is out of bounds.
variableScope:
* line 332: The scope of the variable 'item' can be reduced.
* line 533: The scope of the variable 'x' can be reduced.
* line 533: The scope of the variable 'y' can be reduced.
* line 838: The scope of the variable 'b' can be reduced.
* line 864: The scope of the variable 'b' can be reduced.
* line 1910: The scope of the variable 'n' can be reduced.
* line 2199: The scope of the variable 'str' can be reduced.
* line 2812: The scope of the variable 'length' can be reduced.
* line 2813: The scope of the variable 'i' can be reduced.
* line 3838: The scope of the variable 'c' can be reduced.
* line 4112: The scope of the variable 'scratch' can be reduced.
* line 4181: The scope of the variable 'i' can be reduced.
* line 4345: The scope of the variable 's' can be reduced.
In src/game/player/hud.c
arrayIndexOutOfBounds:
* line 132: Array itemlist[43] accessed at index 255 which is out of bounds.
Itemlist assigned only once, and has only 43 items, better ignore unexisted items.
variableScope:
* line 82: The scope of the variable 'n' can be reduced.
* line 217: The scope of the variable 'x' can be reduced.
* line 217: The scope of the variable 'y' can be reduced.
* line 218: The scope of the variable 'cl' can be reduced.
* line 583: The scope of the variable 'cl' can be reduced.
This prevents gibs and debris being easily destroyed with the rocket
launcher but leaves enough room for the entities being destroyed by
elevators, doors and the like if necessary.
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.
Fixes issue 323.
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.
The actual fix was already committed as part of 69b6e5a. This is just a
little cleanup commit, mainly for documentation purposes.
This closes#320.
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.
1) Do not increment the frame rate returned by SDL by 1. Incrementing
is unnessecary, more or less up to date versions on Nvidias, AMDs
and Intels GPU driver on relevant platform return an value that's
either correct or rounded up to next integer. And SDL itself also
rounds up to the next integer. At least in current versions. In fact,
incrementing the value by one is harmfull, it messes our internal
timing up and leads to subtile miss predictions. Working around that
in frame.c would add another bunch of fragile magic... So just do
it correctly. If someone still has broken GPU drivers or SDL versions
that are rounding down the could set vid_displayrefreshrate.
2) The calculation of the 5% security margin to pfps in frame.c was
wrong. It didn't take into account that rfps can be slightly wrong
in the first place, e.g. 60 on an 59.95hz display. Correct it by
comparing against rfps including the margin and not the plain value.
On Unix platforms unicode is implemented through UTF-8 which is
transparent for applications. But on Windows a UTF-16 dialect is
used which needs alteration at application side. This wrapper is
another step to unicode support on Windows, now we can replace
fopen() by a function that converts our internal UTF-8 pathes to
Windows UTF-16 dialect.
This is a noop for Unix platforms. The Windows build is broken,
the compiler errors out in shared.h. This will be fixed in a
later commit.
Caveats:
* fopen() calls in 3rd party code (std_* and unzip) are not replaced.
This may become a problem. We need to check that.
* In the Unix specific code fopen() isn't replaced since it's not
necessayry.
Resurrect support for render / refresher loadable libraries and use them to implement an experimental OpenGL 3.2 renderer. Please note that the new renderer interface is somewhat different from the original one, old render libraries will NOT work!
there's a target_secret (with targetname "t117"), but no one triggers
it - that's why the help computer shows four secrets, but you can only
get three of them.
Now when you open the door in front of the hidden secret armor
(by shooting it), it'll trigger the target_secret and you can get all
four secrets.
fixes#182
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 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 issue #162.
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.
Until now autoexec.cfg was a special case. It was read several
times, whenever the 'game' cvar was altered or when the client was
restarted. But only if it was in the right directory in the right
position of the internal search path... Remove this altogether and
replace it by an ordinary 'exec autoexec.cfg' at startup.
This may break some mods that depend on an autoexec.cfg if the user has
his own version in ~/.yq2/. Such mods should use default.cfg instead.
This closes issue #163.
In baseq2 there's no need to force a certain damage texture on gunners
since there's only one. Also gunners can't wear the powershield so
there's no need to turn it of.
This was noticed by Maraakate.
This crash was found by DanielGibson, he even guessed the right fix
without having a usable coredump. ;) In boss1.bsp Macron is waiting for
the player, despawning as soon as the player moves to him. After that
the player needs to press 2 buttons, each button triggers 3 flyers. If
the player is fast enough, the first bunch of flyers may spawn before
macron is despawned. Now there's a small chance that a flyer decides to
attack macron... If Macron despwans at the the next frame, self->enemy
is set to NULL (Macron is gone) but nevertheless flyer_fire() is called.
The correct fix would be to call flyer_fire() before Macron despawns,
but that's hard to impossible. So take the easy route and check if
self->enemy is not NULL.
This bug was "fixed" by id with removing two lines in the ground entity
check. When cleaning up the game I added them back... I don't know if
it's really correct to just remove them, but let's try it. This fixes
issue #157.
The old implementation had two problems:
* OSTYPE and ARCH are systemwide defines, overriding them may break
the global libc headers. This is a theoretical problem, I've never
seen it in praxis.
* Not all system set ARCH correctly when building in a chroot env.
For example on Linux ARCH is set to x86_64 when building in an
i386 chroot. Now the user can do something like "make YQ2ARCH=i386"
to get things right.
In lower mines you can drop a rock onto a tank by using a lever.
This was broken, the rock exploded instead of dropping, because debris
is spawned and that debris was solid.
Now the debris is not solid anymore (like it was up to
b4d16ab6b3
"Some additions to last commit:") and it works again
The game code does not include common.h, so it needs to redo this
part for builds without SOURCE_DATE_EPOCH, where BUILD_DATE will
not have been passed in from the outside.
Signed-off-by: Simon McVittie <smcv@debian.org>
For deterministic/reproducible builds (where the same source and
toolchain can be verified to produce the same binary, allowing
maliciously substituted binaries to be detected) it is desirable to
take the software's idea of the build date from the build system;
otherwise, the real-time clock at the time of building affects the
result, making it non-reproducible.
SOURCE_DATE_EPOCH is a distribution-neutral specification for how
to do that. It is meant to be set by meta-build systems such as
dpkg or RPM, using a date/time that is already part of the source code,
for example the date of the latest git commit, the date in
the package's debian/changelog, or the date in the RPM spec file.
See https://reproducible-builds.org/specs/source-date-epoch/ for the
specification of SOURCE_DATE_EPOCH, or https://reproducible-builds.org/
for more information on reproducible builds in general.
The old whitelist was a leftover from the early days of YQ2. It should
run on most / all architectures, as long SDL supports them. As suggested
by smcv in issue #138 generate the OSTYPE and ARCH defines by the build
system instead of hardcoding it.
Savegame compatibility is provided by bumping the savegame version. Old
savegames are compared against the old OSTYPE and ARCH defined, new ones
against the new defines. This compatibility code should be removed
somewhere in the distant future.
not sure if this has any drawbacks, seems to work good so far.
No idea why id apparently deactivated this at some point, maybe to
optimize performance?
Without this change the conditionals at g_misc.c:199 and 381 wouldn't
trigger until level.framenum reach it's previous value, resulting in
much to few debris or gibs being thrown. This fixes#104.
Many thanks to maraakate for the analysis and the idea how to fix it.
This reverts commit 123e409a2e.
This commit breaks several float calculations in subtiles ways. For
example grenates drift to the left. In fact, it's another example why
I'm so hesitant to merge anything that's not a fix for a clearly
reproducable bug. This fixes#99.
This work was submitted by Dmitry Antipov. We stick to macros instead of
inline functions since they're in line with the rest of the code base.
This patch removes several unused functions and tranfers most of the
rest into macros.
See https://github.com/yquake2/yquake2/issues/71
and https://github.com/yquake2/xatrix/issues/4
In ClientThink(), the float value ent->velocity[i]*8 is saved into
a short and if the value is too big for a short, in 32bit gcc builds
the short is set to SHRT_MIN, resulting in the player being pressed
down instead of up.
Now we put the result in a 32bit int first (which should be big enough)
and assign the int to the short. This still overflows, but with -fwrapv
at least in a defined way (most probably the same way the original
binaries did).
And while I was at it, when the game lib is loaded, it prints the date
it was built, this is especially interesting for our Win32 binaries.
In rogue's RHANGAR1 the turret didn't blow up the ceiling when friendly fire
was off, because in ClientTeam() both entities were set to "" (no team),
but OnSameTeam() just did a strcmp() instead of checking this special
case (no team).
We check this now and thus it works. Hooray.
I also refactored ClientTeam() to take the buffer instead of using a
static one and to be static (it's only called by OnSameTeam() anyway).
The savegame table entry for this function was invalid, but it doesn't
need to be saved anyway, so I just deleted it from the table.
COM_FileExtension() was parsing strings from beginning to end, bailing
out as soon as '.' was found and treating everything thereafter as the
file extension. That behavior caused problem with relatives pathes like
models/monsters/tank/../ctank/skin.pcx. The new implementation uses
strrchr() to determine the last '.'.
This fixes issue #48. The bug was introduced in e07294b which replaced
hand rolled code with COM_FileExtention().
Revert "change several strcat calls to Q_strlcat calls"
This reverts commit ab879f1bc7.
Revert "change (v)sprintf calls to (v)snprintf calls"
This reverts commit b46e210d76.
This sanity check caused a too early exit of the function if the player
stood directly in front of a wall and fires the blaster or hyper
blaster. Therefor the wall impact effect wasn't drawn. This commit
fixes issue #6. Many thanks to svdijk for narrowing this problem down to
somewhere between 3.00 and 4.00.
- create an unnamed info_player_start when necessary
- increase the fixup radius of the coop-connector to 550
- some formation improvemens
- add SP_CreateUnnamedSpawn to the savegames and break them again
