CoPaP Forum Index CoPaP
 A community of linked Neverwinter Nights worlds. 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups 
 RegisterRegister   Log inLog in 
The time now is Sat Apr 20, 2019 12:02 am
All times are UTC - 5
View posts since last visit
View unanswered posts
 General
 Home
 About CoPaP
 Articles of CoPaP
 Forum
 Downloads
 NWNX/APS
 Links
 Contact

 Linked Worlds
 Arkaz
 Avlis
 Hala
 Tairis'nŗdur

 Linking in Progress

 Worlds in Progress

Poll
Add More Templates or Restore the Old Solaris One?

Add more themes and update Solaris to work with the site. [6]
Update Solaris, we don't need a bunch of themes no one will use. [13]
Add more themes... Screw Solaris for now. [0]

You must login to vote


Welcome to CoPaP: How to join...

General: Articles of the Confederation Online
Posted: Themicles @ Wed Dec 31, 1969 7:33 pm
CONFEDERATION OF PLANETS AND PLANES

TABLE OF CONTENTS (Click on link to go directly to section)


ARTICLE 1: TYPES OF SERVERS

The Confederation will consist of two types of servers: Avlis Compliant Servers that run the Avlis Core Code (ACS's), and Non-Avlis Compliant Servers (NACS's).

Section 1: Avlis Compliant Servers that Run Avlis Core Code:
Servers that are Avlis compliant will use all of the basic core code of the Avlis project in their module. This option is highly recommended for PW builders who wish to create a world without making every integrated system from scratch. Most of the work is already done. Creating an Avlis-compliant server will go a long way towards making it easy to balance your world with other worlds in the Confederation. It will also entitle you to updates of the Avlis core code as the team makes them available.

All members of the Confederation will receive the following core systems:
Crafting System: Avlis has its own unique crafting system based off of NWNX. Instead of having skills based on percentages, they are based on levels. You can earn levels in a skill much the same way you earn levels in a character class. The amount of experience required to level in crafting classes is the same as level advancement for your regular classes. The system is based off the principle that you need to gather resources (e.g., iron, wood, plants, and other placeables) as ingredients for items. To make an item, you take the ingredients and place them into the crafting placeable (e.g., anvil or sawhorse). A menu will then ask you what item you want to craft. When you open the placeable again, it checks your skill and if you're successful the ingredients will disappear and you'll find the item you crafted. These "recipes" are very easy to add. Adding a new recipe or even a new skill is as easy as inputting it into your SQL database.
Dying System: When a character gets damaged in one hit to any number below -1, their hitpoints automatically set to - 1 and they become unconscious. Example: Bob the fighter has 2 hitpoints. He's fighting a dragon. The dragon smacks him for 80 hitpoints. Bob now has -1 hitpoint and is bleeding to death at 1 point a round, with a small chance to stop bleeding and a smaller chance to recover a hitpoint.

For about 10 seconds after being hit, the plot flag is set on Bob to prevent an instant death, but after that he is vulnerable once again to being hit while he's down. The point of this is to make it easier to fight in groups. It's very hard to be insta-killed this way, and that makes the fights last a lot longer and be more fun. People still die, however.

Death System: When the player goes below -10 hitpoints, their items are stripped and put into a death corpse. A record of the items is stored in the database under their name via NWNX. The player is then whisked away to the outer plane that most closely matches their alignment. They lose 50 experience per level (configurable in the database). When they get to their death plane, they need to either be resurrected by a player or complete a short quest on the death plane so they can return to the land of the living. If they decide to complete the death quest they get their lost experience back. If they get rezzed they appear next to their body. If they complete the quest they respawn at a temple or shrine and need to walk the "naked mile" back to their corpse. Clicking on their own corpse once automatically brings all the items in the corpse into their inventory. This system may be used with modifications to make it more in line with the story/world of your server, however the same severity or lack of severity and risk vs. reward must be present.
Drugs and Addiction: There are roughly 7 different drugs in the core system. Taking a drug gives you the benefit of raising a stat by a lot of points temporarily. However, the drugs are addicting. If you take them in excess, you will suffer through three phases of addiction culminating in stat losses. Eventually you will need to take the drug just to feel normal. Time can heal the addiction. DM's can also create quests to rid a character of addiction.

Disease system: Whenever you enter an area it checks for any diseases you may have. If you have one, it checks to see if you suffer the effects. Diseases are persistent like anything else and need to be cured.
Treasure drop system: Random loot is not random. There is a table in the database that has the name, resref, item type, gold value and other info on any piece of treasure that can drop in the game. If the item is not listed in that table, it will NEVER drop in any chest, or monster in the entire game. By adjusting the gold piece value of the item artificially, you can control how often it drops. This system works VERY well for controlling loot that spawns in game and ensuring that we remain a low magic world. The system also drops random gold.

Persistent chests: We have our own persistent chest system. I dare say this is the original NWNX persistent chest system.
Player tracking system: A comprehensive system for tracking players' advancement on the server as they login. The system also determines if the character they are logging in with is theirs. If it finds that the player has logged in with someone else's character due to a bug, it paralyzes them and sends you a message.

