Jump to content

Alloc

Fun Pimps Staff
  • Posts

    1,538
  • Joined

  • Last visited

  • Days Won

    21

Everything posted by Alloc

  1. The fact just stems from the other fact that this is a public community driven Wiki (not something owned/run by TFP) where anyone can commit stuff to. And that Linux stuff was written by me too, not by TFP. Well, for one there is no Linux support in this game at all atm. Even if there was it was a matter of "./7DaysToDie.x86 -serverconfig <somepath>". There's actually nothing more to really run the server. But nobody wants to do that manually, caring for having the process going into background, manage PIDs, update engine, ... So why should anyone officially care about that? Also most people are happy with what there is mostly because it plain works. (And it's open so anyone can check what he's running as root ... and the game is never run as root). Btw, I have not seen a dedicated game server so far that provided anything more than the plain binary either. Only some community driven scripts. How about because I am the only one who cared to write up something at all? If you are so concerned about it there's no one stopping you from documenting that. And as I said before if there are any specific questions I might help out but I won't do another public documentation just for something that most people do not need anyway and in the end consists of a single program execution. Nope, packages do not go to "local". It's "local" for a reason. See e.g. the Linux Foundation on this or TLDP. Like some of the games that are often run by private people? Like Valve games? Which do not have more documentation than "run the executable"? This is just nonsense ... As I said before people want to run this thing, they don't want to set up their own infrastructure. Sure a few do, but they can just do it. What do you want to have documented as a completely manual setup besides "run the exe"? If it's manual there is nothing more to it, if you want scripts to help it ... well, I provided them with quite a bunch of documentation. Caring about security is ok, but at some point you have to trust others (e.g. what about the Linux engine files I provide? I could have tampered with them too ... And those are not even open source as they originally come from Unity). Running some management tasks as root is quite common too, the game is not run as root and the parts that do not have to be run as root will not be forever either (when I find a larger timeslot that is not used for more important stuff). Well, I think that's what I have to say on this topic. Also if you want to keep going this I would ask you to open a thread for that as right now this is cluttering this thread with offtopic. Kind regards, Chris
  2. Sure, SteamCMD does run fine that way ... but it's generally easier to access files that belong to a normal user than files owned by root. So I trust that ownership more than I would ever trust a normal user account. Also, if you use the same account to run the game as you do for installing it at least that user (and therefore the game itself) has access to the Steam account information -> security hole in the game leads to possible leak of your steam data (which is my highest concern) Well, sure I do ... and sure I could write about most of the stuff. But having that information as kind of a tutorial means you also get people using that which *always* leads to some people not knowing what they do. And that obviously leads to questions and hassle if something does not work as expected. You don't even want to know what kind of questions I got so far (though I don't mind at the time as I provide a tutorial so I provide the support if something does not work. Also those questions sometimes help to improve parts of it) Don't worry, I do respect that. I would not do myself if I was not easily able to check (or just did not want to bother spending that time) if the stuff is trustworhty Heh, there's always many ways to do something Considering parts of the supported actions only executable as root (excluding e.g. updating the game cause of the above mentioned points regarding account data confidentiality) might change in the future. Installing such stuff into /usr/local is what this part of a typical Linux directory tree is for though ;D Regards, Chris
  3. I do not mind suggestions at all Though I will only add stuff that is actually interesting for server administration, nothing that changes the behavior of the game in any way. E.g. I do not see any reason to add a command to heal someone unless anyone can tell me why that's important to admins (but of course you're free to add such things to your local build if you want to ). Anyway if you have an idea just post it and we'll see if that fits the purpose of this patch. Regards, Chris
  4. Hi pinkpagan, the scripts don't alter the behavior of the game (besides the server fixes but those don't really interfere with the *behavior* either). The only thing to be aware of is that updating the engine obviously can revert changes you did to the game's files. I haven't really worked with prefabs or any other modding stuff but don't changes to the XML files and such need to be done on the client too? Regarding the deletion of an instance: If you delete an instance by the 'instances delete' command it removes the whole instance folder. If that does not succeed (though I can not imagine any reason for that ) and the config.xml stays there this could happen. I do not see any other reason this port check could fail afterwards If that happens again please check if there were any errors when running delete instance or if the old instance folder still exists. Regards, Chris
  5. Hi tekkitan, I do understand your concerns. But right now there's just a few things that have to be run as root (e.g. engine-updating and alike as you would not want that a normal user account could read your Steam login data either ). So if you don't trust me and don't want to check the scripts you'll have to do it on your own (though you could obviously still look on the scripts how I do stuff ). Unfortunately writing just another manual on how to run everything manually is nothing I have the time for. Especially as more things could go wrong and then I would get questions on why something is not working and I could not even follow on what those people did exactly. I might be answering minor questions on specific topics of running the game on Linux but I won't write a complete howto for completely manual usage. Regards, Chris
  6. Glad you like it @all: To my shame I must admit that I made a mistake with the inventory-code. Looks like the previous release threw an exception if a player had multiple stacks of the same item in his inventory. .Net sees Lists as collections that cannot have a single key multiple times ... That's the way I notice I have only been working with .Net since last monday ;D Rev.98 fixes this and everything in it should be stable atm. Regards, Chris
  7. When helping av55545 with using this mod I noticed that I had made two mistakes (fixed in rev.96): I had only registered the new commands when the Telnet server was enabled I actually had used the client DLL ... too many DLLs on my PC So looks like noone else tried the stuff up to now? Would be happy for any feedback Regards, Chris
  8. Well, first of all: Your path suggest you tried to use it with the client. This would work if you patched the Assembly-CSharp yourself but you can not simply use the dedicated server's DLL with the client. If you put it in the dedi server and it still does not change anything there's another problem that I am not aware of right now Regards, Chris
  9. As this might be quite interesting for you admins out there: Just added a command "showinventory" which allows to look at the bagpack/belt of a given player.
  10. Hm, that one should already have the name fixes ... If that happens with v32 again please send me a snippet of the log (output_log.txt) with such a conflicting player's "Player connected" line.
  11. Which version of the scripts are you running? This should be fixed for a few revisions by now
  12. Just released v.32 which also includes the server fixes. @nolram: With the server fixes running you can query information with the "lpe" command as long as players are connected (e.g. on a regular base by cron and after they connected with a playerConnect hook).
  13. Thanks for the info DerPopo @Linux users: Just released a new version of the scripts which also integrates the server fixes. @All: As I'm posting anyway just a note: a new version of the server fixes is released. Regards, Chris
  14. Short answer is probably: no But I have been playing on a server for over a week which already uses the dedicated server build. And as that's the only difference for v.31 I would call it "stable" Regards, Chris
  15. As long as you use the exe and not the patched Assembly-CSharp it should be fine. If you want to use DerPopo's Assembly-CSharp you have to apply my patches manually.
  16. Just updated the files to rev.83. Release notes on the wiki page. I won't always post here from now on when I upload new revisions so if you're interested in updates check the wiki page every now and then. Regards, Chris
  17. Mostly. It does not allow to read sensitive data like passwords. This way you can allow normal users to run this command without fearing they could do anything bad but they would be able to check what e.g. LandClaimSize is on your server.
  18. Hi there, as it was always an annoyance to me that a) you have no chance to get the IP clients use and b) the Telnet part of the server was unstable and only allowed a single connection at a time I started a 7dtd-server-fixes project. I think this could be useful to anyone running a dedicated server Note that this only works with the new dedicated server build of 7dtd. I also added three new console commands (getgameprefs, gettime, listplayersextended). A more detailed information on what this project currently includes, where to download (both precompiled and sources), and release notes for future updates can be found on: https://7dtd.illy.bz/wiki/Server%20fixes Regards, Chris PS: People running a Linux server and using my scripts to manage it do not need to download this manually as I will integrate it in the next release of the scripts.
  19. Yup, locales shouldn't be a problem in the future anymore but have been in different places before Manually changing it should be ok, just make sure to stop the instance first.
  20. o.O Looks like locale setting is a problem here If you do not have done anything saved in that instance yet please delete the players.xml in the save game folder. /EDIT: Looks like deleting that players-file will do just two things: - Reset friendships - Remove landclaim-block <-> player associations
  21. Hmz ... locales ... Uploaded 30, please try that one.
  22. Could you send me one of the RequestToSpawnPlayer-lines of your <date>_output.log?
  23. Yeah, sure ^^ Ok, just to sum it up to this point: You have updated to scripts version 29 Restarted the instance after that Got nothing besides <date>_output.log, stdout.log and output_log.txt? <date>_output.log contains normal entries though? Also lines like "<datetime> RequestToSpawnPlayer ...."?
  24. That one is ok What about <date>_chat.log? Not even that one?
  25. Hm ... what about logs/<date>_players.log?
×
×
  • Create New...