mirror of
https://github.com/PlayPro/CoreProtect.git
synced 2026-10-28 09:44:56 +00:00
master
4
Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
  
|
4b1e9ab334 |
Reduced entity kill data by skipping default attributes (#1028)
* Reduced entity kill data by skipping default attributes EntityDeathListener stored every registered attribute of a killed mob, about 23 entries on 1.21+, although almost all hold default values. The attribute list made up about 88% of each kill blob. Store an attribute only when its base value differs from the default or it has modifiers. Kill data now always carries index 7 (UUID or null), index 8 (kill location slot, null for mobs) and a format marker at index 9. When restore sees the marker, it first resets every attribute of the respawned entity to its default base value and removes spawn-time modifiers, then applies the stored attributes, so rollback reproduces the logged entity exactly. Rows without the marker restore as before. Capture and restore both use AttributeInstance#getDefaultValue. It is deprecated since 26.1 for returning the server default rather than the entity type default, but it exists on every supported version (1.16.5+) and the same value is used on both sides. Zombie kill blob: 2036 to 1027 bytes in the legacy format, and 250 to 141 bytes with EntityDataCodec (DuckDB and ClickHouse today, SQLite and MySQL after the v26 migration). On SQLite that is 4096 to 1365 bytes per kill on disk now, or 158 bytes after v26. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f * Restored left-out attributes from a frozen baseline Restoring sparse kill data reset every attribute of the respawned entity to the restoring server's defaults. An attribute the logging server did not have yet was reset as well: a horse logged before 1.20.5 and restored on 26.1 got the global step height, safe fall distance and fall damage multiplier instead of the horse values. AttributeUtils now holds a frozen baseline of 40 attribute values, taken from the 26.2 registry defaults. Kill data leaves out an attribute only when it is in the baseline, has the baseline value and has no modifiers, and sets that attribute's bit in a long stored after the format marker at index 10. Restore sets exactly the attributes with a bit to their baseline values and leaves every other attribute as spawned. Entries are only ever appended, so stored bits keep their meaning, and the restoring server's defaults are never read. Rows without the marker restore as before. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com> --------- Co-authored-by: Claude <noreply@anthropic.com> Co-authored-by: TonyJamesStark <tonyjamesstark1@gmail.com> |
||
|
|
d5db22c23e |
Entity radius purge (#1030)
* Fixed world purges leaving orphaned entity data
co_entity has no world column, so /co purge r:#world deleted the kill
rows in co_block but kept every co_entity row. Those blobs became
orphans that no later purge removed.
- SQLite: copy only the co_entity rows that a retained kill row still
references. This also drops orphans left by earlier purges.
- MySQL/DuckDB: delete the co_entity rows of the kill rows a world purge
removes, before co_block is purged. MySQL uses a join so MariaDB and
MySQL 5.7 do not run a dependent subquery. Global purges keep the
cheaper time-based delete, which is equivalent. If MySQL stops between
the two deletes, running the same purge again removes the remaining
kill rows.
Player kills use the kill action with type 0 and a user id in data, so
they are never treated as co_entity references.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Fixed SQLite purges with world and block filters purging other tables
On SQLite, /co purge r:#world i:<block> built the retain condition for
world-scoped tables without checking the block restriction, so it purged
co_container, co_chat and the other world-scoped tables in that world
although a block restriction should leave them untouched. The
entity_container/entity_interaction branch and the MySQL path already
check it.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Fixed console purges with a radius purging all worlds
/co purge rejects a numeric radius, but the check only saw the radius
when the sender had a location. From the console, /co purge t:30d r:50
parsed no radius and no world, so it ran as a server-wide purge. The
radius is now also parsed against a placeholder location, so it is
rejected for every sender. r:#world is unaffected.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Added orphaned entity data cleanup to MySQL #optimize purges
MySQL deletes in place, so co_entity rows orphaned by earlier world
purges stay until something removes them. With #optimize, delete every
co_entity row that no kill row references, through a temporary table of
referenced ids (avoids an anti-join on the unindexed co_block.data), then
let OPTIMIZE reclaim the space. Failures are reported like the table
loop, so the entity_spawn link cleanup still runs.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Moved purge conditions into PurgeFilter
PurgeFilter now builds the purge condition for every table, and the
SQLite copy, the SQLite recovery path and the MySQL/DuckDB delete all use
it instead of three hand-built copies. Behavior is unchanged; the block
restriction check that the previous commit added to the SQLite copy is
part of the shared condition.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Added entity kill filters to purge command
/co purge rejected entity types and actions, so mob farm kill logs could
only be removed together with all other data. New arguments on SQLite,
MySQL and DuckDB:
- a:kill purges only entity kill rows.
- i:<entity> purges kills of those entity types; it can be combined with
block types.
- e:<entity> keeps kills of those entity types while purging the rest.
Each purged kill also removes its co_entity row. a:kill with block types,
entity types in both i: and e:, e: with only block types in i:,
non-entity exclusions and entity filters on ClickHouse are rejected. Any
a: value other than a kill alias is rejected instead of falling through
to an unrestricted purge.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Added radius support to purge command
/co purge rejected any numeric radius, so kills of one entity type could
only be purged across a whole world. A radius is now accepted when the
purge is restricted to co_block rows with i: or a:kill, for example
/co purge t:30d r:50 i:zombie. r:50x10 also limits the height.
The radius becomes an x/y/z range in the co_block condition. co_entity
rows follow the purged kill rows, so no entity data is orphaned, and the
(wid,x,z,time) index already covers the range. Other tables are left
untouched, as with any restricted purge.
Rejected: a radius without i: or a:kill, WorldEdit selections, radius
purges on ClickHouse, and a numeric radius from the console (it has no
location, as in the console radius fix merged into this branch).
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f
* Made MySQL entity data purges safe against concurrent writers
The #optimize orphan sweep snapshots the co_entity ids that kill rows
reference, then deletes every row missing from the snapshot. Another
installation sharing the database could commit a kill between the two
statements and lose its entity data. The sweep now only deletes rows
inside the purge time range. A kill always writes its co_entity row with
the current time, and a purge range ends at least 24 hours ago, so a
concurrent kill never matches.
A world purge deletes the entity data of the purged kills and
then the kill rows. On MySQL a failure or cancellation between the two
left kept kill rows without their rollback data. Both deletes now run in
one transaction.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Limited SQLite entity data cleanup to the purge time range
A SQLite purge dropped every co_entity row no kill referenced, including
rows newer than the purge range, and counted them as deleted. It now only
removes unreferenced rows inside the range, like the MySQL #optimize sweep.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Rejected purge include and exclude lists without a value
/co purge t:30d e: passed validation, parsed to no exclusions, and ran
as an unrestricted time purge. e:, and e:,,, did the same, as did an
e: at the end of the command and an empty i:. The argument check now
follows each include or exclude list across its continuation tokens and
rejects a list that ends without a value. Space-separated lists such as
e:zombie, villager still work.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Matched purge entity filters to kills logged under renamed types
Bukkit resolves a legacy name such as zombie_pigman to the renamed type,
so the filter only matched the id of the new name. e:zombie_pigman then
purged the old kills it was meant to keep, and i:zombie_pigman missed
them. The filter now covers every entity map id that resolves to the type.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Rejected purges with more than one radius argument
/co purge t:30d r:50 r:#world_nether i:zombie ignored the explicit world
and purged around the player in their current world. Two r: arguments
always conflict, so the second one is now rejected before the purge
starts, whether it is a world, #global or another radius.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Applied max-radius to radius purges
A radius purge accepted any value. A radius past the int range saturated,
the area overflowed, and the purge reported success with nothing deleted.
It now stops at max-radius like lookups and rollbacks.
Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
* Checked radius arguments inside purge include and exclude lists
/co purge t:30d i:zombie, r:50 r:#world_nether passed the second-radius
check: the validator took r:50 as a value of the include list, then saw
r:#world_nether as the only radius. The radius and world parsers read
both. A list now continues only with plain or minecraft: namespaced
values, so a radius after a trailing comma is counted and the second one
is rejected. This is the same change as
|
||
|
tonyjamesstarkandClaude
|
29d22d5a58 |
Fixed console purges with a radius purging all worlds (#1026)
/co purge rejects a numeric radius, but the check only saw the radius when the sender had a location. From the console, /co purge t:30d r:50 parsed no radius and no world, so it ran as a server-wide purge. The radius is now also parsed against a placeholder location, so it is rejected for every sender. r:#world is unaffected. Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f Co-authored-by: Claude <noreply@anthropic.com> |
||
|
tonyjamesstarkandClaude
|
4e70d63978 |
Fixed SQLite purges with world and block filters purging other tables (#1025)
On SQLite, /co purge r:#world i:<block> built the retain condition for world-scoped tables without checking the block restriction, so it purged co_container, co_chat and the other world-scoped tables in that world although a block restriction should leave them untouched. The entity_container/entity_interaction branch and the MySQL path already check it. Claude-Session: https://claude.ai/code/session_01PdEuKbjcVoVinVQJq4te1f Co-authored-by: Claude <noreply@anthropic.com> |