Persistent locations: When you rest, the system saves your location on the server so that if there is a crash you will reappear in that spot upon login.
Persistent server locations: For worlds like us who have multiple servers on a LAN, we instituted a system that will not let players log into one server and then immediately log into another server... also known as server hopping. This is because our servers represent geographical areas and logging in from one to another can mean an instantaneous journey of hundreds of miles, which is not realistic. Once you log onto one server, you must log out and wait one hour to log into another, or petition a DM. We chose one hour, as this is the amount of real time to walk from one side of Avlis to the other.

Persistent merchants: This system is largely under development still, but it runs well for what we have so far. Merchants work off of persistent chests. They remember their inventory from boot to boot and they actually have an economic strategy for making money. This enables us to make trade routes on our servers because one merchant will buy certain goods at a higher price than another merchant. This is dependent on individual items, not a blanket rate of markup or markdown like the normal Bioware merchants.
Guild system: Guild leader get an item that allows them to induct/kick people from the guild, as well as bestow guild tokens and officer items. All guild ranks are persistent.

Experience system: Set the slider on your mod to 0% and let the system take over. It is a basic system that accounts for character levels in the party more evenly and fixes exploits caused by summoned creatures and mixed party levels. The system is created to closely award experience according to the rules for Challenge Rating experience rates in the 3rd Edition Dungeon Master's Guide.
All of these systems may be modified by the ACS if they wish. So long as credit is given to the original authors of the scripts, they may make any modifications they desire to enhance the quality of their own personal world.

All ACS's must use NWN Extender 2 (NWNX2) with MySQL database as their backend. Other forms of persistence, such as the 1.30 database support, are permitted only if they are used in conjunction with NWNX2 and MySQL.

Section 2: Non-Avlis Compliant Servers
NACS's are worlds that choose to stay with their own already-existing systems or to build new systems completely on their own. Even though they are an NACS, their server implementation itself (such as custom death and treasure systems) must comply with the rules and intent of the Articles of Confederation (see Article 3 Sections 1-3 regarding balance, Article 4 Section 1 regarding server specific modifications, Article 5 Sections 1-2 regarding server attributes and connections). NACS's are admitted only after they prove that their guidelines are exactly as strict and balanced as the ACS's. We do not recommend running a NACS, for it is much much harder to be admitted to CoPaP with one of these.

NACS's will almost always have variant experience systems, as well as persistence. Though they are not required to keep their data using NWNX2 and MySQL, NACS's will still need to run the NWNX plugin called VaultSTER, which gives the servers the ability to transfer characters between them. If the world uses some other type of persistence, such as the Bioware database support, NWN-FF (until Vaultster compatibility is added), or Quietus NWNX (QNX), they may set up a small one area mod which runs NWNX VaultSTER to act as a portal module to its connecting worlds.

PW's that are not Avlis-compliant will need to be handled more carefully than those that are.


ARTICLE 2: SERVER ADMINISTRATION

Section 1: Who runs your world?

You do. Each world will be run by its own team of people picked according to the wishes of the PW creator or team organizer. Unless stated by the team organizer, people from other teams will have no say on what goes on in the internal affairs of their world. Team organizers are expected to manage their own world and the team that runs it in any way they see fit.

Section 2: DM's

Dungeon masters are restricted to the world they were hired for. A DM on one world will not receive DM access or privileges on any other world unless expressly allowed by the team leader of that PW. Crossover events can and should occur between servers, but they should be arranged internally between the DM's from the two (or more) teams involved

Hiring of DM's is an internal team matter, and will not be dictated by the confederation. It is solely up to the individual team leaders.

If a DM is allowed to cross over into another world, they are responsible for adhering to all DM standards set forth by that world's creator.

Section 3: Ambassadors

Each team will pick as many as three Ambassadors to act as liaisons between their world and the confederation. It is recommended that the team leader be one of these Ambassadors.

The purpose of the Ambassadors is to organize communication between the worlds in the confederation. They are responsible for maintaining the standards between the worlds and for ensuring that their world is in compliance with the confederations minimum requirements.

Ambassadors may be given access to special website areas for PW development forums, as well as DM access to that PW if the team leader allows it. If they obtain DM access, they are to adhere to all DM rules for that server. They are also not encouraged to interact with the players, as their main role should be to look around and tour the world.

Section 4: Players

A player who joins a world in the confederation automatically joins all of the worlds involved in the linkup. The confederation is responsible for making sure that the player has a list of all passwords needed to enter any of the available servers.

Section 5: Player Discipline and Banning

"Banning a player" is defined by entering that player's CD key, username, and IP address into the nwplayer.ini file. Player discipline is entirely up to the team managing the world where the player commits an offense. This is considered an internal team matter, and each team is free to deal with the player's destiny on THEIR server however they see fit.

