Instead of replacing the original, the second class will get renamed now, using the originating file as an identifier. In the vast majority of cases this should do exactly what is needed: Create an unconflicting second class that can coexist with the original. Unless the class is used by name this should eliminate all problems with this, but so far I haven't seen anything that used them by name.
This is choosing the lesser of two evils. While some mod out there may get broken, the old setup meant that the first class of a given name could not be written out to a savegame because it was not retrievable when loading it back.
Ultimately we may have to get a fully qualified name out of this, so Outer should be a type that can handle this feature. The new class for this is currently used as base for PType and PSymbol so that PNamedType inherits from it and maybe later a namespace symbol can, too.
There have been reports about crashes in here with Linux that point to some of the code that gets called here doing unwanted things on the owner, so with these links cleared that should no longer be possible.
- This was fine with fixed point numbers, since they could never be
outside of short range when converted to regular ints. With floating
point numbers now, that condition no longer holds.
- allow recursive linking of $random definitions (as long as they do not link back, see above.)
- fixed the sound precaching which did not handle $alias inside $random. Normally this went undetected but in cases where the random sound index was the same as a sound index in the current link chain this could hang the function.
The slot had been there forever to address this same problem but only one of the two constructors actually set it, too bad that it was the wrong one...
This is something that normally won't be noticed. But if some actor is spawned on a moving platform, with both thinkers on the same statnum it means that the order of execution is not correct with the platform being done first, resulting in the actor to 'jump' while the platform is moving. To prevent this it is necessary that all sector movers only tick after all actors have completed their thinking turn.
We have to be extremely careful with the player data, because there's just too much code littered around that has certain expectations about what needs to be present and what not.
Obviously, when travelling in a hub, the player_t should be retained from the previous level. But we still have to set player_t::mo to the PlayerPawn from the savegame so that G_UnsnapshotLevel doesn't prematurely delete it and all associated voodoo dolls, because it checks player_t::mo to decide whether a player is valid or not.
The actual deletion of this redundant PlayerPawn should only be done in G_FinishTravel, after the actual player has been fully set up
* do not skip the player_t init when travelling in a hub. The old player may still be needed in some edge cases. This applies only to singleplayer for now. The multiplayer version still needs reviewing. I left it alone because it may shuffle players around which is not wanted when doing hub travelling.
* do not spawn two temp players in G_FinishTravel. Instead handle the case where no player_t::mo can be found gracefully by adding a few nullptr checks. This temp player served no real purpose except for having a valid pointer. The actual start position was retrieved from somewhere else.
- Fixed properties not having the proper indices.
- Use ViewPos-to-actor instead of measuring actor-to-actor.
- Use the actual camera instead of the actor so camera textures can work.
