Alloc

That part looks just fine. Nothing after it?

Inventory search is a good idea, added to my list. Auto kick/ban could come with configuration later on, but probably only for really illegal stuff (e.g. by defining blocks that one could *never* get a hold on your server like bedrock). Yup, think so too. How do you expect this to work? Using developer mode is client side and the client is told by the server if he is allowed to enable DM. So if a client is not allowed but still gets it enabled that means the client is hacked. Do you really think someone who hacks the client to enable DM would send this information to the server? I recommend posting the whole log to something like pastebin.com so we can have a look. Remember to remove passwords from that file. You probably just downloaded the source, not the release. The source has to be compiled obviously to get an executable.

Haven't heard of such a problem before. Also don't see any reason why this should happen, the backup folders are just plain copies of the instance folder. Anything in the log after such crashes?

Just "protect", no extension or anything

See here under activation, part in bold

Yeah, something like that is only possible with a firewall, the .NET webserver classes do not allow to limit the access. Well, I could add an IP block later on the request handling itself of course but there's nothing like that for now

Nope, because using the current webfiles would fail when they do not have access to the API. What exactly do you want to achieve? Block all access to the web stuff? -> disable the web server by removing the webserver-folder Block all access to the API? -> web page won't work that way either, so see above Block access just for unauth users? -> enable authorization with the "protect" file Anything else? Tell me what

You know switching the server files won't stop people from using the API directly? So if you run a more recent version of the mod and do not have it set protected anyone who know about this can query e.g. the whole playerlist or claims. Public+protected access will be quite easy as soon as I switch to Steam auth but that's probably not gonna happen before a10.

Ignore those, they seem to not be causing any issues.

Rerendering won't help, the claims are taken from the game itself as you request the information on the page. The information is the same the game uses for land claims so if it does not show a claim the game won't know about that claim either. Maybe those people just didn't have their whole base within a claim zone? /EDIT: Just rechecked the code .. I'm using the same information from the game that is used to calculate the protection hardness for blocks when you hit something. So as said before: I doubt the shown data is incorrect, I would rather go with people not having every part of their base within claim zones.

Just ignore it for now Would have to adapt the code to load the favicon.ico from the static-folder, gonna do that in a later release. Would have to read the ToS first ... most frontend-services don't like to be used by other programs as their backend. E.g. my server got banned from SteamDB for querying the 7dtd gameinfo on a 2 minute interval

Last part of this post, and then these: one, two Not sure what exactly FRT was doing but I think he also just checks whether the process still exists. So in that case you will get the same level of detection the way described in those posts. Shouldn't crash that frequently though. Do you run an older save from pre 9.3 era?

Yep, this will probably become an option in a future release.

Yeah, you can simply ignore that one. The worst thing that could happen there is that the client (browser) does not get a file to display

Sure, don't mind.

There are overall improvements on the console handling coming up Not sure about quoting yet though. Hm, yeah, maybe I should remove the short form of rlp so such an action is protected against mistakes. The only thing it does is unload unused things. And that unloading is at least done whenever a client disconnects but also in a few other places where I did not find yet what triggers them. Yeah, will add that. Yup, currently caching is disabled so whenever a client requests one of the files it's directly read from disk.

Sure, both possible (and the latter one will definitely come). Maybe I'll just add a LLP near player in between. Added steamid to LP block display in the web map (just uploaded, webserver files only). Yup, the game can only modify blocks in chunks that are currently loaded. Will add a message to recheck with LLP after deleting to make sure everything has gone Hm, hate those "put three coordinates values in here" commands but I think that command variation might actually be helpful

That's happening whenever the remote end doesn't reply to netcat (used for the network "Telnet" client in the scripts). Wouldn't call this a safe indicator Though sorted out might be interesting for others with the same problem: Looks like the game uses a lot of file descriptors sometimes and by default a single process in most Linux distros may only open like 1000 files at once. Solution in qriff's post here

Well, that's why I wrote that back when you asked: I.e. you probably just got that case: Server process still running but not doing its job anymore. Currently no way to autodetect this.

Don't worry, there'll be an update soon™ Hm, even though paging sounds like a good idea in the current framework it would be annoying to implement. Isn't filtering the list (llp summary, llp <steamid> etc) not enough? I suppose until there is a real chat command implementation it doesn't help you much. Obviously it's a bit less work for the admin but on the other hand you can still send a message manually, have people reply (/join would work just fine ) and use "tele <other> <your>" to get them to you. One command per player, shouldn't be thaaaat problematic

Hi, can't tell you much on the network-deob part as that's by DerPopo but as there are no errors I'd assume it's fine. For the ManualDeob it's fine too, those 64 "failures" are from classes that don't have those methods so it's actually fine. Didn't come around to filter those yet Regards, Chris

Yup, the Deobfuscator needs UnityEngine and I think also SteamworksManaged.dll by now. Normally it should work with drag'n'dropping the AC#.dll on the executable but it looks like that's not always the case Well, that would definitely include client side changes, so not for now. But I think the new server browser might also include things like a server homepage

In chat: Not yet, that's just text for everyone right now. I assume you want it to be sent to others and they can click thank link? Or really open a browser just locally by typing "/url ..."? Hm, would have to see if that's possible, may require a client side change which would make it impossible for now. At least the last one means you don't have a deobfuscated DLL from the latest deobfuscator as the PackaqeQueue deobfuscation has been there since 0.3.1. The other two may just be different field names in your DLL (couldn't easily deob them so those are the only two that have to be checked each update ). Might be they would have the correct names if you update to the latest deob too as that could change field order because of the added deobfuscation for another field in the entities. If not use an assembly browser (e.g. the one from MonoDevelop) to look at the deobfuscated DLL, go to Command_listplayers.Run() and check which fields that reads for "id" and "remote".

It's an SVN so you can do an SVN checkout or grab an archived tree from http://websvn.illy.bz/listing.php?repname=7dtd&path=%2Fbinary-improvements%2F .

@leadingzero: You might also want to check this: http://www.allenconway.net/2012/01/fixing-systemiofileloadexception-upon.html