In Spigot they include Orebfuscator. While I doubt including it with the API is a good idea, we should come up with a better way of stopping xrayers. One that doesn’t have ores popping up and other things that aggerivate legitimate players.
1 Like
We could force the sponge clients to query the server for textures but that will just lagg the clients or the server itself and I am pretty sure that they would like vanilla clients to be able to join so this sort of feature is upto Mojang to implement in their vanilla clients first if you get what I mean.
Another approach would be to get the clients to query the servers for all the textures at the start but again this could lead to lag on either ends if not implemented properly.
One reason why Mojang would be refraining from such a feature would be because the freedom of allowing the user to use his/her own texture pack would be taken out because it would be useless if this feature was implemented.
- TangentSpy
why not have the server request the texture pack the client is using? like a whitelist
Now that is a very good idea however it will be hard to report texturepacks as players will just change the texture pack names to circumvent such a feature. One way around this would to check to see if the texture is null or completally transparent. I’m not sure of a Java library that would allow for graphic checking such as that but this is good way to get around it.
- TangentSpy
For those talking about resource packs, all blocks as of 1.8 should support transparency, meaning XRay resource packs, no longer work, at all.
“Only transparent blocks will now render as transparent (eliminates the use of x-ray texture packs)”
This is a quote from the 1.8 changelog, does this deter all X-raying or is it an incomplete fix?
@Jake_Kessler It only stops those that don’t code or use unique clients, meaning it only stops resource pack XRayers.
Thats another good point that @J_Triggs made there.
I doubt that this feature will stop modded or new unique clients from still X-Raying but it should stop the average person using the normal vanilla client.
- TangentSpy
That is what I assumed, that really sucks that they could not make a complete fix to the issue.
Why not leave antii-xray up to plugins?
Is xraying still a problem? I mean, I havent run any xray clients in awhile so I dont know what they’re currently capable of, but I have noticed a huge difference in vanilla world rendering that seems to make xraying a moot subject now. Even in spectator mode, flying underground you dont see any ores unless they are exposed to air.
Something important to note is that it’s almost never texture packs that are the problem but the actual xray mod.
1 Like
The whole point of an X-ray mod is changing that.
1 Like
The server really can’t stop XRay without changing the way chunks are communicated to the client. Since compatibility with default minecraft is a goal I think the only option would be for servers to enforce a signed
(and therefore unmodified) sponge client and that client only load mods requested by the server. It unfortunately cuts out a large population of users but would accomplish the goal on strict servers.
Would it not be possible to implement the same system that spigot uses for anti-xray?
Ore obfuscation relies on sending incorrect information to the client. The chunk is sent without ore, and then when the player gets near ore blocks, they are sent manually. There is a performance/accuracy tradeoff though.
For the API to support it, we would need an event when the server tries to send a chunk to the client.
CraftBukkit had a system where chunk processing for sending could be handled on another thread. That would probably be necessary too. They also had a way to send false block update messages.
1 Like
I think an orebfuscator feature in the SpongeAPI would be awesome, but if it means latency issues for servers and clients, I think it best be left to plugins so people can choose whether or not their server should have that trade off.
Although if there is a way to implement it into the base API without those issues, I think that’d be the best option. If there is a way to bypass the latency issues, I don’t know what it is.
Right, the API should just offer hooks for Plugins to handle the actual implementation.
1 Like