[BUG] Teleports broken in versions newer than 4.11.3

[nickbailuc]

GZDoom version

4.14.0

Which game are you running with GZDoom?

Doom 2

What Operating System are you using?

Linux ARM (Raspberry Pi)

Please describe your specific OS version

Debian 13 (trixie)

Relevant hardware info

Apple M2

Have you checked that no other similar issue already exists?

• I have searched and not found similar issues.

A clear and concise description of what the bug is.

After filing #2830 , I realized this is not just for silent teleports in myhouse.pk3 but for regular teleports in vanilla Doom. I tested the original doom2.wad, the BFG doom2.wad, enhanced doom2.wad, and kex doom2.wad. Walking into a teleport does not trigger them immediately, but instead keeps you in the same location usually. Walking back and fourth through them, or with momentum sometimes randomly does trigger the teleport, but this seems to happen entirely random.

Steps to reproduce the behaviour.

Explain how to reproduce

1. Launch any vanilla Doom2 wad (original, BFG, enhanced, kex)
2. Go to MAP04
3. Walk through the teleporters in the end of the map

Your configuration

completely vanilla config, not even key bindings

Provide a Log

No response

[JeodC]

Hi, came across this error when testing various mods. I can confirm on linux arm64 teleports will only function if you are sprinting as you hit them. Normal player movement does not trigger them.

[nickbailuc]

Hi, came across this error when testing various mods. I can confirm on linux arm64 teleports will only function if you are sprinting as you hit them. Normal player movement does not trigger them.

I have always run activated, but I guess even then it needs a certain speed (although I remember sometimes it works at a low speed randomly too). In any case this is bad in the vanilla games and ruins any silent teleport WADs.

I just use g4.11.3 because it's the last version that worked properly, so definitely something changed in the newer versions that created this bug.

Any idea why this is happening specifically in linux-arm64, and what other architectures it may be happening on?

[JeodC]

Tick rate differences, especially in physics. I am able to make a teleport function with standard player speed by sliding back and forth very short distances while colliding with the teleport. It may be something in this section:

gzdoom/src/playsim/p_teleport.cpp

