Underwater Portal Migration Failure [TMS 222179]
Pheotis opened this issue ยท 9 comments
- When a player creates underwater personal stargates in Knarvik
0.9.3.7(fixed or networked)
And when the player tries to migrates them to ALPHA-1.0.0.4 on Paper 1.18.2; - When any player attempts to activate one of said underwater portals, nothing happens; no messages are printed to the player.
Note that all non-underwater portals function perfectly.
Environment
Plugin Version: ALPHA-1.0.0.4 (Migrating Knarvik 0.9.3.7, Test Environment unit 2-Paper-Offline-MigKnar-Modern-SQL)
Server Version: git-Paper-350 (MC: 1.18.2) Implementing API Version 1.18.2-R0.1-SNAPSHOT
Description.
Input
See here
Output
[16:03:11 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:29 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:29 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:32 INFO]: [Stargate] isOpenForUUID = null
[16:03:33 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:34 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:36 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:39 INFO]: [Stargate] isOpenForUUID = null
[16:03:41 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:43 INFO]: [Stargate] isOpenForUUID = null
[16:03:43 INFO]: [Stargate] Checking permissions for entity CraftPlayer{name=UserTest}
[16:03:43 INFO]: [Stargate] Checking access permissions
[16:03:43 INFO]: [Stargate] Checking permission 'sg.use.world.world'. returned true
[16:03:43 INFO]: [Stargate] Checking permission 'sg.use.network.custom.PreTest1'. returned true
[16:03:43 INFO]: [Stargate] Checking permission 'sg.use.design.watergate.gate'. returned true
[16:03:43 INFO]: [Stargate] Checking permission 'sg.use.type.networked'. returned true
[16:03:44 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
[16:03:46 INFO]: [Stargate] isOpenForUUID = null
[16:03:46 INFO]: [Stargate] Checking permissions for entity CraftPlayer{name=UserTest}
[16:03:46 INFO]: [Stargate] Checking access permissions
[16:03:46 INFO]: [Stargate] Checking permission 'sg.use.world.world'. returned true
[16:03:46 INFO]: [Stargate] Checking permission 'sg.use.network.custom.PreTest1'. returned true
[16:03:46 INFO]: [Stargate] Checking permission 'sg.use.design.watergate.gate'. returned true
[16:03:46 INFO]: [Stargate] Checking permission 'sg.use.type.networked'. returned true
[16:03:46 WARN]: [Stargate] This should never be triggered, an unknown glitch is occurring
In 1.19 on the same instance as before, this can be partially repro'd.
Imported A gates result in misplaced corals.
Once they are used as a destination (i.e. once a player teleports to them), they fix themselves.
Besides that, corals work as intended.
[TMS 222 178]
For imported A gates, there is no button location registered, as A gates cannot be activated by buttons. As such, it shouldn't try to place any buttons. I have no idea how that coral ended up in the entrance, but it doesn't seem to have anything to do with button generation.
I'm guessing it has to do something with iris generation/degeneration?
I think this bug is actually not a migration bug. I tested this myself on the latest build. The data in the database seems totally fine. I cannot find anything weird.
When I created another identical underwater gate, the new gate had the same bug. Living wall corals seem to be bugged, but dead wall corals work fine.
It seems there is something wrong with the handling of corals in general. Dead wall corals are not part of Tag.WALL_CORALS, and will always be overwritten to DEAD_TUBE_CORAL_WALL_FAN. This seems to fix whatever is wrong with the corals.
The main reason the click isn't working is found in PlayerEventListener line 95, where it is hardcoded to only work for DEAD_TUBE_CORAL_WALL_FAN, and not any other type of coral.
In 1.19 on the same instance as before, this can be partially repro'd. Imported A gates result in misplaced corals.
Once they are used as a destination (i.e. once a player teleports to them), they fix themselves.
Besides that, corals work as intended.
[TMS 222 178]Misplaced corrals? Isn't the entrance of the portal made out of blue corals? For me it seems like this is an issue with blockphysics not being blocked at startup for always on portals
Yes, that about describes it; block physics running on startup for A gates.
Sorry, "misplaced corals" was a poor description.
So one easy fix to this would just be to regenerate the portal entrance on startup
In 1.19 on the same instance as before, this can be partially repro'd. Imported A gates result in misplaced corals.
Once they are used as a destination (i.e. once a player teleports to them), they fix themselves.
Besides that, corals work as intended.
[TMS 222 178]
Misplaced corrals? Isn't the entrance of the portal made out of blue corals? For me it seems like this is an issue with blockphysics not being blocked at startup for always on portals