Duke4.net Forums: The Ledgeshot Bug - Duke4.net Forums

Jump to content

Page 1 of 1
  • You cannot start a new topic
  • You cannot reply to this topic

The Ledgeshot Bug  "an Eduke32 classic"

User is offline   Danukem 

  • Duke Plus Developer

#1

There is a longstanding bug with the EDuke32 custom projectile system that has been around for a long time -- it probably goes back to the introduction of custom projectiles.

The bug is this: If an actor (including the player) fires a non-hitscan custom projectile downward while standing on a ledge*, then depending on the ledge and the downward angle, the projectile can impact on the air in front of the actor even though it has a clear trajectory to a distant target. Hitscan projectiles do not do this. Also, non-hitcan projectiles that are hardcoded (SHRINKSPARK, RPG, FIRELASER, FREEZEBLAST) do not do this either.

*this will require some definition

My current preferred hack for working around this ancient bug is as follows. I detect whether the shot would have a zvel of +8000 or more. If it does, then I use a hacked shot: first, I make the actor fire a FREEZEBLAST, and give the projectile the correct zvel for moving toward the intended target. The FREEZEBLAST is immediately rendered invisible in EVENT_EGS. I let the FREEZEBLAST travel for 2 tics. Then, having traveled a safe distance past the point where it would impact on the air, the FREEZEBLAST fires the custom projectile, applying to it the zvel needed to continue on the trajectory and transferring the owner from the original actor. Having served its purpose, the FREEZEBLAST is deleted.


EDIT: below is the definition of a projectile that exhibits this bug. Aside from the VEL_MULT property, it's a fairly generic projectile. And yes, I have seen this bug on projectiles that do not use VEL_MULT

defineprojectile RANGERPROJ PROJ_WORKSLIKE 32770
defineprojectile RANGERPROJ PROJ_VEL 844
defineprojectile RANGERPROJ PROJ_VEL_MULT 3
defineprojectile RANGERPROJ PROJ_HITRADIUS 0
defineprojectile RANGERPROJ PROJ_SPAWNS RAILIMPACT
defineprojectile RANGERPROJ PROJ_EXTRA 24
defineprojectile RANGERPROJ PROJ_EXTRA_RAND 6
defineprojectile RANGERPROJ PROJ_XREPEAT 12
defineprojectile RANGERPROJ PROJ_YREPEAT 12
defineprojectile RANGERPROJ PROJ_TRAIL RANGERTRAIL
defineprojectile RANGERPROJ PROJ_PAL 21
defineprojectile RANGERPROJ PROJ_FLASH_COLOR 255

0

User is offline   Perro Seco 

#2

I hope this is not offtopic, but in case devs have time to take a look, I'll also like to show some similar bugs related to projectiles. They're also present in the original Duke 3D, and some of them even in other Build Engine based games, so I don't know how difficult can be fixing them.

- If I understood you correctly, that bug is also present in the RPG, which can kill the player if god mode is off:
Spoiler

- But even if that bug is fixed, there's still another one:
Spoiler

- Sometimes projectiles skip collisions when enemies/players are moving:

0

User is offline   TerminX 

  • el fundador

  #3

This isn't a bug in the custom projectile system, it's a bug in the Build Engine and it affects every game we've tested.
1

User is offline   Danukem 

  • Duke Plus Developer

#4

View PostTerminX, on 12 February 2019 - 12:43 PM, said:

This isn't a bug in the custom projectile system, it's a bug in the Build Engine and it affects every game we've tested.


I'm glad to hear that you guys are aware of it. It's one of those things that doesn't get mentioned often, but it's a real pain. I still maintain (admittedly without providing any real evidence at the moment) that it's still worse with custom projectiles. If that wasn't the case, then the hack that I described above would not do the job. But it does.

It seems like what is happening is the projectile thinks it is hitting the floor of the sector it is in. This can happen with or without slopes, but it seems worse with slopes. So one obvious thing to look for is whether the projectile is checking the floorz of the sector (which obviously would be the wrong thing to check on a slope) as opposed to the actual height of the floor at that point in the slope.
0

User is offline   Danukem 

  • Duke Plus Developer

#5

I'm bumping this thread with a new finding, although it's something I should have known long ago.

I confirmed that the tendency of projectiles to hit the ledge is proportional to their speed. If the speed at spawn time is low enough, it becomes a non-issue. This enabled me to use a hack that is much less convoluted than the one I described above.

The best place to test this is the sloped ledge right above the box after you come down the chute in E1L1. Stand on the slope and face away from the window where the hidden liztroop is shooting you, and aim down. If you fire a custom projectile that moves much faster than a rocket (the one I was testing had an xvel of 844 with a vel_mult of 2), it will hit the air in front of your face (really it is hitting the slope at your feet) with even a slight downward angle. This really shows how absurdly bad the problem can be, since from that angle you have a clean line of sight to something on the ground far below and you can't even see the slope that the projectile is detonating on.

My hack solution is: change the projectile definition so that it has only 1/3 the speed you really want. Let the projectile move at the slow speed for 2 tics after spawning, and then triple both its xvel and zvel. For me this completely solved it. I was able to fire downward from ledges with no problem, and I could barely tell that the projectile was starting slow. I'm going to go back now and apply this to some other fast projectiles that have been problematic.
2

User is offline   TerminX 

  • el fundador

  #6

r7436
1

User is offline   Danukem 

  • Duke Plus Developer

#7

Fix confirmed. :)
0

User is offline   TerminX 

  • el fundador

  #8

Great!
0

User is offline   Danukem 

  • Duke Plus Developer

#9

View PostTerminX, on 20 March 2019 - 01:11 AM, said:

Great!



I spoke too soon:

Posted Image

It's an improvement, but there are still ledges where it happens. It passed tests in E1L1 at least.
0

User is offline   TerminX 

  • el fundador

  #10

What are the art dimensions of the tile for that projectile? What does it look like in F7 mode if you hold down the look left or look right key and fire?
0

User is offline   Danukem 

  • Duke Plus Developer

#11

View PostTerminX, on 20 March 2019 - 01:31 AM, said:

What are the art dimensions of the tile for that projectile? What does it look like in F7 mode if you hold down the look left or look right key and fire?


The pixel dimensions are 19x19 but it doesn't matter because I can't replicate the problem now, which can only mean I'm a complete idiot and I must have accidentally used the wrong .exe when starting that level last time.

I did notice that the shots can clip right through the ledge now, but I think you guys already know that.

EDIT: Also the shading on voxels in the distance will jump between correct and full bright (not related, but very noticeable from that particular ledge)

This post has been edited by Trooper Dan: 20 March 2019 - 01:49 AM
Reason for edit: minor edit

0

User is offline   TerminX 

  • el fundador

  #12

Yeah, I've seen that. I don't think it's possible to fix without a more thorough reworking of how clipping works, though I am thinking about some possible workarounds.
0

Share this topic:


Page 1 of 1
  • 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