Crumble fof
Basic (but kind of WIPish still) support for remote falling of FOFs by linedef execs or Lua. Originally started for Nev3r to use his dark magic on.
Making this MR so people actually remember I was doing something regarding crumbling FOFs, it's been months since I did stuff for this now mind...
* linedef type 446: basic setup is same as the remote shatter one (436), except the FOF of course falls down rather than shatters. By default the FOF respawns
* *No Climb*: the FOF *doesn't* respawn
* *Block Enemies*: respawning ability is determined by the FOF's flags (if it has FF_NORETURN it doesn't return, if it doesn't it does return)
* *Block Enemies + No Climb*: inverted version of above
* EV_StartCrumble for lua, format: `EV_StartCrumble(controlsec, rover, [floating?, [player, [origalpha, [crumblereturn?]]]])`
* *controlsec* is the FOF's control sector
* *rover* is the FOF itself
* (optional) *floating?* does the FOF float on water after crumbling? Defaults to false (NOTE: probably should be set to `rover.flags & FF_FLOATBOB` for best results currently, kind of weird otherwise)
* (optional) *player* is the player that caused the FOF to fall; needed for some effects such as who to award points to if you killed someone =3 Defaults to nil
* (optional) *origalpha* is the FOF's original alpha before crumbling (the thinker for respawning + floating crumbling FOFs tinkers with the alpha for some reason). Defaults to rover.alpha
* (optional) *crumblereturn?* will the FOF respawn afterwards? Defaults to false (NOTE: probably should be set to `not (rover.flags & FF_NORETURN)` for best results currently, kind of weird otherwise)
* the return value of EV_StartCrumble means something I forget offhand now ...it's either true or false though, mind
See MonsterIestyn/crumble-fof on the FTP for a test exe (srb2win-crumblefof.exe), a test map for the linedef, and a test lua script for EV_StartCrumble (which can also be tested in the map).
See merge request !55
* Super sprites are now deliniated via an additional S_SUPER lump between S_START and S_END. Above are normal sprites, below are super sprites. Handled internally via FF_SPR2SUPER.
* Sprite2 numbers are now appropriately limited for the data type that stores them.
* SPR2_SPIN is now SPR2_ROLL, SPR2_DASH is now SPR2_SPIN and SPR2_PEEL is now SPR2_DASH. Makes more sense, right?
This new function returns a string representing the type of userdata the variable given (e.g. mobj_t, player_t), it even works on "minor" userdata types (player_t.powers, skin_t.soundsid, sector_t.lines, etc)
Sprite2 changes
Some stuff!
* Lua access to sprite2.
* Introducing new Lua-exclusive function, P_IsValidSprite2(mo, spr2). Basically just a wrapper for (((skin_t *)mobj->skin)->sprites[spr2].numframes > 0), useful for creating custom sprite2 defaulting functions since hooking into P_GetMobjSprite2 wouldn't be worth it.
* FF_ANIMATE support for sprite2s. The var2 of the state works identically to normal FF_ANIMATE, but var1 is completely disregarded - it just runs all of the frames available to that one sprite2 animation set.
* As a result, a bunch of states which were either not previously animatable or had animated at constant speed now get animation without state changes.
* P_SetMobjState now supports sprite2 defaulting like P_SetPlayerMobjState does.
See merge request !51
* All Lua-originated sprite2 settings are now forced through P_GetMobjSprite2. Makes sense because of SPR2_JUMP, which none of the main characters have sprites for yet all use.
* Cleaned up P_GetMobjSprite2 to not set irrelevant, otherwise-unused variable.
my P_SearchBlockmap_* functions are now a single searchBlockmap function, you can choose between "objects" and "lines" with the first arg to decide what to iterate through. I also rearranged the argument order a bit for easy stack cleanup etc
I'll remove the old stuff later, don't worry, it's disabled for now
- Press spin in midair to stomp directly downwards (losing horizontal momentum), creating a flickering fireball around you.
- No bouncing on enemies, item boxes, etc - just go straight through.
- Hurts other players on touch whilst you're stomping.
- Spawns a bunch of flames around you when you hit the ground.
Also:
- Electric shield's ability now uses different sounds, because I'm picky.
When I first wrote this, I thought the .h file that contained a function declaration needed to have the same name as the .c file the function was in. Now I know that's not the case, off to p_local.h with you.
The idea is for the layman Lua user to understand better what range of values to use for mobj types, states, sfxs, player #s etc. Additionally, mobjinfo/states/sfxinfo/hudinfo tables all now have actual bound checks when accessing/editing them. Yikes, why didn't they have any before?!
P_RandomChance is now a macro for something that should happen a
certain percentage of time.
P_SignedRandom was moved to a macro. Nobody cared.
# Conflicts:
# src/p_inter.c
There is a caveat to this: The first time EvalMath is used, a
deprecated function warning will be shown to the user that tells
them to use _G[] instead.
This reverts commit 9d36cf37bd.
Use whatever names you want for your music. So long as you prefix the lumps with O_ or D_, it doesn't matter anymore.
DISCLAIMER: Linedef type 413 (change music) and Lua scripting is not tested.
(cherry picked from commit 025ca413a2)
# Conflicts:
# src/p_user.c
*player->health (formerly the "HUD" health) is now to be known as player->rings, and now acts as the player's actual ring count
*player->mo->health (formerly rings + 1) is now always 1 when alive, regardless of ring count; if player with rings is damaged, this is untouched
Damage in normal SP/Coop gameplay has been tested and still works fine; still a lot of mess to clear up though
Tag damaging probably is broken now, I'll fix this later
No longer turns you super, instead emeralds steal points
from enemy players and give you (and relevant teammates)
an invincibility + super sneakers monitor.
P_PlayerWeaponPanelOrAmmoBurst will go through all of the
player's weapon rings and either drop the weapon panel itself
(with no ammo attached, and no ammo taken away!) OR if the
player has ammo but no weapon, it drops the ammo instead
(and you lose it).
Angles now go from 0 to 0xFFFF (360 degrees == FRACUNIT) instead
of using a full UINT32. Lua only has one number type, so signedness
gets in the way of using angle_t directly. This handling of angles
matches up with how ZDoom ACS scripting and the like does it.
I also changed all the integer casts and pushes of fixed_t to
their own macro in preperation for possible future seperation.
EvalMath is for SOC only.
It spawns an entirely seperate instance of Lua and requires
uppercase-only strings, and it's ability to parse strings to
enums is redundant to Lua's _G table (try using
_G["MT_BLUECRAWLA"] for instance)
Currently the main benefit of these changes is that a number of non-Object-related hazards/deaths no long rely on dummy MT_NULL objects or other hacks to tell the game how you were hurt/killed, yay
git-svn-id: https://code.orospakr.ca/svn/srb2/trunk@9039 6de4a73c-47e2-0310-b8c1-93d6ecd3f8cd
