Page 1 of 1

CanCollideWith and teleporting stuff

Posted: Mon Sep 11, 2017 2:32 pm
by JPL
I have a setup where the player teleports (ACS special 70) to a TeleportDestination, and very close by is a ZScript actor that overrides CanCollideWith for some custom touching/not-touching logic. When the player enters and exits the actor's radius by walking its CanCollideWith logic operates as intended, but when the player teleports into its radius as described, CanCollideWith only begins to fire once the player begins moving within its radius - if the player doesn't move after teleporting, they'll never trip the actor's CanCollideWith logic.

This seems like a bug rather than intended behavior... if it is, feel free to move this to the bugs forum. If not I'd be curious as to what the rationale is. There's probably a way I can work around this (manually nudge-moving the player a bit right after the teleport maybe?) but if it's a bug I'll let the fix save me that work.

Re: CanCollideWith and teleporting stuff

Posted: Wed Sep 13, 2017 12:23 pm
by Matt
Could this be related to the (intended, canonical vanilla) behaviour with pickups where they won't be picked up unless you're moving (or, in ZDoom, crouching)?

Re: CanCollideWith and teleporting stuff

Posted: Wed Sep 13, 2017 5:49 pm
by JPL
Vaecrius wrote:Could this be related to the (intended, canonical vanilla) behaviour with pickups where they won't be picked up unless you're moving (or, in ZDoom, crouching)?
As best as I can tell from the code, yes quite possibly. Pickups have their own special case handling via Touch / P_TouchSpecialThing, but that happens during PIT_CheckThing which I don't think is called for players that aren't moving(?).

I think I found a workaround, which is to run CheckPosition in the Tick of the object I want to detect collisions with, effectively re-checking for collisions every frame. On a map with about 30 of these, it appeared to add 1ms to "stat think". The map will eventually have about 200 of them so we'll see how that scales!

If anyone with deep knowledge could weigh in on whether the current behavior is intended (or, alternately, "unintended but way too sensitive to try fixing") that would be useful!