* Combine task_activity item and npc fields
This will make tooling easier.
While denormalizing goallists may not be ideal, it decouples tasks from
rewards which share the table and removes a redundant column in favor
of a using the delimited string which better matches live packet data.
* [Tasks] Deprecate goallists table, migrate reward goal lists, simplify logic
* Update 2022_09_25_task_concat_matchlists.sql
* Update 2022_09_25_task_concat_matchlists.sql
* Tweaks
* Fix reward column name in conversion script
* Task reward stacking
* Update task_client_state.cpp
* Implement stack counts
* Fix reward item instance memory leak
* Validate reward item instance
* Fix item reward message
* Fix findtask
Co-authored-by: Akkadius <akkadius1@gmail.com>
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.
* 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>
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.
* Insert repository improvements
* Remove no longer necessary code, remove license banner since we have a license at the repo level
* Update template comments