Disciplinary decisions by the team do not carry over to other servers. Thus, if it is decided to ban a player, that ban only extends to the server where the player was banned, and not any of the other servers in the confederation. The player is still free to play on the other servers, until they are banned on those too, if that should occur. Banning a player entirely from the confederation would require that each individual server ban them manually.

Characters, whether banned or not, may not send copies of their bic files to other servers for inclusion into that world's vault, unless they have already tried to get there directly through a portal and failed. This is designed for sake of realism and to protect you from a thousand player requests of "Will somebody please copy my character into your world?"Ö

Example:
Bob the fighter is banned on Avlis. If Bob the fighter never visited the Toril5 server, he may not send them a copy of his bic file for inclusion into their vault. He may start a new character on Toril5, but the only way to get his old character there is to walk it there from another server where he has access.


ARTICLE 3: BALANCE

To maintain cohesiveness, we need to balance various implementations on each server. The following sections are requirements for balance on all member PW's.

Section 1: Experience

Bioware experience sliders should be set between 0% and to no more than 3%. Setting it lower than 2% is not recommended. This setting also assumes that the challenge rating (CR) for monsters is left at the normal calculated value in the toolset.

Member worlds may use any custom experience system that has been sufficiently playtested. However, the result of that system may not enable player characters to achieve 20th level in less than 6 months while playing 3 hours per day. For new PW's this is hard to ascertain.

Section 2: Item Balance

The rules for item balance are as follows:

No items greater than +1 enchantment are to be sold on merchants as part of their default inventory. +2 items should be obtainable in random loot by characters of 15th level and higher. On average, a 10th or 12th level character should have one or two of these items in their possession. Some will have more. Some less. +3 items should be obtainable in random loot only by 20th level characters, and even then only occasionally. For items that give skill points instead of enhancement bonuses, triple the numbers above. So for example, items of greater than +3 skill bonus should not be sold in merchants, etc. The ONLY way to obtain armor and weapons of +4 enchantment or greater is to get them on a DM-run quest. Amulets and rings of +4 or +5 enchantment can be given out as random loot in VERY rare circumstances to 20th level characters. DM's may give out items in quests that are better than the ones that are found in random loot.

CLICK HERE FOR REWARD TABLE


Standard Reward: +1 to +2 item: These are the meat and potatoes of rewards. You may readily leave them in the path of any group you see adventuring well together and roleplaying. It is also common to give them for DM quests. They go out at roughly +1 for level 6 or lower, +2 for level 7 or higher. At level 14 this will scale up to a +3. In addition, players may receive a +1 or +2 item with some other minor enhancement, such as 1-2 elemental dmg.

Prestige Reward:

Named item: These bring prestige to anyone the player shows the description to. The item will thus bring prestige for the player among their circle of friends. You may readily give these depending on power level of the item for good role-playing. Further the item does not have to be unbalancing. It will serve its purpose at low power.

Player Named Item: There is a much higher level of prestige associated with these items. These items should go to role-players that deserve to be noticed. Once again they are not about power, but about prestige, and then can go to anyone deserving. To become deserving though, it takes several months of stellar RP.

Highly Enchanted Items Items: +4 or equivalent. These items bring great power to players and should be given out rarely and only to high levels. They should involve a great amount of DM interaction, or a great amount of legwork on the players part. Remember, they will make players much harder to kill/control as a DM, and make those players much more powerful than their peers.

Glowing Weapon: This is observable by everyone. A +1 1/d6 fire sword is seen with more prestige than a +3 blade. Low enchanted elemental weapons make good mid-high level rewards, as they bring prestige but not necessarily great power. We give out about 1 glowing item a month. They only go to players above level 14 or so, although there can be exceptions for exceptional RP. Uber & Haste Item: Should be given out almost never, and only to a very deserving and trusted player. Perhaps a few times a year. Players WANT haste items. The double movement sets them apart, and they get very nice bonuses. +4 to ac, extra attack/spell per round, and enough speed to outrun all enemies. This is huge, and is our ultimate reward. Avlis has been running for about a year, and there are only 10 of these in existence on the whole server of 1000 players. Items like these should be EXTREMELY RARE.

Cast / day items: These items show up to observant players when the owner uses them. There is a nice little combat text of so and so uses such and such an item. Questions will invariably be asked, in character and out of character. Scale these rewards according to power level.

Banned Items: These rules are REQUIRED so as to ensure balance among the confederation. These items should never be given out more than once or twice, ever. Players who already have these items in their possesion from a time period before linking to CoPaP may keep them. However, the following items are banned from dropping:
Hide in Plain Sight (HiPS)
Immune knockdown
Immune mind affecting
Immune spell school
Immune specific spell
Perma Haste
Immune spell by level
Immune Critical Hit
Immune Sneak Attack
Immune Death Magic
Some of the On Hit effects (dispels, vorpal and the slays in particular)
Cast Spell of a spell level higher than 4
Damage Resistance of greater than 15
Improved Evasion
True Seeing
Items with FR description (unless you run a FR world)


