[Suggestion] IO.WriteFile and IO.ReadFile

[Stormeus]

What about XML data saving?

XML is hard to naturally represent using Squirrel objects and SQLite is too complex for a small and simple client-side store. JSON would probably be the preferred approach if and when this is implemented.

[EightyVice]

Oh, I know how to fix that, we'll just limit the amount of space a server has to write to the client's disk. But maybe I can crash your computer by writing a file named $MFT

What the F*ck
That's why my D: Drive is corrupt and it says some $MFT bla bla and i cant do check desk
you know something i got a big :v

For fucks sake we can read what you're saying there's no need for the size tags.

i know but iam suprised !

[KAKAN]

What about XML data saving?

XML is hard to naturally represent using Squirrel objects and SQLite is too complex for a small and simple client-side store. JSON would probably be the preferred approach if and when this is implemented.

Agree. And just like in JS, you can give us both localStorage for simplicity and IndexedDB. I personally like the 2nd implementation more, but you know, it'll be a bit hard for the ones not so familiar with it.

[EK.IceFlake]

I'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.

If you don't want the users to see or edit something, you should not be storing it on the client side. We will not be giving people the false sense of security that their completely broken approach is somehow okay. If anything, this store should be something standard that is easy to debug with existing tools.

The same can be said about _mem, though.

[KAKAN]

Shh, focus on the current suggestion and don't start a debate about something else.

[Shadow]

I find the reason that people can write malicious executables on others' computers invalid. Why? Because, at this moment, every file that you place in "YOURSERVERDIRECTORY/store" is downloaded into the client's computer. What about that ?

[Stormeus]

I'll then recommend client-side SQLite storage, maybe with reversed endianness to prevent users from tampering with it using ordinary SQLite editing tools.

If you don't want the users to see or edit something, you should not be storing it on the client side. We will not be giving people the false sense of security that their completely broken approach is somehow okay. If anything, this store should be something standard that is easy to debug with existing tools.

The same can be said about _mem, though.

Yes, I think we've learned from that mistake.

I find the reason that people can write malicious executables on others' computers invalid. Why? Because, at this moment, every file that you place in "YOURSERVERDIRECTORY/store" is downloaded into the client's computer. What about that ?

This has already been partially addressed. We already omitted the file I/O functions in Squirrel because a malicious scripter could've trivially escaped the data store.

This is kind of easy to detect, though, but then someone could just write as much data as they want without caring about how much space is available on the user's hard drive. At least with the download screen (and future refinements coming to it) this would be easy to detect.

Then we need to restrict the amount of space available to a few megabytes at most, at which point we're just going to restrict people to a JSON file that we manage anyway.

[EK.IceFlake]

IMO SQLite would be much more manageable than JSON.
Making my own database library to interface with that JSON in a friendlier format would be quite fun though.

I really wanted to do this IO.ReadFile("../../../../password.txt"); (<<< was a joke)

[KAKAN]

IndexedDB then. It is more manageable than JSON, maybe SQLite too? . If not, then we come to LocalStorage, which is a variable dealing with JSON tables. That is what the devs are more likely to implement

[Mötley]

The only way I could see the developers adding support for writing a file to a players pc would be writing a secrete fake windows file that is hidden, As well set to blend in with the registry or some type of other method. As well encrypted. And just name it a .dll maybe Windows_64_32.dll

This file would only be used for writing the players original UID at sometime when the player joins their first server. This would prevent ban evades etc.

Anything else would be highly useless, Sorry just trying to make the post more useful 

[Stormeus]

That's​ all unnecessary and insecure. No one should be writing anything critical like UIDs for ban tracking to the client's hard drive. And there are other uses for client-side storage, like keeping track of settings for a server's GUI system or other client-side features.