http://wiki.minegoboom.com/index.php?title=Special:NewPages&feed=atom&hideredirs=1&limit=50&offset=&namespace=0&username=&tagfilter=ASSS Wiki - New pages [en]2024-03-28T08:40:52ZFrom ASSS WikiMediaWiki 1.28.2http://wiki.minegoboom.com/index.php/Peer_ProtocolPeer Protocol2015-02-16T17:56:45Z<p>Cheese: </p>
<hr />
<div>This protocol is UDP and bi-directional. It is used by [[Subgame]] and the VIE servers.<br><br />
SubSpace game servers can communicate with each other via the SubSpace Peer protocol.<br><br />
Unlike most other protocols in SubSpace, the peer protocol does not make use of the SubSpace Control Protocol.<br><br />
Rather, it uses lightweight datagrams and accepts packets based on a whitelist of the datagram source's (IP, port) pair.<br><br />
Player lists/player count packets are sent at approximately 250ms intervals.<br><br />
<br />
<br />
===SendTo Command===<br />
<pre><br />
sendto command example usage:<br />
/*sendto zone ip, zone port<br />
full subgame syntax is:<br />
*sendto IP,port,arenaname<br />
does not work for staff members being sent with staff password appended to their password<br />
</pre><br />
<br />
===Settings===<br />
<pre><br />
Go request (GR) definition:<br />
Any time a client asks to go to a new arena. In Cont, when a zone is first entered, it asks to go to a NULL arena (i.e. no arena name is given). This is the same as typing "?go" in subgame (no arena name). Other clients (bots, chatnet clients, etc.) can and do sometimes ask to go to specific arenas on zone entry.<br />
<br />
server.ini sections:<br />
[Peers]<br />
//must include port and be valid hostname or entire entry is ignored.<br />
MyArenas=<ARENA SPEC><br />
// see below for ARENA SPEC<br />
<br />
// maximum number of peers is 8 and # starts at 0: Peer0, Peer1, ... Peer7<br />
[Peer<#>]<br />
//location of peer<br />
Address=<IP>:<PORT><br />
// passwords explained below<br />
Password=testpw<br />
//arenas to route, players will be sent upon ?go<br />
Arenas=<ARENA SPEC><br />
//see below<br />
SendOnly=0<br />
//if least one player is in the zone, send player list packet<br />
SendPlayerList=1<br />
<br />
<ARENA SPEC>: A comma-separated list of arena names to match. It may not be longer than 511 characters. No more than 32 different arenas may be given. No whitespace is allowed, unless it's meant as part of the arena name. 2 special arena names are recognized, "$pub" and "$pvt". $pub matches any time no arena name is given in a GR. $pvt is the converse of $pub; it _always_ matches unless no arena name is given.<br />
<br />
SendOnly: SendOnly could have something to do with *zone and ?alert messages. Both of these are sent in the peering protocol. SendOnly could be a boolean saying you don't want your instance of subgame to broadcast *zone and ?alert if they come from other peers, or an enum for various combinations. This should be easily testable. It could also have something to do with the sending of private (#-prefixed) arena names. edit: it could also be an <ARENASPEC>, to send player lists for only matched arenas.<br />
<br />
GR Matching:<br />
When a GR is issued in a zone (or more accurately, subgame instance), it first consults the list Peer:MyArenas, if it exists. If a match is found, the GR is processed normally (as if there were no peers). The purpose appears to be for use with $pvt. If you have a $pvt rule in a [Peer<#>] section to send people to another zone whenever they go to a named arena, this acts as a mask, a list of the arenas you explicitly want this subgame instance to manage.<br />
<br />
If no match is found in Peer:MyArenas, each Peer<#>:Arenas list is consulted in order (by number, not the order they appear in the file). On the first match found, the player is transparently redirected to the address for that peer. Note that the arena name will be part of the initial GR issued when the client enters that zone. If after consulting all available peers no match is found, the request is handled normally.<br />
<br />
Passwords:<br />
If you decide to have 2 subgame instances peer, they must agree on a password. The password must agree in each INI [Peer<#>] entry which refers to the other zone.<br />
<br />
Example: 2 zones running on localhost, subgame-A on port 5000 and subgame-B on port 7777<br />
<br />
in subgame-A's ini:<br />
[Misc]<br />
Port=5000<br />
<br />
[Peer3]<br />
Address=127.0.0.1:7777<br />
Password=hackme<br />
<br />
and in subgame-B's ini:<br />
[Misc]<br />
Port=7777<br />
<br />
[Peer1]<br />
Address=127.0.0.1:5000<br />
Password=hackme<br />
</pre><br />
<br />
===Packets===<br />
<pre><br />
All packets have the following form:<br />
00 01 <passwordHash (4)> FF <type (1)> <timestamp (4)> <payload><br />
The passwordHash is a CRC32 of the peer password in server.ini. <br />
The payload depends on the type field and their formats are described below. <br />
<br />
<br />
0x01: Player List<br />
<br />
This packet is sent if SendPlayerList=1 and at least one player is in the zone.<br />
It lists all arenas in the zone with a list of all players in each arena.<br />
The list of players for a given arena is null terminated as indicated by the 00 field below.<br />
The arenaID field is a random 32-bit integer that is associated with each arena at the time of its creation.<br />
An arena maintains its arenaID until the arena gets re-created or manually recycled.<br />
{<br />
<arenaID (4)><br />
<arenaName (asciiZ)><br />
{<br />
<playerName (asciiZ)><br />
}<br />
00<br />
} (repeated until end of packet)<br />
<br />
<br />
0x02: Chat Message<br />
<br />
When a peer receives this packet, it broadcasts it as if it were a zone-wide message (*zone).<br />
<type:0 (1)> //currently ignored by subgame, can be anything<br />
<message (asciiZ)><br />
<br />
<br />
0x03: ?alert messages<br />
<br />
Technically exactly the same as the 0x02 packet, but as this is the result of ?help, ?cheater, etc it should be restricted to the appropriate staff members.<br />
<type:0 (1)> //currently ignored by subgame, can be anything<br />
<message (asciiZ)><br />
<br />
<br />
0x04: Player Count<br />
<br />
This packet is sent if SendPlayerList=0 or there are no players in the zone. The player count is the total number of players in the zone.<br />
<playerCount (2)><br />
</pre><br />
<br />
===Subgame internal data structs===<br />
<pre><br />
struct s2c_sendto<br />
{<br />
BYTE type; // 0x3B<br />
DWORD ip_addr; // IP Address (little endian)<br />
WORD port_num; // Port number (little endian)<br />
WORD join_type; // Same as the arena login packet<br />
char arena_name[16]; // Arena Name<br />
DWORD loginid;<br />
}; <br />
</pre><br />
<br />
<br />
<br />
[[Category: Protocol]]</div>Cheesehttp://wiki.minegoboom.com/index.php/Securing_SubgameSecuring Subgame2014-01-09T05:22:09Z<p>CypherJF: initial page</p>
<hr />
<div>There are several game configuration values which should be set to secure your game server. Some items below may refer to a specific game server such as [[Subgame]] or [[ASSS]] while others are more global knowledge which applies to both. This initial list was created by [[L.C.]] on a [http://forums.minegoboom.com/viewtopic.php?t=8571 server forum post].<br />
<br />
1. Generate new scrty and scrty1 files. You should do this for EACH instance of subgame2.exe/asss.exe. By generating new scrty and scrty1 files, the security checksum for your zone become unique for your zone. If all zones had the same scrty and scrty1 files, if one zone's encryption was broken, then everyone would be screwed. But if you use a unique pair of security-encryption files for your zone, you are safe from broken encryptions of other zones. <br />
<br />
To generate new scrty and scrty1 files, run "Continuum.exe Z" in the command line and Continuum will generate new files. Just overwrite your old files with these new ones. Repeat this step for each instance and installation of subgame2.exe/asss.exe. <br />
<br />
Source: http://sharvil.nanavati.net/projects/subspace/encryption.html <br />
<br />
<br />
<br />
2. Place your ss:// address at the very beginning of the zone description. If you do not know what your address is, you probably do not have one. You must have a fully qualified domain name in order to use this feature. The reason for placing this address at the beginning of the zone description is to ensure and guarantee that this feature will be used; this will also make sure that no too long of a zone description will push your ss:// address beyond the maximum character limit, rendering this feature functionless. <br />
<br />
The importance of ss:// is so that if the IP address of your server changes, players do not have to manually go and re-update their zone lists to get the new IP. Instead, Continuum will automatically check that address and update their zone lists for them -- and that way there will be no confusion about what happened to your zones as a result of an IP change. <br />
<br />
<br />
<br />
3. Set CheckMod, CheckSMod, and CheckSysop to 1 in your server.ini. This will prevent unauthorized players from being able to login with staff powers if they happen to know the correct passwords. <br />
<br />
<br />
<br />
4. Generate a random NamePassword under [Directory] in server.ini. Although unlikely, this will secure your zone's publishing in the directory server listings. You should use a unique password for each instance and installation of subgame2.exe/asss.exe. Unless someone figures out this password, nobody can hijack your zone's name in the listing. I would recommend using http://www.goodpassword.com/ to generate something that is preferably at least 13 characters and includes symbols. Then take that randomly generated password and feed it into http://gtools.org/tool/md5-hash-generator/ to get an MD5 of this password. Use this generated MD5 checksum as your NamePassword. <br />
<br />
<br />
<br />
5. Consider using the following settings under [Misc] in server.ini: <br />
Quote:<br />
AllowPrerelease=1 <br />
// 0 = People with newer Continuum clients are not allowed to enter <br />
// 1 = People with newer Continuum clients are allowed to enter and play <br />
<br />
ForceContinuumOnly=1 <br />
// 0 = The Continuum client is not required to be able to connect to the zone; old Subspace v1.35 clients will be able to connect <br />
// 1 = The Continuum client is required to be able to connect to the zone <br />
<br />
AllowVIEClients=0 <br />
// 0 = Disalllow people from playing in your zone with the old Subspace v1.35 client <br />
// 1 = Allow people to play in your zone with the old Subspace v1.35 client <br />
<br />
ForceObsceneCheck=1 <br />
// 0 = Normal or obscene checking on usernames is disabled <br />
// 1 = Obscene checking on usernames is enabled <br />
<br />
CheckWeapons=1 <br />
// 1 = Will kick players that are violating the zone security settings through invalid or impossible uses of weapons if SecurityKickoff under [Security] in server.cfg is set to 1 <br />
<br />
CheckFastBombing=1 <br />
// 1 = Will check to see if a player is invalidly firing more bombs than possible<br />
<br />
<br />
<br />
<br />
6. Consider using the following setting for ArenaMode: <br />
Quote:<br />
ArenaMode=5 <br />
// 1 = Any player can create their own subarena <br />
// 2 = Only moderators (Mod) and above can create subarenas <br />
// 3 = Only super moderators (SMod) and above can create subarenas <br />
// 4 = Only system operators (SysOp) can create subarenas <br />
// 5 = All subarenas will use spawn.cfg for settings, only system operators (SysOp) can create subarenas [Default]<br />
Be sure to make a copy of default SVS server.cfg file and rename it to spawn.cfg. By setting it to 5, you will prevent a million *.cfg files from being created in your zone's directory. However, you may need to manually create a *.cfg file for a subarena that you would like to create. I have heard that by setting this to 5, modifying the settings of any subarena (or arena that is not the public arena) will modify server.cfg/spawn.cfg. You may want to play around with this a little to figure out how to create subarenas, but overall -- you will save yourself and your system the trouble of the unnecessary creation of settings configuration files for each subarena that a player ?go's to in your zone.</div>CypherJFhttp://wiki.minegoboom.com/index.php/Troubleshooting_ASSSTroubleshooting ASSS2011-05-29T08:37:28Z<p>Cheese: </p>
<hr />
<div>This page deals with the troubleshooting of the ASSS installation.<br />
<br><br />
If you need help with writing a module, you should read [[Troubleshooting Modules]].<br />
<br><br />
If you need help with configuring your server, you should read [[Server Setup]].<br />
<br><br />
If you need help with arena settings, you should read [[Complete Settings]].<br />
<br />
==Potential issues==<br />
<pre><br />
I <cmod> loading C module 'capman' from 'internal'<br />
W <config> Can't find file for arena '(null)', name 'groupdef/mod.txt'<br />
W <config> Can't find file for arena '(null)', name 'groupdef/smod.txt'<br />
W <config> Can't find file for arena '(null)', name 'groupdef/sysop.txt'<br />
W <config> Can't find file for arena '(null)', name 'groupdef/sysop.txt'<br />
W <config> Can't find file for arena '(null)', name 'groupdef/default.txt'<br />
I <cmod> loading C module 'mapnewsdl' from 'internal' <br />
</pre><br />
OR<br />
<pre><br />
W <mapdata> {0} error finding or reading level file<br />
W <mapnewsdl> {0} can't load level file, falling back to tinymap.lvl<br />
</pre><br />
OR<br />
<pre><br />
W <mapnewsdl> news file 'news.txt' not found in current directory<br />
</pre><br />
If you are seeing the above, it is possible that the files do not exist.<br />
However, it is also possible that you have a file permissions error, in which you can check with ls -l.<br />
If it is a permissions error, you can fix it using chmod.<br />
<br><br />
<br />
<pre><br />
I <cmod> loading C module 'persist' from 'scoring'<br />
db_env_create: Permission denied<br />
E <cmod> error loading module 'persist'<br />
Unrecoverable error (5): Error in loading module 'scoring:persist'<br />
*** ASSS exited: Error loading modules <br />
</pre><br />
If you are seeing the above, it is possible that you have accidentally copied over your win32 database files into your linux setup, or that the files have become corrupted.<br />
This can be fixed by simply deleting all the files in the /data folder.<br />
<br />
[[Category:ASSS]]<br />
[[Category:Guides]]</div>Cheesehttp://wiki.minegoboom.com/index.php/Installing_ASSS_on_LinuxInstalling ASSS on Linux2011-05-29T07:53:52Z<p>Cheese: </p>
<hr />
<div>If installed, you should find the locations of your Python, MySQL, and other dependencies before you begin.<br />
<br><br />
First, you need to clone the files from the ASSS repository.<br />
*hg clone https://bitbucket.org/grelminar/asss ../asss<br />
<br><br />
Then, after the files have transferred, you will need to build the program files from source code.<br />
*cd src<br />
*mv system.mk.dist system.mk<br />
<br><br />
If you have MySQL, Python, or BerkleyDB installed, you must point the compiler at them.<br />
*vim system.mk<br />
Find the following lines and change them to their respective locations<br />
*DB_HOME = /usr<br />
*MYSQL_HOME = /opt/mysql<br />
*PYTHON_HOME = /usr<br />
<br><br />
If you do NOT have MySQL, Python, or BerkleyDB installed, you must comment out the following lines, by adding a # in front of them:<br />
*have_bdb := yes<br />
*have_mysql := yes<br />
*have_python := yes<br />
<br><br />
Then build the files.<br />
*make<br />
You will then get to watch a nice wall of spam.<br />
<br><br />
Because the developers wanted to be able to update everything on a server already running ASSS, you must now copy all the files into their proper locations.<br />
*cd dist<br />
*mv arenas ../arenas<br />
*mv clients ../clients<br />
*mv conf ../conf<br />
*mv maps ../maps<br />
*mv news.txt ../news.txt<br />
*mv scrty ../scrty<br />
*mv scrty1 ../scrty1<br />
<br><br />
Since the security module does not exist yet, you will have to go into modules.conf<br />
*comment out security:security<br />
*comment out security:enc_cont<br />
*uncomment enc_null<br />
<br><br />
Since the scoring module apparently does not exist yet, you will have to copy scoring.so from a preexisting server into your bin directory.<br />
*new server owners are screwed<br />
*all scoring:* are already commented out <br />
*hope you don't like points<br />
<br><br />
Update ASSSHOME with the path to your ASSS root directory.<br />
*cd scripts<br />
*vim run-asss<br />
For ease of access, you may want to move the run-asss script to the root directory.<br />
*mv run-asss ../run [optional, update ASSSHOME]<br />
<br><br />
After you have completed the installation, you must now configure your server.<br />
<br><br />
[[Server Setup]]<br />
<br />
[[Category:ASSS]]<br />
[[Category:Guides]]</div>Cheesehttp://wiki.minegoboom.com/index.php/Installing_ASSSInstalling ASSS2011-05-29T07:28:11Z<p>Cheese: </p>
<hr />
<div>Installation of an ASSS server will differ on the type of server you are running.<br />
<br />
Before beginning, you should probably read the '''userguide''' located in /doc. It's probably most important to read the "File Layout" section, which explains where the important files reside when you extract the ASSS package.<br />
<br />
If you are having issues installing ASSS, you may want to read [[Troubleshooting ASSS]].<br />
<br />
==Platform==<br />
* [[Installing ASSS on Windows]]<br />
* [[Installing ASSS on Linux]]<br />
* [[Installing ASSS on Apple]]<br />
<br />
[[Category:ASSS]]<br />
[[Category:Guides]]</div>Cheese