Dirt Bomb + Liquid Bombs/Rockets Can Grief Protected Regions

[lost-werewolf]

• TShock version: 6.0.0-beta (latest release)
• TShock build number (if known):

Reproduction steps (if applicable)?

1. Throw a dirt or liquid bomb into a region you cannot build in
2. When the bomb explodes, it will still place dirt (or liquid) in the region

Any stack traces or error messages (if known)?

N/A

Any screenshots?

Video clip provided of the issue:
https://files.catbox.moe/d82p4u.mp4
Could not upload to GitHub, so I used an alternative hosting service.

Any log messages from files that end in .log or .txt? What are the last 100 log messages from the server console?

2026-01-22_03-25-52.log

What plugins and what versions of those plugins are you running?

None

If this is a duplicate issue, please close it.

[lost-werewolf]

From my own research into this, the explosions from dirt bombs/liquid bombs (or rockets) are handled on the server side when the projectile is killed. The relevant code is in Projectile.Kill, and more specifically, the spreading of dirt/liquid is handled through Projectile.Kill_DirtAndFluidProjectiles_RunDelegateMethodPushUpForHalfBricks.
Fixing this likely requires hooks that fire off when:

• Projectile.Kill is called
• The plot method fed into Kill_DirtAndFluidProjectiles_RunDelegateMethodPushUpForHalfBricks is called

As for implementation, it's out of my scope, so I opened this issue in hopes someone else can solve this problem. These projectiles have been able to grief protected regions for a good while now, and I'd really like to see this fixed properly.
What I can think of though, is to remember who last killed a projectile which spreads tiles/liquids on the server's end. And when the plot method is called inside of Utils.PlotTileArea, build permission gets checked for that player (and it exits early if they aren't allowed to build there). There's no other real way I can see to associate the TileActionAttempt to a player unless parts of how killed dirt bombs/liquid bombs (or rockets) are re-implemented.

[bartico6]

I reimplemented the whole "tile projectiles" system because it is so thoroughly unfriendly to modded servers that there was no point trying to hack it to work correctly.

An IL patch could however edit the relevant methods to include a Player parameter and insert the player instance easily (projectile.owner points to who made the projectile and thus who should be tested for permissions)

[lost-werewolf]

Reimplementing that system is more than ideal to fix this, IMO. Does your reimplemention also reimplement Utils.PlotTileArea in a way that takes the invoking Player? Because if it does, this is more than perfect for fixing the problem. It should future-proof any newer cases of the server placing tiles or liquids from something the client did (killing a projectile) that may be added in 1.4.5.

Also should note that if you DID reimplement Utils.PlotTileArea at all, you may want to make sure it's up to date soon - the bfs algorithm for it has been improved in 1.4.5 according to Chicken Bones in the tML discord (https://discord.com/channels/103110554649894912/445276626352209920/1426715527010586795)

[sgkoishi]

My approach is wrap the DelegateMethods.Spread* with a small check binds the player. Hook on proj kill is quite big but should be compatible with other changes in vanilla, and being small specific snippet. Not handling any potential new similar projectiles tho.

[bartico6]

Reimplementing that system is more than ideal to fix this, IMO. Does your reimplemention also reimplement Utils.PlotTileArea in a way that takes the invoking Player? Because if it does, this is more than perfect for fixing the problem. It should future-proof any newer cases of the server placing tiles or liquids from something the client did (killing a projectile) that may be added in 1.4.5.

Also should note that if you DID reimplement Utils.PlotTileArea at all, you may want to make sure it's up to date soon - the bfs algorithm for it has been improved in 1.4.5 according to Chicken Bones in the tML discord (https://discord.com/channels/103110554649894912/445276626352209920/1426715527010586795)

The only issue is the changes are not cross-compatible with tShock at all. My comment was meant to suggest a course of action for anyone looking for a solution, not offering a ready-made one.

And yes, it takes the player parameter. It also is hand optimised because the original (IIRC) looped over the same tiles multiple times