• Content count

  • Joined

  • Last visited


About Spectre01

  • Rank
    was rileymartin

Recent Profile Visitors

1826 profile views

Single Status Update

See all updates by Spectre01

  1. What's the deal with Mancubus fireballs flying through walls in PRBoom+? I got hit no less than 3 times today while behind cover.

    1. Show previous comments  8 more
    2. Doomkid


      So does that mean the explanation found here is totally off base? http://forums.zdaemon.org/viewtopic.php?t=16625



      You see, the "speed" of a projectile is how many units it instantaneously moves forward on each "step". The frame duration defines how often the projectile makes such steps. Thing is, if your projectile is currently close to a wall (but still without touching it), it might appear entirely on the other side of the wall after making another step. It will fly straight through the wall because the collision technically never happened.

      To fix this, decrease the duration of the projectile frames and also the speed parameter. That way the projectile can fly just as fast, but the steps will be shorter and thus it will improve the odds of (or even guarantee) proper collisions with any walls. This will, however, increase the animation speed as well.

      To keep the animation the same as well, here's what you can do. I'll use plasma projectiles as an example. Plasma loops through frames 107 and 108; 6 tics for each frame. Instead, make it loop through four frames (e.g. 107, 108, and unused frames 720, 721); 3 tics for each. Frames 107/108 and 720/721 would visually look the same. Now decrease its speed (e.g. from 25 to 15) and you'll have a projectile that looks and acts identically to usual plasma except it travels 20% faster and yet collides with all the walls properly.

      I apologize if you're experienced with dehacked enough not to be explained these things in such detail but I figured perhaps others could find it helpful.

      I just ended up increasing the radius of the projectiles, but I thought this idea was brilliant - but based on what I'm hearing here, it won't actually work?

    3. Doomkid


      (Also interesting chats like this make me wish status updates were easier to find after they drift away from the front page..)

    4. scifista42


      The occurence of clipping through a single 1-sided line (or through an extremely-thin wall) is determined by the projectile's speed, the line's angle, the projectile's angle relative to the line, and the projectile's exact position relative to the line, which in turn is determined by the distance from the attacker to the wall modulo the projectile's speed.


      Passing through a thick wall with void inside it (thicker than the projectile's diameter) consists of 2 events: Passing through one line into the void, and passing through another line out of the void. The chance of it happening depends on the very things described in the paragraph above, but applied twice in a row, and for that very reason, the chance is further affected by the distance between the 2 lines, their relative angle, and the angle under which the projectile passes through the first line.

    5. scifista42


      @Doomkid Yes, you can change the projectile's animation however you want and it won't affect its movement in any way. Decreasing the projectile's speed and/or increasing its radius are the only effective changes.

    6. Da Werecat

      Da Werecat

      I just made the rockets "static" (they were looped with 1 tic duration before) and they worked just fine. If that explanation was true, they'd just freeze in place.


      Strangely enough, when I put 0 into the next frame, the rocket never shows up, even though it's not supposed to change frames with -1 in duration. DEHACKED is fun.

    7. scifista42


      @Da Werecat Would you share your DEHACKED so I could look at the duration issue?

    8. Da Werecat

      Da Werecat

      Patch File for DeHackEd v3.0
      # Created with WhackEd4 1.2.0 BETA
      # Note: Use the pound sign ('#') to start comment lines.

      Doom version = 21
      Patch format = 6

      Frame 114
      Duration = -1
      Next frame = 0

    9. Da Werecat

      Da Werecat

      I changed next frame to 115 and rockets turn into BFG balls now. A second -1 down the line stops the animation. Looks like it's just the first frame that can't be static.

    10. Doomkid


      That's totally bizarre

    11. scifista42


      Frame 115 is a BFG ball frame, Da Werecat just tested whether next frame will work in that case, and it worked as it should have, that part is not bizarre.


      I think I found the issue in the source code. When a projectile gets spawned, the following function is called:

      void P_CheckMissileSpawn (mobj_t* th)
          th->tics -= P_Random()&3;
          if (th->tics < 1)
      	th->tics = 1;

      The last 3 lines are supposed to randomize the projectile's animation, but if the duration of the first frame is -1, this code will change it to 1. As a result, the projectile will animate even though it's not supposed to. And since the duration is only 1 and the next frame is set to 0, the projectile will disappear as soon as it tries to animate.