Same here. The second I updated and restarted the server no errors and players on it.
Steven Sumichrast schrieb: > I just did an update to my Killing Floor Linux servers and they > received a single binary file update (the ucc-bin-real file), and now > my servers are not throwing that error about STEAMSTATS any longer. > Looks like we're operational. > > On Mon, May 18, 2009 at 9:08 AM, John Gibson > <j...@tripwireinteractive.com> wrote: > >>>> I'll once again apologize for the headache this caused, and let you >>>> >> know >> >>>> this won't be done again. >>>> >>>> One final thing though, please please please do NOT do this: >>>> >>>> [ROFirstRun] >>>> ROFirstRun=9999 >>>> >>>> That will definitely cause problems in the future as that setting is >>>> used by the engine not only to update ini settings but also do some >>>> other things behind the scene in the engine when versions change. >>>> Messing with that number will almost certainly cause with a server at >>>> some point when we update in the future. >>>> >>> Unfortunately from a GSP point of view its the only way to ensure that >>> future updates dont break things. If you want to discuss this off list >>> give me a shout, but suffice to say we had exactly the same issues with >>> Epic's UT3 and in the end they understood the issue and provided a few >>> nice command line options to prevent this "auto upgrade" and other >>> things breaking in a commercial environment. >>> >> If you don't want the first autoupdate to run, set your ini like this: >> >> [ROFirstRun] >> ROFirstRun=1085 >> >> 1085 is the current version with the one time force update for the inis, >> so anything greater than 1084 will never get force updated. Having >> worked with UE3 I'll say that the ini system is completely different. In >> UE2.5, if you update the default.ini the game.ini will not get updated >> unless it is deleted. In UE3 if you update the default.ini, the game.ini >> WILL get force updated with the new defaults. >> >> In the end it's your decision what you do with this value, but we won't >> be able to support any issues you get from setting this to 9999. In >> other words, change it at your own risk ;) >> >> Thanks, >> >> John Gibson >> President >> Tripwire Interactive LLC >> >> -----Original Message----- >> From: hlds-boun...@list.valvesoftware.com >> [mailto:hlds-boun...@list.valvesoftware.com] On Behalf Of Steven >> Hartland >> Sent: Sunday, May 17, 2009 8:24 PM >> To: Half-Life dedicated Win32 server mailing list >> Subject: Re: [hlds] Required Killing Floor Server Update Released >> >> >> ----- Original Message ----- >> From: "John Gibson" <j...@tripwireinteractive.com> >> To: "'Half-Life dedicated Win32 server mailing list'" >> <h...@list.valvesoftware.com> >> Sent: Sunday, May 17, 2009 11:16 PM >> Subject: Re: [hlds] Required Killing Floor Server Update Released >> >> >> >>> Thanks for the feedback Steven and I completely agree with you. This >>> >> was >> >>> a one time thing we did to address the issue we had with less >>> >> proactive >> >>> server hosts than yourself as well as an issue where a development >>> version of the server's ini files got released before they were >>> >> cleared >> >>> for broad distribution. Essentially we had about 70% of the servers >>> >> put >> >>> up by server admins on the first day using the defaults (you know >>> >> those >> >>> servers that said "Killing Floor Server") that were incorrect. Fans >>> >> were >> >>> getting really angry that all the servers were Easy/Short. >>> >> Understood, documenting the changes and making it clear how the updated >> defaults are applied would be the best solution to this in that case :) >> >> >>> We do use an inherited config system, in a sense that KillingFloor.ini >>> will always inherit its settings from Default.ini. The problem was, >>> >> that >> >>> while we were still testing the server builds, the non-final version >>> >> of >> >>> the server got shipped and announced to the HLDS list. Thus the >>> Default.ini settings were wrong, and even if we updated the >>> >> Default.ini >> >>> (which we did), all the servers had already inherited the wrong >>> >> settings >> >>> (including some non gameplay changing settings that were causing >>> >> servers >> >>> to not show up right in the browser). And our inherited ini system >>> >> will >> >>> not override KillingFloor.ini unless an admin deletes it and starts >>> >> over >> >>> Thus we had to do the one time force update to get everyone up to the >>> official release version of the ini settings in their Default.ini and >>> KillingFloor.ini. >>> >> I think your misunderstanding my use of inherited config system. I >> believe >> what your talking about there is a template system not an inherited >> config >> system, which is why you had the issue. In a true inherited config >> system >> you would only have the changes in the file the user edited so things >> like >> player count, server name etc. >> >> Don't get me wrong I know your just working with how the engine was >> designed, >> just pointing out some design changes in this area could make things >> much >> easier for you and for admins. As I'm sure you'll appreciate there is a >> hell >> of a lot of stuff in the current config which will never or should never >> be >> edited. >> >> If you up for a challenge I can give you a full spec / list of all the >> issues >> in the UE config system for the version your using. >> >> >>> I'll once again apologize for the headache this caused, and let you >>> >> know >> >>> this won't be done again. >>> >>> One final thing though, please please please do NOT do this: >>> >>> [ROFirstRun] >>> ROFirstRun=9999 >>> >>> That will definitely cause problems in the future as that setting is >>> used by the engine not only to update ini settings but also do some >>> other things behind the scene in the engine when versions change. >>> Messing with that number will almost certainly cause with a server at >>> some point when we update in the future. >>> >> Unfortunately from a GSP point of view its the only way to ensure that >> future updates dont break things. If you want to discuss this off list >> give me a shout, but suffice to say we had exactly the same issues with >> Epic's UT3 and in the end they understood the issue and provided a few >> nice command line options to prevent this "auto upgrade" and other >> things breaking in a commercial environment. >> >> Regards >> Steve >> >> ================================================ >> This e.mail is private and confidential between Multiplay (UK) Ltd. and >> the person or entity to whom it is addressed. In the event of >> misdirection, the recipient is prohibited from using, copying, printing >> or otherwise disseminating it or any information contained in it. >> >> In the event of misdirection, illegible or incomplete transmission >> please telephone +44 845 868 1337 >> or return the E.mail to postmas...@multiplay.co.uk. >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds >> >> >> _______________________________________________ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> http://list.valvesoftware.com/mailman/listinfo/hlds >> >> > > _______________________________________________ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > http://list.valvesoftware.com/mailman/listinfo/hlds_linux > > _______________________________________________ To unsubscribe, edit your list preferences, or view the list archives, please visit: http://list.valvesoftware.com/mailman/listinfo/hlds_linux
