Angled vehicles develop holes [$15]

[Headjack]

While all this vehicle renaissance is going on, does it seem feasable to tackle that problem where cars at a 45-degree angle can be entered diagonally between otherwise solid parts? I think you know what I mean, how if two boards are adjacent vertically, at an angle you'll cross between them somehow. Ideally it would check the vehicle structure and make the space beyond functionally impassable/opaque from only that side. It'd probably be a tough fix, but it ought to happen at some point.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[i2amroy]

Probably would require a bit of an update with pathing where squares could be flagged as "diagonally impassable", which would mean if two diagonally impassable squares are diagonal to each other you can't cross between them diagonally.

[Headjack]

So long as it only applies to vehicles, I'd imagine.

[Zireael07]

Any chance of getting a fix?

[tyrael93]

This issue was opened seven months ago and never resolved.
What do you think?

[KA101]

Spewing bile is more likely to slow dev work, since I don't think we code with 3-4 environmental resistance on our eyes. Don't be a boomer!

[tyrael93]

I'm sorry, I didn't know stating plain facts was a hate crime. My deepest apologies.

[Headjack]

It'll probably be folded in with a bigger vehicle update once that sort of thing rolls around. I think dev is mostly on some other polish right now, and I think the z-level bounties which are a tough target. But let's just hold out for the moment; even when I put it up it was just to put down the issue for being logged.

[kevingranade]

Many years later and I have a proposal to fix it, but no time to implement it at the moment.

Any time a vehicle is skewed, add a "clone" of the shifted part that covers the gap.

Tiny ascii illustration:
Facing north:

####
|00|
|00|
####

Rotated to NE:

####
 \00\
  \00\
   ####

Rotated to NE, plus gap covers:

#####
\\00\\
 \\00\\
  #####

To make it even simpler, widen the vehicle in the two locations that this scheme avoids, it doesn't prevent problems, but it makes it consistent:

######
 \\00\\
  \\00\\
   ######

Additionally, when a vehicle is "partially skewed", you can either just block the gaps:

####
\00\\
\\00\
 ####

Or widen the whole vehicle:

######
\\00\\
 \\00\\
 ######

This effectively makes the vehicle slightly thicker when skewed, which might cause some unexpected collisions, but that's a lot easier to cope with than the existing gaps.

The tricky part is taking collisions to the "cloned" parts and allocating the impact correctly to the original part.

[Epictyphlosion]

Many years later and I have a proposal to fix it, but no time to implement it at the moment.

Any time a vehicle is skewed, add a "clone" of the shifted part that covers the gap.

Tiny ascii illustration:
Facing north:

####
|00|
|00|
####

Rotated to NE:

####
 \00\
  \00\
   ####

Rotated to NE, plus gap covers:

#####
\\00\\
 \\00\\
  #####

To make it even simpler, widen the vehicle in the two locations that this scheme avoids, it doesn't prevent problems, but it makes it consistent:

######
 \\00\\
  \\00\\
   ######

Additionally, when a vehicle is "partially skewed", you can either just block the gaps:

####
\00\\
\\00\
 ####

Or widen the whole vehicle:

######
\\00\\
 \\00\\
 ######

This effectively makes the vehicle slightly thicker when skewed, which might cause some unexpected collisions, but that's a lot easier to cope with than the existing gaps.

The tricky part is taking collisions to the "cloned" parts and allocating the impact correctly to the original part.

A better solution would be to make it so that the gap covers count as one part, even though they appear as two when the vehicle is at an angle, meaning...
(X = Part being damaged)

######
 X\00\\
  \\00\\
   ######

Instead of just basically doubling the amount of parts when the vehicle is at an angle...

######
 XX00\\
  \\00\\
   ######

They are counted as one part. So it appears that two parts are being damaged, even though it's really one part being damaged, and it would show up like that once the vehicle straightens out.

I hope I didn't make this too complicated. But I also hope this issue doesn't become five years old, lol

[Asmageddon]

Alternative idea: An 8-direction bitfield on every tile, which remains zeroed for terrain, but for vehicles and their neighboring tiles is computed based on the traversability of the original, unrotated vehicle. If the appropriate bit is 0, any checks proceed as they usually would, but if it's 1, a more involved check can be performed to see what other tile the current algorithm(raycasting, movement, pathfinding) should be redirected to. It'd also work for non-boundary walls as well.

