NeoForge Version

20.4.140

Twilight Forest Version

4.4.2156

Client Log

No response

Crash Report (if applicable)

No response

Steps to Reproduce

In the config file, have newPlayersSpawnInTF set to true, but set portalForNewPlayer to false.

What You Expected

Spawn in TF with your feet firmly planted on the ground.

What Happened Instead

Spawn in TF with your feet in the process of being firmly planted in the ground through gravitational forces.

Additional Details

I've been slapping some breakpoints around the place as well as teasing the configs. On accident, I tested the config with the portal being made alongside the player spawning in. This is where I find out that the logic works perfectly fine if portalForNewPlayer is true, but if it's set to false, the player will end up being spawned at least 64 blocks above surface. Simple observation: it's the Y coordinate for spawning in the overworld.

I put breakpoints around TFTeleporter.getPortalInfo and found this while destPos is initially incorrect, this coordinate does get corrected in TFTeleporter.makePortal, but only in the variables. While spot does get corrected in TFTeleporter.findPortalCoords, the problem is that the portal coords never get cached in TFTeleporter.cacheNewPortalCoords. The simple reason is that the cache is trying to look for portal blocks, but since we spawned in without the portal, the coords are never cached, leading to a cascade back up to the second call for TFTeleporter.placeInExistingPortal where the cache is empty, meaning blockpos returns null, meaning ITeleporter.super.getPortalInfo is returned, rather than the pos. As such, the coordinates to spawn in never get set properly and relies on the overworld's spawn point.

Please Read and Confirm The Following

• I have confirmed this bug can be replicated without the use of Optifine.
• I have confirmed the details provided in this report are concise as possible and does not contained vague information (ie. Versions are properly recorded, answers to questions are clear).
• I have confirmed this issue is unique and has not been reported already.