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 <[email protected]> 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: [email protected] > [mailto:[email protected]] 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" <[email protected]> > To: "'Half-Life dedicated Win32 server mailing list'" > <[email protected]> > 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 [email protected]. > > > _______________________________________________ > 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
