Ohhhhhhhhhhhhh, I thought conf.json was telling it what port to run on. Ah well that's much easier then, thanks. EDIT: Yeah, I did a before and after netstat. D'oh.
Yep, the port change bit me to after an upgrade, and of course one needs to re-apply the change to the lobby again. I put a small detail page about my server @ http://planet.unfix.org this also renders the JSON that is published http://pastats.com/servers as a bit more directly readable HTML under http://planet.unfix.org/paservers/. As can be seen there though there are two servers: Planet Unfix & "24 Core Opteron at 2.6Ghz 32GB 10Gbit Server". The latter is apparently somebody in the CS department at University of Utah. Port number on that one is 20454, while mine is at 20545 (and that is also what is reported in this thread). I guess fixing it at something else with the --port argument to the server is a better way to go for the long run though to keep it in sync with the json file. Or possibly better, amend the script to force the --port argument to what is in the conf.json.
Yeah I thought of improving it to directly do --port with the port in the json by now as well. Someday soon... For now I am in the habit of always setting --port by hand
Just wanted to thank you for your superb work on this, Cola. I setup a server on Azure today with minimal hassle thanks to these instructions, would never have managed it without them.
I want to make my computer available as a server on PA stats, but all that tech stuff , any shortcut to the server setup?
wait for Uber to provide an easier way, I am sure the reason why it takes so long is because they are trying to make this stuff much easier than I do xD
So I'm trying to set up a VPS running Debian to host a PA server. Debian, unlike Ubuntu, does not come with the 'add-apt-repository' program. Apparently it is included in 'software-properties-common' (and/or 'python-software-properties'). However I have tried adding both of these, and when i run the second command @cola_colin lists, I still get bash: apt-get-repository: command not found Now, I am a bit of a Linux noob. I've used Ubuntu quite a b it on desktop machines, but not done a great deal of command line stuff. So still basically in noob territory. I know basic commands and whatnot. So yeah, I would appreciate some help!
That ppa is only for installing the go language on ubuntu. so replace following: sudo add-apt-repository ppa:duh/golang with : something that install's "go" on debian (google it)
Does not matter as golang is included in Debian. See post #30: https://forums.uberent.com/threads/wip-dedicated-servers.65077/page-2#post-1019398 You will have to use the 'unstable' branch though as some stuff needs golang 1.1 which is not in stable yet. (or mess around with apt-pinning, but why bother with that
I've written a slightly more user friendly guide on how to do this. Many, many thanks to Cola_Colin for the original instructions.
Awesome. That's not just slightly more user friendly. Though I don't think this is actually required: Then we update the permissions on the file and run it. chmod +x papatcher.go I just wrote that somewhere because I wasn't sure at the time and executed it without ever testing without. In setting up more servers over the recent days I could test skipping that and it seems to work fine. Basically go is a program that is executed and reads in the script file. So the file itself isn't executed I think. EDIT: Also while it is possible to up the max number of planets above 16 that will crash the texturing system on the client. By default that means a dead pa.exe. In that file I'd more look for the maximum size of the planets, the maxium height range and the fact that there is an if that removes waters from moons. All those limits can be removed there.
Thanks, I'll check those points and update the guide and have already put a disclaimer in about the planet limit.
When upgrading between versions, you might have to 'roll-back' the changes made manually, otherwise the checksums do not match and the patching fails. Hence, I just "rm -rf ~/.local" when upgrading. Note that post in my Post #30 there is also a init script for automatically starting the server at boot. (though, it might be that your version of Ubuntu already converted itself to non-init.d usage) You can skip it (setting executeable flag on the papatcher.go file). By calling "go run <filename>", you are asking 'go' to 'run' that file. Hence, the only bits that come into question is if 'go' can read the file (r bit) as the user you are running it at. The +x bit would have been useful if the first line of papatcher.go was Code: ///usr/bin/env go run $0 $@ ; exit then calling "./gopatcher.go" would translate to 'go run ./gopatcher.go' which gives the same effect.
I've seen such checksum errors before, but I don't think they are important. I though they just mean "the patcher detected this file is not what it should be (as a new version is available) and will now fix it"
I also ignored them, but then PA really did not work either; which might have been a fluke corrected by a retry and something else actually borking the real thing though. Is there btw a RSS feed somewhere or a notification email for new versions of the code, aka "please upgrade your server"? Otherwise I'll have start polling the update server once a day or so and generate a RSS feed myself for that.
There is some ubernet webservice that returns the current build version. I forgot the link, but it is very easy to reverse from PA or ask Pyrus in the pa irc. His bot's !patch asks the webservice.