HashMapPalette uses an instance of CrudeIncrementalIntIdentityHashBiMap
internally. A Palette has a preset maximum size = 1 << bits.
CrudeIncrementalIntIdentityHashBiMap has an initial size but is
automatically resized. The CrudeIncrementalIntIdentityHashBiMap is created
with the maximum size in the constructor of HashMapPalette, with the aim
that it doesn't need to be resized anymore. However, there are two things
that I think Mojang hasn't considered here:
1) The CrudeIncrementalIntIdentityHashBiMap is resized, when its initial
size is reached and not the next time, when a further object is added.
2) HashMapPalette adds objects (unnecessarily) before checking if the
initial size of CrudeIncrementalIntIdentityHashBiMap is reached.
This means to actually avoid resize operations in
CrudeIncrementalIntIdentityHashBiMap, one has to add 2 to the initial size
or add 1 and check the size before adding objects. This commit implements
the second approach. Note that this isn't only an optimization but also
makes async reads of Palettes fail-safe. An async read while the
CrudeIncrementalIntIdentityHashBiMap is resized is fatal and can even lead
to corrupted data. This is also something that Anti-Xray is currently
relying on.
Up to now Anti-Xray did only replace blocks that have the default block
state of the specified blocks in hidden-blocks (engine-mode: 1) or
hidden-blocks and replacement-blocks (engine-mode: 2). Therefore it wasn't
possible to replace for example chests facing south because chest refers to
the default block state facing north. Supporting block states in these lists
is overkill. Instead this commit makes Anti-Xray to replace all block states
of a specified block. However, Anti-Xray will still place the default block
states.
* Preserve order of hidden-blocks in Anti-Xray
This small change allows to specify and predict the order in which
Anti-Xray uses the hidden-blocks in engine-mode 2. The order is
preserved as specified in the hidden-blocks list. This can be useful,
for example, when adding air to the hidden-blocks to predict which fake
ores should be exposed to fake air.
* Allow to add equal blocks multiple times to hidden-blocks
This adds the ability to add equal blocks multiple times to the
hidden-blocks of Anti-Xray in engine-mode 2. Thus it is possible to give
certain blocks different priorities in Anti-Xray. For example if air and
diamond_ore are added twice, the obfuscated chunk will contain twice as
many air and diamond_ore blocks as other blocks in the list.
Up to now a simple counter variable was used to iterate through the
hidden-blocks in engine-mode 2 while obfuscating. This results in low
quality obfuscation.
One could for example easily write a hack, which bypasses Anti-Xray
by not showing ores, which have a certain pattern.
Furthermore, engine-mode 1 is slightly optimized by this commit.
However, engine-mode 2 is probably somewhat slower. I did some tests but
I wasn't able to get stable results for some reason. Therefore this
needs further testing.
An optimized random algorithm is utilized to pick random blocks from the
hidden-blocks list. This implementation uses xorshift and integer
multiplication for bounding. The resulting distribution is negligibly
biased because xorshift doesn't generate 0 and integer multiplication
also implies biased results.
Obfuscate multiple chunks at a time over the server thread pool.
Will speed up chunk processing when anti xray is enabled.
Co-authored-by: Aikar <aikar@aikar.co>
HashMapPalette uses an instance of CrudeIncrementalIntIdentityHashBiMap
internally. A Palette has a preset maximum size = 1 << bits.
CrudeIncrementalIntIdentityHashBiMap has an initial size but is
automatically resized. The CrudeIncrementalIntIdentityHashBiMap is created
with the maximum size in the constructor of HashMapPalette, with the aim
that it doesn't need to be resized anymore. However, there are two things
that I think Mojang hasn't considered here:
1) The CrudeIncrementalIntIdentityHashBiMap is resized, when its initial
size is reached and not the next time, when a further object is added.
2) HashMapPalette adds objects (unnecessarily) before checking if the
initial size of CrudeIncrementalIntIdentityHashBiMap is reached.
This means to actually avoid resize operations in
CrudeIncrementalIntIdentityHashBiMap, one has to add 2 to the initial size
or add 1 and check the size before adding objects. This commit implements
the second approach. Note that this isn't only an optimization but also
makes async reads of Palettes fail-safe. An async read while the
CrudeIncrementalIntIdentityHashBiMap is resized is fatal and can even lead
to corrupted data. This is also something that Anti-Xray is currently
relying on.
Child nodes are handled by CommandDispatcher#parse checking
requirements.
Vanilla clients only send ServerboundCommandSuggestionPacket when
encountering a command node with ASK_SERVER suggestions, however a
modified client can send this packet whenever it wants.
Undo the accidental renaming of a method in e45e15c
Aikar wanted to rename DataPalette#getDataBits(T object) to getOrCreateIdFor
in e45e15c but he also accidentally renamed
ChunkPacketInfo#getDataBitsIndex(int chunkSectionIndex) to
getOrCreateIdForIndex.
Remove chunk-edge-mode and chunk loading entirely from Anti-Xray
The chunk-edge-mode is broken since several versions.
Loading chunk neighbors for chunk edge obfuscation isn't needed anymore.
Unlike in previous versions, these are under normal circumstances already loaded
at the time we need them (plugins for example can bypass this).
Use the modified methods and constructors everywhere
Anti-Xray provides support for the default nms methods and constructors,
which where modified by Anti-Xray to avoid breaking stuff (plugins)
which somehow uses these methods.
However, the modified versions of those methods and constructors should be used
where possible.
