Vgstation13: Chair scooting lets you scoot through and on top of borgs

[D3athrow-Issues]

(WEB REPORT BY: sonixapache REMOTE: 172.93.109.202:7777)

Revision

c49d1851271db3264cee2c04307e7f151b09e5bd

Description

You can chairscoot through borgs.
You can land on top of borgs by chairscooting.

Steps to Reproduce

Chairscoot with a borg in or at the end of the line of movement

What you Expected

Stop when chair hits borg

What Actually Happened

go through or land on top of borg

[SonixApache]

[insert passive-aggressive whining here]
May also apply to humans, didn't really check as I was playing a borg and I noticed it in the escape shuttle.
@Unknown-as-Captain

[ghost]

No problem here, chairs are non-dense even when buckled so you could always do this, from dragging or ZAS or anything that moved chairs

(gif taken from different branch before scooting)

[ghost]

If you think this is a consistency issue and should be changed anyways I'm a bit of at a loss on how to fix it because this stuff is based on density, unless I add a super snowflake anti-CANPASS flag or something

I also just tried making office chairs dense when locked, and you won't like how THAT works. Rollerbeds do that, and they make you immune to bullets when buckled because bullets cannot into dense objects

[SonixApache]

what
what

[ghost]

Basically, although this is "working as intended" I can see why this might want to be changed

It's very problematic code-wise to change it though

[Riekland]

are you fucking serious you retarded nigger

[Exxion]

The fact that the bug existed before does not make it a feature

[ghost]

I already acknowledged that it probably should be changed and I already explained the difficulty in doing so, I'm open to ideas

I've GOT to say it's literally not a bug, though

[SonixApache]

it's literally a bug, but for your PR it's working as intended

[ghost]

c https://github.com/vgstation-coders/vgstation13/issues/15963#issuecomment-328981124

Chairs do this for all known methods of movement, scooting is no different and didn't change anything, the title of this issue should be "office chairs can go through and top of mobs if moved"
This is because they are non-dense (you don't want them to be dense, either)

Trying to find a solution now and boy is this a can of worms
https://github.com/vgstation-coders/vgstation13/blob/Bleeding-Edge/code/modules/mob/living/living.dm#L1266

[jknpj]

why not just make chairs dense when they have locked atoms?

[ghost]

See above: https://github.com/vgstation-coders/vgstation13/issues/15963#issuecomment-328982111
Rollerbeds do that, and it's really, really bad

Experimental PR soon

[jknpj]

You can make use of bullet_act to fix that.

[ghost]

Bullets are just one example, you'll find a lot more wonky stuff

Anyways like I said, PR soon

[Shadowmech88]

Couldn't you make it so that when an atom attempts to bump another atom, it first checks whether there is anything locked to that atom and, if so, bumps that instead of what it actually hit?

Unless I'm missing something, that should fix all collision issues that have to do with locking atoms to dense atoms.

[ghost]

Bump is what happens AFTER the atoms have determined if they collide or not, I'd have to do this during Cross, exclusively on the receiving atom

That said: I'm fairly sure that's already the case for what happens when you try to run into somebody that's on an office chair. Enter the fucking spaghettibowl: https://github.com/vgstation-coders/vgstation13/blob/Bleeding-Edge/code/modules/mob/living/living.dm#L1266
It just results in nothing happening

[Shadowmech88]

AFTER the atoms have determined if they collide or not

Why is that a problem? If a thing determines during Cross() that it collides with a chair, it'd logically be colliding with the person on that chair, wouldn't it? So what's the problem with having the Bump() call itself with the locked atom as the argument in order to have it bump the buckled person rather than the chair?

[Exxion]

The problem is when the chair is doing the moving, not when the chair is being moved into

[Exxion]

Oh I'm sorry, you said that correctly. I'm just tired.
The problems are:

1. That Bump() is an internal call. We have no control over the arg passed.
2. Our movecode doesn't use inheritance. The chain is broken at many points. We'd have to correct that to even have a chance of fixing it in a way similar to that.

[Shadowmech88]

Alright, so altering Bump() won't work.
I'm not familiar with Cross(), but could we do something similar using that? If an atom is being crossed by another, have it check whether the atom doing the crossing has an atom locked to it and, if so, check that atom's density in addition to the density of the atom doing the crossing?
Or from the frame of reference of the atom doing the crossing, have it check whether it has an atom locked to it and, if so, have it check that atom's density in addition to its own before determining whether it can cross?

This would make it so that non-dense things with dense things locked to them would be unable cross dense things.

[ghost]

That'd be point 2 I think, for that to work you need to edit the super-most-call of Cross() and anything that overwrites that without calling super gets baloney'd.

But that's not a bad idea on its own.

[ghost]

Also, if you call Cross() on another item, does that automatically proceed to Crossed() or Bump() or whatever? Or is Cross() just essentially canCross()?

[Exxion]

If you call it manually, nothing happens other than what is inside Cross() itself.
In internal calls:
Tile movement (like us): in /turf/Enter(), after the stuff in that proc executes, Cross() is checked for everything in the tile. If any of those return false, Enter() returns false. If Enter() returns false, the first dense object on the tile (NOT necessarily the object whose Cross() failed) has Bump() called on it, and movement halts. If Enter() returns true, the tile is successfully entered, and Entered() is called on the turf, and Crossed() is called on everything on the turf.
Pixel movement: When something's bounding box attempts to intersect with another object's bounding box, Cross() is called. If it fails, Bump() is called on said object. (Note that if two objects have bounding boxes that end at the same place, the first one in its loc's contents will be the one Bump()ed.) if Cross() succeeds, movement continues as normal and Crossed() is called on the object. /turf/Enter() does not directly factor in.

[Intigracy]

There's no way the janicart lets you drive over people like you can on these chairs, and you can hit people on them with projectiles

How does it do it that you can't adapt it?

[Exxion]

The janicart is dense

[Kitfox88]

I thought the Janicart absorbed impacts that hit it while driving around until it blew up?

[Exxion]

It does

[ghost]

It does because it's specifically coded to, but there's other stuff such as being immune to thrown items