Items that have already been given out to your players before adoption of these standards do not have to be removed from them unless the team leader of your world requires it.

Section 3: Death Systems

It is recommended that ACS's use the same death system as Avlis. However small variations are allowed. Death systems need to be balanced both with the risk vs. reward of your home server AND the risk vs. reward of all the other servers. If your death system is too harsh, players will flock away from your server. All death systems in the confederation must meet the following minimum requirements:

No permanent death
Bleeding to -10
No permanent level loss on death, UNLESS the level loss is due to experience losses
No permanent stat loss on death
Players must have the ability to respawn on their own without help from another player if they choose to do so

The Avlis death system makes use of a death corpse. When a player dies, their items are left in the corpse, and their "soul" respawns on one of the outer planes that best suits their alignment. They can be resurrected if another player casts the raise dead or resurrection spell on their corpse, but they can also do a short quest on their death plane to return to the land of the living. Upon dying after reaching 3rd level, the player loses 50 exp per level, and it is possible to lose a level because of this. No gold loss occurs upon dying on Avlis. If the player completes the death quest in their death plane, they get the experience returned to them, and they respawn at the local temple or shrine. They must then make their way overland back to their corpse and loot back their items before someone else does. (More on this later.)

We highly recommend that whatever death system you use adheres to the basic 3rd edition cosmology set forth in Manual of The Planes. Experience and gold losses are tolerated as penalties for death, although we do not recommend inflicting more than a 15% penalty in experience and a 40% penalty in gold. If your penalty is too stiff, players will flock to servers with less harsh penalties.

Also remember that the rate of experience gain on these worlds is EXTREMELY low. It takes months to reach level 20 without any experience penalties on death. Thus, it is not always necessary to deduct large amounts of experience as part of your death system.

Section 4: Player Rules and Conduct

Having a similar system of player rules is necessary to maintain a high caliber of good roleplayers on the worlds making up the Confederation. Every server is required to have the following rules of conduct in one form or another:

1) Grief-style playing, or griefing, is illegal. Griefing is defined by any style of play that makes the person playing a character feel genuine distress and anger through disruption of their gaming session.

2) People should be in character at all times. Shouting is disabled. Using tells, IRC, and teamspeak to convey in-character information is illegal, however it is ok to use these media to talk about out of game things.

3) Player vs. Player combat is illegal. However, Character vs. Character combat is legal. A "player" is defined by the person sitting behind the screen playing the game. A "character" is defined by the alternate personality you portray within the game. Characters can have disagreements and fight over them, but as soon as it becomes a personal matter between the players behind the characters, it is no longer justified.

4) Exploitation of bugs to gain experience, wealth, or to save time is illegal and a bannable offense. This includes duplicating items and inappropriate server hopping.

5) Common sense is a rule. If an action goes against common sense, it's not legal.

Section 5: Clarifications and Examples

The rules stated in sections 1 through 4 are REQUIRED. However, we encourage servers in the Confederation to add "house rules" as desired. In addition to required rules, we have a number of recommended to enhance roleplaying:

Looting: Servers may handle looting however they like. ACS's have built in looting control that logs every instance of looting on the server so it can be tracked. On Avlis, looting is completely legal, but there are certain "gentleman's" rules that apply and which were made up entirely by our playerbase. If your community is capable of doing this, we encourage you to make looting legal and let your players enforce the severity of it. When you make a world that requires applications and passwords it is more likely that you will attract the type of players that can make these rules.

PvP: Players fighting each other to test items or to min/max and powergame should not be tolerated on any server. However, in-character vendettas and conflicts should be perfectly legal, so long as they do not become real life personal disputes. Anything that goes wrong on your server along these lines will be considered an internal matter handled by your staff. We very highly recommend that your pvp settings be turned to Full on your module.

No "Cheesing": "Cheesing" an ability is the act of playing your character as if they have an ability which the NWN engine would not otherwise allow them to have. While your world may respect these "abilities" no other world is required to enforce them, and new players to your world may have difficulties understanding abilities that they cannot see.

Example 1: You should not be a giant-kin by picking half-orc and writing "Veerbeeg" in the subrace field.

Example 2: You should not say your character is a vampire with exceptional strength and the ability to make other characters into a vampire by biting them. ONLY abilities that are granted by your class, race, and level within NWN are in-game. Extra powers that you make up or pretend to have are unacceptable in Avlis.

Example 3:
Player1: *pretends to whack Player2 over the head*
Player2: What was that for?
Player1: You're unconscious now. I whacked you over the head.
Player2: No I'm not. You didn't do any damage to me at all.
Player1: But I have a 42 strength. I'm a giant.
Player2: No you aren't. You look like a halfling, and your character sheet says you have a 7 strength.
Player1: I know. I know. That's what my character sheet says. But I'm REALLY a giant and I have a 42 strength, so you better roleplay being knocked out, buster.
Player2: That is the stupidest f****g thing I have ever heard.