I'm probably ignorant about how the current code looks, but my intuition says algorithms could probably be changed to use this bitfield, possibly replacing bool->bitfield for visibility also, thus leaving the standard checks(==0 and ==255) intact, e.g. without injury to performance for the common cases.

Would probably be a pretty involved change, though it could conceivably be futureproofed against if someone wants to do portals some distant baleful day. One way or the other.

[mlangsdorf]

I honestly have no idea what that bitfield is supposed to do or how it's supposed to work. Can you explain with a concrete example?

For instance:
There is a standard car at local position [ 3, 3 ]. It has a windshield at mount [ 1, 2 ], a door at mount [ 1, 1 ], and a door at mount [ 1, 0 ]. It's pivot point is actually mount [ 0, 0 ], it's turned 45 degrees, and the parts have local position [ 2, 5 ], [ 3, 4 ], [ 4, 3 ], starting at the windshield and then the two doors. An NPC is near to the car at [ 5, 5 ] and wants to get in to steal my katana, sitting on the seat at [ 3, 3 ].

Currently, the NPC movement code checks to see that there are no obstacles between [ 5, 5 ] and [ 3, 3 ]. There aren't, so the NPC walks to [ 4, 4 ] and then [ 3, 3 ] and can take it.

How are the bitfields changing this situation?

[Asmageddon]

@mlangsdorf Sorry, I guess I botched typing that. The idea is that instead of having a single boolean representing whether a tile is traversable, to have a field of 8 bits representing directional passability. For ordinary terrain, it would always be either 0 or 255, but for rotated vehicles... actually, it's a bit of a PITA, but I'll draw a demonstration of sorts.

With red/orange dots representing bits that are 1. If they're all 0 or 1, code can just treat them exactly as it currently does, alternatively it takes a slower path which checks the individual appropriate bit.

E.g. still check obstacles, but situationally(vehicles), do a directional check instead since a boolean is insufficient to represent the fact that only some tile boundaries are impassable.

[Zireael07]

Just to clarify, red dot means it's impassable? So most parts are impassable from all directions, and possible holes (orange) are impassable on diagonals?

[Asmageddon]

@Zireael07 Correct. This could hypothetically be used to avoid holes within the vehicle, as well as making diagonal passages impassable, or directionally passable tiles(turnstile).

[mlangsdorf]

Thanks, I think that's a lot clearer.

So the seat tile at mount [ 0, 0 ] has its bitfield set so that diagnol movement is impossible. NPC pathfinding algorithm sees that's impossible to move from [ 4, 4 ] to [ 3, 3 ] and proceeds to bash the windshield.

Fair enough.

I'll defer to Kevin as how hard it would be to get this to interact with the light, vision, and pathfinding code.

[kevingranade]

The impact to the code would be VERY high, not only would everything that cares about opacity, damage application, navigation or movement have to be updated, but it changes the current "can I enter this square/can I see through this square" check to "can I enter square x from square y/can I see into square x from square y".
I'm not at all sure how this would interact with vision. The way vision interacts with opaque tiles is that you can see the opaque tile, but nothing past it. In this case is it the tile adjacent to the vehicle that counts as opaque or the vehicle tile itself?

From the point of view of addressing the diagonal gap issue, I much prefer the other solution, it's completely localized to the vehicle system instead of requiring updates throughout the rest of the code.

[Asmageddon]

Yeah, it'd probably touch a lot of code. And you'd probably have to do two branches instead of one, one to cover ==0 and one for ==255, before finally falling back to the directional code. And in this case, the tile which cannot be entered from the current direction would be considered opaque. E.g. from inside the vehicle, the grass tile is opaque, from outside, it's the inside one that is.

Still, I wanted to pitch the idea mainly, since idk, creating faux parts strikes me as really inelegant. It does sound efficient and effective, but... well, there's a reason why I have difficulty managing coding nowadays.

[Headjack]

Asmageddon's solution sounds ideal to me, but the impact issue is important too. The bitfield can't be applied only to vehicle tiles?

[mlangsdorf]

It's not whether it can be applied only to vehicle tiles or not, it's the other areas of the code that need to know about the bitfield.

The nice thing about Kevin's hack is that it isolates all the changes to the vehicle code.