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.
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?
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.
https://empyriononline.com/threads/teleporting-with-active-connection-to-cargo-coq-crash-6520.51701/ This is related. Since making profound awareness of above bug on Transcendence, the teleporter bug here decreased significantly.
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
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.
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...
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.
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.
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
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.