Repository navigation
BIG_INFO_STRING is too short #1215
Description
Activity
How sad
I looked at the current serverinfo on Bunker and it's about 800 bytes. This is close to the "normal" MAX_INFO_STRING size of 1024, but nowhere near BIG_INFO_STRING. So probably the
bcscommands are just broken and can't handle stuff more than 1024 correctly.Reacted by cu-kaiI looked at the current serverinfo on Bunker and it's about 800 bytes. This is close to the "normal" MAX_INFO_STRING size of 1024, but nowhere near BIG_INFO_STRING. So probably the
bcscommands are just broken and can't handle stuff more than 1024 correctly.Thanks for the clarification. So the real bug is not the one I am reporting? Feel free to re-title this as appropriate.
I was able to reproduce locally. The server sends a
bcs0and abcs2command, but somehow only thebcs2command arrives to the client.#1218 fixes the
bcs exceeded BIG_INFO_STRINGbug, BUT it does not mean that you can safely have a serverinfo string up to 8192 characters. In other parts of the system the serverinfo string is limited to 1024 chars. It has more restrictions than a general config string.With #1218 you can now safely have a serverinfo string which is close to 1024 characters but not exceeding it (this was probably your use case.)
Increasing the max serverinfo length would require a compatibility-breaking change. Anyway the idea of the serverinfo is to display only the things that would be most relevant to someone deciding which server to join.
What is the long term fix? Are you saying we should create another mechanism for syncing arbitrary data between the server and client?
Increasing the max serverinfo length would require a compatibility-breaking change. Anyway the idea of the serverinfo is to display only the things that would be most relevant to someone deciding which server to join.
It seems to also be used to let the client decide which buildables, classes and equipment to show as locked in the menu.
What is the long term fix? Are you saying we should create another mechanism for syncing arbitrary data between the server and client?
This would probably be the best thing to do?
Other cvars that need to be sent to clients could be put in another info string besides the serverinfo one.
Reacted by cu-kaiIncreasing the max serverinfo length would require a compatibility-breaking change. Anyway the idea of the serverinfo is to display only the things that would be most relevant to someone deciding which server to join.
Isn't this part handled by
SVC_Info()instead? The server version display required modifying it and adding stuff to theinfo_map, while simply setting the cvar asCvar::SERVERINFOresulted in the client getting that info only after joining.There are 2 types of queries whereby non-connected clients can get information about the server,
getinfoandgetstatus. "Info" is the minimal one used when "pinging" servers to populate the server list, which despite its name, does not show SERVERINFO vars. "Status" is the more detailed one that includes the player names and SERVERINFO cvars. This is supposed to be done when you click on a server in the list to see more info (currently broken in-game, but it works on https://unvanquished.net/servers).- added a commit that references this issue
on Apr 23, 2026
We are sending a lot of information in the info strings now, and 8192 is just not big enough for this as I found out, simply setting some
g_disabledEquipmentandg_disabledBuildablescaused an overflow on Bunker, and players are either spammed by: "Warn: Unknown client game command ..." or kicked from the server with the "bcs exceeded BIG_INFO_STRING" message.Can we increase this? (double it?) What are the implications of such a change?