Talk:Hostage entity
Possible number of hostages per map in CSS
SirYodaJedi, how did you find out there can only be 12 hostages in a map? I do experience that the game crashes as soon as bots join. Is it the same with players? --popcorn (talk) 21:52, 19 January 2026 (PST)
- MAX_HOSTAGES. It seems to be used in bot code and for displaying the hostage locations in the minimap. It probably won't crash if there are only human players? Don't have enough friends to test.
— SirYodaJedi (talk) 06:45, 20 January 2026 (PST)
How many hostages must be rescued to win a round in CSS?
I did some testing long time ago on a listenserver with bots and documented it at Creating a Classic Counter-Strike Map#Game Mode Description and it seems to still hold today (correct me if I'm wrong):
The game intends to win the round for CTs if 50 % of all existing hostages are rescued. This is implemented as follows: If no (map-placed) hostages are left, i.e. if each hostage is either rescued or killed, the game decides whether or not to fire a CTs win event, otherwise the round continues and in fact becomes an elimination scenario, i.e. the last team alive wins the round.
However, it seems there is (still) a bug so that: every time a hostage is rescued, the game "forgets" about all hostages that have been killed up to this moment, as if they hadn't existed at round start. This has insane implications. It is advantageous for CTs, because in many cases they must in fact rescue less than the intended 50 %.
Now, what does that mean? Order matters. Suppose there are 4 hostages. Kill 3. Rescue the last. The game forgets about the 3 killed hostages. Now, that's "100 %" rescued (1 out of "1" instead of 1 out of 4), so CTs win. If you rescue one and kill 3, the round continues. For any number of hostages, the behavior is the same. Suppose there are 12 hostages. Kill 11. Rescue the last. The game forgets the 11 killed. That's "100 %" rescued (1 out of "1" instead of 1 out of 12), same thing. This is also the case if more of the hostages are rescued, but as long as the last one is rescued, it does not matter.
The intended 50 % rule does hold if and only if all rescues happen first and then the kills. Suppose 4 hostages. Rescue 2. Kill 2. That's 50 % (2 out of 4) rescued, no hostage is "forgotten". CTs win. Same for 12 hostages. Rescue 6. Kill 6. CTs win. If less than 6 are rescued, CTs do not win and the round continues.
A CT player can even kill the last hostages to win: Suppose 12 hostages. 2 rescued and 5 killed in any order. The next is rescued. The game forgets the 5 killed hostages. Since there are 3 remaining (neither killed nor rescued) and 3 have already been rescued, killing the last 3 hostages wins the round. That's "50 %" (3 out of "6").
To conclude: Rescuing 4 hostages, as has been written, is good, but not always enough to win the round. Due to the fact that more than 12 hostages are possible if you are alone on the server (and more cases?), it is more accurate if we write "50 % of the hostages" and not "4". This is why I change this back.
--popcorn (talk) 21:52, 19 January 2026 (PST)
- I confused the maximum number of func_hostage_rescues on the minimap with the actual maximum number of hostages rescued. I have updated the aforementioned entity's page accordingly.
— SirYodaJedi (talk) 06:40, 20 January 2026 (PST)- Oh well. I hope you still found my findings interesting. --popcorn (talk) 22:39, 21 January 2026 (PST)
- Definitely.
— SirYodaJedi (talk) 12:57, 22 January 2026 (PST)
- Definitely.
- Oh well. I hope you still found my findings interesting. --popcorn (talk) 22:39, 21 January 2026 (PST)