Re: [hlds_linux] Red X'es
Here is another screenshot, http://i.imgur.com/coJUG.jpg still is a problem. On Tue, Aug 28, 2012 at 11:50 AM, Tom McClellan wrote: > if you ever played gmod with some one that has a wepon that you do not > have, you would know that red x's means you are missing a file or too. > > On Tue, Aug 28, 2012 at 1:32 AM, Michael Johansen wrote: >> >> What's weird is that I even tested this on a fresh tf2 server install, does >> nto happen on vanilla maps (valve maps) but I see it daily on my surf >> servers. >>> From: kyle.l...@gmail.com >>> Date: Tue, 28 Aug 2012 01:20:33 -0700 >>> To: hlds_linux@list.valvesoftware.com >>> Subject: Re: [hlds_linux] Red X'es >>> >>> While MvM may have made it more prominent in TF2, it didn't come with >>> that update. I've been seeing it since Pyromania, before that, all >>> seemed to be fine... >>> >>> http://cloud.steampowered.com/ugc/939249452348510719/ADB2CB1B3163FCEDBB7AAB4FD18965739A0C12CE/ >>> Mirror: http://i.imgur.com/vd4ea.jpg >>> >>> This isn't my screenshot, rather one posted on our forums dating July >>> 22nd 2012. If you see the Pool of red off to the right that's roughly >>> 22x16 Vortigaunts (Player sized), it's a rather common occurrence. >>> Yes, it's rather distracting. >>> >>> Thanks, >>> Kyle. >>> >>> On Tue, Aug 28, 2012 at 1:02 AM, Michael Johansen wrote: >>> > >>> > Its a issue with the damn MvM files, this happened after MvM. The >>> > particles precache is full or something. >>> > >>> >> From: kyle.l...@gmail.com >>> >> Date: Mon, 27 Aug 2012 19:52:13 -0700 >>> >> To: mreeu...@yahoo.com; hlds_linux@list.valvesoftware.com >>> >> Subject: Re: [hlds_linux] Red X'es >>> >> >>> >> Pretty sure it isn't any of those... Nothing installation wise has >>> >> changed on our server, yet the red X's appeared in CS:S 2 syncs ago. >>> >> Not that I can complain, but they're definitely present there as well. >>> >> We're not using Consistency or Pure. >>> >> >>> >> Thanks, >>> >> Kyle. >>> >> >>> >> On Mon, Aug 27, 2012 at 3:19 PM, Mart-Jan Reeuwijk >>> >> wrote: >>> >> > >>> >> > >>> >> > That is a issue of not hosting the models/skins etc (via whitelisting >>> >> > ). >>> >> > >>> >> > ..\steam\steamapps\*yourloginname*\team fortress 2\tf\ >>> >> > >>> >> > That folder has one or more of the folders: >>> >> > ..\materials\ >>> >> > ..\models\ >>> >> > ..\particles\ >>> >> > ..\scripts\ >>> >> > ..\sound\ >>> >> > >>> >> > Delete / move those and then start hosting. >>> >> > >>> >> > >>> >> > >>> >> >> >>> >> >> From: Tom McClellan >>> >> >>To: Half-Life dedicated Linux server mailing list >>> >> >> >>> >> >>Sent: Monday, 27 August 2012, 23:54 >>> >> >>Subject: Re: [hlds_linux] Red X'es >>> >> >> >>> >> >>Do a clean install of your server and client, that should fix it. the >>> >> >>red x's are from missing files. >>> >> >> >>> >> >>On Sat, Aug 25, 2012 at 2:43 PM, Michael Johansen >>> >> >>wrote: >>> >> >>> >>> >> >>> VALVE: Is there any updates on this? I would love to have it fixed >>> >> >>> without having to ask someone to code an extension to disable the >>> >> >>> precaching of MvM stuff. It still only happens on Surf. >>> >> >>> >>> >> From: michs...@live.no >>> >> To: hlds_linux@list.valvesoftware.com >>> >> Date: Thu, 23 Aug 2012 21:33:24 +0200 >>> >> Subject: Re: [hlds_linux] Red X'es >>> >> >>> >> >>> >> They seemed to work, but they didn't. >>> >> >>> >> > Date: Thu, 23 Aug 2012 13:59:53 +0100 >>> >> > From: f...@thehh.co.uk >>> >> > To: hlds_linux@list.valvesoftware.com >>> >> > Subject: Re: [hlds_linux] Red X'es >>> >> > >>> >> > Would you share the Stripper config you have for this? >>> >> > >>> >> > Thursday, August 23, 2012, 1:02:12 PM, you wrote: >>> >> > >>> >> > > I |think| I duct taped a fix for it, kinda. I used Stripper and >>> >> > > removed the particle showing. Idk if it works, but I have >>> >> > > gotten far >>> >> > > less reports about it. Still, VALVE NEEDS TO FIX IT! kthx >>> >> > >> From: michs...@live.no >>> >> > >> To: hlds_linux@list.valvesoftware.com >>> >> > >> Date: Wed, 22 Aug 2012 22:38:50 +0200 >>> >> > >> Subject: Re: [hlds_linux] Red X'es >>> >> > >>> >> > >>> >> > >> This issue is still here. >>> >> > >>> >> > >> > From: eliw...@gmail.com >>> >> > >> > Date: Wed, 22 Aug 2012 16:13:59 -0400 >>> >> > >> > To: cebceb7...@yahoo.com; hlds_linux@list.valvesoftware.com >>> >> > >> > Subject: Re: [hlds_linux] Red X'es >>> >> > >> > >>> >> > >> > "removing those clientside effects fixed the problem for >>> >> > >> > both me, and >>> >> > >> > everyone else playing on my server, oddly enough." >>> >> > >> > >>> >> > >> > There's nothing odd about that at all, your TF2 client *is* >>> >> > >> > the server in >>> >> > >> > this instance, so the server has different models than the >>>
Re: [hlds_linux] [hlds] Mandatory TF2 update coming later today
cant...keep...eyes..open..must..stay..awake...for...update... On Mon, Aug 20, 2012 at 9:04 PM, Aaron Thompson wrote: > Does this fix the crashes on linux? Almost all of my servers crash at least > once every day since last update. > > On Mon, Aug 20, 2012 at 7:25 PM, Fletcher Dunn > wrote: > >> The sounds will only be cached if the server is running an MvM map. >> >> -Original Message- >> From: hlds_linux-boun...@list.valvesoftware.com [mailto: >> hlds_linux-boun...@list.valvesoftware.com] On Behalf Of Ross Bemrose >> Sent: Monday, August 20, 2012 5:21 PM >> To: Half-Life dedicated Win32 server mailing list; Half-Life Linux >> dedicated server mailing list >> Subject: Re: [hlds_linux] [hlds] Mandatory TF2 update coming later today >> >> Will this also apply to the nearly-full soundprecache table? At the >> moment, it only has 320 free entries, which means some plugins will >> overflow it. >> >> On 8/20/2012 8:18 PM, Fletcher Dunn wrote: >> > >> > We're preparing an update that addresses the most important problems >> > people are experiencing: >> > >> > *String table overflow >> > >> > *Player counts in the server browser useless / meaningless in MvM >> > >> > *Server and client crash on map change when player was being healed by >> > dispenser >> > >> > *Matchmaking connecting players to out-of-date servers >> > >> > *General improvements to matchmaking throughput and match quality. >> > >> > This will be a mandatory update. >> > >> > Apologies for the late release. >> > >> > - Fletch >> > >> > >> > >> > ___ >> > To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> >> ___ >> To unsubscribe, edit your list preferences, or view the list archives, >> please visit: >> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux >> > ___ > To unsubscribe, edit your list preferences, or view the list archives, please > visit: > https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux ___ To unsubscribe, edit your list preferences, or view the list archives, please visit: https://list.valvesoftware.com/cgi-bin/mailman/listinfo/hlds_linux
Re: [hlds_linux] [hlds] TF MvM hosting questions
Actually, day two is already here. http://www.teamfortress.com/mvm/mercs/ Any ideas what the map names will be so we can setup some servers that will restart when the updates comes out and instantly load up on the new maps? On Tue, Aug 14, 2012 at 8:38 PM, doc wrote: >> True but there just is a limit to the amount of players you can support. >> Sure they could enable 64 players but it's completely broken, out of >> resources, not designed for that. >> >> There comes a time in brainstorming where you just have to draw the line. >> People were able to set up vs. Saxton Hale, and Prop Hunt, and all sorts of >> other fun gamemodes that didn't require a raising of what is essentially a >> hard limit. >> >> I feel like the people asking for more slots don't understand the many >> important reasons there is this "arbitrary" limit. I don't think this is >> Valve stomping on the server owner, if anything they've bent over backwards >> trying to keep the community modding and server operators happy. >> >> We haven't even been shown day 2 of MVM and people are >> already clamoring for the code behind MVM be changed to better fit all this >> crazy theorycrafting about what the gamemode MIGHT be like. >> >> On Tue, Aug 14, 2012 at 5:27 PM, Nomaan Ahmad wrote: >> >>> Class restriction was just an example... we need to experiment before you >>> can stay its rubbish tbh... >>> There are other things server operators can try but we need some unofficial >>> support to allow increased slots. >>> >>> Its up to the communities how they want their servers.. If you dont like >>> servers with more than 24 slots or you lag on them... simple, don't play on >>> them. If their servers are unbalanced or configured badly, I'm sure players >>> will leave and they wont have populated server anyway. Or do you carry on >>> playing on them? I know I don't... >>> >>> On 14 August 2012 23:33, dan wrote: >>> >>> > On 14/08/2012 22:40, Nomaan Ahmad wrote: >>> > >>> >> Some servers ops will know how to make it balanced... class limiting is >>> >> one >>> >> of them. >>> >> >>> > >>> > No they don't. Class limiting is a flawed approach. It suggests that if >>> > you assign forced roles that the game will be good. It won't be. It just >>> > means the 2 or 3 engineers you have will be halfwits and the one guy that >>> > can play engineer has to watch these halfwits in frustration. The only >>> time >>> > highlander and class limits works is when you have organised teams and >>> > matches and then you can say "Bill, you be the medic...John, you play >>> > engineer" and so on. >>> > >>> > Yes it sucks if you have 5 spies and 5 snipers on a team, but the truth >>> > is, forcing these guys to play a different class won't help. It's far >>> > better to let people play what class they want and use that data to see >>> > they are all buffoons. They'll see it when they lose and you'll see it >>> when >>> > you join so you can, if you want, just hit 'change server' and find a >>> round >>> > that will be better. >>> > >>> > Of course, from a server admin point of view the idea the best way to >>> find >>> > a good round is to hit 'change server' isn't that appealing, hence the >>> > flawed attempts to try and mess things around instead. >>> > >>> > You can't turn a buffoon into a good player by making him play a >>> different >>> > class, nor a team of buffoons into a good team using the same method. >>> > >>> > As I said in another post, generally speaking, increasing the number of >>> > players, reducing the number of shots you need to kill or removing the >>> > penalty for death are all designed to hide differences in skill between >>> > players and teams. >>> > >>> > Or in other words, people play on 32 man, instant spawn servers (and >>> Robin >>> > runs around with his OP rocket launcher or people pay saigns for silly >>> > weapons and abilities) because it helps hide the fact they suck. >>> > >>> > With 12v12 with respawn timers (and things like nocrit) you will see >>> which >>> > players on the server can play better than the others and which team is >>> > better - especially if both teams are motivated towards the objective. >>> > >>> > Their skill will be more evident (although as the comp players will tell >>> > you, 6v6 is better than 12v12 for that) But, unfortunately, it will >>> > generally result in average and below players spending a lot of time >>> > spectating and losing rounds. >>> > >>> > Which obviously for them is a worse experience than having a 3 hour round >>> > that no one wins (or that one team can trivially win because there are >>> some >>> > trivial ways to win with instant spawn, especially when you have weapons >>> > like the dead ringer) >>> > >>> > It's a lot easier to configure a server badly than it is to get better at >>> > playing it too. >>> > So it's no real surprise there's a player base happy to play on servers >>> > configured this way. >>> > >>> > >>> > -- >>> > Dan >>> > >>> > ___
