- Moved destination tag off of linedef tag and into args.
- Bot controller values can be changed mid-level with ACS. (Linedefs using type 2004 will still be activated on level load.)
- Add flag to make bots fastfall
Replaced all mentions of starpostnum and Starpost w/ cheatchecknum and CheatCheck (so Ivo can stop asking why we still need it when its going to save our asses on release patches)
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.
Instead of storing this during binary-UDMF conversion and then copying it for certain argument fields, put it directly onto stringarg[0] (or [1] if it's the backside), then make relevant changes with those.
Reduces the amount of Zone memory used for binary converted maps, and the amount of struct memory used for all types of maps.
They have also been removed from the Lua API. Fret not, the stringargs on line_t have far more utility.
Adds r_spritefx.cpp
lightlevel should be -255 to 255, relative offset to
normal sector lightlevel.
If RF_ABSOLUTELIGHTLEVEL, mobj_t.lightlevel becomes an
absolute lightlevel in the range 0 to 255.
Lines, sides, sectors, and things now all support the "Custom" tab properly. Label a property as `user_[whatever you want]` in this tab, and it will be added to the structure. ACS will then be able to retrieve it using the `Get[x]UserProperty()` function.
There can be very many precipmobjs in a sector. During BSP
rendering, for each sector reached by BSP (the entire
visible level at least), all the precipmobjs would be
iterated and their distance from the camera calculated, to
determine whether they are within draw distance.
The issue with the old approach is that there really are
too many precipmobjs in each sector. By iterating the
blockmap within a certain range instead, precipmobjs
out of view are not iterated at all, saving some time.
Caveat: drawdist_precip is no longer respected as an
exact value, since it must round to the precision of the
blockmap.
List of potentially scary changes:
- Removes snext/sprev for precipmobj_t
- Removes preciplist for sector_t
- Adds bnext/bprev for precipmobj_t
- mobj_t and precipmobj_t field offsets are symmetrical
- Modified P_SetPrecipitationThingPosition and P_SetThingPosition
- The syntax in these functions is kind of wacky
Specifically, it avoids sorting or clipping the sprite
against stuff like FOF planes, which are notorious for
messing up sprites. Useful for debug stuff which
absolutely must be visible.
- DMG_STUMBLE in SOC, hardcode
- Has sector type
- UDMF: damagetype = "Stumble"
- Binary: Sector type 9, section 1
- Can be chained even when invincible, unlike Tumble
- Will never instinctively cause hitlag
- Lines can be set to activate when crossing or bumping into them, with distinctions for players, enemies, and missiles+items.
- A new flag has been added to determine if a line special can activate more than once.
- Finish Line + Respawn Line are now handled like other specials. This means that:
- They follow the new line activation rules (so you can potentially have a finish line that you have to bump instead of cross)
- More importantly, they can be called as functions in ACS. (Player_FinishLine and Player_Respawn)
- Fixed linedef flags not being saved in save games.
- Precache M_NOLVL.
- Make all width calculations relative to a lump 320 pixels wide, to make outdated map thumbnails much, MUCH more visible.
- Add K_DrawLikeMapThumbnail to draw a 320x200 patch like a map thumbnail (currently used only for RANDOMLVL).
All typedefs for structs that were present in other header
files have been moved to here. (Except node_t because the
renderer and netcode both define node_t LOL.)
- Use `SpeedPad` to set the strength. Intended to be scaled like Trick Panels, so 1 for yellow, 2 for red, so on. Can use floating point.
- Use `SpeedPadAngle` to rotate the thrust direction. This is in the same system as map angles, so east is 0, north is 90, west is 180, and south is 270. Also accepts floating point.
- Speed Pad angle accounts for the flat alignment itself, as well.
- Like Sneaker and Trick Panels, the sector / line special are now deprecated.
- Grab thumbnail and minimap pictures even for base game maps
- Repair modified game event for replacement map load
- PU_STATIC thumbnail and minimap, freed on new file load lump discovery
- Fix W_CheckNumForMap to not SIGSEGV if no match
- Reduce the number of pointless map lump hunts, we've already got it stored
- Prevent use-after-free for map pictures on voting screen
- Cache "BLANKLVL" patch once
- Draw minimap on the time attack menu
Unfortunately cups are still broken and I'm not sure where to start on that, or if it's just not having a sample wad to test with that includes cups
Makes slopes at a great enough steepness able to match the contrast of walls.
COMING SOON: Directional lighting & contrast modifier, as options for map header.
* Rework HU_UpdatePatch to HU_UpdateOrBlankPatch with a "required" boolean.
* If desired graphic is not present in resources:
* If required is true, return `missingpat`.
* If false, return NULL as before (font compatibility).
* Add an alias with the previous function signature, so you don't need to add a million `true`s everywhere.
* Remove a ton of irrelevant graphics the game attempts to cache only because of code inherited from vanilla SRB2.
* Remove the unused hudinfo system, also inherited from vanilla SRB2.
* Set via a fourth digit in the upper midtexture for transparent FOFs
* For example - #2551 is additive solid, #1282 is subtractive half...
* The original method of setting the upper midtexture to #900 or 901 still works, since I'm not out to break existing maps.
* Software: Remove the horrible `else if` ladder for FOF translucency. Algorithms, baby!
* OpenGL: Move to using `HWR_GetBlendModeFlag` in more places, for more long-term extensible support for multiple blendmodes.
All my work thus far on solving the drawflag/renderflag/additive/subtractive conundrum.
Outstandng problems:
* Bad additive/subtractive tables means that they appear opaque except under certain conditions.
* No support for FOFs, Polyobjects, or linedefs in OpenGL yet.
* All OpenGL support mostly done blind, may or may not function in practice.
If nothing else, the hard engineering problems are solved and it's just bug hammering...
