ASSS Wiki - User contributions [en]

Sysop Guide

2008-05-10T18:22:31Z

Smong: corrected 2 spelling mistakes. not sure about "Creating New Arenas", looks like the 2 commands do the same thing?

This is a guide for sysop functions that are very basic. Stuff such as adding players to modlist and changing maps.

===Adding New Staffer to Staff List===

<pre><nowiki>*getmodlist</nowiki></pre>

You will recieve a modlist.txt. Open it up and you will see something like...
<pre>
/// Senior Refs /// <Title of group
//Maeniel+ <Name of staffer
//+Maeniel+:4v4 <Arena of power
//+Name:Arena <Arena of power
</pre>
Just rename all the above to suit your zone. When complete save the file and then...

<pre><nowiki>*putmodlist</nowiki></pre>

Will take about 2 minutes to update then have the staffer re-login.

===Adding LVZs===

<pre><nowiki>*getfile server.cfg</nowiki></pre> server is our default, for an arena you will need the name of your arena .cfg. Example: subarena1.cfg

Scroll down till you see LevelFiles, you will see a list of all your enabled lvz's, simply add the name of your lvz to the file and then...

<pre>LevelFiles=lvzname.lvz,lvzname2.lvz,lvzname3.lvz,lvzname4.lvz,lvzname5.lvz</pre>

<pre><nowiki>*putfile server.cfg</nowiki></pre>

After you've done this feel free to upload you lvz's to put with

<pre><nowiki>*putfile lvzname.lvz</nowiki></pre>

It takes a couple of minutes again to upload but you'll see when it's up as you re-enter the zone there will be a new download.

Note: you only need to do the LevelFiles part for every new lvz, after it's up there skip all the steps except *putfile lvzname.lvz

===Uploading new map===

Simply

<pre><nowiki>*putfile mapname.lvl</nowiki></pre>

It'll kick everyone and just log back in. Make sure map name is the same as the arena. This will only be different in the case of your own public map (first one as you enter) so find out what yours is.

===Creating New Arenas===

Simply go to the name of the new arena and

<pre><nowiki>*putfile mapname.lvl</nowiki></pre>

After this you will be kicked, re-login go back to the arena and

<pre><nowiki>?setlevel mapname</nowiki></pre>

Mapname should be the same as setlevel name.

[[Category: Subgame]]
[[Category: Guides]]

Sysop Guide

2008-05-10T18:19:01Z

Smong: adding categories so something links to this page

This is a guide for sysop functions that are very basic. Stuff such as adding players to modlist and changing maps.

===Adding New Staffer to Staff List===

<pre><nowiki>*getmodlist</nowiki></pre>

You will recieve a modlist.txt. Open it up and you will see something like...
<pre>
/// Senior Refs /// <Title of group
//Maeniel+ <Name of staffer
//+Maeniel+:4v4 <Arena of power
//+Name:Arena <Arena of power
</pre>
Just rename all the above to suit your zone. When complete save the file and then...

<pre><nowiki>*putmodlist</nowiki></pre>

Will take about 2 minutes to update then have the staffer re-login.

===Adding LVZs===

<pre><nowiki>*getfile server.cfg</nowiki></pre> server is our default, for an arena you will need the name of your arena .cfg. Example: subarena1.cfg

Scroll down till you see LevelFiles, you will see a list of all your enabled lvz's, simply add the name of your lvz to the file and then...

<pre>evelFiles lvzname.lvz,lvzname2.lvz,lvzname3.lvz,lvzname4.lvz,lvzname5.lvz,=</pre>

<pre><nowiki>*putfile server.cfg</nowiki></pre>

After you've done this feel free to upload you lvz's to put with

<pre><nowiki>*putfile lvzname.lvz</nowiki></pre>

It takes a couple of minutes again to upload but you'll see when it's up as you re-enter the zone there will be a new download.

Note: you only need to do the LevelFiles part for every new lvz, after it's up there skip all the steps except *putfile lvzname.lvz

===Uploading new map===

Simply

<pre><nowiki>*putfile mapname.lvl</nowiki></pre>

It'll kick everyone and just log back in. Make sure map name is the same as the arena. This will only be different in the case of your own public map (first one as you enter) so find out what yours is.

===Creating New Arenas===

Simply go to the name of the new arena and

<pre><nowiki>*putfile mapname.lvl</nowiki></pre>

After this you will be kicked, re-login go back to the arena and

<pre><nowiki>?setelevl mapname</nowiki></pre>

Mapname should be the same as setlevel name.

[[Category: Subgame]]
[[Category: Guides]]

Ball Friction

2008-03-10T13:17:51Z

Smong: fixed another code tidying typo (good job no one has seems to have seen this yet)

<pre>
fireball()
{
ball.frictiontimer = 1000000;
}

// call this per tick
updateball()
{
if (ball.xspeed || ball.yspeed)
{
int workfriction = ball.frictiontimer / 1000;
ball.xspeed = ball.xspeed * workfriction / 1000;
ball.yspeed = ball.yspeed * workfriction / 1000;

ball.frictiontimer -= cfg_friction;
if (ball.frictiontimer < 0)
ball.frictiontimer = 0;
}
}
</pre>

[[Category:Game Intricacies]]

Ball Friction

2008-03-09T22:49:21Z

Smong: adding category

<pre>
fireball()
{
ball.frictiontimer = 1000000;
}

// call this per tick
updateball()
{
if (ball.xspeed && ball.yspeed)
{
int workfriction = ball.frictiontimer / 1000;
ball.xspeed = ball.xspeed * workfriction / 1000;
ball.yspeed = ball.yspeed * workfriction / 1000;

ball.frictiontimer -= cfg_friction;
if (ball.frictiontimer < 0)
ball.frictiontimer = 0;
}
}
</pre>

[[Category:Game Intricacies]]

Ball Friction

2008-03-09T17:00:02Z

Smong: renamed a variable to make it more obvious

Physics

2008-03-09T16:56:41Z

Smong: added ball friction

[[SubSpace]] works on its own special unit scales. This is a collection of observed units and other special physics that SubSpace uses.

; Bounce Formula : SpeedAfter = SpeedBefore * (16 / BounceFactor) (See [[Misc Settings]].)

; Rotation : 90Â° rotation in 1/100th of a second, ''ie: Set rotation to 400, can do a full rotation of 360Â° in one second.''

:: In packets, rotation of a player's ship is a number 0-39... where 0 is straight up and proceeding clockwise. This corresponds to which of the 40 degree graphics to display.

: degrees per tick = rotation_setting / 1000

; Speed : Pixels traveled in 10 seconds.

: pixels per tick = speed_setting / 1000

; Thrust : '''Speed''' increased every 1/100th of a second.

:: ''Sample: Thrust of 10 applied for a second increases your speed by 1000''

; Tick : 1/100th of a second, ''i.e. 0.01s or 10ms.''

; Recharge : Amount of energy units gained in 10 seconds.

; Ball Friction : The amount subtracted from a timer per tick. This timer is initialised to 1 million when the ball is fired, and multiplied with the ball x and y speeds separately on each tick. See also [[Ball Friction]].

[[Category:Game Intricacies]]

Ball Friction

2008-03-09T16:54:21Z

Smong: oops, fixed mistake when I was tidying up the code

<pre>
fireball()
{
ball.workfriction = 1000000;
}

// call this per tick
updateball()
{
if (ball.xspeed && ball.yspeed)
{
int workfriction = ball.workfriction / 1000;
ball.xspeed = ball.xspeed * workfriction / 1000;
ball.yspeed = ball.yspeed * workfriction / 1000;

ball.workfriction -= cfg_friction;
if (ball.workfriction < 0)
ball.workfriction = 0;
}
}
</pre>

Ship Settings

2008-03-09T16:51:27Z

Smong: /* SoccerBallFriction */ linked to ball friction

'''[Warbird] [Javelin] [Spider] [Leviathan] [Terrier] [Weasel] [Lancaster] [Shark]'''<br>
These settings determine the properties of each of the eight ships. These go in an arena's .[[cfg file]] for [[subgame]] and in [[arena.conf]] for [[ASSS]]. Ship names themselves can be changed with [[shipinfo.dat]].

<div style="float: right; margin-left: 20px; margin-bottom: 20px">__TOC__</div>

=== InitialRotation ===
''Datatype:'' 90°/ second / 100 (That is, 400 for a full rotation in 1s).

Initial rotation rate of the ship.

=== InitialThrust ===
''Datatype:'' Speed / second / 10.

Initial thrust of ship.

=== InitialSpeed ===
''Datatype:'' Pixels / second / 10.

Initial speed of ship. Note that 0 will prevent the ship from moving without afterburners or a speed upgrade.

=== InitialRecharge ===
''Datatype:'' Energy / second / 10.

Initial recharge rate.

=== InitialEnergy ===
''Datatype:'' Energy.

Initial amount of energy that the ship can have.

=== MaximumRotation ===
''Datatype:'' 90°/(seconds / 100) (That is, 400 for a full rotation in 1s).

Maximum (with upgrades) rotation rate of the ship.

=== MaximumThrust ===
''Datatype:'' Speed / second / 10.

Maximum (with upgrades) thrust of ship.

=== MaximumSpeed ===
''Datatype:'' Pixels / seconds / 10.

Maximum (with upgrades) speed of ship.

=== MaximumRecharge ===
''Datatype:'' Energy / seconds / 10. (That is, 10 means 1 energy per second.)

Maximum (with upgrades) recharge rate, or how quickly this ship recharges its energy.

=== MaximumEnergy ===
''Datatype:'' Unknown.

Maximum (with upgrades) amount of energy that the ship can have.

=== UpgradeRotation ===
''Datatype:'' 90°/(seconds / 100) (That is, 400 for a full rotation in 1s).

Amount added per Rotation Upgrade Prize.

=== UpgradeThrust ===
''Datatype:'' Speed / second / 10.

Amount added per Thruster Upgrade Prize.

=== UpgradeSpeed ===
''Datatype:'' Pixels / seconds / 10.

Amount added per Speed Upgrade Prize.

=== UpgradeRecharge ===
''Datatype:''Energy / seconds / 10..

Amount added per Recharge Upgrade Prize.

=== UpgradeEnergy ===
''Datatype:'' Energy.

Amount added per Energy Upgrade Prize.

=== CloakStatus ===
''Datatype:'' Enumeration.

Whether ships can to receive [[Cloak]].
* 0 = no
* 1 = yes
* 2 = yes & starts with prize

=== StealthStatus ===
''Datatype:'' Enumeration.

Whether ships can to receive [[Stealth]].
* 0 = no
* 1 = yes
* 2 = yes & starts with prize

=== XRadarStatus ===
''Datatype:'' Enumeration.

Whether ships can to receive [[X-Radar]].
* 0 = no
* 1 = yes
* 2 = yes & starts with prize

=== AntiWarpStatus ===
''Datatype:'' Enumeration.

Whether ships can receive [[AntiWarp]].
* 0 = no
* 1 = yes
* 2 = yes & starts with prize

=== CloakEnergy ===
''Datatype:'' Energy / second / 10 (0 to 32000).

Amount of energy required to have '''Cloak''' activated.

=== StealthEnergy ===
''Datatype:'' Energy / second / 10 (0 to 32000).

Amount of energy required to have '''Stealth''' activated.

=== XRadarEnergy ===
''Datatype:'' Energy / second / 10 (0 to 32000).

Amount of energy required to have '''X-Radar''' activated.

=== AntiWarpEnergy ===
''Datatype:'' Energy / second / 10 (0 to 32000).

Amount of energy required to have '''Anti-Warp''' activated.

=== InitialRepel ===
''Datatype:'' Count.

[[Repel]]s given to ships when they spawn.

=== InitialBurst ===
''Datatype:'' Count.

[[Burst]]s given to ships when they spawn.

=== InitialBrick ===
''Datatype:'' Count.

[[Brick]]s given to ships when they spawn.

=== InitialRocket ===
''Datatype:'' Count.

[[Rocket]]s given to ships when they spawn.

=== InitialThor ===
''Datatype:'' Count.

