Factorio Forums

(I am posting here mainly to ask, has anyone else tried this yet? I don't want to be reinventing the wheel.)

I have decided I am fed up with how crappy and basically useless the administrator user management tools are, and so I am just going to make a wild blind stab at trying to find a solution myself.

I don't really know C/C++/LUA or all the data storage methods, so my code for this will likely be an inelegant mess. Maybe this will work. Maybe not. I am just going to try, and see what happens.

Hopefully this could be implemented entirely via control.lua so anyone can use this, including on vanilla games.



Method and potential problems:

• Log all the things, in a ridiculously huge memory buffer. There is apparently no way to write these event logs to disk and then just sequentially read_file("./temp/currently-playing/logfile",linenumber) the specific small data range that we want to show at this moment.
  
  Fine, whatever. I will try putting 10,000 to 100,000 lines of player event history in memory and just see what happens.
  • I have no idea what the memory limits are for indexed tables. I assume it is unbounded and really only limited by the player's local memory, and automatically saved into the savegame ZIP.
  • Since this is textual data with high repetition, it will likely compress 90% or more inside a savegame ZIP, so likely won't add much to the ZIP size sent to all players.
    • Tokenizing the event storage might save more memory without being verbose, though with added line display complexity. I am not worrying about this at the beginning.
• When the arbitrarily chosen event logging capacity limit is reached, either:
  • Loop back to the beginning and start overwriting old events in each player's event log
  • Nul each oldest event line in player's event log table, each time the table element counter adds new event lines to that table.
  ... I don't yet know what effect either of these choices have on garbage collection, which is always a performance killer. I am sure there are probably better ways to store data that an experienced LUA programmer would know.

• Splitting this logging to be separate for each player, rather than a single combined log of all players events, would make it easier to spot grief events in these logs. I will need another window for selecting the event histories for logged-on and logged-off players, in order of most recent logon/off event.
  • I also need to find a way to expire old data across these separate player eventlog tables, in a linear manner, as the memory storage limit is reached, new players join and new eventlog tables are created for those new players.
  • It is currently unknown to me if a player that set fire to or has used grenades on a factory object causes them to be assigned as the owner of it, before it is destroyed. This would be needed for separate player event log windows to work for item grief tracking with flamethrower/grenade.
• Looks like I'm going to have to fake up my own resizeable, moveable GUI window, that re-paginates when the number of visible lines changes.
  • I expect faking line-scrolling in a table array for every event via LUA is going to suck, so probably best to treat the logged data as pages and clear the frame when the bottom line is reached, as that eliminates scrolling refresh for every line.
  • Dynamic window resizing and dragging would be useful, but currently I have no idea if "MouseDown" cursor detection events are possible.

User interactions:

• Buttons at the top advance by page: Go to oldest page, back 1 page, back 10, back 100, forward 100, forward 10, forward 1, Go to newest page.
• When viewing old records, the progress bar shows where we are viewing in the log, acting as a scroll indicator. It is updated and adjusts, as new data is added and old event data is removed.
  • I don't yet know if a progress bar can act as an actual scroll bar, receiving clicks and reporting click position, then jumping to that log page relative to the click.

• Clicking the Show button to the left of event lines with coordinates, should have some way to highlight the affected tile or selection area.
  
  • Allow admins to instantly undo the actions of players, or immediately Kick or Ban them via the GUI.
    • Add new admin feature, Freeze, to temporarily lock suspected griefers in place and prevent any further actions, except writing messages in the console.
  • Player message: "Only admins can use Undo or Freeze/Kick/Ban buttons."
  • Player message: "You have been FROZEN by admin Plawerth. All actions except quit are blocked, but you can still talk."
  • Pop-up admin confirmation window: "Undoing this logged event will remove item(s) 'x' currently at this position. The game will be briefly paused, the object replaced, and original owner reassigned. Players in the way of the Undo, will be moved to the map spawn. Removed objects will be logged and can be restored. Continue?"

So, nothing too ambitious, really. Now let's see if this actually goes anywhere.

Sounds like a good idea, a couple of suggestions and points.
1) you can't get access to the system time, only the current tick. Rseding believes that it's "nondeterministic" because it's machine specific, much like keys being pressed or mouse movements.
2) Don't store the string. Create your own structure and store that. Will reduce the size immensely and you will already have to store this information anyway (to get the undo button to work).
3) A search by current location would also be beneficial as sometimes you get there and know that something is incorrect, but you can't quite remember what it should be like.
4) Search by event type, such as "damage" or "deconstruction", as you may not have been on the server when the griefing occurred.
5) Allow a custom maximum log length, or implement a purge-on-save mechanism (manual save that is).
6) Save the logs to a file that is automatically a mod script. Then if you really really want to see old events you can copy the disk "log" into your mod directory and load up your game with the entire history of events.
7) along with "undo" have a teleport button, so that you can go directly to the suspected griefing location.

