Functionally nothing should change in this patch. This refactors a lot
of formatting and code duplication in requests and member removals.
The long SharedTaskMessage namespace and its constants were contributing
to a lot of formatting that was difficult to read. These were shortened
since they're not all shared task specific anyway (though they should
probably just be moved to string_ids.h with other eqstrs now)
Shared task requests were refactored a little to remove an unnecessary
function that filled potential members. The separate functions used for
/taskquit and /taskremove were also combined into a single function to
remove a member while preserving live message differences.
* Add shared task element locking
This adds the `lock_activity_id` field to the tasks table which will
automatically lock a shared task when that element becomes active.
A method was added to world analogous to zone's UnlockActivities to
determine when an activity is active with respect to task steps.
Also adds quest apis to manually lock or unlock a client's shared task
* Add comment
* [Feature] GM State Change Persistance
- Flymode and Invulnerable will now persist over zoning.
- Appended GMSpeed, Flymode and Invulnerable to the hideme message GMs see when they first login.
- Added #godmode [on/off] command to turn on or off hideme, flymode, gmspeed and invulnerable all in one shot.
- /becomenpc will now disable tells to the target player. It will also automatically disable GM States that interfere with its functionality.
- GM Command /toggle will not properly turn tells on/off
- GMs will now be notified if they are ignoring tells when they first zone-in, provided their GM flag is up.
- Added TellsOff variable to the output to #showstats
* [Bug] Fix tells when gmhideme is turned off.
* [Cleanup] Cleanup function and rename for consistancy.
Remove un-needed this->
* Tweaks
* Tweaks
* Update db_update_manifest.txt
* Move string building logic to a vector and use strings join
* Update client_packet.cpp
* Update 2022_07_28_gm_state_changes.sql
* PR comment tweaks
Co-authored-by: Akkadius <akkadius1@gmail.com>
This was implemented in a very odd way. The intensity is just a float.
This is a breaking api change but low-impact (intensity will be
different).
To convert old values to new values with same intensity:
0: 0.03125
1: 0.05625
2: 0.1
3: 0.175
4: 0.3
5: 0.5
6: 0.9
7: 1.6
8: 2.8
9: 4.8
10: 8.0
Live sends the task updated message for every solo quest and task
increment (not just goal completed).
Also changed color to what live uses now. There are some other color
changes with shared task messages but they correspond with colors
changed in client generated messages but probably not worth chasing
down and causing inconsistency.
* Changed mana_used to use int32,
to match int32 mana_cost
This will allow higher mana costs to function
* Corrected DoHPToManaCovert to Int32
* Removed unused uint16 GetMana function call from Server/zone/questmgr.h
* Change GetSkillDmgAmt from Int16 to Int32 (SkillDamageAmount2 which uses function is Int32)
* Delete mob.cpp
* Revert "Delete mob.cpp"
This reverts commit 3db8bf04d13d7263632b06da4f95bacfcfcfd60c.
* Revert "Change GetSkillDmgAmt from Int16 to Int32 (SkillDamageAmount2 which uses function is Int32)"
This reverts commit cf5dbc9ce81d6e9362ba658a999faab36abf237a.
Co-authored-by: dmcintosh-BCT <dan@blackcreektechnologies.com>
* Add task reward points field
This replaces the separate DoN crystal reward fields with points and
point_type fields. This will make it easier to import data from
packet/client captures and possibly better support any future clients
or tasks that don't reward through the newer reward window.
* Fix manifest column check
* Update logic checks everywhere for FVNoDropFlag.
FVNoDropFlag == 0 is disabled
FVNoDropFlag == 1 is enabled for everyone
FVNoDropFlag == 2 is enabled for Admin() >= Character:MinStatusForNoDropExemptions
* Adding extra parenthesis to reduce ambiquity of order of operations for FVNoDropFlag checks
* Move FVNoDropFlag checks into a helper function in emu_constants.cpp and make an enum for the possible values.
Added console warning if setting is outside of allowed values.
* Move to client scoped helper method
Co-authored-by: Akkadius <akkadius1@gmail.com>
* Update C++ standard to C++17
* Nuke EQ::Any in favor of std::any
* Remove std::iterator due to deprecation
* Replace result_of with invoke_result due to deprecation
Returning non-zero from EVENT_CLICK_DOOR will prevent the default
handler.
This should have been implemented when expeditions were put in to
allow scripts to prevent zoning out of vxed and tipt without flags.
Some upcoming changes may need this to allow scripts to prevent
automatic dz entry.
When a packet was over max_raw_size and zlib failed to compress the
first packet chunk then the final output would be 513 bytes which
exceeded m_max_packet_size of 512.
This occured because the first packet chunk used sublen without
adjusting for the new_length + 1 compression flag added in Compress().
When the packet failed to compress then it was already at its max.
After the first packet, chunk sizes are calculated using max_raw_size
which already accounted for the compress flag. (From #979)
This should fix#2325
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
* Fix for GENERIC_9_STRINGS
* Update .gitignore
* OP_ExpansionPacketData for Titanium and RoF2
* Update for login_opcodes_sod.conf
* Add OP_LoginExpansionPacketData for Titanium and RoF2
* Few expansion fixes
* Update client.h
* Update client.h
* l
* Updates based on PR feedback.
Moved configuration to login.json
Set Titanium limits to constants
* Update login.json
Added the two configurations to login.json
display_expansions - true/false to display on the server select screen
max_expansions - the bitmask of expansions enabled (http://spire.akkadius.com/calculators#expansions-bitmask-calculator)
* Further cleanup based on feedback.
* Further cleanup and refactor max_expansions to max_expansions_mask to better reflect its purpose
* Missed rename of max_expansions corrected.
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