[[Thor's Hammer]]s given to ships when they spawn.

=== InitialDecoy ===
''Datatype:'' Count.

[[Decoy]]s given to ships when they spawn.

=== InitialPortal ===
''Datatype:'' Count.

[[Portal]]s given to ships when they spawn.

=== InitialGuns ===
''Datatype:'' Weapon level (0 to 3).

[[Bullet|Gun]] level given to ships at respawn. Note that a ship cannot start with L4 guns.

=== InitialBombs ===
''Datatype:'' Weapon level (0 to 3).

[[Bomb]] level given to ships at respawn. Note that a ship cannot start with L4 bombs.

=== RepelMax ===
''Datatype:'' Count.

Maximum '''Repels''' a ship can store. Any Repel prizes after this will be ignored.

=== BurstMax ===
''Datatype:'' Count.

Maximum '''Bursts''' a ship can store. Any Repel prizes after this will be ignored.

=== DecoyMax ===
''Datatype:'' Count.

Maximum '''Decoys''' a ship can store. Any Repel prizes after this will be ignored.

=== RocketMax ===
''Datatype:'' Count.

Maximum '''Rockets''' a ship can store. Any Repel prizes after this will be ignored.

=== ThorMax ===
''Datatype:'' Count.

Maximum '''Thor's Hammers''' a ship can store. Any Repel prizes after this will be ignored.

=== BrickMax ===
''Datatype:'' Count.

Maximum '''Bricks''' a ship can store. Any Repel prizes after this will be ignored.

=== PortalMax ===
''Datatype:'' Count.

Maximum '''Portals''' a ship can store. Any Repel prizes after this will be ignored.

=== MaxGuns ===
''Datatype:'' Weapon level (0 to 3).

Maximum '''gun''' level a ship can have. Note that a ship cannot have L4 guns without a flag upgrade.

=== MaxBombs ===
''Datatype:'' Weapon level (0 to 3).

Maximum '''bomb''' level a ship can have. Note that a ship cannot have L4 bombs without a flag upgrade.

=== BulletFireEnergy ===
''Datatype:'' Energy.

Base energy it takes a ship to fire a bullet. ''Formula:'' EnergyUsed = GunLevel * BulletFireEnergy. So this setting is for an L1 bullet, and is doubled for L2, and so on.

=== BulletSpeed ===
''Datatype:'' Pixels / second / 10.

How fast bullets travel.

=== BulletFireDelay ===
''Datatype:'' Seconds / 100.

Delay before a ship can fire another weapon after it fires a bullet.

=== MultiFireEnergy ===
''Datatype:'' Energy.

Energy it takes a ship to fire a set of multifire bullets. ''Formula:'' EnergyUsed = GunLevel * MultiFireEnergy.

=== MultiFireDelay ===
''Datatype:'' Seconds / 100.

Delay before a ship can fire another weapon after it fires a set of multifire bullets.

=== MultiFireAngle ===
''Datatype:'' Rotation Points / 1000. (''Note:'' One rotation point equals exactly 9°.)

Angle spread between multi-fire bullets and standard forward-firing bullets.

=== DoubleBarrel ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether ships fire double-barrel bullets.

=== BombFireEnergy ===
''Datatype:'' Energy.

Amount of energy it takes a ship to fire a bomb.

=== BombFireEnergyUpgrade ===
''Datatype:'' Energy.

Extra energy it takes a ship to fire an upgraded bomb. ''Formula:'' EnergyUsed = BombFireEnergy + (BombLevel - 1) * BombFireEnergyUpgrade.

=== BombThrust ===
''Datatype:'' Unknown.

Amount of back-thrust (recoil) this ship receives when firing a bomb.

=== BombBounceCount ===
''Datatype:'' Count.

Times a bomb fired by this ship can bounce before it explodes on impact

=== BombSpeed ===
''Datatype:'' Pixels / seconds / 10.

How fast bombs fired by this ship travel.

=== BombFireDelay ===
''Datatype:'' Seconds / 100.

Delay before this ship can fire another weapon after it fires a bomb.

=== EmpBomb ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether this ship fires EMP bombs.

=== SeeBombLevel ===
''Datatype:'' Weapon Level (0 to 4).

Lowest level of bombs this ship can see on radar. ''Special Value:'' 0 = no bombs on radar. (Continuum .36+)

=== MaxMines ===
''Datatype:'' Count.

Maximum number of mines this ship can place.

=== SeeMines ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether ships see mines on radar.

=== LandmineFireEnergy ===
''Datatype:'' Energy.

Energy it takes this ship to place an L1 mine.

=== LandmineFireEnergyUpgrade ===
''Datatype:'' Energy.

Extra energy it takes to place an upgraded landmine. ''Formula:'' EnergyUsed = LandmineFireEnergy + (BombLevel - 1) * LandmineFireEnergyUpgrade.

=== LandmineFireDelay ===
''Datatype:'' Seconds / 100.

Delay before a ship can fire another weapon after it drops a landmine.

=== ShrapnelMax ===
''Datatype:'' Count (0 to 31).

Maximum shrapnel pieces released from this ship's bombs.

=== ShrapnelRate ===
''Datatype:'' Count (0 to 31).

Additional shrapnel pieces gained by a 'Shrapnel Upgrade' prize.

=== BurstSpeed ===
''Datatype:'' Pixels / seconds / 10.

How fast the burst "shrapnel" move for this ship.

=== BurstShrapnel ===
''Datatype:'' Count.

Burst shrapnel released when this ship fires a [[Burst]].

=== TurretThrustPenalty ===
''Datatype:'' Unknown.

This ship's thrust is decreased this much when a turret it riding.

=== TurretSpeedPenalty ===
''Datatype:'' Pixels / second / 10.

This ship's speed is decreased this much when a turret it riding.

=== TurretLimit ===
''Datatype:'' Count.

Number of turrets allowed on this ship.
If you don't want ships to attach, set TurretLimit to 0.

=== RocketTime ===
''Datatype:'' Seconds / 100.

How long a [[Rocket]] lasts.

=== InitialBounty ===
''Datatype:'' Count.

Number of prizes given to this ship when it spawns.

=== AttachBounty ===
''Datatype:'' Points.

Bounty required by ships to attach to another ship to form a turret.

=== AfterburnerEnergy ===
''Datatype:'' Energy.

Energy required to have 'Afterburners' activated.

=== DisableFastShooting ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether firing bullets, bombs, or thors is disabled after using afterburners. (Continuum .36+)

=== Radius ===
''Datatype:'' Pixels.

The ship's radius from center to outside. ''Special Value:'' 0 = 14 pixels. (Continuum .37+)

=== DamageFactor ===
''Datatype:'' Factor (0 to 5000).

How likely a the ship is to lose a prize when damaged. (1 is extremely likely, 5000 is almost never.) ''Special Value:'' 0 = never.

=== PrizeShareLimit ===
''Datatype:'' Points.

Maximum bounty that this ship can receive by Team Prizes.

=== SuperTime ===
''Datatype:'' Seconds / 100.

How long [[Superpower]] lasts for this ship. The actual time is random up to this value.

=== ShieldsTime ===
''Datatype:'' Seconds / 100.

How long [[Shields]] last for this ship.

=== Gravity ===
''Datatype:'' Factor.

Modifies radius over which a [[wormhole]]'s gravity has an effect.

''Formula:'' EffectRadius = 1.325 * Gravity ^ 0.507. That is, a wormhole will have an effect over 31 tiles if this is set to 500.

The setting for Warbird also controls how far out bombs/mines are effected by wormholes.

=== GravityTopSpeed ===
''Datatype:'' Pixels / seconds / 10.

How much this ship's maximum speed is increased when under the influence of a wormhole's gravity. Note that '''this does not replace the previous speed'''.

=== SoccerBallFriction ===
''Datatype:'' Unknown.

Amount of [[Ball Friction|friction]] on the [[soccer]] ball when it is not carried by a ship.

=== SoccerBallProximity ===
''Datatype:'' Pixels.

How close the ship must be in order to pick up a ball. Set this to 0 to disallow the ship from picking up a ball.

=== SoccerBallSpeed ===
''Datatype:'' Pixels / seconds / 10.

Initial speed given to the ball when fired by this ship.

=== SoccerThrowTime ===
''Datatype:'' Seconds / 100.

Time player has to carry soccer ball before it automatically fires (out the back of the ship).

If this is 0 or 32768 or greater then carry time is unlimited and no timer is shown on the players screen.

[[Category: Settings]]

Ball Friction

2008-03-09T16:50:11Z

Smong: initial page

<pre>
fireball()
{
ball.workfriction = 1000000;
}

// call this per tick
updateball()
{
if (ball.xspeed && ball.yspeed)
{
int workfriction = ball.workfriction / 1000;
ball.xspeed = ball.xspeed * workfriction / 1000;
ball.yspeed = ball.yspeed * workfriction / 1000;

ball.workfriction--;
if (ball.workfriction < 0)
ball.workfriction = 0;
}
}
</pre>

Talk:Core Protocol

2007-10-13T20:18:26Z

Smong: /* Packets can be nested(?) */ another reason

== Note on 0x0a00 packet ==
I think when asss sends these the total size of each packet is 480 bytes, with the last packet in the stream being the remainder (read: less than 480 bytes).

correct [[User:BaK|BaK]] 06:34, Jan 12, 2007 (PST)

== Note on login response ==
sending back the original key without change means no encryption, both to 1.34 and continuum

== Packets can be nested(?) ==
Revision: http://wiki.minegoboom.com/index.php?title=Core_protocol&oldid=5804

Revision By: Doc Flabby

[[User:Smong|Smong]] 13:11, October 13, 2007 (PDT) says:
:I'm not sure on this, I think at one point I decided only 00 03 (reliable) and 00 0e (clustered) packets are allowed to contain other core packets. Or put another way, the fragmented packets (small and large streams) cannot contain another core packet. This is important when it comes to implementing a core protocol stack.

:An implementation could use a packet object which contains a 520 byte buffer, you could have these packet objects allocated statically or from a resizable pool. If this method is used it is impossible to pass a packet larger than 520 bytes through the core protocol stack without some ugly special case code.

:Also since you can only have one small and one large stream at a time you do not need to keep a list of streams. You only need 2 static variables, one for each type of stream (most likely a struct containing a pointer to a dynamically allocated buffer).

:Finally ASSS does not expect a core packet to be inside a fragmented packet (it will just ignore it by default).

[[User:Smong|Smong]] 13:18, October 13, 2007 (PDT) says:
:Additionally I think this phrase already in the page "There is support for reliable ordered packets, large packets and cluster packets" covers the "Packets can be nested (They are usually processed recursively)" phrase. The original intention of the bullet points was for important specifications that would look awkward written as a complete sentence.

Talk:Core Protocol

2007-10-13T20:11:00Z

Smong: Packets can be nested(?)

Directory server

2007-10-11T19:16:54Z

Smong: /* Directory Server Software */ added skydir, I might get back to reformatting this section

A '''Directory server''' is provides a way for [[client]]s to retreive a list of [[zone]]s that are currently online and running. These servers provide information on any zones that have registered with the directory server. This information includes the name and description of the zone, the ip and port that should be used to connect to the zone, the server version, whether or not a billing server is connected to the zone, as well as the number of players in the zone.

Both [[SubSpace]] and [[Continuum]] [[client|clients]] are capable of saving this information locally on the PC in the [[zone.dat]] file.

== Communication ==

A [[client]] can connect to a directory server to retrieve a list of active zones. Client's connect to UDP port 4990 using the [[Directory Client Protocol]].

A [[zone]] can register itself with one or more directory servers so players can find the zone. It utilizes the [[Directory Game Server Protocol]] on UDP port 4991.

== Directory Server Software ==

A variety of directory server's are available for you to download.

* SkyDir by [[User:Doc flabby|Doc Flabby]], written in Python with SQLite.
** http://forums.minegoboom.com/viewtopic.php?t=7590

=== Windows ===

* Public Directory Server software v0.3 (by [[PriitK]])
** http://www.subspacedownloads.com/index.php?act=list&cat=3

* SubSpace Directory Server 4 (by [[catid]])
** http://www.mervbot.com/files/DDirServ.zip

* JEDirectoryServer (by ''unknown'')
** http://www.subspacedownloads.com/index.php?act=list&cat=3

=== Linux ===

* SubSpace Directory Server 4 (by [[catid]]), ported to Linux by [[User:Doc flabby|Doc Flabby]].
** http://forums.minegoboom.com/viewtopic.php?p=74575

[[Category: Definitions]]
[[Category: Servers]]

Directory server

2007-10-11T19:12:39Z

Smong: /* Communication */ grammar fix, wasn't sure if it was intended to be singular or plural so catered for both

A '''Directory server''' is provides a way for [[client]]s to retreive a list of [[zone]]s that are currently online and running. These servers provide information on any zones that have registered with the directory server. This information includes the name and description of the zone, the ip and port that should be used to connect to the zone, the server version, whether or not a billing server is connected to the zone, as well as the number of players in the zone.

Both [[SubSpace]] and [[Continuum]] [[client|clients]] are capable of saving this information locally on the PC in the [[zone.dat]] file.

== Communication ==

A [[client]] can connect to a directory server to retrieve a list of active zones. Client's connect to UDP port 4990 using the [[Directory Client Protocol]].

A [[zone]] can register itself with one or more directory servers so players can find the zone. It utilizes the [[Directory Game Server Protocol]] on UDP port 4991.

== Directory Server Software ==

A variety of directory server's are available for you to download.

=== Windows ===

* Public Directory Server software v0.3 (by [[PriitK]])
** http://www.subspacedownloads.com/index.php?act=list&cat=3

* SubSpace Directory Server 4 (by [[catid]])
** http://www.mervbot.com/files/DDirServ.zip

* JEDirectoryServer (by ''unknown'')
** http://www.subspacedownloads.com/index.php?act=list&cat=3

=== Linux ===

* SubSpace Directory Server 4 (by [[catid]]), ported to Linux by [[User:Doc flabby|Doc Flabby]].
** http://forums.minegoboom.com/viewtopic.php?p=74575

[[Category: Definitions]]
[[Category: Servers]]

Continuum Encryption

2007-10-11T19:09:21Z

Smong: some rewording

The [[Continuum]] encryption algorithm was developed by [[PriitK]] to combat cheating which plagued the original [[SubSpace]] client and server. The actual implementation is supposed to be secret. Only releases of the client [[Continuum]], servers [[Subgame]] and [[ASSS]] support Continuum encryption.

[[Category:Game Intricacies]]

Core Protocol

2007-10-09T19:04:31Z

Smong: took out the tcp protocol part to avoid distracting from the main article

This protocol is UDP and bi-directional. It can be thought of as another layer within an application's network layer. [[Subgame]], [[ASSS]], [[Continuum]], VIE's [[SubSpace]] client, the [[Directory server]], and some [[Billing Server|Billing Servers]] utilize this protocol.

There is support for reliable ordered packets, large packets and cluster packets.

*The maximum packet size is 520 bytes
*All integers are little endian
*All core packets begin with the type byte 0x00

<pre>
0x01 login
offset size comment
0 1 type 0x00
1 1 type 0x01
2 4 client key
6 2 protocol version (vie = 0x01, ctm = 0x11)

0x02 login response
offset size comment
0 1 type 0x00
1 1 type 0x02
2 4 ~client key (negative)

0x03 reliable header
offset size comment
0 1 type 0x00
1 1 type 0x03
2 4 packet id
6 ? payload (514 max)

0x04 reliable acknowledge
offset size comment
0 1 type 0x00
1 1 type 0x04
2 4 packet id

0x05 sync
offset size comment
0 1 type 0x00
1 1 type 0x05
2 4 local time
6 4 packets sent
10 4 packets received

0x06 sync response
offset size comment
0 1 type 0x00
1 1 type 0x06
2 4 time from last received 0x05 packet
6 4 server time

0x07 disconnect
offset size comment
0 1 type 0x00
1 1 type 0x07

0x08 small chunk
offset size comment
0 1 type 0x00
1 1 type 0x08
2 ? payload (expect 472 max)
keep appending payloads until 0x09 chunk tail is received

0x09 chunk tail
offset size comment
0 1 type 0x00
1 1 type 0x09
2 ? payload (expect 472 or less)
append this payload then process contents as a non-core packet

0x0A stream
offset size comment
0 1 type 0x00
1 1 type 0x0A
2 4 total length of all segments
6 ? payload
keep appending payloads until total length is reached then process contents as
a non-core packet.

0x0B cancel stream request
offset size comment
0 1 type 0x00
1 1 type 0x0B

0x0C cancel stream acknowledge
offset size comment
0 1 type 0x00
1 1 type 0x0C

0x0E cluster
offset size comment
0 1 type 0x00
1 1 type 0x0E
2 1 length
3 ? payload with length as above
packet repeats from offset 2 until end, process contents as arbitrary packet
</pre>

[[Category: Protocol]]

ChatGui

2007-08-12T17:11:53Z

Smong: initial page, very brief, just to acknowledge its existence

'''ChatGui''' is a chatnet client written by [[User:D1st0rt|D1st0rt]] in C#.

More information and downloads including source are available at http://forums.minegoboom.com/viewtopic.php?t=7623

[[Category: ChatNet Clients]]

User:Smong

2007-08-12T17:09:22Z

Smong: misc updates

Smong's website http://toktok.sscentral.com/ has some [[ASSS]] and [[MERVBot]] plugins with source code. There is also some other misc stuff related to SubSpace.

=== Programs written by Smong ===
*[[DustEd]] - A basic map editor.
*[[confclean]] - A .conf file cleaner.
*[[ChatNet]] - A Java asss chat client.
*[[NAAP]] - Newbie ASSS Admin Program, a Java tool to setup asss on windows.
*[http://forums.minegoboom.com/viewtopic.php?t=4635 Blender rotation script], for making 3D shipsets.
*[http://forums.minegoboom.com/viewtopic.php?t=4535 FSM] - Font Sheet Maker, can be used with SS/Cont and with map tilesets.
*[http://forums.minegoboom.com/viewtopic.php?t=4367 Nebula] - GUI directory client.

=== ASSS arenas by Smong ===
Zones (in chronological order):
*Battlezone (aka BZ)
**Parts of WZCTF bot cloned in modules
*Grand Theft Auto (aka GTA)
**Car jacking
*Unreal Tournament (aka UT)
**Adrenaline
**Bombrun
**CTF
**Weapon pickups
*Pirates!
**Merchants
**Towns
*Command and Conquer (aka CNC)
** Destructible sentry turrets
** Destructible base structures

Misc event modules (alphabetical):
*Avalanche
*Asteroids
*Dodgeball
*Elim
*Golf
*Pacman
*Race
*Wipeout

=== Misc ASSS developer's 'you might want to know this' ===
*In the packet callbacks the buffer has been allocated plenty of space, so you can read past the indicated length safely.
*When using amalloc() it will set the memory to all 0's for you.
*When using per-arena/player data that is also all 0'd for you.
*adkey and pdkey are often used as the arena data and player data keys respectively
*Functions with names_like_this() are probably local (ASSS uses local inplace of the static keyword)
*Functions with NamesLikeThis() are probably from an interface
*All your base are belong to us
*The ShipChange callback is broken, despite several requests for grel to fix it
*game_timer/Misc:TimedGame is not fully supported yet (shh)
*The default modules.conf doesn't have scoring:points_periodic, objects or messages
*The default permissions don't have the ?owner command enabled
*<nowiki>*</nowiki>arena has been changed to ?a, <nowiki>*</nowiki>log to ?lastlog [<lines>] [<filter>] and esc+c with ?quickfix [<filter>]
*There is a glitch called lag coma where reliable packets get stuck (30+ players?)
**Supposedly fixed.
*Downloads do take longer than subgame (needs tweaking)
*Autowarp/[[Moveto Module|moveto]] does screw up your aim
*?help got hijacked and it's now used as online commands and settings help.
**There is a patch to make ?help like subgame, moving the command to ?man (short for manual).
*The stock objects doesn't support all targets correctly.

=== Contact ===
*MSN: mp564 at hotmail
*ICQ: 123727323

=== Some notes on the Soccer:CapturePoints setting ===
<pre>
capturepoints: positive
each goal starts with this many tokens
scoring a goal takes a token from the enemy goal and puts it in your goal
win by all enemies having 0 tokens
enemy has no tokens left: <team goal!> 'Enemy goal had no points to give.' <arena ?score>

capturepoints: negative
when you have this many tokens you win (soccer game over)
each goal starts with 0 tokens
scoring a goal gives you (team/freq) 1 token

capturepoints: non-zero
all modes except mode0: output from ?score sent to whole arena on goal
end of game message: (ding) 'Soccer game over.'

capturepoints: zero
just reward points given
?score does not work
game never ends

?score: mode0, mode3, mode4, mode5, mode6
SCORE: Team0:%d Team1:%d Team2:%d Team3:%d
SCORE: Warbirds:%d Javelins:%d Spiders:%d Leviathans:%d

?score: mode1, mode2
SCORE: Evens:%d Odds:%d
SCORE: Warbirds:%d Javelins:%d

special case: mode0
just reward points given
no tokens lost or gained
game never ends

special case: mode1, mode2
freq's are odds/evens, so spider = warbird etc.
</pre>

[[Category: People]]

NAAP

2007-08-12T17:02:08Z

Smong: initial page

'''Noob ASSS Admin Program''' or '''NAAP''' is a graphical configuration utility for [[ASSS]] written by [[User:Smong|Smong]] in Java.

It's purpose is to hide the alleged complexity of ASSS from newcomers, allowing them to quickly setup a running zone and even import arenas from a subgame zone using a wizard like interface. There is also a built in chatnet client.

It is not intended to provide remote control of ASSS, such as uploading modules and starting/stopping the server.

More information and downloads including source are available at http://forums.minegoboom.com/viewtopic.php?t=6069

[[Category: ChatNet Clients]]

CN-Palm

2007-08-12T16:54:58Z

Smong: initial page, very brief, just to acknowledge its existence

'''CN-Palm''' is a chatnet client written by [[User:Smong|Smong]] in C for Palm OS based devices.

More information and downloads including source are available at http://toktok.sscentral.com/ss-chat.html

[[Category: ChatNet Clients]]

ASSS Chat

2007-08-12T16:52:07Z

Smong: initial page, very brief, just to acknowledge its existence

'''ASSS Chat''' is a chatnet client written by pokemon 2001 in VB.

More information and downloads including source are available at http://forums.minegoboom.com/viewtopic.php?t=3555

[[Category: ChatNet Clients]]

CCC

2007-06-30T22:11:11Z

Smong: removed old link, added note about scripts directory, fixed likely typo

CCC is a chat client using the [[ChatNet Protocol|TCP chat protocol]]. It's written in Python by [[User:grelminar|grelminar]]. It is available in the [[ASSS]] distribution (within the scripts directory).

Features:

* runs in a console window, so it's easy to use over ssh
* auto-reconnecting after disconnection
* complete logging of everything to a file
* double-colon support
* separate windows for different chat channels, mod chat, and private messages
* multiple profile support
* auto-enter commands

[[Category: ChatNet Clients]]

LVZ

2007-06-27T13:11:40Z

Smong: added info on how to add lvz to an arena

An LVZ is a file that can customize an arena beyond simply changing the map with a LVL. An LVZ can contain compressed files, map objects, screen objects, or a combination of the three. The server will send the LVZs to a [[Continuum]] client when it enters an arena for storage in the zone's directory (Continuum\Zones\[Zone Name]) along with the LVLs and news.txt for that zone. The primary way of creating an LVZ is the [http://www.shanky.com/cgi-bin/ryan/download.cgi?lvztoolkit.zip LVZ Toolkit] and the [http://forums.minegoboom.com/viewtopic.php?t=3907 Cross Platform Lvz Toolkit] (which includes bug fixes and has better compression).

Continuum only supports 256 different images in all of your lvz files combined. If you exceed this limit, toggling the 257th image will turn on the 1st image. This is often undesired, so be careful.

== Adding/Replacing Files ==

Adding a file to an LVZ with the same filename (extension does not matter) as a default Continuum image or sound file will replace that file for that arena. For example, placing a file called victoryl.wav in an LVZ will override the standard victory music in that arena. Along with the standard BMP (<tt>.bm2</tt>) and WAV (<tt>.wa2</tt>) formats, Continuum supports [http://www.libpng.org/pub/png/ PNG], GIF, and JPEG — MP3 is ''not'' supported.

Adding a file to an LVZ with a different filename from one of the defaults will make that image available to be placed as a map object or screen object.

Note that files included by themselves (not within an LVZ) will take precedence over ones inside an LVZ. This also means that a user can place a file (say, ship1.bm2) in a zone's folder and it will override any custom ship graphics the zone uses.

== Adding LVZ to an arena ==
LVZ can be set as optional by prefixing a plus (+) before the filename in the settings. Do not rename the actual file.

=== subgame2 ===
Place the .lvz files in the server root directory. Add the filenames separated by commas to the [Misc] LevelFiles= setting inside the arena's .cfg file.

=== ASSS ===
Place the .lvz files in the maps directory or the arena's directory (asss/arenas/<arena name>). Add the filenames separated by commas to the [General] LevelFiles= setting inside arena.conf (asss/arenas/<arena name>/arena.conf).

== Map Objects ==

Map objects are images placed by Continuum at a static location on the [[map]]. They can be animated in the normal way for [[SubSpace]]/Continuum, that is, with horizontal and vertical tiles representing frames. Their display time and display mode (when Continuum will display them) can be customized.

== Screen Objects ==
[[Image:Refpoints.gif|thumb|Click for larger view indicating the locations of the modifiers.]]

Screen objects are images placed by Continuum at a specific point on the screen or a point relative to one of the presets, meaning they will move around with the pilot. Like map objects, they can be animated and their display time and mode can be customized.

== See Also ==
* [[LVZ Format|LVZ File Format]]
* [[LVZ Scripting]]
* [[Continuum Level / Ini Tool]]

[[Category:Definitions]]

Talk:Installing New Modules

2007-06-26T16:35:21Z

Smong: note about mysql path

==zlib==
Add additional info about optionally adding zlib.dll to the linker in step 6 of "With Dev C++"?
--[[User:JoWie|JoWie]]

== mysql ==
If you are compiling mysql.c (or another module that directly requires mysql functions) you may need to add windeps/mysqlinc tothe include directories. --[[User:Smong|Smong]]

This zone is not connected to the central player database

2007-06-04T13:34:58Z

Smong: deleted some waffle

[[Image:Zone_warning.png|thumb|The zone warning]]

When trying to enter a [[zone]] that is not connected to the [[Hosts|SSC-biller]], the [[Continuum]] [[client]] will prompt the user with the following message:
<blockquote>''This zone is not connected to the central player database. You should use a different password for this zone as your passwords may be exposed to zone staff. Do you wish to login using the current password?''</blockquote>
The Continuum client triggers this message as a security mesure, in order to better protect users from username and password theft. It has often been considered a nuisance, as it sometimes scares new players away from non-[[Hosts|SSC]] [[zone]]s.

You can ignore this message at your own risk.

Writing Modules In Python

2007-05-22T10:34:24Z

Smong: /* Trouble shooting */ added error msg

== Basic python module ==
I have tried to comment what is going on in the source. This module demonstrates callbacks, commands and using interfaces.
<pre>
# demo asss python module
# dec 28 2004 smong

# nearly always use this
from asss import *

# get some interfaces
# see chat.h for where I_CHAT comes from, see other .h files for more (fx:
# game.h)
chat = get_interface(I_CHAT)

# a callback
# this function is called when a player enters/leaves, see core.h for PA_???
# constants
def paction(p, action, arena):
# start indenting
if action == PA_ENTERARENA:
# see chat.h for the names of more functions like SendMessage
chat.SendMessage(p, "hello " + p.name)

# tell asss to call 'paction' when CB_PLAYERACTION is signalled
# see .h files for CB_??? names
cb1 = reg_callback(CB_PLAYERACTION, paction)

# a command
# see cmdman.h for what each parameter does
def c_moo(cmd, params, p, targ):
# help text (?help moo)
"""\
Module: <py> demo
Targets: none
a sample command.
"""
chat.SendMessage(p, "moo cows")

# tell asss to call 'c_moo' when a player types ?moo
# note: add cmd_moo to conf/groupdef.dir/default so players have permission to
# use this command.
cmd1 = add_command("moo", c_moo)

# setting chat (or other interfaces), cb* or cmd* to None is equivalent to
# unregistering that item.
</pre>
Save this in bin/demo.py. Then ingame make sure pymod is loaded by using ?lsmod and ?insmod. Then add this module with the following command: ?insmod <py> demo. Re-entering the arena and typing ?moo should do some stuff.

== Code snippets ==
The bread and butter of most custom modules.
=== Callbacks ===
<pre>
from asss import *

chat = get_interface(I_CHAT)

def goal(arena, p, bid, x, y):
chat.SendArenaMessage(arena, "goal.")

cb1 = reg_callback(CB_GOAL, goal)
</pre>

=== Commands ===
Useful for controlling events, fx: ?elim start. In this case the command is ?t1.
<pre>
from asss import *

chat = get_interface(I_CHAT)

# cmd = the name of the command, fx: elim
# params = any parameters, fx: start
# p = who sent the command
# targ = player or arena
def c_mycmd(cmd, params, p, targ):
"""\
some help text
"""
if isinstance(targ, ArenaType):
chat.SendMessage(p, "command sent to public chat")
elif isinstance(targ, PlayerType):
chat.SendMessage(p, "command sent as priv msg to %s" % targ.name)

cmd1 = add_command("t1", c_mycmd)
#where the "t1" is located would be the name of the command, ex: ?t1
</pre>

You can parse integers from the params using the following code:
<pre>
try:
val = int(params)
except ValueError:
# here the conversion of params from a string to an int failed.
# change the next line to 'pass' to silently ignore the conversion error,
# 'return' to exit the function, or 'val = 0' to set a default value to val.
chat.SendMessage(p, "Integer parameter required.")
</pre>

=== Manipulating built-in stats (such as kills/points) ===
This example makes it so team kills don't effect the wins/losses of both players involved.
<pre>
stats = get_interface(I_STATS)

def kill(arena, killer, killed, bty, flags, pts, green):
# This checks to see if the killer killed someone on the same team.
# If so then it will take away a kill from the killer and take away a death from the killed player.
# The scores are updated right away and the stats appear as if you never died.

if killer.freq == killed.freq:
# stats can be incremented...
stats.IncrementStat(killer, STAT_KILLS, -1)

# ...or set to an absolute value
deaths = stats.GetStat(killed, STAT_DEATHS, INTERVAL_RESET)
stats.SetStat(killed, STAT_DEATHS, INTERVAL_RESET, deaths - 1)

# SendUpdates must be called so everyone's F2 box shows the correct values
stats.SendUpdates()

return pts, green

cb1 = reg_callback(CB_KILL, kill)
</pre>
More STAT_* types can be found in statcodes.h. If you look at stats.h you can see there is also an IncrementStat function

=== Per-player/arena data ===
Use this to store game state, player score, etc.
<pre>
def shipchange(p, newship, newfreq):
# prefix mymod_ an abbreviation of your module name to the variable
# so that it doesn't clash with other modules. per arena data works
# in exactly the same way.
p.mymod_lastship = p.ship

cb1 = reg_callback(CB_SHIPCHANGE, shipchange)
</pre>

=== Persistent per-player data ===

<div style="color: red; font-weight: bold; border: thin solid; padding: 5px 5px 5px 5px">Note this has changed since 1.4.2. See bin/fg_turf.py for the latest implementation. Or the example at: http://forums.minegoboom.com/viewtopic.php?p=63321#63321</div>

ASSS has built in mechanisms for saving data per player and per arena across sessions (users logging off or server restarting).

You need to provide three functions that will be called by ASSS to save, restore and clear the data. The example below is a complete module.
<pre>
# each player can save a note that only they can see

from asss import *

chat = get_interface(I_CHAT)

# show and store a note
def c_note(cmd, params, p, targ):
if params:
p.note = params
if p.note:
chat.SendMessage(p, "note: %s" % p.note)
else:
chat.SendMessage(p, "no note set")

cmd1 = add_command("note", c_note)

# return the data to save for player p
# returning None means "don't store a record in the database,
# and delete any record that's there already".
def getpd(p):
return p.note

# restore the data for player p
def setpd(p, d):
p.note = d

# reset/clear the data for player p
def clearpd(p):
p.note = None

mypd = reg_player_persistent(
7890, INTERVAL_FOREVER, PERSIST_GLOBAL,
getpd, setpd, clearpd)
</pre>
Ideally you should load the module when the server starts. Alternatively if you load it dynamically you can kick everyone (not desirable) or alter the code to catch AttributeError when it attempts to read from the per player data ''.note''.

Taking a look at ''reg_player_persistent'' the number ''7890'' is arbitrary, but must be unique for every module using persistent data. Low numbers are reserved for the core modules. ''INTERVAL_FOREVER'' is how long this data will be kept for. Interestingly the INTERVAL_* constants are defined in statcodes.h, not persist.h. ''PERSIST_GLOBAL'' is defined in persist.h. Here are the respective code extracts (as of Feb 7 2005).
<pre>
/* these are the possible intervals */
enum interval_t
{
/* pyconst: enum, "INTERVAL_*" */

/* these are shared between arenas with the same arenagrp */
INTERVAL_FOREVER = 0,
INTERVAL_RESET,
INTERVAL_MAPROTATION,
/* these are not shared between arenas */
INTERVAL_GAME = 5,
INTERVAL_FOREVER_NONSHARED
};
</pre>
<pre>
typedef enum persist_scope_t
{
/* pyconst: enum, "PERSIST_*" */

PERSIST_ALLARENAS,
/* using this for scope means per-player data in every arena */
/* using this for scope means per-arena data will be stored
* per-arena */

PERSIST_GLOBAL
/* using this for scope means per-player data shared among all arenas */
/* using this for scope means per-arena data will be shared among
* all arenas (so it will effectively be global data). */
} persist_scope_t;
</pre>
Note: ASSS must be compiled with the berkeleydb option for persistent data to be available.

=== Attach/Detach ===
Attaching and detaching is similar to load/unload in a C module except it is arena specific. So you can use it to initialise per-arena data.
<pre>
def mm_attach(arena):
# do stuff with arena
def mm_detach(arena):
# undo stuff
</pre>

=== Looping over all players ===
This example counts the number of players in an arena.
<pre>
def count_players(arena):
# a list must be used as all other variables are immutable to
# nested functions.
players = [0]
def cb_count(p):
if p.arena == arena:
players[0] = players[0] + 1
for_each_player(cb_count)
return players[0]
</pre>

=== Timers ===
Good for checking if a game is over yet. '''A reference to the timer is returned and must be retained''' (you can use per-arena data to store it). Losing the reference will cancel the timer.

''initial'' is the time in 1/100th's of a second before the nested function timer() will be called, you can cancel the timer before it is called. ''interval'' is the time gap, again in 1/100th's of a second between all future calls of timer(). So make_hello_timer(100, 200, arena) will make it send the arena message "hello" every 2 seconds starting from 1 second after make_hello_timer() was called.

The third argument to set_timer (''interval'') can be omitted and it will be assumed to be the same as ''initial''.

The parameter ''arena'' is needed in this case because SendArenaMessage() requires an arena parameter.
<pre>
def make_hello_timer(initial, interval, arena):
def timer():
# announce
chat.SendArenaMessage(arena, "hello")
# non-repeating timer. return 1 for it to be called after the next interval
return 0
return set_timer(timer, initial, interval)

def somefunc(arena):
# create a hello timer that will execute after 1 second, and then every
# 2 seconds until cancelled. timers can cancel themselves, see above.
myref = make_hello_timer(100, 200, arena)

# cancel the timer by losing the reference to it
myref = None
</pre>

=== Regions ===
This is untested but it should go something like this:
<pre>
mapdata = get_interface(I_MAPDATA)

# regionname is a string, x and y are map tile coords.
def region_contains(arena, regionname, x, y):
success = 0

rgn = mapdata.FindRegionByName(arena, regionname)

if rgn != None and mapdata.Contains(rgn, x, y):
success = 1

return success
</pre>
It is a good idea to cache ''rgn'' within [[#Per-player.2Farena_data|per-arena data]] so you don't add unecessary load to the server looking it up everytime.

You might come across a region callback when browsing the .h files. This is currently (1.4.2) not available in python.

=== Moving Balls ===
This is untested but it should go something like this:
<pre>
balls = get_interface(I_BALLS)

# xy are in tiles
# bid is ball id (0-7, depends how many balls are in the arena)
def move_ball(arena, bid, x, y):
bd = balldata()
bd.state = BALL_ONMAP
bd.x = x * 16
bd.y = y * 16
bd.xspeed = bd.yspeed = 0
bd.carrier = None
bd.freq = -1
bd.time = current_ticks()
balls.PlaceBall(arena, bid, bd)
</pre>

=== Targets ===
Many of the module interfaces use Targets to specifiy which players should be affected by a function call.
<pre>
# entire arena
tgt = arena

# specific player
tgt = p

# specific freq
tgt = (arena, freq)

# entire zone
tgt = "zone"

# example interface function that requires a tgt
game.WarpTo(tgt, x, y)
</pre>
Currently (asss 1.4.3) list targets are not supported.

== Trouble shooting ==
If code won't run at all check to see if there is a mix of tabs and spaces used for indenting (SyntaxError: invalid syntax). If so convert all indents to the same type (tabs or spaces). It may not be necessary to do this for the entire module, just in affected functions.

Look at the asss console for execution errors (at the time of writing not all errors are relayed to logged in staff), and if that doesn't help, add some chat.SendArenaMessage(ALLARENAS, "i'm at line ...") type messages to locate the buggy piece of code.

[[Category:Module]]
[[Category:Guides]]

Talk:Hosts

2007-05-17T19:11:12Z

Smong: /* Cleanup */ pss move to east coast

[[User:CypherJF|CypherJF]]: Actually I don't think SSN is run by L Chance anymore. I'm not sure the history of it but the latest back I can remember was Altec . running it with Sideburn? Spring/Summer of 2004, Altec . and L Chance brought back SSN using Lord Maucaub's biller system. They shut it back down after HALO switched back to SSZ; and now I believe Dark Mistress / TheBest999 / Cospar / MS-DOS; someone is running it.

[[User:Smong|Smong]]: I think NTC has it now. They keep changing tags which is annoying. For the record I remember them with SSDM and TNT too if you want to stick that in a 'most annoying network decisions ever' page.

[[User:CypherJF|CypherJF]]: Yeah NTC is the Dark Mistress / TheBest999 / Cospar / MS-DOS network.

[[User:Smong|Smong]]:Someone add NTC and SSDT at least. Also I think this page should be called Networks, but that is more jargon I guess and could easily be confused.

[[User:D1st0rt|D1st0rt]]:Whoa 17th is near me? Trench still has a lower ping

== Category? ==

There's already a category called ''Servers'', don't you think this should belong there? I know you couldn't have the short descriptions, but they're kinda hard to keep track of and not that useful. --[[User:Cyan~Fire|Cyan~Fire]]

Well, hmm. We could always make each server its own category, the short desc goes on the category desc, and each zone is added to the specific server category they are on. [[User:Pests|Pests]]

[[User:Smong|Smong]]: I don't think search looks at categories (I feel like I am typing that several times a day).

I wasn't saying remove the page, just saying get rid of the server list, since it'll soon become outdated and is redundant. But, whatever, no biggie. --[[User:Cyan~Fire|Cyan~Fire]]

== Combine Pages? ==

Since there's actually not all that much info to put about each of these servers, how would you feel about me merging all of the individual server pages here? This page could be divided up into Active and Inactive servers, if that's a problem. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: SSZ Subspace Network? I think that needs changing. SSN is still run by L. Chance? Also who nicked the css for the wiki?

== Cleanup ==

[[User:Smong|Smong]]:
I don't like the look of this page. First Servers, I would prefer a page called Hosts or Networks.

Next a table of active networks, columns are: tag, owners + contact, website, billing (yes, own billing/yes, tag of other biller/no biller) and location. <s>A network is considered active if it has its own menu on [http://stats.17thparallel.com stats.17thparallel.com].</s>

[[User:Smong|Smong]] 16:10, Mar 11, 2007 (PDT): A network is any tag with more than 1 zone or has been up for a noticeable period of time.

<table border=1>
<tr><th>Tag</th><th>Operators</th><th>Website</th><th>Billing</th><th>Location</th></tr>
<tr><td>CSSS</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, Central</td></tr>
<tr><td>PSS</td><td>Doc Flabby</td><td>[http://www.playsubspace.com/ www.playsubspace.com]</td><td>unknown</td><td>USA, East</td></tr>
<tr><td>SSCC</td><td>Freakmonger<td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCE</td><td>Luminate <luminate rshl.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCI</td><td>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Central</td></tr>
<tr><td>SSCU</td><td>PriitK <priitk trenchwars.org><br>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Multiple</td></tr>
<tr><td>SSCX</td><td>PriitK <priitk trenchwars.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSDC</td><td>blackjayde <support xtremegaming.net></td><td>[http://ssdc.xtremegaming.net/ ssdc.xtremegaming.net]</td><td>SSDC</td><td>USA, East</td></tr>
<tr><td>SSEO</td><td>cybersnipe, contempt</td><td>http://www.ssenetwork.com/</td><td>SSE</td><td>USA, East</td></tr>
<tr><td>SSL</td><td>Steigerwald</td><td>N/A</td><td>N/A</td><td>USA, Central</td></tr>
<tr><td>SSO</td><td>cybersnipe, contempt</td><td>http://www.ssenetwork.com/</td><td>SSE</td><td>USA, East</td></tr>
<tr><td>SST</td><td>Confess <confess321 yahoo.com><br>Top Gun. <ajchuck achosting.net></td><td>[http://www.ssthosting.net www.ssthosting.net]</td><td>SST</td><td>USA, East</td></tr>
<tr><td>T3</td><td>Mecbot+</td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
</table>

The purpose of this table is to serve as a summary of active hosts and so people can quickly find contact details of who is operating them.

Next, a seperate section (or possibly page) containing a history of the networks, start/end dates, ownership, comments (reason for creation/closure, generally accepted reputation).

[[User:I88gerbils|i88gerbils]]: Why not give a brief 1-line summary of TAG, host, web site making the tag a wiki link to description + contact information? Kind of like the corporation info bar on wikipedia.

{{host|Tag=SSCX|ServerName=SubSpace X|Contact=Xalimar|Email=}}? {{zone}}?

Agreed with basically all of this. I'll change the name now, and probably separate this at least into current and historical. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: There's a long way yet to go. I'm still making my way through the recent changes and may start rewriting this page later.

--[[User:I88gerbils|i88gerbils]] 16:24, Mar 10, 2006 (EST): I like my style better. It's pretty easy to just add a standard wiki template to add an entry. And probably easier to add CSS for just that template to pretty it up if MGB wants.

Writing Modules In Python

2007-04-18T19:24:33Z

Smong: /* Trouble shooting */ tab/space indent tip

== Basic python module ==
I have tried to comment what is going on in the source. This module demonstrates callbacks, commands and using interfaces.
<pre>
# demo asss python module
# dec 28 2004 smong

# nearly always use this
from asss import *

# get some interfaces
# see chat.h for where I_CHAT comes from, see other .h files for more (fx:
# game.h)
chat = get_interface(I_CHAT)

# a callback
# this function is called when a player enters/leaves, see core.h for PA_???
# constants
def paction(p, action, arena):
# start indenting
if action == PA_ENTERARENA:
# see chat.h for the names of more functions like SendMessage
chat.SendMessage(p, "hello " + p.name)

# tell asss to call 'paction' when CB_PLAYERACTION is signalled
# see .h files for CB_??? names
cb1 = reg_callback(CB_PLAYERACTION, paction)

# a command
# see cmdman.h for what each parameter does
def c_moo(cmd, params, p, targ):
# help text (?help moo)
"""\
Module: <py> demo
Targets: none
a sample command.
"""
chat.SendMessage(p, "moo cows")

# tell asss to call 'c_moo' when a player types ?moo
# note: add cmd_moo to conf/groupdef.dir/default so players have permission to
# use this command.
cmd1 = add_command("moo", c_moo)

# setting chat (or other interfaces), cb* or cmd* to None is equivalent to
# unregistering that item.
</pre>
Save this in bin/demo.py. Then ingame make sure pymod is loaded by using ?lsmod and ?insmod. Then add this module with the following command: ?insmod <py> demo. Re-entering the arena and typing ?moo should do some stuff.

== Code snippets ==
The bread and butter of most custom modules.
=== Callbacks ===
<pre>
from asss import *

chat = get_interface(I_CHAT)

def goal(arena, p, bid, x, y):
chat.SendArenaMessage(arena, "goal.")

cb1 = reg_callback(CB_GOAL, goal)
</pre>

=== Commands ===
Useful for controlling events, fx: ?elim start. In this case the command is ?t1.
<pre>
from asss import *

chat = get_interface(I_CHAT)

# cmd = the name of the command, fx: elim
# params = any parameters, fx: start
# p = who sent the command
# targ = player or arena
def c_mycmd(cmd, params, p, targ):
"""\
some help text
"""
if isinstance(targ, ArenaType):
chat.SendMessage(p, "command sent to public chat")
elif isinstance(targ, PlayerType):
chat.SendMessage(p, "command sent as priv msg to %s" % targ.name)

cmd1 = add_command("t1", c_mycmd)
#where the "t1" is located would be the name of the command, ex: ?t1
</pre>

You can parse integers from the params using the following code:
<pre>
try:
val = int(params)
except ValueError:
# here the conversion of params from a string to an int failed.
# change the next line to 'pass' to silently ignore the conversion error,
# 'return' to exit the function, or 'val = 0' to set a default value to val.
chat.SendMessage(p, "Integer parameter required.")
</pre>

=== Manipulating built-in stats (such as kills/points) ===
This example makes it so team kills don't effect the wins/losses of both players involved.
<pre>
stats = get_interface(I_STATS)

def kill(arena, killer, killed, bty, flags, pts, green):
# This checks to see if the killer killed someone on the same team.
# If so then it will take away a kill from the killer and take away a death from the killed player.
# The scores are updated right away and the stats appear as if you never died.

if killer.freq == killed.freq:
# stats can be incremented...
stats.IncrementStat(killer, STAT_KILLS, -1)

# ...or set to an absolute value
deaths = stats.GetStat(killed, STAT_DEATHS, INTERVAL_RESET)
stats.SetStat(killed, STAT_DEATHS, INTERVAL_RESET, deaths - 1)

# SendUpdates must be called so everyone's F2 box shows the correct values
stats.SendUpdates()

return pts, green

cb1 = reg_callback(CB_KILL, kill)
</pre>
More STAT_* types can be found in statcodes.h. If you look at stats.h you can see there is also an IncrementStat function

=== Per-player/arena data ===
Use this to store game state, player score, etc.
<pre>
def shipchange(p, newship, newfreq):
# prefix mymod_ an abbreviation of your module name to the variable
# so that it doesn't clash with other modules. per arena data works
# in exactly the same way.
p.mymod_lastship = p.ship

cb1 = reg_callback(CB_SHIPCHANGE, shipchange)
</pre>

=== Persistent per-player data ===

<div style="color: red; font-weight: bold; border: thin solid; padding: 5px 5px 5px 5px">Note this has changed since 1.4.2. See bin/fg_turf.py for the latest implementation. Or the example at: http://forums.minegoboom.com/viewtopic.php?p=63321#63321</div>

ASSS has built in mechanisms for saving data per player and per arena across sessions (users logging off or server restarting).

You need to provide three functions that will be called by ASSS to save, restore and clear the data. The example below is a complete module.
<pre>
# each player can save a note that only they can see

from asss import *

chat = get_interface(I_CHAT)

# show and store a note
def c_note(cmd, params, p, targ):
if params:
p.note = params
if p.note:
chat.SendMessage(p, "note: %s" % p.note)
else:
chat.SendMessage(p, "no note set")

cmd1 = add_command("note", c_note)

# return the data to save for player p
# returning None means "don't store a record in the database,
# and delete any record that's there already".
def getpd(p):
return p.note

# restore the data for player p
def setpd(p, d):
p.note = d

# reset/clear the data for player p
def clearpd(p):
p.note = None

mypd = reg_player_persistent(
7890, INTERVAL_FOREVER, PERSIST_GLOBAL,
getpd, setpd, clearpd)
</pre>
Ideally you should load the module when the server starts. Alternatively if you load it dynamically you can kick everyone (not desirable) or alter the code to catch AttributeError when it attempts to read from the per player data ''.note''.

Taking a look at ''reg_player_persistent'' the number ''7890'' is arbitrary, but must be unique for every module using persistent data. Low numbers are reserved for the core modules. ''INTERVAL_FOREVER'' is how long this data will be kept for. Interestingly the INTERVAL_* constants are defined in statcodes.h, not persist.h. ''PERSIST_GLOBAL'' is defined in persist.h. Here are the respective code extracts (as of Feb 7 2005).
<pre>
/* these are the possible intervals */
enum interval_t
{
/* pyconst: enum, "INTERVAL_*" */

/* these are shared between arenas with the same arenagrp */
INTERVAL_FOREVER = 0,
INTERVAL_RESET,
INTERVAL_MAPROTATION,
/* these are not shared between arenas */
INTERVAL_GAME = 5,
INTERVAL_FOREVER_NONSHARED
};
</pre>
<pre>
typedef enum persist_scope_t
{
/* pyconst: enum, "PERSIST_*" */

PERSIST_ALLARENAS,
/* using this for scope means per-player data in every arena */
/* using this for scope means per-arena data will be stored
* per-arena */

PERSIST_GLOBAL
/* using this for scope means per-player data shared among all arenas */
/* using this for scope means per-arena data will be shared among
* all arenas (so it will effectively be global data). */
} persist_scope_t;
</pre>
Note: ASSS must be compiled with the berkeleydb option for persistent data to be available.

=== Attach/Detach ===
Attaching and detaching is similar to load/unload in a C module except it is arena specific. So you can use it to initialise per-arena data.
<pre>
def mm_attach(arena):
# do stuff with arena
def mm_detach(arena):
# undo stuff
</pre>

=== Looping over all players ===
This example counts the number of players in an arena.
<pre>
def count_players(arena):
# a list must be used as all other variables are immutable to
# nested functions.
players = [0]
def cb_count(p):
if p.arena == arena:
players[0] = players[0] + 1
for_each_player(cb_count)
return players[0]
</pre>

=== Timers ===
Good for checking if a game is over yet. '''A reference to the timer is returned and must be retained''' (you can use per-arena data to store it). Losing the reference will cancel the timer.

''initial'' is the time in 1/100th's of a second before the nested function timer() will be called, you can cancel the timer before it is called. ''interval'' is the time gap, again in 1/100th's of a second between all future calls of timer(). So make_hello_timer(100, 200, arena) will make it send the arena message "hello" every 2 seconds starting from 1 second after make_hello_timer() was called.

The third argument to set_timer (''interval'') can be omitted and it will be assumed to be the same as ''initial''.

The parameter ''arena'' is needed in this case because SendArenaMessage() requires an arena parameter.
<pre>
def make_hello_timer(initial, interval, arena):
def timer():
# announce
chat.SendArenaMessage(arena, "hello")
# non-repeating timer. return 1 for it to be called after the next interval
return 0
return set_timer(timer, initial, interval)

def somefunc(arena):
# create a hello timer that will execute after 1 second, and then every
# 2 seconds until cancelled. timers can cancel themselves, see above.
myref = make_hello_timer(100, 200, arena)

# cancel the timer by losing the reference to it
myref = None
</pre>

=== Regions ===
This is untested but it should go something like this:
<pre>
mapdata = get_interface(I_MAPDATA)

# regionname is a string, x and y are map tile coords.
def region_contains(arena, regionname, x, y):
success = 0

rgn = mapdata.FindRegionByName(arena, regionname)

if rgn != None and mapdata.Contains(rgn, x, y):
success = 1

return success
</pre>
It is a good idea to cache ''rgn'' within [[#Per-player.2Farena_data|per-arena data]] so you don't add unecessary load to the server looking it up everytime.

You might come across a region callback when browsing the .h files. This is currently (1.4.2) not available in python.

=== Moving Balls ===
This is untested but it should go something like this:
<pre>
balls = get_interface(I_BALLS)

# xy are in tiles
# bid is ball id (0-7, depends how many balls are in the arena)
def move_ball(arena, bid, x, y):
bd = balldata()
bd.state = BALL_ONMAP
bd.x = x * 16
bd.y = y * 16
bd.xspeed = bd.yspeed = 0
bd.carrier = None
bd.freq = -1
bd.time = current_ticks()
balls.PlaceBall(arena, bid, bd)
</pre>

=== Targets ===
Many of the module interfaces use Targets to specifiy which players should be affected by a function call.
<pre>
# entire arena
tgt = arena

# specific player
tgt = p

# specific freq
tgt = (arena, freq)

# entire zone
tgt = "zone"

# example interface function that requires a tgt
game.WarpTo(tgt, x, y)
</pre>
Currently (asss 1.4.3) list targets are not supported.

== Trouble shooting ==
If code won't run at all check to see if there is a mix of tabs and spaces used for indenting. If so convert all indents to the same type (tabs or spaces). It may not be necessary to do this for the entire module, just in affected functions.

Look at the asss console for execution errors (at the time of writing not all errors are relayed to logged in staff), and if that doesn't help, add some chat.SendArenaMessage(ALLARENAS, "i'm at line ...") type messages to locate the buggy piece of code.

[[Category:Module]]
[[Category:Guides]]

Category:Discretion

2007-04-16T16:50:22Z

Smong: created page

Main article: [[Discretion]].

Creating and Testing a Simple Discretion Module in MS Visual Studio

2007-04-16T16:49:28Z

Smong: added categories: Discretion, Guides

This is a tutorial for module creation in [[Discretion]]. For other tutorials, see the [[Discretion Module Tutorial]].

Making a module is easy pie once you know what to do, so let's get to it.

==Windows with MSVC==

First step: make a new VS.net C++ Project.

1. File -> New Project

2. Win32 Console Project

3. Give your project a name ("TestModule" in the picture)

4. Press Ok

[[Image:disc_module1.PNG]]

5. Click on application settings on the left

6. Click DLL from the list of radio buttons

7. Press the Empty Project checkbox

8. Press Finish

[[Image:disc_module2.PNG]]

9. File -> Add New Item

10. Select C++ Source File (.cpp)

11. Name your source file ("testmodule.cpp" in the picture)

12. Press Open

[[Image:disc_module3.PNG]]

13. Paste the following code into your source file
<pre>// Sample Discretion Module Source File
#include "Module.h"

void* getClassInstance(void* _mm, LoadMode lm)
{
if (lm == LOADMODE_Init)
printf("Test Module Initialized\n");

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}</pre>

14. Right Click your project in the Solution Explorer and go to Properties (You can also access this through the Project Menu, Project -> Properties)

[[Image:disc_module4.PNG]]

15. In the properties window, from the drop down menu select "All Configurations"

16. Select C++, General from the tree view on the left

17. Type the directory to the Modules directory (the one with Module.h in it, not the one with only .dlls!) that comes with the full version of Discretion in the Additional Include Directory property ("E:/client/modules" in the picture)

18. Press Ok

[[Image:disc_module5.PNG]]

19. Go to Buld -> Build <project name> ("TestModule" in the pictue)

[[Image:disc_module6.PNG]]

If all goes well, you code should compile and a .dll should be produced that is a Discretion module! Now let's put the module into Discretion to see it at work.

20. Copy the produced .dll into your Discretion executable's Module folder (the one with the .dlls in it, not the one with Module.h in it).

[[Image:disc_module7.PNG]]

21. Edit conf/MAIN.CONF with a program such as Notepad

22. Add the name of your dll to the Modules::Names setting (it's a comma seperated list of module names, order doesn't matter)

23. Save the file

[[Image:disc_module8.PNG]]

24. Run Discretion, Select Practice Offline

25. Observe your modules initialization in the console window

[[Image:disc_module9.PNG]]

Now you might say, rightfully so, that this module doesn't do anything. The way to do real things in Discretion is by using other modules. Want to react to user key presses? Use the KeyControls module. Want to display some images? Use the Graphics module. I'll gladly write additional tutorials for how to use each of these as needed. Tell me what you want to do and I'll write a tutorial with how to use the existing modules to accomplish what you want to do.

[[Category:Discretion]]
[[Category:Guides]]

Discretion

2007-04-16T16:48:24Z

Smong: added category: Discretion

[[Image:discretionss.PNG|thumb|A Screenshot of SubSpace Discretion.]]

Discretion is a [[SubSpace]] client created by [[User:BaK|BaK]]. It is open source, like [[ASSS]], and is released under the [http://en.wikipedia.org/wiki/GPL GPL]. Discretion was developed because of the limitations of the in-use client, [[Continuum]]. Furthermore, the lack of development of Continuum led to a situation where limitations in the client would never be overcome. Making heavy use of [http://en.wikipedia.org/wiki/Simple_DirectMedia_Layer SDL], Discretion is cross-platform, and is currently supported under Windows and Linux, with Mac OS X support on the way. Discretion is intended to be secure through design, rather than through obscurity like Continuum. It is designed to make cheating is impossible, rather than just difficult.

Since cheating is to be made impossible, the server must check the data players send it for cheating. This requires modifying the server, which rules out using [[Subgame]]. There is, however, a modified ASSS Server that allows Discretion clients to connect[http://rshl.org/bak/Server.zip].

In order to encourage client development, Discretion is designed with a modular system similar to ASSS. There are interfaces which define actions for modules (such as "draw ship at 50,50"), and callbacks which signal when events occur (such as "player has been killed"). Where ever possible, magic values have been removed and are instead loaded from plain-text settings files. The goal of this is to eliminate any built-in constraints present in VIE SubSpace and Continuum. These magic values include the location / color of the FPS counter, 1024x1024 tiles in maps, each tile being 16x16 pixels, each ship image having 40 frames thus 9 degree turns, the number of fly over tiles, two sets of doors four tiles each per map, the 0x01 type packet cooresponding to an arena login, friendly players showing up yellow in the stat box, the colors in the font file, the number of frames in the wormhole animation, the text that shows up when you press ESC, the number of ships, as well as all the settings Conitnuum does allow you to change such as the ship images, the gameplay settings, and the controls. The server is intended to be able to modify most of these, thus giving [[Zone]] developers maximum creativity and flexibility.

==Modules==
Discretion is divided up into several modules, dynamically linked into the main program much like ASSS. These modules are desired to be as generic as possible, with their Continuum-like actions coming from the settings, rather than the modules themselves. Thus Discretion is like a 2D grid game engine, with settings and graphics which make it look like SubSpace. The module interfaces are documented in the cooresponding header files using Javadoc-style documentation. There are currenly over 30 modules in the Discretion release. Some of the main ones are discussed below.

===Settings Handler===
The '''SettingsHandler''' modules loads the settings from ini-like plain text files. The main settings file is located in conf/MAIN.CONF, which #includes many other settings files. All these settings files are plain text, meaning they can be edited using a utility like pico or notepad. Individual settings can be specified in several formats, depending on how they should be interpretted. Supported types include intergers (''50'', ''0x30'', ''0777''), strings (''hello person''), points/vectors/dimensions (''(100,200)''), rgb colors (''(255,255,255)'', ''(0,128,128)''), and [[lvz]]-style screen locations (''(C+50,50)'', ''(B-10,C+25)''). There also exists a helper function to parse comma seperated a list of strings from a single sting in shared/StringManip.h. This module interface also allows modules to load their own conf files, or save a group of settings to a file which the program can then read out of.

The front end program, '''cskinviewer''' uses the saving capability of '''SettingsHandler''' to keep track of zone data between program executions.

===Module Manager===
The '''Module Manger''' itself is a module which is loaded by the program, which then proceeds to load any other modules. This uses the setting Modules::Names which is a comma seperated list of strings to figure out which modules to load. It loades module files, '.dll's in Windows and '.so's in Linux, from the bin/ directory. Modules are loaded in stages. During the first stage, LOADMODE_Init, modules register their interface, if any, with the '''Module Manager''' and register any callbacks they want to listen for. During the next stage, LOADMODE_LoadInterfaces, modules load any interfaces they plan to use. Finally, during LOADMODE_PostLoadInterfaces, modules can use their loaded interfaces to other modules to initalize themselves. Upon sucessful program termination, LOADMODE_Unload is invoked which allows the module to free any data or resources it's using. The module manager also facilitates callbacks. Where possible, C++ exception handling is used to aid in catching errors in a non-fatal way and reports the cause of the problem.

Note that some initialization tasks should not be done in LOADMODE_PostLoadInterfaces since they require modules be initialized in a specific order. For example, the '''Text''' module, which writes text to the screen should not be initialized before the ''Graphics'' module is, since it would be unable to load the text image. Thus some initilization tasks are be done in callbacks, CB_LOADIMAGES in this instance.

===Graphics===
The '''Graphics''' module allows one to load images and draw them to the screen or map. When an image is loaded through the interface, an image handle is given to the calling module which is used to refer to the image. This handle can also be used to get the image size (taking into account that some images are framed animations), or free the image when it's no longer needed. Blank images can also be created and drawn on, thus allowing one to predraw complex images instead of redrawing them every frame. Images, when drawn to the screen, are drawn in layers. This allows several modules to queue up images to be drawn out of order and still result in a correct drawing. Some layers include L_Tiles, L_Weapons, L_AfterWeapons, L_Gauges, L_Chat and L_TopMost. Images can be drawn relative to the screen, or relative to the map. Images can also be blended such that they appear translucent, as long as the user has Graphics::UseBlending set to 1. Rectangles of a constant color can also be drawn to the screen or on to another image. The images are queued up to be drawn during the CB_PRERENDER callback.

Although providing a basic interface, it is uncommon to '''Graphics''' module directly for loading images. Instand the '''UniqueImage''' module allows one to specify an image in the settings and refer to it in code by a name. This is much easier than loading the image yourself, and easily allows a single graphic to contain many different images, which is not uncommon in SubSpace images (the bullets image, for example, contains images for all sorts of bullets rather than just a single type). The '''UniqueImage''' module makes sure to only keep a single copy of the image in memory at all times. The '''UniqueImage''' module, in turn, is used by the '''Animations''' module to provide simple access to SubSpace-style animations. Thus, a programmer can code something like 'draw animation "bullet explosion" at 512,512' and it will handle loading the image, figuring out how many frames there are, the speed of the animation, and how long to display it for.

===Controls===
The '''Controls''' module permits the programmer to provide actions("move forward"), while the settings specify exactly what keyboard or joystick input they coorespond to("up arrow key"). Controls should be registered in the CB_CONTROLSLOADED callback. Also, since this a generic module it does not capture any of the physical controls itself, instead relying on other modules to handle that aspect.

The '''SDL Key Controls''' module handles capturing keyboard input and sending it to the '''Controls''' module. The '''Mouse''' module does not use the '''Controls''' module directly, instead providing its own interface which allows one to create mouse hotspots and be notified of mouse clicks or movements within these hotspots.

===Timers===
Similar to how ASSS has timers implemented in the mainloop module, Discretion has a '''Timers''' module that provides a timer functionality. One can register a function to be called in X milliseconds, or every X milliseconds until it's cancelled. Discretion is currently not multithreaded beyond SDL, so that a timer in an infinite loop (or any piece of code that gets to run, for that matter), will result in the program freezing up. Thus you should not use blocking calls in timers or take up too much processing time which will degrade performance.

The '''Net''' module uses a timer to send and receive packets.

===Text===
The '''Text''' module provides an easy way to draw text on the screen. This is the standard subspace text and can be specfied by color. This module draws the text on one line for a single frame. Therefore, you must call the appropriate functions in this interface during CB_PRERENDER every frame for however long you wish to display the text. There is support for drawing text relative to the screen or to the map, as well as blending text and drawing on any layer.

The '''Textbox''' module uses '''Text''' to draw its text, but provides additional features such as drawing textbox borders and allowing easy textbox loading from files. '''EscapeBox''' and '''PlayerList''', in turn, use '''Textbox'''. '''Chat''' also makes use of the '''Text''' module when it draws player chat to the screen. The '''Flash''' module, which handles messages similar to SubSpace's kill and prize messages, also uses the '''Text''' module. Pretty much anywhere you see text, the '''Text''' module is at work.

===Physics===
The '''Physics''' module provides functions which can give you a particle's new position given its initial position, velocity, and time elapsed. This is used for ships as well as weapons. The position can be advanced in such a way that is affected by the map (such as bombs going around a wormhole), or not. Particles can bounce off the level or explode on contact.

The '''SelfShip''' module uses '''Physics''' to compute the new position of the player over time. '''SS_Items''' uses '''Physics''' to find the position of a bullet after a certain amount of time.

===PerPlayerData===
The '''PerPlayerData''' module provides a simple way to have data that is common to every player. This is similar to ASSS' PlayerData module in that a struct of memory can be allocated for every player and referred to using a key. The module also facilitates simple sharing of per player data between module such as "name", "x", or "y".

The '''PlayerList''' module uses the sharing facility of '''PerPlayerData''' to get the names of the players on the player list.

===Level===
The '''Level''' module provides a simple interface to possibly many different types of level formats. Modules can load levels through the interface, as well as get the map or tile size. Furthermore, forces on the level, such as wormholes, friction, or gravity can be applied through the interface.

Currently, the only map format implemented is '''oldlvl''' which supports regular SubSpace [[LVL]] files. This provides a somewhat more generic implementation, which a customizable amount of doors or custom animation tiles (wormholes, space station, and asteriods), as well as having wormholes with different properties on the same map.

===Front End===
The front end, not exactly a module, is implemented as its own program, '''cskinviewer''', contributed by [[User:Smong|Smong]]. This program allows one to download a list of ASSS servers from a [[Directory Server]], and choose one and login. It uses the '''SettingsHandler''' to save the current zone list to the settings. Custom zones can not be added through the interface yet, but can be added by hand by editing conf/profiles/ZoneList.conf.

The front end executes '''in_game''', which in turn loads the '''Module Manager''' which runs '''Main SDL''' which runs callbacks to load the various SDL Subsystems and starts the program's main loop.

==Contribute==
Development for Discretion is ongoing and everyone is encouraged to contribute. Graphics are always helpful, and if you have an idea feel free to make it. In the spirit of free software, it would be best if eventually all VIE owned graphics were replaced, as their copyright status is unknown. This includes the ships, bullets, default tileset, and all other graphics from VIE SubSpace or Continuum. Also, a Discretion [[skin]] is yet to be made for the front end (the format follows that of Continuum's, see the skins directory in your Continuum folder). Additionally, many features are in development or unimplemented. If one wanted to help out, just contact BaK (bak2007 [at] gmail [dot] com), or start working on graphics or a module. There is also a [[Discretion Module Tutorial]] which shows you how to create a simple module. Some planned modules include:

====Star Background====
A '''StarBackground''' module that draws stars and planets similar to how Continuum does it. It would be great it this looked better than Continuum as it would really lead to the immersion necessary for a fun experience. This could also be used to draw all sorts of backgrounds, such as grass for earth-based zones, to provide an alternate to tiling LVZ all over the map. This would be a good module to make to get introduced to Discretion development.

====LVZ====
A reverse compatible LVZ module is desired to allow current zones to easily switch over to Discretion without remaking their lvz files. This could provide additional functionality not present in current lvz such as lvz that depend on ship locations to allow animations within shipsets. The easier way to make this is probably to make a static image/animation module which uses the settings and '''UniqueImage''' and '''Animations''' to draw images on the map and screen. Then, an lvz compatibility layer module would be made which translates an lvz file into a .conf file and uses '''SettingsHandler''' to load in the images from the generated file.

====Radar====
Subspace and Continuum include a radar for locating enemies. This will have to be implemented in Discretion. The users should also be able to make the radar bigger by pressing a key (alt).

====File Transfer====
This module is currently being worked on. This will allow file transfer using STP (SubSpace Transfer Protocol) as well as HTTP. This will permit quicker downloads as servers can put their files on the net instead of forcing everyone to download off the slow servers. Files transferred will include the settings, maps, and lvz files.

====Sound====
Sound provides immersion in video games and gives them an authentic feel. We need a way to play sounds when certain actions occur such as a bullet being fired or player bouncing off a wall. WAV sounds will have to be implemented for reverse compatibility, but mp3 is not out of the question for longer sounds such as victory music or just music in general. After this is done, a built in mp3 player could be made to allow players to change songs from within the game. SDL_mixer[http://www.libsdl.org/projects/SDL_mixer/] provides mp3 capabilities and may be used.

====Weapons====
Currently, only non-bouncing bullets are implemented. There are many items SubSpace uses which must be implemented. Care must be taken here to prevent cheating. For example, it would not be difficult to write a program to detect right before a player is about to get hit and automatically portal out or repel. Thus, these items may have to be modified to be on a timer, so that using a portal might require your ship to take a second to "charge up" instead of instantly warping. Also, it would be great if weapons didn't have to follow boring straight lines and instead could turn. Thus I could specify in the settings the direction a weapon would travel if the ship were facing straight up and it would happen. So a straight line would be (0,t), a curvey shot may be (sin(t),t), a shot that speeds up over time may be (0,2^t).

====Custom Client Side Code====
The server should be able to provide code that can be executed client side. There are two types of code that will be provided: updated versions of modules, and gameplay related code. This is especially dangerous since a malicious server owner should not be permitted to compromise players' computers. The module updates can be done by providing a RSA signature with the binary .dll or .so which can be checked before executing any downlaoded files. As for gameplay related code, a Java virtual machine could be used with a Security Manager that allows nothing beyond basic functions. Then, an interface could be provided to the game code that could be used by the code. Thus, binary .class file could be distributed for an arena that aren't allowed to delete files off your computer, but are allowed to access the gameplay relayed interface thus permitting graphics to be drawn or players to be warped around.

==External links==
*[http://rshl.org/bak/client.php Main Discretion Website]

[[Category: Clients]]
[[Category: Discretion]]

Discretion Commands and Displaying Images

2007-04-16T16:47:53Z

Smong: added categories: Discretion, Guides

This is a tutorial for module creation in [[Discretion]]. For other tutorials, see the [[Discretion Module Tutorial]].

In this tutorial, you wil learn how to listen for chat commands using Discretion's Chat Module as well as how to load and display images on the screen using UniqueImage and Graphics.

Topics covered: Listening for Callbacks, Using Interfaces, UniqueImage, Graphics

We will make two commands, ?show and ?hide which will cause a graphic to appear and disappear on the screen.

The first thing we'll do is make the graphic we want to display and put it in our Discretion/graphics folder. This can be done in a progam such as Paint. Here we saved the file as my_testimage.png.
[[Image:cg_1.PNG]]

Now onto the code, make a module as specified in the [Simple Module Creation Tutorial]. The first thing we're going to do is listen to the callback when commands are sent through the chat. Callbacks in Discretion are similar to callbacks in AS3. They represent events that occur that you can react to. Callbacks are registered through the module manager.

<pre>
/**
* - tells the module manager that you want to receive a callback
* @param myVersion the version of the module requresting this callback, this is useful in
* debugging if we were to cause a crash while we're in a callback
* @param callbackName is a name string that will tell the module manager which callback you want
* to receive
* @param callbackVersion is the version string for the callback. If you use an antiquated version,
* and a different version of the callback is called, an error will be recorded
* @param func is a function pointer to a function that should be called when the callback occurs,
* note that all callback functions are of the same form, but you can cast the parameter to a more
* usable form. Donâ€™t change the param, as it must be used to call the other functions too
*/
void (*regCallback)(const char* myVersion, const char* callbackName, const char* callbackVersion, callbackFunc func);
</pre>

Here we pass in myVersion, which is used only if there's a problem with your callback handler, so make it something that you will be able to recognise when it's printed to the console, such as "show-hide graphic module" or the interface handle if you have an interface defined, or even the C preprocessor macro __FILE__ will work. callbackName and callbackVersion are unique to the callback, more on that in a moment, func is the function to call when the callback occurs. callbackFunc is typedefed to a function pointer:

<pre>
typedef void (*callbackFunc)(void* param);
</pre>

In general, you can figure out information about the callback in the file where it's defined. For the command callback we're interested in, we look in Chat.h:

<pre>
// occurs when a possible internal command is sent, if you're processing this command set processed to TRUE
#define CB_INTERNALCOMMAND "InternalCommand"
#define CB_INTERNALCOMMAND_VERSION "1"
// the parameter is as follows, set processed to TRUE if you process it
struct InternalCommandParam
{
const char* command; // the entire command line, with parameters and everything, but no command character
BOOL processed; // set this to true if you process the command

// you can use this function to check if this command is yours, sets processed for you
// setToParams points to whatever's after the command if successful, can be NULL if you don't care
BOOL isCommand(const char* what, const char** setToParams)
{
...
}
};
</pre>

Here the callback name is defined to CB_INTERNALCOMMAND and callback version is defined to CB_INTERNALCOMMAND_VERSION. The parameter to the callback, which is a anonymous pointer (void*) can be cast to a InternalCommandParam*. We then use the isCommand to check if this is the command we're interested in.

So now to register the internal command callback with the module manager and print out a message to the console when we receive "?show" or "?hide". Note that we have to #include "Chat/Chat.h" because that's where the callback is defined.

<pre>
// Commands - Graphics Tutorial Discretion Module
#include "Module.h"
#include "Chat/Chat.h"

ModuleManager* mm = 0;

void gotInternalCommand(void* param)
{
InternalCommandParam* icp = (InternalCommandParam*)param;

if (icp->isCommand("show",0))
{
printf("Received Command: show\n");
}
else if (icp->isCommand("hide",0))
{
printf("Received Command: hide\n");
}

}

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_Init)
{
mm->regCallback(__FILE__, CB_INTERNALCOMMAND, CB_INTERNALCOMMAND_VERSION, gotInternalCommand);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

We should be able to make this module and see the effect when we type ?show and ?hide and press enter in the chat.

[[Image:cg_2.PNG]]

Now onto making an image display on the screen. There are two steps to this, loading the image, and drawing the image on the screen. Loading the image can be done in a few ways, the easiest is to use the UniqueImage module. The UniqueImage module loads settings from conf files, so you can refer to the image by name in the code. UniqueImage also ensures the image is only loaded once (it's unique), so that you can use the same image in different modules without worrying about wasting memory. Unique image will give you an image handle from an image name. An image handle is just an int, which we can pass to Graphics when we're drawing the image. First we'll define the image in the conf files. Open up Image.conf in conf/visual/ and add <Image Name>Path = <path to image> and <Image Name>Frames = (1, 1) to the bottom of the file. In the picture we use CommandsGraphicsTutorial as the name of our image... this is what we'll refer to the image in the code, just make sure it isn't the same as any of the other names. The Frams setting defines how many frames are in the image, for example ships are typcially defined in a single file with 40 images aranged 10 wide and 4 tall, so we'd use (10,4) for the frames if we had such an image. For our image though, we only use a single frame so (1, 1) is correct.

[[Image:cg_3.PNG]]

Now we have to get the UniqueImage interface and use it. Interfaces are generally loaded during LOADMODE_LoadInterfaces in getClassInstance. They are gotten using the interface identifier and the module manager. The interface identifier is defined in UniqueImage.h

<pre>
#define I_UNIQUEIMAGE "UniqueImage-1"
</pre>

To use this constant we need to #include "UniqueImage/UniqueImage.h". In getClassInstance, if lm is LOADMODE_LoadInterfaces, we use the module manager to load the interface using the getInterface function.

<pre>
/**
* - tells the module manager that you want an interface. If the interface is not loaded by the
module manager, an error will result which the module manager takes care of
* - this should be called when getInstance(MODE_LoadInterfaces) is called
* @param myVersion the version of the module calling this function
* @param getVersion the version of the module we want to load
* @return a void* pointing to the class interface of the loaded module
*/
void* (*getInterface)(const char* myVersion, const char *getVersion);
</pre>

Here getVersion is I_UNIQUEIMAGE, myVersion, as in callbacks, is only used in case of errors. We can use __FILE__ or an identfying string like "commands-graphics tutorial". We save the pointer returned by getInterface. The question now is when should we call UniqueImage's getImageHandle function. We want to make sure that we do not call it too early, because the image loading system may not be initialized. This problem is solved through callbacks. For loading images, there is a callback that says "the image loading system is initialized, load your images now". This callback is in Graphics.h, CB_LoadImages.

<pre>
/*
This LoadImage callback will be called when the images are to be loaded, there is no parameter
This is guarenteed to be in POSTLOAD_Interfaces
*/

#define CB_LOADIMAGES "LoadImages"
#define CB_LOADIMAGES_VERSION "1"
</pre>

So we register a callback for this function (and #include "Graphics/Graphics.h"), and load our image and save the image handle UniqueImage gives us.

<pre>
// Commands - Graphics Tutorial Discretion Module
#include "Module.h"
#include "Chat/Chat.h"
#include "UniqueImage/UniqueImage.h"
#include "Graphics/Graphics.h"

ModuleManager* mm = 0;
UniqueImage* ui = 0;

int imageHandle = 0;

void gotInternalCommand(void* param)
{
InternalCommandParam* icp = (InternalCommandParam*)param;

if (icp->isCommand("show",0))
{
printf("Received Command: show\n");
}
else if (icp->isCommand("hide",0))
{
printf("Received Command: hide\n");
}
}

void loadImages(void* param)
{
imageHandle = ui->getImageHandle("CommandsGraphicsTutorial");
}

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_Init)
{
mm->regCallback(__FILE__, CB_INTERNALCOMMAND, CB_INTERNALCOMMAND_VERSION, gotInternalCommand);
mm->regCallback(__FILE__, CB_LOADIMAGES, CB_LOADIMAGES_VERSION, loadImages);
}
else if (lm == LOADMODE_LoadInterfaces)
{
ui = (UniqueImage*)mm->getInterface(__FILE__,I_UNIQUEIMAGE);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

Now that we have the image, we need to draw it on the screen. This is done using the Graphics interface. We get this interface similar to how we got the UniqueImage interface (in getClassInstance where lm == LOADMODE_LoadInterfaces). The function we're interested is one that draws images on the screen:

<pre>
/** Draw an image in the next frame, this is to be done in the prerender callback
* This one draws relative to screen coordinates, rather than absolute coordinates, no bounds checking is done
* @param imageHandle an image handle from the loadImage function
* @param frame the frame of the image to draw on, for example the rotated ship graphic is 0-39
* @param xPixel the xPixel to draw with, this in screen coordinates
* @param yPixel the yPixel to draw with, this in screen coordinates
* @param Layer the layer to draw on, probably from the enum Layer
* @blend a number between 0 and 100 to determine how much blending is to be done for this image,
* so 0 is completely transparent and 100 is opaque
*/
void (*drawScreenImage)(int imageHandle, int xPixel, int yPixel, int frame, int layer, int blend);
void (*drawScreenImage2)(int imageHandle, int xPixel, int yPixel, int layer);
</pre>

imageHandle is the handle we got from UniqueImage, xPixel is the x pixel to use for the left part of the image, yPixel is the y pixel for the top of the image. (0, 0) is the upper left corner of the screen, with y increasing downward and x increasing rightward. Frame is the frame of the image to draw, for us this is 0 since we have only a single frame defined in our image. Layer is layer to draw on, some common ones are given in the enum Layer. Blend is the amount to blend the image, 100 for opaque images and fading to completely transparent when blend is 0. Here is the layer enum:

<pre>
// The layer enum, note you can define your own layers between these ones if you want
enum Layer
{
L_BelowAll = 50,
L_Background = 100,
L_AfterBackground = 150,
L_Tiles = 200,
L_AfterTiles = 250,
L_Weapons = 300,
L_AfterWeapons = 350,
L_Ships = 400,
L_AfterShips = 450,
L_Gauges = 500,
L_AfterGauges = 550,
L_Chat = 600,
L_AfterChat = 650,
L_TopMost = 700
};
</pre>

The question now is when we should call drawScreenImage. The answer is, once again, in a callback. The callback in this case is in Graphics.h, PreRender:

<pre>
// The parameter to the prerender callback
struct PrerenderParam
{
PrerenderParam(int m, Rect* s) : milDif(m) , screen(s) {}

int milDif; // milliseconds since last prerender callback, or 0 on the first one
Rect* screen; // the screen bounds, in pixels
};

// The prerender callback
#define CB_PRERENDER "Pre-render"
#define CB_PRERENDER_VERSION "2"
</pre>

This callback occurs every frame, when we call drawScreenImage, it will get drawn for a single frame. We register the callback like we did for LoadImages and InternalCommand. We then call drawScreenImage based on whether the user has used ?show or not. The final version the code is below:

<pre>
// Commands - Graphics Tutorial Discretion Module
#include "Module.h"
#include "Chat/Chat.h"
#include "UniqueImage/UniqueImage.h"
#include "Graphics/Graphics.h"

ModuleManager* mm = 0;
UniqueImage* ui = 0;
Graphics* g = 0;

int imageHandle = 0;
bool showImage = false;

void gotInternalCommand(void* param)
{
InternalCommandParam* icp = (InternalCommandParam*)param;

if (icp->isCommand("show",0))
{
showImage = true;
}
else if (icp->isCommand("hide",0))
{
showImage = false;
}
}

void loadImages(void* param)
{
imageHandle = ui->getImageHandle("CommandsGraphicsTutorial");
}

void preRender(void* param)
{
if (showImage)
{
g->drawScreenImage2(imageHandle, 200, 200, L_TopMost);
}
}

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_Init)
{
mm->regCallback(__FILE__, CB_INTERNALCOMMAND, CB_INTERNALCOMMAND_VERSION, gotInternalCommand);
mm->regCallback(__FILE__, CB_LOADIMAGES, CB_LOADIMAGES_VERSION, loadImages);
mm->regCallback(__FILE__, CB_PRERENDER, CB_PRERENDER_VERSION, preRender);
}
else if (lm == LOADMODE_LoadInterfaces)
{
ui = (UniqueImage*)mm->getInterface(__FILE__,I_UNIQUEIMAGE);
g = (Graphics*)mm->getInterface(__FILE__,I_GRAPHICS);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

And when we run this module in Discretion we get the desired result:

[[Image:cg_4.PNG]]

Hopefully, by now you are comfortable with listening to callbacks and using interfaces as well as more familiar with the UniqueImage and Graphic modules. Here's a few things you can try to do:

- Instead of drawing the image on the screen, draw it on the map at pixel 8200,8200, and make it so that you can fly over it with your ship.

- Make your image have two frames instead of just a single one, and use a command "?switch" to change the frame of the image being displayed.

- Add a command "?blend <int>" where <int> is an integer specifying the blend amount to use. Observe the effects of different blend values.

[[Category:Discretion]]
[[Category:Guides]]

Listening for Key Presses, Displaying Text, and Per Player Data

2007-04-16T16:47:02Z

Smong: added categories: Discretion, Guides

This is a tutorial for module creation in [[Discretion]]. For other tutorials, see the [[Discretion Module Tutorial]].

The purpose of this tutorial is to explain how to 1) display text on the screen with the Text module, 2) show how to access shared per player data, 3) listen and act upon key presses in Discretion, and 4) show how to register and use local per player data. You are assumed to know how to create and load a basic module, as well as how to use interfaces and callbacks. If you don't know how to do this, do the corresponding [[Discretion Module Tutorial]].

We shall construct a module that displays the currently ticked (in the playerlist) player's name, squad, or frequency. The user will be able to press the ALT key to cycle between these attributes. The module will also keep track of how many times the user has pressed alt for each player.

So for example, consider a case where there's two players in the arena, tux(the user) on freq 0 and squad "Killers", and BaK on freq 1 on squad "BakAttak". Initially the player himself is ticked. The screen will say "Name: tux (Switched 0 times)". The player can then select the next player on the playerlist using page down. After the user presses page down, the screen says "Name: BaK (Switched 0 times)". The user can then press the alt key and the screen switches to "Squad: BakAttak (Switched 1 time)". If the user than presses alt again it switched the text to "Freq: 1 (Switched 2 times)". If the user presses page up it goes back to "Name: tux (Switched 0 times)". Alt will then yield the text "Squad: Killers (Switched 1 time)". Page down will go back to "Freq: 1 (Switched 2 times)". Alt again will give us "Name: Bak (Switched 3 times)".

So let's work off a basic module template:

<pre>
// Discretion Tutorial, goals:
// 1) display text on the screen with the Text module
// 2) show how to access shared per player data
// 3) listen and act upon key presses in Discretion
// 4) show how to register and use local per player data.
// April 2007

#include "Module.h"

ModuleManager* mm = 0;

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_Init)
{

}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

Let's display some text on the screen using the Text module. The text module can display text on the screen or on the map, on any layer. These layers are the same layers that are used to display images. The function we are interested in is displayTextScreen:

<pre>
/**
* Display this text for one frame, call during prerender, this in is screen coordinates
* @param line the line of text to display
* @param color the color string to display
* @param layer the layer to display it on
* @param topLeft the top left corner of where we should start drawing
* @param blend how much to blend the text, 0 = transparent, 100 = opaque
*/
void (*displayTextScreen)(const char* line, const char* color, int layer, const Point* topLeft, int blend);
void (*displayTextScreen2)(const char* line, const char* color, int layer, const Point* topLeft);
</pre>

So as in the images tutorial, we register a callback to CB_PRERENDER, which is when we call displayTextScreen2 to display the actual text. We also get the Text interface. Then, during the prerender callback, we call displayTextScreen2, which will display the text we want on the screen.

<pre>
// Discretion Tutorial, goals:
// 1) display text on the screen with the Text module
// 2) show how to access shared per player data
// 3) listen and act upon key presses in Discretion
// 4) show how to register and use local per player data.
// April 2007

#include "Module.h"
#include "Text/Text.h"
#include "Graphics/Graphics.h"

ModuleManager* mm = 0;
Text* t = 0;

void preRender(void* param)
{
Point topLeft(400,200);

t->displayTextScreen2("test string", "yellow", L_Chat, &topLeft);
}

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_LoadInterfaces)
{
t = (Text*)mm->getInterface(__FILE__, I_TEXT);

mm->regCallback(__FILE__,CB_PRERENDER, CB_PRERENDER_VERSION, &preRender);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

You can see how we could use the text module to display various strings at various layers. Running this code makes the module display the string "test string" at position 400, 200:

[[Image:Ss1.PNG]]

Next, we want to be able to get data about the players. This data is stored as shared Per Player Data. This is gotten using the PerPlayerData interface's getSharedData function:

<pre>
/**
* Get data that was shared by other modules with registerSharedData
* @param pid the player's id we're concerned with
* @param dataName the unique name of the data we want
* @return a void* to the data we want. See the module documentation for the correct name and type
*/
void* (*getSharedData)(int pid, const char* dataName);
</pre>

The parameter dataName refers to the name of the data, in this case "name", "squad", and "freq". There currently isn't a global list of common shared data anywhere, but such a list probably will be made at some point.

We can get the ticked player's id number using the PlayerList interface.

<pre>
/**
* Get the Pid of the currently targeted player
* @return the pid of the player currently "ticked" in the player list box
*/
int (*getTargetPID)();
</pre>

Now once we get the shared data, we receive a void*, which is a pointer that can point to any type of data. Again, a global list of common shared data types isn't yet available, so trust me that getting "name" will give you data of type char*, "squad" will get you data of type char*, and "freq" gets you data of type int*. With a pointer to the data you can modify the data, and this is the mechanism for doing that. You should cast the void* to the proper type of pointer, then use that pointer to get/set the data as one would with a normal pointer.

So in our tutorial, in our prerender callback, we get the ticked player's id from the playerlist, use that with PerPlayerData to get the name of the ticked player, and display that on the screen using the Text Module.

<pre>
// Discretion Tutorial, goals:
// 1) display text on the screen with the Text module
// 2) show how to access shared per player data
// 3) listen and act upon key presses in Discretion
// 4) show how to register and use local per player data.
// April 2007

#include "Module.h"
#include "Text/Text.h"
#include "Graphics/Graphics.h"
#include "PerPlayerData/PerPlayerData.h"
#include "PlayerList/PlayerList.h"

ModuleManager* mm = 0;
PerPlayerData* ppd = 0;
PlayerList* pl = 0;
Text* t = 0;

void preRender(void* param)
{
Point topLeft(400,200);
int ticked_pid = pl->getTargetPID();
char* playerName = (char*)ppd->getSharedData(ticked_pid, "name");

t->displayTextScreen2(playerName, "yellow", L_Chat, &topLeft);
}

void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_LoadInterfaces)
{
t = (Text*)mm->getInterface(__FILE__, I_TEXT);
pl = (PlayerList*)mm->getInterface(__FILE__, I_PLAYERLIST);
ppd = (PerPlayerData*)mm->getInterface(__FILE__, I_PERPLAYERDATA);

mm->regCallback(__FILE__,CB_PRERENDER, CB_PRERENDER_VERSION, &preRender);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

When we run this code (you'll need to run a Discretion-compatible ASSS server to get a name), we get the expected result:

[[Image:Ss2.PNG]]

Now, in the tutorial, we will react to when the user presses alt to cycle through the name, squad, and freq. First, we modify our conf file to specify what keys correspond to our action. Throughout the code (and conf files) we refer to our action with a string. Let's use "cycle_data" as the name for our action. Then, we use the Controls module to specify a function to call when the key(s) for "cycle_data" are pressed. In this function, we will change the type of data we're displaying about the player in prerender.

So first let's edit conf/modules/Controls.conf. Open this file (in notepad, for example), and add "cycle_data" to the list of controls in Controls::Name. Also, we set Controls::cycle_data to RALT. In general, the names of the controls (like "RALT" for us) are equal to the SDLK_ constants for the keys, which you can google for. Alternately, if you're curious, examine initKeys() at the bottom of Modules/KeyControls/SDL Key Controls/SDL_KeyControls.cpp. Usually they're pretty obvious, as was the case with "RALT". If you wanted to allow either alt key to be pressed you could use "RALT, LALT", or if you wanted both, "RALT + LALT". There will eventually be a nice visual interface where the user can rebind all these keys to whatever values they want to use. Proceed to add the mentioned settings to the conf/modules/Controls.conf.

[[Image:Ss3.PNG]]

Now to figure out when the key is pressed, we need to tell the Controls module we're interested in a particular action (cycle_data). We first need to get the controls interface, and then register the callback CB_CONTROLSLOADED, which is when we should register key events.

<pre>
// The controls loaded callback, parameter is null
// this callback occurs when we have loaded the controls bindings, at this point you can call regControlEvent
#define CB_CONTROLSLOADED "CB_CONTROLSLOADED"
#define CB_CONTROLSLOADED_VERSION "1"
</pre>

In that callback, we use regControlEvent from the Controls module to tell the Controls module what function to call when your action occurs (the user presses alt).

<pre>
/**
* tell the Controls modules you want a function to be called when a certain control is pressed,
* down is true iff we want the function to be called when the key is pressed down, if itâ€™s false it will be
* called iff the key combo is lifted up.
*
* call this function in your handler for the CB_CONTROLSLOADED callback
*
* @param keyString the keyString corresponding to the event, as defined in the settings (like "repel")
* @param funcToCall the function to call when the event occurs, down = true iff we're pressing the key combination
*/
void (*regControlEvent)(const char* controlString, void (*funcToCall)(bool down, const char* controlString));
</pre>

To do this, we need a function to call when the control is pressed down or released. The type of the function is void function taking parameters (bool down, const char* controlString), so we add such a function to our module (we named it cycleDataPressed). When this function is called, we change a global variable in our module which changes what we display.

Note that once we #include "Controls/Controls.h", we need to add Modules/Shared/StringManip.cpp to our project to avoid unresolved external symbol linker errors. This is done by going to File -> Add Existing Item, then selecting Modules/Shared/StringManip.cpp.

[[Image:Ss4.PNG]]

The resultant code should now be:

<pre>

// Discretion Tutorial, goals:
// 1) display text on the screen with the Text module
// 2) show how to access shared per player data
// 3) listen and act upon key presses in Discretion
// 4) show how to register and use local per player data.
// April 2007

#include "Module.h"
#include "Text/Text.h"
#include "Graphics/Graphics.h"
#include "PerPlayerData/PerPlayerData.h"
#include "PlayerList/PlayerList.h"
#include "Controls/Controls.h"

ModuleManager* mm = 0;
PerPlayerData* ppd = 0;
PlayerList* pl = 0;
Text* t = 0;
Controls* c = 0;

// 0 = name, 1 = squad, 2 = freq
int dataState = 0;

void cycleDataPressed(bool down, const char* controlString)
{
// if the key is pressed down (rather than released)
if (down)
dataState = (dataState + 1) % 3;
}

// callback below
void keyControlsLoaded(void* param)
{
c->regControlEvent("cycle_data",cycleDataPressed);
}

void preRender(void* param)
{
Point topLeft(400,200);
int ticked_pid = pl->getTargetPID();

char buf[128];

if (dataState == 0)
{
char* playerName = (char*)ppd->getSharedData(ticked_pid, "name");
snprintf(buf,sizeof(buf),"Name: %s",playerName);
}
else if (dataState == 1)
{
char* squadName = (char*)ppd->getSharedData(ticked_pid, "squad");
snprintf(buf,sizeof(buf),"Squad: %s",squadName);
}
else
{
int freq = *(int*)ppd->getSharedData(ticked_pid, "freq");
snprintf(buf,sizeof(buf),"Freq: %i",freq);
}

t->displayTextScreen2(buf, "yellow", L_Chat, &topLeft);
}

// interface functions below
void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_LoadInterfaces)
{
t = (Text*)mm->getInterface(__FILE__, I_TEXT);
pl = (PlayerList*)mm->getInterface(__FILE__, I_PLAYERLIST);
ppd = (PerPlayerData*)mm->getInterface(__FILE__, I_PERPLAYERDATA);
c = (Controls*)mm->getInterface(__FILE__, I_CONTROLS);

mm->regCallback(__FILE__,CB_PRERENDER, CB_PRERENDER_VERSION, &preRender);
mm->regCallback(__FILE__,CB_CONTROLSLOADED, CB_CONTROLSLOADED_VERSION, &keyControlsLoaded);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}

</pre>

With this module, when we press the right alt key (assuming you used RALT in the conf file), it should cycle through the ticked player's data:

[[Image:Ss5.PNG]]

Finally, let's use some local per player data to count how many times we've toggled the state for each player. Our data will keep track of the current information we're displaying for each player, as well as how many times alt was pressed for the player.

Each module is allowed to allocate one structure of per player data for local use. We are interested in the number of times the player presses alt, as well as the current data we're displaying. We also provide the PerPlayerData module with two functions, one to initialize the data, and one to deinitialize the data. You can skip either of these functions. In our case, we want to set the initial number of times the user pressed alt to 0, and set the initial display to 0 (which is the name). The function we make has to accept a void* which we cast to be a pointer to our structure. Here is our structure and initialization function:

<pre>

struct MyPlayerData
{
int dataState;
int count;
};

void initMyPlayerData(void* param)
{
MyPlayerData* mpd = (MyPlayerData*)param;

mpd->count = 0;
mpd->dataState = 0;
}

</pre>

We now have to tell the PerPlayerData module we want it to keep track of data for us. This is done during CB_LOADPERPLAYERDATA, which we listen for.

<pre>
/*
When this callback occurs, you should register the per player data for your module
*/
#define CB_LOADPERPLAYERDATA "Load Per Player Data"
#define CB_LOADPERPLAYERDATA_VERSION "1"
</pre>

During this callback we want to call the interface function in PerPlayerData, reserveData. This allocates some space for every player.

<pre>
/**
* Call this during CB_LOADPERPLAYERDATA to reserve some per player data for your module.
* @param interfaceName the I_ interface name that you're using
* @param size the number of bytes to allocate, use sizeof(YourDataStruct)
* @param initer the function to call with the data as the argument after we allocate (can be null)
* @param deiniter the function to call with the data as the argument before we free (can be null)
* @return key the key to use in GetData when we want to change / use the data
*/
int (*reserveData)(const char* interfaceName, unsigned int size,
void (*initer)(void* data), void (*deiniter)(void* data));
</pre>

In this function, the interface name is the name of the interface, as when we're registering callbacks. Using __FILE__ like we have been will work. The size parameter should be set to the size of our data structure, we'll use sizeof(MyPlayerData) here. This function returns a key which we keep track of in order to get the data later on. To get the data, we use the GetData interface function from PerPlayerData:

<pre>
/**
* Get the Data which we've previously reserved with ReserveData for a particular player
* @param pid the player id of the player whose data we want (often sent in packets)
* @param key the key returned by ReserveData which we use to tell your data apart from a different module's
*/
void* (*getData)(int pid, int key);
</pre>

This returns a void* which we can cast to be a pointer to our structure. We put getData into our CB_PRERENDER to get the state and number of times alt was pressed for the targeted player, and display that. We also increment the number of times alt was pressed every time cycleDataPressed is called when a key is pressed down.

The final code is:

<pre>
// Discretion Tutorial, goals:
// 1) display text on the screen with the Text module
// 2) show how to access shared per player data
// 3) listen and act upon key presses in Discretion
// 4) show how to register and use local per player data.
// April 2007

#include "Module.h"
#include "Text/Text.h"
#include "Graphics/Graphics.h"
#include "PerPlayerData/PerPlayerData.h"
#include "PlayerList/PlayerList.h"
#include "Controls/Controls.h"

ModuleManager* mm = 0;
PerPlayerData* ppd = 0;
PlayerList* pl = 0;
Text* t = 0;
Controls* c = 0;

int myPlayerDataKey = 0;

struct MyPlayerData
{
// 0 = name, 1 = squad, 2 = freq
int dataState;
int count;
};

void initMyPlayerData(void* param)
{
MyPlayerData* mpd = (MyPlayerData*)param;

mpd->count = 0;
mpd->dataState = 0;
}

void cycleDataPressed(bool down, const char* controlString)
{
// if the key is pressed down (rather than released)
if (down)
{
int ticked_pid = pl->getTargetPID();

MyPlayerData* data = (MyPlayerData*)ppd->getData(ticked_pid, myPlayerDataKey);

data->dataState = (data->dataState + 1) % 3;
++(data->count);
}
}

// callbacks below
void keyControlsLoaded(void* param)
{
c->regControlEvent("cycle_data",cycleDataPressed);
}

void loadPerPlayerData(void* param)
{
myPlayerDataKey = ppd->reserveData(__FILE__, sizeof(MyPlayerData), initMyPlayerData, 0);
}

void preRender(void* param)
{
Point topLeft(400,200);
int ticked_pid = pl->getTargetPID();
MyPlayerData* data = (MyPlayerData*)ppd->getData(ticked_pid, myPlayerDataKey);

char buf[128];

if (data->dataState == 0)
{
char* playerName = (char*)ppd->getSharedData(ticked_pid, "name");
snprintf(buf,sizeof(buf),"Name: %s (Switched %i times)", playerName, data->count);
}
else if (data->dataState == 1)
{
char* squadName = (char*)ppd->getSharedData(ticked_pid, "squad");
snprintf(buf,sizeof(buf),"Squad: %s (Switched %i times)", squadName, data->count);
}
else
{
int freq = *(int*)ppd->getSharedData(ticked_pid, "freq");
snprintf(buf,sizeof(buf),"Freq: %i (Switched %i times)", freq, data->count);
}

t->displayTextScreen2(buf, "yellow", L_Chat, &topLeft);
}

// interface functions below
void* getClassInstance(void* _mm, LoadMode lm)
{
mm = (ModuleManager*)_mm;

if (lm == LOADMODE_LoadInterfaces)
{
t = (Text*)mm->getInterface(__FILE__, I_TEXT);
pl = (PlayerList*)mm->getInterface(__FILE__, I_PLAYERLIST);
ppd = (PerPlayerData*)mm->getInterface(__FILE__, I_PERPLAYERDATA);
c = (Controls*)mm->getInterface(__FILE__, I_CONTROLS);

mm->regCallback(__FILE__,CB_PRERENDER, CB_PRERENDER_VERSION, &preRender);
mm->regCallback(__FILE__,CB_CONTROLSLOADED, CB_CONTROLSLOADED_VERSION, &keyControlsLoaded);
mm->regCallback(__FILE__,CB_LOADPERPLAYERDATA, CB_LOADPERPLAYERDATA_VERSION, &loadPerPlayerData);
}

return 0;
}

extern "C"
{
EXPORT void* getInstance(void* mm, LoadMode lm)
{
return getClassInstance(mm,lm);
}
}
</pre>

And we're done!

[[Image:Ss6.PNG]]

[[Category:Discretion]]
[[Category:Guides]]

Discretion Module Tutorial

2007-04-16T16:46:37Z

Smong: added categories: Discretion, Guides

This tutorial is divided into a few pieces. If you're completely new to Discretion, you can view them in order, otherwise you can skip to the one you're interested in.

[[Creating and Testing a Simple Discretion Module]]

[[Discretion Commands and Displaying Images]] (Also covers listening for callbacks and using interfaces)

[[Listening for Key Presses, Displaying Text, and Per Player Data]]

[[Category:Discretion]]
[[Category:Guides]]

Writing Modules In Python

2007-04-16T08:42:55Z

Smong: /* Moving Balls */

== Basic python module ==
I have tried to comment what is going on in the source. This module demonstrates callbacks, commands and using interfaces.
<pre>
# demo asss python module
# dec 28 2004 smong

# nearly always use this
from asss import *

# get some interfaces
# see chat.h for where I_CHAT comes from, see other .h files for more (fx:
# game.h)
chat = get_interface(I_CHAT)

# a callback
# this function is called when a player enters/leaves, see core.h for PA_???
# constants
def paction(p, action, arena):
# start indenting
if action == PA_ENTERARENA:
# see chat.h for the names of more functions like SendMessage
chat.SendMessage(p, "hello " + p.name)

# tell asss to call 'paction' when CB_PLAYERACTION is signalled
# see .h files for CB_??? names
cb1 = reg_callback(CB_PLAYERACTION, paction)

# a command
# see cmdman.h for what each parameter does
def c_moo(cmd, params, p, targ):
# help text (?help moo)
"""\
Module: <py> demo
Targets: none
a sample command.
"""
chat.SendMessage(p, "moo cows")

# tell asss to call 'c_moo' when a player types ?moo
# note: add cmd_moo to conf/groupdef.dir/default so players have permission to
# use this command.
cmd1 = add_command("moo", c_moo)

# setting chat (or other interfaces), cb* or cmd* to None is equivalent to
# unregistering that item.
</pre>
Save this in bin/demo.py. Then ingame make sure pymod is loaded by using ?lsmod and ?insmod. Then add this module with the following command: ?insmod <py> demo. Re-entering the arena and typing ?moo should do some stuff.

== Code snippets ==
The bread and butter of most custom modules.
=== Callbacks ===
<pre>
from asss import *

chat = get_interface(I_CHAT)

def goal(arena, p, bid, x, y):
chat.SendArenaMessage(arena, "goal.")

cb1 = reg_callback(CB_GOAL, goal)
</pre>

=== Commands ===
Useful for controlling events, fx: ?elim start. In this case the command is ?t1.
<pre>
from asss import *

chat = get_interface(I_CHAT)

# cmd = the name of the command, fx: elim
# params = any parameters, fx: start
# p = who sent the command
# targ = player or arena
def c_mycmd(cmd, params, p, targ):
"""\
some help text
"""
if isinstance(targ, ArenaType):
chat.SendMessage(p, "command sent to public chat")
elif isinstance(targ, PlayerType):
chat.SendMessage(p, "command sent as priv msg to %s" % targ.name)

cmd1 = add_command("t1", c_mycmd)
#where the "t1" is located would be the name of the command, ex: ?t1
</pre>

You can parse integers from the params using the following code:
<pre>
try:
val = int(params)
except ValueError:
# here the conversion of params from a string to an int failed.
# change the next line to 'pass' to silently ignore the conversion error,
# 'return' to exit the function, or 'val = 0' to set a default value to val.
chat.SendMessage(p, "Integer parameter required.")
</pre>

=== Manipulating built-in stats (such as kills/points) ===
This example makes it so team kills don't effect the wins/losses of both players involved.
<pre>
stats = get_interface(I_STATS)

def kill(arena, killer, killed, bty, flags, pts, green):
# This checks to see if the killer killed someone on the same team.
# If so then it will take away a kill from the killer and take away a death from the killed player.
# The scores are updated right away and the stats appear as if you never died.

if killer.freq == killed.freq:
# stats can be incremented...
stats.IncrementStat(killer, STAT_KILLS, -1)

# ...or set to an absolute value
deaths = stats.GetStat(killed, STAT_DEATHS, INTERVAL_RESET)
stats.SetStat(killed, STAT_DEATHS, INTERVAL_RESET, deaths - 1)

# SendUpdates must be called so everyone's F2 box shows the correct values
stats.SendUpdates()

return pts, green

cb1 = reg_callback(CB_KILL, kill)
</pre>
More STAT_* types can be found in statcodes.h. If you look at stats.h you can see there is also an IncrementStat function

=== Per-player/arena data ===
Use this to store game state, player score, etc.
<pre>
def shipchange(p, newship, newfreq):
# prefix mymod_ an abbreviation of your module name to the variable
# so that it doesn't clash with other modules. per arena data works
# in exactly the same way.
p.mymod_lastship = p.ship

cb1 = reg_callback(CB_SHIPCHANGE, shipchange)
</pre>

=== Persistent per-player data ===

<div style="color: red; font-weight: bold; border: thin solid; padding: 5px 5px 5px 5px">Note this has changed since 1.4.2. See bin/fg_turf.py for the latest implementation. Or the example at: http://forums.minegoboom.com/viewtopic.php?p=63321#63321</div>

ASSS has built in mechanisms for saving data per player and per arena across sessions (users logging off or server restarting).

You need to provide three functions that will be called by ASSS to save, restore and clear the data. The example below is a complete module.
<pre>
# each player can save a note that only they can see

from asss import *

chat = get_interface(I_CHAT)

# show and store a note
def c_note(cmd, params, p, targ):
if params:
p.note = params
if p.note:
chat.SendMessage(p, "note: %s" % p.note)
else:
chat.SendMessage(p, "no note set")

cmd1 = add_command("note", c_note)

# return the data to save for player p
# returning None means "don't store a record in the database,
# and delete any record that's there already".
def getpd(p):
return p.note

# restore the data for player p
def setpd(p, d):
p.note = d

# reset/clear the data for player p
def clearpd(p):
p.note = None

mypd = reg_player_persistent(
7890, INTERVAL_FOREVER, PERSIST_GLOBAL,
getpd, setpd, clearpd)
</pre>
Ideally you should load the module when the server starts. Alternatively if you load it dynamically you can kick everyone (not desirable) or alter the code to catch AttributeError when it attempts to read from the per player data ''.note''.

Taking a look at ''reg_player_persistent'' the number ''7890'' is arbitrary, but must be unique for every module using persistent data. Low numbers are reserved for the core modules. ''INTERVAL_FOREVER'' is how long this data will be kept for. Interestingly the INTERVAL_* constants are defined in statcodes.h, not persist.h. ''PERSIST_GLOBAL'' is defined in persist.h. Here are the respective code extracts (as of Feb 7 2005).
<pre>
/* these are the possible intervals */
enum interval_t
{
/* pyconst: enum, "INTERVAL_*" */

/* these are shared between arenas with the same arenagrp */
INTERVAL_FOREVER = 0,
INTERVAL_RESET,
INTERVAL_MAPROTATION,
/* these are not shared between arenas */
INTERVAL_GAME = 5,
INTERVAL_FOREVER_NONSHARED
};
</pre>
<pre>
typedef enum persist_scope_t
{
/* pyconst: enum, "PERSIST_*" */

PERSIST_ALLARENAS,
/* using this for scope means per-player data in every arena */
/* using this for scope means per-arena data will be stored
* per-arena */

PERSIST_GLOBAL
/* using this for scope means per-player data shared among all arenas */
/* using this for scope means per-arena data will be shared among
* all arenas (so it will effectively be global data). */
} persist_scope_t;
</pre>
Note: ASSS must be compiled with the berkeleydb option for persistent data to be available.

=== Attach/Detach ===
Attaching and detaching is similar to load/unload in a C module except it is arena specific. So you can use it to initialise per-arena data.
<pre>
def mm_attach(arena):
# do stuff with arena
def mm_detach(arena):
# undo stuff
</pre>

=== Looping over all players ===
This example counts the number of players in an arena.
<pre>
def count_players(arena):
# a list must be used as all other variables are immutable to
# nested functions.
players = [0]
def cb_count(p):
if p.arena == arena:
players[0] = players[0] + 1
for_each_player(cb_count)
return players[0]
</pre>

=== Timers ===
Good for checking if a game is over yet. '''A reference to the timer is returned and must be retained''' (you can use per-arena data to store it). Losing the reference will cancel the timer.

''initial'' is the time in 1/100th's of a second before the nested function timer() will be called, you can cancel the timer before it is called. ''interval'' is the time gap, again in 1/100th's of a second between all future calls of timer(). So make_hello_timer(100, 200, arena) will make it send the arena message "hello" every 2 seconds starting from 1 second after make_hello_timer() was called.

The third argument to set_timer (''interval'') can be omitted and it will be assumed to be the same as ''initial''.

The parameter ''arena'' is needed in this case because SendArenaMessage() requires an arena parameter.
<pre>
def make_hello_timer(initial, interval, arena):
def timer():
# announce
chat.SendArenaMessage(arena, "hello")
# non-repeating timer. return 1 for it to be called after the next interval
return 0
return set_timer(timer, initial, interval)

def somefunc(arena):
# create a hello timer that will execute after 1 second, and then every
# 2 seconds until cancelled. timers can cancel themselves, see above.
myref = make_hello_timer(100, 200, arena)

# cancel the timer by losing the reference to it
myref = None
</pre>

=== Regions ===
This is untested but it should go something like this:
<pre>
mapdata = get_interface(I_MAPDATA)

# regionname is a string, x and y are map tile coords.
def region_contains(arena, regionname, x, y):
success = 0

rgn = mapdata.FindRegionByName(arena, regionname)

if rgn != None and mapdata.Contains(rgn, x, y):
success = 1

return success
</pre>
It is a good idea to cache ''rgn'' within [[#Per-player.2Farena_data|per-arena data]] so you don't add unecessary load to the server looking it up everytime.

You might come across a region callback when browsing the .h files. This is currently (1.4.2) not available in python.

=== Moving Balls ===
This is untested but it should go something like this:
<pre>
balls = get_interface(I_BALLS)

# xy are in tiles
# bid is ball id (0-7, depends how many balls are in the arena)
def move_ball(arena, bid, x, y):
bd = balldata()
bd.state = BALL_ONMAP
bd.x = x * 16
bd.y = y * 16
bd.xspeed = bd.yspeed = 0
bd.carrier = None
bd.freq = -1
bd.time = current_ticks()
balls.PlaceBall(arena, bid, bd)
</pre>

=== Targets ===
Many of the module interfaces use Targets to specifiy which players should be affected by a function call.
<pre>
# entire arena
tgt = arena

# specific player
tgt = p

# specific freq
tgt = (arena, freq)

# entire zone
tgt = "zone"

# example interface function that requires a tgt
game.WarpTo(tgt, x, y)
</pre>
Currently (asss 1.4.3) list targets are not supported.

== Trouble shooting ==
Look at the asss console for execution errors (at the time of writing not all errors are relayed to logged in staff), and if that doesn't help, add some chat.SendArenaMessage(ALLARENAS, "i'm at line ...") type messages to locate the buggy piece of code.

[[Category:Module]]
[[Category:Guides]]

Writing Modules In Python

2007-04-16T08:41:26Z

Smong: /* Code snippets */ added moving balls and info on targets

== Basic python module ==
I have tried to comment what is going on in the source. This module demonstrates callbacks, commands and using interfaces.
<pre>
# demo asss python module
# dec 28 2004 smong

# nearly always use this
from asss import *

# get some interfaces
# see chat.h for where I_CHAT comes from, see other .h files for more (fx:
# game.h)
chat = get_interface(I_CHAT)

# a callback
# this function is called when a player enters/leaves, see core.h for PA_???
# constants
def paction(p, action, arena):
# start indenting
if action == PA_ENTERARENA:
# see chat.h for the names of more functions like SendMessage
chat.SendMessage(p, "hello " + p.name)

# tell asss to call 'paction' when CB_PLAYERACTION is signalled
# see .h files for CB_??? names
cb1 = reg_callback(CB_PLAYERACTION, paction)

# a command
# see cmdman.h for what each parameter does
def c_moo(cmd, params, p, targ):
# help text (?help moo)
"""\
Module: <py> demo
Targets: none
a sample command.
"""
chat.SendMessage(p, "moo cows")

# tell asss to call 'c_moo' when a player types ?moo
# note: add cmd_moo to conf/groupdef.dir/default so players have permission to
# use this command.
cmd1 = add_command("moo", c_moo)

# setting chat (or other interfaces), cb* or cmd* to None is equivalent to
# unregistering that item.
</pre>
Save this in bin/demo.py. Then ingame make sure pymod is loaded by using ?lsmod and ?insmod. Then add this module with the following command: ?insmod <py> demo. Re-entering the arena and typing ?moo should do some stuff.

== Code snippets ==
The bread and butter of most custom modules.
=== Callbacks ===
<pre>
from asss import *

chat = get_interface(I_CHAT)

def goal(arena, p, bid, x, y):
chat.SendArenaMessage(arena, "goal.")

cb1 = reg_callback(CB_GOAL, goal)
</pre>

=== Commands ===
Useful for controlling events, fx: ?elim start. In this case the command is ?t1.
<pre>
from asss import *

chat = get_interface(I_CHAT)

# cmd = the name of the command, fx: elim
# params = any parameters, fx: start
# p = who sent the command
# targ = player or arena
def c_mycmd(cmd, params, p, targ):
"""\
some help text
"""
if isinstance(targ, ArenaType):
chat.SendMessage(p, "command sent to public chat")
elif isinstance(targ, PlayerType):
chat.SendMessage(p, "command sent as priv msg to %s" % targ.name)

cmd1 = add_command("t1", c_mycmd)
#where the "t1" is located would be the name of the command, ex: ?t1
</pre>

You can parse integers from the params using the following code:
<pre>
try:
val = int(params)
except ValueError:
# here the conversion of params from a string to an int failed.
# change the next line to 'pass' to silently ignore the conversion error,
# 'return' to exit the function, or 'val = 0' to set a default value to val.
chat.SendMessage(p, "Integer parameter required.")
</pre>

=== Manipulating built-in stats (such as kills/points) ===
This example makes it so team kills don't effect the wins/losses of both players involved.
<pre>
stats = get_interface(I_STATS)

def kill(arena, killer, killed, bty, flags, pts, green):
# This checks to see if the killer killed someone on the same team.
# If so then it will take away a kill from the killer and take away a death from the killed player.
# The scores are updated right away and the stats appear as if you never died.

if killer.freq == killed.freq:
# stats can be incremented...
stats.IncrementStat(killer, STAT_KILLS, -1)

# ...or set to an absolute value
deaths = stats.GetStat(killed, STAT_DEATHS, INTERVAL_RESET)
stats.SetStat(killed, STAT_DEATHS, INTERVAL_RESET, deaths - 1)

# SendUpdates must be called so everyone's F2 box shows the correct values
stats.SendUpdates()

return pts, green

cb1 = reg_callback(CB_KILL, kill)
</pre>
More STAT_* types can be found in statcodes.h. If you look at stats.h you can see there is also an IncrementStat function

=== Per-player/arena data ===
Use this to store game state, player score, etc.
<pre>
def shipchange(p, newship, newfreq):
# prefix mymod_ an abbreviation of your module name to the variable
# so that it doesn't clash with other modules. per arena data works
# in exactly the same way.
p.mymod_lastship = p.ship

cb1 = reg_callback(CB_SHIPCHANGE, shipchange)
</pre>

=== Persistent per-player data ===

<div style="color: red; font-weight: bold; border: thin solid; padding: 5px 5px 5px 5px">Note this has changed since 1.4.2. See bin/fg_turf.py for the latest implementation. Or the example at: http://forums.minegoboom.com/viewtopic.php?p=63321#63321</div>

ASSS has built in mechanisms for saving data per player and per arena across sessions (users logging off or server restarting).

You need to provide three functions that will be called by ASSS to save, restore and clear the data. The example below is a complete module.
<pre>
# each player can save a note that only they can see

from asss import *

chat = get_interface(I_CHAT)

# show and store a note
def c_note(cmd, params, p, targ):
if params:
p.note = params
if p.note:
chat.SendMessage(p, "note: %s" % p.note)
else:
chat.SendMessage(p, "no note set")

cmd1 = add_command("note", c_note)

# return the data to save for player p
# returning None means "don't store a record in the database,
# and delete any record that's there already".
def getpd(p):
return p.note

# restore the data for player p
def setpd(p, d):
p.note = d

# reset/clear the data for player p
def clearpd(p):
p.note = None

mypd = reg_player_persistent(
7890, INTERVAL_FOREVER, PERSIST_GLOBAL,
getpd, setpd, clearpd)
</pre>
Ideally you should load the module when the server starts. Alternatively if you load it dynamically you can kick everyone (not desirable) or alter the code to catch AttributeError when it attempts to read from the per player data ''.note''.

Taking a look at ''reg_player_persistent'' the number ''7890'' is arbitrary, but must be unique for every module using persistent data. Low numbers are reserved for the core modules. ''INTERVAL_FOREVER'' is how long this data will be kept for. Interestingly the INTERVAL_* constants are defined in statcodes.h, not persist.h. ''PERSIST_GLOBAL'' is defined in persist.h. Here are the respective code extracts (as of Feb 7 2005).
<pre>
/* these are the possible intervals */
enum interval_t
{
/* pyconst: enum, "INTERVAL_*" */

/* these are shared between arenas with the same arenagrp */
INTERVAL_FOREVER = 0,
INTERVAL_RESET,
INTERVAL_MAPROTATION,
/* these are not shared between arenas */
INTERVAL_GAME = 5,
INTERVAL_FOREVER_NONSHARED
};
</pre>
<pre>
typedef enum persist_scope_t
{
/* pyconst: enum, "PERSIST_*" */

PERSIST_ALLARENAS,
/* using this for scope means per-player data in every arena */
/* using this for scope means per-arena data will be stored
* per-arena */

PERSIST_GLOBAL
/* using this for scope means per-player data shared among all arenas */
/* using this for scope means per-arena data will be shared among
* all arenas (so it will effectively be global data). */
} persist_scope_t;
</pre>
Note: ASSS must be compiled with the berkeleydb option for persistent data to be available.

=== Attach/Detach ===
Attaching and detaching is similar to load/unload in a C module except it is arena specific. So you can use it to initialise per-arena data.
<pre>
def mm_attach(arena):
# do stuff with arena
def mm_detach(arena):
# undo stuff
</pre>

=== Looping over all players ===
This example counts the number of players in an arena.
<pre>
def count_players(arena):
# a list must be used as all other variables are immutable to
# nested functions.
players = [0]
def cb_count(p):
if p.arena == arena:
players[0] = players[0] + 1
for_each_player(cb_count)
return players[0]
</pre>

=== Timers ===
Good for checking if a game is over yet. '''A reference to the timer is returned and must be retained''' (you can use per-arena data to store it). Losing the reference will cancel the timer.

''initial'' is the time in 1/100th's of a second before the nested function timer() will be called, you can cancel the timer before it is called. ''interval'' is the time gap, again in 1/100th's of a second between all future calls of timer(). So make_hello_timer(100, 200, arena) will make it send the arena message "hello" every 2 seconds starting from 1 second after make_hello_timer() was called.

The third argument to set_timer (''interval'') can be omitted and it will be assumed to be the same as ''initial''.

The parameter ''arena'' is needed in this case because SendArenaMessage() requires an arena parameter.
<pre>
def make_hello_timer(initial, interval, arena):
def timer():
# announce
chat.SendArenaMessage(arena, "hello")
# non-repeating timer. return 1 for it to be called after the next interval
return 0
return set_timer(timer, initial, interval)

def somefunc(arena):
# create a hello timer that will execute after 1 second, and then every
# 2 seconds until cancelled. timers can cancel themselves, see above.
myref = make_hello_timer(100, 200, arena)

# cancel the timer by losing the reference to it
myref = None
</pre>

=== Regions ===
This is untested but it should go something like this:
<pre>
mapdata = get_interface(I_MAPDATA)

# regionname is a string, x and y are map tile coords.
def region_contains(arena, regionname, x, y):
success = 0

rgn = mapdata.FindRegionByName(arena, regionname)

if rgn != None and mapdata.Contains(rgn, x, y):
success = 1

return success
</pre>
It is a good idea to cache ''rgn'' within [[#Per-player.2Farena_data|per-arena data]] so you don't add unecessary load to the server looking it up everytime.

You might come across a region callback when browsing the .h files. This is currently (1.4.2) not available in python.

=== Moving Balls ===
This is untested but it should go something like this:
<pre>
# xy are in tiles
# bid is ball id (0-7, depends how many balls are in the arena)
def move_ball(arena, bid, x, y):
bd = balldata()
bd.state = BALL_ONMAP
bd.x = x * 16
bd.y = y * 16
bd.xspeed = bd.yspeed= 0
bd.carrier = None
bd.freq = -1
bd.time = current_ticks()
balls.PlaceBall(arena, bid, bd)
</pre>

=== Targets ===
Many of the module interfaces use Targets to specifiy which players should be affected by a function call.
<pre>
# entire arena
tgt = arena

# specific player
tgt = p

# specific freq
tgt = (arena, freq)

# entire zone
tgt = "zone"

# example interface function that requires a tgt
game.WarpTo(tgt, x, y)
</pre>
Currently (asss 1.4.3) list targets are not supported.

== Trouble shooting ==
Look at the asss console for execution errors (at the time of writing not all errors are relayed to logged in staff), and if that doesn't help, add some chat.SendArenaMessage(ALLARENAS, "i'm at line ...") type messages to locate the buggy piece of code.

[[Category:Module]]
[[Category:Guides]]

Talk:Server.ini

2007-04-08T15:11:09Z

Smong: /* Directory Servers */ ok

Oh yes, and sorry about the weird mistakes in here. RegEx's make me lazy. Also, I'm giving information on all the settings I know about, and all the settings Priit has added with explanations in the changelog, but some I have no clue (like most of Comms and Permission) --[[User:Cyan~Fire|Cyan~Fire]]

==TOC==

gerbils, that TOC looks ''really'' ugly. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:I88gerbils|i88gerbils]]: Put it on the left side though it's refreshing to find a Table of Contents on the right. Better than having it ontop.

[[User:Mine GO BOOM|Mine GO BOOM]]: I like it better on the right than anywhere else. On top is too long, on the left just pushes the page too far over. If you want to get fancy, put it in a floating div box on either side, so the rest of the page wraps around it. Should look better then (though I still think better on the right).

Floating boxes are so annoying to get right. Can't we just take advantage of the "Hide" feature? --[[User:Cyan~Fire|Cyan~Fire]]

[[User:I88gerbils|i88gerbils]]: I told you it looked purrty! :d

== Directory Servers ==

[[User:Doc Flabby|Doc Flabby]]: Are the ones in the wiki correct?

sscentral.subspace.inet.fi,ssdir.playsubspace.com

I thought it was
sscentral.sscuservers.net,ssdir.playsubspace.com

[[User:Smong|Smong]]: You are correct, I have updated the article.

Server.ini

2007-04-08T15:10:06Z

Smong: /* IP */ updated recommended dirservs

server.ini is the initialization file for [[subgame]] that controls all of the global settings. Individual arena's settings are stored in arenaname.cfg. The following are the various sections in the server.ini.

<div style="float: right; margin-left: 20px">
__TOC__
</div>

== Validation ==

See [[Validation]].

== Custom ==
These settings configure custom arenas. (I think?)

=== ArenaMode ===
''Datatype:'' Enumeration.

This controls the ownership of private arenas. By "own a new subarena", it means that if the selected level of player creates a new subarena with ?go, and the arena does not have settings associated yet, subgame will create settings for that arena and assign [[arena ownership|ownership]] to the creating player. If the player creating the arena is below the selected level, subgame will still create settings for the arena, but will not grant ownership.
#Any player can own a new subarena.
#Mods+ can own a new subarena.
#Smods+ can own a new subarena.
#Sysops can own a new subarena.
#''Special:'' New subarenas will just use spawn.cfg. (That is, a new cfg must be placed in the server directory manually to give an arena its own settings.)

== Arena ==
These settings configure default arena settings.

=== ArenaMaxPlayers ===
''Datatype:'' Count.

Number of players allowed in any arena. (This can be overridden in the [[Misc Settings]] for an arena.)

=== ArenaDesiredPlayers ===
''Datatype:'' Count.

Subgame will create a new arena for entering players once an arena hits this population. This is different from the above setting in that users can still manually enter an arena with this population.

=== ArenaMinimumPlayers ===
''Datatype:'' Count.

Minimum number of players in a public arena before subgame automatically sends a message advising players to move on.

=== SpawnKeepScores ===
''Datatype:'' Boolean (1=yes,0=no).

Whether player-spawned arenas keep track of scores.

=== MaxArenas ===
''Datatype:'' Count.

The maximum number of arenas subgame will allow.

=== MaxArenasMemory ===
''Datatype:'' Bytes.

The maximum amount of memory subgame will allocate for arena data. Normally the default should suffice.

== Comms ==
Communication (networking) settings.

=== MaxQueueToLogin ===
''Datatype:'' Count.

Maximum number of clients waiting to login. Any that try when this limit is exceeded will receive the message "The server is busy handling other login requests. Please try again in a few moments. If problem persists, seek help at the Tech Support Forums found at www.subspacehq.com".

=== PacketHistoryMax ===

=== IncomingBufferSize ===

=== OutgoingBufferSize ===

=== EncryptMode ===

=== UnreliableBufferSize ===

=== TransportBufferSize ===

=== FlushTime ===
''Datatype:'' Milliseconds.

Subgame will queue position packets for this amount of time before sending them. ''Setting this too high will severly lag your zone.''

=== BandwithIdleTime ===
''Datatype:'' Seconds.

Subgame will stop sending position packets to a spectator after this time of inactivity. Useful for saving bandwidth.

=== SelectTime ===
''Datatype:'' Milliseconds.

Time delay subgame should wait for incoming packets before continuing on. This is recommended over CPU:SleepTime.

== Misc ==
Miscellaneous settings.

=== DisableShareware ===

=== RegisterKickShareware ===
''Datatype:'' Boolean.

Should subgame kick shareware users in favor of registered users when server is full? (Leave set to 0.)

=== MaxSharewarePlayers ===
''Datatype:'' Count.

Maximum number of shareware players allowed on server. ''Special Value:'' -1 = unlimited.

=== MaxPlayers ===
''Datatype:'' Count.

Maximum total players allowed in zone.

=== MaxSharewareTime ===

=== DisableSharewareNames ===
''Datatype:'' Boolean.

Disables the ability for demo players to have customized names. The default displayed name will just be "~Demo".

=== DisableSharewareShips ===
''Datatype:'' Boolean.

Disables the ability for demo players to use ships 5-8.

=== DisableSharewareScores ===
''Datatype:'' Boolean.

Disables the ability for demo players to retain their scores between sessions. ''Note:'' Scores will always be disabled if the players do not have a name.

=== MenuKickOutDelay ===
''Datatype:'' Hundredths of seconds.

Amount of time a player may take logging in before server disconnects client.

=== NoAntiInSafe ===
''Datatype:'' Boolean.

If enabled, subgame will ignore [[AntiWarp]] of a player in a safe zone.

=== LockFreqs ===
''Datatype:'' Boolean.

Determines whether [[Commands#Arena Management|locking]] an arena locks freqs as well as ships. (1.34.3+)

=== PositionDataAccess ===
''Datatype:'' Enumeration.

Determines staff level that will receive extra position data when speccing. Useful if [[Misc Settings#ExtraPositionData]] is disabled.
*0=Sysop (default)
*1=SMod+
*2=Mod+

=== AlertCommand ===
''Datatype:'' Comma-delimited list.

If a player types any of these commands preceeded by a '?' followed by a message, subgame will send the message to all online staff. This is a replacement to the BanG ?cheater command. (1.34.3+)

=== AllowPubScorereset ===
''Datatype:'' Boolean.

If enabled, players in public arenas may use the ?scorereset command.

=== AllowPvtScorereset ===
''Datatype:'' Boolean.

If enabled, players in private arenas may use the ?scorereset command.

=== TimerDropFlagTerritoryRadius ===
''Datatype:'' Tiles.

All flags dropped when timer expires (non-neutral) will drop this radius from the ship, overriding [[Flag Settings#FlagTerritoryRadius]]. This is useful for respawning neuted flags (set FlagTerritoryRadius to 0). ''Special value:'' 0 = always use FlagTerritoryRadius.

=== ShipTypeSwitchResetPeriod ===
''Datatype:'' Milliseconds (?).

Determines length of time for [[Security Settings#MaxShipTypeSwitchCount]]. ''Special Value:'' 0 = disabled.

=== CheckWeapons ===
''Datatype:'' Boolean.

If enabled, any of the following conditions will trigger a security violation. The checks do not apply to SMod+.
* Bullet fired with level > [ship]MaxGuns + [Flag]FlaggerGunUpgrade
* Bouncing bullet fired and [PrizeWeight]BouncingBullets is 0 and [Cost]Bounce is 0
* Bomb fired with level > [ship]MaxBombs + [Flag]FlaggerBombUpgrade
* Prox bomb fired and [PrizeWeight]Proximity is 0 and [Cost]Prox is 0
* Bomb fired with shrap > [ship]ShrapnelMax
* Bomb fired with bouncing shrap and [PrizeWeight]BouncingBullets is 0 and [Cost]Bounce is 0
* Mine is fired and [ship]MaxMines is 0
* A prize is picked up and [PrizeWeight] of that prize is 0
* Stealth is turned on and [ship]StealthStatus is 0
* Cloak is turned on and [ship]CloakStatus is 0
* XRadar is turned on and [ship]XRadarStatus is 0
* Anti-Warp is turned on and [ship]AntiWarpStatus is 0
* Player uses UFO

=== CheckFastBombing ===
''Datatype:'' Bitfield.

*1 - Send sysop alert when fastbombing is detected
*2 - Filter out fastbombs
*4 - Kick fastbombing player off

=== FastBombingThreshold ===
See above.

=== LocalChat ===
''Datatype:'' Comma-delimited list.

Listed chat channels are local to the zone.

=== ForceObsceneCheck ===
''Datatype:'' Boolean.

Forces players to have obscene checking on.

=== NoFlagRewardLimit ===
''Datatype:'' Boolean.

Disables the default reward multiplier limit of 2 for [[Flag Settings#FlagRewardMode]].

=== LogPoints ===
=== PointUpdateDiff ===
''Datatype:'' Points.

Number of points that will trigger a score update sent to clients.

=== JackpotBroadcastPoints ===
''Datatype:'' Boolean.

If enabled, subgame will broadcast the jackpot points to all zones on the [[billing server]]. Not recommended.

=== ServerLog ===
''Datatype:'' Boolean.

If enabled, server will keep a text file log of events.

=== KeepAliveDelay ===
''Datatype:'' Milliseconds.

Delay between keepalive packets sent to clients. Should not be changed.

=== DefaultLevelFile ===
''Datatype:'' String.

Level file (such as _bzw.lvl) that zone will use for public arenas.

=== Port ===
''Datatype:'' Short.

Game port that subgame will user. Keep it above 1000 to avoid interference with other networking applications. This needs to be different for every zone running on the same server.

=== AllowVIEClients ===
''Datatype:'' Boolean.

Determines whether VIE [[SubSpace]] users are allowed to enter zone at all.

=== StaffChat ===
''Datatype:'' Comma-delimited list.

These chat channels are only joinable by Mods+.

=== ForceContinuumOnly ===
''Datatype:'' Boolean.

Determines whether only [[Continuum]] users are allowed to play.

=== ServerIP ===
''Datatype:'' IP Address.

WAN IP address of server computer. This can be found using http://www.whatismyip.com/ (easiest), ipconfig, or a router's status page.

== CPU ==
These settings determine subgame's CPU usage. Usually it performs well, so these should not be changed.

If you don't want subgame to take large amounts of CPU use these settings (or similar):
<pre>
ProcessMaxTime=4
SleepPerIteration=1
SleepTime=10
</pre>

=== LoopDelay ===
=== ProcessMaxTime ===
How long in CPU.
=== SleepPerIteration ===
Turns sleep on.
=== SlowIterationWarningLevel ===
=== SleepTime ===
How long until next in CPU.

== Permission ==
These settings restrict which clients may connect to your zone.

=== AllowBadMachineId ===
=== AllowLowBandwidth ===
=== MinimumSecondsToLogin ===
=== PermissionMaxPoints ===
=== PermissionMode ===
''Datatype:'' Boolean.

If enabled, only allows player names listed in permit.txt.

=== AutoPermissionPoints ===
=== AutoPermissionIDList ===
=== AutoPermissionMessage ===

== Password ==
Passwords for various player levels. Change to your heart's content.

=== SysopPassword ===
=== EnergyPassword ===
=== ModeratorPassword ===
=== SuperModeratorPassword ===
=== VIPPassword ===

== Billing ==
Configures subgame's interaction with the [[biller]].

=== LogMessages ===
''Datatype:'' Boolean.

Enables "logging" of commands to the biller. It is recommended to turn this off, as it normally just wastes bandwidth.

=== IP ===
''Datatype:'' IP/DNS address.

The address of the biller. If you are running the biller on the same computer as subgame, set this to <tt>localhost</tt>.

=== Password ===
''Datatype:'' String.

The password to connect to the biller. Normally, this should be the same as subbill.ini's Misc:Password.

=== ServerName ===
''Datatype:'' String.

The name of the zone that will be sent to the biller upon connection. This will also be sent to the directory server.

=== Port ===
''Datatype:'' Integer.

The port to connect to the biller, which should be equal to subbill.ini's Misc:Port.

=== ServerId ===
''Datatype:'' Integer.

The ServerID sent to the biller. This is not often used and should be equal to Misc:Port.

=== GroupId ===
''Datatype:'' Integer.

The group this server will join on the biller. This has to do with group operators, and is recommended to leave set to <tt>1</tt>

=== ScoreId ===
''Datatype:'' Integer.

The ScoreID of the server which the biller will use to identify your server between connections. This should normally be the same as Misc:Port.

=== ReconnectTime ===
Seems to have no effect.

=== AttemptTime ===
''Datatype:'' Hundredths of seconds.

How long subgame will attempt unsuccessfully to connect to the biller before it gives up.

== Advertise ==
These settings control subgame's built-in advertisement capability. To use advertisements, just create bitmaps in the SS Palette and save them in the subgame directory as ad0.bmp,ad1.bmp, etc. Prefix the name with "s_" to send to shareware players, with "r_" to send to registered players, and "b_" to send to both. For example, "b_ad0.bmp". Subgame will then randomly pick advertisements to display to players.

=== SendMode ===
''Datatype:'' Sum (bitfield).

Determines when advertisements are sent.
*1 = send them when the player enters the zone.
*2 = send them when player dies.

=== DisplayMode ===
''Datatype:'' Enumeration.

*0 = at top of screen behind all other graphics.
*1 = at top of screen on top of all other graphics.
*2 = floating around like a backdrop.

=== Duration ===
''Datatype:'' Milliseconds.

Length of time an advertisement is displayed. ''Special Value:'' 0 = always on.

== Directory ==
These settings configure subgame's interaction with the [[directory server]].

=== IP ===
''Datatype:'' IP/DNS list.

List of directory servers subgame will send its entry to. As of April 2007, the following list is recommended:
<pre>sscentral.sscuservers.net,ssdir.playsubspace.com</pre>


=== Description ===
''Datatype:'' String.

This description will be sent to the directory server to be associated with your zone. Include an ss:// DNS address to have Continuum keep your IP up to date (see [[Server_Configuration_Faq#What_does_the_ss:.2F.2Fsome.dns_mean_in_zone_description.3F|Server Configuration FAQ]]). You are advised not to use the "&" character inside the description, it displays incorrectly on some clients.

=== NamePassword ===
''Datatype:'' String.

The password associated with the zone's server prefix. All zones with the same prefix must have the same NamePassword or the Directory server will not list them.

=== Port ===
''Datatype:'' Integer.

Leave this set to <tt>4991</tt>.

[[Category:Settings]]

Talk:Writing Modules In C

2007-04-08T15:05:09Z

Smong: /* Bug? */

The example given for how to use the FOR_EACH_PLAYER macro doesn't show '''why''' you need a Link pointer named link!

The example just declares the variable, without initializing it to any value, and '''doesn't do anything with the Link pointer after that'''.

quote from article:
"''There is an ASSS macro, FOR_EACH_PLAYER, that will help us loop through every player. To use this macro we need: a Player* '''and a Link* named link.'''''"

[[User:Mine GO BOOM|Mine GO BOOM]] 15:56, Oct 3, 2006 (PDT): In player.h, the macro FOR_EACH_PLAYER is defined as the following. The for line assumes a '''Link*''' variable named '''link''' for it to work correctly. Under C++, you could initalize the '''link''' variable in the '''for''' loop but you cannot in C. A slightly better method would have the '''Link*''' variable name be include in the macro's definition instead of assuming a variable named '''link'''.
<pre>#define FOR_EACH_PLAYER(p) \
for ( \
link = LLGetHead(&pd->playerlist); \
link && ((p = link->data, link = link->next) || 1); )</pre>

=== Bug? ===

So looking back on this tutorial I think
<pre>
if (action == MM_LOAD)
{
mm = mm_;

chat = mm->GetInterface(I_CHAT,ALLARENAS);
aman = mm->GetInterface(I_ARENAMAN, ALLARENAS);
pd = mm->GetInterface(I_PLAYERDATA,ALLARENAS);

if (!chat || !aman || !pd) // check interfaces
rv = MM_FAIL;
else
{
// allocate data
arenaKey = aman->AllocateArenaData(sizeof(MyArenaData));
playerKey = pd->AllocatePlayerData(sizeof(MyPlayerData));

if (!arenaKey || !playerKey) // check if we ran out of memory
{
rv = MM_FAIL;
}
else
{ // declare callbacks, commands, and timers
mm->RegCallback(CB_SHIPCHANGE, ShipChange, ALLARENAS);
rv = MM_OK;
}
}
}
</pre>

fails to release the interfaces when there's an error, which will create problems when modules unload. After "rv = MM_FAIL;", in both instances, I think it's necessary to add
<pre>
mm->releaseInterface(chat);
mm->releaseInterface(aman);
mm->releaseInterface(pd);
</pre>

also, the modules shouldn't be listening for MM_ATTACH AND MM_DETACH if it's never using those guys (or the tutorial should cover what they do).

Let me know if I'm wrong. [[User:BaK|BaK]]

Yes the interfaces and allocated arena/player data should be freed properly. However since modules are usually loaded at startup if any module fails to load the server will exit, so any leaks would not matter. [[User:Smong|Smong]] 08:05, Apr 8, 2007 (PDT)

Server.ini

2007-03-28T09:40:48Z

Smong: /* CPU */ http://forums.minegoboom.com/viewtopic.php?p=70689#70689

server.ini is the initialization file for [[subgame]] that controls all of the global settings. Individual arena's settings are stored in arenaname.cfg. The following are the various sections in the server.ini.

<div style="float: right; margin-left: 20px">
__TOC__
</div>

== Validation ==

See [[Validation]].

== Custom ==
These settings configure custom arenas. (I think?)

=== ArenaMode ===
''Datatype:'' Enumeration.

This controls the ownership of private arenas. By "own a new subarena", it means that if the selected level of player creates a new subarena with ?go, and the arena does not have settings associated yet, subgame will create settings for that arena and assign [[arena ownership|ownership]] to the creating player. If the player creating the arena is below the selected level, subgame will still create settings for the arena, but will not grant ownership.
#Any player can own a new subarena.
#Mods+ can own a new subarena.
#Smods+ can own a new subarena.
#Sysops can own a new subarena.
#''Special:'' New subarenas will just use spawn.cfg. (That is, a new cfg must be placed in the server directory manually to give an arena its own settings.)

== Arena ==
These settings configure default arena settings.

=== ArenaMaxPlayers ===
''Datatype:'' Count.

Number of players allowed in any arena. (This can be overridden in the [[Misc Settings]] for an arena.)

=== ArenaDesiredPlayers ===
''Datatype:'' Count.

Subgame will create a new arena for entering players once an arena hits this population. This is different from the above setting in that users can still manually enter an arena with this population.

=== ArenaMinimumPlayers ===
''Datatype:'' Count.

Minimum number of players in a public arena before subgame automatically sends a message advising players to move on.

=== SpawnKeepScores ===
''Datatype:'' Boolean (1=yes,0=no).

Whether player-spawned arenas keep track of scores.

=== MaxArenas ===
''Datatype:'' Count.

The maximum number of arenas subgame will allow.

=== MaxArenasMemory ===
''Datatype:'' Bytes.

The maximum amount of memory subgame will allocate for arena data. Normally the default should suffice.

== Comms ==
Communication (networking) settings.

=== MaxQueueToLogin ===
''Datatype:'' Count.

Maximum number of clients waiting to login. Any that try when this limit is exceeded will receive the message "The server is busy handling other login requests. Please try again in a few moments. If problem persists, seek help at the Tech Support Forums found at www.subspacehq.com".

=== PacketHistoryMax ===

=== IncomingBufferSize ===

=== OutgoingBufferSize ===

=== EncryptMode ===

=== UnreliableBufferSize ===

=== TransportBufferSize ===

=== FlushTime ===
''Datatype:'' Milliseconds.

Subgame will queue position packets for this amount of time before sending them. ''Setting this too high will severly lag your zone.''

=== BandwithIdleTime ===
''Datatype:'' Seconds.

Subgame will stop sending position packets to a spectator after this time of inactivity. Useful for saving bandwidth.

=== SelectTime ===
''Datatype:'' Milliseconds.

Time delay subgame should wait for incoming packets before continuing on. This is recommended over CPU:SleepTime.

== Misc ==
Miscellaneous settings.

=== DisableShareware ===

=== RegisterKickShareware ===
''Datatype:'' Boolean.

Should subgame kick shareware users in favor of registered users when server is full? (Leave set to 0.)

=== MaxSharewarePlayers ===
''Datatype:'' Count.

Maximum number of shareware players allowed on server. ''Special Value:'' -1 = unlimited.

=== MaxPlayers ===
''Datatype:'' Count.

Maximum total players allowed in zone.

=== MaxSharewareTime ===

=== DisableSharewareNames ===
''Datatype:'' Boolean.

Disables the ability for demo players to have customized names. The default displayed name will just be "~Demo".

=== DisableSharewareShips ===
''Datatype:'' Boolean.

Disables the ability for demo players to use ships 5-8.

=== DisableSharewareScores ===
''Datatype:'' Boolean.

Disables the ability for demo players to retain their scores between sessions. ''Note:'' Scores will always be disabled if the players do not have a name.

=== MenuKickOutDelay ===
''Datatype:'' Hundredths of seconds.

Amount of time a player may take logging in before server disconnects client.

=== NoAntiInSafe ===
''Datatype:'' Boolean.

If enabled, subgame will ignore [[AntiWarp]] of a player in a safe zone.

=== LockFreqs ===
''Datatype:'' Boolean.

Determines whether [[Commands#Arena Management|locking]] an arena locks freqs as well as ships. (1.34.3+)

=== PositionDataAccess ===
''Datatype:'' Enumeration.

Determines staff level that will receive extra position data when speccing. Useful if [[Misc Settings#ExtraPositionData]] is disabled.
*0=Sysop (default)
*1=SMod+
*2=Mod+

=== AlertCommand ===
''Datatype:'' Comma-delimited list.

If a player types any of these commands preceeded by a '?' followed by a message, subgame will send the message to all online staff. This is a replacement to the BanG ?cheater command. (1.34.3+)

=== AllowPubScorereset ===
''Datatype:'' Boolean.

If enabled, players in public arenas may use the ?scorereset command.

=== AllowPvtScorereset ===
''Datatype:'' Boolean.

If enabled, players in private arenas may use the ?scorereset command.

=== TimerDropFlagTerritoryRadius ===
''Datatype:'' Tiles.

All flags dropped when timer expires (non-neutral) will drop this radius from the ship, overriding [[Flag Settings#FlagTerritoryRadius]]. This is useful for respawning neuted flags (set FlagTerritoryRadius to 0). ''Special value:'' 0 = always use FlagTerritoryRadius.

=== ShipTypeSwitchResetPeriod ===
''Datatype:'' Milliseconds (?).

Determines length of time for [[Security Settings#MaxShipTypeSwitchCount]]. ''Special Value:'' 0 = disabled.

=== CheckWeapons ===
''Datatype:'' Boolean.

If enabled, any of the following conditions will trigger a security violation. The checks do not apply to SMod+.
* Bullet fired with level > [ship]MaxGuns + [Flag]FlaggerGunUpgrade
* Bouncing bullet fired and [PrizeWeight]BouncingBullets is 0 and [Cost]Bounce is 0
* Bomb fired with level > [ship]MaxBombs + [Flag]FlaggerBombUpgrade
* Prox bomb fired and [PrizeWeight]Proximity is 0 and [Cost]Prox is 0
* Bomb fired with shrap > [ship]ShrapnelMax
* Bomb fired with bouncing shrap and [PrizeWeight]BouncingBullets is 0 and [Cost]Bounce is 0
* Mine is fired and [ship]MaxMines is 0
* A prize is picked up and [PrizeWeight] of that prize is 0
* Stealth is turned on and [ship]StealthStatus is 0
* Cloak is turned on and [ship]CloakStatus is 0
* XRadar is turned on and [ship]XRadarStatus is 0
* Anti-Warp is turned on and [ship]AntiWarpStatus is 0
* Player uses UFO

=== CheckFastBombing ===
''Datatype:'' Bitfield.

*1 - Send sysop alert when fastbombing is detected
*2 - Filter out fastbombs
*4 - Kick fastbombing player off

=== FastBombingThreshold ===
See above.

=== LocalChat ===
''Datatype:'' Comma-delimited list.

Listed chat channels are local to the zone.

=== ForceObsceneCheck ===
''Datatype:'' Boolean.

Forces players to have obscene checking on.

=== NoFlagRewardLimit ===
''Datatype:'' Boolean.

Disables the default reward multiplier limit of 2 for [[Flag Settings#FlagRewardMode]].

=== LogPoints ===
=== PointUpdateDiff ===
''Datatype:'' Points.

Number of points that will trigger a score update sent to clients.

=== JackpotBroadcastPoints ===
''Datatype:'' Boolean.

If enabled, subgame will broadcast the jackpot points to all zones on the [[billing server]]. Not recommended.

=== ServerLog ===
''Datatype:'' Boolean.

If enabled, server will keep a text file log of events.

=== KeepAliveDelay ===
''Datatype:'' Milliseconds.

Delay between keepalive packets sent to clients. Should not be changed.

=== DefaultLevelFile ===
''Datatype:'' String.

Level file (such as _bzw.lvl) that zone will use for public arenas.

=== Port ===
''Datatype:'' Short.

Game port that subgame will user. Keep it above 1000 to avoid interference with other networking applications. This needs to be different for every zone running on the same server.

=== AllowVIEClients ===
''Datatype:'' Boolean.

Determines whether VIE [[SubSpace]] users are allowed to enter zone at all.

=== StaffChat ===
''Datatype:'' Comma-delimited list.

These chat channels are only joinable by Mods+.

=== ForceContinuumOnly ===
''Datatype:'' Boolean.

Determines whether only [[Continuum]] users are allowed to play.

=== ServerIP ===
''Datatype:'' IP Address.

WAN IP address of server computer. This can be found using http://www.whatismyip.com/ (easiest), ipconfig, or a router's status page.

== CPU ==
These settings determine subgame's CPU usage. Usually it performs well, so these should not be changed.

If you don't want subgame to take large amounts of CPU use these settings (or similar):
<pre>
ProcessMaxTime=4
SleepPerIteration=1
SleepTime=10
</pre>

=== LoopDelay ===
=== ProcessMaxTime ===
How long in CPU.
=== SleepPerIteration ===
Turns sleep on.
=== SlowIterationWarningLevel ===
=== SleepTime ===
How long until next in CPU.

== Permission ==
These settings restrict which clients may connect to your zone.

=== AllowBadMachineId ===
=== AllowLowBandwidth ===
=== MinimumSecondsToLogin ===
=== PermissionMaxPoints ===
=== PermissionMode ===
''Datatype:'' Boolean.

If enabled, only allows player names listed in permit.txt.

=== AutoPermissionPoints ===
=== AutoPermissionIDList ===
=== AutoPermissionMessage ===

== Password ==
Passwords for various player levels. Change to your heart's content.

=== SysopPassword ===
=== EnergyPassword ===
=== ModeratorPassword ===
=== SuperModeratorPassword ===
=== VIPPassword ===

== Billing ==
Configures subgame's interaction with the [[biller]].

=== LogMessages ===
''Datatype:'' Boolean.

Enables "logging" of commands to the biller. It is recommended to turn this off, as it normally just wastes bandwidth.

=== IP ===
''Datatype:'' IP/DNS address.

The address of the biller. If you are running the biller on the same computer as subgame, set this to <tt>localhost</tt>.

=== Password ===
''Datatype:'' String.

The password to connect to the biller. Normally, this should be the same as subbill.ini's Misc:Password.

=== ServerName ===
''Datatype:'' String.

The name of the zone that will be sent to the biller upon connection. This will also be sent to the directory server.

=== Port ===
''Datatype:'' Integer.

The port to connect to the biller, which should be equal to subbill.ini's Misc:Port.

=== ServerId ===
''Datatype:'' Integer.

The ServerID sent to the biller. This is not often used and should be equal to Misc:Port.

=== GroupId ===
''Datatype:'' Integer.

The group this server will join on the biller. This has to do with group operators, and is recommended to leave set to <tt>1</tt>

=== ScoreId ===
''Datatype:'' Integer.

The ScoreID of the server which the biller will use to identify your server between connections. This should normally be the same as Misc:Port.

=== ReconnectTime ===
Seems to have no effect.

=== AttemptTime ===
''Datatype:'' Hundredths of seconds.

How long subgame will attempt unsuccessfully to connect to the biller before it gives up.

== Advertise ==
These settings control subgame's built-in advertisement capability. To use advertisements, just create bitmaps in the SS Palette and save them in the subgame directory as ad0.bmp,ad1.bmp, etc. Prefix the name with "s_" to send to shareware players, with "r_" to send to registered players, and "b_" to send to both. For example, "b_ad0.bmp". Subgame will then randomly pick advertisements to display to players.

=== SendMode ===
''Datatype:'' Sum (bitfield).

Determines when advertisements are sent.
*1 = send them when the player enters the zone.
*2 = send them when player dies.

=== DisplayMode ===
''Datatype:'' Enumeration.

*0 = at top of screen behind all other graphics.
*1 = at top of screen on top of all other graphics.
*2 = floating around like a backdrop.

=== Duration ===
''Datatype:'' Milliseconds.

Length of time an advertisement is displayed. ''Special Value:'' 0 = always on.

== Directory ==
These settings configure subgame's interaction with the [[directory server]].

=== IP ===
''Datatype:'' IP/DNS list.

List of directory servers subgame will send its entry to. As of June 2006, the following list is recommended:
<pre>sscentral.subspace.inet.fi,ssdir.playsubspace.com</pre>


=== Description ===
''Datatype:'' String.

This description will be sent to the directory server to be associated with your zone. Include an ss:// DNS address to have Continuum keep your IP up to date (see [[Server_Configuration_Faq#What_does_the_ss:.2F.2Fsome.dns_mean_in_zone_description.3F|Server Configuration FAQ]]). You are advised not to use the "&" character inside the description, it displays incorrectly on some clients.

=== NamePassword ===
''Datatype:'' String.

The password associated with the zone's server prefix. All zones with the same prefix must have the same NamePassword or the Directory server will not list them.

=== Port ===
''Datatype:'' Integer.

Leave this set to <tt>4991</tt>.

[[Category:Settings]]

Talk:Hosts

2007-03-26T14:32:43Z

Smong: sso updates

[[User:CypherJF|CypherJF]]: Actually I don't think SSN is run by L Chance anymore. I'm not sure the history of it but the latest back I can remember was Altec . running it with Sideburn? Spring/Summer of 2004, Altec . and L Chance brought back SSN using Lord Maucaub's biller system. They shut it back down after HALO switched back to SSZ; and now I believe Dark Mistress / TheBest999 / Cospar / MS-DOS; someone is running it.

[[User:Smong|Smong]]: I think NTC has it now. They keep changing tags which is annoying. For the record I remember them with SSDM and TNT too if you want to stick that in a 'most annoying network decisions ever' page.

[[User:CypherJF|CypherJF]]: Yeah NTC is the Dark Mistress / TheBest999 / Cospar / MS-DOS network.

[[User:Smong|Smong]]:Someone add NTC and SSDT at least. Also I think this page should be called Networks, but that is more jargon I guess and could easily be confused.

[[User:D1st0rt|D1st0rt]]:Whoa 17th is near me? Trench still has a lower ping

== Category? ==

There's already a category called ''Servers'', don't you think this should belong there? I know you couldn't have the short descriptions, but they're kinda hard to keep track of and not that useful. --[[User:Cyan~Fire|Cyan~Fire]]

Well, hmm. We could always make each server its own category, the short desc goes on the category desc, and each zone is added to the specific server category they are on. [[User:Pests|Pests]]

[[User:Smong|Smong]]: I don't think search looks at categories (I feel like I am typing that several times a day).

I wasn't saying remove the page, just saying get rid of the server list, since it'll soon become outdated and is redundant. But, whatever, no biggie. --[[User:Cyan~Fire|Cyan~Fire]]

== Combine Pages? ==

Since there's actually not all that much info to put about each of these servers, how would you feel about me merging all of the individual server pages here? This page could be divided up into Active and Inactive servers, if that's a problem. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: SSZ Subspace Network? I think that needs changing. SSN is still run by L. Chance? Also who nicked the css for the wiki?

== Cleanup ==

[[User:Smong|Smong]]:
I don't like the look of this page. First Servers, I would prefer a page called Hosts or Networks.

Next a table of active networks, columns are: tag, owners + contact, website, billing (yes, own billing/yes, tag of other biller/no biller) and location. <s>A network is considered active if it has its own menu on [http://stats.17thparallel.com stats.17thparallel.com].</s>

[[User:Smong|Smong]] 16:10, Mar 11, 2007 (PDT): A network is any tag with more than 1 zone or has been up for a noticeable period of time.

<table border=1>
<tr><th>Tag</th><th>Operators</th><th>Website</th><th>Billing</th><th>Location</th></tr>
<tr><td>CSSS</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, Central</td></tr>
<tr><td>PSS</td><td>Doc Flabby</td><td>[http://www.playsubspace.com/ www.playsubspace.com]</td><td>unknown</td><td>USA, West</td></tr>
<tr><td>SSCC</td><td>Freakmonger<td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCE</td><td>Luminate <luminate rshl.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCI</td><td>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Central</td></tr>
<tr><td>SSCU</td><td>PriitK <priitk trenchwars.org><br>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Multiple</td></tr>
<tr><td>SSCX</td><td>PriitK <priitk trenchwars.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSDC</td><td>blackjayde <support xtremegaming.net></td><td>[http://ssdc.xtremegaming.net/ ssdc.xtremegaming.net]</td><td>SSDC</td><td>USA, East</td></tr>
<tr><td>SSEO</td><td>cybersnipe, contempt</td><td>http://www.ssenetwork.com/</td><td>SSE</td><td>USA, East</td></tr>
<tr><td>SSL</td><td>Steigerwald</td><td>N/A</td><td>N/A</td><td>USA, Central</td></tr>
<tr><td>SSO</td><td>cybersnipe, contempt</td><td>http://www.ssenetwork.com/</td><td>SSE</td><td>USA, East</td></tr>
<tr><td>SST</td><td>Confess <confess321 yahoo.com><br>Top Gun. <ajchuck achosting.net></td><td>[http://www.ssthosting.net www.ssthosting.net]</td><td>SST</td><td>USA, East</td></tr>
<tr><td>T3</td><td>Mecbot+</td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
</table>

The purpose of this table is to serve as a summary of active hosts and so people can quickly find contact details of who is operating them.

Next, a seperate section (or possibly page) containing a history of the networks, start/end dates, ownership, comments (reason for creation/closure, generally accepted reputation).

[[User:I88gerbils|i88gerbils]]: Why not give a brief 1-line summary of TAG, host, web site making the tag a wiki link to description + contact information? Kind of like the corporation info bar on wikipedia.

{{host|Tag=SSCX|ServerName=SubSpace X|Contact=Xalimar|Email=}}? {{zone}}?

Agreed with basically all of this. I'll change the name now, and probably separate this at least into current and historical. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: There's a long way yet to go. I'm still making my way through the recent changes and may start rewriting this page later.

--[[User:I88gerbils|i88gerbils]] 16:24, Mar 10, 2006 (EST): I like my style better. It's pretty easy to just add a standard wiki template to add an entry. And probably easier to add CSS for just that template to pretty it up if MGB wants.

Talk:Hosts

2007-03-11T23:10:22Z

Smong: added pss

[[User:CypherJF|CypherJF]]: Actually I don't think SSN is run by L Chance anymore. I'm not sure the history of it but the latest back I can remember was Altec . running it with Sideburn? Spring/Summer of 2004, Altec . and L Chance brought back SSN using Lord Maucaub's biller system. They shut it back down after HALO switched back to SSZ; and now I believe Dark Mistress / TheBest999 / Cospar / MS-DOS; someone is running it.

[[User:Smong|Smong]]: I think NTC has it now. They keep changing tags which is annoying. For the record I remember them with SSDM and TNT too if you want to stick that in a 'most annoying network decisions ever' page.

[[User:CypherJF|CypherJF]]: Yeah NTC is the Dark Mistress / TheBest999 / Cospar / MS-DOS network.

[[User:Smong|Smong]]:Someone add NTC and SSDT at least. Also I think this page should be called Networks, but that is more jargon I guess and could easily be confused.

[[User:D1st0rt|D1st0rt]]:Whoa 17th is near me? Trench still has a lower ping

== Category? ==

There's already a category called ''Servers'', don't you think this should belong there? I know you couldn't have the short descriptions, but they're kinda hard to keep track of and not that useful. --[[User:Cyan~Fire|Cyan~Fire]]

Well, hmm. We could always make each server its own category, the short desc goes on the category desc, and each zone is added to the specific server category they are on. [[User:Pests|Pests]]

[[User:Smong|Smong]]: I don't think search looks at categories (I feel like I am typing that several times a day).

I wasn't saying remove the page, just saying get rid of the server list, since it'll soon become outdated and is redundant. But, whatever, no biggie. --[[User:Cyan~Fire|Cyan~Fire]]

== Combine Pages? ==

Since there's actually not all that much info to put about each of these servers, how would you feel about me merging all of the individual server pages here? This page could be divided up into Active and Inactive servers, if that's a problem. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: SSZ Subspace Network? I think that needs changing. SSN is still run by L. Chance? Also who nicked the css for the wiki?

== Cleanup ==

[[User:Smong|Smong]]:
I don't like the look of this page. First Servers, I would prefer a page called Hosts or Networks.

Next a table of active networks, columns are: tag, owners + contact, website, billing (yes, own billing/yes, tag of other biller/no biller) and location. <s>A network is considered active if it has its own menu on [http://stats.17thparallel.com stats.17thparallel.com].</s>

[[User:Smong|Smong]] 16:10, Mar 11, 2007 (PDT): A network is any tag with more than 1 zone or has been up for a noticeable period of time.

<table border=1>
<tr><th>Tag</th><th>Operators</th><th>Website</th><th>Billing</th><th>Location</th></tr>
<tr><td>CSSS</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, Central</td></tr>
<tr><td>PSS</td><td>Doc Flabby</td><td>[http://www.playsubspace.com/ www.playsubspace.com]</td><td>unknown</td><td>USA, West</td></tr>
<tr><td>SSCC</td><td>Freakmonger<td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCE</td><td>Luminate <luminate rshl.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCI</td><td>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Central</td></tr>
<tr><td>SSCU</td><td>PriitK <priitk trenchwars.org><br>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Multiple</td></tr>
<tr><td>SSCX</td><td>PriitK <priitk trenchwars.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSDC</td><td>blackjayde <support xtremegaming.net></td><td>[http://ssdc.xtremegaming.net/ ssdc.xtremegaming.net]</td><td>SSDC</td><td>USA, East</td></tr>
<tr><td>SSEO</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, East</td></tr>
<tr><td>SSL</td><td>Steigerwald</td><td>N/A</td><td>N/A</td><td>USA, Central</td></tr>
<tr><td>SST</td><td>Confess <confess321 yahoo.com><br>Top Gun. <ajchuck achosting.net></td><td>[http://www.ssthosting.net www.ssthosting.net]</td><td>SST</td><td>USA, East</td></tr>
<tr><td>T3</td><td>Mecbot+</td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
</table>

The purpose of this table is to serve as a summary of active hosts and so people can quickly find contact details of who is operating them.

Next, a seperate section (or possibly page) containing a history of the networks, start/end dates, ownership, comments (reason for creation/closure, generally accepted reputation).

[[User:I88gerbils|i88gerbils]]: Why not give a brief 1-line summary of TAG, host, web site making the tag a wiki link to description + contact information? Kind of like the corporation info bar on wikipedia.

{{host|Tag=SSCX|ServerName=SubSpace X|Contact=Xalimar|Email=}}? {{zone}}?

Agreed with basically all of this. I'll change the name now, and probably separate this at least into current and historical. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: There's a long way yet to go. I'm still making my way through the recent changes and may start rewriting this page later.

--[[User:I88gerbils|i88gerbils]] 16:24, Mar 10, 2006 (EST): I like my style better. It's pretty easy to just add a standard wiki template to add an entry. And probably easier to add CSS for just that template to pretty it up if MGB wants.

Talk:Hosts

2007-03-11T22:58:57Z

Smong: updated hosts table

[[User:CypherJF|CypherJF]]: Actually I don't think SSN is run by L Chance anymore. I'm not sure the history of it but the latest back I can remember was Altec . running it with Sideburn? Spring/Summer of 2004, Altec . and L Chance brought back SSN using Lord Maucaub's biller system. They shut it back down after HALO switched back to SSZ; and now I believe Dark Mistress / TheBest999 / Cospar / MS-DOS; someone is running it.

[[User:Smong|Smong]]: I think NTC has it now. They keep changing tags which is annoying. For the record I remember them with SSDM and TNT too if you want to stick that in a 'most annoying network decisions ever' page.

[[User:CypherJF|CypherJF]]: Yeah NTC is the Dark Mistress / TheBest999 / Cospar / MS-DOS network.

[[User:Smong|Smong]]:Someone add NTC and SSDT at least. Also I think this page should be called Networks, but that is more jargon I guess and could easily be confused.

[[User:D1st0rt|D1st0rt]]:Whoa 17th is near me? Trench still has a lower ping

== Category? ==

There's already a category called ''Servers'', don't you think this should belong there? I know you couldn't have the short descriptions, but they're kinda hard to keep track of and not that useful. --[[User:Cyan~Fire|Cyan~Fire]]

Well, hmm. We could always make each server its own category, the short desc goes on the category desc, and each zone is added to the specific server category they are on. [[User:Pests|Pests]]

[[User:Smong|Smong]]: I don't think search looks at categories (I feel like I am typing that several times a day).

I wasn't saying remove the page, just saying get rid of the server list, since it'll soon become outdated and is redundant. But, whatever, no biggie. --[[User:Cyan~Fire|Cyan~Fire]]

== Combine Pages? ==

Since there's actually not all that much info to put about each of these servers, how would you feel about me merging all of the individual server pages here? This page could be divided up into Active and Inactive servers, if that's a problem. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: SSZ Subspace Network? I think that needs changing. SSN is still run by L. Chance? Also who nicked the css for the wiki?

== Cleanup ==

[[User:Smong|Smong]]:
I don't like the look of this page. First Servers, I would prefer a page called Hosts or Networks.

Next a table of active networks, columns are: tag, owners + contact, website, billing (yes, own billing/yes, tag of other biller/no biller) and location. A network is considered active if it has its own menu on [http://stats.17thparallel.com stats.17thparallel.com].

<table border=1>
<tr><th>Tag</th><th>Operators</th><th>Website</th><th>Billing</th><th>Location</th></tr>
<tr><td>CSSS</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, Central</td></tr>
<tr><td>SSCC</td><td>Freakmonger<td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCE</td><td>Luminate <luminate rshl.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSCI</td><td>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Central</td></tr>
<tr><td>SSCU</td><td>PriitK <priitk trenchwars.org><br>Argyle<br>Death+ <dxexaxtxh gmail.com></td><td>N/A</td><td>SSC</td><td>USA, Multiple</td></tr>
<tr><td>SSCX</td><td>PriitK <priitk trenchwars.org></td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
<tr><td>SSDC</td><td>blackjayde <support xtremegaming.net></td><td>[http://ssdc.xtremegaming.net/ ssdc.xtremegaming.net]</td><td>SSDC</td><td>USA, East</td></tr>
<tr><td>SSEO</td><td>unknown</td><td>N/A</td><td>unknown</td><td>USA, East</td></tr>
<tr><td>SSL</td><td>Steigerwald</td><td>N/A</td><td>N/A</td><td>USA, Central</td></tr>
<tr><td>SST</td><td>Confess <confess321 yahoo.com><br>Top Gun. <ajchuck achosting.net></td><td>[http://www.ssthosting.net www.ssthosting.net]</td><td>SST</td><td>USA</td></tr>
<tr><td>T3</td><td>Mecbot+</td><td>N/A</td><td>SSC</td><td>USA, East</td></tr>
</table>

The purpose of this table is to serve as a summary of active hosts and so people can quickly find contact details of who is operating them.

Next, a seperate section (or possibly page) containing a history of the networks, start/end dates, ownership, comments (reason for creation/closure, generally accepted reputation).

[[User:I88gerbils|i88gerbils]]: Why not give a brief 1-line summary of TAG, host, web site making the tag a wiki link to description + contact information? Kind of like the corporation info bar on wikipedia.

{{host|Tag=SSCX|ServerName=SubSpace X|Contact=Xalimar|Email=}}? {{zone}}?

Agreed with basically all of this. I'll change the name now, and probably separate this at least into current and historical. --[[User:Cyan~Fire|Cyan~Fire]]

[[User:Smong|Smong]]: There's a long way yet to go. I'm still making my way through the recent changes and may start rewriting this page later.

--[[User:I88gerbils|i88gerbils]] 16:24, Mar 10, 2006 (EST): I like my style better. It's pretty easy to just add a standard wiki template to add an entry. And probably easier to add CSS for just that template to pretty it up if MGB wants.

TCP Billing FAQ

2007-02-11T15:14:29Z

Smong: added two new questions, deleted old unanswered question

== What's so special about TCP billers? ==
TCP billers use a new simpler protocol compared to the original UDP billers.

== Can I use subgame with a TCP biller? ==
No, currently only ASSS can connect to a TCP biller. It is possible to use proxy to convert between the UDP and TCP protocols to allow subgame.

== Why is there no ability for the billing server to shutdown/restart a server? ==
The ability of the billing servers to shutdown a zone server is a relic from the old system. The biller is no longer an administrative and control server, but simply a validation system used to control passwords for player names and bans.

== Are there any TCP billers available for public download? ==
Yes, but only unfinished ones.

* Two different versions of [[POCoB]] written by [[User:Smong|Smong]] are available at http://toktok.sscentral.com/ss-pocob.php.
* [[SkyBill]] written by [[User:Doc flabby|Doc Flabby]] is available at http://playsubspace.com.

[[Category: FAQ]]
[[Category: Protocol]]

TCP Billing FAQ

2007-02-11T15:07:47Z

Smong: /* Are there any TCP billers available for public download? */ grammar

== Why is there no ability for the billing server to shutdown/restart a server? ==
The ability of the billing servers to shutdown a zone server is a relic from the old system. The biller is no longer an administrative and control server, but simply a validation system used to control passwords for player names and bans.

== Are there any TCP billers available for public download? ==
Yes, but only unfinished ones.

* Two different versions of [[POCoB]] written by [[User:Smong|Smong]] are available at http://toktok.sscentral.com/ss-pocob.php.
* [[SkyBill]] written by [[User:Doc flabby|Doc Flabby]] is available at http://playsubspace.com.

== Why should I use a TCP biller instead of something like SSC? ==
- answer me -

[[Category: FAQ]]
[[Category: Protocol]]

TCP Billing FAQ

2007-02-11T15:07:20Z

Smong: /* Are there any TCP billers available for public download? */ ew, cleaned this up.

== Why is there no ability for the billing server to shutdown/restart a server? ==
The ability of the billing servers to shutdown a zone server is a relic from the old system. The biller is no longer an administrative and control server, but simply a validation system used to control passwords for player names and bans.

== Are there any TCP billers available for public download? ==
Yes, but only unfinished ones.

* Two different versions of [[POCoB]] written by [[User:Smong|Smong]] is available at http://toktok.sscentral.com/ss-pocob.php.
* [[SkyBill]] written by [[User:Doc flabby|Doc Flabby]] is available at http://playsubspace.com.

== Why should I use a TCP biller instead of something like SSC? ==
- answer me -

[[Category: FAQ]]
[[Category: Protocol]]

Talk:Biller

2007-02-11T15:00:32Z

Smong:

"Today, the name Billing Server is confusing as it is just a user database."
How is that so? -L.C.

Because no one is "billed" for playing this game. Today its primary function is storing user accounts. -Smong

Zone.dat

2007-01-15T10:12:43Z

Smong: fixed category

== Zone.dat format ==

For each zone an entry like this must exist.

The last field indicates that [[Continuum]] will not warn you are entering a non-[[SSC]] zone. This is changed to 1 if you tick the box do not warn me again in Continuum. The unknown field often seems to contain a dns name for some zones such as "server.trenchwars.org" for Trench Wars.
<Warn non-SSC zone> value is ignored by Continuum if the zone is an SSC zone.

<pre>
<Zone name>,<Zone ip>,<Zone port>,<unknown dns (can be left blank)>,<Warn non-SSC zone>
#<description>
</pre>

Example:

<pre>
SSCU Trench Wars,66.36.241.110,5400,server.trenchwars.org,0
#SSCU Trench Wars - Sysops: DoCk> and PriitK - http://www.trenchwars.org ss://server.trenchwars.org
</pre>

== Tips and Tricks ==

In the zone description you can prefix URLs with a name in brackets like so:
<pre>
(Zone Website)http://zone.website/
</pre>
Then in the "Web Links & News" menu you can name your links.

[[Category: Formats]]

Zone.dat

2007-01-15T10:11:33Z

Smong: /* Tips and Tricks */ added naming links tip

[[Category:Category Formats]]

== Zone.dat format ==

For each zone an entry like this must exist.

The last field indicates that [[Continuum]] will not warn you are entering a non-[[SSC]] zone. This is changed to 1 if you tick the box do not warn me again in Continuum. The unknown field often seems to contain a dns name for some zones such as "server.trenchwars.org" for Trench Wars.
<Warn non-SSC zone> value is ignored by Continuum if the zone is an SSC zone.

<pre>
<Zone name>,<Zone ip>,<Zone port>,<unknown dns (can be left blank)>,<Warn non-SSC zone>
#<description>
</pre>

Example:

<pre>
SSCU Trench Wars,66.36.241.110,5400,server.trenchwars.org,0
#SSCU Trench Wars - Sysops: DoCk> and PriitK - http://www.trenchwars.org ss://server.trenchwars.org
</pre>

== Tips and Tricks ==

In the zone description you can prefix URLs with a name in brackets like so:
<pre>
(Zone Website)http://zone.website/
</pre>
Then in the "Web Links & News" menu you can name your links.

Misc Settings

2006-11-30T17:08:14Z

Smong: /* VictoryMusic */ redefinition, at least for asss

[Misc] These settings determine various arena properties that (supposedly) didn't fit in any other section.

=== FrequencyShipTypes ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether ships are frequency-specific (freq0 uses warbird, freq1 uses javelin, and so on).

=== WarpPointDelay ===
''Datatype:'' Hundredths of seconds.

How long a Portal point is active.

=== DecoyAliveTime ===
''Datatype:'' Hundredths of seconds.

Time before a decoy disappears. Note that decoy will instantly disappear if owner enters safe zone.

=== BounceFactor ===
''Datatype:'' Factor.

How bouncy the walls are. ''Formula:'' SpeedAfter = SpeedBefore * (16 / BounceFactor).

=== SafetyLimit ===
''Datatype:'' Hundredths of seconds. (90000 = 15 mins)

Time a player can spend in the safe zone before getting kicked. Use this to encourage users to spec when AFK.

=== TickerDelay ===
''Datatype:'' Hundredths of seconds.

Time between ticker help messages.

=== WarpRadiusLimit ===
''Datatype:'' Tiles.

Ships randomly placed on the map can be a maximum of this far from the map's center. Note that 1024 will cover the entire map.

=== ActivateAppShutdownTime ===
''Datatype:'' Hundredths of seconds.

Time a ship is shutdown when user reactivates client application (when user comes back from Windows mode).

=== NearDeathLevel ===
''Datatype:'' Energy.

Energy that constitutes a near-death experience. The server will reduce the ship's bounty by 1 when this occurs. (Used for dueling zones.)

=== VictoryMusic ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether the zone plays the victory music when a team is winning a flag game.

In ASSS (1.4.3) victory music will always be played when a team is winning (provided you are using the default fg_wz module). I set to 1 this setting instead has the effect of disallowing staff from forcefully starting the victory music by typing %100.

=== BannerPoints ===
''Datatype:'' Points.

Points required for a player to display a banner.

=== MaxLossesToPlay ===
''Datatype:'' Count.

Deaths before a player is forced into spectator mode. ''Special Value:'' 0 = no limit.

=== SpectatorQuiet ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether spectators can talk to active players.

=== MaxPlaying ===
''Datatype:'' Count.

Maximum number of players that can be playing (not spectating) at one time. ''Special Value:'' 0 = no limit (but still obeys maximum players in arena). Staff can bypass this limit. Also this setting really means MaxPlaying-1=..., so MaxPlaying=7 actually allows 8 players.

=== TimedGame ===
''Datatype:'' Hundredths of a second.

Time in a timed game (like speed zone). ''Special Value:'' 0 = not a timed game.

=== ResetScoreOnFrequencyChange ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether a player changing frequency resets his score. (Used primarily for timed games like soccer.)

=== SendPositionDelay ===
''Datatype:'' Hundredths of a second (0 to 20).

Time between position packets sent by clients. Do not modify this setting without a good reason.

=== SlowFrameCheck ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether to check for slow frames on the client (possible cheat technique). '''Warning:''' flawed on some machines, do not use.

=== SlowFrameRate ===
''Datatype:'' Frames per second (0 to 35).

A frame rate less than this setting is considered slow by the above setting.

=== AllowSavedShips ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether ships' stats are saved between arenas and after lagouts. Do not enable this if subarenas have different ship settings.

=== FrequencyShift ===
''Datatype:'' Hertz (0 to 10000).

Random frequency shift applied to sounds to make them more realistic.

=== ExtraPositionData ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether regular players receive sysop data about a ship. Leave this off.

=== SheepMessage ===
''Datatype:'' String.

Message that appears when a player types ?sheep, in commemoration of the first sheep cloning. Sound 24 '[http://wiki.minegoboom.com/upload/sounds/bong24.wav baa]' is sent with the message.

=== MaxPlayers ===
''Datatype:'' Count.

Maximum amount of players in this arena. Will override server.ini's max arena setting.

=== GreetMessage ===
''Datatype:'' String.

This message will be sent when a player enters the arena. Note that if the arena is public, then it will essentially be a zone-enter message.

=== PeriodicMessage0 ===
''Datatype:'' Mixed.

This setting and the following set automatically repeating arena messages. Must be set to this format: [Repeat Delay] [Delay before start after arena creation] [Message]. Delays are in minutes. Prefix [Message] with '*' to make the message zone-wide. ''Special Value:'' 0 = no message.

=== PeriodicMessage1 ===
''Datatype:'' Mixed.

See above.

=== PeriodicMessage2 ===
''Datatype:'' Mixed.

See above.

=== PeriodicMessage3 ===
''Datatype:'' Mixed.

See above.

=== PeriodicMessage4 ===
''Datatype:'' Mixed.

See above.

=== MaxXRes ===
''Datatype:'' Resolution.

Max X-res allowed. ''Special Value:'' 0 = no limit

=== MaxYRes ===
''Datatype:'' Resolution.

Max Y-res allowed. ''Special Value:'' 0 = no limit

=== ContinuumOnly ===
''Datatype:'' Boolean (1=yes, 0=no).

Enable to allow VIE clients only to spec, and not to play.

=== LevelFiles ===
''Datatype:'' Filename list.

Files used by arena, seperated by commas, that will be downloaded via client. A '+' in front of a file will make it optional. Put LVZs here.

=== MinUsage ===
''Datatype:'' Hours.

Total usage required to play in this arena.

=== StartInSpec ===
''Datatype:'' Boolean (1=yes, 0=no).

Enable to make all players enter in spec, no matter what ship they choose on the menu.

=== MaxTimerDrift ===
''Datatype:'' Tenths of a percent.

Percentage of how much client timer is allowed to differ from server timer.

=== DisableScreenshot ===
''Datatype:'' Boolean (1=yes, 0=no).

Only allows spectators to take screenshots.

=== AntiWarpSettleDelay ===
''Datatype:'' Hundredths of seconds.

Delay after a player warps/portals/attaches before he can warp/portal/attach again. (Acts like a personal antiwarp.)

=== SaveSpawnScore ===
''Datatype:'' Boolean (1=yes, 0=no).

Whether to save spawn scores to arenaname.scr. Disable to prevent creation of large amounts of *.scr files in the server directory.

=== TeamKillPoints ===
''Datatype:'' Boolean (1=yes, 0=no).<br>
''Compatibility:'' ASSS.

Whether points are awarded for a team-kill.

[[Category: Settings]]

MERVBot

2006-11-22T17:19:22Z

Smong: fixed link to catids site

MERVBot is an open source bot core written by [[catid]] in C++. It is modular, meaning that you can download user made plugins that will perform a desired action (such as Elim, or Lag Checking).

== Download ==
*[http://catid.ssihosting.com/files/MERVBot.rar Latest Version]
*A [[MERVBot_script|script for running MERVBot inside linux]].

Here is a rather dubious link to a rar unpacker for those of you that don't like the rar icon ftp://ftp.externet.hu/pub/mirror/sac/pack/unpacker.zip

== Resources ==
*[http://catid.sscontinuum.com Homepage]
*[[MERVBot Tutorial]]

[[Category: Bots]]