Duke4.net Forums: [Fixed] Impossible to get crushed by enemies when shrunk - Duke4.net Forums

Jump to content

  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic

[Fixed] Impossible to get crushed by enemies when shrunk

#1

In DOS Duke, you can get crushed by other enemies when growing back from being shrunk. In particular it's possible to walk underneath other enemies while in a shrunk state, if and only if they are moving however.

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.
4

#2

So I dug into the code and isolated 2 separate problems associated with this. All of the following can be found in 'source/duke3d/src/player.cpp'

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

User is offline   Forge 

  • Speaker of the Outhouse

#3

this is still broke with r8122

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

0

#4

I believe one of the reasons why this is not trivial to fix is that the original shrinking behavior that allowed passing under enemies in the first place also causes the player to clip through spritefloors.
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.
0

#5

Still broken as of r8494.
1

User is online   Trooper Dan 

  • Duke Plus Developer

#6

Still broken as of 8534.

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.
0

User is offline   Forge 

  • Speaker of the Outhouse

#7

you should have paid more attention when I suggested you should stop updating the AA snapshot.

Remember when a Duke3D modification meant you were deviating from vanilla features instead of modifying code to emulate vanilla features?
Pepperidge Farm remembers.


https://www.18stripes.com/wp-content/uploads/2016/11/deadhorse.jpg

This post has been edited by Forge: 24 January 2020 - 05:46 PM

0

User is online   Trooper Dan 

  • Duke Plus Developer

#8

View PostForge, on 24 January 2020 - 05:40 PM, said:

Remember when a Duke3D modification meant you were deviating from vanilla features instead of modifying code to emulate vanilla features?



I haven't actually been doing that, but now that you mention it...
0

User is online   Trooper Dan 

  • Duke Plus Developer

#9

Playing with it some more, player shrinking is hilariously broken in EDuke32. Not only does Duke push enemies away so they can't crush him, he can also kick them to death while shrunk (in vanilla your shrunken kicks do nothing). It's kind of an advantage being shrunk because you are invincible and can still attack. Also, the player takes fall damage!

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.
1

User is offline   Forge 

  • Speaker of the Outhouse

#10

option 2: ask D64H for a fork similar to what AMC TC is using to get back some of the vanilla behavior while still benefiting from the performance improvements
0

#11

View PostForge, on 24 January 2020 - 10:48 PM, said:

option 2: ask D64H for a fork similar to what AMC TC is using to get back some of the vanilla behavior while still benefiting from the performance improvements

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

1

User is offline   Forge 

  • Speaker of the Outhouse

#12

View PostDoom64hunter, on 24 January 2020 - 11:25 PM, said:

(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 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

0

User is online   Trooper Dan 

  • Duke Plus Developer

#13

Autoducking and shrunk player bugs are the only issues that significantly impact AA right now, that I'm aware of. We don't use model flipping, TROR in areas with enemies, sprite ladders, switching between renderers, etc. As far as a separate branch goes, I'm more concerned about people trying to run in software renderer or polymer than I am about the bugs (i.e. I wish those options could be removed). The longstanding bugs are frustrating, though.
0

#14

View PostTrooper Dan, on 25 January 2020 - 11:19 AM, said:

Autoducking and shrunk player bugs are the only issues that significantly impact AA right now, that I'm aware of. We don't use model flipping, TROR in areas with enemies, sprite ladders, switching between renderers, etc. As far as a separate branch goes, I'm more concerned about people trying to run in software renderer or polymer than I am about the bugs (i.e. I wish those options could be removed). The longstanding bugs are frustrating, though.


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

0

User is online   Trooper Dan 

  • Duke Plus Developer

#15

View PostDoom64hunter, on 25 January 2020 - 11:31 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.


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.
0

User is offline   Forge 

  • Speaker of the Outhouse

#16

View PostTrooper Dan, on 25 January 2020 - 11:37 AM, said:

they are dong.

have to agree
0

User is offline   LeoD 

  • Topic #3513

#17

View PostDoom64hunter, on 25 January 2020 - 11:31 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, ...
Someone could file a feature request for a CLASSIC=0 compile parameter. Must be very patient, though...
0

User is offline   TerminX 

  • el fundador

  #18

View PostForge, on 24 January 2020 - 11:38 PM, said:

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)

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.
1

User is offline   Mark 

  • Honored Donor

#19

Hmm... Where did I see that post from Forge saying something about someone needing a new PR dept? :P

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

0

User is offline   LeoD 

  • Topic #3513

#20

View PostTerminX, on 25 January 2020 - 05:15 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.
Nothing is made up. Since the EDuke32 project started there's been nothing but "snapshots". Never any kind of release version, no stable-like branches, even since you've started stampeding forwards into Fury "development". No version Duke3D players could rely or agree on during the last years. No build without serious and/or annoying issues. So, yes, you have temporarily abandoned the Duke part of the project and let down both community contributors, casual and regular players. You want to be a pro and make some bucks out of your hard work? Fine. You deserve it.
Now please start acting like a pro, too, in terms of both manners and project handling for Duke's sake!
0

User is offline   Forge 

  • Speaker of the Outhouse

#21

View PostTerminX, on 25 January 2020 - 05:15 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.

try again. this time aim higher.


View PostTrooper Dan, on 24 January 2020 - 01:05 PM, said:

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.



................................................................................. .................................................................................. .................................................................................. ............................
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

-1

User is online   Trooper Dan 

  • Duke Plus Developer

#22

Acknowledgement of bug reports and some kind of timeline or plan for addressing them would have been nice. The wait has been long and the lack of communication on some of these issues has been frustrating.

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.
7

User is offline   TerminX 

  • el fundador

  #23

View PostForge, on 25 January 2020 - 07:48 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

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.
1

#24

Admittedly I can't help but laugh slightly over how the 'making things up' response was almost a 1:1 re-enactment of the response I got in the Discord some months ago.

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.
0

User is offline   RADAЯ 

  • Zionist Shill

#25

View PostHigh Treason, on 26 January 2020 - 04:20 AM, said:

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.


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.
1

User is offline   Forge 

  • Speaker of the Outhouse

#26

View PostTerminX, on 26 January 2020 - 12:42 AM, 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.

*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

-1

User is offline   TerminX 

  • el fundador

  #27

Maybe you should pray for an improvement to your own understanding of such issues.

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.
2

User is offline   Forge 

  • Speaker of the Outhouse

#28

I understand that I spoke out of frustration. I feel like I have to post incredibly stupid shit just to get your attention. It's not the proper way to go about things if a positive environment between the user and the developer is to be maintained

I'm sorry.
3

User is offline   RADAЯ 

  • Zionist Shill

#29

https://i.imgur.com/Muh7YYP.jpg
2

User is offline   TerminX 

  • el fundador

  #30

I'm speaking out of frustration myself.

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.
12

Share this topic:


  • 3 Pages +
  • 1
  • 2
  • 3
  • You cannot start a new topic
  • You cannot reply to this topic


All copyrights and trademarks not owned by Voidpoint, LLC are the sole property of their respective owners. Play Ion Fury! ;) © Voidpoint, LLC

Enter your sign in name and password


Sign in options