Portals Not Working in Hearth & Home Update

[rikere]

We're running a multiplayer server, the only server side mod is V+, we DID enable the "items can go through portals" option and nothing else.

AnyPortal appears to be broken. As near as we can tell, on reboot, the game erases portal names or otherwise forgets them. They are at the portal in the dialog box. If we go to the portal, open/close, the connections work again.

That's our initial experience anyway, happy to do further testing later (players are currently active so I can't do a lot without being disruptive aside from disabling the mod to restore standard portal operation).

We're on 0.202.19 for Valheim and 1.0.4 for Anyportal. 0.9.9 for V+.

I believe the server is a docker instance. All players are using Windows 10.

[sweetgiorni]

Thanks, I'll see if I can make some time to update this mod in the next few weeks.

[Keirsti]

Just to add another experience as my server seems to be running into the same issue - we are also running 0.202.19 for Valheim, 1.0.4 for AnyPortal, 0.9.9 for Valheim+, and a few other mods that I don't think should conflict.

On login, if I am the only player logged in, there appear to be no issues - portals remain connected, the full portal list populates, etc. I've tested this in a single-player game, on a dedicated server on another machine in my local network, and on our "production" server which is hosted by a third-party provider. The same seems to occur for other players on the server (several people mentioned 'testing' it yesterday morning after I updated our modpack to add AnyPortal and had no issues).

As soon as we seem to have two or more people online, behaviour is inconsistent. Some players will see the full list, while others will have the portal destinations clear as soon as they try to access them/see the hover text, and in most cases the dropdown menu will be completely depopulated (except for the 'No destination' entry added by your code). Opening and closing the portal and opening it again will sometimes partially populate the list. Other users who have the list (or at least have that portal in their list) can go to that portal and often when they set a destination (or re-apply the current destination) the portal will work for the affected user and the portal name will show up in the list. Additionally, if they or someone else walks 'near' a portal (or passes by a portal when taking another portal, given how the game handles teleports),

Generally speaking, once a portal starts showing up in the list for a player it remains there for the rest of the session, though I'm not certain this is the case (we had a one hour comedy of errors last night resulting in multiple corpse runs and at one point I believe two players who had the full portal list suddenly lost it).

When I turned the debug logs on, the below was the only error being thrown, though there's no real error logging for the other bits (e.g. populating the list), though I don't know if there would be any tell for you to even log an error on - does the game know there "should" be forty portals and it's only sending four when you call GetAllZDOsWithPrefab? ;)

In poking around the community, it seems some people are seeing this behaviour, and some people aren't, and I'm looking to see if I can figure out where our modlists differ just in case there is a conflict of some kind. Additionally, I haven't ruled out that it isn't a "user error" issue with some of the users on my server - especially after a conversation late last night where I discovered like half of them hadn't followed my instructions re: upgrading to the latest version of our mod list - so I intended to try and rope some people into actual testing (including checking for mod conflicts) and I'll follow-up once I get that done. ;)

For context, this is the mod list we're running:

This mod has been pretty critical for our servers - especially where we tend to have a large number of players and encourage 'spreading out' around the world so we don't tank everyone's performance with a giant hub housing district - so hoping to get this resolved either by identifying it as something on our end or isolating why the code is struggling w/ the new version. :)

[ersan]

We are also running MMHOOK with Jotunn and I believe that was when the issues started, didn’t get any reported issues before installing Jotunn.

[rikere]

My mod list client-side. Some of my players use the same ones, it's not universal.

I believe we have overlap only with Valheim Plus and Equipment Quick Slots. Map Teleport was added after the portal issue as a stopgap solution to getting around.

BepinEx just updated today, we should see if that has any involvement/if it fixed the issue (I doubt it, but hey, bugs everywhere).

I had an issue where the portal itself didn't even show to me, slow loading. The issue could possibly be a timeout fetching the names of all the other portals?

[Keirsti]

We've had intermittent issues with portals not rendering as well, rikere - someone mentioned it literally as I reloaded this page to see if there were any updates. Usually a log off/log on or moving far enough for it to de-render and render again fixed it for them.

I didn't try the new BepInEx version - not sure if you had a chance to install it. I also can't say if JVL/MMHOOK were a factor for our group, as we had it on the server already (for PlanBuild), but if I can drag people in a room to test I'll definitely see what's up. :)

[sweetgiorni]