Floaty Names: Names over character's heads are OOC, and using OOC information IC is not allowed. The floating name can be used if your character already knows the other character (as long as the other character told you their real name). However, a person you know under the effects of "Invisibility" or "Improved invisibility" cannot be identified by the floating name unless your character is under the effects of "see invisibility" or "true seeing".


ARTICLE 4: HAKPAKS AND GAME MODIFICATIONS

There are three kinds of modifications to the server: 1) Modifications that EVERY server will need; 2) Modifications that only one server or world will need; and 3) Optional modifications.

Section 1: Common Game Modifications

Confederation Servers are SoU/HoTU compliant, and must have a minimum of two small hakpaks plus the Community Expansion Pack: 1) UniversalHak.hak; and 2) CoPaPHak.hak (name can be changed as desired). Both of these haks are available at HYPERLINK "http://www.avlis.org/portal.php?getpage=downloads"http://www.avlis.org/portal.php?getpage=downloads.

The UniversalHak contains models that are needed on all servers. These models include extra weapon and shield models, and dynamic racial models. Only model and tga files are contained here. 2Da files are in the other hak.

The CoPaPHak contains only 2da's. These files must always be in the top hak connected to the module, or they will be ignored. If a 2da exists in a hak that is not at the top, it will not have its intended effect on your module. Thus, ANY 2da modification that you make to your server must be in this hakpak. Each server is welcome to change this 2da hak and re-issue it to its players under a new name. This will be necessary if your server has changed any 2da files in the past. Currently, the biggest portion of this hak is the 2da files for custom races.

Every so often, the common game haks are re-evaluated and expanded. Once you join the confederation, you will have the opportunity to get your special items or head models added to the hakpak.

The current CODI supported custom races are detailed in the following table:

The confederation uses Red Golemís AutoBic as its custom race and Enforce Legal Character (ELC) software.

CoPaPTlk is the common custom tlk table for all CoPaP worlds. Its entries are all listed after line number 100,000, making it easy to combine with the current talk entries of incoming member worlds as well as other community expansions. This tlk is periodically updated with additions from the various member worlds over time.

The current AutoBic supported custom races are detailed in the following table:
CLICK HERE FOR RACE CHART


Races designated with a "*" are Avlis-specific. Your world will need to add these races so that players who play these custom races in other parts of the Confederation can travel to your server. We plan to add more custom races in the future, so compile your suggestions and we may integrate them into the updated hakpaks.

Section 2: Server-Specific Modifications

If your server uses a tileset hak or other hak that only affects your server, it need not be downloaded by everyone in the Confederation. For example, the Avlis Wilderness server uses the Drylands hakpak. No other server in the Confederation is required to use this hakpak. Thus, only players who wish to travel to the Avlis Wilderness server need to get download this hak. Similarly, you may want to have a separate tileset and creature model hakpak that players on your world must download. This is acceptable and there are no current limitations on hakpaks you can use for your own server. However, keep in mind that if your hak is too large, it may drive players away.

Section 3: Optional Modifications

There are no optional modifications at this time. These changes can be made at the team leader's discretion for each world independently.


ARTICLE 5: SERVER QUALITY

Section 1: Server Attributes

All servers MUST have the following settings and attributes:
*Adequate and approved methods for enforcing legal characters must be present.
*Adequate and approved item level enforcement must be present.
*Servervault characters only.
*PvP setting is full.

Game type is PW: Story
Gamespy display name has prefix "CoPaP -"

Section 2: Server Connection

Servers in the Confederation must have reliable internet connections of DSL quality or better. It is preferable that the upload speed of the connection exceed 500 kbps. Servers on dialup connections are not permitted. In order to maintain good quality in our products, servers must strive for an uptime of 24/7. Weekend servers and other temporary servers are not permitted.

Section 3: Server Applications

All servers in the Confederation of Planes & Planets must require players to fill out an application in order to join. The applications are necessary as a method of weeding out some players who will cause trouble. The philosophy of CoPaP is that all players who are old enough (we recommend age 16) may play on the server, regardless of previous roleplaying or gaming experience. However, once they are accepted for membership, they are required to follow the rules or be kicked out. The application acts as an intermediary process to stop people from popping in for a day to the server to grief others and leave. Applications may be turned down only for the following reasons:

Player is underage. (Age is set by the team leader.)
Player did not fill out the required fields of the application: Full Name, name of Internet Service Provider (ISP), and age.
Any special considerations for your particular server.


Section 3a: Player Acceptance Process

Accepting a player into your CoPaP server should follow the process given below. When a player applies to one CoPaP server and gets accepted, they are automatically accepted to play on all other CoPaP servers. Players may also fill out a standard CoPaP application that will be honored by all worlds in CoPaP.:

Player fills out application and submits it to a world.
That world reviews the application and checks that it follows the conditions in Section 3.
If the application is to be accepted, the world sends them an acceptance letter and adds that person to the CoPaP mailing list.


The acceptance letter sent to the player will contain the passwords for ALL CoPaP servers, not just the server they applied to, for the reasons given above.


ARTICLE 6: WHEN THINGS GO WRONG

