[Suggestion] IO.WriteFile and IO.ReadFile

[EK.IceFlake]

Would be nice if we'd have some client-side storage-limited IO locked to the store folder.

null IO.WriteFile(string path_relative_to_the_store_directory, array<int> buffer);
array<int> IO.ReadFile(string path_relative_to_the_store_directory);

:edit: Files in store are cleared if they do not exist in the server's store directory every rejoin. Maybe VCMP/04beta/serverdata/ip-port.
:edit: Stream functionality like file in sqstdlib would be even better due to efficiency.

[KAKAN]

This was discussed before. I agree, we should be given a space of like 5MB to store our data in client side. But writing and reading files, never.

[EK.IceFlake]

But writing and reading files, never.

How else and why not?

[vito1]

How else and why not?

SQLite for example and security reasons.

[KAKAN]

localStorage or IndexedDB in JS standards. Something like that.
And for the other part, I said that it was discussed. So search it.

[EightyVice]

You read my mind about that , +1
but you know maybe it abused like making viruses and so on :v

[Stormeus]

We will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.

At best we could give a limited amount of space per server for a key/value store.

[EightyVice]

We will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.

At best we could give a limited amount of space per server for a key/value store.

What about making a folder for the files and disallow the way to reach to any folder and making specific extintions that can't be excited
Like bat exe vbs and so on?

[Stormeus]

We will never allow arbitrary client-side I/O since it can be abused to write malicious executables that automatically run when the player's computer is restarted.

At best we could give a limited amount of space per server for a key/value store.

What about making a folder for the files and disallow the way to reach to any folder and making specific extintions that can't be excited
Like bat exe vbs and so on?

Sure, I'll just surreptitiously write 500GB of data to your hard drive to exhaust it then.

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. In which case we can limit writing data to a specific file per server, or limit the types of data that can be written.

Now we're just at this suggestion:

we should be given a space of like 5MB to store our data in client side

localStorage or IndexedDB in JS standards. Something like that.

[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

[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.

[Xmair]

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.

[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.

Why would you store anything on the client-side that you can't trust the client not to modify?

[maxorator]

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.

[DizzasTeR]

What about XML data saving?