Marisa Kirisame wrote:That's one big difference with UE1. At least it had a concept of "out of bounds" (and it was very aggressive in enforcing it).

I wonder just how hard it'd be to figure out a way to detect when things are really outside of any sector.

The easiest way would be to get the actor's current sector* and check if the actor's current position/center is inside the sector's polygon. That will only check the actor's center, but should be enough.I'm using the algorithm from this StackOverflow answer in my mod.Of course, such a method isn't perfect, and probably has some edge cases, but way better than nothing.

Hege Cactus wrote:also why the does the engine even still make it run if its 32K outside the map/last used linedef? Even basic game engines have "out of bounds" check to destroy an object that goes way way outside the bounds :V

I don't think anybody would cry too many tears if any non-player actor that left the map boundries got automatically deleted.

"Doom does not know the concept of 'outside any sector'. Any valid point inside the map boundaries belongs to some subsector and as a consequence to some sector."

This explains why when you're next to a sector with slime (but don't appear to be in any sector) you take damage. It would be interesting to show a sector's true extent with some faint lines, especially for slime sectors, so you can avoid them when nocliping around the map.

Presumably some of the plasma balls were passing through the walls, somehow, getting into the void and then carrying on until they tried to make a sound (death sound? - though they can't have hit anything). Problem is, I don't think I can do anything about this from a mapping perspective.

[edit] I just watched the same thing but I was at the automap with cheats enabled. Sure enough, the sentry plasma was getting through the walls quite a bit. Checking the DECORATE for it, it has a radius of 1 and a speed of 20 but does not inherit from FastProjectile. Presumably, remaking it to inherit from FastProjectile would help prevent the projectiles passing through the walls. However, I'm still unsure if a) that would cure the problem 100% of the time and b) how valuable the error message is in a case like this. Although, I suppose it has flagged up a potential improvement in the actor definition. [/edit]

Yup, that's been a thing forever - probably right back to people dehacking Doom projectiles to be tiny. Inheriting from FastProjectile usually cures problematic actors if the radius needs to be particularly small for whatever reason.

Interesting. I see that the Mancubus projectile also has a speed of 20. I guess it's around about that value that collision with certain 1s wall starts failing.

Question is, if a mancubus fireball passes through a wall and keeps going, can it get outside the maximum map size and, if it does, will it cause one of these messages when/if it dies? If so, i guess this message could even pop-up on Doom2 IWAD maps.

Enjay wrote:Interesting. I see that the Mancubus projectile also has a speed of 20. I guess it's around about that value that collision with certain 1s wall starts failing.

Actually, it has less to do with the speed and more to do with the fact that its 6 radius gives it a total horizontal hitbox size of 12, which means there's 8 units it moves each tic that are just completely skipped by its collision checks. Bump it up to 10 radius and it'll suddenly stop skipping walls entirely.

Enjay wrote:Interesting. I see that the Mancubus projectile also has a speed of 20. I guess it's around about that value that collision with certain 1s wall starts failing.

Actually, it has less to do with the speed and more to do with the fact that its 6 radius gives it a total horizontal hitbox size of 12, which means there's 8 units it moves each tic that are just completely skipped by its collision checks. Bump it up to 10 radius and it'll suddenly stop skipping walls entirely.

Not correct. If the movement speed is larger than the radius the move will be split, but once the radius falls below a certain threshold, the entire movement logic becomes slightly erratic. This is some really, really bad code and not how movement should have been implemented.