Some issues with Gap.outsideCollisionBlocker

[SomeRandomNoobKekeke]

Disclaimers

• I have searched the issue tracker to check if the issue has already been reported.
• My issue happened while using mods.

What happened?

disclaimer

Well, i'm not saying you must fix all of them this instant. I'll just put them here so you know. Imho it might even be easier to rework this outsideCollisionBlocking system entirely
I used this for testing
I might have misunderstood how some of these things work
Videos are potato quality mostly because of github 10mb limit

1. There are many zones not covered by collision blockers on each sub

uncovered.mp4

another example

Barsuk.dead.zone.mp4

They seems to be located where the ray from hullToOut gap is blocked by something
It could be second layer of walls, turrets, maybe depth charge tubes, maybe some fins

There's an easy way to see them:
lock sub, freecam, explode the sub, teleport it into a wall, wait a few seconds until all colliders settle, teleport it back into open water

First all colliders activate because they are in the wall and then in water every collider disables except for blocked ones because you just return without setting its state to false here

Here are screenshots of every sub, green zones are uncovered

2. Colliders are not disabled explicitly and remain active by default

This is not really a problem by itself but opens a gap for more problems
I suppose normally colliders are updated when somebody approaches the gap
And might remain active if the gap if left alone

sub.is.moving.mp4

3. Colliders that remain active seems to be blocking lasers and bullets

blocking.lasers.mp4

4. Sometimes you can enter submarine without triggering the gap

It works a least on the bottom of Orca 1, i don't really understand why, maybe because ballast hulls are not intersecting with outer walls

So you might touch colliders that remain active and doesn't want to update

not.updated.mp4

5. Colliders spawn between main sub and its drone

Drone.mp4

6. Colliders between main sub and pirates are annoying

Imagine pirates sank on your sub
All entrances blocked, subs stuck, you drilled a hole to them but you can't pass through it because of these pesky colliders, and there are not enough space between subs for you to be considered outside

pirates.mp4

7. Closed hatches don't create colliders

It's kind of intended, but what if the hatch is deep inside the sub, or walls around it are broken? It will create a hole in colliders

hatch.mp4

Reproduction steps

Use this

Bug prevalence

Happens regularly

Single player or multiplayer?

Single player

-

No response

Version

v1.2.8.0 (Winter Update hotfix 2)

-

No response

Which operating system did you encounter this bug on?

Windows

Relevant error messages and crash reports

No response

[Regalis11]

Thank you for the report!

I'm not entirely sure I understand all of the listed issues. To me it seems like you might be misunderstanding what this system is and how it's intended to work: these blockers are only intended as a way to prevent you from ending up inside a wall or other solid obstacle when you exit the sub.

1. There are many zones not covered by collision blockers on each sub

Does this cause some kind of issues? There are plenty of situations in which there is no need for the "blocker" when you're exiting (that seems to be the case in the first clip for example).

2. Colliders are not disabled explicitly and remain active by default

Why is this a problem? They should only register collisions with characters leaving the sub, so I don't see why they need to be disabled. Projectiles colliding with the "blocker" seems to be a bug though, that should definitely be prevented.

4. Sometimes you can enter submarine without triggering the gap

Why should it trigger when entering the sub?

7. Closed hatches don't create colliders

I don't see why they should. You cannot exit the sub through a closed hatch, so there's no need to prevent collisions while you're exiting.

Imho it might even be easier to rework this outsideCollisionBlocking system entirely

Do you have some kind of ideas on a better system? I feel like this is a non-trivial problem to solve with the way moving into and out from subs works in the game.

[SomeRandomNoobKekeke]

I mean there are more ways to end up inside a wall:
If you try to leave the sub in uncovered zone you might accidentally swim into a wall and get stuck, some of that zones are too close to subs border
While you are repairing hull from outside, submarine may move and push you inside a wall
Creatures that are tryng to board the sub might get pushed into a wall as well

People manage to swim into a wall from time to time

If it's just for when you're leaving the sub then fine, who needs to repair outer hulls, care about tigerthreshers anyway?

2. Colliders are not disabled explicitly and remain active by default. Why is this a problem?

Well it's not. But i would disable them just for safety. It would solve 3 and 4. Also as you can see in 1 if you somehow enable blocked collider it will remain active and blocking you inside sub forever (or until you fix its gap)

4. Sometimes you can enter submarine without triggering the gap
   Why should it trigger when entering the sub?

For the people that are fixing hulls from outside. But yes, you can just ask Artie to do that

7. Closed hatches don't create colliders. I don't see why they should.

Just for cases when your sub is falling on a thresher swarm, they naturally gather around hatches and often pushed into a wall like this. But who care about tigerthreshers anyway?

Imho it might even be easier to rework this outsideCollisionBlocking system entirely.

I think it works accceptable in vanilla, but it doesn't work at all for larger creatures

It's not even intended to help creatures eat you

ye ok

Do you have some kind of ideas on a better system?

I do, but i'll probably make a mod first and if it works fine then i make a PR

[Regalis11]

