CDClientSnapshot converts a copy of the client's fdb into its own
CDServer-<hash>.sqlite with the cdserver migrations applied, on its own
connection. CDClientDatabase::Reconnect opens the new file before letting go
of the old one; CDClientManager::Reload empties every table (old entries kept
alive so references from spawned objects stay valid), retires the old fdb view
and loads again.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
The world and master servers pass the client's res/cdclient.fdb to
CDClientManager. When it opens, these three tables, all looked up by
their first column, find rows through the fdb's buckets instead of each
process caching the whole table: ComponentsRegistry keeps nothing,
ItemComponent and Objects keep only the entries asked for (their API
returns references). Ids whose rows CDServer.sqlite changes are loaded
from SQLite at startup and win. Without an fdb (or with one whose
columns don't match) the tables load from CDServer.sqlite as before.
ItemComponent and Objects now fill entries from one template for both
sources instead of copies of the same field list.
Tests cover the SQLite changes on top of the fdb, the no-fdb and
unmapped paths, and, when DLU_CLIENT_RES points at a client, every id of
the three tables through the fdb against CDServer.sqlite.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Every entity and every inventory item looks these up, and an id not seen yet was a full scan of the
unindexed table, so a character holding about 3000 different items took a minute to load (the client
waited at 35%). Loading both tables once at startup costs a few MB per server.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
EventGating (eventName, date_start, date_end; 8 rows) is only in the
CDClient for the server: the 1.10.64 client has no string for it. The
dates are Unix times (UTC), inclusive: pirateDay 2011-09-19 00:00 to
2011-09-20 23:59:59 (Talk Like a Pirate Day), buildNexusTower 2010-03-09
to 2011-03-14, buildNexusTowerEnd, frostburgh2010_notused and test rows.
The live Lua asked for an event with GetHolidayEvent{eventToCheck =
name}.isValid; the only callers are the Crux Prime random spawners
(L_BASE_RANDOM_SPAWNER.lua, L_AM_ZONE_SERVER.lua), whose only event is
pirateDay. DLU's BaseRandomServer::CheckEvents was a TODO.
- CDEventGatingTable loads the table; HolidayEvents::IsActive(name) is
true while the dates include now, or when event_1..event_8 names the
event (every live date is in 2010/2011, so this is how a server turns
one on; the same settings already switch gatingOnFeature objects).
- BaseRandomServer::CheckEvents: during pirateDay the str and zip areas
use the event loads from the Lua (80%: 5 pirates on each of type1-3,
20%: 5 admirals each; multipliers secA 1, secB 1, secC 1.2 for str).
Inferred: every spawner's Lua put the whole {str, zip} table in its
zones, which its getRandomLoad walks with ipairs and so finds no load;
DLU uses each table for the area it names, as L_AM_ZONE_SERVER.lua's
layout intends.
- sharedconfig.ini says event_N also takes EventGating names.
Check in game: with event_2=pirateDay in sharedconfig.ini, the Crux Prime
areas filled by the str and zip random spawners (spawner networks
em_str_* and em_zip_*) spawn only Maelstrom pirates and admirals; the
other two areas and a server without the setting spawn the usual mix.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
CollectibleComponent (79 rows: id, requirement_mission) is only in the
CDClient for the server: the 1.10.64 client has no string for it. DLU
never read it.
What the column holds (1.10.64 CDClient, joined with ComponentsRegistry,
Missions and MissionTasks): for 63 rows it is the mission the collectible
belongs to. Mostly that is the achievement whose collection task
(taskType 3) targets the collectible's LOT (the flags, imagination bricks,
Johnny Thunder collectibles). For a few it is a mission to accept from an
NPC that does not collect the item itself: the four Ninjago dragon relics
(16483-16485) are collected by the hidden achievements 2064-2067 but
their requirement is 2040 (accepted from LOT 13789, "complete 2064-2067").
Other values: -1 and 66666666 (no such mission) on test rows.
So a collectible whose requirement_mission is a mission to accept
(Missions.isMission) now only counts (HasBeenCollected progresses
nothing) while the player has that mission accepted and not handed in
(ACTIVE, READY_TO_COMPLETE or their repeat states). Achievements, missing
missions and rows without one are unchanged. Without this, a player who
had not accepted 2040 could collect the relics early and have 2040
complete as soon as it was accepted. The gate itself is inferred from the
data: the captures show collections but not the live server's check.
The collectible's object report shows the requirement mission.
Check in game: in Ninjago Monastery, before accepting the dragon relic
mission (2040), touch a dragon relic: it does not count; accept 2040 and
collect them: each counts and 2040 completes after the fourth. Flags,
imagination bricks and Johnny Thunder collectibles still count as before.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Deleting an item now follows its ItemComponent delResIndex row in the
DeletionRestrictions table, the way the client's shared inventory code
decides it (LWOInventoryComponent_Common::CanRemoveFromInventory @
0x00ce0d20, CheckDeletionRestrictionIndex @ 0x00c94c20):
- missing, unrestricted, unknown-type or empty rows allow it;
- LOTS_INCLUDED: another item of any listed LOT must remain;
- LOTS_EXCLUDED: other items of every listed LOT must remain;
- ANY_RESTRICTION / ALL_RESTRICTIONS: any / all listed rows allow it;
- ZONE: only in the listed maps; ALWAYS_RESTRICTED: never.
Operators (GM level 9) may delete anything, as in the client. A refused
delete is logged and the item stays.
ItemComponent.minNumRequired is not used: the client never reads it, so
its meaning can't be verified.
Issue 960: the rocket (6416, row 8) and the classic rocket parts (rows 1-3)
have rows that keep at least one rocket or part, so the last rocket can
no longer be deleted and strand the player.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ModularBuildFinish hardcoded the item a finished build becomes (6416 for 3
parts, 8092 for 7) and the car chassis part (8129) that the every-part-
swapped check skips. They now come from ModularBuildComponent: createdLOT,
<numberOfParts> and the <ExamplePartLOT> of the <rootPart> module (new
CDModularBuildComponentTable). Same results with the 1.10.64 cdclient;
tests cover the xml parsing and the lookup.
Refs #691
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* move the pet minigame table loading logic out of petcomponent
* misc fixes
* actually, using paths is dumb here when they're already char strings. why bother? silly me.
* removed unga bunga reference-casting
* add back in puzzle not found error message
* pre-allocate unordered map and make getter const-correct
* Update dDatabase/CDClientDatabase/CDClientTables/CDTamingBuildPuzzleTable.cpp
Co-authored-by: David Markowitz <39972741+EmosewaMC@users.noreply.github.com>
---------
Co-authored-by: David Markowitz <39972741+EmosewaMC@users.noreply.github.com>
* Move CDClientManager to be a namespace
Tested that worlds still load data as expected. Had no use being a singleton anyways.
* Move cdclient data storage to tu local containers
Allows some data from these containers to be saved on object by reference instead of always needing to copy.
iteration 2
- move all unnamed namespace containers to a singular spot
- use macro for template specialization and variable declaration
- use templates to allow for as little copy paste of types and functions as possible
* remember to use typename!
compiler believes T::StorageType is accessing a member, not a type.
* Update CDClientManager.cpp
* move to cpp?
* Assorted pet improvements
* remove unecessary include
* updates to address some feedback
* fixed database code for testing
* Removed reference member (for now)
* Removed cmake flag
* chore: organize build flags
* Remove ambiguous include path
Don't be default incluyde bcrypt so you need to specify the folder. Allows pre-processor to find the correct file.
* Revert settings
* working
f
* feat: reward codes
this is for giving rewards across characters as the did in live.
Tested that the default config works
Tested that all claim codes work
Tested that saving and loading claim codes work
Tested that mail sends correctly
* newlines
* include array
* delete cascade
* newline
* address feedback
* Database: Convert to proper namespace
* Database: Use base class and getter
* Database: Move files around
* Database: Add property Management query
Database: Move over user queries
Tested at gm 0 that pre-approved names are pre-approved, unapproved need moderator approval
deleting characters deletes the selcted one
refreshing the character page shows the last character you logged in as
tested all my characters show up when i login
tested that you can delete all 4 characters and the correct character is selected each time
tested renaming, approving names as gm0
Database: Add ugc model getter
Hey it works, look I got around the mariadb issue.
Database: Add queries
Database: consolidate name query
Database: Add friends list query
Update name of approved names query
Documentation
Database: Add name check
Database: Add BFF Query
Database: Move BFF Setter
Database: Move new friend query
Database: Add remove friend queries
Database: Add activity log
Database: Add ugc & prop content removal
Database: Add model update
Database: Add migration queries
Database: Add character and xml queries
Database: Add user queries
Untested, but compiling code
Need to test that new character names are properly assigned in the following scenarios
gm 0 and pre-approved name
gm 0 and unapproved name
gm 9 and pre-approved name
gm 9 and unapproved name
Database: constify function arguments
Database: Add pet queries
* Database: Move property model queries
Untested. Need to test
placing a new model
moving existing one
removing ugc model
placing ugc model
moving ugc model(?)
changing privacy option variously
change description and name
approve property
can properly travel to property
* Property: Move stale reference deletion
* Database: Move performance update query
* Database: Add bug report query
* Database: Add cheat detection query
* Database: Add mail send query
* Untested code
need to test mailing from slash command, from all users of SendMail, getting bbb of a property and sending messages to bffs
* Update CDComponentsRegistryTable.h
Database: Rename and add further comments
Datavbase: Add comments
Add some comments
Build: Fix PCH directories
Database: Fix time
thanks apple
Database: Fix compiler warnings
Overload destructor
Define specialty for time_t
Use string instead of string_view for temp empty string
Update CDTable.h
Property: Update queries to use mapId
Database: Reorganize
Reorganize into CDClient folder and GameDatabase folder for clearer meanings and file structure
Folders: Rename to GameDatabase
MySQL: Remove MySQL Specifier from table
Database: Move Tables to Interfaces
Database: Reorder functions in header
Database: Simplify property queries
Database: Remove unused queries
Remove extra query definitions as well
Database: Consolidate User getters
Database: Comment logs
Update MySQLDatabase.cpp
Database: Use generic code
Playkey: Fix bad optional access
Database: Move stuff around
WorldServer: Update queries
Ugc reduced by many scopes
use new queries
very fast
tested that ugc still loads
Database: Add auth queries
I tested that only the correct password can sign into an account.
Tested that disabled playkeys do not allow the user to play the game
Database: Add donation query
Database: add objectId queries
Database: Add master queries
Database: Fix mis-named function
Database: Add slash command queries
Mail: Fix itemId type
CharFilter: Use new query
ObjectID: Remove duplicate code
SlashCommand: Update query with function
Database: Add mail queries
Ugc: Fix issues with saving models
Resolve large scope blocks as well
* Database: Add debug try catch rethrow macro
* General fixes
* fix play key not working
* Further fixes
---------
Co-authored-by: Aaron Kimbre <aronwk.aaron@gmail.com>
