If a message was longer than 50 characters with "00000" somewhere in the
message (such as messages with hex numbers) then the saylink injection
method was sending a blank message to the chat window.
This refactors the saylink injection method using a crude state machine
to build the output. It should function the same:
- Inner-most brackets generate saylinks when nested
- Saylinks are not generated in brackets that already have a saylink
- Existing saylinks are preserved
- Existing saylinks that contain text with brackets do not attempt to
generate saylinks
- Saylinks are not generated if brackets contains leading or trailing
spaces (e.g. [ spaces ])
If a member is offline (or possibly during a race while zoning?) when
the shared task is completed they will not receive the reward. On live
the character receives their reward (with an updated replay timer) if
they enter back into game while the shared task is still active. They
keep the original replay timer if the shared task is no longer active
and do not receive a reward.
This makes it so clients are issued rewards (and a task completed
event is dispatch) if the client's task state was out of sync with a
completed shared task. To prevent characters being rewarded more than
once in case of bad sync checks, a 'was_rewarded' field has been added
to the character_tasks table and updated when rewards are assigned.
This fixes a couple bugs so the character_activities table is correctly
updated with shared task states to better detect when out of sync:
- The character_activities table is now flagged to update after syncing
shared task states. This table was not being updated if a client was
offline or inaccessible for a shared task element update.
- The character_activities table is now updated when a task element is
completed. This was only being updated for activity increments and on
completing the entire task. SaveClientState is now called at the end
of ClientTaskState::IncrementDoneCount to cover all cases.
This also has a cosmetic change to show replay timers before rewards
like live, though this will not work for shared tasks until refactoring
world code
Shared task replay timers used to be based on the task start time
(reducing the final lockout timer by elapsed task time).
Live changed this in the 2022 April 20 patch:
"Replay timers will now apply their full duration upon completion of
their associated task/quest."
Solo tasks and quests already did this
This also fixes a small bug where request timers were being
deleted when replacing replay timers for shared tasks
EventItem was leaving the package table on the stack in successful
(non-encounter) calls and only popping the return. All events were
also leaking the full stack on lua_pcall errors. Lua mod callbacks
were popping error returns but leaking the table.
* Implement SetFace opcode
This implements the opcode that's used to update zone clients when a
client updates their face
* Use SetFace in #feature command
Add check for valid number
This adds the #feature eyes command which isn't in the illusion struct
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.