it could happen that UIs are added to the internal list twice,
and also that the last UI wasn't removed from the list when a new one
was focused fast enough.
That should work better now, I hope I didn't break anything..
Some entities wrote the handle from gameRenderWorld->AddLightDef()
into savegames and reused it after restoring it.
That's a bad idea, because at that point the handle most likely belongs
to something else (likely some idLight). The most visible issue this
can create is that the flashlight may not work correctly after loading
a savegame with flashlight on, when it happens to alias a light that's
updated each frame to (mostly) being off..
The correct way to handle this (THAT FOR SOME REASON WAS ALREADY
IMPLEMENTED IN D3XP BUT NOT THE BASE GAME - WHY?!) is to get a fresh
handle with AddLightDef() when restoring a savegame - unless the handle
was -1, which means that the light didn't exist when saving.
fixes#495
Some level scripts in d3xp (erebus4, erebus4, phobos2) use
$entity.startSoundShader( "", SND_CHANNEL_BODY );
(or whatever channel) to stop the sound currently playing there.
With s_playDefaultSound 1 that results in a beep..
Added a special case to that event implementation to call StopSound()
instead when the soundName is "" (or NULL)
- TestHugeTranslation() prints positions (and asserts only afterwards),
from "Work around assertion in alphalabs4, fix#409"
- idCompiler::CompileFile() prints proper filename
from "Fix usage of invalid pointer in idCompiler::CompileFile()"
idClipModel::axis is an idMat3 rotation matrix.
Usually it's an identity matrix, but if the player is pushed around by
an idPush entity it's modified and apparently can (wrongly) remain
modified, possibly when saving while idPush is active.
This seems to happen sometimes on the crashing elevator in game/delta1.
The fix/workaround is to reset it to mat3_identity when loading a
savegame.
like the dhewm3 version and the OS and architecture of the dhewm3
version that created the savegame.
Also added an internalSavegameVersion so be independent of BUILD_NUMBER
fixes#344
"Fix "t->c->value.argSize == func->parmTotal" Assertion in Scripts, #303"
had broken old savegames because the script checksum
(idProgram::CalculateChecksum()) changed, see #344.
This is fixed now, also the BUILD_NUMBER is increased so old savegames
can be identified for a workaround.
Don't use this commit without the next one which will further modify the
savegame format (for the new BUILD_NUMBER 1305)
If a "class" (object) in a Script has multiple member function
prototypes, and one function implementation later calls another before
that is implemented, there was an assertion when the script was parsed
(at map start), because the size of function arguments at the call-site
didn't match what the function expected - because the function hadn't
calculated that size yet, that only happened once its own
implementation was parsed.
Now it's calculated (and stored) when the prototype/declaration is
parsed to prevent this issue, which seems to be kinda common with Mods,
esp. Script-only mods, as the release game DLLs had Assertions disabled.
If you save, you get a message like "Game Saved..." which goes away
after a few seconds. This happens at the very end of idPlayer::Save():
if ( hud ) {
hud->SetStateString( "message", /* .. left out .. */ );
hud->HandleNamedEvent( "Message" );
}
And handled in hud.gui, "onNamedEvent Message { ..."
However, if you save again before it's gone, it'll be shown after
loading the savegame and not go away until you save again..
This works around that issue by setting an empty message after
loading a savegame.
The underlying problem (which is not fixed!) seems to be that the
transition GUI command (that's executed when hud.gui handles the
"Message" event that's used to show this message) is probably not
properly saved/restored so fading out the message isn't continued
after loading.
For some reason the idMoveableArrow's animator didn't have a modelDef,
which caused masterAnimator->GetJointTransform() to return immediately
without setting masterAxis or masterOrigin - so they contained garbage
data which lead to NaNs which lead to trouble.
I check for that issue now to make sure they're initialized, but I'm not
100% sure this is a proper fix - the underlying issue is that this
animator has no modelDef. Is that bad? Could it create other issues?
No idea.
I hope I guessed this right: This could prevent the rare assertion
in RenderWorld.cpp:954 ("bounds[0][0] <= bounds[1][0]
&& bounds[0][1] <= bounds[1][1] && bounds[0][2] <= bounds[1][2]").
it was caused by decals of size 0 (when the arrow hits the floor)
at least in Rivensin this caused trouble, so it seems likely that it's
responsible for some of the reported Dentonmod crashes as well
so mod authors can tell cmake to call it mymod.dll instead of base.dll
or d3xp.dll
and the compiler defines are also easily configurable now
I also added a comment to EndLevel.cpp, which was released with the GPL
source (and in d3xp/ it already existed in the SDK), but has not been
used to build the dlls.
I created this repo from the original dhewm3 repo, but I used
git filter-branch to kill all the files that are not needed to just
build base.dll and d3xp.dll (or .so or .dylib or whatever).
So this is basically just the files the original Doom3 SDK had, but
taken from dhewm3 instead (and thus GPL licensed and patched for
64bit-support etc) + some dhewm3 specific stuff + CMakeLists.txt
to build them.
The git filter-branch details:
filter-branch -f --prune-empty --tree-filter /tmp/killkill.sh @
## /tmp/killkill.sh:
#!/bin/sh
find . -exec /tmp/removeothers.sh {} \;
exit 0
## /tmp/removeothers.sh:
#!/bin/bash
FNAME="$1"
if [[ $FNAME == \./\.git* ]] || [[ $FNAME == \./d3xp/* ]] || [[ $FNAME == \./game/* ]]
then
#echo "ignoring $FNAME"
exit 0
fi
if ! grep -Fxq "$FNAME" /tmp/d3sdklist.txt
then
#echo "REMOVING $FNAME"
rm -rf "$FNAME"
fi
exit 0
## /tmp/d3sdklist.txt was is just a textfile with one path per line with
all the files (and directories!) I wanted to keep, like:
.
..
./sys/platform.h
./framework/Game.h
./config.h.in
./CMakeLists.txt
## ... and all the relevant files from the SDK
Sometimes memory was allocated with new[] but freed with delete instead
of delete[], which is wrong.
And there were some small memory leaks, too.
Furtunately clang's AddressSanitizer detected all that so I could easily
fix it.
(There seem to be some more small memory leaks which are harder to fix,
though)
The assertion in idBounds::operator-(const idBounds&) was triggered
from idWeapon::Event_LaunchProjectiles() (ownerBounds - projBounds)
It only happened when using the BFG.
So I added a check to make sure calling operator- is legal.
I guess this also caused #122
While I couldn't reproduce the crash, according to the bugreport it
happens if renderSystem->GetScreenWidth()/Height() returned 0 - and
that is indeed the only plausible reason I can imagine for it.
So I check for that case and handle it gracefully by defaulting to
4:3 FOV values.
Added r_aspectratio -1 which means "auto" (as new default).
This mode sets fov_x and fov_y according to screen-width/height.
=> No need to set r_aspectratio manually anymore (assuming your display's
pixels are about square).
The standard aspect ratios can still be enforced as before, though.
This was only implemented with MSVC style asm.
Comments suggest that it was used to help catch invalid FOV calculations,
which were probably only happening with ancient compiler bugs.
(Except for handling of longs in TypeInfo and win32-only Maya import stuff).
sizeof(long) == sizeof(int) on x86 and win64,
but not on 64bit (x86_64) linux/unix/osx/.. so they should be avoided.
Monsters got stuck in same places of d3xp because PVS calculations
returned that they were not in the players PVS.
This only happened on LP64 systems like Unix/Linux amd64 where
sizeof(long) == 8 - it did not happen on Win64 because it's LLP64, i.e.
sizeof(long) == 4 (like on x86 32bit).
Bit fiddling code in Pvs.cpp seemed to assume that sizeof(long) == 4
like on win32.
Fixes#7.
