Knight cant do damage under special circumstances

Sounds like it's detecting the door as "blocking" the attack. I'll look into it next week.

 

This has only become an issue due to the widening of the jab hitbox.

I don't really see how handling them like tiles would help much, unless you mean the semantic approach instead of the current code approach. Tiles are compared to the current aim angle (needs to be <20 degrees), some logic is added to detect hidden corner tiles, there's some extra logic to handle jabbing doing fake "partial" damage to tiles, and if all that checks out then damage is done. That doesn't exactly extend to blobs in any meaningful way that I can see.

 

Here (uploaded) is KnightLogic as I've updated it - basically for any blob that would block damage, I've stored the angle to that blob, and then it blocks any subsequent hits that are within a 35 degree span (17.5 deg either side) of that, rather than just blocking all incoming hits.

I might need to adjust the thresholds a little so I'd be happy for you folks to try it out and see if you can break it.

I'm not going to limit this to 20 degrees within the aimangle as fuzzle seems to be suggesting because then hits at the edges of the arc won't be processed correctly - it's ok for the tiles because the best tile is selected to be hit, but I believe the logic I've implemented here is required to properly filter blobs while allowing multiple hits (and multiple blockers).

Happy to discuss the fix further though.

 

Yeah I understand why this is happening and it's quite frustrating. It's not really "the inconsistency above" so much as "the nature of how hit info is presented".

When you're aiming directly at the knight, the first hitinfo it gets is in line with the knight. If you aim down, since it sweeps hit arcs outwards/sideways, the hitinfo for the door is on the bottom corner - in some cases this is enough to get around the hit tolerance.

Without raycasting against every object in-script (which is crazy slow) the only way to fix this is to up the block angle or do some gnarly maths about what the actual obscurance of the door is at a given range. Since I'm not meant to be working on KAG at all next week, I'll be going with the former I'm afraid. I might swap to using object centres rather than hit positions to make it more consistent as well.

To remove the tile inconsistency I'll consider making tiles behave in the same way (reporting their centres as a hit blocking surface). That would mean that the "attacking through a 1 tile window" case would probably no longer be possible, but I'll see how close I can get the tolerances (even though the current bug is a result of keeping the tolerance very low).

In general this is a fiddly problem to properly solve - it might seem "insane" that it's going through the door, but keep in mind that before, at the top of this thread, having a door above you would block hits to another direction, which is similarly "insane", and has gone unnoticed for what, about a year for jabs (when the jab hit radius was increased) and longer for slashes?

 

The raycasting would have to be done in scripts, or a "script callback raycast" function added to the engine, or a special case "raycast against blobs with specific traits" function added to the engine. The first two are super slow (the 2nd is actually slower due to jumping between AS context and C++ context and marshalling values repeatedly) and the 3rd is a weird special case, that'd then need to be either ad-hoced onto the hit infos code, or handled "after the fact" like it currently is. The raycasting for tiles is done as part of collecting hitinfos, which is why it occludes objects properly.

The reason existing raycasting isn't used is that if it is, standing inside platforms makes attacking "not work" mysteriously, and depending on where you raycast to, standing inside platforms can make you invincible. It worked that way for a few builds, but was obviously hugely problematic. Similarly, open doors block attacks with that method. It's not bulletproof.

 

@Fuzzle I hilariously don't have access to making that approved, but in response to your question, they're indeed calculated with rays sweeping outward from the middle of the hit arc. First hit adds the object to the list and stops raycasting to it.

I've got a similar solution that I was gonna ask you folks to test, I've uploaded it - it actually depended on an engine-side fix for the blob radius being double what it should be, so this is very slightly modified (see line 817).

This ignores the hit position entirely at least for blocking behaviour, and uses the same thing for tiles - it converts blocking objects into an angular position and angular size and then uses that for blocking hits. There's a minimum size used, not sure if that's a sensible idea or not.

Looks like we're going in the same direction. I'm going to leave this for now and look at how this develops tomorrow, I'd like to get a fix out soon but I don't want to keep pushing to production for "testing" :)

 

They do have a radius - it should end up as something "quite big" though. That in turn should make them behave more or less the same as the old implementation - once they're encountered, they'll block all hits.

Re: your list - definitely valid concerns. This was all done in a hurry, as should be pretty clear.

• That's what I get for hastily copying formulae :) Could have sworn there already was a pi constant somewhere. I guess it didn't make it AS-side.
  
• Makes sense. Merging the occluders is a good idea but also fiddly.
• I don't think it is, they have a more aggressive radius check, but I'll look into it.
• I'm not sure it should - blobpos is the knight's position, pos is the hit position. It's inconsistent with the attack code above, but I think they should use the knight pos as well (rather than the hit arc pos)
  
• Tile radius is intentionally lower, as there's already a raycast in place - I don't mind people hitting stuff that's detected as a hit around corners a _little_ earlier.

I don't have time to implement many of them at the moment though, I'm not meant to be on KAG this week :)

If you're excited to work on your one, please go ahead - for now I'm considering fixing the major bugs you've outlined and pushing out a minor build to bandaid the issue in the meantime.

 

Yep, this has been left since last time. If there is a door closer to the attack point than the builder is, it'll currently "block" the attack.

@Fuzzle I'd honestly be ok with a more vague system than currently - I don't really care much about the "through-single-hole" case here, it's more the "door 90 degrees away from target blocks attack" case. The attacks aren't particularly far-reaching so there's only so much ambiguity, and I've got a feeling a fully accurate solution is going to involve a lot of debugging.