This Article is designed to cover the common disputes that may arise between players and worlds in the Confederation. When dealing with CoPaP, there are two kinds of issues, internal matters and external matters. An internal matter is any issue that affects only one server, but not the rest of CoPaP. An example would be a report of player griefing. The team who runs that world would deal with the player in whatever way they see fit, without input from the rest of the worlds in CoPaP. Internal matters are also any matter that involves the day to day runnings of a server. They are always dealt with using whatever mechanisms the world has in place on their team. An external matter is any issue that can affect all of CoPaP, or the majority of its servers. External matters are dealt with via the team's Ambassadors to CoPaP. They include anything that has to do with experience, item balance, allowed races, etc. Both of these kinds of matters are discussed in more detail below:

Section 1: Player Disputes

Player disputes are internal world matters and should not be taken out of the server where they occur. A team leader has the right to deal with any player on their server however they see fit, no matter where that player originated. However, the team leader may not forcibly control that player's destiny on any other server besides his or her own. This concept is further discussed in HYPERLINK ""Art2, Sec5: Player Discipline and Banning.

Section 2: Intra-Team disputes

Intra-Team disputes (i.e., internal disputes between members of your team) are an internal matter. They are settled however your team leader sees fit.

Section 3: Inter-Team disputes

Inter-Team disputes arise between one or more worlds in the Confederation. Disputes between teams must be kept between the parties involved. They must not branch out to other members of the Confederation. If a dispute grows out of control, the parties may agree to mediation. All teams involved must agree on the mediator, and the mediator need not be someone who is part of the Confederation. We encourage all disputes to be settled in a civilized and logical matter.

Section 4: Rules Disputes and Changes

These Rules are not subject to debate or modification once a world has joined the Confederation. You may informally request a change or modification to these rules by writing directly to Orleron. You may also petition to have a rule changed by a vote of the Ambassadors. To do so, you must assemble a meeting of Ambassadors, or obtain written proxies from absent Ambassadors. Each world gets one vote independent of their size and stature. A change or modification to these Articles of Confederation requires a 3/4ths majority vote of Ambassadors. Once per month, Orleron may enact a veto to a passing rule. Vetoes by Orleron are cumulative if they are not used in a given month. A vetoed matter may be brought for another vote two-weeks after the veto is received from Orleron.

Section 5: Voting mechanism

Whenever there is an external matter other than changing these Articles that needs a vote to be resolved, the following procedure is used:

The party interested in proposing the vote must write up a clear and concise summary of what they want the vote to cover, and why it is being proposed. The summary must be posted in a place where all CoPaP Ambassadors have access, as well as emailed to all Ambassadors and Team Leaders in CoPaP. The post must be of the following form:
Proposal:
Version #:
Before voting, the proposal may be discussed by all ambassadors, though each post in the discussion must take the following form:
Agree, Disagree or Indifferent:
Reason:
Counter-proposal:
New version #:
Once a finalized version has been reached, and all parties who wish to have had their say, each CoPaP world may cast ONE vote, regardless of their size or prominence. This vote must be casted or endorsed by the leader of that world either directly or by proxy. A proxy must be in the form of a written letter to the voter giving permission. Votes are casted by adding ONE post to the thread where the proposal is displayed. It must say either Aye, Nay, or Abstain. For a vote to be valid, at least 3/4th of all CoPaP worlds must have voted either Aye, Nay, or Abstain. If this condition is not met, the vote is postponed until the quorum is met. For a vote to pass, there must be more Aye's than Nay's. If a vote passes, it is enacted. If it fails, it is discarded.

Section 6: Designated External Matters

The following situations are designated as external matters for the purpose of settling disputes. The list does not cover ALL possible external matters, however.

Item/Gold wipes on a server - Any time a team decides to wipe out items or gold from a player OnEnter, it is an external matter and the other servers must be consulted.

Player wipes on a server - These are forbidden unless there is a unanimous consensus by all CoPaP members to do so. A server may wipe their vault before linking to CoPaP, but not after.

Modifying player inventories upon entering a server - Any unilateral changes to a player's inventory upon entering a CoPaP server must be discussed as an external matter. Member worlds may not enact any code that takes away a single item or changes an item before the player has any choice in the matter, unless it is cleared by a vote in CoPaP under Article 6 Section 5. The giving or taking of player helper wands is excluded from this situation.

Modifying player experience or level upon entering a server - As with inventories, a player's level or amount of experience may not be tampered with upon entering a server unless it is cleared by a vote in CoPaP under Article 6 Section 5.


ARTICLE 7: COPAP AMBASSADORS

This article gives a description of Ambassadors and their function and privlidges.

Section 1: Ambassador Purpose

Each server may appoint three ambassadors to act in this organization. The team leader may be one of them. This is recommended. Ambassadors in CoPaP shall have the following major functions: Acting as liason between CoPaP teams
Overseeing DM interaction between servers and crossover events
Checking that their server is compliant with CoPaP standards


