Attack Z witdh issue?

[O Ilusionista]

Question: Has anyone here ever had problems with the Z axis of the attackbox? I'm starting to think there's a problem with that.

I have an attack that deals area damage, so I set the Z of the attack to 50 (I tested lower values before) and as much as I increased it, I noticed a strange behavior:

- if the enemy is on the same line or down (on the Z axis), hit
- if the enemy is up (pos Z minor) it does not hit, even if it is on the side.

See the attached image - the enemy painted green is hit, but the red one is not.

The information I have is that the value you place on the Z axis in the attackbox is shared in both directions - that is, the Z value would be divided; if you put 50 in the Z, it would be 25 px for each direction

attack {#} {x} {y} {right} {down} {damage} {power} {block} {noflash} {pausetime} {z}

But it is not what my tests are telling me.
I'm going to do a test with the new method of attacking, although I don't like it.

Edit: I've made a test with the Modders tool and while the box is displayed the same way it is in OpenBORstats (and I know Stats has an issue with larger boxes), the tool had converted the attackbox to the new format and that gave me a hint, take a look:

attack.block.penetrate 0
attack.damage.force 40
attack.damage.type 1
attack.effect.hit.flash.disable 0
attack.position.x -9
attack.position.y 80
attack.reaction.fall.force 5
attack.reaction.fall.velocity.x 4.0
attack.reaction.fall.velocity.y 3.0
attack.reaction.pause.time 2
attack.size.x 160
attack.size.y 7
attack.size.z.1 65

So the engine  (I am using build 6315) is using the Z witdh only in one axis, not for both.

 

[DCurrent]

O Ilusionista,

There's been some confusion - so before we go searching for bugs, let's talk about intended behavior:

First the parameters:

• Z1 = Into background (away from camera).
• Z2 = Into foreground (toward camera).

The information I have is that the value you place on the Z axis in the attackbox is shared in both directions - that is, the Z value would be divided; if you put 50 in the Z, it would be 25 px for each direction

That is not correct, and if you got it from me, I apologize. The split isn't a split, it's more like a doubling. If you specify a single Z axis of 50, you get 50 in both directions.

Also, this behavior is only for backward compatibility, and only applies to the legacy attack boxes. The currect attack box system is specfically meant to avoid confusing sanitation and backward compatibility behaviors, with one exception. If you do not specify any Z value at all or set them both to 0, you get this instead:

coords->z_background = coords->z_foreground = (int)(model->grabdistance / 3 + 1);

Assuming default grab distance, it comes out to ~15 in both directions. Otherwise you get exactly what you ask for, and nothing more. So if you only provide Z1 of 50, then the box will reach 50 pixels into the background, and 0 into foreground.

DC

 

[O Ilusionista]

Damon Caskey Thanks for the info. I can't remember from who I got it, but I got it here for sure.
After some tests, I can confirm that Z1 (away from camera) isn't working. I've set a big value for both, like 300, and if the entity is just few pixels above in Z axis, it won't hit it. Z2 is working perfectly.

Pay attention to those screenshots - there is a drum can in the background and a wood barrel in the foreground, both in the same X position but with different Z position.
I've set Z1 and Z2 as 300, which is wider than the game resolution itself, so it would hit anything.

Hawkeye is standing between both

See what happens when the arrow (he jumps and shoots it to the ground) hits the floor - only the wood barre gets hit

What I did for bypassing this was to make the box taller and made it to stay longer on the screen, so some enemies will just walk towards it and get hit.

I will test it on newer builds to see if it still happens.

 

[DCurrent]

It may be something that I've already fixed but not yet released. To be frank, the collision code was a dang mess. No blame on any one person, it had just been edited too many times by too many folks through the years. But still, it was a ton of spaghetti code nobody wanted any part of - not even SX or Plombo. But last fall I said "screw it" and jumped in. Since then that's where most of my coding time went. My private build that includes the clean up work passes various tests that are similar to yours, but I'll go over it with you before release.

Obviously I can't retroactively fix current builds, so you may have to stick with a workaround temporarily. I also can't 100% guarantee backward compatibility - since if something wasn't working as intended and now it does, workarounds may be broken.

DC

 

[O Ilusionista]

Damon Caskey do you remember if the 4.0 pre-alpha already had this change? or its already on the source code? So I can test it.

 

[Bloodbane]

First the parameters:

    Z1 = Into background (away from camera).
    Z2 = Into foreground (toward camera).

I believe z1 and z2 are in different axis than level's z axis. That's why increasing z1 won't cover the back as desired. OTOH increasing z2 might hit entities which it shouldn't hit
That's also why single attackbox can't be used to create ground shake attack (hit anything on ground but can't hit flying opponents)

 

[O Ilusionista]

Bloodbane but the attack can hit flying opponents if I made the attackbox taller, normally.

 

[Gurtag]

had the same problem implementing z attack boxes in the past, z doesnt extends paralel to walkable area but instead extend directly toward screen so to speak, if you want to hit enemy toward background, make attackbox taller, if you want to hit toward screen make it extend below offset, asked about this but was unable to explain my self well and may be it is the same now but check this tread in case it serves of any use.

http://www.chronocrash.com/forum/index.php?topic=4437.15

 

[O Ilusionista]

Gurtag yeah I had to make the attackbox taller, but this makes no sense.

 

[DCurrent]

O Ilusionista, Bloodbane, Gurtag

The old code for whatever reason integrated Y and Z axis. I have NO clue why. It probably was one of Roel's many brilliant optimizations that eventually got corrupted over the years. The new code I'm testing works with Z and Y axis independently. It's less optimal but will avoid the kind of stuff you are talking about.

DC