[Zone] Implement zone player count sharding

[Akkadius]

Description

This is a change that was sparked due to issues observed during THJ's launch. Once Bazaar reached 300 players, the network traffic became too much for anyone to have a good experience in the zone and network re/sends start to fall behind.

While I'd like a single zone to support 1k+ clients from a performance perspective, this is an easy, simple level that any server operator can lean into for general use cases.

It works by configuring the addition of a new zone table field shard_at_player_count (Default: 0), if this value is non-zero it will shard a zone by the configured player count number. Once a zone has been filled to count capacity, a new instance (100 year expiry) will be dynamically created and players will be routed to that one until it is filled. Once that one is filled a new one is created and the process repeats.

Menu

• Shard menu is displayed when entering a sharded zone (unless Zone:ZoneShardQuestMenuOnly is enabled)
• Shard menu is displayed when invoking #zoneshard in a sharded zone (unless Zone:ZoneShardQuestMenuOnly is enabled)
• Shard menu can be displayed via quest via $client->ShowZoneShardMenu();

Logic

• If a player is not in a sharded zone, the shard menu shows nothing
• If a player is not in a sharded zone, shard menu saylinks do nothing
• If a player zones to a sharded zone, sharding logic will ensure player is routed to the first zone under the shard player count
• If a player explicitly zones to a sharded zone instance that is over the sharded player count, it will still allow them and routing logic will not attempt to find a different zone. Players may want to visit each other in even full shards and can do so freely.

This can eventually be rigged up to the /pick menu

Quest API Changes

• Added Perl $client->ShowZoneShardMenu();
• Added Lua client:ShowZoneShardMenu();

New Rule

RULE_BOOL(Zone, ZoneShardQuestMenuOnly, false, "Set to true if you only want quests to show the zone shard menu")

Other Changes

• Fixed an issue with CheckInstanceExpired having an overflow when start time and duration are added together
• Fixed an issue where DeleteInstance wasn't actually deleting the instance entry (leaving this commented for now because maybe there was a reason this was this way that isn't clear and I don't want to cause other bugs)

Type of change

• New feature (non-breaking change which adds functionality)

Testing

• Tested database migration locally

Script invocation works

function event_say(e)
	e.self:ShowZoneShardMenu();
end

Checklist

• I have tested my changes
• I have performed a self-review of my code. Ensuring variables, functions and methods are named in a human-readable way, comments are added only where naming of variables, functions and methods can't give enough context.
• I own the changes of my code and take responsibility for the potential issues that occur
• If my changes make database schema changes, I have tested the changes on a local database (attach image). Updated version.h CURRENT_BINARY_DATABASE_VERSION to the new version. (Delete this if not applicable)

[Valorith]

Awesome feature :D

[Kinglykrab]

Seems like this could be used to supplement /pick support since you’d have shards of the zone to use to populate the window as well as the player count.

[fryguy503]

I believe I mentioned /pick support to Neckkola to look into as well and provided Xackerys issue with opcodes and breakdown - #1615

[Akkadius]

Seems like this could be used to supplement /pick support since you’d have shards of the zone to use to populate the window as well as the player count.

I mentioned this in the body of the PR

[catapultam-habeo]

	.content_schema_update = true

This is a content update

[Akkadius]

Good eye, updated

[catapultam-habeo]

On initial deployment of this PR, zone with shard_at_player_count = 200 displays 3 available shards to the 1 player logged in. One of those shards can be accessed, the other gives error about zone ID being expired.

[Akkadius]

On initial deployment of this PR, zone with shard_at_player_count = 200 displays 3 available shards to the 1 player logged in. One of those shards can be accessed, the other gives error about zone ID being expired.

Adjusted queries to filter more here

[catapultam-habeo]

Would a rule or column to specify the shard zone version be appropriate?

[Akkadius]

Would a rule or column to specify the shard zone version be appropriate?

It should go off of the zone row context, which has version

[catapultam-habeo]

I would like to request the following enhancements;

• A script hook (either explicit or behavior of an existing one) to zone a client back into their current zone which re-evaluates shard routing
• clients should use shard routing when logging in, rather than logging back into their last shard. (Maybe use 30 minutes offline to gate this)