Lines 684 to 785 in 98b5d8b

	int flags = fog ? (TELF_DESTFOG | TELF_SOURCEFOG | TELF_KEEPORIENTATION) : TELF_KEEPORIENTATION;
	bool res =
	P_Teleport (victim, DVector3(dest->Pos().XY() + newp, z),
	nullAngle, flags);
	// P_Teleport only changes angle if fog is true
	victim->Angles.Yaw = (dest->Angles.Yaw + victim->Angles.Yaw - source->Angles.Yaw).Normalized360();
	return res;
	}
	//-----------------------------------------------------------------------------
	//
	// [RH] Teleport a group of actors centered around source_tid so
	// that they become centered around dest_tid instead.
	//
	//-----------------------------------------------------------------------------
	bool FLevelLocals::EV_TeleportGroup (int group_tid, AActor *victim, int source_tid, int dest_tid, bool moveSource, bool fog)
	{
	AActor *sourceOrigin, *destOrigin;
	{
	auto iterator = GetActorIterator(source_tid);
	sourceOrigin = iterator.Next ();
	}
	if (sourceOrigin == NULL)
	{ // If there is no source origin, behave like TeleportOther
	return EV_TeleportOther (group_tid, dest_tid, fog);
	}
	{
	auto iterator = GetActorIterator(NAME_TeleportDest, dest_tid);
	destOrigin = iterator.Next ();
	}
	if (destOrigin == NULL)
	{
	return false;
	}
	bool didSomething = false;
	bool floorz = !destOrigin->IsKindOf (PClass::FindClass("TeleportDest2"));
	// Use the passed victim if group_tid is 0
	if (group_tid == 0 && victim != NULL)
	{
	didSomething = DoGroupForOne (victim, sourceOrigin, destOrigin, floorz, fog);
	}
	else
	{
	auto iterator = GetActorIterator(group_tid);
	// For each actor with tid matching arg0, move it to the same
	// position relative to destOrigin as it is relative to sourceOrigin
	// before the teleport.
	while ( (victim = iterator.Next ()) )
	{
	didSomething |= DoGroupForOne (victim, sourceOrigin, destOrigin, floorz, fog);
	}
	}
	if (moveSource && didSomething)
	{
	didSomething |=
	P_Teleport (sourceOrigin, destOrigin->PosAtZ(floorz ? ONFLOORZ : destOrigin->Z()), nullAngle, TELF_KEEPORIENTATION);
	sourceOrigin->Angles.Yaw = destOrigin->Angles.Yaw;
	}
	return didSomething;
	}
	//-----------------------------------------------------------------------------
	//
	// [RH] Teleport a group of actors in a sector. Source_tid is used as a
	// reference point so that they end up in the same position relative to
	// dest_tid. Group_tid can be used to not teleport all actors in the sector.
	//
	//-----------------------------------------------------------------------------
	bool FLevelLocals::EV_TeleportSector (int tag, int source_tid, int dest_tid, bool fog, int group_tid)
	{
	AActor *sourceOrigin, *destOrigin;
	{
	auto iterator = GetActorIterator(source_tid);
	sourceOrigin = iterator.Next ();
	}
	if (sourceOrigin == NULL)
	{
	return false;
	}
	{
	auto iterator = GetActorIterator(NAME_TeleportDest, dest_tid);
	destOrigin = iterator.Next ();
	}
	if (destOrigin == NULL)
	{
	return false;
	}
	bool didSomething = false;
	bool floorz = !destOrigin->IsKindOf(NAME_TeleportDest2);
	int secnum;

..or I could be off track with my guess. Anyway, here is a diff of the two releases for this specific cpp file: https://www.diffchecker.com/PnPaqBex/

In short the second implementation uses a substitute for the Z coordinate, while the first extracts that coordinate from the player actor alongside X and Y. Is this the cause? I don't know. My approach with source code as a hobbyist has always been trial-and-error when it comes to unfamiliar codebase.

This is easily replicable by using GZ Doom with The Legend of Doom mod. The first cave, right in front of you, is a teleport. On Windows 11, g4.14.0 works fine. On Linux Arm64, g4.14.0 fails to teleport unless I perform the above steps and make subtle movements on top of the teleporter area.

[grobuzga]

I also have an issue with the teleports, but different kind - it doesn't allow me to leave the teleport tile.

For example, at DooM 1 E2M1 there's a teleport right in the beginning - it teleports me to the destination just fine, but when I try to leave it teleports me back to the first room, and vice versa.

I've found a workaround for the first teleport on the level - leaving the teleport tile sideways does the trick. But this workaround won't work on a second one - there's simply no place to sidestep - only go forward.

The device I'm using is Trimui Smart Pro, with custom linux OS and GZDoom 4.13.2 .

[nickbailuc]

I also have an issue with the teleports, but different kind - it doesn't allow me to leave the teleport tile.

For example, at DooM 1 E2M1 there's a teleport right in the beginning - it teleports me to the destination just fine, but when I try to leave it teleports me back to the first room, and vice versa.

I've found a workaround for the first teleport on the level - leaving the teleport tile sideways does the trick. But this workaround won't work on a second one - there's simply no place to sidestep - only go forward.

The device I'm using is Trimui Smart Pro, with custom linux OS and GZDoom 4.13.2 .

Hey, I've got the same result in E2M1, its the same issue! I'm guessing that device you listed is also ARM64?

[madame-rachelle]

I am currently unable to test on the ARM64 platform, but can you please compile from master (as of now) and test to see if that works?

Also - please swap compilers (Clang if using GCC or GCC if using Clang) to see if the problem goes away.

There was recently an issue with one of the VM functions being translated incorrectly to a native call when the JIT was disabled.

[JeodC]

At the rate wsl compiles this, I'll have an answer for you for GCC tomorrow. For the record I compile on bullseye with cmake -DNO_GTK=ON -DNO_FMOD=ON -DCMAKE_BUILD_TYPE=Release .., I assume the TrimUI comment above is similar if not the same, or they simply take the precompiled binary from the releases page.

Edit: Build is complete, unfortunately the problem persists. I may attempt a clang build later if nobody else gets to it first.

[grobuzga]

I also have an issue with the teleports, but different kind - it doesn't allow me to leave the teleport tile.
For example, at DooM 1 E2M1 there's a teleport right in the beginning - it teleports me to the destination just fine, but when I try to leave it teleports me back to the first room, and vice versa.
I've found a workaround for the first teleport on the level - leaving the teleport tile sideways does the trick. But this workaround won't work on a second one - there's simply no place to sidestep - only go forward.
The device I'm using is Trimui Smart Pro, with custom linux OS and GZDoom 4.13.2 .

Hey, I've got the same result in E2M1, its the same issue! I'm guessing that device you listed is also ARM64?

Yes, the device runs 64bit linux system.