Can we store the type of the recent projectile as well? This could be used in my upcoming PR regarding the golf packet where I check for recently created projectiles, and their types. Having only the index is not useful in this scenario, because the projectile can already be killed, so cannot access the Main.projectile array to get the projectile type.
Can this be public instead of internal? Developers could make good use of it, instead of having to implement their own version of RecentProjectiles in their plugins.
Per packet debug logs are redundant for people with the packet monitor
plugin. If you need packet monitoring, please install the packet monitor
plugin.
Update the validation logic to be accurate:
* use pixels and not tiles
* allow master mode
* use npc position and not player position
Cleanup some style inconsistencies in NetHooks_SendData.
This reverts commit 7ad46abced. This
reintroduces the worldpath argument as per request from #1914, but at a
different name. This is because users have configurations like this,
which no longer work:
-world + -worldpath = crash
If you want to use -worldselectionpath to specify a world, you should be
able to use -worldname, but don't use -world unless you specify an
absolute path to a world.
No matter how we solve this we get a support headache (-worldpath +
-world = crash). This temporary stopgap should work to help address
issue #1914 until we can figure out a final solution. Since users are
impacted by this change, temporarily adding this back is the best move.
To be 100% clear, though:
-world + -worldselectpath without specifying an absolute path will
result in a crash that is unhelpful. Please don't do that.
These are high priority checks we really want to look at. I want to add
more of these debug statements to all checks in Bouncer and other parts
of GetDataHandlers, but I think this is good enough for now.
* Remove commented out warning disable
* Add initial ItemBans segregation infrastructure
* Add shell for initial OnSecondUpdate stuff
* Add comments yo
* Remove duplicated logic
* Split out more item ban code
This part of the fragments work is primarily aimed at reducing the
complexity of OnSecondUpdate in TShock and moving that check out into
the ItemBans subsytem.
Of major note in this is the removal of "check", which was a string
variable that tracked state and replacement of many of the item ban
activities with sane private methods that are at least somewhat
sensible. Obviously there's a lot to be desired in this system and I'm
really going for a run here by trying to continue a branch from so long
ago that I barely even remember the whole point of existence.
Still to do: GetDataHandlers related item ban code needs to be moved
into its own hook in the ItemBan system. Finally, there is a downside to
some of this: we're basically iterating over players again and again if
we keep this pattern up, which is kinda lame for complexity purposes.
* alt j: comment changes
* Move item ban check out of main playerupdate check
Separates out item ban logic from the rest of GetDataHandlers so that
item bans is more isolated in terms of what fragments is asking for.
* alt-j: convert indentation to tabs
* alt-j: fix botching source code
* Move item ban related chest checks out of gdh
* Remove chest item change detection from item bans
It doesn't do anything. If a user removes an item from a chest, it
bypasses this check. If a user adds an item to a chest, the server seems
to persist the change anyway, even if the event is handled. That's a bug
for sure, but fundamentally, it's not the item ban system's fault.
* Revert "Remove chest item change detection from item bans"
This reverts commit 758541ac5c4d4096df2db05ba2a398968113e1e4.
* Fix logic issues related to item ban handling
Re-implements chest item handling and correctly handles events and
returns after setting handled event state.
* Remove TSPlayer.HasProjectilePermission
In infinite wisdom, it turns out this is not a good method for TSPlayer
to have. It just checks the states of things as per what the item ban
system says is banned and then creates implicit relationships to the
projectile ban system.
Doing this effectively knocks down another external reference to the
item ban system outside of the context of the implementation for the
system itself and its related hooks.
This commit also adds context around what the heck is going on with some
of our more interesting checks as per discussions in Telegram with @Ijwu
and @QuiCM.
* Update changelog
* Remove useless ref to Projectile.SetDefaults
* Change item ban to ban based on ID not strings
I think I was so confused as to why we were passing strings everywhere
that I just felt inclined to continue the trend in previous commits.
From #1653:
>From latest version (2301)
If a player puts on a banned peice of armour, they get the message to say "You are wearing banned equipment"
After they take it off, the messages stop, but they keep getting disabled.
Solution:
Approx line 1131 in tShock.cs on `OnSecondUpdate` the `tsplayer.IsDisabledForBannedWearable` gets set to true, but it never gets set to false.
Change:
```csharp
if (check != "none")
player.IsDisabledForBannedWearable = true;
```
>To:
```csharp
if (check != "none")
player.IsDisabledForBannedWearable = true;
else
player.IsDisabledForBannedWearable = false;
```
Requires testing
The stat tracker has been offline for the last several weeks/months and
nobody has done anything to fix that. Because of that, GDPR, and the
fact that we haven't used it, we're discarding it.
If there's one thing I learned in this exercise, it's that letting
people add random python scripts to the repo like gpltext.py that
promise to be easier than find and replace is a bad idea.
As pointed out by @QuiCM, TShock.Players is actually an array and not a
smarter collection, so length will return the total collection size and
not the active players. An earlier commit was added that gives TSPlayer
an ICollection<TSPlayer> that contains only active players. This is now
the basis of determining the number of active players on the server.
This is not a great method, but it's actually the only method in TShock
that interpolates the %map% and %players% variables and it used in at
least three places in the codebase. Since it's already so specialized,
it's not worth changing it to take an actual File object, in my humble
opinion.
This also clarifies what the method does and what makes it special, as
opposed to being fairly generic.
The ban system needs a full rewrite anyway, but this move removes
something from Utils, puts it closer to its operating point, simplifies
the method, and clarifies what it actually does.
