PAX prime 2012 video
Bitcrusher
Join Date: 2012-08-28 Member: 156628Members
Join Date: 2012-08-28 Member: 156628Members
<div class="IPBDescription">Natural Selection 2 developer panel!</div><a href="http://www.twitch.tv/pax2/b/330879441" target="_blank">http://www.twitch.tv/pax2/b/330879441</a>
Not sure if this has been posted already but it is a great video with the devs and the community.
Someone share this to other people.
<i>added topic description --Zaggy</i>
Not sure if this has been posted already but it is a great video with the devs and the community.
Someone share this to other people.
<i>added topic description --Zaggy</i>
Comments
Love the talk, impressive to see what a long hard road it has been and how much the community support means to them!
With regards to the crosshairs and other mods, I think the way the source engine handles it is by having a whitelist of files that can be modified by the client. There is really no way that you can modify crosshairs.dds to gain an advantage so if the clients file differs from the servers it's not a big deal. But obviously you can't allow all textures to be modified because if the skulk texture differs that could be seen as giving an advantage if it's easier to see.
Repeating myself from two other threads:
<!--quoteo(post=1970224:date=Sep 3 2012, 01:28 AM:name=Dghelneshi)--><div class='quotetop'>QUOTE (Dghelneshi @ Sep 3 2012, 01:28 AM) <a href="index.php?act=findpost&pid=1970224"><{POST_SNAPBACK}></a></div><div class='quotemain'><!--quotec-->I've talked a little bit about this in another thread but allowing even a single lua file to be modded is allowing cheating since the "game" part is not separate from the UI part (i.e. the UI has access to A LOT of information and functions that can be used to cheat). They would have to implement a second Lua VM to handle the UI to be able to separate those two by only giving the UI part access to very specific information.
Unfortunately, this is not an easy process and it actually poses another problem: The original UI needs access to some information that could be used for cheating, but it also should be able to be modified and replaced by mods... I wouldn't know any easy solution for this problem.
The only thing UWE can do for now is provide toggles and sliders for all sorts of stuff, which shouldn't be too much work to implement. I will not be able to play this game on my 5:4 screen if it doesn't have a FoV slider and NO I cannot buy a new monitor for another year or so.<!--QuoteEnd--></div><!--QuoteEEnd-->
With regards to the crosshairs and other mods, I think the way the source engine handles it is by having a whitelist of files that can be modified by the client. There is really no way that you can modify crosshairs.dds to gain an advantage so if the clients file differs from the servers it's not a big deal. But obviously you can't allow all textures to be modified because if the skulk texture differs that could be seen as giving an advantage if it's easier to see.<!--QuoteEnd--></div><!--QuoteEEnd-->
This works fine in source because it's not written in LUA and the code cannot be modified on the fl by the users. To my knowledge this is quite difficult to do in NS2 because the LUA files themselves don't limit the scope very well. As far as i've understood you have to blacklist modifications on pretty much every LUA file to prevent any kind of hacking because even one open LUA file gives you access to all the stuff defined in the other LUA files. Since i'm not very proficient with LUA and the codebase of NS2 feel free to prove me wrong.
The panel was great but i found it quite amusing that Hugh highlighted how NS2 is ready to be a great esports because of Insight but then Max and Brian acknowledged that they have no idea how to prevent cheating and hacking. Knowing that security is not something that you can easily add to a system after writing it and the fact that the release date is couple of days away i'm afraid that NS2 will be filled with hackers.
Hacking is a difficult one really, and I don't know much about how to programme. But from what I understand, it is basically impossible to prevent hackers if they really want to circumvent anti-hacking implementations. Aimbots are easy to spot, but wallhacks are something different. I remember a tool that was developed in part with enemydown.co.uk (UK league, now extremely quiet) that took random screenshots of your display view and uploaded them onto the server. So if there were any visual cues on screen they could be spotted by admins. But I think there are also ways around this.
I was actually one of the admins for this league, and everyone had to record demos. If there were doubts, I would have to watch the demos back and I often used hacking tools to try and work out if they were using hacks or not. Sometimes wallhacking was obvious, and a few were caught in videos that I made. Other times it was quite debatable.
I know for a fact that during its peak, CS 1.6 had a MASSIVE problem with hackers. But it did not stop it becoming the biggest thing since god.
The BIGGEST deterrent in my mind, was that if you were caught by VAC you were perm banned from playing on any server or at least for a certain amount of time. I think this drastically reduced people using them, otherwise you'd have to have several Steam accounts and re-buy the game. This actually happened to me when I forgot to remove the hacking tools from my folder and joined a public server, and I had to use a different account for a while.
As long as NS2 uses VAC and some consistency checks, all you need to do is produce a good game that just plays wells and just accept that cheating is an inevitable part of it. But I assure you that these people will eventually be caught, and regret it.
I'm sorry if they didn't. I was quite tired when watching it live, I guess i will have to watch this part again today. :)
You cant simply allow ppl to make modifications to the lua files(and a lot of other files), you basically need to block everything but stuff that is whitelisted in a database, somebody has to approve first with no additional modifications possible. (also in addition to that, the server operators need a way to exclude modifications that are in this whitelisted database, just because something isnt a cheat - doesnt mean you want to allow it)
The other option would be (at least for lua stuff) to have an additional lua vm for some parts (like the ui) that has very limited access. (since currently, the second you are allowed to modify one file in the main lua vm - you can access and do everything you want)
I have no programming experience at all(so its possible i wrote crap here) - but thats how i understand the problems.
Would love to go for a beer with Brian, makes me laugh just looking at him (no offence Brian).
The panel was great but i found it quite amusing that Hugh highlighted how NS2 is ready to be a great esports because of Insight but then Max and Brian acknowledged that they have no idea how to prevent cheating and hacking. Knowing that security is not something that you can easily add to a system after writing it and the fact that the release date is couple of days away i'm afraid that NS2 will be filled with hackers.<!--QuoteEnd--></div><!--QuoteEEnd-->
Agreed, consistency checks and VAC should be enough to stop most would be hackers and griefers.
And while you can't really prevent hacking 100% as evidenced by the fact that even CS:GO has has aimbotters, speedhackers and wallhackers since the beta.
Hell, I even bumped into a speedhacker/aimbotter in CS:GO just yesterday.
Luckily, the admin was around and banned him within minutes.
You cannot stop hardcore hackers from eventually doing this stuff, but you can make it really not worth their time if they get banned from all multiplayer by VAC upon being detected or reported with tangible proof like demos by community members.
~$30 down the drain just to grief a few games "for fun" isn't something most people would ever do, they'd much rather have fun playing the game.
Also, nice panel guys, I enjoyed all the insights into the indie development process.
Can't wait for that casper ghost catching mod.
Zeikko I know you already said you were tired and might have misunderstood that section, but it is worth me really driving the point home for other people: <i>I did not say that, or anything like that, and Brian and Max certainly did not say anything like that either.</i> What we all said was far more nuanced and really was the complete opposite. It would be well worth watching that section again.
Ok I watched it again now. The question is asked on 26:55 and the answers last about 4 minutes. I couldn't hear any mention about VAC. Pretty much the only technical explanation is that there will be consistency checks and that the problem with consistency checks with LUA is that you either have to close the game so much that even the UI can't be modded or you end up opening it so much that cheating is possible.
Hugh's answers (in the video) also make me to understand that the community should take the responsibility of creating admin tools keep the cheaters at bay. We have actually been thinking about adding ban database to ns2stats if cheating becomes a problem. Althought administering the bans, servers and admins, and all the drama around this kind of thing is kind of off putting.
What sort of lua mods would be considered fair though? You can change the crosshairs and hud by just editing the texture files, no lua required. I guess they could separate off a file for customizing the hud more than that or just provide more options in the menu. I don't really see any mods beyond basic hud and crosshairs changes being deemed to be "fair" anyway.
I imagine HUD and crosshair LUA files and art files will be separate so you can tweak them.
This has nothing to do with Lua. In Counter Strike you can't create a client side code mod and use it on a server that enforces consistency, can you? Like Source games, we can allow server operators to permit specific texture assets to be modified, if you wanted to tweak the cross hairs or the GUI for example. Also like a Source game, if we allow the client to run different code locally, you're opening up the possibility of cheating. As I mentioned in my answer, this isn't even limited to code mods you can gain unfair advantages just by allowing replacement of the player models (for example this: <a href="http://img.tomshardware.com/de/2007/05/13/cheaten-falsches-spiel/counter-strike-cheat-spike-modelsbig.jpg)" target="_blank">http://img.tomshardware.com/de/2007/05/13/...-modelsbig.jpg)</a>.
Lua does actually permit us to do some interesting things with regards to limiting what a client mod can do. Sandboxing is a common technique to run untrusted scripts (in this case it's not the host computer that doesn't trust the script, it's the server). The trick is giving the mods access to enough information to do interesting things, without allowing it to do things which allow cheating. A simple example would be to give client side UI mods the ability to access the local player entity and its weapons, but not anything else.
So, in summary, what we are planning on providing on release in the same basic consistency checking you get in Source games. If a server operator wants to allow clients to muck with their Lua, they can do that. But if you want to make sure nobody is getting an unfair advantage, you can also do that by enforcing consistency on all of those files. Most likely we will include an option to enable VAC on a server before release, but honestly I think the only reason that would be effective at limiting hardcore cheating is the threat of getting your account banned, not actually catching cheaters. Post release we'll be looking into ways of going beyond what other games allow and have players able to use cool UI mods in a safe way.
No, that's <i><b>not what I said either</b></i>. I said that the openness of Spark is not necessarily a total weakness, it is also in many ways a strength.
Anyone reading this thread should go and watch the video, instead of relying on the summaries of others. We were very candid, open, and honest during the panel hour. The people trying to distil us down into sound-bites and two sentence summaries are truly missing the nuance and detail with which we have answered complicated questions.
There is certainly a wealth of information beyond the four minutes spent talking about cheating, and how we are confident about containing it.
Great PAX panel. I had no idea mods were being made for this game (maybe I should go to the modding section?) like that light vs. dark one that was mentioned. It would be nice to have a game spearhead the return of the golden modding days. I don't have any useful talent, but I've messed around in the Spark map making tool and even I was able to create something that made me look good. I feel like if UWE can get the word out about how amazing their game design tools are they could really reap the benefits. Look at what DayZ has done for Bohemia Interactive. I would love for UWE to really benefit from how open they have been, hopefully setting an example for other game companies.
Lua does actually permit us to do some interesting things with regards to limiting what a client mod can do. Sandboxing is a common technique to run untrusted scripts (in this case it's not the host computer that doesn't trust the script, it's the server). The trick is giving the mods access to enough information to do interesting things, without allowing it to do things which allow cheating. A simple example would be to give client side UI mods the ability to access the local player entity and its weapons, but not anything else.
So, in summary, what we are planning on providing on release in the same basic consistency checking you get in Source games. If a server operator wants to allow clients to muck with their Lua, they can do that. But if you want to make sure nobody is getting an unfair advantage, you can also do that by enforcing consistency on all of those files. Most likely we will include an option to enable VAC on a server before release, but honestly I think the only reason that would be effective at limiting hardcore cheating is the threat of getting your account banned, not actually catching cheaters. Post release we'll be looking into ways of going beyond what other games allow and have players able to use cool UI mods in a safe way.<!--QuoteEnd--></div><!--QuoteEEnd-->
Thanks for the thorough answer Max. Yeah I know that hacking is not limited to lua, but consistency checking is easy way to prevent texture, model, etc. modifications while consistency checking LUA has some problems because it prevents users from making cosmetic non exploit changes as you said.
I don't quite get how the sandboxing will work in the server - client, lua environment but i hope it will turn out great. Looking good, i hope cheating will never become a major problem in ns2.
Hugh's answers (in the video) also make me to understand that the community should take the responsibility of creating admin tools keep the cheaters at bay. We have actually been thinking about adding ban database to ns2stats if cheating becomes a problem. Althought administering the bans, servers and admins, and all the drama around this kind of thing is kind of off putting.<!--QuoteEnd--></div><!--QuoteEEnd-->
It sounds like its largely up to the server admin, how much consistency checking goes on and if they want to slap on extra security features. Sounds fine.
I expect there will be a default list of files to check, or several sets perhaps of files to check.
Absolute - All files
Moderate - Check important files, most models.
Light - Check important files, don't check models.
None - Do not check anything.
I would be interested in something like this. I always found <a href="http://www.steambans.com/" target="_blank">Steambans</a> to reduce cheating/hacking frequency for the servers I'd play on for Source games. I've been hoping someone would implement something similar for NS2 (or get the Steamban people to support NS2).
Reading the FAQ, you only get banned in games with the same engine.
e.g. hacking in a source game will get you banned in
Counter-Strike: Source
Half-Life 2: Deathmatch
Day of Defeat: Source
Team Fortress 2
etc.
Hacking in gold source gets you banned in
Counter-Strike
Condition Zero
Ricochet
Day of Defeat
Team Fortress Classic
Half-Life: Deathmatch
Deathmatch Classic
etc.
It seems that it doesnt do that with any other games, even if the engine is more or less the same across games. (e.g. some CoD games etc.)
:/
edit2: Wouldnt ppl that cheat have extra steam accounts for their games then? (Guess at least inspecting ppls profiles gives you a hint if they might do something shady, even if they are not yet banned... i mean who has only 1 game in steam?)
Yup. Combined with community-made mods like the ENSL plugin for NS1.