You will be able to get it all done in LUA. Don't worry about the garbage collection aspect, the rate at which you will remove entries will be negligible compared to the rate that you will release other items such as strings, and that will be negligible compared to just doing the work you need to do. Storage space will be your biggest issue. Some of the controls aren't available directly in the game, such as the progress bar or a mouse resizable window (afaik). But all the other features should be there, with some creativity. For example, create a "tile highlight" entity that you can create & destroy for your mouse over location highlighting. It's an ambitious effort, so I wish you all the fun in the world.

*edit:
When an entity is destroyed you are given the player that did the damage in the event, so the grenades, guns, tanks etc are not an issue. I am not sure how this goes with fire however.

Depending on how far Undo logging goes, a question arises of what is even possible to track and log like this. Doing things the basic way as I am planning, the map may end up with duplicated objects and more items than it started with before the Undo.

Ideally deconstructed objects removed by robots would be tracked to the final inventories where they went and are removed from those inventories when placed back into the world. ..... But if enough time has passed, that object may have been taken out and placed somewhere else, so what to do then?

I am not going to worry about possible removed-item duplication when using Undo. The admin is not using Undo to cheat, but to repair griefer damage to the world.

If someone wants change my messy beginner code to get this ridiculous about inventory auditing during an Undo, that's their decision.

Also there is the question of merely Undoing the flagging for deconstruct, or also putting the object back if it has been removed by the bots.

Tracking huge swaths of bot deconstruction/construction by a player will greatly increase memory usage for this logging, and may make it unworkable. I don't know, will see what happens if/when I get that far.


I've already talked about this elsewhere, but I am probably going to see if there is some way to limit the maximum deconstruct or blueprint selection size or area. Furthermore, there may need to be a required time delay to use a blueprint or deconstruct again, to reduce the item logging rate.

So regular players will now have to use multiple blueprints for more than, oh, a 20x20 tile selection, and may have to wait 30 seconds before they use it again, but administrator blueprints and deconstructs are unlimited and not logged for Undo???

OMG, that's just .... uh, fine.

BenSeidel wrote:1) you can't get access to the system time, only the current tick. Rseding believes that it's "nondeterministic" because it's machine specific, much like keys being pressed or mouse movements.

And where is the current tick coming from when a new client joins? The server. So send the server's time in GMT along with the current tick to the clients. Send them both in the same network packet, even.

Wow, that was hard to solve.

While the undo feature would be nifty, it is not a replacement for autosaves & backups etc, so don't worry too much about an item's "lifetime". Also, don't worry too much about the actions an admin can take. Get the logging working the way you want and then crowdsource ideas. If you can find out the griefer it won't take long to ban most of them (mainly because the percentage of them in the community is really really small), and the finding is the hard part.

As for the "duplicate item" issue, simply take the (grieving) deconstructed item out of the admins inventory, printing a notification of the "missing" items. Likewise put any (grieving) constructed items into their inventory. if it's full, spill to ground, etc. There should be a solution for most things.
An additional form of griefing I have just thought of is deconstructing EXPENSIVE items, then logging out with them in your inventory. It's amazing how many level 3 modules you can carry and how crippling it is to a factory to have to make them all again. Without a "destruction" event whereby the entity is killed, restoring them could be seen as cheating.

Plawerth wrote:

BenSeidel wrote:1) you can't get access to the system time, only the current tick. Rseding believes that it's "nondeterministic" because it's machine specific, much like keys being pressed or mouse movements.

And where is the current tick coming from when a new client joins? The server. So send the server's time in GMT along with the current tick to the clients. Send them both in the same network packet, even.

Wow, that was hard to solve.

It's not solved, you still can't get access to it in the LUA script. so... go team?

BenSeidel wrote:An additional form of griefing I have just thought of is deconstructing EXPENSIVE items, then logging out with them in your inventory. It's amazing how many level 3 modules you can carry and how crippling it is to a factory to have to make them all again.

I believe there should be a way for the admin to see into the private inventory of any player, whether logged-on or off, and freely add or remove items as they wish. I am probably going to see if there's a way to do that here.

As part of the Undo process, it would be a good idea to be automatically checking for and removing high-value items such as laser turrets and enhancement modules from the logged-off player's inventory that removed them, to place back into the world and prevent duplication.


I'm sort of joking about the time thing, as that comment should really be directed at the game dev in question, not you.

please keep on your thinking about this we are always trying to arcvhive ideas there
i am happily adding your starting projekt there
viewtopic.php?f=6&t=42843

just start

collect everything and sort it by | tiles|x,y | used action | player | player owner | time code on the savegame

dont think about undoing yet we will get something out quickly!

Digging up an old thread. mewmew of ComfyFactorio has implemented this as an Admin panel on Fish Defender and other softmodded scenario based mods, using the Explosive Gaming softmod scenario User Interface...



Clicking on a line in the log opens a mini-window that zooms in on the location of the object to quickly see if it is grief or not.