Update entWatch to 4.1

[notkoen]

List of tasks to complete before releasing 4.1.x version for public use:

• Miscellaneous tasks
  • Fix indentation levels of all files
  • Setup admin menu system for transfer and restrictions
• entWatch-core
  • Merge MAXUSES and MAXUSES_COOLDOWN together as one mode
  • Add math_counter tracking support, including counterup and counterdown just like CS2
  • Add support for custom names of abilities/buttons
• entWatch-tools
  • Fix transfers not registering item pickup events
• entWatch-servercommand
  • Add convar for toggling feature
• entWatch-restrictions
  • Add database support
  • Add offline eban support
• entWatch-messages
  • Translation file / message config file support
  • Add support for custom names of abilities/buttons
  • Add convar for setting message recipient mode
• entWatch-interface
  • Merge MAXUSES and MAXUSES_COOLDOWN together as one mode
  • Add COUNTERUP and COUNTERDOWN support
  • Add convar for setting team interface mode
• entWatch-forcedrop
  • Setup GameData for ForceDrop feature
  • Setup ForceDrop feature

[Rushaway]

Regarding the EntWatch restriction, some changes will be made, and it will not be compatible with EW 3.
This breaking change is intentional to improve performance and maintainability.
While EW 3 used two tables, EW 4 will use only one.

EntWatch_Ebans
├── id                    (PK auto-increment)
├── client_name           varchar(32)
├── client_steamid        varchar(64)
├── admin_name            varchar(32)
├── admin_steamid         varchar(64)
├── duration_minutes      int
├── issued_at             int
├── expires_at            int NULL
├── reason                varchar(64)
├── unbanned_at           int NULL
├── unban_reason          varchar(64) NULL
├── unban_admin_name      varchar(32) NULL
├── unban_admin_steamid   varchar(64) NULL

Here’s a detailed explanation of why EW4 is better and what the breaking changes entail:

---

Why EW4 is Better

1. Simplified Schema
   EW4 consolidates ban data into a single table (EntWatch_Ebans), eliminating the need to manage two separate tables (EntWatch_Current_Eban and EntWatch_Old_Eban) as in EW3. This reduces complexity in database management and queries.

2. Improved Performance
   With only one table to query and maintain, database operations such as inserts, updates, and lookups are faster and more efficient. Indexes are simpler to maintain, and queries avoid costly UNION operations across multiple tables.

3. Better Maintainability
   A single table schema reduces code duplication and the risk of inconsistencies between current and old ban records. It simplifies application logic, making it easier to develop, debug, and extend.

4. Clearer Data Model
   EW4 explicitly separates ban and unban information with dedicated nullable fields (expires_at, unbanned_at, unban_reason, etc.), improving clarity and making it easier to track ban lifecycle events.

5. Reduced Storage Overhead
   By removing the server field and consolidating tables, EW4 reduces redundant data storage and index overhead, which can improve overall database size and speed.

---

Detailed Breaking Changes

1. Table Consolidation

   • EW3 uses two tables: EntWatch_Current_Eban for active bans and EntWatch_Old_Eban for expired/unbanned records.
   • EW4 merges these into a single table EntWatch_Ebans that holds all ban records regardless of status.

2. Schema Differences

   • The server column present in EW3 tables is removed in EW4. Any logic depending on the server field must be updated or removed.
   • Column names have changed:
     • duration → duration_minutes
     • timestamp_issued → issued_at
     • timestamp_unban → unbanned_at
     • reason_unban → unban_reason
     • admin_name_unban → unban_admin_name
     • admin_steamid_unban → unban_admin_steamid

3. Nullable Fields for Unban Data

   • In EW4, unban-related fields (unbanned_at, unban_reason, unban_admin_name, unban_admin_steamid) are nullable, reflecting that a ban may or may not have been lifted.
   • This differs from EW3 where unban data is split across two tables.

4. Data Migration Required

   • Existing data from EW3’s two tables must be merged into the single EW4 table format. This requires a migration script or process to combine current and old bans correctly.

5. Application Code Updates

   • Any code querying or updating ban data must be updated to use the new single table and new column names.
   • Queries that previously joined or unioned the two EW3 tables must be simplified.

6. Index Changes

   • EW4 uses a different indexing strategy focused on the single table, so any custom queries relying on EW3 indexes may need adjustment.

---

tdlr; I will provide a migration script to handle these changes from ew3 to ew4.

[Rushaway]

TODO:

• Translations Core
• Replace messages from restrictions with forwards to entwatch message system
• Sql script to transfert ew3 data to ew4
• Setup ebans4.nide.gg and update code to new sql structure
• Fix ban edit errors on web panel
• Expired ebans tab return invalid results
• Mutlticolors support
• Translations restrictions inspired by ew3 ++ (colors)
• Format code
• Verify HUD logic if it can improved
• Create a forward for interface reply cmd
• Update messages sp to support restrictions
• Update all mesagges to support entwatch tag with colors
• Cache convars values
• setup admin menu system for transfert and restrictions
• Print to server when item get spawned
• Handle all items state calling forward
• Spawn items module
• Spawn item in admin menu
• Add commands like sm_setmaxuses ?...