Sorry, I misread that as “if they don’t know what THEIR IP address is.” My mistake.
But the core of this is that unless we do a survey asking ROBLOX users if they know what an IP address is, we can’t make accurate assumptions about their knowledge and it’s not really worthwhile to argue about it unless we have that information. Without it, we’re just playing a guessing game.
I have no idea how ROBLOX’s report system works, and I’m pretty sure you don’t either. I’ve heard them mention before that they want to make moderation more efficient, which is what led me to that idea. This also reminds me of another question I have about this - unless your playerbase was really small, how could you even feasibly keep up with the reports of exploiting/verbal abuse unless you had some kind of automated system to manage it? Wouldn’t it make more sense to just solve the (exploiting) problem once and for all by making your game more secure? And if you REALLY distrusted ROBLOX’s moderation system, you could also potentially make your own reporting system using datastore, and then sort through everything yourself.
[quote]
[quote]
They gauge the idea based on how many people want it added. If you want to point out “Hey this will negatively impact ROBLOX in X way” that’s perfectly fine. “Oh me personally well I don’t like this feature and I think others are important” is nonconstructive – if you like other features better then go bump back those threads or post a new feature request if there isn’t an existing thread. Expressing your distaste for a feature because you like other features better is not appropriate behavior. [/quote]
I don’t think ROBLOX has ever said they only consider how many people want a feature when considering it for implementation, and I NEVER said I only distaste this feature because I like other features more. I said that I don’t think it’d be a worthwhile effort to spend the time and resources to implement this feature because of what I stated before, when they could be working on a less flawed feature instead. There have been a few points raised about privacy concerns, multiple users using the same networking being banned, time investment, and alternative solutions. The core of my argument is that implementing this feature would NOT allow you to stop exploiters/abusive users from entering your games and causing trouble, because no matter what you do, even if you managed to meticulously go and ban each and every one, they could always subvert it.
I see two options:
A ) This gets implemented and then you have to manually or somehow automate the banning of users. This would probably be manageable for small games with not a lot of users (clan bases maybe?), but for large-scale games this would be a nightmare to try and keep up with. Technically literate banned users would still be able to bypass the ban. This would probably be easier to implement than porting a project over to FilteringEnabled, but it’s less secure and completely useless against somebody that knows their way around a computer.
B ) Fortify your project with additional security (FilteringEnabled, client-distrusting remotes, etc), and rely on ROBLOX for managing the verbal abuse of other players. This would result in your game being pretty much immune to exploits, you could add a flood check/filter/etc to chat, however you’d be at the mercy of the ROBLOX moderation system to deal with unsavory players. Personally, I haven’t had much of an issue with players harassing me on ROBLOX, and I’ve pretty much NEVER had it happen to me in-game. If somebody did decide to follow me around and harass me ingame, I’m able to just block them - easy.
Obviously, if this feature were implemented it wouldn’t negatively impact me - I don’t need it, so I just wouldn’t use it. I see where you’re coming from on that point. However, my whole argument is to say that this wouldn’t completely solve the problem and there are potential solutions already in the ROBLOX engine that you could be taking advantage of.
All of my games are FilteringEnabled. Exploiters are not my concern. Regardless of how large my game is, I can very easily tell if a specific person is causing havoc for my game. Even with the size of Club Boates, Josh was able to effortlessly pinpoint the person who was causing issues within his game – the same story with Rukiryo. If someone is going into my games and harassing my users, they’re going to get banned. This is something I and many others already do, and is not something we would only start doing if we could determine if a user had used the same network as another user. A yes/no answer on whether or not a person has used the same network as another user would make that existing process so much easier. FilteringEnabled solves my exploiter issue – the remaining problem is harassment, and this would allow the squashing of that. No amount of moderation is going to help improve that – you can’t realistically expect a small team of moderators to keep hundreds of thousands of players in check in an expedient manner. That’s something we as the place owners have to deal with ourselves, but we can’t deal with it ourselves easily unless we have access to a feature such as this.
The only reason I bring up this being a method of stopping some exploiters is because regardless of whether you can see it or not, it will undeniably stop a number of exploiters in non-FE games whose developers are otherwise incapable of dealing with them. Right now, there are absolutely zero ways for a developer of a non-FE game to combat exploiters. Being able to tell if someone used the same network as another will immediately crush all of the exploiters who got the exploit from their friends / a forum link. I used to exploit games with my friends in our petty 2,000 member clan, and I know how exploits can spread. You don’t have to be a genius to exploit. Not one person in our little ring would have been able to get around an IP ban at the time.
If somebody’s harassing you constantly, you could just type in “/block [username]” and then your problem is solved. Seems a lot easier to me. The same goes for your players - I think it would be more beneficial to make this command more apparent.
This is actually a really good point in favor of the feature, but those developers would still run into scalability issues. It’s easy to just ban somebody who’s obviously following you around causing problems, but if your game is riddled with exploiters it’d be a lot more difficult to take them all down.
I understand the idea but this kind of implementation would be really difficult to scale and still be bypassed. I feel like it’d make more sense as a website feature under the access tab of a game - you’d type in their username and it’d prevent them and anybody on their most recently used IP address from joining the game. This would result in 0 exposure of any kind of sensitive information to prying eyes and do the same thing (with the same flaws).
Yes, IPs can be constantly changing, and people can even change their own IPs if they have a static IP, but that doesn’t mean the whole idea is pointless. Just because it isn’t fail proof doesn’t mean it wouldn’t be effective.
There’s no point in applying the effort to implement a feature if it isn’t going to be effective enough. You guys need to build an argument. I’m telling you that your points aren’t strong enough.
IP detection is weak because many users have dynamic IPs, which can be changed easily.
MAC address detection is weak because changing a MAC address is trivial.
From these, we can initially assume that implementing this feature will not be effective. The next step is to gather data in an attempt to show the contrary. Find out how many exploiters are able to change their IPs or MACs on a whim. If the data shows that this feature would cut down a significant percentage of exploiters, then it you can conclude that it would be worth implementing. Have fun.
I have mastered the almighty technique of ignoring people – it’s not possible for someone to harass me. What they can do however is harass my players who aren’t so good at ignoring people.
The only way to prevent your game from being destroyed when exploits are widespread is to convert your game to FilteringEnabled – no potential feature can change that. What this feature can stop though are the pockets of users who pop up every now and repeatedly exploit the same place over and over outside of exploit season.
I do think a blacklist on the site is even better though. I would love to use that not only to prevent certain detrimental people from entering my places but also to restrict access to my places while they are under development. I would however say that a method to ban people in-game is still necessary. There would be no need to give any network information to the developer – just a :BanUser(userid) method so that you could reasonably allow others to ban people in-game without setting up your own web proxy to be able to contact via HTTPService and have that web proxy add them to the ban list on the site.
Or don’t even show people the hash. Just have an option in the place settings were all you have to do is put in the username. Or give us a function to do it.
Glossary: MAC-address
A MAC-address consists of 6 times 2 hexadecimal symbols, seperated by a hyphen.
For example is
A2-EB-72-07-C1-23
a MAC-address (the 16 hexadecimal symbols are 0, 1, …, E, F).
In opposion to an IP-address, it is not possible to rewrite a MAC-address - it’s burned by the fabric directly into the network card (in ROM). MAC-addresses are also called the physical address, because it is printed on the card physically. A special organisation, which purpose is to handle many internet questions, make sure that network card -producents don’t make use of the same MAC-addresses, when the network card are produced. There are 2[sup]48[/sup] different MAC-addresses (thus ca. 140.000 billion) - so there’s lots to take of.
Unless you go as far as having a ton of network cards, I can’t see how it’s trivial to change your MAC-address. Please explain
Google gives this as first result, it shows that it is a very trivial thing to do.
Besides, MAC addresses can vary between interfaces. The MAC address of your ethernet adapter does not have to be the same as your wireless adapter, etc.