Fixed Teleporting to an orbit playfield has a chance to place you in a bad location

Discussion in 'Fixed (Read Only)' started by Fenra369, Jun 25, 2019.

  1. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    Mode: Survival
    Mode: Dedicated Server

    If applicable:
    MODIFIED PLAYFIELDS: Yes

    Reproducibility: Unable
    Severity: Minor

    Type: Teleport

    Summary: Teleporting to an orbit playfield has a chance to place you in a bad location

    Description: When you take a teleport to an orbit playfield, there is a chance (maybe 1 in 100) that you get placed nowhere near the teleporter you are being sent to. In every case this occurs, you get placed at the location (5000, 0-1, 0-1). The playfield server then moves you to the edge of the planet. This is very problematic for certain server setups that are dependent on teleporters as a means of travel.

    Steps to Reproduce: Create a SC 10 POI with a teleporter, and on a planetary teleporter targeting the POI, use repeatedly. Seems having a ping above 200 causes it more often, but has happened with a ping of 30 or so.

    Workaround: Bandages and motorbikes is helpful enough to handle an unexpected descent. Also having a pocket SV ready to spawn is also useful. 20190619230805_1.jpg
     
    #1
  2. Hummel-o-War

    Hummel-o-War Administrator
    Staff Member Community Manager

    • Developer
    Joined:
    Jun 15, 2015
    Messages:
    9,994
    Likes Received:
    14,836
    This seems to be a server-client sync issue i am afraid. Does this happen frequently or only after "heavy use" by teleporting back and forth a lot?

    Question 2: Does it happen when teleporting BETWEEN two playfields or also when teleportin IN a playfield?
     
    #2
  3. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    1. The amount of use of a teleporter does not seem to have an impact on the probability of this issue. I've had it happen while only using it incidentally, but cannot triggering spam-teleports or with many people on. It is really random.

    2. This issue only happens between playfields, especially orbit playfields.

    Some other info: Lag does not seem to matter either, it occurs with people on 30 ms just as much as someone at 200+ms.
     
    #3
  4. Javarox87

    Javarox87 Commander

    Joined:
    Oct 19, 2016
    Messages:
    225
    Likes Received:
    214
    #4
  5. Keith Hovey

    Keith Hovey Captain

    Joined:
    May 11, 2016
    Messages:
    450
    Likes Received:
    330
    Mode: Survival
    Mode: MP

    SERVER NAME: Unknown Skies
    SEED-ID: N/A

    If applicable:
    MODIFIED PLAYFIELDS: Yes

    Reproducibility: Sometimes for Specific Playfields in Specific Situations
    Severity: Minor

    Type: Teleport, Portals

    Summary Teleporter Randomly dumps people into space:

    Description: Once in awhile teleporters "Miss" Their targets. As you can see in the video. It seems that orbits are a lot more likely to have this happen, and CPU usage / Number of entities is a factor. Empty orbits I could not re-produce this in!! In the included Gamesave I was able to reproduce this in the playfield "PvP Pirate Hub 506".

    Steps to Reproduce: Teleport to any station in admin mode. Use a teleporter to PvP Pirate Hub 506 repeatedly from any station. Within 1 to 5 attempts to warp back and forth from 506 to another station and back you will be stranded in space. I was NOT able to reproduce this in the other playfields but I did see this happen frequently at the beginning of the season when CPU usage was above 70% on the dedicated randomly at all space stations. It was especially bad on a playfield that had not been loaded yet but was teleported to. Portals had a 50% failure rate on a fresh server where admins did not teleport from planet to planet and all stations to "Pre-generate them. I could not reproduce this result in the fresh server. So im assuming that MAY have been fixed at some point recently or may have been from the result of being over loaded for the first 2 weeks of operation.

    Video is @ https://urlzs.com/u4Vst and is around 20 minutes total. Had to shorten link because forum reformats and wipes out the twitch link to the video failing to show a proper link automatically. Sorry about this.

    Game save - https://drive.google.com/open?id=0B0Zv6-e2OQQYeGVkNmpkbzc0YVU
     
    #5
  6. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    Figured I'll update with my findings from ZeroG:

    We concur it's definitely happening for orbit playfields. We see this for both asteroid belts and planet orbits both, however we don't get near the % of occurrences that Keith has. For us it's roughly 10-20% chance of happening, and often in waves. I do not have any monitoring on CPU usage so I cannot determine whether CPU has a factor. Teleporters seem to "mostly work" regardless of ping/number of users on however. They happen with one person on, or 6. Our server is very low pop, so if the CPU theory makes sense then our low occurrence supports that.
     
    #6
  7. Keith Hovey

    Keith Hovey Captain

    Joined:
    May 11, 2016
    Messages:
    450
    Likes Received:
    330
    Our failure rate was only high under a high load. It literally ran people off our server hahahahaha. Lots of people got stuck in space. To be fair this is the first time we bothered using portals since 7.0 because we always have a small percentage of failed teleports. I thought this was a well known problem as a lot of server owners told me they dont rely on portals much for the same reason. Players know it too as far as I knew.

    Two portals In the same playfield never fail at all for us. Its only when the targeting structure on the playfield is unloaded entirely that there is a small chance (Seems entity count based) or when a lot of players teleport at once (Doesnt have to be same portal even) or when cpu usage is high.

    For example our PvP Pirate Hub has a lot of ore in the orbit and other NPC structures. Its failure rate is about 1 in 5 jumps TO it fail. All portals were checked in the above video and all portals were shown to work at some point. My theory is DSL fails to load fast enough and player pops into random space instead (Like you targeted playfield correctly for the portal but you mispelled the building name). Disable DSL and they no longer fail at all. Thats why its my running theory. Empty playfields support it. So if you look in the save above you'll find all the other stations have empty orbits. I cannot create that error at all in those orbits if im the only player on. I did an experiment where i swapped the yaml from Pirate hub into two of the other station playfields and all 3 then had the same failure rate. Reduce the ore in the playfield (And the structures around the target station) and the problem lessens as you do. This only works however until cpu load is high.

    To explain my theory better... I think portals work something like this --->Player enters--->player teleports--->Server loads remote playfield--->Player is placed on structure after playfield load. I think this fails sometimes because the game doesnt check to see if the structure actually loaded for the player. Instead it assumes it either has or that the structure is invalid. So if playfield loads and structure loads BEFORE player finishes teleporting they end up in the correct location. If the playfield loads and the structure does NOT before the player arrives the game assumes target is invalid and teleports the player to 0,60,0 on the target playfield. This would explain the high load scenario as well as entities being the problem as both would slow down DSL.

    This has only been an issue since DSL was introduced. Before that sometimes the other side never loaded hahahahaha. You would just be stuck in loading endlessly. Portals have had many issues... I am re-designing my map to avoid their use again as we speak as it decimated our server this season...
     
    #7
    Last edited: Jul 26, 2019
  8. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    https://empyriononline.com/threads/...lace-you-in-a-bad-location.51702/#post-330014

    Same issue, same symptoms, same theory. It's occurring even with pings as low as 24ms on smaller servers.

    I would suggest the following fix:
    The ABSOLUTE removal of DSL for any ENTITY with a teleporter attached. I can tell there was an attempt to wait for the server stuff to load in before placing us in the area, but this still has a chance to fail even under optimal conditions. At this point DSL is a liability for teleporters which isn't really worth working around. I'd rather lag a lot than end up in a spot where I'm guaranteed to die.
     
    #8
  9. Tarc Novar

    Tarc Novar Commander

    Joined:
    Nov 14, 2017
    Messages:
    108
    Likes Received:
    62
    I run a private, dedicated server. I have never liked DSL, so I always disable it. This might not be an option, though, if you play on someone else's server.
     
    #9
  10. Taelyn™

    Taelyn™ Administrator
    Staff Member

    • Developer
    • Administrator
    Joined:
    May 29, 2016
    Messages:
    3,247
    Likes Received:
    3,353
    Dont know who moved that report but it hasnt been handled yet. We need a 100% reproduction case what we havent found yet

    DSL cant be removed from certain structers we needed due to the planet size and RAM Usage. Specialy for ppl who play with just 8GB.

    Ill merge this post with the other and reopen it
     
    #10
  11. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    I can give you an orbit POI that seems to induce this with some regularity. It's very common when traveling *to* an orbit playfield.
     
    #11
  12. Fenra369

    Fenra369 Commander

    Joined:
    Apr 5, 2016
    Messages:
    223
    Likes Received:
    111
    You can remove this bug report, it appears to be solved for 10.5
     
    #12

Share This Page