200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 06:41 PM |
Link: http://www.roblox.com/Item.aspx?id=81501686
I made this so access to DataPersistence functions from a LocalScript is possible, it uses two scripts, DataHandler_Server and DataHandler_Client.
DataHandler_Client is the LocalScript that provides other LocalScripts access to DP by making a Data object under each player, and in that object there are two other objects named Load and Save, inside both of those there are the 4 types supported by DataPersistence, Instance, String, Number, and Bool.
DataHandler_Client has 3 important functions, shared.LocalData.Load, shared.LocalData.Save, and shared.LocalData.Ready.
shared.LocalData.Load is used to load data, it creates a value under player.Data.Load that DataHandler_Server then uses to load data from the player.
shared.LocalData.Save is used to save data, it creates a value under player.Data.Save that DataHandler_Server then uses to save data to the player.
shared.LocalData.Ready is used to get the players DataReady value.
More information is provided inside the scripts, read them, I provide the arguments for each function in there. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 07:23 PM |
Why would you ever do that?
You're literally inviting exploiters to exploit your game...
Data persistence is server side and there's a reason for that. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 07:29 PM |
Might as well stick a GUI in the beginning that says, "Hey exploiters! Click this button to change other people's stats!"
~Techboy6601: The IDE guy~ |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 08:17 PM |
| Then I will pass protect the functions and have the scripts put themselves in shared, and then delete themselves and loadstring them in other scripts so that noone can see the pass in them, and ill make it so when loading/saving the server side handler checks for the pass in each value. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 09:34 PM |
"Then I will pass protect the functions"
You completely don't understand how scripting works. |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 09:58 PM |
Lol... I mean that I would have an argument like
local scriptPass = "haiImAPassw0rd" function func(pass) if (pass == scriptPass) then --do stuff end end
Something like that |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:09 PM |
| ..I really don't see a point in this, this ought to be handled by the server. This just makes data management more complicated than is should be. |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 10:11 PM |
More complicated? This uses less functions and is easier to use then normal... |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:14 PM |
Ima go look at it, but from your description of it, it sounds more complicated than
player:SaveString("Keyhere","Oyus93") print(player:LoadString("Keyhere")) |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 10:16 PM |
It's not.
There's only 3 functions, 2 of them are save/load functions, and all that is extra is 2 arguments, player and type(string,number,etc)
That's all there is to it. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:19 PM |
You wrote 300 lines to replace 8
LoadBoolean LoadNumber LoadString LoadInstance SaveBoolean SaveNumber SaveString SaveInstance
As well as created security holes in your place. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:20 PM |
| You wrote decent code and all, don't get me wrong, but honestly it is not the most practical thing. |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:21 PM |
| DonnyTheDemented pretty much summed it up. |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 10:44 PM |
The only damage to security I'm noted of is admittedly pretty bad, and that is the fact that it's now easy for exploiters to edit stats, but with my script-hideing and pass idea I can fix that.
What else? |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 10:49 PM |
I skip your script and write directly to player.Data.Save and stuff, skipping your local script, tricking your server script.
Why is it that you want to use this so much? It seems to be much more work (since you will have to add patches, and edit your previous code) than it's worth. |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 10:56 PM |
@Donny That will be fixed with along with my script hiding and pass-protecting fix.
And, I don't really want to use it that much, I really don't know why I'm defending it so much, I see that it is really more trouble then it's worth. I do love the idea of it though, but I probably wont spend too much more time on it.
I guess I just didn't like the immediate down-bringing of my script. :P |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 11:01 PM |
Constructive criticism is the best kind.
http://www.roblox.com/Forum/ShowPost.aspx?PostID=54863281
Now that is bad, thankfully, Julien shot me down and explained why what I was thinking was wrong.
Your code was good, just misdirected and we were trying to point this out before you invested more time in/made more of it :P |
|
|
| Report Abuse |
|
|
|
| 22 May 2012 11:11 PM |
Really, trying to edit data persistence on the client side is just wrong.
Even if you made a completely flawless system to do it, you still shouldn't do it.
Just because it's wrong.
Just like you shouldn't award badges on the client.
The ROBLOX developers have not made that possible and there are many reasons.
One of them, and probably the most important, is security. But it's not only about security, it's also just that data persistence and badges are things that are clearly related to a place. They communicate with ROBLOX's servers and they are clearly not related to the clients at all.
It's just better to keep them on the server side. It's just better like that. It's just.. supposed to be like that.
What is on the server side should be kept on the server side.
However, if you really need to make clients able to communicate and share values with the server for some reason, that's completely possible and reasonable.
For example, if you want, for some reason, to save the camera's position when the player leaves, the right thing to do is not to make the client save it. The right thing to do is to create a CFrame value or a Vector3 value and to give the camera's position to the server so it can save it.
That way, the server is still doing all of it and it is a server script that decides what the key is and what kind of value will be saved. And there is no security flaw either.
However, giving the power to the client to save values is just the wrong way to do it. |
|
|
| Report Abuse |
|
|
200AB
|
  |
| Joined: 24 Aug 2010 |
| Total Posts: 1604 |
|
|
| 22 May 2012 11:20 PM |
@julien
Ah, I see why you are against this now. |
|
|
| Report Abuse |
|
|
Quenty
|
  |
| Joined: 03 Sep 2009 |
| Total Posts: 9316 |
|
|
| 23 May 2012 12:16 AM |
| Yeh. Crazyman32 has a system where you just connect his function to a function when you instance a new 'Value'. |
|
|
| Report Abuse |
|
|