Talk:Overflow

How to REJOIN the queue?

I welcome the "leave queue" button. but then there also needs to be a way to rejoint the queue or "travel" to the real world where players can me met.

About that...

The overflow shard is always active this beta. I never have once been in my own server and been playing in overflow. And even then, its laggy at best as even the overflow gets filled with over 100+ people in a tight space (like the hospital after the tutorial for humans). Will there be a point where overflow even gets overflowed? They are going to have trouble come release as it just moves you to it automatically and doesn't ask if you want to go there like shown in the small image on this page. Yumiko ^,~ 14:53, 28 April 2012 (UTC)

We're not a forum. For actual questions regarding ArenaNet's intentions, please post here instead. - Infinite - talk 15:03, 28 April 2012 (UTC)

When you log in with an existing character you receive the message as seen in the image. When you create a new character, you are not asked if you want to wait, but instead placed in the overflow shard and informed when you can go to your server. AidanReed 15:28, 28 April 2012 (UTC)

Well that clarifies things... Infinite can be such a buzzkill sometimes jumping to chomp at the bit too quickly. But I guess that's why we love him. Yumiko ^,~ 15:32, 28 April 2012 (UTC)

← moved to User talk:Infinite#Questions on main space talk page

Some ramblings on overflow shards

I've recently begun thinking about overflow shards and their workings. I have some evidence that might clarify my doubts and to increase the amount of information on the page.

When you are sent to an overflow shard, we can consider the following

1-The Overflow shard is specific to that server, e.g. someone on Sea of Sorrows would be moved to Sea of Sorrows Overflow Shard 1.

2-The overflow shard is global (for a given region), e.g. players from every server can join any overflow shard. The order of entering Overflow Shard 1 or 2, 3, 4... is in a "first come, first serve" basis.

3-The overflow shard is specific to a set group of servers (for a given region), e.g. players from a specific pool of server can join specific overflow shards (Overflow Shard of Group A-1, for a group of 3 servers, for example, 1 being the first overflow shard for that group).

First what I'll do is post this screenshot:

This was in the end event of the first BWE. Zerax and Colin, both Anet staff, were kind enough to join our guild for a quick screenshot. You'll notice that we (Zerax and I) are in different servers, according to the guild roster. However, Zerax is right in front of me, in-game. Colin is there too, also from another server, although he wasn't representing our guild anymore. This eliminates option #1 completely, as we are all from different servers and we share the same overflow shard, assuming that, even though they are Anet staff, they don't have special powers that grants them choice of any overflow server, and they must be rooted to a home server. This is actually essential: if someone can provide another screenshot that is not of the staff, and it shows a similar case, we can rule out #1 completely.

That leaves 2 and 3, and they are pretty similar, the only difference being #2 is global, #3 is in groups of servers.

With my screenshot alone, I have no way of backing up only one of these two. I ask for further evidence so we can verify which one is true.

The following are my considerations and conclusions for #3:

3.1-A group of servers might share one overflow shard because of population issues - a group of 1 heavily populated server and 2 light to medium population, for example. This avoids the issue of people from 1 server being too diluted when in an overflow shard, thus shattering some sense of community within their home server. The problem with this method of selecting servers is that new overflow shards of the same group will suffer from population issues (overflow shard A-1 might be heavily populated, but once that one fills, there will be a low pop A-2). This can happen with every group of shards,

A-1 (full)

A-2 (light)

B-1 (full)

B-2 (full)

B-3 (light)

C-1 (light)

such as that you'll have a bunch of overflow shards with a low population, instead of, if every server uses the same overflow shard group (option #2), there will be at maximum, 1 shard like that.

3.2-A group of servers might share one overflow shard based on a zone-wide event. Say that, to start the Shadow Behemoth event in Godslost swamp, severs I, II and III need between 15 and 50 portals closed, so they get a shard that has between 15-50 portals closed. Servers IV, V and VI need between 0-15, servers VII, VIII, IX need between 60-120, and so on.

Based on that, they would all be placed in overflow shards that share similar statuses, as to ensure that the player is not "cheated" out of an event because say, he had to zone to town and back again. It also gives some (more on that below) protection against people that purposely enters an overflow shard to get more kills of the same boss in a row - they would kill the behemoth, port to town and back again and, because they know the regular server is full, they would be ported to an overflow shard that is about to kill one.

Although this system almost -ensures- that the person would get 1 more kill (the overflow shard is as close as possible to the regular server), it limits the "abuse" to 1 more kill, and that's it.

