More namespace details

This commit is contained in:
Bottersnike 2022-01-12 21:57:26 +00:00
parent 0e15f97c77
commit 8a3d17dd26
2 changed files with 84 additions and 11 deletions

View File

@ -39,10 +39,72 @@
a <i>lot</i> of possible methods, so the majority of this document is a big reference for them all. There are a
number of generic methods, and a number of game specific ones. If you haven't clocked yet, I've been working on
an SDVX 4 build for most of these pages, and each game also comes with its own set of game-specific methods.
These are namespaces under the <code>game.%s</code> module and, in the case of SDVX 4, are all
<code>game.sv4_<i>method</i></code>. I may or may not document the SDVX 4 specific methods, but I've listed them
here anyway for completeness.
These methods are sometimes namespaced tidily, and in other cases are strewn all over the place. Namespaces I'm
currently aware of are listed below. Note that <code>game.*</code> is used by many games, and has identically named
methods within the <code>game</code> module. Expect to need to filter based on model code for this one.
</p>
<table>
<tr>
<td><code>game.*</code></td>
<td>Sound Voltex I</td>
</tr>
<tr>
<td><code>game.sv4_*</code></td>
<td>Sound Voltex IV</td>
</tr>
<tr>
<td><code>game.sv5_*</code></td>
<td>Sound Voltex V</td>
</tr>
<tr>
<td><code>game.sv6_*</code></td>
<td>Sound Voltex VI</td>
</tr>
<tr>
<td><code>exchain_*</code></td>
<td>GITADORA EXCHAIN</td>
</tr>
<tr>
<td><code>matixx_*</code></td>
<td>GITADORA Matixx</td>
</tr>
<tr>
<td><code>nextage_*</code></td>
<td>GITADORA NEXTAGE</td>
</tr>
<tr>
<td><code>op2_*</code></td>
<td>Nostalgia Op.2</td>
</tr>
<tr>
<td><code>game.*</code>, <code>playerdata.*</code></td>
<td>Pop'n Music</td>
</tr>
<tr>
<td><code>game.*</code></td>
<td>HELLO! POP'N MUSIC</td>
</tr>
<tr>
<td><code>info22.*</code>, <code>player22.*</code></td>
<td>Pop'n Music 22 (Lapistoria)</td>
</tr>
<tr>
<td><code>info23.*</code>, <code>player23.*</code></td>
<td>Pop'n Music 23 (éclale)</td>
</tr>
<tr>
<td><code>info24.*</code>, <code>player24.*</code></td>
<td>Pop'n Music 24 (Usagi to Neko to Shounen no Yume)</td>
</tr>
<tr>
<td><code>game_3.*</code></td>
<td>Museca</td>
</tr>
<tr>
<td><code>info2.*</code>, <code>player2.*</code></td>
<td>BeatStream</td>
</tr>
</table>
<p>Paths in the XML bodies are formatted using an XPath-like syntax. That is, <code>status@/response</code> gets the
<code>status</code> attribute from <code>response</code>, and <code>response/eacoin/sequence</code> would return
that node's value.

View File

@ -34,12 +34,18 @@
<item name="keepalive" url="http://localhost:8080/keepalive?pa=localhost&amp;ia=localhost&amp;ga=localhost&amp;ma=localhost&amp;t1=2&amp;t2=10" />
</services>
</response>{% endhighlight %}</pre>
<p>Fairly standard response here. Many more services are listed than actually available, but that's fine. The router
address (<code>ia</code>), gateway (<code>ga</code>) and centre (<code>ma</code>) are all set to
<code>localhost</code>, ensuring pings succeed.
</p>
<h2><code>pcbtracker.alive</code></h2>
<pre>{% highlight "cxml" %}<?xml version="1.0" encoding="SHIFT_JIS"?>
<response>
<pcbtracker ecenable="0" eclimit="0" expire="0" limit="0" status="0" />
</response>{% endhighlight %}</pre>
<p>Inform the game we have no intention of supporting PASELI. Implementing PASELI involves implementing carding, and is
a sizable amount of work. Smart EA exists to start games, not implement all features.</p>
<h2><code>message.get</code></h2>
<h3>Maintenance disabled:</h3>
@ -47,6 +53,7 @@
<response>
<message status="0" />
</response>{% endhighlight %}</pre>
<p>Just report that there's nothing to process. Nice and simple.</p>
<h3>Maintenance enabled:</h3>
<pre>{% highlight "cxml" %}<?xml version="1.0" encoding="SHIFT_JIS"?>
<response>
@ -55,6 +62,8 @@
<item end="86400" name="sys.eacoin.mainte" start="0" />
</message>
</response>{% endhighlight %}</pre>
<p>When maintenance is enabled, we publish two messages. I believe the former is to announce the whole ea network is
under maintenance, and the latter PASELI-specific.</p>
<h2><code>facility.get</code></h2>
<p>This packet notably has its encoding bytes as <code>00 FF</code> which to the best of my knowledge is not a valid
@ -86,20 +95,22 @@
</public>
<share>
<eacoin>
<notchamount __type="s32">0</notchamount>
<notchcount __type="s32">0</notchcount>
<supplylimit __type="s32">1000000</supplylimit>
<notchamount __type="s32">0</notchamount>
<notchcount __type="s32">0</notchcount>
<supplylimit __type="s32">1000000</supplylimit>
</eacoin>
<url>
<eapass __type="str">http://localhost</eapass>
<arcadefan __type="str">http://localhost</arcadefan>
<konaminetdx __type="str">http://localhost</konaminetdx>
<konamiid __type="str">http://localhost</konamiid>
<eagate __type="str">http://localhost</eagate>
<eapass __type="str">http://localhost</eapass>
<arcadefan __type="str">http://localhost</arcadefan>
<konaminetdx __type="str">http://localhost</konaminetdx>
<konamiid __type="str">http://localhost</konamiid>
<eagate __type="str">http://localhost</eagate>
</url>
</share>
</facility>
</response>{% endhighlight %}</pre>
<p>Pretty standard <code>facility.get</code> response here, full of the usual fake values. Notably not even the share
URLs were lucky enough to get real data.</p>
<h2><code>pcbevent.put</code></h2>
<pre>{% highlight "cxml" %}<?xml version="1.0" encoding="SHIFT_JIS"?>