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.
Commented out the no_stamina bit. Stamina in Rivensin is used for the energy shield and not running. If this was set in a map, the shield was disabled. Noticeable if playing some user made maps and Hell levels in vanilla campaign.
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.
Somehow I must have added that
savefile->WriteFloat( spreadCrouchFactor );
twice when merging the Ruiner/Rivensin changes into the SDK.. damn.
(As it's only read once, all data read from the savegame after it
will be garbage)
I had a crash when creating a Savegame in idAnimState::Save(),
because animator was NULL - so I added a check for that.
The rest has been found with GCC address sanitizer (ASan)
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]").
Cursor now uses 2 different guis based upon aspect ratio just like
the hud. This is due to the translations of of the cross hairs being
off if a 4:3 cursor is on top of a 16:9 render view.
Requires additional key in the player def just like the hud does.
In game menu no longer stretches. Looks much better.
This is the menu that displays the advanced controls.
(DG: based on revility's commit with same message, removed stuff already
implemented here and cleaned up the rest a bit)
pm_crouchviewheight updated. origin was set from near the player's stomach and not the neck
pm_thirdpersonsidescale default value reduced. Player can still adjust the amount in the main menu.
Added new cvar pm_crossHairSideScale
Corrected description of pm_ProjectileOrigin.... this does not effect projectiles. Only the tracers, models or particles attached to them.
adds a new cvar pm_crossHairSideScale to move the view position origin sideways. Useful if pm_crosshairorigin is set to 0 and aiming around corners. weapon projectiles use this as their spawn position. cross hairs use it as the origin of the trace line. default is 0. player should adjust to their liking and current camera settings. If set too far over, the player can shoot around walls.
removed bobbing and jittering while the crosshair origin is set to use a joint on the player model (pm_crosshairorigin 1). Was very noticeable while looking at steps.
Needed if you want to play some of the vanilla doom 3 maps by default. Note that you will need to update more stuff like statements, globals, etc. for the game to start with all of them. Another note that the scripts are not loaded by default in ruiner/Rivensin due to none of the maps being tested. Most of them are not third person friendly. Someday I hope to get a mini version of the campaign ported.
Game will go into first person while at a gui and then back to thirdperson when leaving. Needed for maps which use gui consoles in them. Check comments in code for full details. Probably a better way to do this.
CheckCrossHairOrigin is used when entering and exiting guis to get the player's current setting and restore it when leaving the gui. Check the player.cpp for full details.
This was done so pm_thirdperson wil always reset to 1 when starting the game. If the game crashes or quits while in first person it was starting back up in it before.
New cvar to enable and disable launching projectiles from the weapon's world model barrel joint and also towards the crosshair's position. launchfrombarrel must be set to 0 in projectile def files to use. Done incase a weapon doesn't need it or has issues using it in the future. none currently do.
Changes cross hair trace line origin from the camera's origin to a joint on the player's model defined in player.cpp file
Done this way because pm_modelview cvar has some kind of over ride going on when the levels start. Consider this a work around fix.
Not sure how or why it happened, but the code was causing the bow to use wrong cross hairs, and auto weapon switch. I believe there was a mistake on my end when cleaning up the code in the player.cpp and playercursor.cpp files.
Additionally having a second weapon to use the soul cube hud notice is not needed as the planned weapon is not happening anytime soon.
Only the soul cube can display hud notifications when enough kills are done. this adds support for a 2nd weapon to do so. weapon is not in 2010 but will be 2018 build. Code should still be compatible with 2010 build.
This should fix hdr always resetting every time the game is restarted, thirdperson view sometimes not enabled by default, and the need for pm_modelview to be turned on for cross hair trace line origin fix.
Also cleaned up formatting around hdr cvars, and third person camera cvars.
Enabling the pm_modelview and setting the correct joint in the player.cpp file corrects issues with the trace line used for creating thirdperson crosshair getting cut off early due to objects being to close. Most mostly noticeable shooting around corners.
Stamina is now used for the player's shield spell. hold down the old zoom key to activate while the player has stamina. Calls are made to the player's script to UpdateSkin. UpdateSkin is new and not apart of vanilla d3 or Rivensin 2010 build
Stamina use also is no longer associated with player's movement and does not adjust movement speed.
The telishield key is used via the player script file to check if active and change the torso animations to blocking/spell casting.
Added the telishield key for the player def and script to use. This key disables the player taking damage and can be checked in the script for stuff like changing skins, etc.
cross hair fix: pm_modelview . This cvar changes the origin of the playerview to a joint for the crosshairs. This is set to a joint close to the player weapons to prevent the trace line used for cross hairs stopping too early when shooting around corners.
Additionally pm_modelview's axis is now the renderview axis and not the joint other wise the thirdperson crosshair is displayed in wrong directions.
pm_modelview is now on by default.
adds the telishield key for the player.def & script to use. When set to 1, the player will take no damage. Done this way so we can check it and also apply other effects such as player skin changing.
launch from barrel is no longer needed for projectiles to launch from the weapon's barrel, and then to the thirdperson cross hair position. This fixes the projectiles not launching to the center of the thirdperson cross and also fixes the offset when aiming too high or too low.
projectiles in weapon.def files need launchfrombarrel set to 0 for this work. the crosshair offsets also need to be adjust in the cursor.gui file as each one offset manually in Rivensin/Ruiner 2010 build.