Problems with this consideration:

-As I said, it'll ensure that a smart player will get one more kill if he can work with the server.

-It locks players out of a chance of finishing an event - while the shard will be close in terms of completion of an event, it might already been completed (like in the case of the 0-15 portals closed shard), thus screwing a portion of the player base. This is not such a big issue, as we can assume that, because there's always less players in an overflow shard than in the regular server (or they are populated AFTER the regular server), they will always be behind in terms of completion of events, disregarding player skill.

-Unfortunately, this type of segregation would also suffer from population issues, as in case 3.1.

-It would take a madman to program something like this. Players in a heavily populated server might complete the requirements for a zone-wide event way slower than a less populated server, and the back-and-forth dance of zone-wide events requirements would need a dynamic overflow shard system that would change in terms of seconds to minutes, causing hangups to the whole system, or so I believe, not to mention more dilution than option #2. Not only that, but EVERY zone would have a requirement, and unless they have 1 overflow shard for every zone, it would be pretty much impossible to meet several servers' requirements at once.

For the last reason alone I would eliminate this, the 3.2 possibility. And for the 3.1 option, it also seems such a huge trade-off that I wouldn't consider it to be true.

What I think it happens is that perhaps all the servers share the same group of overflow shard(s) (#2). IF there's something to diminish the "dilution" of server populations, I would guess that there is an algorithm in place that tries to send people of your server to the same overflow shard, thus counterbalancing the "dilution", one of the issues with this choice. Of course, to back up such a claim it would be necessary conclusive proof.

I'm sorry if this got too big, but I wanted to include all of the considerations into it. What are your thoughts on this matter? Onoros 09:01, 21 May 2012 (UTC)

Responses

I'm going to condense this down into tl;dr form. Please let me know if I misunderstood.

• Overflow could work in one of three ways: shards are specific to (1) the home world; (2) the region (EU, US, ...); (3) a group of servers within a region (dynamically as needed or predetermined).
• Onoros' research rules out #1, but cannot rule out/in either #2 or #3.
• Onoros also suggests some good reasons for 2 & 3 being better than 1 (notably: less likely to be in low-populated shard).
• The OP also tries to highlight some of the possible criteria for deciding when to branch into a new shard: population, event continuity, smooth transition from shard to main world, etc.
• Finally, Onoros highlights some of the potential issues with various methods for branching.

– Tennessee Ernie Ford (TEF) 00:43, 22 May 2012 (UTC)

Let me add my experience, too:

• During peak hours, exiting a city (nearly) always meant ending up in an overflow shard.
• Being in the same party, same guild, or nearby someone else had no effect on whether we ended up together; most of the time, we ended up on our own.
• Jumping to an external waypoint (as opposed to using the portal) fared no better; we still ended up on our own (however, only started doing this towards the end, so fewer data points).
• At an external waypoint, logging off/logging on always resulted in everyone ending up together and on the home server (not a shard). (Fewer data points for this, too.)

This leads me to believe that people are moved dynamically (and therefore seemingly randomly) to shards and that proximity matters (how many people nearby, not just in the zone). – Tennessee Ernie Ford (TEF) 01:01, 22 May 2012 (UTC)

Me and my friend once entered Queensdale at almost same time but ended up at different instances without getting overflow pop-up note. I blame the beta, thou. Mediggo 06:43, 22 May 2012 (UTC)

Why is overflow outdated?

I think there is a misunderstanding regarding overflows. They still exist, what has changed is how they are handled. The Megaserver system will throw closer players preferrably into the same overflow, but people still can change back and forth between overflows ("Join friend in [Zone name]" context option). You can check what overflow you are in by typing /ip. The term should be reinforced as "still alive", because it still works as GW2's version of a queuing system, the difference is how overflows are handled. I don't know why the community now refers to overflows as "megaservers", that's just the incorrect name for each map copy (which is, btw, an ugly name aswell). – Valento ^msg 18:02, 18 February 2015 (UTC)

The megaserver system subsumed and replaced overflows. Since the concept of a main or primary instance has been eliminated, the concept of an overflow no longer makes sense. All instances are equal. —Dr Ishmael 18:24, 18 February 2015 (UTC)

"the concept of a main or primary instance has been eliminated" - ah. Yes, in that sense yeah. I just got a bit confused because of wording, it just doesn't make sense to call instances (better name) a "megaserver", since the latter is the technology name. – Valento ^msg 18:50, 18 February 2015 (UTC)