I think there's probably still some kind of a misunderstanding of what these do. They are only intended to stop you from colliding with things outside the submarine when you're exiting the sub, i.e. when you're still in the submarine's "local coordinate space" and cannot "actually" collide with things outside. I don't see why there'd be any need for them to affect characters outside the sub: they are already in the "external coordinate space" and collide normally with level walls and such. Characters outside don't collide with these blockers though, because the blockers are in the sub's local coordinate space.

To me it seems like the only clear issues with the blockers here are that projectiles can hit them, and that they don't take into account whether the obstacle outside is a broken wall that you should be able to swim through. Those are things we definitely look into, but the others seem unrelated to the blockers / or misunderstandings of what they do or how they work and not really issues in the system.

I think it works accceptable in vanilla, but #12680

The issues mentioned in that discussion have nothing to do with the blockers. We have implemented support for allowing large monsters to enter sub for the next update though, albeit in a different way: they don't teleport to the sub's internal coordinate space at all (because that causes issues like the ones in the clip posted there).

[SomeRandomNoobKekeke]

I didn't mean that they need to affect characters outside. I meant cases when 99% of your body is ouside but you are touching some broken wall with your toe and considered inside

[Regalis11]

I still don't quite follow. You mentioned for example threshers getting pushed by closed hatches: unless I'm missing something, enabling the blockers on those would not affect anything. The threshers wouldn't collide with them because they're outside, and characters exiting the sub shouldn't collide with them either because you can't exit the sub through a closed hatch.

Colliders are not disabled explicitly and remain active by default. Why is this a problem?

Well it's not. But i would disable them just for safety. It would solve 3 and 4.

Also, to continue on this: it would not solve 3 and 4. It would just make the issue occur in the situation where the blocker is active, e.g. that you couldn't fire the turret when someone is exiting the gap near it.

[SomeRandomNoobKekeke]

I mean if there are broken walls around the closed hatch, threshers are long, they can touch it and be consideren inside while hatch is closed and there's no collider against it
it's rather rare case, so it's ok if you ignore it
I think same will happen if there are broken wall next to intact one, so yes, there's nothing special about the hatch

Yes, ok it wouldn't fix 3, but 4 seems to be caused by colliders being active when there's no reason to be

[Regalis11]

I mean if there are broken walls around the closed hatch, threshers are long, they can touch it and be consideren inside while hatch is closed and there's no collider against it

Ah, I think I got it now! So you're thinking of something like a situation where at thresher is exiting the hatch, the hatch then closes, and the collider gets disabled even though the thresher is still considered to be inside? That does seem like an issue, although I don't think keeping the collider enabled would be an appropriate way to fix it. The same issue could happen if there was a solid wall in place of the hatch: the thresher could exit through a gap next to it, and wiggle to the position with no collider while still touching the sub, and end up inside a level wall.

This is not a trivial problem to solve, so if you do have ideas for a solution, I'd be very interested in hearing what you have in mind! I think a robust solution might be something like modifying the physics engine so a fixture can register collisions in both the sub's internal coordinate system and the external. That could possibly be done by making it actually exist in two positions in the quad tree that stores the fixtures (and then adding some custom logic to handle the collisions in both coordinate spaces), or maybe by using some kind of a "proxy fixture" that registers the collisions in the "other" coordinate space.

[SomeRandomNoobKekeke]

No, i just thought of making them slightly more precise
Like Scanning cells in radius of length of the boarding creature and not in ray, make colliders exactly match outer edges of those cells, move them relative to the sub so they would stay in the same place in real world

That could possibly be done by making it actually exist in two positions in the quad tree that stores the fixtures (and then adding some custom logic to handle the collisions in both coordinate spaces), or maybe by using some kind of a "proxy fixture" that registers the collisions in the "other" coordinate space.

i like your funny words magic man.jpg

Btw, how do you know all this? Do you have some secret farseer docs or did you just read all the souce code?
Their site seems to be dead, and docs in archived version are very shallow and don't look like a docs
There's no words about quad trees or proxy fixtures
Should i just look in box2d docs and guess how it should work in c#?

[Regalis11]

Like Scanning cells in radius of length of the boarding creature and not in ray, make colliders exactly match outer edges of those cells, move them relative to the sub so they would stay in the same place in real world

Something like that could work too, but I feel that'd easily get very complex: you'd most likely need to modify the shapes of the fixtures on the fly, and possibly use some more complex shapes than just lines to ensure they always cover anything. And even then, it might not be foolproof: each individual fixture might need to be arbitrarily large to ensure nothing can get past it, no matter how large the character is.

Worth noting though that they do already move relative to the sub, but the position is only refreshed periodically because doing the raycasts frequently would lead to performance issues (and the "scanning" and modifying the shape would most likely be much more expensive).

Btw, how do you know all this?

I've gradually learned it by just using it, reading through the code and messing around with it (we've e.g. done quite a bit of modifications and optimizations to it during the development). The code is pretty well documented and easy to read. And since it's a fork of box2D, the box2D docs are also very useful: practically everything in there applies directly to Farseer too, even though the syntax of the code examples is slightly different. For example, it explains what fixtures and "trees" are in this context, both of which you'd probably need to understand if you wanted to lets say modify the shapes of the colliders to match the edges of the cells.