In some places, P_UndoPlayerMorph was called with the 'force' argument placed in the 'unmorphflag' parameter, so that 'forced' unmorphs would be not completely forceful.
I hope no mod relied on this weirdness...
Note that this required splitting P_SerializeWorld, because sector_t and FSectorPortal contain some actor pointers, for which the same rule applies: Portal linking can only be done after all sectors have been read, meaning it cannot be done along with the rest of the data in these structures.
Obviously such a change breaks savegame compatibility so the min. savegame version had to be increased again.
- This reverts commit 06216d733e.
- I don't know what I was thinking. Since stateowner is always available
to the wrapper function, and this code is only generated for the wrapper
function, it's a nonissue. The state is already located before calling
any function that uses it.
- This reverts commit 39df62b20e.
- Anything that needs to lookup a state also needs stateowner. See
FxMultiNameState::Emit(). I will need to be more selective when
de-actionifying functions.
- An actor function really only needs to be an action function if:
1. It can be called with no parameters specified, either because it takes
none or because all its parameters are optional. This lets SetState()
call it directly without creating a wrapper function for it.
2. It wants access to the callingstate or stateowner parameters. Most
functions don't care about them, so passing them is superfluous.
- DECORATE now has atan2(y,x) and VectorAngle(x,y) functions. They are
identical except for the order of their parameters. The returned angle
is in degrees (not radians).
Two issues:
Portal linking requires all skyboxes in the sectors to be present, without them some info is not there when needed.
UpdateWaterLevel was called in AActor::Serialize, which operated on the freshly loaded level where lots of things haven't been set up yet and plane heights may be wrong.
All the PortalBlocks* functions were turned into real function calls which for such a frequent check should be avoided. So now any linked portal sets a flag in the attached sectors so that it isn't necessary to check the skybox pointer each time which makes the functions subject to inlining again.
- When the camera texture for a player view was rendered, its psprites
would overwrite the ones stored for hardware acceleration.
* Use a temporary vissprite in R_DrawPSprite() until it's known that it
will be accelerated.
* Do not write to any of the VisPSprites*[] arrays until it's known that
the sprite will be accelerated.