Part 1: Acting as a liason - Ambassadors should be in constant communication with the other ambassadors from member worlds, as well as other team leaders. They are responsible for making sure that all necessary information is shuttled back and forth between the teams so that CoPaP runs smoothly.

Part 2: Overseeing DM and event crossovers - Ambassadors are responsible for keeping track of all plots that are taking place between their particular server and other servers they are connected with. They do not need to run the events themselves. They just need to make sure that DM's from both servers involved are in contact with them about it. When overseeing this contact, their main objective is to make sure that the continuity of all worlds involved in the crossover is preserved. They must ensure that the tone and feel of each world involved in the crossover is preserved throughout the event, and that the world's foundation is not compromised unless it is allowed by the world's creator.

Part 3: Checking compliance - Ambassadors are responsible for checking that ALL servers involved in CoPaP are compliant with its standards. They are not only responsible for their own server of origin. They are responsible for making sure that every connected server is following the standards described in this document. If they find a non-compliance, they are to refer to Article 6.

Section 2: Ambassador Privlidges

Ambassadors must have enough access to do their jobs effectively. Specifically, they must be allowed to log in to all CoPaP servers. Whether or not this access is DM-level is up to the team leader of that world. Leaders are not required to give ambassadors DM access, but it is recommended. If an ambassador is granted DM access, they must follow the given conditions, unless amended by the team leader of the world they are logging into:

The ambassador may not run any plotlines on the server or interact with players in any way, such as giving experience or spawning objects. The ambassador may not divulge the DM password to any other person, unless specified by the team leader. This includes members of their own team. The ambassador may do what he/she needs to in order to test systems such as death, gold drops, etc. so long as it does not violate conditions 1 and 2.

Ambassadors must also have enough boards access to do their jobs effectively. Though they are not required to be given access to the internal private team boards of the servers they are working on, it is recommended. If they are not given this access, they should be given a small forum someplace where they can interact with the team of the server.


ARTICLE 8: ADMITTANCE AND EXPUNGMENT OF MEMBER WORLDS

This article covers how worlds will be admitted or excluded from CoPaP.

Section 1: Admittance to CoPaP

Four current members of CoPaP will make up a small council that oversees the admittance of worlds. In order of seniority, they are Orleron, Themicles, Drakuul, and Sarrena. At any point in the admittance procedure, one of these individuals can veto the process. If the veto is enacted, the process stops. Only a council member of higher status can undo the veto and start the proceedings rolling again.

Example:
If Bobís i337 Dood server wants to join CoPaP, they would start the proceedings below. If Sarenna does not think this server should be allowed to join, she may veto the proceedings. If Drakuul thinks that they SHOULD be allowed to join, he may undo the veto. If Themiclesí common sense prevails, he may then re-instate the veto. Orleron can then either allow the veto to stand, or undo it again.

Any CoPaP member may start the proceedings for a world to join according to the following procedure:

1) Prospective member must read the Articles of Confederation. If they are not in agreement with them, stop here. If they find that you like what they propose, go on.
2) Send a message to the person who recruited them. Include the following information:
* Notify that the Articles of Confederation have been read.
* Send name and world's name (does not have to be a final name for the world)
* Give a summary of how far along the world's development is and, how many players if any
* Brief background and history of the setting
* Whether world will be an Avlis compliant server or a non-Avlis compliant server... if making a NACS, how will the server differ

5) The contact person who received this information from the prospective member must then post the information up in the main CoPaP forum for all members to review. This information must be posted in the format of a normal proposal as dictated in Article 6 Section 5.

6) The proposal is debated and voted on in the usual way described in Article 6 Section 5.

The results of the vote are submitted to the council of four. If none of the members of the council have an issue with the result, it is allowed to stand and the server is admitted to CoPaP as a probationary "World in Progress".

8) The world leader and new ambassadors from the World in Progress will be given access to the CoPaP forums, and the Avlis Zero module. They will also be added to a mailing list where you can talk with other CoPaP leaders.

9) The new team is to start/continue building their server, using the CoPaP forums for support, giving periodic estimates of when they think they'll be online.

10) When the new server's development reaches a point where the leader thinks they are able to link to CoPaP, the world will be checked for compliance. This is done by announcing the readiness in the CoPaP forum, and having all Ambassadors visit the world at various unannounced times to search for compliance issues.

11) Once initial compliance issues are worked out, the server may begin to work on its plotline to link to CoPaP, with the help of any DM's and ambassadors willing to help.

12) If desired, the new server will be allowed to run for 2 or 3 weeks unlinked so it can build up its own playerbase and work out bugs and balance. More time will be given if needed.

10) At the end of the testing and player recruitement period, the server will be given the VaultSTER software (if it has not been distributed to the public yet). A test link will be set up between the new world and the world they are linked with directly. Once this step is achieved, the World in Progress becomes a full member with voting rights in CoPaP.

Section 1a: Admittance of Well-established, Pre-existing servers to CoPaP>

