Very very valid concern Scottso. And one which I do not think a shared application with an open-source client can ever be perfectly armored against. But I think that there are a number of things which can be done to provide some decent "defense in depth", keeping in mind that the server(s) is not public. For obvious reasons, I will decline to go into details on a public board, but I would love to discuss my thoughts thus far in that regard with you if you are willing.

My greatest concern right now is handling any naturally-occurring "deletion" gracefully. Deliberate sabotage is a close second.

Well this is indeed a very valid concern.

This is why I have not to date released storm track to the public.

This is why you probably rarely see public shared db's as well. Guild only or group only would seem viable and a very worthy project if a guild could come up with the info for such a project.

This also has been one of the biggest delays in the client functionality to save data locally

I'd be interested to hear your thoughts on it in more detail, cspag. I have a few ideas after thinking about it for a bit.

One simple way to exchange data between all clients might be to send the data out over a specific chat channel. That way all the data can be collected by everyone's client and stored and processed locally. This way you a) have some sort of accountability because you can see who is sending the data, and b) you are not dependent on a third party server that might or might not go away some day.

Or maybe just have a third party server that holds a list of player names using the client who are online that are using the client and then have the client /msg everyone with an account on the third party server the data. If you require folks to "register" to use the shared functionality you'll at least have a real e-mail for everyone using it.

A third solution might be to delay updates to the db until you get the same update from x number of other unique players. For station information this should be acceptable since it doesn't change that often and everyone visits stations a lot. For something like tracking ion storms this probably wouldn't be feasible.

Even better would be if there was a way to anonymously tie a specific (ab)user to a specific account for blacklist purposes but I don't see how that could be implemented without help from the VO devs. Something like a lua function that gives back a hash unique to a specific game login and a lua function that can verify that the hash is valid. Like:

checkUserHash('*hash*'.. '*player name*')

which would return 1 if valid, 0 if not. (note that player name is the player's name in game not the actually account login). If the getUserHash() function only worked for your own login, which is easy to check for if you have access to the VO binary code, then this is a foolproof way to authenticate users from the lua side. As I said, though, this would require some coding from the devs. Not very much though. :)

Anyway, those are just some of my thoughts. Plenty of room to flesh them out.

Yeah, send it over a chat channel - a pirate's dream!

Kinda cool, while you get spammed, your current location is announced on a chat channel. That way the victim can't even call his friends using the same plugin for help because they all get spammed. Double win!

That's not really an issue I don't think. Nothing says the data transmission has to be real time. The clients can transmit the data every 15 or 30 or some configurable amount of minutes. So the dreamy pirate will know someone was at a station 20 or 30 minutes ago. If they are that desperate to find someone they will just be camping a wormhole anyway.

As far as spam, I haven't looked at it but I was going under the assumption there was a lua way to intercept the incoming chat text and not display it in the normal chat interface.

Anyway, I posted my thoughts here so people will poke holes. :) So keep poking.

Scottso, I will send you an email tonight (after I get home).
Blacknet, can you send me your email too please?

In general:
- Using email to verify users is not effective, as malicious users will just supply a "throw away" email. I also do not want to make the administration of this "manual" if we can possibly avoid it, as that becomes a nightmare very fast.
- Client-client direct communication via a chat channel is an interesting idea, but is "fraught with peril" of multiple sorts, I think it would be better to not go that way.
- Using an "external server" does run the risk of that server "going away" (or being "down" at inconvenient times). I think that we could mitigate that relatively easily, maybe by having more than one server, and allowing the "list of servers" to be pushed out from the servers.

More later...

yes you can easily exclude a specific channel from being displayed, but it requires modifying the interface code itself, so it can't be done with a plugin.

version 1.5 released. added /ta purge and saving data between sessions.

This simply doesn't seem to work on my computer very well.

Scottso's version 12c causes problems with the vendetta binary at logout. System notes are not updated and computer starts swapping like there is a huge memory leak/infinite allocation loop in the application. Once I also get a segmentation fault from the process without memory problems.

