son schwachsinn....
wenn 12 spieler auf dem server sind 12/16 (4 reserved) ist das ganze rot markiert, weil jetzt nur noch admins connecten könnten (falls reserve_type auf 0 stehen würde)
Dann heisst das, dass HLSW das bisher schlau gehandhabt hat. Und weiter heisst das, dass HLSW nun geaendert werden muss, weil es seit 3111 andere Daten bekommt.
aber wieso wechselt bitte schön SEIT DEM UPDATE auf HLDS 3.1.1.1a die MAXPLAYERS angabe? an der ganzen config wurde _NIX_ aber auch wirklich _NIX_ verändert...
[...]
ich kann es mir nur so erklären, AM 2.50.52 (und auch andere versionen) kommen nicht mit HLDS 3.1.1.1a, weil die "maxplayers" angabe inner console immer richtig ist (16)
da ich circa 192 andere half-life server geupdated habe weiß ich wovon ich rede....
Auch falsch.
Da ich keine Lust habe, das alles nochmal zu erklaeren, zitiere ich hier jetzt einfach mal ein paar emails an andere. Ich hoffe Du kannst Englisch. Wenn nicht, frag Deinen Lehrer.
Alfred wrote:
> Admin Mod is behaving correctly however in setting that cvar, the
> "maximum public players" allowed on the server will be
> "public_slots_free" + "active client count". You need to update the
> client side tools you use to parse the infostring response properly.
Maybe to elaborate a bit more on that: When a server had reserved slots
these would still show up as free slots in the server browser and people
would try to join only to get kicked being told that no slots are free.
This was frustrating for regular players and to address this issue the
sv_visiblemaxplayers cvar was added. The server browser from HL/CS now
uses this value as the number of maxplayers. If a server has the same
amount of players playing as the maxplayers number then the server
browser won't attempt to connect the client to that server.
What Admin Mod does, is to set the sv_visiblemaxplayers cvar to the
number of slots that are actually free for regular players, i.e. players
without access to reserved slots. This way normal players will no longer
be kicked from a server repeatedly upon trying to join because they are
kept from joining if no slots are available to them in the first place.
All this is true for the normal server browser in the HL client. Other
server browser tools may handle this differently but there the user
normally has better methods to filter for cvars and can thus achieve the
same effect.
Admin Mod does thus effectively hide the reserved slots as a courtesy to
normal players in order not to annoy them when trying to join a server
without available public slots. Priviledged admins can still join from
the console or from a shorcut which is the recommended method of
connecting to a server as admin.
The setting of the sv_visiblemaxplayers cvar depends on the method of
reserving slots chosen. With reserve_type set to 1 only this one slot
will be hidden and sv_visiblemaxplayers is maxplayers-1. The same is
true for reserve_type 0 where it will be maxplayers-reserve_slots. Only
for reserve_type 2 will sv_visiblemaxplayers be set to public_slots_free
+ active players because this reservation method has to account for
admins joining into reserved slots which would otherwise be available
for regular players.
I hope this helps to explain why Admin Mod does what it does. It is not
a bug, it's a feature.
As Alfred explained, if you do not want to
have this behaviour for your server then set amv_hide_reserved_slots to
0 which will turn hiding of reserved slots off.
Noch mal zur Verdeutlichung: Admin Mod verhaelt sich korrekt, am Verhalten von Admin Mod hat sich nichts geaendert. Die Serverbrowser muessen sich an den Bugfix im HLDS anpassen. Wenn alle Tools so schlau waeren wie HLSW waere das nicht notwendig gewesen, aber hier muss man sich nun mal am kleinsten gemeinsamen Nenner orientieren. Und der ist nun mal der Serverbrowser im HL Client.
