[Fixed] Impossible to get crushed by enemies when shrunk
#1 Posted 03 September 2019 - 08:55 AM
As of eduke32 r8075, you can no longer move below other enemies while shrunk, even if they themselves move, pushing them away instead.
By consequence, it is no longer possible to get crushed by enemies when growing back.
Edit: Bisected it, and it appears that r7428 (aka. the big clipping change) introduced this problem.
#2 Posted 04 September 2019 - 12:29 AM
1. The player cannot move under enemy sprites when shrunk. This occurs because his z position is clamped in the following function in player.cpp:
static void P_ClampZ(DukePlayer_t* const pPlayer, int const sectorLotag, int32_t const ceilZ, int32_t const floorZ) { if ((sectorLotag != ST_2_UNDERWATER || ceilZ != pPlayer->truecz) && pPlayer->pos.z < ceilZ + PMINHEIGHT) pPlayer->pos.z = ceilZ + PMINHEIGHT; if (sectorLotag != ST_1_ABOVE_WATER && pPlayer->pos.z > floorZ - PMINHEIGHT) pPlayer->pos.z = floorZ - PMINHEIGHT; }
Specifically in the second if-statement, the player is fixed to a certain point above the floor's height. This prevents the player from passing under enemies.
Even when this is commented out, there is a second section that breaks the original behavior, at line 5377 in player.cpp:
// This makes the player view lower when shrunk. This needs to happen before clipmove(). if (!FURY && pPlayer->jetpack_on == 0 && sectorLotag != ST_2_UNDERWATER && sectorLotag != ST_1_ABOVE_WATER && playerShrunk) pPlayer->pos.z += ZOFFSET5 - (sprite[pPlayer->i].yrepeat<<8); // pPlayer->pos.z += ZOFFSET5;
The commented line is what this used to be before the change in r7428. Apparently the player is not placed low enough to pass under enemies with the new code.
Changing these two sections on my end results in the original behavior in regards to being able to pass under enemies.
2. Even with the player being able to pass under enemies again, I noticed that he still doesn't get crushed when growing back. At line 4735 in player.cpp, we find the following:
int32_t ceilZ2 = ceilZ; getzrange(&pPlayer->pos, pPlayer->cursectnum, &ceilZ, &highZhit, &dummy, &dummy, pPlayer->clipdist - GETZRANGECLIPDISTOFFSET, CSTAT_SPRITE_ALIGNMENT_FLOOR << 16); if ((highZhit & 49152) == 49152 && (sprite[highZhit & (MAXSPRITES - 1)].cstat & CSTAT_SPRITE_BLOCK) != CSTAT_SPRITE_BLOCK) ceilZ = ceilZ2; pPlayer->spritebridge = 0; pPlayer->sbs = 0;
replace 'CSTAT_SPRITE_ALIGNMENT_FLOOR << 16' with 'CLIPMASK0', and the player will be crushed by enemies as expected when growing back. Unfortunately I don't really have an idea as to why this is the case.
Now of course, I don't know why exactly these changes were made and what impact they have on the gameplay, as such I won't suggest the above as an actual patch.
Hopefully however this analysis will help you find a solution to the problem.
This post has been edited by Doom64hunter: 04 September 2019 - 12:35 AM
#3 Posted 17 September 2019 - 07:49 AM
still can't be walked over by aliens while in a shrunken state
side effect - the aliens can't walk on the player, they can't shoot the player, the player can bulldoze the enemies and push them around. Being shrunk is now a state of semi-invincibility
This post has been edited by Forge: 17 September 2019 - 07:52 AM
#4 Posted 17 September 2019 - 11:19 AM
This is most likely what this change aimed to fix, since it no longer happens on recent eduke32 versions.
In order to make player crushing work properly again while also preventing the player from clipping through spritefloors, one would have to add some kind of logic that makes the player non-blocking against enemies only.
This would then somehow have to check if the player is inside the hitbox of an enemy actor once he grows back, and kill him if this is the case.
#6 Posted 24 January 2020 - 01:05 PM
This is an example of a major issue caused by the clipping changes that apparently is being ignored. Doom64Hunter bisected the intro of the bug back to 7428, which was back in March of 2019, nearly 11 months ago now. Not a single comment from any dev on the bug despite several bumps to this thread, and even specific research and suggestions from Doom64Hunter. So, I think "ignored" is an appropriate characterization of the response based on what we know.
There are parts of the vanilla game where avoiding squishing from enemies is intended to be a challenge. Also, in general, the threat from protector drones is reduced to near zero by this bug.
#7 Posted 24 January 2020 - 05:40 PM
Remember when a Duke3D modification meant you were deviating from vanilla features instead of modifying code to emulate vanilla features?
Pepperidge Farm remembers.
This post has been edited by Forge: 24 January 2020 - 05:46 PM
#8 Posted 24 January 2020 - 08:28 PM
Forge, on 24 January 2020 - 05:40 PM, said:
I haven't actually been doing that, but now that you mention it...
#9 Posted 24 January 2020 - 09:04 PM
I've tried a few simple CON hacks to allow the enemies to enter the player's clipping sphere while shrunk, but no luck so far. Neither changing the player's cstat nor clipdist does the trick.
#10 Posted 24 January 2020 - 10:48 PM
#11 Posted 24 January 2020 - 11:25 PM
Forge, on 24 January 2020 - 10:48 PM, said:
The fork was made specifically because we are passing limits that no other mod or game is exceeding and because we wanted to keep the included eduke32 executable updated to the current revision, rather than having it be stuck at r6775, while also keeping our longstanding features functional.
The fork is not intended to be used with Duke 3D or any other game really, and the goal is to eventually reduce the amount of changes as eduke32 gets updated, such that the only remaining changes are limit increases that would not be useful for the main branch of the engine.
Another argument is that the AMC TC has long passed being a mere mod of an existing game and is now evolving to be stand-alone entirely, without the use of the original assets.
I would strongly advice against other mods of smaller caliber from doing this as it could end up causing a large mess, where certain code changes are needed but users can't upgrade because the main branch diverged substantially from what the mod was based on.
(However, I will acknowledge that the current situation has similar problems. Seemingly every eduke32 mod out there includes their own instance of the binary that is known to work properly with the mod. While possible in theory, in practice it's almost never the case that a user can simply upgrade their eduke32 revision without breaking substantial parts of the mod. This has already created a situation where each mod is essentially locked to a specific revision when they are no longer being maintained.)
This post has been edited by Doom64hunter: 24 January 2020 - 11:33 PM
#12 Posted 24 January 2020 - 11:38 PM
Doom64hunter, on 24 January 2020 - 11:25 PM, said:
this was pretty much my point
right now eduke has gone in a direction where vanilla features are no longer functioning. It's basically abandoned while the devs work on whatever it is that suits their fancy. (probably mobile and console ports)
most things made before 7136 won't work with the current snapshot.
if the dev ever decide to tinker with eduke again, anything made between 7136 and that hypothetical future snapshot won't work with anything afterwards.
Any mod or tc made with the current snapshot will not be compatible with a snapshot that has the current crop of issues fixed.
upgrading of snapshots is a utopian pipe-dream at this time
a customized snapshot to gain back certain vanilla elements - like an actual working shrink system with proper enemy interaction isn't a far-fetched request.
of course it depends on the free time and willingness of the person capable of doing such things, and the possibility that the current damage can be undone without breaking something else.
I'm not volunteering you, but you probably have enough knowledge to determine if such a thing were even possible.
This post has been edited by Forge: 24 January 2020 - 11:59 PM
#13 Posted 25 January 2020 - 11:19 AM
#14 Posted 25 January 2020 - 11:31 AM
Trooper Dan, on 25 January 2020 - 11:19 AM, said:
Polymer can be removed by compiling the binary with the option POLYMER=0, no changes to the code necessary.
The software renderer cannot be disabled, although if you really wanted to you could add a conditional message to the title screen that tells people to play in OpenGL.
This post has been edited by Doom64hunter: 25 January 2020 - 11:31 AM
#15 Posted 25 January 2020 - 11:37 AM
Doom64hunter, on 25 January 2020 - 11:31 AM, said:
The software renderer cannot be disabled, although if you really wanted to you could add a conditional message to the title screen that tells people to play in OpenGL.
Can selection of software mode be disabled from appearing in the dropdown menu on the startup screen? I think that would suffice -- if someone really wants to select it after starting the game, they probably know what they are dong.
#16 Posted 25 January 2020 - 11:38 AM
#17 Posted 25 January 2020 - 11:47 AM
Doom64hunter, on 25 January 2020 - 11:31 AM, said:
The software renderer cannot be disabled, ...
#18 Posted 25 January 2020 - 05:15 PM
Forge, on 24 January 2020 - 11:38 PM, said:
Oh for fuck's sake, quit making ridiculous shit like this up. Keep the retarded posts to the outhouse. Sometimes things are broken in development snapshots... fucking deal with it. You don't need to start fabricating stories about how a project that still has somewhere between dozens to hundreds of commits made every month is "basically abandoned."
The issues will be fixed, but acting like a stupid cocksucker isn't going to speed up the process any.
#19 Posted 25 January 2020 - 05:53 PM
Seriously though, we don't have the coding smarts of the devs. From what little we can understand of the tech speak in the change logs of those dozens and dozens of updates, the perception is they are aimed at something other than the bugs found and haven't been addressed for quite a few revisions including ones where exact revision culprits were found or that have been researched and suggested fixes given.
(whew, I should break that sentence up into a couple more)
This post has been edited by Mark: 25 January 2020 - 06:09 PM
#20 Posted 25 January 2020 - 07:33 PM
TerminX, on 25 January 2020 - 05:15 PM, said:
The issues will be fixed, but acting like a stupid cocksucker isn't going to speed up the process any.
Now please start acting like a pro, too, in terms of both manners and project handling for Duke's sake!
#21 Posted 25 January 2020 - 07:48 PM
TerminX, on 25 January 2020 - 05:15 PM, said:
The issues will be fixed, but acting like a stupid cocksucker isn't going to speed up the process any.
try again. this time aim higher.
Trooper Dan, on 24 January 2020 - 01:05 PM, said:
................................................................................. .................................................................................. .................................................................................. ............................
it's kinda sad that I have to post outlandish shit after 5+ months to get you to even acknowledge that threads like this exist & that what's being discussed is even a problem with the port
This post has been edited by Forge: 25 January 2020 - 07:59 PM
#22 Posted 25 January 2020 - 09:08 PM
But guys, that's still no excuse to act entitled to someone else's time who is not your employee. Life is short, TerminX and Hendricks266 could just walk away from this tomorrow to do bigger and better things, and I for one would be very sad if that happened. If you look at the big picture, the overall trajectory of EDuke32 capabilities and quality is upward. We are in a rough patch. Let's get through it without nuking bridges.
#23 Posted 26 January 2020 - 12:42 AM
Forge, on 25 January 2020 - 07:48 PM, said:
It's kinda sad that I don't get any respect after 15+ years of working on this shit for free.
Go get fucked in the ass.
#24 Posted 26 January 2020 - 04:20 AM
I'm sure there's an irony in here somewhere, but naturally this doesn't really matter because any words I might have are probably worth nothing as, apparently, I'm an anti-Semitic person of Semitic descent or something. Making things up. You know what they say about projecting.
As far as respect goes, I think this is probably the wrong community to expect that kind of thing from, they say it's earned and not given, or at the very least is reciprocal, but around here I think it's a foreign concept to most people, it all just becomes the norm after a while, you get used to it. Fair enough, I guess, this is the internet after all, suppose it depends on whether one needs some form of confirmation from others, or whether they do things solely for themselves or for their own enjoyment, albeit criticism does generally come with releasing anything to the public and it should, it's what you do with the criticism that matters¹.
¹In my case, took it on board and deliberately did more of the things that pissed people off, but then nobody is pouring hours, months or years worth of their time into anything I made or having to rely on it, which certainly allows some license to be an asshole in this way.
#25 Posted 26 January 2020 - 05:44 AM
High Treason, on 26 January 2020 - 04:20 AM, said:
¹In my case, took it on board and deliberately did more of the things that pissed people off, but then nobody is pouring hours, months or years worth of their time into anything I made or having to rely on it, which certainly allows some license to be an asshole in this way.
Is that why you recommend 6 year old builds (way before any of the clipping overhaul was introduced) just to play your maps? On that topic, have you tested Dimension Shift with Rednukem? If it's still broken then I think you just have to admit that's it's designed poorly mate.
#26 Posted 26 January 2020 - 08:24 AM
TerminX, on 26 January 2020 - 12:42 AM, said:
Go get fucked in the ass.
*demands respect, but doesn't give the community any
*doesn't communicate with the community, also doesn't understand why people make speculations when there's nothing else to go off of
*doesn't understand his own part in why these things happen, doesn't care either. Just flies off the handle when it does happen
That's okay though, I still pray for you, your wife, and your family. I wish you the best.
This post has been edited by Forge: 26 January 2020 - 08:37 AM
#27 Posted 26 January 2020 - 09:25 AM
Thanks for the kind wishes, though. I have no ill will toward you... I just think you're acting like a moron by fabricating scenarios to fill in your lack of understanding regarding the current EDuke32 problems. It saddens me to see you say things that are simply not true. Actually, no, saddens isn't the right word for it--I am outraged at how completely full of shit you are regarding the current state of EDuke32. If you want to be ignorant, that's one thing, but don't go conjuring up reasons why things are the way they are and stating them as fact. It just makes you look like a dipshit, and makes me look like an asshole because heavy-handed angry responses tend to be how I deal with bullshit.
I will make a commit later that makes some of the clipping fixes conditional on running Ion Fury. Please try to keep your imagination in check in the meantime.
#28 Posted 26 January 2020 - 09:28 AM
I'm sorry.
#30 Posted 26 January 2020 - 09:57 AM
You know, you could just ping me on Discord... it would probably be more effective than making me want to strangle you.
Anyway, I accept your apology and offer my own.
Here's the situation with EDuke32: yes, there is some obvious breakage at the moment. It stems from the game's ass-backward handling of the player view position in relation to the player's actual sprite. When you crouch or are shrunk in Duke3D, the player's sprite is actually forced underneath the floor. This is undesirable for obvious reasons and is the core cause of clipping errors like quickly bypassing the exit gate in the beginning of Movie Set. This same behavior is what allows the player to pass through monsters when shrunk--the player's clipping area simply does not collide with them because the player sprite is in the floor.
The game also uses the player's view position instead of the player's sprite position when determining whether or not to automatically step up onto sprite geometry. In fact, the position of the APLAYER sprite is always directly tied to the view camera position--it is unconditionally moved every tic to reflect the current player view position, even if that means it ends up inside geometry. Unfortunately, fixing these issues causes additional problems because a lot of Duke3D behavior ends up relying on the game working in the way I described. The reason it has remained broken is because I've been unable to come up with a suitable set of rules to allow me to fix the issues, yet leave things just barely broken enough that all of the existing maps work. I didn't want to lose the improvement regarding clipping against sprite geometry just because Todd was high when he programmed the player movement. However, this is what will have to happen until a time when the problems can be addressed in a way that doesn't conflict as much with all of the quirks Duke3D has. Most of the other improvements will be retained.