1. Subject line pretty much says it all. I run a PvE server and would like to log various actions - some I announce in chat and those all work fine, but some I'd just like to log so I can review them later; like C4 usage.


    Thanks in advance!
     
  2. Wulf

    Wulf Community Admin

    For Rust, you can use the ConVar.Server.Log if you NEED a separate one, else just use the normal print() methods.
     
  3. Hi Wulf, thanks for the help - I was hoping to use the separate log file to send off to a web service but actually I see there is support for GET and POST requests from Oxide plugins.

    I might explore using these directly to collate the potential PvP actions. Do you know what would be least resource intensive? I was thinking I could collate the events to a variable and do a GET or POST request every minute or so.
     
  4. It sounds like you want to share state between multiple servers, a MySQL database used together with the builtin MySQL extension might be what you're looking for.
     
  5. Possibly, but would that involve installing/configuring stuff on the server? What I'm doing is logging various PvP actions to a web page that any user can look at and filter. Long term any PvE server would be able to use the plugin and see the actions online. There is a database at the web side but I don't really want to add too much complexity on the game server - as that will be a barrier to usage.

    The plugin is currently being written in Javascript - though I might get someone to rewrite it one day in whatever language is least resource intensive.
     
  6. You can host the database on your webserver and access it via the MySQL extension from your server.
    You'll have to host some service somewhere else in both cases - for webrequests you need to host a web server somewhere, for MySQL you need to host the MySQL service somewhere.
    I think a MySQL database is optimal for your problem. You're looking to share state, you only want to read that state when a user requests to read it, you want the database to be hosted at a remote location, not on the game server.
    Implementing this via POST requests is arguably more effort - mainly because you'll have to deal with your game server authenticating itself for the web server so it can POST updates to the web servers, while MySQL already provides this.
     
  7. Yeah - I already have a DB on the web server.

    I intended to keep auth simple as it's not like the data is sensitive. I'm not really sharing state as the data is in the form of text strings describing acts on the server e.g. 12:34:56 - Rebajas used some timed explosive OR 12:34:56 - Rebajas destroyed a wooden door. The idea is we might see patterns that indicate a raid based on what got destroyed, I might also add position data so I can see where on the map things have occurred - it's early days.

    If you still think mySQL is a route I should look at then great, it's another option for me to explore. Some links or JS code examples would be great. Otherwise I still think POST is a viable option, my main concern being server overhead and actually finding a JS POST example so I can get started :)

    Thanks.
     
  8. Well, there's barely any JS plugins and the doc is also very sparse.
    In most cases you can try to just translate the Python/C# code at this point.
    For MySQL you can read the MySQL extension page and my *Sync plugins and translate that to JS.
    If all you're looking to do is serve a log file on your webserver then POST is also a viable option, but the POST auth issue remains.
    You need the authentication so that random people are not able to POST log writes to your server.
     
  9. Sparse is the word! I don't mind muddling my way through with JS but I do think I will get this rewritten at a later date - so really this is a proof of concept right now.

    I appreciate why I need the auth, I'm just not so worried about that right now - The web site is HTTPS so at a later date the game server admin may have to get a key that is checked on the server on POST, as at some point I will need to know what data comes from what game server anyway. Does that sound sufficient for a start?
     
  10. HTTPS client authentication is probably the best solution for a simple web api client auth, yes.
    I'm just not sure if webrequests supports HTTPS, let alone client cert auth.
     
  11. lol - so I might be going up a deadend alley. I'll knock up a quick test based on what little docs I can find and see if it works.

    This is good fun... :)
     
  12. MySQL will probably end up being the easiest solution after all ;)