Spigot might be reintroducing a built-in anti-xray, monitor

[ProgrammerDan]

And if they do, add auto-disable back

https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/pull-requests/68/overview

https://hub.spigotmc.org/stash/projects/SPIGOT/repos/spigot/pull-requests/61/overview

[RoboMWM]

#spigot-dev:

[03:43:58] stonar96: md_5: What's going on with Anti-Xray? Will it be merged? Any changes required? [03:47:48] ~md_5: it's still quite dependent on internal format, and I'm not convinced it is maintainable. Also someone has released an anti xray plugin also [03:49:32] ~md_5: I might sit down and evaluate it again when I get time, but the reality is that we need to be pretty sure we are capable of updating your code to every MC version that comes out now and 3 years in the future

[sgdc3]

@RoboMWM damn XD

[ProgrammerDan]

@RoboMWM Thanks for passing that along! I'll keep an eye on that pull request; largely we want to make sure that if Spigot does introduce a built-in, we add a hook to optionally disable either it or ours so they don't overlap.

[intangir]

wasn't lishid involved in the original support for anti-xray in spigot?

the paper fork might also be interested in any pull requests which readd support for anti-xray directly into the server, as would alot of users such as myself

[intangir]

another thread about it might want to contact @stonar96

[RoboMWM]

Paper is likely reintroducing it, though. https://github.com/PaperMC/Paper/pull/349

[ProgrammerDan]

Sounds good -- hopefully that works out well!

I'd love to see some side-by-side timings, I know the spigot built-in always got bad press, I'm very curious how Orebfuscator4 would stack up against @stonar96 's PaperSpigot contribution.

[stonar96]

@ProgrammerDan You can't really compare the timings. My implementation is async but tests have shown that my implementation is much faster than the old Spigot inbuilt Anti-Xray implementation when my implementation wasn't yet async bacause it has many optimizations.

[ProgrammerDan]

You can generally compare two things that do the same thing; regardless of sync or async, just measure how long to obfuscate / unobfuscate, do so other a time period, measure cpu load and mem load while holding other things as equal as possible ...

I might be misunderstanding you, or you me. I'm not suggesting compare the new PaperSpigot implementation vs. the old Spigot built-in, but rather your new PaperSpigot vs. this project -- "under new management" Orebfuscator :)

[stonar96]

Of course you can compare it. I thought you were talking about the timings on the main thread were a comparison wouldn't make sense.

[ProgrammerDan]

:) Anyway, idle curiosity. These things wind up being preference / ease at the end of the day.

[RoboMWM]

In case you aren't already aware, Paper implemented antixray. https://github.com/PaperMC/Paper/commit/524ebe97d7bf947e540019baf0eb68777449db0a

[ProgrammerDan]

@Aleksey-Terzi I'd be curious for a methodology check on their performance metric testing: https://github.com/PaperMC/Paper/pull/858

Also, @RoboMWM do you have any idea on feature parity? We've packed in a lot of great features that for sure have increased running time a bit but greatly enhanced functional utility ... thoughts?

All the same, good to see that PaperSpigot will offer people some baseline anti-xray!

[RoboMWM]

Idk, I've already jumped ship :P although as you're probably aware I didn't use any of the proximityhider, darkness, etc. features.

Main thing that makes paper's highly performant is that it runs asynchronously.

If you want to add more, it's interesting to see how he's changing the obfuscated ores as the blocks are updated... ~~though not sure what the purpose of doing that is to be honest (wouldn't that, at best, just increase network bandwidth? /shrug)~~ I suppose the purpose is to fake out xrayers in determining if a nearby-updated block is revealing an ore or not.

[ProgrammerDan]

Hmm, fakeout seems unwise. Non-static presentation would lead to interference patterns ... which can be studied and eliminated, by clever client-side code. Static doesn't have this failing, as it'll only ever lie to you in the same way, so there's nothing to eliminate...

Still, can't blame you, performance makes a big difference although that's my interest -- the performance gains seemed "relatively" small (ofc it adds up!), so I'm curious on their methodology.

[Aleksey-Terzi]

@ProgrammerDan Yes, I should look it definitely.

@RoboMWM

Main thing that makes paper's highly performant is that it runs asynchronously.

Btw, did you have performance issues with latest Orebfuscator?

[RoboMWM]

No, but I hardly have any sizeable, consistent playerbase to speak of.

[Aleksey-Terzi]

I asked, because of:

1. Current Orebf even with enabled ProximityHider (which anyway is working in async task) almost haven't impact on performance (was tested on servers with 100+ players simultaneously), when tps is 20 - I think server could be considered as well working :)

2. I have doubts that "runs async" optimization will give visible performance improvement, because of main server's process is not thread safe. So if "anit-x ray" want to use some Bukkit API (and it will need to use) - it need to lock server's thread...

3. Orebf is using caching - so in most cases data even not generated but just sent to client

But in any case would be good to look to anti-xray patch, perhaps there was found some perfect way which made server much more performant. Also would be good to see some performance results on large amount of players.

[RoboMWM]

So basically paper has it and it's great. Idk the patch myself but the async-ness is safe and performant (details on respective PRs) and apparently what was pulled was far better than what he initially PR'd.

Spigot won't be getting antixray, stonar96 long gave up on trying to get a PR in there (especially with the PR politics surrounding spigot).