The VO.ini file tends to gather a lot of extra information over time. Too much in a lot of ways. Any corruption tends to cause a lot of problems and may even force its deletion resulting in a loss of important information. I know that some information can be stored via the sector notes but gkini is much easier to use and better suited to some types of information.

I was thinking that a plugin.ini file could be added by copying and renaming the gkini api functions to point to a different file.

Yeah, it would be good to be able to keep plugin configuration separate from game configuration, IMO. That would be useful to people who play on multiple pieces of hardware - I could copy the plugin.ini onto my laptop without worrying about that screwing up the video settings which differ from my desktop.

I just wanted to chime in and say that I'm not ignoring this topic, but I'm wanting to put some more thought into my reply since there are multiple factors to keep in mind when considering changes to how data is stored.

I ended up using systemnotes for my code because of limitations on gkini and what you can store there. Big spickled tables kind of exceed the line size limit.

I considered the system notes option but I already have 2 plug ins using them for data storage. Kind of worried there is going to be some interference eventually. The only remaining option is to use an offline data base which can add a lot of other complications...

There is actually very little chance of conflict between plugins that use system notes. The sheer range of numbers useable makes it highly unlikely for this to happen, unless it's done purposely. That aside, I think the best option is actually to try and provide some sort of interface to allow authors to write to a config file within their plugin's directory. I don't have any ideas on how this could feasibly be accomplished, though.

Well if gkini is used as a template it wouldnt be all that hard to use a fixed file name redirected to the plug in folder. It also would not be to hard to direct to a file named after the plug-in with ini as its extention.

io is disabled for a reason. To keep people from being malicious. Along with that, we have no way of associating a plugin with a specific folder.

This could probably be accomplished in some manner by extending the plugin loader, adding some sort of plugin definition file, and using metatables, but all in all, it's probably more work for ray than it's worth at this point.

I know that World of Warcraft has some method of associating a saved data file with a plugin, but I haven't looked into it at all. Further, while their API sandbox is a little more open in many regards, it's also a bit more restrictive in others. For instance, they can't use dofile(), for what it's worth, and loading of additional files is controlled by some sort of XML definition file and the plugin loader.

Perhaps you should review the sector notes functions....
We may not be able to associate a specific plug in to a specific folder at our level but the devs can do so easily.

If you think the sandbox prevents me from being malicious - think again.

I'm well aware of the potential to still be malicious with what we have. It just limits that ability. You can't go overwriting system files or other things.