I would not be so heavy handed against preventing players from grabbing Spray Cans on custom levels, but designing a system that permits unloaded headers to retain their cans is frankly overkill. There are plenty of other ways the same kind of level-scouring play can be experienced on custom levels.
Instead of being specific to each level, Spray Cans are stored in a list on gamedata that will be stepped along each Spray Can you collect.
They are only assigned to a level on collection - which prevents you from farming the same easy location for every colour in the game.
In addition, this new system is one step short of dehardcoding them entirely. Now only Spray Cans specifically asked for by the existence of UC_SPRAYCAN will be put in the list, and if a secondary parameter is either "Yes" or "True", it will be put at the head of the list. This could technically support custom skincolours one day, but the author of this commit doesn't care to do the last bit of work necessary to make it happen.
There's a slight extra overhead in that skincolor_t now also holds a `cache_spraycan` (renamed from `cachedcan`, which maps had previously)
Currently, there's no safeguard against grabbing it on a custom course - you'll lose the Spray Can as soon as you load a fresh game again - but I consider that easy to fix (tomorrow) and necessary before merger, because the author of this commit does NOT want complaints on release because we forgot to protect users who keep on losing their skincolors.
- Fix the last few bugs I could find with thing args
- Move version update code
- Rename internal variables to `thing_[string]args` to make older code merge issues more obvious
SRB2 uses a LOT of mapthing args compared to Hexen (which has none) and ZDoom (which only has them on objects that will never ever activate scripts). So we really badly needed to separate the two if we want attaching scripts to things to be useful.
- Replaces a few D00DKart objects because the doomednum specifically replaced one of these
- Reports on load if the map has too many, or if one's assigned but the object doesn't exist
TODO: This should be available as a debugging option at
release, since it would be useful for addon authors.
I don't want to make more cvars, those are getting
cluttered and should maybe be coalesced into a single
debugging option.
- Battle: plays once the orbiting collection animation
finishes and the player's emerald flags are updated
- Centered on the player
- Sealed Star: plays as soon as the orbiting animation
begins
- Centered on the emerald
- Battle emeralds orbit into the player's body upon
collection
- Emerald shrinks down to a speck
- Orbiting speed increases over time
- Player's emerald flags altered at the end of the
animation
Side effects:
- HUD tracking icon now uses emerald's color in Sealed
Stars.
- UFO emerald doesn't disappear when collected. This is
WIP because the emerald is intended to orbit the player.
- Add K_BattleOvertimeKiller
- Kills an object if it is outside of the Overtime
Barrier in Battle
- Add Obj_SpawnEmeraldSparks
- Use this function for MT_EMERALD, MT_MONITOR and
MT_SPECIAL_UFO
- Move thinking code for MT_EMERALD and MT_MONITOR to
objects/monitor.c and objects/emerald.c
- Re-entry SHOULDN'T get stuck nonzero on first join for a given node
- Set to 0 for all players on level start
- Set to 0 for all players on level end
- DEFINITELY never intentionally set on join with teamchange finalisation
- This basically just prevents people from spamming New Challenger after hopping out mid-session, since the previous version, in addition to being buggy, was a little annoying.
- New Challenger no longer happens on tic 0 of mapload
- Handles any late, pending PF_PF_WANTSTOJOINs without threat of reset in P_PostLoadLevel
Since it's already ticking for the sake of a fuse, make it handle its own movement/scaling as well.
Spawning is still handled by the player thinker (and can be blocked by hitlag), but this permits it to disappear when a player dies/disconnects the server.
Fixes connecting to a server that's currently on a map with a loop.
Also tidies P_SpawnItemRow, P_SpawnItemCircle to reduce the likelihood of this happening again, and possible crash with Lua-shortcircuited loop spawning
- Spawned from underneath the UFO and is thrusted downwards
- Is spawned as splats instead of papersprites
- Colorized to sapphire
- Despawns on any ground contact
