EVENT_DISPLAYSPIT - loogies from the SPIT projectile
EVENT_DISPLAYFIST - nukebutton fist (shrunk fists are part of EVENT_DISPLAYWEAPON)
EVENT_DISPLAYKNEE - pstomp knee (quick kick is part of EVENT_DISPLAYWEAPON)
EVENT_DISPLAYKNUCKLES - knuckle crack idle animation
EVENT_DISPLAYSCUBA - scuba gear
EVENT_DISPLAYTIP - tip hand
EVENT_DISPLAYACCESS - access cards / keycards
git-svn-id: https://svn.eduke32.com/eduke32@5118 1a8010ca-5511-0410-912e-c29ae57300e0
Savegame version has been bumped due to the projectile changes. There is no way this commit doesn't cause at least one bug, so DONT_BUILD. ;)
git-svn-id: https://svn.eduke32.com/eduke32@5080 1a8010ca-5511-0410-912e-c29ae57300e0
Also, note a place that is the real cause for "what makes the player slide off
enemies", as far as I can see.
git-svn-id: https://svn.eduke32.com/eduke32@5016 1a8010ca-5511-0410-912e-c29ae57300e0
1. If you switch away from a weapon and switch to a third when the gun is still going down, continue lowering the first weapon instead of immediately raising the third.
2. If you switch away from a weapon and switch back to it before it lowers completely, raise it from its current position instead of going all the way to the bottom.
git-svn-id: https://svn.eduke32.com/eduke32@4915 1a8010ca-5511-0410-912e-c29ae57300e0
VM_OnEvent() has become VM_OnEvent(), VM_OnEventWithReturn(), VM_OnEventWithDist(), and VM_OnEventWithBoth() (the latter of which is only ever used once...). Of course, this required every call to VM_OnEvent() be changed.
memberlabel_t and vmstate_t have been changed to use the regular "int" type versus explicitly specifying int32_t as they did previously. The rationale for this change is simply that it looks cleaner, and I think we should move toward just using "int" in most cases where there's no particular reason to specify an explicit data type.
Also changes CON_KILLIT to just "return" instead of "continue". DONT_BUILD.
git-svn-id: https://svn.eduke32.com/eduke32@4745 1a8010ca-5511-0410-912e-c29ae57300e0
Fix a case in G_MovePlayers(), where the player sprite's shade is approached
toward the ceiling/floor's shade. Before, it could stop at one above or below!
git-svn-id: https://svn.eduke32.com/eduke32@4392 1a8010ca-5511-0410-912e-c29ae57300e0
These hacks could no longer be allowed to co-opt the fake multiplayer mode, used for local testing and mod development.
I have half a mind to remove the hacks outright because they could be likened to drilling bolts directly into your car engine just so you could mount a bowling ball as a hood ornament. However, I don't want to take away the splitscreen hack mod from anyone who uses it, and the work done on these hacks should be useful if proper splitscreen were implemented internally using per-player input and multiple renderer/audio passes.
git-svn-id: https://svn.eduke32.com/eduke32@4249 1a8010ca-5511-0410-912e-c29ae57300e0
It is unacceptable that yvel is on one hand modifiable without restriction from
scripting, but can be used as an array index without prior bound check in the C
code. Because that member has an overloaded meaning and is also used for
innocuous purposes such as the green color intensity of an SE light, it's
infeasible to restrict access from scripting. Consequently, we must add bound
checks on the C side. This is the first part of the effort to make .yvel safe,
adding two functions P_Get() and P_GetP(). There are a couple of other uses as
some kind of index.
git-svn-id: https://svn.eduke32.com/eduke32@4226 1a8010ca-5511-0410-912e-c29ae57300e0
- in the function itself: for floor, currently, do nothing (but this commit
is in preparation of the next one, again)
- In Proj_MaybeDamageCF(), Proj_MaybeDamageCF2() and the A_RadiusDamage() use
if the function, generalize to floors, but with the special case that
parallaxed floors keep blocking projectiles, as before (in constrast to
parallaxed ceilings). However, Sect_DamageCeilingOrFloor() is only
called for non-parallaxed ceilings *and* floors.
git-svn-id: https://svn.eduke32.com/eduke32@4205 1a8010ca-5511-0410-912e-c29ae57300e0
- factor out: G_WallSpriteDist()
- factor out: Proj_MaybeDamageCF() and Proj_MaybeDamageCF2()
in preparation for the next commit
- Make PROJ_DECAYVELOCITY macro take an arg for readability's sake
git-svn-id: https://svn.eduke32.com/eduke32@4204 1a8010ca-5511-0410-912e-c29ae57300e0
- Move ARRAY_SIZE() macro to compat.h, add another one ARRAY_SSIZE()
- In A_RadiusDamage(): note maybe-unaligned access issue, prevent unlikely oob
- sector.c: use SPRITES_OF* macros where appropriate
git-svn-id: https://svn.eduke32.com/eduke32@4199 1a8010ca-5511-0410-912e-c29ae57300e0
Because p->scream_voice is an int8_t.
This is an unlikely situation (126 voices ought to be playing simultaneously
while starting the "scream" sound), but still...
git-svn-id: https://svn.eduke32.com/eduke32@4180 1a8010ca-5511-0410-912e-c29ae57300e0
Likewise for blocking wall sprites. This makes it possible to construct
underwater sections containing complex spritework without losing the
"underwater-ness" when over such sprites, in a backward-compatible way.
Actually, the check is for bit 1 being set, but all other bits should be
considered reserved.
git-svn-id: https://svn.eduke32.com/eduke32@4166 1a8010ca-5511-0410-912e-c29ae57300e0
It was only ever used as upper bound to the time that a visibility change
decays, but since it does that in an exponential fashion, there's really
no point.
git-svn-id: https://svn.eduke32.com/eduke32@3961 1a8010ca-5511-0410-912e-c29ae57300e0
