Assorted I Gate Problems [TMS 222 181]
Pheotis opened this issue ยท 10 comments
- Once created and/or destroyed,
For any interserver (I) portal:- The portal will not react and/or function unless another player is online on the destination server
- Once a player does join the destination server, an infinite portal ID loop occurs on console.
- For any portal ID or network caught in the portal ID loop, it will be impossible to create, access, and/or destroy said portal.
- The signs for portals stuck in such loops will not regenerate their text when broken.
- shift right clicking the signs does nothing.
What server was this on?
This was on both of the 1.19 test instances within set two of the test environment.
The instances were MySQL-connected, on windows, running behind a waterfall proxy.
This is no id loop. Read the console.
What happens is that when an inter-server portal is destroyed, it sends a PORTAL_REMOVE message. When the message is received, the same method is used to destroy the portal, which triggers a PORTAL_REMOVE message back to the other portal.
Casting the network to a local network when receiving the PORTAL_REMOVE message (StargateBungeePluginMessageListener line 163) might fix this.
It not functioning without another player is an expected bug if using SQLite. The only way to know if a portal is connected to anything is to wait for plugin messages to synchronize the inter-server network. If a player is missing from one of the servers, plugin messages cannot be sent, thus the portal assumes its destination does not exist.
This was on both of the 1.19 test instances within set two of the test environment. The instances were MySQL-connected, on windows, running behind a waterfall proxy.
I guess, while MySQL shares the database, making easier sharing of the inter-server network possible, the inter-server network is never fetched again from the database, making it too. reliant on Bungee messages.
It would technically be possible to continously fetch inter-server portals from a shared database and disable the plugin messaging (for portal sharing) when a shared database is used for all connected servers. Still wouldn't help for SQLite though.
It not functioning without another player is an expected bug if using SQLite. The only way to know if a portal is connected to anything is to wait for plugin messages to synchronize the inter-server network. If a player is missing from one of the servers, plugin messages cannot be sent, thus the portal assumes its destination does not exist.
Weirdly enough, this is not a problem as bungee coord stores all messages it could not send and sends them instantly to the server when it can (when a player joins). Servers being empty off players should not matter, as a portals functionality only matters when a player is online: Interserver networks should in theory work exactly as smooth as normal networks
Weirdly enough, this is not a problem as bungee coord stores all messages it could not send and sends them instantly to the server when it can (when a player joins). Servers being empty off players should not matter, as a portals functionality only matters when a player is online: Interserver networks should work exactly as smooth as normal networks
The problem here is that the inter-server portal has no destination until a player joins the target server, thus making it impossible to travel to the target server and let it fix itself.
If the player could go through the portal there would be no problem, unless the destination was actually invalid.
We could go the route of legacy bungee and assume the target exists, but that would partly ruin the point of the new system.
The problem here is that the inter-server portal has no destination until a player joins the target server, thus making it impossible to travel to the target server and let it fix itself.
Could you explain that in different words, I think I'm misinterpreting it. Like it's fetching the whole network including destination from a shared database on startup (also why this feature is not available for SQLite). The bungeecoord messages are only there to keep the list of portals dynamically updated
Could you explain that in different words, I think I'm misinterpreting it. Like it's fetching the destination from a shared database on startup (also why this feature is not available for SQLite). The bungeecoord messages are only there to keep the list of portals dynamically updated
I think I'm mistaken, as this thing confuses me.
I can think of edge cases for SQLite though, where we will get problems because of incomplete synchronization of inter-server portals, such as portals created on one server while the others are offline.
I think this needs to be re-tested with the fix to see if there is actually another problem. I'm not sure exactly which context caused the portal to be marked as invalid, so it could be a non-issue.