Rushnut wrote:

The main supporting counter argument is just simple "NOT MANY PEOPLE WILL USE IT"

I think that's a pretty good argument; it's likely very few would use it, if it's framed in terms of Member storage. I just don't see it being a common thing for people to want to upload files from a game environment to their Member storage.

As far as having some kind of limited per-game file storage for stuff like savefiles, that kind of thing would be used a lot--but I could see it being subject to some abuse, not to mention developers who don't take care with their savefiles will have some awfully big ones (due to saving icons, overlays, etc.). A game with many players could have thousands of savefiles, and that could become an issue over time. Nevertheless I think there's some merit to considering that. This would be very similar to client-side savefiles except only servers would have access, and only then with the correct hub password, so that could theoretically be a much more secure way to share files across servers.

Pretty sure in the entire time we had hubfiles it was used less than 10 times. Not quite the same thing as what is proposed here, so carry on.

Honestly the single biggest reason I'd use this feature would be for savefiles, although maybe you're right about icons being too large. Would it not be possible to just save a refrence to what the icon should be in the game? I don't know, I don't do real programming. I just dick around on DM all day.


As for other applications, the potential is practically limitless, it would remove the entire need to differentiate between a lot of client or server features, because the game could draw from common assets that could be changed whenever, I mean stating this makes me feel like I'm saying the obvious, the applications of server storage that is easily accessible via Import() and Export(), that isn't an outside source to BYOND (And therefor far more difficult and/or expensive to implement) are practically obvious and staring people in the face.

I mean, I accept that I'm biased but when you say it was removed because it wasn't used, my only explanation is that you "marketed" it as being something just for email games, as opposed to just centralized game storage that games can access.

If you tell me straight up that people wouldn't use this feature if it were implemented, I'm afraid I'd have to laugh and then probably scoff in your general direction.


As for the actual application, the reason I suggested BYOND membership storage space is because it's already there and implemented, and easy to hook into, albeit slightly wonky with passwords and the suchlike. However seeing as only BYOND members can make hubs now anyway (Although we keep being told the concept of a hub is being done away with, which doesn't help the situation) I don't see why hubs can't have their own allocated storage. It wouldn't have to be much, heck you could even pull it from the BYOND membership to offset the total hard storage required.

From there it's pretty straightforward, Import()/Export() could have an arg for hubFiles, and if 1 it would directly try to pull/push a file from the world.hub, using the world.hub_password for verification.

The applications for such a feature speak for themselves and shine, and would ultimately help BYOND's multiplayer structure by a pretty hefty magnitude, whilst not being relatively difficult to implement.

Thinking about this - some sort of file based system would be nice.

Although I prefer database storage - one thing I haven't been able to get around is having a hard coded value in order to create or retrieve my connection string details. If there were something (such as the HUB) that was able to provide this, then it would make it a much more fluid system for being able to load the settings of each server.

To combat space requirements, I would think it is possible to determine if the save file contains any image data. It wouldn't be the end of the world if files containing this data were rejected, and it would probably move people into the more conserving 'store only what you need' methods.

I could see the need for specific metadata in order to prevent errors (maybe a referenced ckey, last writen, checked out by [address]), and would be nice to allow for a lock file option (with timeout) in order to prevent race conditions. [preventing writes but not reads]