CastRestrictedSpell is already defined in common/spdat
MSVC Debug builds caught this as an ODR violation, though Release
builds still allowed it (maybe because the methods were identical)
* Add player login reply struct
* Use player login reply struct for failed logins
* Use base message struct for login requests
* Refactor server list reply serialization
Use BaseMessage and BaseReplyMessage structs for server list
and add flags for server type and status
* Use reply message struct for login handshake
Remove client version checks, the packets are the same for titanium and rof2
* Use base headers for join server requests
* Log correct server list ip
* Add compressed flag to base message header
Document encrypt type flag more
This makes the float and integer fields in the doors table not nullable.
The only column this should affect is the buffer column which wasn't
being loaded in the old doors loading query. The other columns weren't
validated but they should still be made not nullable to avoid issues.
This will fix a crash in potimeb which is the only zone that had NULL
values in the buffer column with the current peq database. This column
can be removed in a future followup since it isn't being used anyway.
The include order here was causing a compile error when building with
perl 5.12 due to a bad interaction with the older fmt submodule version
being used
Add hash overload to perl CreateExpedition api
This adds an api to perl similar to the Lua api that accepts a reference
to a hash table with expedition creation info
Usage example:
my $expedition_info = {
expedition => { name => "Perl expedition", min_players => 2, max_players => 6 },
instance => { zone => "crushbone", version => 0, duration => 3600 },
compass => { zone => "gfaydark", x => 238, y => 987, z => -24.90 },
safereturn => { zone => "gfaydark", x => 245.84, y => 987.93, z => -27.6, h => 484.0 },
zonein => { x => 479.44, y => -500.18, z => 5.75, h => 421.8 }
};
$client->CreateExpedition($expedition_info);
Syntax for passing directly from a hash:
my %expedition_info = (...);
$client->CreateExpedition(\%expedition_info);
Add CreateTaskDynamicZone api to perl
Usage example:
sub EVENT_TASKACCEPTED {
if ($task_id == 4795) {
my %dz_hash = (
"instance", { zone=>"thundercrest", version => 11 },
"compass", { zone=>"broodlands", x=>1241.88, y=>511.147, z=>23.4192 },
"safereturn", { zone=>"broodlands", x=>1242.0, y=>526.0, z=>27.0, h=>0.0 }
);
$client->CreateTaskDynamicZone($task_id, \%dz_hash)
}
}
Shared tasks start replay timers based on accept time but solo tasks
should start from completion time. Solo tasks on live that have a
non-unlimited duration may require further investigation
This fixes an edge case where a player could be made leader when added
to an expedition that only had a single member previously.
If a leader in a two-member expedition quit (forcing a leader change)
and the new leader went offline while throttled, a leader change flag
would be set until a non-leader was available. The first added member
would then be made the new leader.
This could also potentially occur on world startup due to the initial
throttle timer state but member statuses aren't processed there yet
This moves members from expeditions so other systems can use them
Replace expedition_members table with dynamic_zone_members
Move 'EnableInDynamicZoneStatus' rule to DynamicZone namespace
Modify #dz list to show dz members (not instance players) and type name
Move various queries to repository methods
This starts some changes that move storage of things from expeditions to
dynamic zone class so other systems can possibly use them. This will also
make it easier to move window packet creation methods to DynamicZone.
For now these will remain on the expeditions table in the database. This
can be re-evaluated once other components are moved and seeing how other
systems may want to handle their player requirements.
World now caches and tracks member statuses so it can send them to zones
that request them on startup. Prior to this the cle would be searched in
world for every zone startup caching request, now it's only searched once
when a new expedition is created.
Bulk loading statuses removed since it would only be needed on world
startup now and likely have no clients in the client list anyway.
This also lets world choose non-linkdead members on expedition leader
changes and better detect when a leader change needs to occur
* Rename dz member id field
The name of the struct is enough to make this implicit
* Rename dz member enum and struct
Rename ExpeditionMember to DynamicZoneMember
Rename ExpeditionMemberStatus to DynamicZoneMemberStatus
* Rename dz window packet structs
This makes it more clear the window may be used by any dynamic zone
system not just expeditions (live missions fill the window when
player doesn't have an active expedition).
* Rename dz window packet fields
Add common expedition base class
Use repository for zone and world expedition caching
World now stores members and leader as Member objects instead of ids
This improves readability of the caching methods and lets world cache
expedition dzs and members like zone. World also now caches expeditions
as unique_ptr which will be necessary for future dz callback lambdas
that capture 'this' so addresses don't change on cache vector resizes.
This creates an abstract class in common so zone and world can share
most of the implementation. World now has access to the same dz data and
api as zone.
Rename CharacterChange to AddRemoveCharacter for clarity
Rename GetRemainingDuration to GetDurationRemaining for consistency
Move dynamic zone queries to custom repository methods
Move early empty shutdown and process rate rules to DynamicZone scope
This decouples the expired status check from expeditions into an
internal dz method that can be called by its owning system
Use internal dz messages to process duration and location changes
Add world DynamicZone class (later this will inherit from a base)
Add FindDynamicZoneByID to get dz from zone and world system caches
Move ExpeditionLockoutTimer to common
This simplifies expedition request conflict checks and uses repository
for the queries instead of processing the query result directly.
This fixes unnecessary leader processing on mass dzquits
Also marks leader dirty for empty expeditions in case something goes
wrong (shouldn't be possible after 62e480fe)
* Rename dynamic zone source files
* Store description and leader name on dz
Removes the DynamicZoneInfo struct used for switch list window. This
data can be stored on DynamicZone and kept updated by its owning system
* Separate create compass packet method
Cleanup MarkSingleCompassLoc
The NPC pointer held by Spawn2 wasn't reset if the npc was depopped
without a respawn timer by #depop commands or depop(false) quest apis.
If the NPC was part of a spawn condition then the condition would try
to dereference that pointer (which gets deleted) on condition change.
Fixes regression from b08dc02a (PR #1051)
The normal door list sent on zone entry caused unopenable double doors
on clients if an api respawned them while the client was zoning. This
waits until the client finishes zoning and has received the initial
door list before sending any despawn/respawn packets.
Moves corpses to graveyard when an expired instance shuts down.
Zones without a graveyard move them to non-instance version instead.
Fixes player corpses being left inside instances that expire
before graveyards process or in instances without a graveyard
This is an experimental change which allows members to log in at the
safe return if they were offline when the expedition was deleted.
Prior to this they would log in at bind instead
Partially reverts commit 32c69d235d
Removed expedition members are no longer hard deleted from db
This removes the is_pending column from character lockouts table
Synchronizing character lockout timers with the expedition's when zoning
into the dynamic zone simplifies adding missing lockouts to new members.
This also matches live behavior that replaces any character lockout
timers from another expedition with ones from the current expedition
This should eliminate race conditions caused by zones trying to set
a leader when members in different zones quit at the same time
Zone still detects when leader goes offline to trigger a change
since it's easier than having world process expedition member status
updates and perform expedition lookups
It isn't necessary to send this packet to current members when a new
expedition member is added. The member list packet changes the current
player count on the window
This fixes unnecessary packets and compass updates being sent for
invited members and better matches live's packet update pattern
This also fixes duplicate updates being sent to the added member
Live only sends a MemberListName update for members added through a
swap (player count doesn't change). For members added through an
invite it sends expedition info and a full member list update
A full member list update is sent for both cases in this patch. This
is because MemberListName currently always adds members with status
"unknown". This is either due to unknown packet fields or a change
in future clients
This exposes dynamic zone ids for any future changes and will make it
easier to preserve historic dz and expedition data. This also cleans up
some dynamic zone creation for expedition requests
When purging instances the expedition table is no longer updated
since dynamic zone ids are not re-used like instance ids are
Update #dz list commands to show dz id
Add GetDynamicZoneID and get_expedition_by_dz_id quest apis
Add 60s to lockout times sent to clients. Lockout timers
are rounded down to the nearest minute when displayed
This replaces the lockout leeway rule with better behavior
All expedition members are notified not just those in dz
This will only work if the dz is running. It might make more sense to
move this to client or world processing so members are notified even if
the zone instance isn't running
This is a breaking api change
eq.get_expedition_by_instance_id(instance_id) is replaced with
eq.get_expedition_by_zone_instance(zone_id, instance_id)
This replaces the FindCachedExpeditionByInstanceID method of
obtaining expeditions via instance id with a new method that
requires the dz zone id as well
This more accurately matches live for the new behavior introduced
in the September 16, 2020 patch. All members of a raid/group are
still checked for conflicts and the truncation is only allowed if
there are none.
It might make sense to add a rule for this since ignoring members
that would exceed the expedition max from the start makes it more
convenient to create expeditions. Members that wouldn't be added
anyway don't really need their conflicts checked.
Add client GetDynamicZones method to provide a single method to get all
associated client dynamic zones
Refactor compass update and MovePCDynamicZone to use this method
instead of searching for client dzs separately
Add optional disable message arg to MovePCDynamicZone
Also supports reducing lockout duration
Add Expedition::AddLockoutDuration
Add Client::AddExpeditionLockoutDuration
Some expeditions require adding to existing lockout durations
during progression. These add the specified seconds to individual
member lockout timers instead of setting a static duration based on
internal expedition lockout like UpdateLockoutDuration.
Add Group and Raid method DoesAnyMemberHaveExpeditionLockout
This is required by some expeditions that perform a manual check for
custom dialogue (Ikkinz group expeditions)
This implements the new behavior from live's September 16, 2020
(test server's September 8, 2020) patch
Expeditions can be created even when the client's group or raid
exceeds the expedition's max player requirement. Members are added
until the max player count is reached and the rest are ignored.
Raid members are added ordered by their raid group number with
ungrouped members having the lowest priority
Rename expedition request method ValidateMembers to CanMembersJoin
Change some expedition messages to System color (live changes)
Increases default from 15 minutes to 25 minutes
This compensates for current default graveyard timer code. Otherwise
instances may shutdown before graveyards can process any corpses.
A better fix needs implemented later to deal with corpses inside
expired dynamic zone/instances. Zones without graveyards should move
corpses to the non-instance version and zones with graveyards should
somehow still be processed (maybe offloaded to world?)
This was loading the dz from database to get safe return data every time
a client's dz removal timer triggered
Add the Zone::GetDynamicZone() method so zones that are dz instances can
find the data from the cache of any dz systems
hg