For servers with a well-established player base and economy that wish to join CoPaP, special consideration will be taken to make their transition smooth. The same procedure for recruitment is followed as laid out in Article 8 Section 1, parts 1 thru 9. However, step 10 will be handled on a case by case basis, and clarified here in reference to pre-established servers.

Clarification of Step 10: For an established server's development to reach compliance with CoPaP, a period of adjustment will be necessary to bring the playerbase in line with CoPaP's standards. Before the server is checked for compliance, the staff of the established server will work out some method for adjusting their item, magic, and player level balance on the server.

Having the established server perform a vault wipe is an acceptable method to clearing the imbalances with CoPaP prior to joining, but it is not mandatory. If the team of the newly joined established server wishes to avoid this, the existing CoPaP members will make efforts to help them think of ways to raise or lower their balance to the proper levels.

Some suggested methods for bringing magic item levels into balance:

1) Custom item trades - Players are allowed to trade in large amounts of powerful magic items in return for a single mildly powerful magic item with a custom made appearance and description. An example of such a trade would be to allow a player to give up five items of +2 enchantment or better per power of custom item. Example: If Bob trades in 10 +2 longswords, he will be able to receive an item called "Bob's Longsword +2". (It costs 5 items to make the +1, and 5 more items to make the +2, for a total of 10 items. A +4 item would cost 20 items at this rate, but the rate can be set to whatever the world needs it to be.)

2) Loot dry-ups - Once the Avlis Treasure System is implemented in the world, all magic loot and gold drops can be turned off for a period of time. Players will use up money for potions and slowly start to lose items to server crashes and other mishaps, and gradually the wealth and magic level of the world will decrease.

3) Aggresive DM Interaction - After implementing the death corpse system by which all items drop to a death corpse upon death, the DM's of the world can institute corpse looting by NPC's. The NPC's can target one or two magic items per death and abscond off with them to get them out of circulation.

4) Other custom methods of balance - Other ideas that rise out of discussion with the prospective member world can be used to try to bring their world's economy and magic prevelance into balance with CoPaP.

Current player base and adoption of an application process: For worlds who join CoPaP and did not previously have an application process, their original player base may still play on their server. However, to get the new password to the server, they must fill out an application for it, or for CoPaP directly. The members are effectively grandfathered in, however, they must fill out applications so there is a record of them. Even underage players may be grandfathered in under this rule.

Section 1b: Linking to CoPaP

Once a server is approved to full membership, they may link directly with as many other CoPaP worlds as common sense permits. The means of travel between worlds must be coherent to the cosmology of 3rd Edition D&D Manuel of The Planes, and 2nd Edition Advanced D&D Spelljammers Campaign Setting. Worlds in CoPaP will be designated as either Planes, Planets, or Wildspace.

Part 1: Planes

These worlds are planar realms. They may be subdivided into either Inner, Outer, or Demi-planes. For more information on this, see the Manuel of The Planes 3rd Edition. Planes may only be linked via planar portals to other worlds, whether they are planets or wildspace areas.

Part 2: Planets

These are generally what people think of as "worlds". They are a planet, much like earth, or Krynn, or Toril, or Avlis. They have continents and seas, and they exist on the Prime Material Plane. Travel from planet to plane must involve a portal. Travel from planet to planet CAN involve a portal as well, but it is recommended that the servers be connected by intermediary wildspace servers.

Part 3: Wildspace

This is a generic term for servers that exist in wildspace or the phlogiston flow, as per 2nd Edition Spelljammers rules. A server of this type can contain both areas of wildspace or flow. They are able to connect to any kind of other server. Planes are connected via portals, and planets are traveled to directly.

Section 2: Termination of CoPaP Membership

There are two kinds of termination of CoPaP membership: voluntary and involuntary. At any time, a CoPaP world may voluntarily decide to leave the organization. When they do this, they agree to cut their links to ALL CoPaP member servers. After their first purposeful severed link is achieved, their voting rights in CoPaP are retracted, and they are no longer a full member.

Involuntary membership termination is done in a similar manner to admittance. A proposal is raised by one of the member worlds and posted in the forums. The proposal is discussed and voted on as per Article 6 Section 5. When a majority vote is achieved, the council of four determines whether the vote will stand or be vetoed, in the same hierarchical fashion as determining admittance.

If a world is successfully voted out of CoPaP, a warning will be sent to all players in CoPaP. The warning will give the players one real-time week to get their character files out of that servervault and into a safe server. After the week is up, ALL worlds directly connected to that server must disable their links.

Failure to disable a link to an expunged world is grounds for an automatic termination of the offending server's membership in CoPaP, without any vote necessary. The final decision for cases like this is left to the council of four in a hierarchical fashion.

For the next three real-time weeks, players of the expunged server will be allowed to email character .bic files to one of the CoPaP team leaders for inclusion into the vault. However, they may ONLY email their bic files to a server where their character has been to at least once before. Characters that have never left the expunge world and did not make it past the one week deadline are stuck there.

( Top )




Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0684s ][ Queries: 13 (0.0561s) ][ GZIP on - Debug on ]