Give us a way to save per-E2 information on a server permanently

[ghost]

with the use of the E2s hash ~ similiar to gTables except permanent in files

[oldmud0]

I still don't get it

[ghost]

think gTableSafe(N) but permanent

gTableSafe(N)   GT  Returns a safe gtable which group is a numerical hash
created from the code of the E2 itself. This is very useful in multiplayer games,
as it makes it impossible to edit the code in order to cheat (by giving yourself
infinite health or ammo etc) since the cheater will then be joining a different group
(edited E2 means different hash). 

[thegrb93]

Storing a hash of every e2 that gets placed is silly. What would this accomplish?

[TomyLobo]

@OpenToClose so basically you want to permanently store data to be read by identical code only, because otherwise the hash mismatches? I'm seeing a potential cleanup problem there

Maybe we can store that stuff in the sqlite database and attach a "last access" column that we update every time an E2 with that hash is spawned or destroyed. Then we could clean up old entries on every server startup.

[Divran]

I don't see a use for this. First off, E2 doesn't allow you to store files on the server at all. They're only stored on the client. Because of that, using a hash wouldn't protect against manual editing. And like @TomyLobo said, this feature would have cleanup problems too. What you want to do to solve this is to have the E2 read the file as usual and then when it communicates with other E2s is when you use the hash. If this is for a game where you want to store the player's progress to a file, then you can't reliably do that with E2's file library. You'd have to store the file online somewhere using the http library. I did notice that the original title to this issue thread was something about adding a hash to the http library? That's actually a much more useful feature. Only question is how would we do it? It'd have to be sent as a get or post parameter I believe, and we can't just override your get/post parameters. You still have to be able to set them using E2. Perhaps if we do a string.replace over a special string, like "%hash%" in the url?

[ghost]

@Divran Originally I changed the title because I believed it to be impossible to implement/or overridden by a user However now that you mention something akin to %hash% I believe that will actually make this a possibility

[oldmud0]

You're better off adding Pastebin support. Storing random stuff serverside can get very cluttered, which is why upload speed is purposefully very limited in Advanced Duplicator.

[ghost]

With pastebin support you cannot verify that a file was edited by a legitimate E2, per-E2 files serverside can only be edited by the respective E2 that created the file

I'm hopeful for the HTTP stuff above though

[Divran]

We're not going to allow E2 to store files on the server. It'd have to be really limited so people couldn't just fill up the server's entire hard drive with junk, and that makes it muuuch less useful than storing the files clientside.

[TomyLobo]

if you use the sqlite database, you shouldnt have too much trouble setting up a per-steamid limit, @Divran

[Divran]

Setting up limits isn't the problem, it's that there'd still be limits, for little gain - aka not worth it

[Nebual]

I wrote a basic serverside fileRead + fileWrite extension back in 2010, which my server has significantly used for a variety of use cases including an Autosaver E2 (powered by an Advdupe wrapper that's definitely too hacky to ever be released), a chip that replaces props in a contraption with appropriately-custom-modelled/colored/materialed/positioned holograms, a racetrack generator, a digital screen image format, several pathfinding projects, a banking system, an E2 code sharing system... most of which wouldn't have made sense to store clientside, either due to transfer times or the need for sharing between players.

How about a default-off serverside file storage extension, which limits a steamid to 100 files totaling < 10mb (okay fine those two can be convars)? So if 100 players come to your server solely for the purpose of filling your SSD, they've consumed a whopping 1gb, and you have 100 steamids to add to your bans.txt. Operations will cost hundreds of ops, to reduce abuse. You can flag a file as 'public', which allows others to read/write it - and the last player to write to it is the one whose quota is consumed. Quotas can probably just be kept in memory, flushed to disk (data/e2serverfiles/quotas.txt) periodically (on server shutdown + 10 seconds after the last write), and loaded on startup.

@Divran @AbigailBuccaneer Would that sort of approach be acceptable, or is this one doomed to stay in my private pile?

[Divran]

sounds ok I guess

[thegrb93]

This is what the file library is for