- Fixed: HasWeaponPiece assumed that once a piece was given, it would not
be removed. The easiest way to break this assumption is by loading an
earlier save where you had fewer pieces. (The catch being that if you
removed all pieces, it would notice that.)
- Quake scaling should be handled for each quake. The former
implementation was potentially taking flags from one quake and applying
them to another, which is broken.
- Remove all the int<->float conversions.
- This is RandomPick but for floats. Considering what RandomPick
translates into in the scripting branch, I hope I don't regret not using
type inference on RandomPick instead of creating a new keyword.
- When using both scaling flags, by default, the effect only reaches half peak going either way. This forces it to go all the way to the top (or bottom if using QF_MAX) before scaling back to its original height..
- QF_SCALEUP behaves like QF_SCALEDOWN: it gradually scales the tremors, only going upwards.
- QF_SCALEUP and QF_SCALEDOWN can be combined to make an earthquake that gradually smoothes in and out.
- QF_MAX can be used to invert this behavior, where it starts at the peak of the amplitude, fades out half way, and then grows back to maximum.
- This could cause problems in places like the GZDoom renderer in the odd circumstance, causing the camera to become stuck in the floor or ceiling until the quake expires.
- Relative quakes are different from other quakes; all quakes affecting
the camera do not become relative if one of them is relative.
- Use a single function call to get quake visual parameters instead of four.
- Thrust things in a psuedo-ellipse if they're inside a damaging quake whose
IntensityX != IntensityY.
- Don't break old savegames.
- Unlocks the full potential of using quakes, including the Z axis. Each intensity applies to X/Y/Z planes whenever a player is experiencing it.
- Flags:
- QF_RELATIVE - Adjusts the quaking of the camera to go in the direction its aiming (X: forward/backward. Y: Left/right.)
- Plans for including pitch will be implemented in the future for the Z axis with relativity.
Hexen uses the spawn height value from the mapthing_t structure to offset the item when floatbobbing. With proper gravity handling enabled this method doesn't really work so as a workaround ZDoom will now enable a hidden compatibility option when playing any map with a Hexen format MAPINFO so that any positive value in this field will make P_ZMovement revert to the original method of setting the items height (excluding the floatbob offset, of course.)
This also removes some code from P_NightmareRespawn that originate from the original Hexen method for floatbobbing which aren't needed anymore
I have no idea why this was ever deemed proper - but it clearly breaks some Hexen maps and it not even remotely mimics the original behavior. Even now, it's not the same but since the items fall down they at least end up where they are supposed to be.
- I'm assuming this check was here for a reason, but when both branches of
the if do the same thing and it's been this way since before recorded
history, it's not obvious what was intended here.
