Difference between revisions of "Community Server"

From Xeriar
Jump to navigationJump to search
Line 9: Line 9:
 
* Added options to server_ini to set game start dates, allow map usage by players, the names and passes to the information files, set the server roller, and the name of the lobby.
 
* Added options to server_ini to set game start dates, allow map usage by players, the names and passes to the information files, set the server roller, and the name of the lobby.
 
* Fixed the dieroller code a little, amongst other things, no longer requires people to copy utils.py, die.py, or other dieroller files arouund.
 
* Fixed the dieroller code a little, amongst other things, no longer requires people to copy utils.py, die.py, or other dieroller files arouund.
 +
* Banned players may not join rooms
  
 
== Features ==
 
== Features ==

Revision as of 00:52, 28 July 2006

This is a version of the mplay_server.py file for OpenRPG that enables communities to monitor their activity, mainly for things such as persistant games like NeoDBZ (which the older version was originally written for). The new version was written for Solar Storms, and is significantly more stable, and has a few other nice features.

Updates

Updates to version B

  • Information file added
  • Roster and information files are now sent as tree nodes
  • A few bugfixes
  • Added options to server_ini to set game start dates, allow map usage by players, the names and passes to the information files, set the server roller, and the name of the lobby.
  • Fixed the dieroller code a little, amongst other things, no longer requires people to copy utils.py, die.py, or other dieroller files arouund.
  • Banned players may not join rooms

Features

  1. It logs chat and tree activity, including whispers.
  2. It has a server-sided dieroller, which has some protections against rollspamming.
  3. It has some minor protections against spamming the chat or forcing scrolling.
  4. It has further anti-cheat and anti-annoyance functionality.
  5. It provides a Roster file that can be used to track players
  6. It has a secondary Information file for general GM usage
  7. It provides a means by which restart times can be set, so players can track how long it's beein since the restart
  8. It has a ban function, and an add-approved GM function.
    1. It restricts map-use to approved GMs only.
    2. Approved GMs can make rooms with passwords even when passwords are disallowed.
    3. Approved GMs can enter passworded rooms without entering the password.
    4. Only approved GMs may boot from the server, or use the server password.
    5. Approved GMs have boot protection, and do not need to enter a password to boot from room.
    6. Approved GMs are automatically GMed upon entering a room.

Banned players may watch, but they are prevented from speaking, being automatically booted from the room when they try. This includes pseudocreations like making a room, sending a node, or whispering.

Rules

I would appreciate it, if you make use of this server, to point other people here so that they may find it, and are aware that they are on a community server and thus are having their activities recorded. This is currently done by default inside the new server code, all I ask is that you don't remove it. A link to this website at the bottom of your lobby message would be nice, of course.

Installation Instructions

You will need to have OpenRPG 1.6.3 installed for this to work, since that is the server it utilizes. A clean installation is best.

Download the file below. After downloading the file, you will need to install it. in the orpg/networking subdirectory of your OpenRPG installation. Typically something like C:\Program Files\OpenRPG\orpg\networking in Windows. You will be asked if you want to overwrite - do so. While this will work, it is not yet fully set up. A few steps need to be taken.

  1. To make the logs work, you will need to create some empty directories under your base OpenRPG directory. These are
    1. /chatlogs - This logs everything a user does by name and ip address.
    2. /roomlogs - This logs everything done in a room, by room name and hour.
    3. /treelogs - This logs all node transfers. This was installed to track PHB-spamming, for the most part.
  2. Finally, you will want to edit your /myfiles/server_ini.xml file appropriately.
    1. The Community Server no longer needs nor recognizes the <cheat ... > line. You can delete it.
    2. In its place, you will want to add the ip addresses of your GMs and those you have permanently banned. Here is the text of my server_ini file for the Solar Storms server:
<server>
 <service port='6774' address='hostname/address' />
 <map file='myfiles/Lobby_map.xml' />
 <message file='myfiles/LobbyMessage.html' />
 <validate_protocol value='true' />
 <autokick silent='no' delay='604800' />
 <version min='1.6.3' />
 <reset year='2005' month='1' day='1' hour='0' />
 <maps allow='no' />
 <info1 name='Roster' file='roster' pass='add_roster' />
 <info2 name='GM Info' file='gminfo' pass='add_info' />
 <lobby name='Insanity' />
 <roller name='std' />
 <room_defaults>
   <passwords allow='no'/>
   <map file='myfiles/Lobby_map.xml'/>
   <message file='myfiles/NewMessage.html'/>
 </room_defaults>
 <room name="Character Creation" password="" boot="apple">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/CCRMessage.html' />
 </room>
 <room name="Arena: Honeycomb" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/HAMessage.html' />
 </room>
 <room name="Arena: Zeta Reticuli" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/ZRAMessage.html' />
 </room>
 <room name="Metaplex: Grand Plaza" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/MPMessage.html' />
 </room>
 <room name="Underplex" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/UPMessage.html' />
 </room>
 <room name="Port: SDP-17" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/SDPMessage.html' />
 </room>
 <room name="Infusion Center" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/ICMessage.html' />
 </room>
 <room name="The North Pole" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/NPMessage.html' />
 </room>
 <room name="The Eta Assembly" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/TEAMessage.html' />
 </room>
 <room name="Spring Waterfall" password="" boot="sight">
   <map file='myfiles/Lobby_map.xml' />
   <message file='myfiles/SWMessage.html' />
 </room>
 <gms gm='127.0.0.1' />
 <bans ban='255.255.255.255' />
</server>

You'll notice a few additional tags there.

<maps allow='no'>

Is the default. Change it to 'yes', to allow non-GMs to make use of maps on your server.

In order to make proper use of the get_days function, you need to set the reset tag.

<reset year='2005' month='1' day='1' hour='0' />

Which ought to be fairly explanatory. Hour is in 24-hour format (0-23), and time is UTC (sometimes incorrectly called GMT).

The Lobby name one lets you change the name of the lobby. Mostly for amusement.

<lobby name='Insanity' />

Name of the dieroller you are using for your server-sided roller, from your own standard roller library. std, wod, etc. Note that Version B no longer reads from the networking directory.

<roller name='std' />

The next two set the name and password for your information files. Typically, you will have a player roster and a gm information file, so these are the defaults. -do- change the add_roster and add_info commands, you only want people you trust using them, naturally.

<info1 name='Roster' file='roster' pass='add_roster' />
<info2 name='GM Info' file='gminfo' pass='add_info' />

Bans and GMs define ip addresses which you want permanently banned or gmed. Note that gming overrides banning.

<gms gm='127.0.0.1' />
<bans ban='255.255.255.255' />

Simply add new ip addresses inside the single quotes, for example:

<bans ban='255.255.255.255 123.123.132.132' />

Adds the latter to the permanently banned list.

Download

Download the modified server file from here.

Usage Instructions

Server-Sided Dieroller

The server-sided dieroller is used much like the regular OpenRPG dieroller, with the main limitation being that powers (the ** operator) are disallowed, for obvious reasons. Only the first such roll on a line is parsed, and it only allows two dieroll strings per { } parsing.

So, where in OpenRPG you would normally roll:

[3d12+4]

In the Community Server, you type:

{3d12+4}

You will see your line returned to you. Other players will only see that returned line, not your initial one.

The Roster

add_roster and add_info (or whatever you've changed them to) will add a line of text to one of your information files. Format it however you like. Typically you'll have some sequence for adding players to a roster, and just a general GM notes file.

  • get_roster - when used by approved gms - gets the roster so far added, sending it as a node.
  • get_info - when used by approved gms - gets the information file so far added, sending it as a node.

Approved GM functions

GMs should be given the server (lobby) password. They will want to type

/admin set <password>

And will then be using

/admin list

and

/admin help

to get IPs and the other functions in order to ban players, add temporary gms, broadcast messages, and so on.

add_master (ip address) will add said IP address to the GM list, allowing them to use such functions, for example

add_master 123.123.123.123

adds the person at 123.123.123.123 to the GM list.

ban_player (ip address) works in much the same way.

Other Functions

get_days will allow your players to find out how many days have passed since your reset began, based on the settings defined in your server_ini.xml file. It is rather handy.

Bugs

There is only one significant bug in this program, to my knowledge. Because the 1.6.3 server is multithreaded, when a player disconnects, all of the chat processing going on will cause their DC message to be finally sent -after- they've left the server. I've tried several mechanisms for avoiding this, but they tend to cause worse problems than the solution.


Enjoy!