5E Character Create Playlist
Page 36 of 53 First ... 26343536373846 ... Last
  1. #351
    I think the reminder was to have you and them immediately pull the logs on both GM and player client when the issue occurs. Sifting through large logs is not very efficient; and having logs that end right about the time that an issue occurs helps tremendously.

    The network library we use attempts to use UPnP for the cloud connections. I wasn't aware that it would try UPnP for the LAN mode; but it's not really important either way since it's not able to automatically configure on your network.

    Regards,
    JPG

  2. #352
    Which ports does UPnP try to open then? I could either allow UPnP or open said ports manually. What's the difference between allowing UPnP and disallowing it from FGU's perspective?

  3. #353
    For the FGU LAN mode, I have no idea. It's a function of the network library that we have that we don't actively use.

    From my understanding of the way UPnP works from FGC, the UPnP port forwarding would make calls over the network using the UPnP protocol to attempt to auto-configure the router for that network segment to forward a given port to the machine. If router did not support or UPnP disabled, then it would just fail. It's not an error to fail; just an indication that the router for that network segment did not allow or does not support auto-configuration. For FGC, we attempt to use UPnP to open port 1802.

    Regards,
    JPG

  4. #354
    Something about these log files has been bugging me, so I went back and looked at them again... I'm only airing my thoughts here, not offering any support or advice to the OP.


    If it was a UPnP issue, the host wouldn't have any connections at all. If the port is open, it's open. I don't know why there is a UPnP error, or even why FG tried to utilize it. Best guess? It just tried because it was programmed to try. A self-check, so to speak. I do not believe UPnP has ANYTHING to do with this specific problem. In fact, it's at the initial network setup/connection phase, and not in the middle of the session AFTER players have already connected. It shouldn't be, wouldn't need to be, and should never be necessary once the connection is either successful or ultimately all attempts fail.


    There appears to have been a duplicate connection to the cloud server at one point. This is probably due to a dropped or late packet during the connection process, that was re-sent or accepted out-of-order, and caused 2 connections at the same time. FG then destroyed the duplicate connection. The error message in German confirms this. It simply states that the WinSock connection was forcefully closed/terminated (literally, cancelled). So, that error is true, in the sense that the purposely-dropped connection failed and caused FG to disconnect from the cloud server -- as designed. Is this system on WiFi or a low-bandwidth wired connection and/or in a network with lots of devices active? SOOOO many things can go wrong here on the host network.


    Moon Wizard, correct me if I'm wrong on this one, but if I'm reading these correctly, the player is connecting before the host has finished loading. It has been my experience that this can cause system stability and performance issues and lead to crashes. The DM should be fully loaded before players connect in order to avoid this, correct?


    (The *-prev.log files' time stamps do not match, so are otherwise useless for analysis.)

  5. #355
    LordEntrails's Avatar
    Join Date
    May 2015
    Location
    -7 UTC
    Posts
    17,151
    Blog Entries
    9
    Quote Originally Posted by Lou Ciphor View Post
    Moon Wizard, correct me if I'm wrong on this one, but if I'm reading these correctly, the player is connecting before the host has finished loading. It has been my experience that this can cause system stability and performance issues and lead to crashes. The DM should be fully loaded before players connect in order to avoid this, correct?
    I experienced this during beta. i.e. where players who tried to join before my desktop was fully loaded would never be able to fully connect. I thought this was fixed, but maybe only partially?

    Problems? See; How to Report Issues, Bugs & Problems
    On Licensing & Distributing Community Content
    Community Contributions: Gemstones, 5E Quick Ref Decal, Adventure Module Creation, Dungeon Trinkets, Balance Disturbed, Dungeon Room Descriptions
    Note, I am not a SmiteWorks employee or representative, I'm just a user like you.

  6. #356
    I'd have to run some new tests to see if something has cropped up in the startup process. However, in general, the players should not attempt a connection until the GM is fully loaded to limit any potential issues.

    Regards,
    JPG

  7. #357
    It's not a UPnP issue, I setup NAT ports in my router manually anyway. I was just pointing out the fact that UPnP was tried and asked what was going on there.

    If FGU cannot handle players connecting until a certain point in time (fully loaded) then FGU should reject any connection until it is ready, everything else should be considered a bug.

    The disconnects happened well into the game, first after 2 hours, second after 3.5 hours.

  8. #358
    So we (me and the level-2 tech) from my ISP have came across something that might have fixed my issues. I have not had a chance to test it out yet as all the players that were having issues have not had any free time to do some testing. Unfortunately the new player we picked up who was also having issues must have became frustrated as he left our discord server and even blocked me, so not even he is around now to test and see if this fixed the issue.

    One of the things we found that at least let me start seeing open ports was disabling the two VM Ware network adapters. Disabling these two adapters also let FGU grab the correct internal and external IPs, and I was able to see the 1802 port was open when I hosted a game on FGC. (Last Sunday we tried using FGC to see if it was not just a unity problem, but nobody was able to connect to my FGC game.)
    See FG network issue with VmWare for further details on what we suspect might be the issue.

    I am not sure as to what or why this became an issue around January as I have not done any updates on VM Ware and probably last used/started it in early 2020. It even further boggles my mind as to why this would caused issues with just some players and not all players.
    Again further testing needs to be done to confirm that this indeed fixed the issues.

  9. #359
    Unfortunately I only just today uninstalled VMWare, because I had the very same adapters installed. I mean to remember that I manually disabled them via Device-Manager, though. Cannot check anymore, because they are gone for good now.

  10. #360
    We got to do some testing today after disabling those VMWare virtual adapters...

    FGU is still not working. As it has been thus far, the existing players can connect but only one of them can get new assets, the others cannot.
    Again it looks like the requests for these files are being made, and the files are being sent but are never received on the clients end.

    With FGC the players can now connect to the game I am hosing, and they can receive new images/assets.


    With further investigation one of my players was showing that they were connecting to 104.248.118.207, which belongs to “DigitalOcean”, is it FGU’s cloud stuff? (For reference my IP is still 100.42.84.13)
    I have posted a screenshot of what my player's was seeing while connecting, and she said she never sees that "Attempting to resolve connection to server..." message when connecting to other people hosting.
    Attached Images Attached Images

Thread Information

Users Browsing this Thread

There are currently 1 users browsing this thread. (0 members and 1 guests)

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  
5E Product Walkthrough Playlist

Log in

Log in