I didn't get this problem when I changed the system id to something small.. but nothing was saved to the file in that case at all. Issues were also "fixed" by commenting out the saving completely. Sounds like there is some "out of bounds" problem with system ID/content handling at the C++ side.

1.5 version from blacknet had some other issues at initialization that prevented also other plugins from working at all.

Edit: 12c problems were most likely caused by huge number of temporary objects (string concats) in output generation and crash by running out of memory when swap was not on. Massaging the saved string generation a bit made me able to exit the game.

crap. lemme fix that.

OK 1.6 fixes that issue.

What exactly did you change in 12c that made it (semi) work, JukiJulma? Just the system ID? Strange that memory issues would arise with string concats. The concats basically build the saved data file which, with every single station and all their contents in the game saved, is only 256K. That should hardly be enough to cause swaping never mind swap issues -- that's a pretty minuscule amount of data these days. Is anyone else seeing that problem? I can't reproduce it at all here.

Just changing the line
local savedSystemID = 71531
to a small value (like 1) didn't work. Nothing got saved.

The final contents of the string isn't that large. It's the intermediate string objects that get created in the process.
NEW_STRING = OLD_STRING .. SOMETHING_APPENDED still keeps the OLD_STRING in the memory even if NEW_STRING overwrites it in the variable (if I have understood Lua internals correctly). It stays in memory until the next garbage collection.

I just created smaller objects where it was possible:

elseif eventname == 'PLAYER_LOGGED_OUT' then
local stationData
local stationsData
local goodsData
stationsData = 'Stations:\n'
for k,v in pairs(TA.stations) do
stationsData = stationsData .. k ..'\n' .. TA.stations[k].sectorid..'\n' .. TA.stations[k].systemid..'\n' .. TA.stations[k].name..'\n'
end
goodsData = 'Goods:\n'
for k,v in pairs(TA.goods) do
goodsData = goodsData .. k..'\n' -- item name
local localgoodsData = '';
for l,w in pairs(TA.goods[k]) do
if type(w) == 'table' then
localgoodsData = localgoodsData .. ' '..l..'\n' .. ' '..(w.sell or ' ')..'\n'.. ' '..(w.buy or ' ')..'\n'
end
end
goodsData = goodsData .. localgoodsData .. TA.goods[k].mass..'\n' .. TA.goods[k].vol..'\n' .. TA.goods[k].type..'\n'
end
stationData = stationsData .. goodsData .. 'End.\n'
SaveSystemNotes(stationData,savedSystemID)

I'm not 100% sure that this caused my problems because just commenting out the "SaveSystemNotes(stationData,savedSystemID)" line also removed all the problems with the original code.. and all those temporary objects were created in that case as well.

What I can say for certain is that with no changes, VO would just take all my memory at the end.

Edit:
Correction. Something got saved to system1notes.txt:
error="Stations:\
1219585\
4764\
...

But of course the formatting is wrong so that the loading didn't work.

that is why you use local variables for any type of manipulation like that as the variable gets purged when the function or loop is terminated.

Ok I just released 1.7 version. I made a major fubar on 1.6 with the saving. Technically it was the loading when you enter the game. This version should fix that. Sorry about that.

Well it IS defined as a local variable. The only time you get all this data appending is at save time and then the client exits. I was not aware that lua copies the original string data during an append. That would seem to be a poor and very inefficient design.

All that said, if blacknet's version now saves locally, you should move to his anyway. I have no intention of maintaining this code going forward. I just wanted something that keeps the data persistent without having to load an external application and 12c was my quick fix.

On the OS X version of VO I'm getting the error "plugins/ta/main.lua:462: attempt to index field 'stations' (a nil value)" when I enter a station with 1.7 of TA installed.

screenshot here: http://farm4.static.flickr.com/3064/3037618250_2a9d07edec_o.png

That is a bug with the trade assistant. Remove it.

for some reason it's not getting the station id.

Ok I have fixed TA, version 1.8 is posted (here) it fixes the station table bug.