PC Can't Download Steam Workshop Maps To Linux Server Made with LGSM- Item State is 8

[bviktor]

What I mean is that I just overwritten the file ~/Steam/KF2Server/Binaries/Win64/lib64/steamclient.so with the file ~/Steam/KF2Server/linux64/steamclient.so of my installation, and it worked so I don't know which is best. Mine seems less files modified so I would say is better

"Better" doesn't come from "simpler". Your solution won't track Steam updates, because it's a one-off copy, instead of linking to the original file that's being kept up-to-date. It'll become obsolete with the first Steam update. So I'd say it's clearly an inferior one. I could give you a oneliner command if that makes you feel better

In any case, there's no "good" solution we users can provide, since this will all break again with the very first integrity check, since the KF2 package contains checksums for the original (wrong) files. I'll modify killinuxfloor to enforce the symlinks with every (re)start, that's all I can do. So an integrity check will put the old wrong files back in place, then the starter script will remove them again and add links to Steam's .so again. Sounds stupid, doesn't it?

The actual solution to the problem would be Tripwire removing the bundled steamclient.so files (and I mean all of them) and relying exclusively on Steam's version. Bundling 3rd party libraries is a horrible practice, particularly so (pun intended) on Linux, and this has been common knowledge since the 90s. I could go on technicalities, but I'd rather not bore you with them, our current issue is a perfect demonstration on its own.

 

[®omano]

Replacing random files because there are three files with same name is no 'superior' it is bull**** in my opinion. The problematic file is the one pointed since post 10 https://forums.tripwireinteractive.c...76#post2331676
If you read and understood how Steam packages are distributed you wouldn't say that it "wouldn't track Steam updates" because obviously the files from package 1006 https://steamdb.info/depot/1006/ as shown are obviously up to date because are directly from the Steam official packages. So I don't know how you are reasoning but in my opinion modifying three files of the game (randomly as you modify three random files "because of name"), with an external file from another program (SteamCMD here or Steam client, not sure) is not good no, sorry.

So I insist, take the updated provided one shipped with server files, and replace the one outdated from server files. Simpler, better. But do as you want in the end you write you wikis as you want (even if it reflects your non understanding of the situation).

 

[bviktor]

Replacing random files because there are three files with same name is no 'superior' it is bull**** in my opinion. The problematic file is the one pointed since post 10 https://forums.tripwireinteractive.c...76#post2331676
If you read and understood how Steam packages are distributed you wouldn't say that it "wouldn't track Steam updates" because obviously the files from package 1006 https://steamdb.info/depot/1006/ as shown are obviously up to date because are directly from the Steam official packages. So I don't know how you are reasoning but in my opinion modifying three files of the game (randomly as you modify three random files "because of name"), with an external file from another program (SteamCMD here or Steam client, not sure) is not good no, sorry.

So I insist, take the updated provided one shipped with server files, and replace the one outdated from server files. Simpler, better. But do as you want in the end you write you wikis as you want (even if it reflects your non understanding of the situation).

I honestly don't give a flying f*ck about your opinion. Proper software deployment is not opinion-based. It's not up for debate, these are hard facts. I'm an IT professional with 8 years in the field, 5 years as a senior technical lead, I wrote my thesis around software deployment, I've been maintaining multi-platform projects for more than a decade, so I simply don't care what you believe is the "right thing". Your reasoning so far has been "it's safer cuz it touches only 1 file instead of 3, and I'm scared to make too many changes", or something along those lines. "seems less files modified so I would say is better" suddenly turned into something way more confident. Whatever dude.

You don't even understand why having FOUR different versions of the same library is a problem (you just call them "random files"), you can't even grasp the difference between copying a file and symlinking them, you believe your one-off copy will automagically stay up-to-date for whatever reason, so why am I wasting my time talking to you? I'm done. Do whatever you see fit, who the hell cares?

 

[®omano]

OK. I didn't write the tutorial.


Solution is replacing the game linux64 steamclient.so file with the up to date linux64 steamclient.so file
The up to date files are /steamclient.so (linux32 file probably) and linux64/steamclient.so (linux64 file probably) files from depot 1006 included in depot 232130 (the game server). The game linux64 outdated file is /Binaries/Win64/lib64/steamclient.so.

Solution: copy /linux64/steamclient.so (or symlink or whatever, that was not even relevant, I don't write wiki and tutorial) to /Binaries/Win64/lib64/steamclient.so to replace the outdated file with the up to date file.

Your solution: copy (or symlink or whatever we don't care as this is a temporary workaround until TWI get its game fixed) the steamclient.so file you find in your Steam(CMD) folder to replace all the steamclient.so file you find in the game server folder.


You're the IT expert dude.

 

[®omano]

UP! I did the usual flooding to TW people, still this issue is ignored when it is just replacing one file for Linux servers and 3 files for Windows servers. This is a real shame TWI, very very bad example on how to treat your community. You changed so much since the Early days. This is sad honestly. As I said in another thread your company is becoming garbage and all you see is dollars. Sad story.

Yoshiro
Kittenmittens
[TW]Ramm-Jaeger
[TW]Wilsonam

When you'll care to fix something, think about this multiple months old issue you lazy ~!$#*% NICE PEOPLE $*!ù*:#*!~ can't fix when it simply takes ONE MINUTE.

edit: see this thread too https://forums.tripwireinteractive....ustom-map-install-issue?p=2332748#post2332748

 

[bviktor]

UP! I did the usual flooding to TW people, still this issue is ignored when it is just replacing one file for Linux servers and 3 files for Windows servers. This is a real shame TWI, very very bad example on how to treat your community. You changed so much since the Early days. This is sad honestly. As I said in another thread your company is becoming garbage and all you see is dollars. Sad story.

Yoshiro
Kittenmittens
[TW]Ramm-Jaeger
[TW]Wilsonam

When you'll care to fix something, think about this multiple months old issue you lazy ~!$#*% NICE PEOPLE $*!ù*:#*!~ can't fix when it simply takes ONE MINUTE.

edit: see this thread too https://forums.tripwireinteractive.c...48#post2332748

Don't sweat it, bugs are rarely fixed I've been dealing with helpdesk people for a decade and a half, if you want something fixed, you almost always have to do it yourself. That's why I usually don't even bother reporting bugs. Because it's pure waste of time. If it's open source, I send patches, but that's not the case with KF2, so I can't do that.

There were instances where I reported multiple bugs for the software we paid for, but they didn't know how to fix it. After a few days I figured it out in their cr@p, and sent patches. They thanked for it and that's all. No discount, license extension, or anything Just "yay, thanks for doing our job, now, please move on".

Once I had an email convo going on with Intel agents about a server board issue for months, with lots of diagnostics and tests on my part, and when it finally got escalated to an engineer, he closed the case immediately like "oh, yeah, that's a regression, we know, please downgrade until further notice". Uh, thanks a lot?

This is purely a deployment issue, and most companies suck hard at that. Mostly because they consider it overhead. They're a game developer company after all... Oh well.