Add 4 tutorials (4 files)
Browse Source
Daemon666 committed
parent d6523b92e3
commit a46f7d50012002453788fda83c82655182ba44db
4 changed files
with 188 additions and 0 deletions
A
amx-ban-commands/en.md
+55 -0
A
cs16-widescreen-resolution/en.md
+9 -0
A
find-player-steamid/en.md
+62 -0
A
pick-a-mod-with-players/en.md
+62 -0
amx-ban-commands/en.md
A
| @@ -0,0 +1,55 @@ | ||
| 1 | +--- | |
| 2 | +title: "amx_ban, amx_banip and amx_unban: Complete Usage" | |
| 3 | +excerpt: "Full syntax and behaviour of the AMX Mod X ban commands — amx_ban, amx_banip, amx_addban and amx_unban — including offline bans, persistence, and the flag you need." | |
| 4 | +category: "administration" | |
| 5 | +tags: "bans, admin" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>AMX Mod X ships a complete ban toolkit in the <code>admincmd</code> plugin. It is better than raw engine <code>banid</code> because it records a reason, handles list persistence automatically, and can ban a SteamID that is not currently connected. Every command here requires access flag <code>d</code> (<code>ADMIN_BAN</code>) — see the <a href="/tutorials/amxx-admin-flags-reference">flag reference</a>.</p> | |
| 10 | + | |
| 11 | +<h2>1. amx_ban — ban a connected player by SteamID</h2> | |
| 12 | +<pre>amx_ban <name | #userid> <minutes> [reason]</pre> | |
| 13 | +<p>Bans by the player's SteamID (authid). <code>minutes</code> of <code>0</code> is permanent. Examples:</p> | |
| 14 | +<pre>amx_ban "Cheater" 60 "aimbot" | |
| 15 | +amx_ban #14 0 "permanent - wallhack"</pre> | |
| 16 | +<p>The player is kicked immediately and the SteamID is added to the ban list. Because it bans the authid, the ban survives an IP change — this is the command you want for a real offender.</p> | |
| 17 | + | |
| 18 | +<h2>2. amx_banip — ban by IP address</h2> | |
| 19 | +<pre>amx_banip <name | #userid> <minutes> [reason]</pre> | |
| 20 | +<p>Bans the player's current IP instead of their SteamID. Use it for non-Steam clients with unreliable IDs, or to stop an immediate reconnect from the same address:</p> | |
| 21 | +<pre>amx_banip "Spammer" 30 "chat flood"</pre> | |
| 22 | +<p>IP bans are blunt — shared/NAT addresses catch innocents, and a dynamic IP defeats them within hours. Prefer <code>amx_ban</code> on Steam servers and reach for <code>amx_banip</code> only when you have no stable SteamID.</p> | |
| 23 | + | |
| 24 | +<h2>3. amx_addban — offline ban</h2> | |
| 25 | +<pre>amx_addban <authid | ip> <minutes> [reason]</pre> | |
| 26 | +<p>Bans an identity that is not currently on the server. This is how you act on a demo review or a report after the player left:</p> | |
| 27 | +<pre>amx_addban STEAM_0:1:55667788 0 "reviewed demo - spinbot" | |
| 28 | +amx_addban 203.0.113.44 1440 "ban evasion"</pre> | |
| 29 | +<p>It writes straight to the ban list without needing a live target.</p> | |
| 30 | + | |
| 31 | +<h2>4. amx_unban — lift a ban</h2> | |
| 32 | +<pre>amx_unban <authid | ip></pre> | |
| 33 | +<p>Removes the entry from the ban list. You must pass the exact identity that was banned:</p> | |
| 34 | +<pre>amx_unban STEAM_0:1:55667788 | |
| 35 | +amx_unban 203.0.113.44</pre> | |
| 36 | +<p>A SteamID ban is undone only by unbanning that SteamID; an IP ban only by unbanning that IP. Unbanning the SteamID does nothing to an IP ban of the same player, which is the single most common unban confusion.</p> | |
| 37 | + | |
| 38 | +<h2>5. amx_banmenu — the visual route</h2> | |
| 39 | +<pre>amx_banmenu</pre> | |
| 40 | +<p>Opens a menu to pick an online player and a preset duration — the fast path during a live incident. It calls the same commands underneath, so everything covered above (SteamID versus IP, persistence, the reason field) applies identically. The menu is what most admins actually use in the heat of a match; the typed commands matter when you are acting on a report after the fact or scripting bans from RCON.</p> | |
| 41 | + | |
| 42 | +<h2>6. Where bans are stored</h2> | |
| 43 | +<p>SteamID bans go to <code>cstrike/banned.cfg</code>; IP bans go to <code>cstrike/listip.cfg</code>. AMXX calls <code>writeid</code> / <code>writeip</code> for you, so amx_ bans persist across restarts automatically — unlike a raw engine <code>banid</code>, which you must follow with <code>writeid</code> yourself (see <a href="/tutorials/rcon-commands-list">RCON commands</a>). You can inspect the current lists in the server console with <code>listid</code> and <code>listip</code>.</p> | |
| 44 | + | |
| 45 | +<h2>Common errors</h2> | |
| 46 | +<ul> | |
| 47 | +<li><strong><code>You have no access to that command</code></strong> — the admin lacks flag <code>d</code>. Grant it in <a href="/tutorials/users-ini-explained">users.ini</a> and run <code>amx_reloadadmins</code>.</li> | |
| 48 | +<li><strong>Banned player rejoins instantly</strong> — you used <code>amx_ban</code> (SteamID) but they are on a different SteamID, or non-Steam. Add an <code>amx_banip</code> as well, or fix authids with <a href="/tutorials/install-reunion">Reunion</a>.</li> | |
| 49 | +<li><strong>amx_unban does nothing</strong> — you unbanned the SteamID but the block is an IP ban (or vice versa). Check <code>listid</code> and <code>listip</code> to see which list holds the entry.</li> | |
| 50 | +<li><strong>Ban lost after restart</strong> — extremely rare with amx_ commands, but happens if <code>banned.cfg</code> is read-only or the process cannot write to <code>cstrike/</code>. Fix file permissions.</li> | |
| 51 | +<li><strong>Wrong universe digit</strong> — a <code>STEAM_1:</code> ban will not match a <code>STEAM_0:</code> reconnect. Ban the exact ID <code>status</code> shows on your server.</li> | |
| 52 | +</ul> | |
| 53 | + | |
| 54 | +<h2>Verification</h2> | |
| 55 | +<p>Ban a test account for one minute with a reason: <code>amx_ban "Tester" 1 "test"</code>. Confirm the kick, then check the server console with <code>listid</code> — the SteamID and remaining time should appear. Have the account try to reconnect; it must be refused. After the minute elapses it should connect again. For a heavier, database-backed workflow with a web interface and cross-server bans, move up to <a href="/tutorials/install-amxbans">AMXBans</a>.</p> |
cs16-widescreen-resolution/en.md
A
| @@ -0,0 +1,9 @@ | ||
| 1 | +--- | |
| 2 | +title: "Widescreen (16:9) in CS 1.6 Without Stretching Problems" | |
| 3 | +excerpt: "How to run CS 1.6 at a native 16:9 resolution, why the game and your monitor stretch the image, and where the fix really lives — the GPU scaling settings." | |
| 4 | +category: "client" | |
| 5 | +tags: "resolution, widescreen" | |
| 6 | +image: "" | |
| 7 | +read_time: "7 min read" | |
| 8 | +--- | |
| 9 | +<p>CS 1.6 was built for 4:3 monitors, and on a modern 16:9 or 21:9 display it either shows black bars, stretches everyone into short wide characters, or crops the view. The good news is the current engine supports widescreen resolutions natively; the confusion is that "stretching" can come from two completely different places — the game's resolution and your monitor's or GPU's scaling. Fix the right one and the game looks correct. This guide covers both.</p><h2>1. Set a native widescreen resolution</h2><p>The cleanest way is launch options. Right-click Counter-Strike in Steam → <em>Properties → Launch Options</em> and set the resolution to match your monitor:</p><pre>-width 1920 -height 1080</pre><p>You can also set it in <em>Options → Video</em> if your monitor's native resolution appears in the list. Use OpenGL as the renderer. Setting a true 16:9 resolution is what stops the game itself from stretching a 4:3 image across a wide screen.</p><h2>2. Understand what "stretch" actually is</h2><p>There are two independent stretches:</p><ul><li><strong>Game-level:</strong> running a 4:3 resolution (like 1024x768) that the display then stretches to fill a 16:9 panel. Fix: pick a 16:9 resolution.</li><li><strong>Scaling-level:</strong> the monitor or GPU scaling a smaller image to fill the panel non-proportionally. Fix: change the scaling mode, not the resolution.</li></ul><p>Many players like the <em>look</em> of a stretched 4:3 (models appear wider and easier to hit) and deliberately keep it. If that is you, the goal is to control the stretch, not eliminate it — which is exactly what the scaling setting does.</p><h2>3. Control scaling in the GPU driver</h2><p>This is where the real control lives — not in CS. In your GPU control panel:</p><ul><li><strong>NVIDIA Control Panel → Adjust desktop size and position:</strong> choose <em>Aspect ratio</em> to keep proportions (black bars on the sides for a 4:3 resolution) or <em>Full-screen</em> to stretch. Set "Perform scaling on: GPU".</li><li><strong>AMD Software → Display → Scaling Mode:</strong> pick <em>Preserve aspect ratio</em> or <em>Full panel</em>.</li></ul><p>Whether you want a sharp 16:9 image or a controlled stretched 4:3, this is the setting that decides it. If a 4:3 resolution still fills the whole screen after you chose "aspect ratio", the monitor's own scaling is overriding the GPU — check the monitor's on-screen menu for an aspect/scaling option too.</p><h2>4. Match the refresh rate</h2><p>Setting a widescreen resolution sometimes drops the game to 60 Hz on a high-refresh monitor. Force the refresh rate in launch options:</p><pre>-width 1920 -height 1080 -freq 144</pre><p>Set <code>-freq</code> to your monitor's actual refresh rate. This does not change the aspect ratio, but a widescreen fix that leaves you at 60 Hz on a 144 Hz panel is only half done.</p><h2>5. About field of view</h2><p>CS 1.6 does not give you a free FOV slider, and at a true 16:9 resolution the engine's default view can feel slightly zoomed compared to 4:3. There is a <code>default_fov</code> cvar (default 90), but most servers reset or restrict it and changing it is not a reliable widescreen fix. Do not rely on it — pick the resolution and scaling you like and leave FOV alone.</p><h2>Common errors</h2><ul><li><strong>Everyone looks short and wide</strong> — you are running a 4:3 resolution stretched to fill 16:9. Either set a 16:9 resolution or switch GPU scaling to "aspect ratio".</li><li><strong>Black bars you do not want</strong> — the opposite: aspect-ratio scaling on a 4:3 resolution. Switch scaling to full-screen or set a native 16:9 resolution.</li><li><strong>Resolution not in the video menu</strong> — set it via <code>-width</code>/<code>-height</code> launch options instead.</li><li><strong>Screen goes 60 Hz after the change</strong> — add <code>-freq</code> with your real refresh rate.</li><li><strong>Scaling setting ignored</strong> — the monitor's own scaler is overriding the GPU. Set the monitor's OSD to the same aspect/scaling choice.</li></ul><h2>Verification</h2><p>Launch the game and check a round scoreboard or the main menu proportions: circles should look round, not oval, if you want true aspect; or uniformly stretched if you chose that on purpose. Confirm the refresh rate is correct (your monitor's OSD usually shows it). Once it looks right, the settings live in your launch options and driver control panel, so they persist without touching <a href="/tutorials/cs16-config-cfg-guide">config.cfg</a>.</p> |
find-player-steamid/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "How to Find a Player's SteamID (Live and From Logs)" | |
| 3 | +excerpt: "Pull a player's SteamID live with status and amx_who, extract it from server logs, understand the non-Steam cases, and use it to ban with persistence." | |
| 4 | +category: "administration" | |
| 5 | +tags: "steamid, logs" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>Almost every moderation action on a CS 1.6 server starts with one thing: the offender's SteamID. You need it to ban the person rather than a name they can change or an IP they share with an ISP. This covers getting the ID while they are connected, digging it out of the logs after they leave, the non-Steam wrinkles, and turning the ID into a ban that survives a restart.</p> | |
| 10 | + | |
| 11 | +<h2>1. Live, from the console: status</h2> | |
| 12 | +<p>The fastest method. In the server console or over RCON:</p> | |
| 13 | +<pre>status</pre> | |
| 14 | +<p>Each connected player prints a block like:</p> | |
| 15 | +<pre># userid name unique team | |
| 16 | +# 12 "Nova" STEAM_0:1:12345678 CT 45 67ms</pre> | |
| 17 | +<p>The <code>unique</code> column is the SteamID (<code>STEAM_0:x:yyyyyyyy</code>), and the leading <code>#12</code> is the <em>userid</em> — the transient slot number you use for <code>kick</code> and RCON commands during this session. The SteamID is the stable identity; the userid resets every map.</p> | |
| 18 | + | |
| 19 | +<h2>2. Live, from in-game admin: amx_who</h2> | |
| 20 | +<p>With AMX Mod X, an admin can run in chat or console:</p> | |
| 21 | +<pre>amx_who</pre> | |
| 22 | +<p>It lists every player with their name, SteamID (authid), current access flags and immunity. This is the admin-friendly version of <code>status</code> and it also tells you at a glance who else on the server has admin. It reads identities from <code>configs/users.ini</code>, the same file that defines your <a href="/tutorials/plugins-ini-load-order">admin flags</a>.</p> | |
| 23 | + | |
| 24 | +<h2>3. From the logs, after they left</h2> | |
| 25 | +<p>Server logs live in <code>cstrike/logs/</code> as dated <code>L*.log</code> files, and every connect line carries the SteamID. Grep for the name or the action:</p> | |
| 26 | +<pre>cd /home/steam/hlds/cstrike/logs | |
| 27 | +grep -i "nova" L*.log</pre> | |
| 28 | +<p>Connect and kill lines embed the ID in angle brackets:</p> | |
| 29 | +<pre>"Nova<12><STEAM_0:1:12345678><CT>" killed "Ghost<9>..."</pre> | |
| 30 | +<p>The three fields in the brackets are name, userid, and SteamID. Even if you missed the player live, the log has their ID as long as logging is on (<code>log on</code>, <code>mp_logdetail 3</code> — see <a href="/tutorials/essential-server-cvars">essential cvars</a>).</p> | |
| 31 | + | |
| 32 | +<h2>4. The non-Steam cases</h2> | |
| 33 | +<p>SteamIDs are only trustworthy on a server that validates them. On a non-Steam server running <a href="/tutorials/install-reunion">Reunion</a> or dproto, IDs depend on the client:</p> | |
| 34 | +<ul> | |
| 35 | +<li>A pending client may briefly show <code>STEAM_ID_PENDING</code> before resolving.</li> | |
| 36 | +<li>Reunion can be configured to hand non-Steam clients generated, stable IDs — but two different people with the same cracked client can collide unless it is configured correctly. See <a href="/tutorials/fix-duplicate-steamids-nonsteam">duplicate SteamIDs on non-Steam</a>.</li> | |
| 37 | +<li>The <code>0</code> vs <code>1</code> in <code>STEAM_0:X:</code> is the auth server digit and is part of the ID — do not "normalize" it away when banning.</li> | |
| 38 | +</ul> | |
| 39 | +<p>On a mixed server, treat the SteamID as the identity but keep the IP as a secondary signal for repeat offenders whose IDs you cannot trust.</p> | |
| 40 | + | |
| 41 | +<h2>5. Turn the ID into a persistent ban</h2> | |
| 42 | +<p>Once you have the SteamID, ban it. With AMX Mod X the clean way is a command that writes the ban and boots them in one step:</p> | |
| 43 | +<pre>amx_ban 30 "Nova" cheating // ban a connected player, 30 minutes | |
| 44 | +amx_addban "STEAM_0:1:12345678" 0 cheating // ban by ID, 0 = permanent</pre> | |
| 45 | +<p>At the engine level the same is done with <code>banid</code>, and the crucial second step is persistence:</p> | |
| 46 | +<pre>banid 0 STEAM_0:1:12345678 | |
| 47 | +writeid</pre> | |
| 48 | +<p><strong><code>writeid</code> is what saves the ban to <code>banned.cfg</code></strong> so it survives a restart; a <code>banid</code> without it evaporates on the next map or reboot. For IP bans the pair is <code>addip</code> / <code>writeip</code>, and <code>listid</code> / <code>listip</code> show the current lists. A menu-driven <a href="/plugins/csb-ban-manager">ban manager</a> or the <a href="/plugins/csb-admin-menu">admin menu</a> wraps all of this so you never fat-finger a raw <code>banid</code>.</p> | |
| 49 | + | |
| 50 | +<h2>Common errors</h2> | |
| 51 | +<ul> | |
| 52 | +<li><strong>Ban gone after restart</strong> — you ran <code>banid</code> without <code>writeid</code> (or <code>addip</code> without <code>writeip</code>). The ban was never written to disk.</li> | |
| 53 | +<li><strong><code>amx_ban</code> says no such player</strong> — the player already disconnected; use <code>amx_addban</code> with the SteamID from the logs instead.</li> | |
| 54 | +<li><strong>Banned the wrong person</strong> — you used the userid (<code>#12</code>) as if it were stable. It is a per-session slot; always ban the SteamID.</li> | |
| 55 | +<li><strong>Non-Steam ban does not stick</strong> — the client's ID changes between sessions. Reunion needs a proper <code>SteamIdHashSalt</code> and configuration; an IP ban may be the only reliable lever.</li> | |
| 56 | +<li><strong>SteamID missing from logs</strong> — logging was off. Set <code>log on</code> and <code>mp_logdetail 3</code> before you need it.</li> | |
| 57 | +</ul> | |
| 58 | + | |
| 59 | +<h2>Verification</h2> | |
| 60 | +<p>Run <code>status</code> and confirm you can read the SteamID of everyone on the server. After banning, check the list persisted:</p> | |
| 61 | +<pre>listid</pre> | |
| 62 | +<p>The banned SteamID should appear. Restart the server and run <code>listid</code> again — if it is still there, <code>writeid</code> did its job and the ban is permanent. If it vanished, you skipped the write step.</p> |
pick-a-mod-with-players/en.md
A
| @@ -0,0 +1,62 @@ | ||
| 1 | +--- | |
| 2 | +title: "Picking a Mod That Still Has Players in 2026" | |
| 3 | +excerpt: "Building for a dead game mode dooms a server before it starts. Here is how to read demand, which CS 1.6 modes still draw crowds, and how to pick one you can win." | |
| 4 | +category: "hosting" | |
| 5 | +tags: "mods, strategy" | |
| 6 | +image: "" | |
| 7 | +read_time: "8 min read" | |
| 8 | +--- | |
| 9 | +<p>The mod you choose decides your ceiling before you install a single plugin. A perfectly run server for a mode nobody plays grows slower than a rough server for a mode people are actively searching for. CS 1.6 in 2026 is a mature ecosystem with clear winners and clear graveyards, and — crucially — popularity is regional. This guide is about reading real demand instead of building what you personally like and hoping.</p> | |
| 10 | + | |
| 11 | +<h2>1. Read the browser, do not guess</h2> | |
| 12 | +<p>The single best market-research tool is the in-game server browser itself. Sort the internet list by players, in your region, and look at what is actually full:</p> | |
| 13 | +<ul> | |
| 14 | +<li>Which modes dominate the top of the list?</li> | |
| 15 | +<li>How many servers already run each mode, and how full are they?</li> | |
| 16 | +<li>Is a popular mode <em>saturated</em> (dozens of full servers) or <em>underserved</em> (high demand, few good servers)?</li> | |
| 17 | +</ul> | |
| 18 | +<p>You want a mode with proven demand but room for one more good server — not the mode with the most servers, but the one where demand outstrips quality supply.</p> | |
| 19 | + | |
| 20 | +<h2>2. The modes that reliably still draw players</h2> | |
| 21 | +<p>These have durable populations across regions in 2026, though the mix varies by country:</p> | |
| 22 | +<table> | |
| 23 | +<thead><tr><th>Mode</th><th>Why it endures</th></tr></thead> | |
| 24 | +<tbody> | |
| 25 | +<tr><td>Classic public (Dust2 24/7, mixed maps)</td><td>The default. Huge, saturated, but always in demand.</td></tr> | |
| 26 | +<tr><td>Zombie (Plague / Escape / Biohazard)</td><td>Consistently one of the largest communities in 1.6.</td></tr> | |
| 27 | +<tr><td>Deathmatch / CSDM / respawn</td><td>Fast, low-commitment, great for warmups and aim.</td></tr> | |
| 28 | +<tr><td>GunGame</td><td>Simple, fun, strong casual pull.</td></tr> | |
| 29 | +<tr><td>Jailbreak</td><td>Roleplay-heavy, sticky regulars where it is popular.</td></tr> | |
| 30 | +<tr><td>Deathrun</td><td>Steady niche with loyal players.</td></tr> | |
| 31 | +<tr><td>Surf / Bhop / KZ</td><td>Movement communities, dedicated and self-sustaining.</td></tr> | |
| 32 | +<tr><td>HNS (Hide and Seek) / Furien</td><td>Regional favourites, popular in specific countries.</td></tr> | |
| 33 | +</tbody> | |
| 34 | +</table> | |
| 35 | +<p>Regional weighting is real: zombie and public dominate some regions, movement and jailbreak others. Trust <em>your</em> region's browser over any global list.</p> | |
| 36 | + | |
| 37 | +<h2>3. Match the mod to what you can actually run</h2> | |
| 38 | +<p>Some modes are far heavier to operate than others:</p> | |
| 39 | +<ul> | |
| 40 | +<li><strong>Zombie and jailbreak</strong> need active admins and constant tuning to stay healthy — great retention if you can staff them, a mess if you cannot.</li> | |
| 41 | +<li><strong>Deathmatch, GunGame, surf, deathrun</strong> largely run themselves once configured — better if you are a solo admin.</li> | |
| 42 | +<li><strong>Classic public</strong> is easy to run but brutally saturated; you need a differentiator (great anti-cheat, a strong stats/ranking system, a known community).</li> | |
| 43 | +</ul> | |
| 44 | +<p>Be honest about your time. A mode that demands moderation you cannot provide will feel dead even with players in it.</p> | |
| 45 | + | |
| 46 | +<h2>4. Find the underserved angle</h2> | |
| 47 | +<p>The winning move is usually a popular mode with a specific twist that the saturated servers do not offer: a well-moderated zombie server in a region where the big ones are laggy; a surf server with a good ranking system and clean map rotation; a public server with real anti-cheat where the competition is full of cheaters. Differentiation beats novelty — a slightly better version of something people already want beats a brand-new mode nobody is searching for.</p> | |
| 48 | + | |
| 49 | +<h2>5. Plan the plugin stack before committing</h2> | |
| 50 | +<p>Each mode implies a plugin set. Confirm the core plugins for your chosen mode exist and are maintained before you build the whole server around it. Browse implementations in the <a href="/plugins">plugin directory</a> — a mode is only viable if you can actually assemble a solid, current stack for it.</p> | |
| 51 | + | |
| 52 | +<h2>Common mistakes</h2> | |
| 53 | +<ul> | |
| 54 | +<li><strong>Building what you like instead of what is searched for</strong> — your taste is a sample size of one. Read the browser.</li> | |
| 55 | +<li><strong>Entering a saturated mode with no edge</strong> — the ten-thousandth identical Dust2 server does not grow. Have a differentiator.</li> | |
| 56 | +<li><strong>Picking a heavy mode you cannot staff</strong> — an unmoderated jailbreak or zombie server rots fast.</li> | |
| 57 | +<li><strong>Ignoring region</strong> — a mode that is huge in one country can be empty in yours. Local demand is what counts.</li> | |
| 58 | +<li><strong>Chasing a truly dead niche "to stand out"</strong> — standing out in an empty room is not an advantage.</li> | |
| 59 | +</ul> | |
| 60 | + | |
| 61 | +<h2>Verification</h2> | |
| 62 | +<p>Before committing, run a simple demand test. For a week, note the peak player counts of the top five servers in your target mode and region at your intended peak hour. If those servers are consistently full, demand exists and your job is to earn a slice of it. If even the top servers in that mode sit half-empty, the demand is not there — pick again. Then align the rest of your launch around the choice: <a href="/tutorials/choose-vps-for-cs16">a VPS close to that audience</a> and a plan for <a href="/tutorials/get-players-on-new-server">seeding the first players</a>.</p> | |
| 0 | 63 |
