Combatting Fullbright mods

Ive been thinking of a few ways to combat fullbright mods lately. The first suggestion to pop out at me was to use a blindness effect. However, after a bit of thinking, it was too gimmicky, and would probably be a bugtesting nightmare. (not to mention some mods could remove the effect clientside)

Another idea was to give a chance to not drop any ores if the block was 0 light level, but then again, ive mined in complete darkness before.

So, does anyone have any ideas so far? im currently going to implement some sort of block breaking average to watch for players that break unnatural numbers of blocks in 0 light, but thats not good enough... Anyone have any ideas?

 

Just throwing ideas out there with no awareness of plausibility, but can you obtain the light level the client is using to render a players screen either via a function call or utilizing packets? If you can get the expected light level from the server and the actual light level from the client then you should be able to easily catch the inconsistency.

again, I'm only speculating; I have no idea if you can obtain the light level the client is actually rendering at.

 

im fairly sure that would require spout :\

But that would be really really awesome.

Perhaps with the new bukkit API coming out? ?

 

how about drastically increasing the time it takes to mine blocks based on the light level?

 

You can't with the non-modified client. It's only a client option that the server doesn't need at all to work.

 

Well yeah but make it like you have to break it twice in a row or something.

 

This dog has a good idea

 

Well... think about the requirements. you'd have to keep track of which blocks have already been attempted to break, and considering that tons of people break stuff all the time...

 

well like you would have to break it right after the first time you did so there would be no long term logs.

 

One method I've seen for this is forcing players to use torches in dark areas by not allowing them to dig without a certain light level.

 

I thought about that too, but its easily passable, by just placing a torch whenever you see some ore you want :\

I think it would work well when implemented with other features, however...

 

Just throwing another idea out there... This isn't so much of a "fix" as a way to annoy people into mining properly. What you could do is add a random chance that every time they break a block in low light level that a monsters is spawned nearby and agro'd towards the miner.

So basically, if you spawn in full light you will mine worry free, but if you are mining in pitch black dark you will have an aggressive mobs spawn on you every so often. The simple fact that you will need to stop mining and defend yourself every 30 seconds or so would counter the speed benefits of mining in the dark.

Again, just throwing random ideas around, I like to see if they will stick to anything like pasta against the wall!

 

oh my.

I love this idea!

However, more on the topic of modifications, im really hoping that the new API gives developers more insight to the clients connected to the server. im hoping that we can see if there are modified clients, or even what the name of the mods are... Possibly. Thing is, that information is potentially spoofable too by modded clients.

So technically there needs to be some security feature that is incredibly dificult, if not impossible to crack, that can detect if the client is modified or not...

Gosh, this is sounding more and more like a pipe dream, isnt it? D:

._. i hate cheaters so much...

 

Not trying to burst your bubble, but I doubt that that will ever happen. The only way Bukkit could tell if it's a modified client, is by literally going through all of a person's files, invasion of privacy. Even if it navigated to %appdata%>blahblah... it's still invasion of privacy, and the bukkit everything will be shut down, and fined by US law.

 

hmm... i knew it was never gonna happen because it would be too good to be true... But i figured that this was similar to how VAC works...

Hmm.. If so, i guess that may be covered under steams ToS/EULA or something then... Dang..

oh woe is us

 

Well VAC scans the running processes not the files.

 

My mistake

ah well. guess theres not much to look forward to that i can think of then..

edit: wait a sec, how is that any less invasion of privacy?

 

It would actually be neat if you could make the scary sound which you hear when a dungeon is near to your position. For example:
Do sound -> player *probably* looks around, sees nothing -> second later spawn one or more mobs behind/in front of him. You shouldn't do this every time though as the player might already be prepared and run away. If he has this behavior and you don't spawn mobs one time he would've went away for nothing.

 

i guess now the only thing i need to figure out is how to find a location to spawn the mob

 

You could cancel the event if it is light level 0.

 

yeah but it can just get annoying and it will seem like lag

 

Get it to send them a message?

 

Please always read through the whole thread before posting to avoid duplicated posts:

 

When it comes to checking for modified clients, couldn't this be done by checking the bit size of the Minecraft.jar file? If the Minecraft.jar file is the exact same bit size as the released version then it has not been modified; but if the Minecraft.jar file is even 1 bit off then it has had some level of modification.

would this stop the issue all together... most likely not; but it would make modifying a client much more difficult and would knock out a massive chunk of the amateur hackers and only leave us with the more sophisticated ones to deal with; and all of this could be done introspectively, or from within the client itself(assuming it was added to vanilla) without touching any files on disk, hence no privacy invasion.

I have a strong feeling that these issues won't be nearly as common in the community once the official API is released because I think they are going to seal up the Client side of the modifying API tighter than a ducks butt, which they should...

If people want complete creative freedom to do what ever they want with the client/server they should go to spout, but for those of us who want stability over creative freedom I feel they should lock up client side modding and make everything that can be modified handled server side, and built the API for the server only.

 

Again, you couldn't because of privacy and all that. You can't look through people's files. AT ALL.

API will do a lot of this, it just means hackers won't use it. The client still has to contain things like events, info and packets to send, so the best hacks (the ones that use packets) will be doable anyway.

Spout will be as stable as the official API when it is finished.

 

but then what if its something like build craft and the person doesn't want to uninstall it just to connect to a server?

 

As stated in the above post (two above), it is invasion of privacy. I understand what you're getting at, and it's a REALLY good idea. Infact, I'm starting to wonder if it's truly invasion of privacy. If a user is sending more packets th en receiving, maybe don't allow them to connect? Not sure how that will work, but still.

Like you were trying to say, you can't actually check if a person has more bits on their client. It involves going to the person's minecraft file, which would, from there, cause the illegal things. See, some people like most of Bukkit would use it to solely keep out cheaters. Others...easily can modify to gain access to one's files, add/delete, etc.

Who knows where the future of Bukkit lies, for now this is out of the question, though.

 

aye, but what if the client sends US that data? instead of the server probing the client, the client gives the server the information.

edit: im not really bothering with this at the moment, its just an idea though

 

That was what I was getting at; I don't mean allow the the server to "comb" the Minecraft directory to gather the desired bit size, but to have an API within the client itself that has one and only one purpose, returning the bit size of the Minecraft.jar file to the server.

The server/administrator will have no access to the clients files... it will not be able to read or write anything, but simple call an API function that returns numeric size value.

Then on the server side you could compare the returned value from the client to what your plug-in assumes the size should be, which could be easily provided to the plugin by the same API that checks whether your Bukkit installation is current that was introduced in 1.2.1.

Honestly, this isn't far fetched; I believe this is exactly how the Bukkit auto updater determines whether your Bukkit version is outdated or not, it compares the bit size of your Bukkit.jar to that of the RB artifact.

I believe this could be easily done with absolutely no invasion, if and only if the client added this API to the client; otherwise I am just blowing smoke.

 

Father Of Time
Couldn't client mods just send a seemingly correct value?