It was discovered that LastNetPosition is being checked to see if it's
zero in Bouncer. Then, Bouncer rejects the update. The default is zero
and potentially this can be zero in other ways. The original code in
master (checked at 9f4892f in GetDataHandlers) had an additional write
on LastNetPosition to update it, but this write was not moved over to
Bouncer. Thus, there is a high probability that players are "desync'd"
after LastNetPosition gets stuck at zero and never updates.
The reimplementation of Terraria player sync was first created by
@Zidonuke when introducing better antihack and the item ban system. He
added this because he was probably attempting to correct the client that
sent that sent bad data. The primary purpose was to send data back to
the client, not necessarily for the purpose of doing anything for the
server. This is demonstrated by the fact that when we added player
update handling, we started rejecting the packets outright and not
sending the player any packets. This means that functionally we don't
run this code hardly ever if someone is actually disabled.
Some of those code was related to /confuse. That is also being removed.
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.
Debug logging now provides ConsoleDebug and ILog has been updated to
support the concept of debug logs. Debug logs are now controlled by
config.json instead of by preprocessor debug flag.
`worldevent` is now the root for the following:
Meteor, fullmoon, bloodmoon, eclipse, invasions, sandstorm, rain.
Added a new set of permission nodes to represent world events: `tshock.world.events.*`
As of 1.4.x.x, these are used for more than just chat text and we need
to start handling them separately. The original check here would just
return true (handling the event) for any module that's not text. Now, we
need to actually do processing and check for exploits on these.
Really.. time for bed.
The Any wasn't terrible, but itwould have allow cross sending projectiles within that dictionary. (send gold stab with copper in hand, or vice versa etc)
This change moves the ban checks used to determine, during TileEdit
events, if an item is banned, out of Bouncer and into the newly isolated
ItemBan subsystem. Rather than creating a large pull request for all of
these, I'm just going to create a series of commits and send them in one
at a time. This should result in about one PR per hook that uses item
bans that needs to move.
* 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.
360 ticks = 6 seconds, according to the wiki, the max possible duration is proportional to dmg taken, so 7.5 seconds would be the max duration (aka 450 ticks)
