- In the A_MoveSprite() code that transports projectiles due to an SE7
(introduced in r1450 / legacy ROR), only report "success" if the
transportation succeeded.
- Clear newly introduced internal SPRITE_DIDNOSE7WATER flag after
checking it.
git-svn-id: https://svn.eduke32.com/eduke32@3682 1a8010ca-5511-0410-912e-c29ae57300e0
Also, in two cases, don't assign A_IncurDamage() result to a variable if
it's not needed.
git-svn-id: https://svn.eduke32.com/eduke32@3681 1a8010ca-5511-0410-912e-c29ae57300e0
- In S_PlaySound(), move the sound index bound check above an indexing.
- For A_CheckHitSprite(), and A_FindPlayer(), allow NULL second arg.
- In A_ShootWithZvel(), make some one-letter vars be int32_t, making
storing safeldist() results in them meaningful.
- In MaybeTrainKillEnemies(), remove two redundant checks and move another
one further up.
- Comment that SIDEBOLT1 will never be translucent as was probably intended.
- In G_MoveFX(), fix an always-true comparison.
git-svn-id: https://svn.eduke32.com/eduke32@3680 1a8010ca-5511-0410-912e-c29ae57300e0
- Rewrite some sprites-of-{stat,sector} loops using the SPRITES_OF,
SPRITES_OF_SECT and new SPRITES_OF_SECT_SAFE macros.
- In passing, identify some problems and mark them with 'XXX', but don't
attempt to fix them yet.
- The usual readability improvements...
git-svn-id: https://svn.eduke32.com/eduke32@3679 1a8010ca-5511-0410-912e-c29ae57300e0
Actually, the tweaked code in VM_Move() is not specific to projectiles, so
other sprites now may pass no-SE7 water boundaries too, but it's most noticeable
with projectiles.
git-svn-id: https://svn.eduke32.com/eduke32@3678 1a8010ca-5511-0410-912e-c29ae57300e0
That is, if submerging, the lower sector MUST have lotag 2. If emerging, the
upper sector MUST have lotag 1. (Previously, emersion happened from ST 2 sectors
unconditionally.) This means that the area where submersion or emersion can
happen is now the same for the top and bottom parts.
git-svn-id: https://svn.eduke32.com/eduke32@3677 1a8010ca-5511-0410-912e-c29ae57300e0
This is done by always calling FX_PlayAuto3D() to play such sounds. It now
additionally takes a third argument 'loophow', permissible values being
FX_ONESHOT and FX_LOOP.
git-svn-id: https://svn.eduke32.com/eduke32@3631 1a8010ca-5511-0410-912e-c29ae57300e0
With this change, it is impossible for negative values to be used as array
indices inside this function, and I believe that it is also impossible that
they escape to somewhere they might be used as such.
For Lunatic, allow setting actor[].picnum to negative values and in the
translator, add (commented out) code to warn whenever it is set to a constant
negative value. Also, fix a _sound call in _addphealth in control.lua.
git-svn-id: https://svn.eduke32.com/eduke32@3626 1a8010ca-5511-0410-912e-c29ae57300e0
In passing, fix a couple of omissions: gameactor() being passed nil's in the
middle, more than one moveflag to CON *actor.
git-svn-id: https://svn.eduke32.com/eduke32@3597 1a8010ca-5511-0410-912e-c29ae57300e0
This should have no adverse effects or side-effects. The changes only apply if a modder chose to use completely broken functionality in the first place.
git-svn-id: https://svn.eduke32.com/eduke32@3544 1a8010ca-5511-0410-912e-c29ae57300e0
Use a new flag to mark hard-coded enemies, not SPRITE_BADGUY.
This fixes an issue where in E1L4, a pigcop would appear in the area
you have to crawl under shrunk. Thanks to LLCoolDave1 for pinpointing
the range of relevant revisions.
git-svn-id: https://svn.eduke32.com/eduke32@3426 1a8010ca-5511-0410-912e-c29ae57300e0
Also, add another flag, signifying that from the editor, also the
"lastwall"s (i.e. the CCW-linked points) should get collected. This is
to signal the editor that their wall lengths should be displayed, too.
git-svn-id: https://svn.eduke32.com/eduke32@3394 1a8010ca-5511-0410-912e-c29ae57300e0
In the normal game, these arrays are conceptually [MAX_WEAPONS][MAXPLAYERS],
allocated as CON per-player gamevars (e.g. WEAPONx_WORKSLIKE).
For Lunatic, they are replaced with
weapondata_t g_playerWeapon[MAXPLAYERS][MAX_WEAPONS].
git-svn-id: https://svn.eduke32.com/eduke32@3328 1a8010ca-5511-0410-912e-c29ae57300e0
Rotation-fixing happens for a couple of hard-coded statnums that presumably
never move (DEFAULT, STANDABLE, FX, FALLER, LIGHT), but for actors it wouldn't
make sense since the common case is that they do move. For this reason, bit 4
was introduced in r1934. The position of such useractors will not diverge
due to error roundoff accumulation in rotating sectors (SE0, train).
git-svn-id: https://svn.eduke32.com/eduke32@3316 1a8010ca-5511-0410-912e-c29ae57300e0
... instead of switch/case-ing them in A_CheckEnemyTile().
Because this requires bumping BYTEVERSION, we also get rid of the
excess trailing bytes in the save game's "rest" data. (See r3052.)
git-svn-id: https://svn.eduke32.com/eduke32@3257 1a8010ca-5511-0410-912e-c29ae57300e0
The redundant ones are in code like this: s->cstat = (int16_t)32768;
Because the value is eventually converted to the type of "s->cstat", any
casts to integral types having at least as many bits are no-ops, signedness
being irrelevant due to (probably any two's complement arch targeting
compiler's) bit-pattern preserving semantics of these conversions.
The now incorrect one is: if (lotag == (int16_t) 65535),
"int32_t lotag" being read from a wall or sprite struct directly earlier.
Now, with these members being unsigned, and (int16_t)65535 equalling -1,
the check always fails. The correction fixes normal switches having such
a lotag ending the level immediately.
In short: integer casts before assignments are unnecessary, those in reads
highly relevant!
git-svn-id: https://svn.eduke32.com/eduke32@3211 1a8010ca-5511-0410-912e-c29ae57300e0
Rewriting them in the obvious way, i.e. by casting the expression
to int16_t first. (That is, this commit is the reverse of r3174,
but with casts applied.) This fixes at least one regression: a
FIREEXT with a hitag of 0 should not be linked with same-
(that is, zero-) tagged SEENINEs or OOZFILTERs.
Mind the corner cases!
git-svn-id: https://svn.eduke32.com/eduke32@3210 1a8010ca-5511-0410-912e-c29ae57300e0
Notes:
- Atomic Edition (Censored) -> Plutonium Pak in grpscan.c
- "scale" in astub.c:drawtileinfo() is incorrect, I think.
- in demo.c, the gethitickms() value should be returned to a double.
git-svn-id: https://svn.eduke32.com/eduke32@3178 1a8010ca-5511-0410-912e-c29ae57300e0
This reverts r3159..r3161.
Conflicts:
eduke32/build/include/compat.h
(Handled so that r3163's changes are kept applied.)
git-svn-id: https://svn.eduke32.com/eduke32@3165 1a8010ca-5511-0410-912e-c29ae57300e0
I think there's also a fix for the CON precache system breakage in here (lost it in my local tree when I started getting the C++ build working in MSVC, sorry!)
git-svn-id: https://svn.eduke32.com/eduke32@3159 1a8010ca-5511-0410-912e-c29ae57300e0
Credit to Plagman for the idea and doing the work on the game side, which is included in this commit.
(Building as C++ will give us features with which we can make improvements and optimizations on the multiplayer code and Polymer.)
git-svn-id: https://svn.eduke32.com/eduke32@3116 1a8010ca-5511-0410-912e-c29ae57300e0
This commit also adds the NOTELEPORT sprite flag, which of course prevents sprites from teleporting.
git-svn-id: https://svn.eduke32.com/eduke32@3094 1a8010ca-5511-0410-912e-c29ae57300e0
And hook it up to SE cstat 64 ('1' in mapster32). This disables both lightmaps
and shadow maps for the spotlight; please let me know if you have a usecase
where you want lightmaps but no shadow maps for specific lights.
git-svn-id: https://svn.eduke32.com/eduke32@3091 1a8010ca-5511-0410-912e-c29ae57300e0
Submersion only happens when the upper sector has lotag 1 and its vertical
neighbor has lotag 2 (this can be useful to create non-submergible above-water
sectors). Currently, only the player is handled. On the implementation side,
the water handling code is split into P_Submerge() and P_Emerge() preparing the
"teleportation", and P_FinishWaterChange() for the finalization.
git-svn-id: https://svn.eduke32.com/eduke32@3072 1a8010ca-5511-0410-912e-c29ae57300e0
For reference, they are the following:
- cache1d.c: suckcache()
- build.c: compare_wall_coords()
- make switch-invisible heuristic
- Mapster32: old sprite search
- Mapster32: manual z range
- m32script: read/writearray, qgetsysstr
- menus.c: savetemp()
git-svn-id: https://svn.eduke32.com/eduke32@2981 1a8010ca-5511-0410-912e-c29ae57300e0
Well, this never worked anyway, but invoking demons flying out of your
nose is never a good idea.
git-svn-id: https://svn.eduke32.com/eduke32@2977 1a8010ca-5511-0410-912e-c29ae57300e0
1. EVENT_PREGAME
2. hardcoded stuff
3. EVENT_GAME
One potential use is to examine values which are clobbered by commands such as ifhitweapon/ifwasweapon.
git-svn-id: https://svn.eduke32.com/eduke32@2973 1a8010ca-5511-0410-912e-c29ae57300e0
The sound distance is the minimum of the two. Both point sources as well
as MUSICANDSFX ambient sound is handled.
git-svn-id: https://svn.eduke32.com/eduke32@2885 1a8010ca-5511-0410-912e-c29ae57300e0
Functions affected are G_Move* in actors.c and A_Shoot in player.c.
Here, the p variable had function scope, now it's redeclared in shorter
blocks. I'm still relatively sure that no observable behavior was changed,
though not as sure as in part 1. Also, some dead assignments and the like
are eliminated.
git-svn-id: https://svn.eduke32.com/eduke32@2876 1a8010ca-5511-0410-912e-c29ae57300e0
The p variable (sometimes named differently) has short scope in all cases,
so I'm almost sure that the replacements amount to an identity transformation.
git-svn-id: https://svn.eduke32.com/eduke32@2875 1a8010ca-5511-0410-912e-c29ae57300e0
Most differences are handled with function parameters, except that one instance
checked SpriteProjectile[i].spawns for being >0 instead of >=0. The factored
function always checks for >=0.
git-svn-id: https://svn.eduke32.com/eduke32@2794 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes an integer overflow when a distance is calculated later.
git-svn-id: https://svn.eduke32.com/eduke32@2785 1a8010ca-5511-0410-912e-c29ae57300e0
(LUNATIC build only.)
Also, a minor problem is identified. sizeof(actor_t) is 124 on 64-bit platforms,
while the expected size is 128 bytes. This needs to be corrected whenever the
next savegame version bump happens.
git-svn-id: https://svn.eduke32.com/eduke32@2724 1a8010ca-5511-0410-912e-c29ae57300e0
Defines SPRITES_OF(Statnum, Iter) and SPRITES_OF_SECT(Sectnum, Iter)
[The first is so that STAT_* can be substituted for Iter and it reads nicely.]
Usage should be self-explanatory, but one thing to keep in mind is that
the sprites that are iterated over MUST NOT be deleted.
git-svn-id: https://svn.eduke32.com/eduke32@2707 1a8010ca-5511-0410-912e-c29ae57300e0
For Lunatic, we'll want to get rid of the t_data --> script indirections, since
the latter will be no more. Thus, all parameters are saved in t_data directly.
For the normal build, there are no changes, only stylistic tweaks.
git-svn-id: https://svn.eduke32.com/eduke32@2669 1a8010ca-5511-0410-912e-c29ae57300e0
EVENT_SOUND: triggered upon playback of any sound, this allows the "hard coded" sounds to be altered in a context-aware fashion instead of having to resort to clunky hacks like replacing them with a blank sound effect. RETURN var
iable is set to the sound effect # of the sound to be played, or -1 to cancel playback.
EVENT_CHECKTOUCHDAMAGE: triggered in P_CheckTouchDamage() whenever the player collides with anything. Value of RET
URN is set to the result provided by clipmove() and so can be decoded in the same way. Value of RETURN when the event is over can also be manipulated to control some of the hard coded damage effects.
EVENT_CHECKFLOORDAMAGE: triggered in P_CheckFloorDamage(), RETURN is simply the picnum of the floor of the sector t
he player is in. Can be used to cancel hard coded floor damage effects or to make other tiles exhibit the same eff
ects
Other misc fixes and cleanups, including a possible workaround for Duke Plus SECTOREFFECTOR light issues wherein all SE49 and SE50 that have a statnum of STAT_EFFECTOR are simply changed to STAT_LIGHT during the STAT_EFFECTOR loop
now.
git-svn-id: https://svn.eduke32.com/eduke32@2652 1a8010ca-5511-0410-912e-c29ae57300e0
The primary reason for doing this is that handing of moving sectors is
significantly simplified. Because moving sectors usually don't move containing
SEs/effector-statnum sprites, no special handing code is needed to move light
SEs with them. Thus, this commit sets light SEs to a new statnum when they're
spawned *from premap*, and a new G_Move*-like function (called G_DoPolymerLights)
is added to process every sprite in that status list.
This should "fix" light SEs moving together with a variety of moving sectors,
but CON programs expecting the old behavior may break, therefore this commit is
marked as experimental.
Additionally, a problem with the old implementation is identified: it seems like
the correct functioning is dependent upon the order of processing between the
sector movement effector and the light SE, so this makes it another good reason
for the change. (A third one is that all lights can be processed with a per-
statnum loop, but CON coders should not do this until the change is considered
final).
git-svn-id: https://svn.eduke32.com/eduke32@2646 1a8010ca-5511-0410-912e-c29ae57300e0
This is so that it may be intercepted in the future.
The only code that's not replaced by the function call is with the CON
interface to g_player[].ps->pals via player[].pals X and .pals_time.
Also, comment out one instance because it's overwritten by a succeeding one.
git-svn-id: https://svn.eduke32.com/eduke32@2643 1a8010ca-5511-0410-912e-c29ae57300e0
- in actors.c, make a static array const (the original patch removed the
staticness)
- remove one comment and change some compiled-out code
- remove commented out pre-Makefile.common stuff
Some changes were not adopted from tueidj's patch:
- whitespace cleanup
- ud.config.UseJoystick = 1 in config.c
- Makefile.common, as mentioned before
- proper read-in of g_numRealPalettes, because it was done with r2503
git-svn-id: https://svn.eduke32.com/eduke32@2632 1a8010ca-5511-0410-912e-c29ae57300e0
- 4 instances -> HandleSE31
- 4 instances -> MaybeTrainKillPlayer
- 2 instances -> MaybeTrainKillEnemies
- move a couple of variables into inner blocks and add 'const' for easier reading
In passing, fix a minor glitch where the squishing sound of an enemy that got
run over by an SE 6 or 14 car would appear to originate from the SE instead
of the enemy's last position.
git-svn-id: https://svn.eduke32.com/eduke32@2607 1a8010ca-5511-0410-912e-c29ae57300e0
This might now be even more confusing for users reading both the source
and CON code (where the access is necessarily still via '.clipping'),
but at least reading the source now makes sense :P
git-svn-id: https://svn.eduke32.com/eduke32@2454 1a8010ca-5511-0410-912e-c29ae57300e0
We've been running with same-sized actor_t for a while without problems now.
In the unlikely event (famous last words) that an issue should pop up later,
this revision should be consulted for the differences between the two versions.
git-svn-id: https://svn.eduke32.com/eduke32@2451 1a8010ca-5511-0410-912e-c29ae57300e0
This plays more nicely with automatic formatters. Also indent accordingly.
git-svn-id: https://svn.eduke32.com/eduke32@2379 1a8010ca-5511-0410-912e-c29ae57300e0
Encountered with Scent.map. Since the SE21 are deleted after they have
been used, the search for them in the ST28 code in sector.c may come up
empty, in which case sector[-1] would be accessed.
git-svn-id: https://svn.eduke32.com/eduke32@2377 1a8010ca-5511-0410-912e-c29ae57300e0
- guard cansee() against negative sectnums (return 0 immediately), since
it's often called with the player sectnum as one argument
- in resetpspritevars(), don't inset APLAYER sprite if sectnum < 0, which
can happen if a map is started in void space accidentally (e.g. from
the editor)
- two checks before accessing sector[] with a player sectnum
git-svn-id: https://svn.eduke32.com/eduke32@2342 1a8010ca-5511-0410-912e-c29ae57300e0
This fixes a bug in passing: 'int32_t j' was assigned to as a temporary inside
one instance of the code, but used as if it were the previous sprite index
further on. Would only happen with projectiles that "work like" both SPIT
and RPG_IMPACT.
git-svn-id: https://svn.eduke32.com/eduke32@2321 1a8010ca-5511-0410-912e-c29ae57300e0