Thanks for the details @Keirsti. You are correct about the portal synchronization between client and server; that is almost definitely where the issue is. I haven't looked at the code in a while, but IIRC the server will only send objects to the client that are in the immediate vicinity of the player. I thought I addressed that with this change, but the issue persists. I need to dive in to the server-client code and figure out what's going on.

It's a bit difficult for me to test multiplayer because I only have one account. At some point I tried loading two instances of the game at once and running a local server, but I think the client has a unique ID that prevents me from doing that. If looking through the code doesn't help I'll try this again. Worst case I'll just add a bunch of debug logs related to portal sync and hope someone sends a log with useful information.

[Keirsti]

For what it's worth, @sweetgiorni, I had zero issues with AnyPortal on three dedicated servers that I ran pre-H&H, including one I ran from March up until mid-August... so that fix probably did the trick for a few months, anyway. ;)

If you do need a guinea pig for testing, let me know. I've spent more than enough time trying to troubleshoot it on my own server with no idea what I'm doing that I wouldn't mind spending time to help someone who does know. ;)

[rikere]

I'd be happy to work as a guineapig as well. I have a few other players I can recruit as well. Distribute the patched client stuff to them and then we just need a server to test on (my own managed, I don't think I can get custom mod code added, but I can ask the support guys, they've been chill).

[sweetgiorni]

@Keirsti @rikere Wanna beta test for me? I was able to reproduce the issue and I think I fixed it. This should also fix the performance issues a few people reported.

AnyPortal.dll You should only have to install it on the server; there were no changes to the client-side logic.

Could you also see what happens when someone destroys a portal far away from you? The next time you open a portal drop-down, the deleted portal should be gone.

[Keirsti]

I've tossed it on a test server and asked my colleagues to test if they get a chance during the day; otherwise, I'll try and drag some in to test with me after my work day is done (~21:00 UTC).

[Keirsti]

@sweetgiorni So far so good - running a quick test at lunch with three other people (who were previously having issues).

We were able to see the full list, set/change without portals resetting or clearing, destroy/add portals and have them show up, and confirmed no issues through several log on/log off attempts and full client restarts.

We won't be tossing it into a larger test/production setup until the weekend at the earliest, so I can't test it with a 10-player count, but considering it was failing with 2-3 before this is a good omen. :)

[rikere]

My server host has been following the thread. They've apparently applied the DLL system wide on their servers. Me and my players will put it through its paces tonight.

[rikere]

I've had a chance to test and I'm still having issues. I am only able to see 1 portal, if that, in the menu. My other players are able to see more. I'm running on the lowest spec. machine of anyone in the group, a 4770 and GTX1060. I suspect if there IS a sync issue, my low specs are making it worse?

One of my players reports:

"Before, I was at least able to name it to a pairing portal and then that portal would exist in the list Well, maybe less broken in that the destination doesn't break right after you set it Log out, log in, the other portals are gone from the list again"

The portals are appearing to not be persistently set?

[Keirsti]

Just to confirm, rikere - did you only install the new version on the server, or server + clients?

We had taken the old version out of the client installs so I had given the version in the thread to the three other players with whom I was testing, and it seemed fine.

[rikere]

Only the server is updated. All clients are running the versions hosted at Thunderstore and Nexus.

[rikere]

Installed the DLL here clientside. No change. I currently show 0 portals.

If I make one nearby, it will show in the list.

There is a portal at my location and one at the elder, as an example. If I put one in the same camp/base as the main portal, they connect. However, I don't know that they stay connected.

I will double check with the server host that they've updated the DLL.

[sweetgiorni]

I've had a chance to test and I'm still having issues. I am only able to see 1 portal, if that, in the menu. My other players are able to see more. I'm running on the lowest spec. machine of anyone in the group, a 4770 and GTX1060. I suspect if there IS a sync issue, my low specs are making it worse?

One of my players reports:

"Before, I was at least able to name it to a pairing portal and then that portal would exist in the list Well, maybe less broken in that the destination doesn't break right after you set it Log out, log in, the other portals are gone from the list again"

The portals are appearing to not be persistently set?

Specs should not affect it. Can you confirm the server was restarted after the DLL was installed?

[rikere]

Server host confirms, latest DLL is applied on the server instance. Server has been restarted.

