Just got a crash in a restarted server while clicking on an inventar of an online player (1 player online)
http://omega-zirkel.de/files/webcrash2016-04-27.log
http://omega-zirkel.de/files/webcrash2016-04-27.log
Native Linux server (with management scripts)
- Thread starter Alloc
- Start date
Nothing explicitly done there. Also see next quote:
There's no difference in how the Windows and Linux version work and now that Linux has 64 bit support that part is ruled out too. So if you experience a difference in stability or resource usage it's part of Unity. We tend to avoid code dedicated to one particular OS
No, has been asked before though, will probably add this.
Try sending a \n, not sure if it will work though. IIRC the UI components actually search for the string "\n" too (as in a backslash followed by a "n", not a newline character) so sending that might also work.
Try querying ".../static/index.html?yourparams". A GET request to the root directory results in a redirect and I assume that's where the params get lost.
Wrong thread, it's about the mod
It *could* be that it's Unity with threaded Texture2D usage, if that's the issue it will be fixed when the next game release (+ mod update, but that's already prepared) is out.
zigstum
New member
Thanks for clarifying, I heard whispers of a stability difference, but nothing concrete. It's good to hear from an official source so that I can rule that out of my enquiriesThere's no difference in how the Windows and Linux version work and now that Linux has 64 bit support that part is ruled out too. So if you experience a difference in stability or resource usage it's part of Unity. We tend to avoid code dedicated to one particular OS
Concerning the 64bit support, does this mean that the startserver.sh respects the results of the uname command? In the past, I had to rename the ".x86_64" to "x86" to get it to load the 64bit. The startserver script seemed to ignore my request for the 64bit executable. Also, when I used updateengine command, the 7daysToDieServer.xxx was not changed, with the renamed x86 executable remaining in the engine folder.I saw this change in the source files on your trac site, this is a welcome addition and will greatly reduce the amount of telnet connections needed, nice one
I had tried this first but with no success, however with the ability to chain commands together (I am about to install the updated serverfixes) this is not a problem.
I will have a look into this again later, thanks for the pointer
As always, thanks for your help
Zig.
-> Release notes:
Code:
v.97 (2016-03-27)
Use 64 bit server on 64 bit systemsHuh? There's just a ticket, nothing done yet ^^I saw this change in the source files on your trac site, this is a welcome addition and will greatly reduce the amount of telnet connections needed, nice one
Just tried it, sending "\n" (the exact two characters, *not* the newline character) works just fine.
blotavious
New member
Hello all:
Has something changed recently in the way the chat log works? All I see is "player joined," "player left" and "player died." No actual chat messages from players. This is also affecting the chat hook, which I use so players can send me emails if they need help and I am not in game.
Has something changed recently in the way the chat log works? All I see is "player joined," "player left" and "player died." No actual chat messages from players. This is also affecting the chat hook, which I use so players can send me emails if they need help and I am not in game.
zigstum
New member
I've had the chat problem too (now resolved), but I presumed it was my fault for breaking the install. I was moving to a new server so I thought it made sense to wait for a fresh install, but alas, the main problem persists - hook scripts in the playerConnect folder are not receiving the arguments that they did before, $2 $3 $4 $5 are all empty, but the instance variable $1 is given. If I missed something obvious (again), I apologise for taking your time Alloc. For reference, here is my join script:
The file greet.log:
The console output:
The hook scripts were working fine until a recent update (the change in GSMG: to CHAT: - 14.6 I think) would be great to get them working again before I open my new server, can you help Alloc?
Thanks,
Zig.
-------------EDIT
Another thing I noticed which may well be related is that the players.log is no longer recording steamids/names/ip addresses. Current log:
previous log:
(steamid/IP changed)
I remember reading somehwere that there was a new variable to be passed to the hook scripts - the ownerid variable for players that are sharing the game. I wonder if this is when it all went horribly wrong
------------EDIT AGAIN
More info that may be necessary:
Code:
#!/bin/bash
. /usr/local/lib/7dtd/common.sh
echo "1: $1 \n 2: $2 \n 3: $3 \n 4: $4 \n 5: $5 \n" >> /root/greet.log
telnetCommand $1 "sayplayer $4 \"[FFD700]Welcome $3![-] \""
Code:
1: test \n 2: \n 3: \n 4: \n 5: \n
Code:
INF Executing command 'sayplayer "[FFD700]Welcome !. [-]"' by Telnet from 127.0.0.1:38527Thanks,
Zig.
-------------EDIT
Another thing I noticed which may well be related is that the players.log is no longer recording steamids/names/ip addresses. Current log:
Code:
2016.05.18 13:22:08 +++
2016.05.18 13:51:19 --- 171
Code:
2016.05.01 00:52:44 +++ 231780 ⓢⓟⓘⓚⓔ3̷0̷0̷0̷1̷ Jalopy XXXXXXXXXXXX3702 XX.XX.XX.207
2016.05.01 00:54:09 --- 231780 ⓢⓟⓘⓚⓔ3̷0̷0̷0̷1̷ Jalopy XXXXXXXXXXXX3702I remember reading somehwere that there was a new variable to be passed to the hook scripts - the ownerid variable for players that are sharing the game. I wonder if this is when it all went horribly wrong
------------EDIT AGAIN
More info that may be necessary:
Code:
Game version: Alpha 14.6 (b26) Compatibility Version: Alpha 14.6
Mod Allocs command extensions: 8
Mod Allocs server fixes: 10
Mod Allocs MapRendering and Webinterface: 13
Mod Coppis command additions: 1
Last edited by a moderator:
blotavious
New member
Thanks Alloc!
SylenThunder
Community Moderator / IT Guru
Lately when I'm running the scripts, I get the following errors. I can't say for certain that I've never had them before, but I just started noticing as I'm still tinkering with this damn server build I've got going on.
In this particular instance, I'm attempting to update to the experimental_u52 version, which in the end, it doesn't actually do anyway since it just verifies the files without actually making any changes. I'll have to wipe the folders and re-install it to get the u52 build.
The assertion failures concerns me a bit though. I don't know if it's nothing, or if it's a sign of a deeper issue in my server I haven't noticed yet.
Oh, and just for reference. This is a clean Ubuntu 16.04 install with using this package.
P.S. Something else I noticed on the initial run. It looks like you added the pre-requisite installers into the initial build install.
Code:
root@7DTD:~# 7dtd.sh updateengine --experimentalLocal buildid: 1189196
Continue? (yn) y
Updating...
Redirecting stderr to '/root/Steam/logs/stderr.txt'
[ 0%] Checking for available updates...
[----] Verifying installation...
Steam Console Client (c) Valve Corporation
-- type 'quit' to exit --
Loading Steam API...applicationmanager.cpp (3091) : Assertion Failed: CApplicationManager::GetMountVolume: invalid index
applicationmanager.cpp (3091) : Assertion Failed: CApplicationManager::GetMountVolume: invalid index
applicationmanager.cpp (3242) : Assertion Failed: m_vecInstallBaseFolders.Count() > 0
Created shared memory when not owner SteamController_Shared_mem
OK.
Connecting anonymously to Steam Public...Logged in OK
Waiting for license info...OK
applicationmanager.cpp (3242) : Assertion Failed: m_vecInstallBaseFolders.Count() > 0
Update state (0x3) reconfiguring, progress: 0.00 (0 / 0)The assertion failures concerns me a bit though. I don't know if it's nothing, or if it's a sign of a deeper issue in my server I haven't noticed yet.
Oh, and just for reference. This is a clean Ubuntu 16.04 install with using this package.
P.S. Something else I noticed on the initial run. It looks like you added the pre-requisite installers into the initial build install.
SteamCMD stuff ... can't do much about it but will do a quick test with a fresh U1604 install later on. Were you trying to "update" from experimental to exp_u52 or no install to exp_u52? Did you actually change the scripts as by default u52 isn't used at all with the scripts?
Didn't get that one ... haven't changed anything in a looong time on the bootstrapper script.
SylenThunder
Community Moderator / IT Guru
I manually edited the scripts so that when I used --experimental, it would get the stable_u52 version.
I was getting that when I had wiped the Engine folder and was re-installing. Because for some reason, even using --force it only verifies the files, and does not actually install the different version.
That's odd with the bootstrapper. I swear when I ran it after the system wipe it ran the installers for the pre-requisites and they failed because they were already installed. I'll have to try that again this weekend.
So far I absolutely cannot run either the stable, or the experimental u52 version at all. (Not in 32-bit nor 64-bit) I've stuck with the stable 32-bit version for now. More experimentation is needed to figure out why the u52 builds cannot read xml files in 64-bit and give pulseaudio errors in 32-bit.
When a15 hits, I'll probably just have to give up hosting because I cannot afford newer hardware.
I was getting that when I had wiped the Engine folder and was re-installing. Because for some reason, even using --force it only verifies the files, and does not actually install the different version.
That's odd with the bootstrapper. I swear when I ran it after the system wipe it ran the installers for the pre-requisites and they failed because they were already installed. I'll have to try that again this weekend.
So far I absolutely cannot run either the stable, or the experimental u52 version at all. (Not in 32-bit nor 64-bit) I've stuck with the stable 32-bit version for now. More experimentation is needed to figure out why the u52 builds cannot read xml files in 64-bit and give pulseaudio errors in 32-bit.
When a15 hits, I'll probably just have to give up hosting because I cannot afford newer hardware.
Ah, ok, will try.
If SteamCMD is asked to validate the files it will also replace everything that doesn't match the selected branch. Meaning it should definitely "install" whatever you selected. Every other behaviour would be a bug in SteamCMD but I never got that to happen so far.
Yeah, the bootstrapper does install the prereqs on Debian based systems / systems using APT. But it's been that way for a looooong time now
Hm, will see if I get the same issue. Normally there should be absolutely no reason having to use the u52 builds for the dedicated build, especially on Linux.
Sorry about that part
Though I thought you could still run the 32 bit build just as before?