[Akkadius]

I would like to request the following enhancements;

• A script hook (either explicit or behavior of an existing one) to zone a client back into their current zone which re-evaluates shard routing
• clients should use shard routing when logging in, rather than logging back into their last shard. (Maybe use 30 minutes offline to gate this)

1. I think a script hook is doable, although I don't think it's really been needed so curious a little more behind the ask there.
2. I thought about this scenario when writing this, at first it feels like a good idea but imagine you are grouping with friends in a sharded zone, your power goes out, you log back in and then you get routed to a different shard because technically the one you were supposed to re-enter went over the shard player count - this will only be annoying to players. Players should also be able to bind in a shard safely and not worry about magically being re-routed to another one and being confused by that behavior.

Happy to chat about these more as well.

[catapultam-habeo]

I would like to request the following enhancements;

• A script hook (either explicit or behavior of an existing one) to zone a client back into their current zone which re-evaluates shard routing
• clients should use shard routing when logging in, rather than logging back into their last shard. (Maybe use 30 minutes offline to gate this)

1. I think a script hook is doable, although I don't think it's really been needed so curious a little more behind the ask there.
2. I thought about this scenario when writing this, at first it feels like a good idea but imagine you are grouping with friends in a sharded zone, your power goes out, you log back in and then you get routed to a different shard because technically the one you were supposed to re-enter went over the shard player count - this will only be annoying to players. Players should also be able to bind in a shard safely and not worry about magically being re-routed to another one and being confused by that behavior.

Happy to chat about these more as well.

The use-case of 1 is to be able to use something like an idle script in non-combat zones such as The Bazaar, PoK, or Guild Lobby to reallocate to attempt to close unneeded shards.

[xackery]

Just noting that RoF2 does not have a native /pick or /pickzone command, it was officially added later.

There are UI elements native on RoF2, and the ability via a client hook to make /pick send a custom packet (via eq-core or whatever), then server replies with the pickzone menu, and then client has ability to communicate it's response, that was covered in my issue.

But yeah, it may be tough to formally support this, maybe consider #zoneshard creating the UI menu on player later as a post feature just for RoF2, and retain fallback to the chat version for anything older than RoF2 that does not have the pick UI

[catapultam-habeo]

I would like to request the following enhancements;

• A script hook (either explicit or behavior of an existing one) to zone a client back into their current zone which re-evaluates shard routing
• clients should use shard routing when logging in, rather than logging back into their last shard. (Maybe use 30 minutes offline to gate this)

1. I think a script hook is doable, although I don't think it's really been needed so curious a little more behind the ask there.
2. I thought about this scenario when writing this, at first it feels like a good idea but imagine you are grouping with friends in a sharded zone, your power goes out, you log back in and then you get routed to a different shard because technically the one you were supposed to re-enter went over the shard player count - this will only be annoying to players. Players should also be able to bind in a shard safely and not worry about magically being re-routed to another one and being confused by that behavior.

Happy to chat about these more as well.

I want to politely reiterate this request after using the shard system for about a week now.

The option to reallocate\collapse\compact shards is going to be a long-term requirement especially for sharded hub zones.

I think the script hook to manually re-evaluate a player (to move them up\down in shard stack as required) would be useful, but having some threshold where players no longer return to their original shard after being logged off is going to be critical. Maybe it could even be on server shutdown?

How this is currently playing out is that once a Bazaar shard on THJ is opened, it will effectively never close, due to traders who hold the upper shards open, if no other way then logging back into them after server downs.

[ConfidentlyInept]

Make it so you can #zoneshard 2 to enter zoneshard 2
Even better add an alias to #zoneshard named #zs

[fryguy503]

server admins can add aliases via the command table

[MortimerGreenwald]

Question.. if a shard exists (is dynamically created) how does #fz (find zone) work? Will it display the shard as well? Ty

[Akkadius]

Question.. if a shard exists (is dynamically created) how does #fz (find zone) work? Will it display the shard as well? Ty

No it is largely something you navigate once you zone into the base zone

[Akkadius]

Remaining items

• Rig up the UI menu mentioned here - ZoneSelect support (aka /pick) #1615