Difference between revisions of "Community Server"
(7 intermediate revisions by the same user not shown) | |||
Line 1: | Line 1: | ||
− | This is a version of the mplay_server.py file for [[OpenRPG]] that enables communities to monitor their activity, mainly for things such as | + | This is a version of the mplay_server.py file for [[OpenRPG]] that enables communities to monitor their activity, mainly for things such as persistent 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. |
+ | |||
+ | [http://xeriar.com/sites/xeriar.com/files/mplay_server.py Download the modified mplay_server.py file here] | ||
+ | |||
+ | == Updates == | ||
+ | Updates to version F | ||
+ | |||
+ | * I forgetted : / Works specifically with OpenRPG 1.7.5 | ||
== Features == | == Features == | ||
Line 6: | Line 13: | ||
# It has some minor protections against spamming the chat or forcing scrolling. | # It has some minor protections against spamming the chat or forcing scrolling. | ||
# It has further anti-cheat and anti-annoyance functionality. | # It has further anti-cheat and anti-annoyance functionality. | ||
− | # It provides a Roster file that can be used for | + | # It provides a Roster file that can be used to track players |
− | # It provides a means by which restart times can be set | + | # It has a secondary Information file for general GM usage |
− | # It has | + | # It provides a means by which restart times can be set, so players can track how long it's beein since the restart |
+ | # It has an add-approved GM function. | ||
## It restricts map-use to approved GMs only. | ## It restricts map-use to approved GMs only. | ||
## Approved GMs can make rooms with passwords even when passwords are disallowed. | ## Approved GMs can make rooms with passwords even when passwords are disallowed. | ||
Line 19: | Line 27: | ||
== Rules == | == 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. | + | 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 == | == Installation Instructions == | ||
− | '''You will need to have OpenRPG 1. | + | '''You will need to have OpenRPG 1.7.5 installed for this to work, since that is the server it utilizes. A clean installation is best.''' |
− | Download the file | + | Download the file above. 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. |
− | |||
− | |||
− | |||
# To make the logs work, you will need to create some empty directories under your base [[OpenRPG]] directory. These are | # To make the logs work, you will need to create some empty directories under your base [[OpenRPG]] directory. These are | ||
## /chatlogs - This logs everything a user does by name and ip address. | ## /chatlogs - This logs everything a user does by name and ip address. | ||
Line 37: | Line 42: | ||
## 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: | ## 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> | + | <server lobbyname="Lobby" boot="stickonehere" register="yes" name="testing"> |
− | + | <service port="6774" address="hostname/address" /> | |
− | + | <map file="Lobby_map.xml" /> | |
− | + | <message file="LobbyMessage.html" /> | |
− | + | <validate_protocol value="true" /> | |
− | + | <roller name='std' /> | |
− | + | <autokick silent="no" delay="10080" /> | |
− | + | <version min="1.6.3" /> | |
− | + | <reset year='2009' month='5' day='1' hour='0' /> | |
− | + | <maps allow='no' /> | |
− | + | <info1 name='Roster' file='roster' pass='add_roster' /> | |
− | + | <info2 name='GM Info' file='gminfo' pass='add_info' /> | |
− | + | <room_defaults> | |
− | + | <passwords allow="no"/> | |
− | + | <map file=""/> | |
− | + | <message file="LobbyMessage.html"/> | |
− | + | </room_defaults> | |
− | + | <room name="Example Persistant #1" password="password" boot="password"> | |
− | + | <map file="Lobby_map.xml" /> | |
− | + | <message file="LobbyMessage.html" /> | |
− | + | </room> | |
− | + | <room name="Example Persistant #2" password="" boot="password"> | |
− | + | <map file="Lobby_map.xml" /> | |
− | + | <message file="LobbyMessage.html" /> | |
− | + | </room> | |
− | + | <gms gm='127.0.0.1' /> | |
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
− | |||
</server> | </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='2009' month='5' 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. | |
− | + | <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 gmed. | ||
+ | |||
+ | <gms gm='127.0.0.1' /> | ||
+ | |||
+ | Simply add new ip addresses inside the single quotes, for example: | ||
+ | |||
+ | <gms gm='127.0.0.1 123.123.132.132' /> | ||
+ | |||
+ | Adds the latter to the gm list. | ||
== Usage Instructions == | == Usage Instructions == | ||
Line 118: | Line 121: | ||
=== The Roster === | === 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 | + | * 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 === | === Approved GM functions === | ||
Line 135: | Line 139: | ||
/admin help | /admin help | ||
− | to get IPs and the other functions in order to ban players, add temporary gms, and so on. | + | 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 (ip address) will add said IP address to the GM list, allowing them to use such functions, for example | ||
Line 146: | Line 150: | ||
=== Other Functions === | === Other Functions === | ||
− | get_days will allow your players to find out how many days have passed since your reset began. | + | 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! | + | === Enjoy! === |
Latest revision as of 02:24, 6 April 2009
This is a version of the mplay_server.py file for OpenRPG that enables communities to monitor their activity, mainly for things such as persistent 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.
Download the modified mplay_server.py file here
Updates
Updates to version F
- I forgetted : / Works specifically with OpenRPG 1.7.5
Features
- It logs chat and tree activity, including whispers.
- It has a server-sided dieroller, which has some protections against rollspamming.
- It has some minor protections against spamming the chat or forcing scrolling.
- It has further anti-cheat and anti-annoyance functionality.
- It provides a Roster file that can be used to track players
- It has a secondary Information file for general GM usage
- It provides a means by which restart times can be set, so players can track how long it's beein since the restart
- It has an add-approved GM function.
- It restricts map-use to approved GMs only.
- Approved GMs can make rooms with passwords even when passwords are disallowed.
- Approved GMs can enter passworded rooms without entering the password.
- Only approved GMs may boot from the server, or use the server password.
- Approved GMs have boot protection, and do not need to enter a password to boot from room.
- 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.7.5 installed for this to work, since that is the server it utilizes. A clean installation is best.
Download the file above. 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.
- To make the logs work, you will need to create some empty directories under your base OpenRPG directory. These are
- /chatlogs - This logs everything a user does by name and ip address.
- /roomlogs - This logs everything done in a room, by room name and hour.
- /treelogs - This logs all node transfers. This was installed to track PHB-spamming, for the most part.
- Finally, you will want to edit your /myfiles/server_ini.xml file appropriately.
- The Community Server no longer needs nor recognizes the <cheat ... > line. You can delete it.
- 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 lobbyname="Lobby" boot="stickonehere" register="yes" name="testing"> <service port="6774" address="hostname/address" /> <map file="Lobby_map.xml" /> <message file="LobbyMessage.html" /> <validate_protocol value="true" /> <roller name='std' /> <autokick silent="no" delay="10080" /> <version min="1.6.3" /> <reset year='2009' month='5' day='1' hour='0' /> <maps allow='no' /> <info1 name='Roster' file='roster' pass='add_roster' /> <info2 name='GM Info' file='gminfo' pass='add_info' /> <room_defaults> <passwords allow="no"/> <map file=""/> <message file="LobbyMessage.html"/> </room_defaults> <room name="Example Persistant #1" password="password" boot="password"> <map file="Lobby_map.xml" /> <message file="LobbyMessage.html" /> </room> <room name="Example Persistant #2" password="" boot="password"> <map file="Lobby_map.xml" /> <message file="LobbyMessage.html" /> </room> <gms gm='127.0.0.1' /> </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='2009' month='5' 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.
<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 gmed.
<gms gm='127.0.0.1' />
Simply add new ip addresses inside the single quotes, for example:
<gms gm='127.0.0.1 123.123.132.132' />
Adds the latter to the gm list.
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.