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
The scrollwheel is unique among PC input because it has no innate "hold length". Previously, the layers gave the mousewheel a fake hold length to allow the not-necessarily-synchronous game/editor code to pick up the input before the layers marked it as "no longer pressed". This passed under Windows, but it didn't slide under SDL.
Besides the two problems listed above, it also potentially limited the rate of weapon selection, where scrolling too fast would not register every clicks. [Unrelatedly, this is still the case when you scroll faster than the game's own tickrate, but addressing that would require rewriting input handling to go through a list of "events" for each tic instead of looking at overall pressed/unpressed states.]
git-svn-id: https://svn.eduke32.com/eduke32@4200 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
Exposed by this snippet from a.m32:
getnumber256 .owner "OWNER (projection picnum): " -MAXTILES
Now, Alt+KP2 works as expected in 3D mode.
git-svn-id: https://svn.eduke32.com/eduke32@4196 1a8010ca-5511-0410-912e-c29ae57300e0
And issue warnings whenever the assignment would fail (error) at game time.
git-svn-id: https://svn.eduke32.com/eduke32@4195 1a8010ca-5511-0410-912e-c29ae57300e0
This generally fixes demo playback. Before, tilesizx[]/tilesizy[] were written
into twice as many bytes as needed. Now, don't do that at all.
git-svn-id: https://svn.eduke32.com/eduke32@4191 1a8010ca-5511-0410-912e-c29ae57300e0
Important because in Lua, a value of zero yields true in a boolean context.
BUILD_LUNATIC.
git-svn-id: https://svn.eduke32.com/eduke32@4184 1a8010ca-5511-0410-912e-c29ae57300e0
In particular, (int32_t)j != -1 is replaced by (uint32_t)j < MAX_WEAPONS
to prevent a value >= MAX_WEAPONS to be assigned to p->wantweaponfire (it's
used as a weapon index in P_CheckWeapon().
git-svn-id: https://svn.eduke32.com/eduke32@4181 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
The ones disabled are because they were found to not be used in any mod I
tested. Exposing members directly is rarely good API.
- bool toggle_key_flag -> const uint8_t ... (because value 2 is used)
- make scream_voice, cheat_phase read-only
git-svn-id: https://svn.eduke32.com/eduke32@4179 1a8010ca-5511-0410-912e-c29ae57300e0
Known as getactor/sprite[].xpanning from CON, values are 0-255. It should be
assumed that this is only valid for wall-aligned sprites (currently, face
sprites also pan).
A test is provided in lunatic/test/animatesprites.con. It should be run in E1L2
and only with the Lunatic build.
git-svn-id: https://svn.eduke32.com/eduke32@4170 1a8010ca-5511-0410-912e-c29ae57300e0
For sanitizing underwater sections, see r4166.
Also, don't print "Menu function executed successfully" when the function
printed something itself.
git-svn-id: https://svn.eduke32.com/eduke32@4169 1a8010ca-5511-0410-912e-c29ae57300e0
Also, if it were to be reenabled again, use execv() instead of execvp(),
i.e. don't look up $PATH for the executable.
git-svn-id: https://svn.eduke32.com/eduke32@4167 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
Add an example searching for all maps containing blocking floor-aligned
sprites in underwater sectors.
git-svn-id: https://svn.eduke32.com/eduke32@4165 1a8010ca-5511-0410-912e-c29ae57300e0
