The commanders body entity is special, because it's spawned in god mode.
That's no problem in the baseq2 and addons campaigns. But it may break
some custom maps and prevents some hacks, one example is putting the
entity inside an killbox.
Submitted by Евгений T.
1: The Vanilla Quake II behaviour, footsteps are generated when the
player is faster than 255.
0: Footstep sounds are never generated.
2: Footstep sounds are always generated.
Defaults to `1`, cheat protected to `1`.
Closes#666.
$PROCESSOR_ARCHITECTURE seems to contain the architecture of the host,
but we need the architecture the current MinGW shell is targeting.
$MINGW_CHOST seems to be just that, and on my system it's either
i686-w64-mingw32 (mingw32.exe) or x86_64-w64-mingw32 (mingw64.exe)
(No idea what it looks like for Windows on ARM...)
As fixing this would otherwise break existing savegames, I bumped the
SAVEGAMEVER to "YQ2-4" and added a quirk for older savegameversions:
On Windows i386 savegames that contain "AMD64" instead of "i386" as
architecture are also accepted.
(For YQ2-1 this didn't seem necessary, apparently "i386" was hardcoded)
src/client/refresh/gl1/gl1_model.c:39:6: warning: type of ‘LoadSP2’ does not match original declaration [-Wlto-type-mismatch]
src/game/g_turret.c:29:6: warning: type of ‘infantry_die’ does not match original declaration [-Wlto-type-mismatch]
src/game/g_spawn.c:43:6: warning: type of ‘SP_info_player_intermission’ does not match original declaration [-Wlto-type-mismatch]
In coop it's often hard to get on the same elevator together, because
they're immediately triggered once the first player steps on it.
This cvar sets a delay (1 second by default) for the elevator to wait
before moving, so other players have some time to get on it.
If you like elevators/platforms that suck, just set it to `0` :-P
Currently only used in func_plat, if it turns out that other entities
are used for automatically triggered platforms, we'll have to adapt
those as well (I guess wait_and_change() is generally useful for that).
We're not bumping the savegame version because they should only break in
an uncommon corner case: *Coop* savegames created with clients including
this change will not work on older clients - SP savegames are not
affected and old savegames on new clients also still work.
In coop a weapon can be picked up only once. That's annoying, because in
coop ammunition is sparse and not getting the ammunition that comes with
a weapons make things worse. When `coop_pickup_weapons` is set to `1` a
weapon may be picked up if:
1) The player doesn't have the weapon in their inventory.
2) No other player has already picked it up.
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.
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.
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.
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.
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().
- 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
