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

Jump to content

Hide message Show message
Welcome to the Duke4.net Forums!

Register an account now to get access to all board features. After you've registered and logged in, you'll be able to create topics, post replies, send and receive private messages, disable the viewing of ads and more!

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

The Ledgeshot Bug  "an Eduke32 classic"

User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,583


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_EXTRA 24
defineprojectile RANGERPROJ PROJ_XREPEAT 12
defineprojectile RANGERPROJ PROJ_YREPEAT 12
defineprojectile RANGERPROJ PROJ_PAL 21
defineprojectile RANGERPROJ PROJ_FLASH_COLOR 255


User is offline   Perro Seco 

  • 227


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:

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

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

Posted Image

User is offline   TerminX 

  • el fundador
  • 5,517


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.

EDuke32 wiki svn builds bugs
Join us in #eduke32 on irc.freenode.net!

User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,583


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.

User is online   Trooper Dan 

  • Duke Plus Developer
  • 3,583


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.

Share this topic:

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

All copyrights and trademarks are property of their respective owners. Instead of reading this text, you could be playing Ion Maiden! ;) © 2018 Voidpoint, LLC

Enter your sign in name and password

Sign in options