Issue #44. Double call to Trigger.Touch when touching a Trigger just once

[Masterkent]

Sometimes entering the collision cylinder of a Trigger results in two calls to Trigger.Touch. This may lead to unwanted effects, such as doubled triggered messages and double toggling. A double toggling can be very frequently observed on SkyBase.unr (when you try to use some button that controls a door, the corresponding trigger often activates the door even number of times resulting in an opening followed by an immediate closing or a closing followed by an immediate opening).

Whenever Touch is called twice per single approach, the first call takes place when the collision cylinders of the player and the trigger do not intersect, and such a call is followed by the corresponding call to UnTouch on the same tick. The next call to Touch is then performed on the next tick, when the collision cylinders intersect:

[Leo T_C_K]

zeur confirms:
"(due to a whirlwind of events I haven't gotten around to implementing hyper's proposed solution, or just about anything else with the craptop, so STFU about that)

Sometimes entering the collision cylinder of a Trigger results in two calls to Trigger.Touch. This may lead to unwanted effects, such as doubled triggered messages and double toggling. A double toggling can be very frequently observed on SkyBase.unr (when you try to use some button that controls a door, the corresponding trigger often activates the door even number of times resulting in an opening followed by an immediate closing or a closing followed by an immediate opening)."

Present in 225f. Noticed it when writing korax.ProximityDoor. Didn't make the link w/ the SkyBase door (which I'm otherwise well aware of), though.

Whenever Touch is called twice per single approach, the first call takes place when the collision cylinders of the player and the trigger do not intersect, and such a call is followed by the corresponding call to UnTouch on the same tick. The next call to Touch is then performed on the next tick, when the collision cylinders intersect:
[snip ad]

I haven't confirmed that part, but it sounds likely.
        --zeur."

[)Leela(-[otS]-]

This is one of the most annoying things with Triggers and Movers set to TriggerToggle when Players or other Pawns touching the Trigger directly.
I can't count how many workarounds I made for such situations and it was even worse when the Movers or Triggers also were set to TriggerOnceOnly.
I really hope, that this annoying "double call" problem can somehow be fixed in the future.

[Leo T_C_K]

zeur sighs:
"

This is one of the most annoying things with Triggers and Movers set to TriggerToggle when Players or other Pawns touching the Trigger directly.
I can't count how many workarounds I made for such situations and it was even worse when the Movers or Triggers also were set to TriggerOnceOnly.

Yeah, this kind of problem made me invent korax.ActionSpecial in the first place. That and UnrealBloat(tm).

I really hope, that this annoying "double call" problem can somehow be fixed in the future.

Let's just hope the fix won't break too much existing stuff.[1]
--zeur.

[1] I wouldn't mind breaking compat if Unreal were rewritten altogether, but alas, that ain't going to happen anytime soon..."

[Masterkent]

Whenever Touch is called twice per single approach, the first call takes place when the collision cylinders of the player and the trigger do not intersect, and such a call is followed by the corresponding call to UnTouch on the same tick. The next call to Touch is then performed on the next tick, when the collision cylinders intersect:
[snip ad]

I haven't confirmed that part, but it sounds likely.

Actually that's demonstrated on the video that you called "ad" (LOL). I modified the UScript code of Engine.Trigger so it indicated the horizontal and vertical overlapping of the collision cylinders of the trigger and the pawn. Negative values imply no overlapping. The game performed ~60 ticks per second, and the number of ticks between the adjacent messages can be calculated based on the time stamps.

[Leo T_C_K]

zeur snarks:
"

Actually that's demonstrated on the video that you called "ad" (LOL).

Mesupposes mecould've called it 'goo''.

I modified the UScript code of Engine.Trigger so it indicated the horizontal and vertical overlapping of the collision cylinders of the trigger and the pawn. Negative values imply no overlapping.

Ah, thanks for the exposition.

The game performed ~60 ticks per second, and the number of ticks between the adjacent messages can be calculated based on the time stamps.

Hold on, isn't there a way to access the tick count using UShit? Me's never had to try...
--zeur."

[Smirftsch]

checking the code it appears that both SetCollision and SetCollisionSize do untouch/touch and do this only by determining bCollideActors. Wouldn't be surprised that to be related to it somehow. Need to start logging now...

[Masterkent]

Unlikely SetCollision or SetCollisionSize are related to this issue. In ConformanceTest_Touch.RunTest, there are two evaluations of A.Move(vect(0, 1, 0)):

Code: Select all

      SetCollision(true, false, false);
      SetCollisionSize(40, 40);

      SpawnLocation = vect(-4.529744, -58.626865, 0);
      A = Spawn(class'Trigger',, 'ConformanceTest_Touch', SpawnLocation);
      A.SetCollisionSize(17, 39);
      A.Move(vect(0, 1, 0));
      A.Move(vect(0, 1, 0));
      if (!bHadValidTouch)
      {
            LogError("Touch was not called for intersecting cylinders");
            LogParam("Horizontal intersection of the cylinders", -HorizontalDistanceTo(A));
      }

The former evaluation slightly moves the Trigger (call it A) towards the ConformanceTest_Touch actor (call it B) so that A doesn't actually reach B (their collision cylinders don't overlap yet), but this call to Move invokes Touch and UnTouch somehow. Then the second evaluation slightly moves A towards B farther (in exactly the same direction) so that the collision cylinders of A and B become overlapping and Touch is invoked again.

[Smirftsch]

nvm that first assumption. After some logging I found that MoveActor didn't do a cylinder check before initiating BeginTouch, but UnTouch check again directly after that did it.
I added it and it seems to do fine, also passing your test. It's now slightly more expensive, but I doubt its much of a problem here.
Will do some playtesting later yet.