Manual Migration Portal Linking Not Working on Locally Hosted Dedicated Server After Server Shutdown

[nice rocks]

Summary: Whenever I first regenerate a 4 shard server that I am hosting locally on my device I can use some commands and the prompt window of each shard to manually link every portal. The portals will stay linked and work as intended for as long as the server stays running. After the server is shut down and then restarted at a later point, the portals will not follow the manual linking setup I gave them. Instead, they try to automatically connect to a previously loaded shard as each shard loads after the batch file that started the server is executed. As a result, some of the migration portals become blocked and cannot be manually relinked to any other portals using any linking commands. The server logs show World #() is now connected, Skipping portal [#] (different permanent world), listing each portal in a given shard that did not connect and cannot be further manually connected to any other portals.
 

I have been trying to host a dedicated server on my local device that has 4 shards consisting of 2 surface shards and two cave shards. After the world and its 4 shards have been regenerated using c_regenerateworld() I am able to use the following commands in each shard's prompt window to manually link each migration portal to another shard:

• for k,v in pairs(Ents) do if (v.prefab=="cave_entrance" or v.prefab=="cave_entrance_open" or v.prefab=="cave_exit") then v.components.worldmigrator:SetDestinationWorld("X", true) end end
  • This should loop through each portal type in the shard that the command was input into and connect it to the shard with designated shard ID X. This should also turn off automatic linking for each migration portal in the shard where the command is run.

• for k,v in pairs(Ents) do if v.prefab == "oceanwhirlbigportal" then v.components.worldmigrator:SetDestinationWorld("X", true) end end
  • This should connect the big whirl portal in the Surface Shard where the command was input to the big whirl portal exit in the Caves shard with designated shard ID X. This should also turn off automatic linking of the big whirl portal.

  • For the Caves shards I would switch out the "oceanwhirlbigportal" with "oceanwhirlbigportalexit" to connect the exit to the portal even though the big whirl portals should only work one way, surface to caves. I do not know if this needs to be done or not to ensure manual linking.

By entering these commands in each shard prompt and adjusting for the shard ID numbers I chose, each cave entrance should be manually linked to a cave exit, the big whirl portal in shard Surface 1 should connect to the sanctum exit in shard Caves 1, the big whirl portal in shard Surface 2 should connect to the sanctum exit in shard Caves 2, there should be no missing links between any of the migration portals, and there should be no automatic linking between migration portals.

Everything works as intended after these commands are first run in the newly regenerated shards, and throughout the duration that the server is running. During gameplay, the cave entrance rocks can be broken and will validate and connect to their corresponding cave exit. After this though, when the server is shut down and restarted at a later time, the migration portals do not follow the manual linking setup I gave them. A shard will fully load, show the portals are validated based on how I set them up and then will try to connect again automatically to another shard after the other shard has loaded. This results in a bunch of "Skipping portal[#] (different permanent world)" messages. The in-game result of this is that sink holes and cave exits become blocked and unusable. Also, they cannot be manually relinked using any commands.

Is there any way this can be fixed on existing worlds that have experienced this issue? Otherwise, is there at least a setup that could be done with newly generated worlds so that the portals manually link as intended each time the server is restarted after it is initially shut down? Below I'll share some images to help try to illustrate this issue I've been having.

This is what each shard looks like after the world is regenerated using c_regenerateworld()

This is an example of a simple portal validation setup that I have been testing. In this case:
•    Each of the 10 cave entrances in Surface 1 should connect to a cave exit in Caves 1
•    The big whirl portal in Surface 1 should connect to the big whirl portal exit in Caves 1
•    Each of the 10 cave entrances in Surface 2 should connect to a cave exit in Caves 2
•    The big whirl portal in Surface 2 should connect to the big whirl portal exit in Caves 

After the server has been shut down and is restarted the shards will load and try to reconnect to each other automatically. This overrides the manual linking, resulting in "Skipping portal[#] (different permanent world)" for each of the broken portals. Using the simple portal setup as an example makes it easier to keep track of what portal links stop working. Keeping track of them becomes more difficult though when the portal setups are more complex like linking some Surface 1 portals to Caves 1 and the rest to Caves 2 and so on.

The broken portals cannot be manually re-linked afterwards. The cluster.ini and server.ini settings for each shard were used:

cluster.ini

[GAMEPLAY]
game_mode = survival
max_players = 10
pvp = false
pause_when_empty = true

[NETWORK]
cluster_description = The portals better work on this world
cluster_name = cluster name
cluster_password = cluster pw

[MISC]
console_enabled = true

[SHARD]
shard_enabled = true
bind_ip = 127.0.0.1
master_ip = 127.0.0.1
master_port = 10889
cluster_key = key

server.ini -- Surface 1

[NETWORK]
server_port = 11000

[SHARD]
is_master = true
id = 1

[STEAM]
master_server_port = 27018
authentication_port = 8768

[ACCOUNT]
encode_user_path = true

server.ini -- Caves 1

[NETWORK]
server_port = 11001

[SHARD]
is_master = false
id = 2

[STEAM]
master_server_port = 27019
authentication_port = 8769

[ACCOUNT]
encode_user_path = true

server.ini -- Surface 2

[NETWORK]
server_port = 11002

[SHARD]
is_master = false
id = 3

[STEAM]
master_server_port = 27020
authentication_port = 8770

[ACCOUNT]
encode_user_path = true

--server.ini -- Caves 2

[NETWORK]
server_port = 11003

[SHARD]
is_master = false
id = 4

[STEAM]
master_server_port = 27021
authentication_port = 8771

[ACCOUNT]
encode_user_path = true

@JesseB_Klei I don't know if any of this cause by a bug but any help with resolving would be greatly appreciated!