* Add faction logging category
Probably should use this for more things
* Add FactionAssociation struct
This is simply just a struct that contains an array of faction ids and
multiplier. This can hold a maximum of 10 entries (Seru hit is 8, so 2
extra) this can be raised if need be.
* Add database changes and other data point changes
This is all the database changes and loading changes
Included is an optional SQL that will be used as a starting point, there
is likely errors or typos, but we will fix those as they are discovered.
* Add Client::RewardFaction function
This just takes the faction ID and the magnitude of the primary faction
hit and calculates the rest.
The minimum change will be either 1 or -1. We stop processing after we
see an ID of 0 and assume there will be no later entries.
The primary faction ID will always receive a hit even if there is no
faction association entries
* Add users of RewardFaction to NPC death, tasks, and QuestRewards
This will only use the new system if the magnitude is set, otherwise we
will just use the old system still
* Add quest system calls and lua QuestReward support
* Add #factionassociation command
This just calls RewardFaction, mostly useful for debugging
This allows removal of the task id limit (MAXTASKS)
There's some suspect places task data isn't verified but left unchanged
If memory use becomes too high once more live data is added tasks can be
stored in shared memory instead
* [Zoning] Fix various zoning issues, flag logic, #zone etc
* Enforce character restrictions later in the connection process so we don't end up in a loop race condition in world
Erasing from the map inside the range loop invalidated the iterator used
internally by the loop. This caused ucs access violations under msvc
debug builds when a discord logging category was enabled.
The task goal system made implementing tasks a little confusing since
the goal could be ambiguous depending on type. This also didn't support
filtering on multiple goals (e.g. looting items from matching npc names
inside an area). Deliver types could specify an npc id in `delivertonpc`
but the database may have multiple npcs with the same name or a task
might want to match partial npc names.
This replaces goalids with explicit fields for npcs, items, proximity
areas, and touch switch ids. These changes make managing task data
easier without needing to update multiple tables and allows filtering
task updates by multiple criteria. To mitigate any performance impact
from merging task proximities, only clients with explore tasks in the
current zone are checked during client movement updates.
Items and npcs still support goallists but it would be possible to
denormalize entries into delimited strings to combine with the match
lists. This would also decouple task goals from reward lists.
The client task update functions were refactored to run through a single
filtering function which significantly reduces duplicated code from the
legacy task system. This will also make it easier to later implement
any unhandled types.
Since the new fields will handle filtering single entries and lists
based on having values set, `goalmethod` now only distinguishes quest
controlled from source controlled.
This is a breaking api change, `taskexploredarea` has been removed
since explore ids no longer exist.
* [Code Cleanup] Zone data loading refactor
* Update client_packet.cpp
* strcpy adjustments
* Ensure safe points get reloaded properly
* Simplify GetPEQZone and getZoneShutDownDelay
* Bring in zone_store where needed
* Update client.cpp
* Signature
* Signature
* Convert helpers to using pointers
* PR comment
* Update worlddb.cpp
* Fix loading for instances
* Fix zoning with fallback as well
* Another place for instance fallback
* Make utils/scripts/generators/repository-generator.pl aware of more
datatypes
This adds support for unsigned and more integer types. It also avoids
using parsing functions that require casting (still needed in some
cases)
Having the data types in the Repository structs better map to the types
in the database will allow us to avoid casting when we pull data out of
them. And as a benefit, assume something is wrong if we do :)
Hopefully clean up some warnings due to casting too.
Co-authored-by: Akkadius <akkadius1@gmail.com>
* [Commands] Add #findrecipe and #viewrecipe Commands.
- Add #findrecipe [Search Critieria] command.
- Add #viewrecipe [Recipe ID] command.
- #findrecipe will show #viewrecipe saylinks if the user has access to that command.
- #viewrecipe will show #summonitem saylinks if the user has access to that command.
* Cleanup
* Lexicon change.
* Remove unnecessary .c_str() and
* Add std::string_view overloads for std::from_chars
std::from_chars floating point support is still pour, so we provide some
fall backs. These fall backs currently lack error handling.
(since GCC 11 and MSVC 2019 16.4 FP support is added, clang with libc++
still doesn't support FP)
GCC's floating point support is still rather pour (performance) and
probably shouldn't be used, but we have support to if people want to
now.
Probably need more test cases ...
* Fix issue with std::chars_format define lacking
My test case for lacking FP support was clang with libc++ which defined
this enum anyways.
Some live tasks make new elements available without requiring all
currently active ones to be completed first.
This adds the `req_activity_id` field to task activities which will mark
an element active if its required activity id is completed. If a valid
value is set then it's used instead of checking the current step.
The `step` field may still be set on rows with a valid `req_activity_id`
to specify its logical step and prevent later steps from becoming active
until completed. It's only ignored when deciding if the current element
is active.
The legacy task logic for unlocking activities was completely refactored
for this. A common method has been added so both zone and world can make
use of it to determine which elements are currently active. The previous
step system should remain unchanged.
The world logic for locking shared tasks when an element became active
did not account for "sequential" mode (all steps 0), unordered steps, or
gaps in step numbers. This also resolves that issue.
* [Commands] Command Status Reloading
Currently command status changes require a server restart to take effect, this will allow them to be changed and use `#reload commands` without needing a restart.
Added a helper method called GetCommandStatus() for future reference when sending command saylinks to people and making sure if they're high enough status for the command before sending the link.
* Update client.cpp
* Update command.h
* Saylink cleanup.
* Remove unnecessary packet sending.
* Revert "Remove unnecessary packet sending."
This reverts commit e7e77b83af02955e6cda97fae7901620e09f9ba1.
* [Saylinks] Convert all GM Command Saylinks to Silent Saylinks.
- This cleans up all non-silent GM Command Saylinks that we had before due to the way they worked before. All saylinks like this should be silent now.
- Add source short hand capability for say links with same link as text.
* Defaults to r anyway.
* Spacing.
This wasn't safe since the erase would invalidate iterators used
internally by the range loops.
Shared tasks with no members are now also cleaned up
Make GetMembers return reference instead of copy (this is used a lot)
Add rule for shared task terminate time for easier debugging
This allows shared tasks to create dz instances automatically through
the `dz_template_id` field instead of using quest scripts. Quest apis
were also added to create expeditions from template ids.
This changes task touch elements to use the dz_switch_id as the goal id
instead of checking if a player zoned. It will remove the need to script
door clicks or modify task element zone field since task packet data can
just be imported.
This adds the `dz_switch_id` field to doors and dynamic_zones. It will
allow for compasses to be automatically added to dz entrances and will
support moving clients to the dz on use without needing to script it.
These can be imported for switches/doors from live packet dumps.
Also removes compass packet encoders (same struct in all clients)
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
* 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
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 ])