Tested on a slightly higher end machine, and yea, not performance related. I had to check, Valheim does chug on this system (I've seen it as low as 15FPS).

[puffncough]

I've had a chance to test this on two different servers, one that was up prior to H&H and a new server after the H&H update. I am self hosting on a Linux dedicated server.

Anyportal works fine on the old server, even with updating the mods I was using it was still working correctly for myself and others.

When testing the beta file onto the new H&H server the portals still do not save. The portal names need to be manually entered for the drop down to remember the location again.

I've reinstalled all addons after the latest beta file to ensure everything was up to date. Did multiple reboots to confirm new file was installed. Other addons being used are EpicLoot, AutoRepair, ExtendedItemData, ItemDrawers, and SpeedyPaths.

Happy to continue testing or help out in any way.

[Keirsti]

Out of curiosity, how many players are you both testing with? I'm going to poll folks to see if they want to try testing it on our live server (which has 10+) this weekend to see how things go, but we only had four people for the other test (I was running a Windows dedicated server in a Win Server 2019 box for that test).

[rikere]

So far, 4 players for mine. I believe our server is a docker instance, it's a paid service.

[Athrunen]

Hey, we've got this problem as well, is there any update on this?

[CappyKD]

I have this same issue. Running dedicated headless server on Valhost. Only have Valheim Plus and Any Portal enabled. Will there ever be a fix for this? Do you need a hand troubleshooting or testing a fix?

[sweetgiorni]

The lack of updates are due to a combination of me being busy with my irl job and not really wanting to work on this project. Debugging decompiled RPC code can be tedious, and I'm not inclined to spend my free time doing things I find tedious.

I was hoping the mod community would have created some debugging tools by now, but I haven't found much. I have some time at the end of the month; I'll try to find a debugging tool or create my own so this project becomes easier to work with.

[Athrunen]

I took some time looking at your code and was wondering why you choose to use the SyncList instead of a dedicated RPC for requesting a list of portals?

Because that seems to be where the problem ultimately lies, the server can see all the portals but something gets lost on the way to the client. Could it be that there was a change in the way SyncLists are handled? There seems to be some zone-distance based filtering going on:

IMAGE REDACTED - COPYRIGHTED CODE

FindSectorObjects(zone, ZoneSystem.instance.m_activeArea, ZoneSystem.instance.m_activeDistantArea, toSync, m_tempToSyncDistant); could be the culprit.

IMAGE REDACTED - COPYRIGHTED CODE

[sweetgiorni]

@Athrunen No reason in particular. I didn't think to add a new RPC since object sync is already present.

As far as the filtering: IIRC, the portal entities are added by using a post-execution hook for CreateSyncList and simply appending to the result list. I don't remember if this code made it into master or if it's still sitting on my local branch I used to create the test patch posted earlier in this thread.

[Athrunen]

This? https://github.com/sweetgiorni/AnyPortal/blob/c95077ed0e08ed5aeab84a7707629deb1d740123/AnyPortal.cs#L219-L229

Isn't that a prefix?

Your drive link is dead btw.

[sweetgiorni]

Ah, yeah it is a prefix. I think I did that way so the objects are sorted correctly in CreateSyncList(), as opposed to adding them after and sorting again. FindSectorObjects() doesn't seem to remove entries that are already present in sectorObjects, so the filtering there shouldn't matter right?

The call to ShouldSend() inside SendZDOs is looking a little suspicious to me. That may be worth investigating as a failure point.

[Athrunen]

What would be the purpose of the sorting? Because just changing Prefix to Postfix seems to improve things significantly for me.

If anyone wants to test it, this is my build.

[Sully-Boi]

What would be the purpose of the sorting? Because just changing Prefix to Postfix seems to improve things significantly for me.

If anyone wants to test it, this is my build.

I tried running it on my server, console got flooded with 10 "Server loaded #### Portals" messages per second. and was causing noticeable lag when interacting with objects.

[Athrunen]

What would be the purpose of the sorting? Because just changing Prefix to Postfix seems to improve things significantly for me. If anyone wants to test it, this is my build.

I tried running it on my server, console got flooded with 10 "Server loaded #### Portals" messages per second. and was causing noticeable lag when interacting with objects.

Whoops, try out this file.

[viperp12]

I will also be trying this dll in my dedicated server the next few days. I have about 6 players on average.

[tnf-a]

Whoops, try out this file.

Can confirm it works on dedicated server with 3 players. One had no portals in list anymore after login, after installing the mod all portals came back. No log issues or anything. Thank you very much!!