Right now, the SaveSystemNotes and LoadSystemNotes functions accept positive and negative numeric values. As the game itself probably won't ever have negatively numbered systems, I propose that if a negative value is provided by plugins, they can save/load to the root settings folder, instead of a character's specific folder, allowing plugins to not have to use the awkward file seeking method to load complex data across characters.

Rather than continuing to use the SystemNotes system, why not let us save to a specific file or series of files within the given plugin's directory? Any attempt to use a relative filename should be sanitized before file save begins.

Also, even Mario had the negative worlds. Perhaps negative numbers could represent sub-space or something. :)

This is something we could investigate. But, I want to be a bit cautious here, some platforms are getting increasingly restrictive about data storage and so on; and I also don't particularly want a plugin to go insane and fill up someone's harddrive (or phone, or whatever), or go nuts with disk I/O.

So, there might be some need for an API that manages a per-plugin quota, or some such. Which, obviously complicates it. Not sure, will think about it.

I would add that SystemNotes has been capable of going crazy and filling up someones harddrive and going nuts with I/O from the beginning, at least so long as the client doesn't timeout. So there is a sort of inherent limit to the damage a plugin can do already. Perhaps a plugin directory save should only be allowed when the player is online.

Yeah, I know it's been possible. But that doesn't actually mean much. I mean, it's also been sufficiently awkward, that that itself was a limiting factor (hence your Suggestion).

If we're going to create a proper system of file access, specific to Plugins, then we need to consider some of these ramifications.

Is it possible to have an in-game setting that allows users to set a limit on total space usage for such things? What a 'reasonable' amount is I have no idea.

We would probably define the limits, since we end up being responsible for them on platforms that are more.. picky about such things.

Anyway.. I don't know specifically what we'll do, or how quickly any of this will happen, but I will keep it in mind. We're looking at doing some maintenance on the Lua API, before long.

Stop storing notes locally, have a json structure, one per account and one per character, stored back at Guild software, and Guild can define the maximum size of each. Avoid all the ios and android nonsense as well as no longer tying the notes to the physical device. Maybe this will create a performance issue but I don't think so based on how fast the client currently can pull a character's entire inventory.

The lua client doesn't have to see it as a json structure, it would appear to be whatever lua normally does. I have more of a server-side perspective and I don't know lua.

That's a recipe for nastiness on multiple levels. I can understand the desire to have configs portable between devices, but if something goes wrong in the config data, what recourse would the average user have for deleting specific files in this case?

Also, some plugins are very write intensive (e.g. Targetless). Already the regular systemnotes write is pretty expensive. If you change that to a blocking network call, that's even worse. Especially when you consider users from around the world with less than good internet.

No, having plugin data stored remotely is a bad idea, unless handled by the plugin author.

Yeah, basically, what draugath says.

You can look at the Unknown System can get an idea of the future density of asteroids in the galaxy.. and that's just the beginning, it may get a lot denser with further changes to the renderer. The last thing I need is someone trying to read and write a hundred-million unique asteroid-scan-results to some networked location on the game server. People are welcome to keep that horror-show on their client device. Hell, even for our historical sectors.

I do support the notion of actually making Sector Notes be stored on the server, but it'll be well after we provide some alternate solution for plugin persistent-data, and we'll probably then limit the server-side notes to 1000 characters apiece or something. So they're just like.. actual sector-notes.

Maybe this will create a performance issue but I don't think so based on how fast the client currently can pull a character's entire inventory.

Also, this is all behind-the-scenes stuff that gets little one-line mentions in updates, but it's important to remember there's a lot of intelligence around the loading and movement of player inventories. There's pre-caching, data segmentation by locale, by type, data-streaming, checksums, various lazy-update techniques and other things going on.. all to make it as fast as possible.

Ultimately, there are ways to optimize the usage and movement of most data, if you understand what the data is and how it is accessed and used. But Plugin data is basically "whatever people want it to be", so now you're dealing with an open-ended block of mystery stuff that needs to be read and written really-fast to a remote network? That's going to be unpleasant.

The fact that some plugin authors don't really know what they're doing, from a programming standpoint, adds to the.. umm, exciting risk-flavor?

I accept that draugath and Incarnate know *way* more about how VO works than I do. In my mind's eye this data is only written to the server when the server wants to accept it, otherwise it's cached on the client. I would just add that the cache should not be written only when the client closes since that's when my client is most likely to crash. I think this is how the config file is handled and I end up adding binds by hand when the client is closed because of it.