In C and Lunatic, split 'jumptoplayer' of enum amoveflags_t / action.MOVFLAGS
into 'jumptoplayer_bits' and 'jumptoplayer_only' (see updated Lunatic doc).
git-svn-id: https://svn.eduke32.com/eduke32@4378 1a8010ca-5511-0410-912e-c29ae57300e0
This flag is set from C for some enemies that should not be pushed back when
damaged, such as TANK. Both the tile flag and the per-sprite flag are used
(i.e. the ultimate flag value is the XOR of the two).
Add currently non-functional example to test.lua that attempts to set this bit
for NEWBEAST.
git-svn-id: https://svn.eduke32.com/eduke32@4371 1a8010ca-5511-0410-912e-c29ae57300e0
Its members are already laid out on the natural alignment boundaries.
Compilation tested with {32-bit, 64-bit} x {Lunatic, non-Lua} builds.
git-svn-id: https://svn.eduke32.com/eduke32@3968 1a8010ca-5511-0410-912e-c29ae57300e0
That is, its value was only referenced during the duration of a function call
that had previously set it. It was also never accessible from CON.
git-svn-id: https://svn.eduke32.com/eduke32@3921 1a8010ca-5511-0410-912e-c29ae57300e0
Using macros like AC_COUNT(t). Clean up related code:
- comment out the dead condition noted in the previous commit
- Lunatic: use get_count() instead of get_t_data(0) in one place,
rename to _get_t_data(), i.e. make that method internal
git-svn-id: https://svn.eduke32.com/eduke32@3920 1a8010ca-5511-0410-912e-c29ae57300e0
It is a 32-bit signed integer. No version bump necessary, although CON code
accessing this new member will not work with earlier revisions (obviously).
git-svn-id: https://svn.eduke32.com/eduke32@3866 1a8010ca-5511-0410-912e-c29ae57300e0
That is, assume that switch(DYNAMICTILEMAP(-1)) (which is an oob access and thus
undefined behavior) gets us to the 'default:' label.
git-svn-id: https://svn.eduke32.com/eduke32@3743 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
Previously, actor[].shootzvel (implementation detail, not available to CON)
was checked, and if it was !=0, that was the overridden velocity. The value
0 meant "hardcoded, projectile-dependent velocity". But that neccesiated a
hack where if zvel 0 was passed and really meant, it needed to be set to
1 instead. Now we have A_ShootWithZvel() taking an additional last argument
plus a macro SHOOT_HARDCODED_ZVEL permissible for that argument.
git-svn-id: https://svn.eduke32.com/eduke32@3465 1a8010ca-5511-0410-912e-c29ae57300e0
actors.h: remove 'packed' from projectile_t, tiledata_t. In tiledata_t,
make .cacherange member an int32_t so that the following member
"projectile_t defproj" is aligned on a 4-byte boundary.
player.h: remove 'packed' from playerspawn_t, DukeStatus_t, input_t.
In Lunatic, correct packing attribute of the base type of the unrestricted
actor_t and DukePlayer_t pointer types (the declaration was used without
Bump BYTEVERSION.
git-svn-id: https://svn.eduke32.com/eduke32@3458 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
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
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
This requires ripping out the .proj member of tiledata_t back into
ProjectileData[] again because it was the only one in g_tile[] that
changed during the course of a game. The g_tile[] array is now also
correctly flagged as "constant throughout a game" (DS_NOCHK).
Savegame version bumped.
git-svn-id: https://svn.eduke32.com/eduke32@3151 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
r2727 made old savegames incompatible, as an array with MAXVOLUMES*MAXLEVELS
is saved in Gv_WriteSave().
git-svn-id: https://svn.eduke32.com/eduke32@2730 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
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
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
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
Since the original source code release of Duke3D, there was a potentially
dangerous hack where actor[].dispicnum was set to -4 to signal "this actor
should not have a floor shadow for this moment" (it doesn't really work,
if you ask me).
Now, use another bit of actor[].flags for that purpose because setting
any picnum members to negative values asks for trouble.
git-svn-id: https://svn.eduke32.com/eduke32@2249 1a8010ca-5511-0410-912e-c29ae57300e0
This makes savegames practically the same as the initial snapshot of a demo.
Saves are now named 'dukesavX.esv' (demos: 'edemoX.edm').
Additionally, many changes that couldn't/needn't be cleanly separated are added
with this commit:
- make spriteext_t have the same size across 32/64 bit platforms (actor_t partially)
- prevent saving/loading in MP games (it certainly didn't work and still doesn't)
- it's time we start using assertions! Define NDEBUG for releasse builds.
- reset savegame major and minor versions (we have a new magic string, so no conflict)
git-svn-id: https://svn.eduke32.com/eduke32@2207 1a8010ca-5511-0410-912e-c29ae57300e0
32- and 64-bit platforms. Also, make struct type actor_t also have a common
size of 128 bytes. New code currently disabled and #ifdef'd for comparison.
This requires certain t_data[] entries ([1]: move ptr, [4]: action ptr and
[5]: ai ptr with actors) to be converted to script offsets instead of pointers,
breaking savegame and net packet compatibility (we could in theory try hard not
to, but it would be too much trouble).
git-svn-id: https://svn.eduke32.com/eduke32@2185 1a8010ca-5511-0410-912e-c29ae57300e0
