I also gave my write up on debugging de_nuke_ve a couple of weeks ago...

It was trying to download non-existent resources from my working fast DL
server. Details reattached herein. But this was a slightly older build, so
things may have changed. In summary my advise was to steer clear from this
map. Good to know the advice was ... ignored! ;)

Fair play on your apology... the original rant was thoroughly comedy and
tragic at the same time. Maybe the moral of the story here is to read old
posts before going off on one.

- Nick


-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Rodrigo
Peña
Sent: 15 September 2012 16:56
To: [email protected]
Subject: Re: [Csgo_servers] custom maps: everyone disconnected on map change
despite sv_pure 0

I posted the solution to this bug weeks ago:

"Finally I've found the problem in loading custom maps in CSGO servers.

I've been making a map, and when you start CSGO with -stringtables to save
the stringtables dictionary to BSP file, later the server won't let the
client download the map, so the solution to load custom maps is to not have
the stringtables dictionary built to them, just ignore the warning about
having maps being distributed without stringtables until Valve fixes the
problem"



-Rodrigo


On 15-09-2012 11:28, Tackdriver wrote:
> Well as it turns out, the person who suggested I try a different 
> custom map was CORRECT to suggest that de_nuke_ve WAS the problem.
>
> I reproduced what all the players were seeing by renaming my local 
> copy of the map to de_nuke_ve.bsp.hide, and connecting to the server.  
> This should have made the server re-serve me the map.
>
> I am posting this because
>
>   1) I was wrong about de_nuke_ve and need to admit it.  I already 
> know I'm a tool, BTW.  But occasionally I do know what I'm talking about.
>
>   2) because there are a LOT of posts on the steam forums piling up 
> after yesterday's update about people getting stuck on loading screens 
> that they never saw before.  Others saying they saw it before, but 
> it's a LOT worse now.  Custom maps are an issue, and like I said, I 
> never had problems with this map before yesterday's update.  So for 
> others having problems like I and others have described, and will 
> describe further below, here are symptoms of the problem that (as 
> absurdminds suggested) are a good indication of a custom map that just
isn't going to play nice.
>
> SYMPTOMS
> (Setting out to determine whether de_nuke_ve was the problem or not)
>
> 1. On my local game client, I renamed my local copy of de_nuke_ve.bsp 
> to de_nuke_ve.bsp.hide, which should have made my local client 
> re-download the map when the server switched to it.
>
> 2. Switched the server to de_nuke_ve.
>
> 3. Saw the new "default" loading screen on client.  Progress bar stuck 
> at somewhere around 20%.  For 10+ minutes.
>
> 4. Server says I'm on, but all I see is a loading screen on the game.
>
> 5. Developer console on game client shows a lot of rebuilding string 
> table hex dump data like:
>
> -------------------------------
> Counter-Strike: Global Offensive
> Map: de_nuke_ve
> Players: 1 (0 bots) / 37 humans
> Build: 5058
> Server Number: 3
>
> SignalXWriteOpportunity(3)
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 156
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 154
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 145
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 143
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 139
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 131
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 173
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 170
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 163
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 167
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 169
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 181
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 267
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 269
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 299
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 297
> CNetworkStringTable::ParseUpdate: NULL pEntry, table modelprecache, 
> index 299 failed processing
>   Dumping messages for channel CLIENT(x.x.x.x:27015) 0x20E5D740 Header 
> bits 104, flags == 177
> 19 messages
> 0 -----------------------
> svc_Print: type( 16 ) group ( 0 ) size ( 2068 bytes ), startbit 6 end bit
910
>     svc_Print: "
> Counter-Strike: Global Offensive
> Map: de_nuke_ve
> Players: 1 (0 bots) / 37 humans
> Build: 5058
> Server Number: 3
>
> "
> RAW(svc_Print) start
> svc_Print  >>  .e.....@ `.D..Cou 1465f70a 00000000 40d7e520 60eae207
> 44f0c109 0a436f75
> svc_Print  >>  nter-Strike: Global Offe 6e746572 2d537472 696b653a 
> 20476c6f 62616c20 4f666665 svc_Print  >>  nsive.Map: de_nuke_ve.Pl 
> 6e736976 650a4d61 703a2064
> 655f6e75 6b655f76 650a506c
> svc_Print  >>  ayers: 1 (0 bots) / 37 h 61796572 733a2031 20283020
> 626f7473 29202f20 33372068
> svc_Print  >>  umans.Build: 5058.Server 756d616e 730a4275 696c643a
> 20353035 380a5365 72766572
> svc_Print  >>   Number: 3.............. 204e756d 6265723a 20330a0a
> 00000000 00000000 00000000
> svc_Print  >>  ........................ 00000000 00000000 00000000
> 00000000 00000000 00000000
> svc_Print  >>  ........................ 00000000 00000000 00000000
> 00000000 00000000 00000000
> svc_Print  >>  ........................ 00000000 00000000 00000000
> 00000000 00000000 00000000
> svc_Print  >>  ........................ 00000000 00000000 00000000
> 00000000 00000000 00000000
>
> -------------------------------
>
>
> It goes on and on, no need to copy-paste it all.
>
> NOTE: I already HAVE "-stringtables" on the server commandline.  
> Again, no problems like this before 9/14 update on this map, and I had 
> no problems serving myself this map from fastdl before yesterday's 
> update.  My wife reminded me that she never could get the server to 
> serve her this map and had to copy it into her maps folder to play it.
>
> 6. Apache logs on the fast redirect server show the client (me) NEVER 
> REQUESTED THE MAP FILE.  (probably because it had choked on building 
> string tables)
>
> 7. I had to disconnect from the server.  10+ minutes should have been 
> long enough if anything new was going to happen.  But before I did, 
> this is what status showed on the server console (at about 8 minutes
connected):
>
> status
> hostname: (My Server's Hostname)
> version : 1.19.0.0/11900 5058 secure
> udp/ip  : a.b.c.d:27015  (public ip: e.f.g.h)
> os      :  Linux
> type    :  community dedicated
> map     : de_nuke_ve
> players : 1 humans, 0 bots (37/37 max) (not hibernating)
>
> # userid name uniqueid connected ping loss state rate adr #  2 1 
> "SomeTool" STEAM_1:1:12345678 08:31 115 0 spawning 128000
> a.b.c.d:27005
> #end
>
>
> 8.  After disconnecting from the server, I closed my game client, 
> renamed my local copy of the map file back to de_nuke_ve.bsp, started 
> steam and game back up, and connected to the server.
>
>   - NO PROBLEMS GETTING ON OR PLAYING
>
>   - NO STRING TABLE BUILD SPEW IN DEVEL CONSOLE AT ALL:
>
> ------------------------
>
>
> Connecting to public(a.b.c.d:27015) ...
> 16.170:  Sending UDP connect to public IP a.b.c.d:27015 Server using 
> 'friends' lobbies, requiring pw no, lobby id 0
> RememberIPAddressForLobby: lobby 0 from address a.b.c.d:27015 Grace 
> request retry for unreserved server...
> Retrying public(a.b.c.d:27015) ...
> 16.193:  Sending UDP connect to public IP a.b.c.d:27015 Server using 
> 'friends' lobbies, requiring pw no, lobby id 0
> RememberIPAddressForLobby: lobby 0 from address a.b.c.d:27015 Server 
> approved grace request...
> Retrying connection to a.b.c.d:27015, server requires lobby 
> reservation but is unreserved.
> Received game details information from a.b.c.d:27015...
> GameTypes: could not find matching map "de_nuke_ve".
> [MM] Sending reservation request to a.b.c.d:27015 Connecting to 
> public(a.b.c.d:27015) ...
> 17.719:  Sending UDP connect to public IP a.b.c.d:27015 Server using 
> 'friends' lobbies, requiring pw no, lobby id 1860000572da3d2
> RememberIPAddressForLobby: lobby 1860000572da3d2 from address 
> a.b.c.d:27015 Connected to a.b.c.d:27015
>
> Counter-Strike: Global Offensive
> Map: de_nuke_ve
> Players: 1 (0 bots) / 37 humans
> Build: 5058
> Server Number: 4
>
> SignalXWriteOpportunity(3)
> Downloading
>
http://my.fastdl.host/games/csgo/resource/flash/loading-de_nuke_ve.swf.bz2.
> Error downloading
> http://my.fastdl.host/games/csgo/resource/flash/loading-de_nuke_ve.swf
> .bz2
> Downloading
> http://my.fastdl.host/games/csgo/resource/flash/loading-de_nuke_ve.swf.
> Error downloading
> http://my.fastdl.host/games/csgo/resource/flash/loading-de_nuke_ve.swf
> No pure server whitelist. sv_pure = 0
> SignalXWriteOpportunity(3)
> SomeTool connected.
> Receiving uncompressed update from server Redownloading all lightmaps 
> Unknown command: clientinpconfig
> ScaleformRenderer::ApplyCurrentStyle() : Attempting to use an 
> unsupported fill type: GFill_2Texture
>   m_blendMode = 0 , m_fillStyle.mStyle = 3 Scoring will not start 
> until both teams have players.
> Scoring will not start until both teams have players.
> Scoring will not start until both teams have players.
> Moe connected.
> Scoring will not start until both teams have players.
> Scoring will not start until both teams have players.
> Zach connected.
> SignalXWriteOpportunity(3)
> Cliffe connected.
>
> ----------------------------
>
>
> 9. Rinse/repeat with de_beroth, another custom map.  This one does 
> come with a loading screen and radar overview files (de_nuke_ve 
> doesn't come with a loading screen).
>
>   - Client cheerfully proceeded to re-download the map, overview, and 
> loading screen files.  Since the loading screen wasn't present (with 
> the right filename, at least, because I had renamed it), I got the 
> default loading screen.
>
>   - Progress bar on the default loading screen actually worked 
> (progressed)
>
>   - Successfully got onto the server, joined a team, had overview, etc.
>
>
> so, the moral of the story?
>
> 1. I'm a tool.  But I am occasionally right about things, and 
> unfortunately have grown weary of arguing about them.  I also 
> apologize for venting out loud on the list.  It is very, very 
> upsetting to lose a server full of players.  I should have chilled the 
> heck out before posting.
>
> 2. As a server operator, you may want to test out any/all custom maps 
> you run on your server since this update and make sure your server can 
> serve them, successfully rebuild string tables, etc.  Just because 
> they worked on a previous version doesn't mean they will on this one.
>
> I had no problems getting onto my server with de_nuke_ve *as long as I 
> already had the map file*.  When I didn't have it, I got stuck on the 
> load screen, with a properly working fastdl server.  Evidently because 
> of string table problems, even though my server IS configured to 
> rebuild string tables.
>
>
>
>
>
>> I have had atleast 3 custom maps on in my server after the update and 
>> after each one, there is a drop of players. I do not know if it's due 
>> to them being custom maps and people not wanting to download but in 
>> any case, not every player dropped off. I'll monitor the situation 
>> during this day and report back if i see any loss of players like all 
>> dropping off due to custom maps.
>>
>> One thing that could have been cause to your player lost is that if 
>> the server that is set to sv_downloadurl has had some temporarely 
>> connection issue, it might have prevented everyone from downloading 
>> the map and no one didn't have the map forehand on their pc's.
>>
>> -ics
>>
>> 15.9.2012 5:36, Tackdriver kirjoitti:
>>>> It might be the update, but a lot of people had problems with that 
>>>> particular map before the update as well. I would suggest trying it 
>>>> with a different map, too, to be able to define the issue more 
>>>> precisely.
>>> I'm not "a lot of other people".
>>>
>>> But don't pay me any mind.  You can even chalk me up as another 
>>> "victory"
>>> if you like.  It's not a measuring contest for me.  So, "you win".  
>>> Just keep telling yourself I had no idea what I was doing, and that 
>>> I really should have tried a different custom map.  Surely that is 
>>> why I had problems.  You'll probably even get some people to agree with
you.
>>>
>>> I must have been wrong.  That's why I just "went away" and didn't 
>>> argue or present any details, logs, etc. to prove my point.
>>>
>>> Yeah.  That's it.
>>>
>>> Or maybe, this isn't my first rodeo and I know it doesn't matter how 
>>> many details I give.
>>>
>>> Einstein was such a genius.
>>>
>>>
>>>
>>>> On Fri, Sep 14, 2012 at 9:40 PM, Tackdriver <[email protected]>
>>>> wrote:
>>>>>> Did you try with another map? I believe there is a known issue 
>>>>>> with nuke_ve.
>>>>> Honestly, no, I didn't.  I was on the server at the time, and 
>>>>> seeing that EVERYBODY was gone, I took immediate action and 
>>>>> changed the map to a stock map, hoping to see some people come 
>>>>> back (which some did).
>>>>>
>>>>> Looking back at the apache logs, funny thing, not a single GET 
>>>>> request for de_nuke_ve.bsp or de_nuke_ve.bsp.bz2.  I would have at 
>>>>> least expected a player or three of the full server of  connected 
>>>>> players to not already have this map and need to download it -- 
>>>>> but there wasnt even a request for it.  Many, many requests for 
>>>>> the overview and loading screen files (using the 
>>>>> overview/radar/loading downloader SM plugin) but none for the 
>>>>> actual map file.
>>>>>
>>>>> Many players attempted to return/join the map (going by the 
>>>>> connect announce plugin messages) but nobody could stay connected.
>>>>>
>>>>> I'll check the smac logs etc, but there were no problems before, 
>>>>> so I am blaming the update  until I can prove otherwise.  No 
>>>>> problems before the update.
>>>>>
>>>>> I had no problems fast downloading de_nuke_ve to myself and 
>>>>> joining the server/map when I played it for the first time (on 
>>>>> this server) - that is, before this update.
>>>>>
>>>>> You don't believe, do you, that Valve wouldn't change something 
>>>>> other than what they put in the official update items list?  Then 
>>>>> why did the mapcyclefile cvar go hidden with this update, which 
>>>>> was said to be a no config changes update?
>>>>>
>>>>>
>>>>>> On Sep 14, 2012 8:50 PM, "Tackdriver" <[email protected]> wrote:
>>>>>>
>>>>>>> Hopefully the subject is enough to begin setting the stage.
>>>>>>>
>>>>>>> Up until tonight's update (9/14), we had a working fast download 
>>>>>>> that would serve custom maps to connected/connecting players if 
>>>>>>> they did not already have them, and they would be able to play.
>>>>>>>
>>>>>>> We have a properly configured HTTP redirect.  I've only been 
>>>>>>> doing this for about the last 6 years so I don't need any 
>>>>>>> well-meaning-but-presumptuous-and-contextually-irrelevant 
>>>>>>> tutorials on sv_downloadurl, bzip2, etc.
>>>>>>>
>>>>>>> After the update, a server we allow custom maps to be voted in 
>>>>>>> proceeded to basically fill up (36 public slots, or 37 total 
>>>>>>> counting the reserved slot).  However with the config we run, 
>>>>>>> via manipulation of the mapcyclefile and mapgroup cvars based on 
>>>>>>> player count, the server was running stock valve maps for most 
>>>>>>> of the time as the player count built up.  Eventually, a custom 
>>>>>>> map (de_nuke_ve) got voted in.
>>>>>>>
>>>>>>> Once the server changed to de_nuke_ve, we saw many 
>>>>>>> (connect-announce plugin based) connect announcements as players 
>>>>>>> began reconnecting at map change, followed by disconnects.  OF 
>>>>>>> EVERY SINGLE PLAYER.  My wife and I, on the local network, were 
>>>>>>> the only 2 players on the server with the bot_quota of bots, 
>>>>>>> despite the multitude of connect announcements from internet 
>>>>>>> players.
>>>>>>>
>>>>>>> We lost everybody.  A FULL SERVER OF HUMAN PLAYERS.
>>>>>>>
>>>>>>> Now, before somebody knee-jerks "you sure you have your custom 
>>>>>>> maps set up properly in your pure server whitelist config?" -- 
>>>>>>> know this:
>>>>>>> sv_pure
>>>>>>> is
>>>>>>> disabled.  So is sv_consistency.  It's not that I want either of 
>>>>>>> them to be off, it's just the way CS:GO is right now.  You 
>>>>>>> couldn't run dedicated servers with either of them ON.  (and the 
>>>>>>> reason I say this is:  I can vouch for my game config and my 
>>>>>>> wife's -- we haven't modified ANYTHING
>>>>>>> -
>>>>>>> but our own servers would kick us for violations with pure or 
>>>>>>> consistency
>>>>>>> enabled)
>>>>>>>
>>>>>>> So it's not an sv_pure or sv_consistency problem.
>>>>>>>
>>>>>>> I jumped into console for this server and checked, just be sure 
>>>>>>> our "no config changes" update didn't finagle-force pure and 
>>>>>>> consistency ON despite my explicit configuration to turn them 
>>>>>>> off.  They were both still OFF.
>>>>>>>
>>>>>>> Yet NOBODY - not ONE SINGLE PLAYER - including many who 
>>>>>>> according to voice chat leading up to the map change were well 
>>>>>>> familiar with de_nuke_ve, could connect/reconnect to our server 
>>>>>>> once it changed to de_nuke_ve.
>>>>>>>
>>>>>>> But as soon as we changed the map back to a stock valve map, we 
>>>>>>> started seeing players come back.
>>>>>>>
>>>>>>> Maybe if I write down Einstein's definition of insanity on a 
>>>>>>> piece of paper, and lay it under my pillow, it will finally seep 
>>>>>>> through.
>>>>>>>
>>>>>>> Tackdriver
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Csgo_servers mailing list
>>>>>>> [email protected]
>>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_ser
>>>>>>> vers
>>>>>>>
>>>>>> _______________________________________________
>>>>>> Csgo_servers mailing list
>>>>>> [email protected]
>>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_serv
>>>>>> ers
>>>>> _______________________________________________
>>>>> Csgo_servers mailing list
>>>>> [email protected]
>>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_serve
>>>>> rs
>>>> _______________________________________________
>>>> Csgo_servers mailing list
>>>> [email protected]
>>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_server
>>>> s
>>>>
>>> _______________________________________________
>>> Csgo_servers mailing list
>>> [email protected]
>>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>>
>> _______________________________________________
>> Csgo_servers mailing list
>> [email protected]
>> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>>
>
> _______________________________________________
> Csgo_servers mailing list
> [email protected]
> https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
>


_______________________________________________
Csgo_servers mailing list
[email protected]
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers
--- Begin Message ---
Well, I had a spare 5 mins so I tried some custom maps and recreating the
problem by using sv_downloadurl fast download.

 

Short version: I think it’s an issue with de_nuke_ve (as downloaded from the
CS blog link).

 

Longer version: I downloaded another custom map, and put a .bz2 file on my
fast download server, setup sv_downloadurl, and it worked just fine. Client
downloaded and in I went.

I captured the console output of my server and client when testing and I can
see the problem with de_nuke_ve is that it goes looking for some other
component files which fail before it tries to download the map file.
Crucially, this on my client:

Downloading http://www.fussake.com/steamcontent/sprites/white.vmt.bz2.

Error downloading http://www.fussake.com/steamcontent/sprites/white.vmt.bz2 

Downloading http://www.fussake.com/steamcontent/sprites/white.vmt.

Error downloading http://www.fussake.com/steamcontent/sprites/white.vmt

These of course don’t exist, nor were extracted from the blog’s zip
download. So I guess it’s the way the map is compiled confusing the download
system? (Yeah, Im no mapper!)

 

Long debug dump version:

1/ Loading the server with custom mapgroup, which includes cs_office,
de_nuke_ve and de_rats_ol_shack_b3

Ø  http://pastebin.com/Ft2g3Qk8

2/ I then changelevel from my client and this is observed from the server
console (no problems)

Ø  http://pastebin.com/Jv9TaD7t

3/ This is what is observed, most crucially, from the client end when
issuing the rcon changelevel de_nuke_ve command and downloading

Ø  http://pastebin.com/CK2A50hL

4/ I then do the same for de_rats_ol_shack_b3 which downloads and starts
fine

Ø  http://pastebin.com/L7sWXB7g

My maps are hosted here on www.fussake.com/steamcontent and set as such as
my sv_downloadurl

 

Regards,

Nick

 

From: [email protected]
[mailto:[email protected]] On Behalf Of Stephen
Bevan
Sent: 22 August 2012 19:47
To: [email protected]
Subject: Re: [Csgo_servers] de_nuke_ve doesn't download from downloadurl

 

I'm having the same problem.  Perhaps someone who has successfully
accomplished this, post the required gamemodes_server requirements.

 

I can play it fine if I have the map already downloaded, but if I don't, I
get what the OP gets.

_______________________________________________
Csgo_servers mailing list
[email protected]
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers

--- End Message ---
_______________________________________________
Csgo_servers mailing list
[email protected]
https://list.valvesoftware.com/cgi-bin/mailman/listinfo/csgo_servers

Reply via email to