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_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
_______________________________________________
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
