AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Jul 2016 08:10 PM |
I have two topics I'd like to see some discussion on regarding how DayZ works/runs.
1) Quantity of Zombies In a single DayZ server, there are a few thousands zombies. Not to mention all of the loot and players. Typically on Roblox that would make the game utterly unplayable. My question is with the tools on Roblox, how could this be achieved? Specifically the most intensive part of the process, tracking if zombies are close enough to players to engage.
With classic roblox zombies, every zombie has something like this: while wait(5) do if range <= distance then EatTheGuy() end end
The DayZ devs have spent a lot of time making that many zombies run at one. OTHER THAN work arounds like only spawning zombies within x amount of players, how could you check if people are in range nearly lag free? And even worse, raycasting if the zombie can see them.
I was just curious what creative solutions there are.
2) Inventories and anti-exploiting I posted this one in Game Design, but it's probably better to post it here. It's a lot of text. Post anything about it here though. https://forum.roblox.com/Forum/ShowPost.aspx?PostID=194789042 |
|
|
| Report Abuse |
|
|
|
| 31 Jul 2016 08:17 PM |
- 1 Group the zombies by some value (torso.Position.X in intervals of 50?) Then loop through the group on the client and add the ones that are near the player to workspace |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
| |
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
| |
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 31 Jul 2016 11:43 PM |
1) Like stated above, keep zombies indexed in a table, and loop through them to get the distance from players. If they're within a certain threshold, allow them to move.
2) Anti-Exploiting: Use FilteringEnabled. It's the best way to prevent exploiting. Don't listen to people who say "FilteringEnabled makes the game more laggy" or "FilteringEnabled won't stop exploiters", because they're wrong. FilteringEnabled doesn't add much more latency if done correctly, and it stops pretty much all exploiters (since they can't make changes on the client anymore). 2) Inventories: Keep track of the player's items in a table on the client, but validate every new item added on the server. Use RemoteEvents/RemoteFunctions to communicate with the clients with Filtering Enabled. Also, make sure you somehow validate the RemoteEvents/RemoteFunction calls, otherwise exploiters could possibly use them.
|
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Jul 2016 11:48 PM |
| Cuyler.. that's not really.. the answer.. to the question.. |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Jul 2016 11:50 PM |
| In the second post I was asking about an exploiter proof system using tracking and similar things, not how to use FE |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 31 Jul 2016 11:50 PM |
It is an answer. I'm not going to write code for either of those things, because it's too complicated to spend my time on just for a forum post. I answered how you could keep track of zombies and control them, how to stop exploiting, and also a way of communicating inventory from client <-> server.
|
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 31 Jul 2016 11:51 PM |
The only way to achieve "exploiter-proof" is FE. Don't think any other solution will work, because they won't.
|
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Jul 2016 11:54 PM |
I suppose I should've mentioned that I: 1) Have fairly advanced scripting knowledge 2) I use FE
Cuyler, you do know FE isn't enough? I'm asking for advice from people who might've done stuff like this before for specific methods for this context. |
|
|
| Report Abuse |
|
|
Lua_Virus
|
  |
| Joined: 13 Jul 2016 |
| Total Posts: 277 |
|
|
| 31 Jul 2016 11:55 PM |
@Cuyler
"(since they can't make changes on the client anymore)."
Do you mean on server? |
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 31 Jul 2016 11:58 PM |
| Also, just looping through a table and seeing if a zombie is in range is what I said would NOT work. In the original post I said you would need a smarter system than that to have thousands of zombies not lag kill the server. |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:05 AM |
I've dealt with FE countless times. Like I said, completely preventing exploiters in FE is possible, unless they have a server-sided exploit. If that is the case, then no matter what you do, it's unlikely you'll be able to stop them at all.
Anyways, there aren't any server-sided exploits currently that I know of. To prevent regular exploits from ruining your FE game, add a 'validation key' of some sort to your RemoteEvent fires or RemoteFunction invokes.
An example would be:
Server Script: local playerRequestedKeyTable = {}
local server_ValidationKey = game:GetService('HttpService'):GenerateGUID(false) remoteFunction.OnServerInvoke:connect(function(player, func, arguments, validationKey) if validationKey ~= server_ValidationKey then player:Kick() warn( ('%s sent an invoke request with an incorrect validation key! Validation Key supplied: %s | Function: %s | Arguments: %s'):format(tostring(player), tostring(validationKey), tostring(func), tostring(unpack(arguments))) ) else --//If correct validation key was sent, do stuff here end end
remoteEvent.OnServerEvent:connect(function(player, event, arguments, validationKey) if not playerRequestedKeyTable [player] and event == 'ValidationKey' then remoteEvent:FireClient(player, 'ValidationKeySend', server_ValidationKey) playerRequestedKeyTable[player] = true elseif validationKey ~= server_ValidationKey then player:Kick() warn( ('%s fired an event with an incorrect validation key! Validation Key supplied: %s | Event: %s | Arguments: %s'):format(tostring(player), tostring(validationKey), tostring(event), tostring(unpack(arguments))) ) elseif validationKey == server_ValidationKey then --//Do event stuff here end end)
-----------------------------------------
Get the idea? Basically on the localscript, you'd store the validaiton key once, then make sure you send it with event invoke/event you send to the server. Otherwise, the player would be kicked, because they would be considered exploiting.
|
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:06 AM |
@Lua, no I meant that when Filtering Enabled, any changes made on the client aren't replicated to the server.
|
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 01 Aug 2016 12:07 AM |
| Someone could intercept a validation code. |
|
|
| Report Abuse |
|
|
Lua_Virus
|
  |
| Joined: 13 Jul 2016 |
| Total Posts: 277 |
|
|
| 01 Aug 2016 12:08 AM |
@Cuyler
Well some of them are especially regarding character. People can still change their speed and teleport. |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:10 AM |
No, I highly doubt anyone would intercept your 'validation code' lol.. it's way too much effort for anyone to specifically learn how your validation works and create a work around for it. Besides, everything is compiled in Roblox's custom lua bytecode, so if you really wanted, you could do some tricky stuff on the client, like using the current time to encode the validation key and then decode it on the server.
Basically what I'm saying is, no matter what you do, if someone is determined to exploit your game, then they will. Most people have literally no idea how to exploit, they just use someone else's exploit themselves. FilteringEnabled and using some sort of RemoteObject validation will prevent 99.9% of exploiters at any place you have.
|
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 01 Aug 2016 12:14 AM |
No offense, but the fact that you keep talking about extremely basic filtering enabled facts shows me you probably don't know much about anti-exploiting.
By the way, any data stored on the client is readable and obtainable. Thus, the solutions I posted on my other forum are mostly server sided. |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:16 AM |
Alright, choose to believe what you want. If you're going to insult me, without knowing a single thing about me, and believe that your methods will produce better results, then go ahead. I doubt anyone else will produce 'useful' methods for you.
|
|
|
| Report Abuse |
|
|
Lua_Virus
|
  |
| Joined: 13 Jul 2016 |
| Total Posts: 277 |
|
|
| 01 Aug 2016 12:17 AM |
@Cuyler
The validate key thingy is BS tbh. You can easily get it as it's stored on Client. |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:20 AM |
If you really think people will attempt to find it, then just create a function that changes the validation key every few seconds. Have it randomize the length, so the variable on the client has to be reallocated. This will prevent it from being in the same place in memory.
If you have better methods, then why are you asking the forum?
|
|
|
| Report Abuse |
|
|
AntiFiter
|
  |
| Joined: 14 May 2009 |
| Total Posts: 12290 |
|
|
| 01 Aug 2016 12:22 AM |
Cuyler, I'm going to say this very nicely. You don't really understand how this works.
People WILL find flaws, and sending the validation key every few seconds means they can even more easily intercept it.
Still looking for input on my original post. |
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:24 AM |
Yeah, I definitely don't understand a thing about exploiting. The hat I'm wearing is totally not something I received for helping Roblox patch exploits. You're so much smarter than me when it comes to reverse engineering and preventing it.
|
|
|
| Report Abuse |
|
|
Cuyler
|
  |
| Joined: 27 Feb 2006 |
| Total Posts: 3784 |
|
|
| 01 Aug 2016 12:29 AM |
I don't normally get this worked up, but when you're asking for ways to prevent exploiting, and you insult the people who are attempting to help you, then I can't help it. I'm done replying to the thread. I hope you figure out a solution to your problem.
|
|
|
| Report Abuse |
|
|
|
| 01 Aug 2016 02:13 AM |
>wasting bandwidth sending keys ._. |
|
|
| Report Abuse |
|
|