Update card types in docs

templates/pages/proto/cardmng.html

@@ -23,12 +23,20 @@
     </thead>
     <tr>
         <td><code>1</code></td>
-        <td>Old style magnetic stripe card</td>
+        <td>Old style grey cards</td>
     </tr>
     <tr>
         <td><code>2</code></td>
         <td>FeliCa RFID card</td>
     </tr>
+    <tr>
+        <td><code>3</code></td>
+        <td><i>Unknown</i></td>
+    </tr>
+    <tr>
+        <td><code>4</code></td>
+        <td>Virtual card</td>
+    </tr>
 </table>
 
 <ul>

templates/pages/proto/pcbtracker.html

@@ -5,7 +5,7 @@
 <h2 id="alive"><code>pcbtracker.alive</code></h2>
 <h3>Request:</h3>
 <pre>{% highlight "cxml" %}<call ...>
-    <pcbtracker method="alive" model*="" hardid="" softid="" accountid="" agree="" ecflag="" />
+    <pcbtracker method="alive" model*="" hardid="" softid="" accountid*="" agree="" ecflag="" />
 </call>{% endhighlight %}</pre>
 <p><code>ecflag</code> here is determining if the arcade operator allows the use of paseli on this machine.</p>
 <p><code>agree@</code> and <code>ecflag@</code> appear to either be totally non present, or present with a value of

templates/pages/protocol.html

@@ -163,22 +163,61 @@
     <p>I know which of these I'd rather use for reverse engineering (sorry, Ghidra)!</p>
 </details>
 
+<h2>Service URLs</h2>
+<p>By design, different modules call to different service endpoints. This is totally optional (all endpoints can be set
+    to the same value) however it can also be leveraged to simplify deployment. The first request any game makes when
+    starting is <code>services.get</code>, which is made to the service URL configured in the ea3 configuration. The
+    response to this request returns a list of endpoints and their corresponding URLs.</p>
+<p>Notably, the <code>services.get</code> request contains everything required to identify a game, so it may be
+    beneficial to route different games to different URLs (where appropriate).</p>
+<p>The endpoint names <b>are not</b> the same as module names. Many are, but similarly, many aren't.</p>
+
+<table>
+    <thead>
+        <tr>
+            <td>Endpoint</td>
+            <td>Modules serviced</td>
+        </tr>
+    </thead>
+    <tr>
+        <td><code>lobby</code></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td><code>lobby2</code></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td><code>local</code></td>
+        <td><code>eventlog</code>, <code>game_3</code></td>
+    </tr>
+    <tr>
+        <td><code>local2</code></td>
+        <td><code>eventlog</code>, <code>playerdata</code>, <code>matching</code>, <code>system</code>,
+            <code>esoc</code>, <code>game</code>
+        </td>
+    </tr>
+    <tr>
+        <td><code>globby</code></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td><code>pkglist</code></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td><code>posevent</code></td>
+        <td></td>
+    </tr>
+    <tr>
+        <td><code>netlog</code></td>
+        <td></td>
+    </tr>
+</table>
+<p>Modules not listed can be assumed to be served by the endpoint of the same name. <b>This table is very
+        incomplete.</b></p>
+
 <h2>Possible XRPC requests</h2>
 
 {{ generate_xrpc_list()|safe }}
-
-<b>Totally undocumented services (based on <code>services.get</code>):</b>
-<ul>
-    <li><code>numbering</code></li>
-    <li><code>pkglist</code></li>
-    <li><code>userid</code></li>
-    <li><code>local</code></li>
-    <li><code>local2</code></li>
-    <li><code>lobby</code></li>
-    <li><code>lobby2</code></li>
-    <li><code>netlog</code></li>
-    <li><code>globby</code></li>
-    <li><code>poseevent</code></li>
-</ul>
-<p>I'll try and figure these out in due course, promise!</p>
 {% endblock %}