Customizable parts of Meridian

This document explains the various parts of Meridian that have customizable parameters. These parameters can be changed while the game is running and will alter the game experience.

How Node Attacks Work

Technical Aspects

The node attacks are controlled by an object, similar to the object that controls the assassin’s game. In order to access this object from the admin window, you need to enter the command: send object 0 GetNodeAttack. This command will return an object number which you must then show object to view.

The node attack object has several settable parameters. This allows us to customize the attacks on the fly to determine how node attacks behave.

The variables:

Name Default Description
pbAttackEnabled 0 (FALSE) Are attacks scheduled?
piAttackFrequency 36 The number of Meridian days minimum between scheduled attacks. The actual attack happens up to 2 Meridian days after it is "scheduled".
piAttackIntensity 8 The maximum number of Xeochicatl that spawn with an attack. This number can be less, but never more.
piAttackDuration 60 Number of minutes the attack lasts.
piLossDuration 12 Number of Meridian days a node loss lasts
piSeveredChance 5 Base percent chance a person is severed from a node instead of merely losing it’s mana during that time.
piNumberOnForAttack 20 Minimum number of people needed to be on for an attack.
pbXeoRespawn 0 (FALSE) When heartstones are dropped, do Xeochicatl respawn from them after a short period of time.
Note that a Meridian day is equal to two "real" hours.

Xeochicatl are also not affected by DestroyDisposable if in the same room as a node attack. That means they won’t be cleared out of a room if left alone for a long time like other monsters. After a node attack, all Xeochicatl may be removed normally.

So, what happens?

After the correct number of Meridian days pass (piAttackFrequency), a timer is created to start the attack. The conditions are then checked for the attack. In order to proceed, there must not be another node attack in progress, the node selected must not currently be deactivated (from a previous node attack), and there must be a minimum number of people online (piNumberOnForAttack). If any of these conditions are not met, then the attack is scheduled for ½ to one full Meridian day later.

When an attack starts, Xeochicatl are created around the node, and Miriana is brought from her previous location to a location near the node. Players then have a certain number of minutes (piAttackDuration) to kill all the Xeochicatl. At the start of the attack, all monsters in the attacked room will die, and a message will be given to all players in the room. Monsters will stop generating in the room. All players online that have bonded with the node will get a message that they feel one of their nodes threatened. After 1/3 of the total time has passed, all online players are given a notification of which node is being attacked.

During a node attack, the Xeochicatl will be in the room and will not leave, even if no users show up. This means that users cannot avoid an attack by not going there. Note that after the attack, the Xeochicatl will disappear like any other monster if left alone for a period of time.

If all are destroyed, the node attack is averted. Note, that the heartstones that the Xeochicatl drop can respawn into Xeochicatl if left on the ground long enough (A variable in the Node Attack object (pbXeoRespawn) controls if heartstones respawn into Xeochicatl). If this feature is enabled, then the last Xeochicatl killed in a node attack should cause heartstones to respawn automatically.

If the attack is not averted, then the node is "taken". This means the art is changed, and it will remain "dead" for a certain period of Meridian days (piLossDuration). During this period, players who have bonded with the node will not get the extra mana that bonding normally gives. In addition, no player will be able to bond with the node during this time. There is a chance that a player will actually be severed from the node instead (piSeveredChance). This chance is checked individually for each character, and is modified by the number of nodes they already have. If severed, the player will have to re-bond with the node in at a future time.

Players online will get a message if the node is lost or severed. Offline players will get a gmail notification of the results.

Which nodes?

Currently, the node attacks are scheduled to happen at the following nodes:
NODE_H9, NODE_VICTORIA, NODE_BADLANDS, NODE_ORCCAVES, NODE_A5, NODE_ICECAVE1

Additionally, there are mechanics for another node that can have attacks scheduled manually for NODE_Q. This node is the "Martyr's Battleground" node. Due to the difficulty of getting to this node, it must be scheduled manually.

Other Information

For events, an admin may open an admin window and send a node the message DoNodeAttack. This will start an attack, following most of the normal conditions. The only condition it will ignore is the minimum number of players online.

When node attacks are activated the designer fairies in the rentable rooms will require heartstones from the Xeochicatl in order to place most of the objects within the room.  Before activation, the designer faries will place any object besides a wooden box.  Afterwards, one heartstone will allow you to place a number of objects based upon which heart stone is offered.  It takes all four types of heartstones (sky, red, blue, brown) in order to place one wooden box within the room.

How the Territory Game Works

The territory game now has a few customizable parameters.

You can get the territory game object by sending the command: send object 0 GetTerritoryGame By showing the object, you can see following parameters:
 
Variable Default Description
piClaimWait 10 Number of minutes to wait before a flag claim is completed.
piClaimRetry 480 Number of minutes to wait before you can claim a flag again.
piMinUsers 20 Minimum number of users needed online before you can take a flag.
piMinAllies 4 Minimum number of allies you must have in same room to make claim.

How the Economy Controls Work

There are new variables in the system object (object 0) that control how much stuff drops from monsters.  These variables work as percentages, so that a value of 50 cuts things down by half and a value of 200 doubles whatever the variable controls.
 
Variable
Default
Description
piMoneyFactor 100 Controls the amount of money dropped by monsters when money does drop.
piItemFactor 100 Controls the total number of items dropped by a monster at death.
piMagicItemModifier 100 Modifies the chance that a magical item is created in a monster's treasure.

These controls can be used to modify the amount of loot dropped from monsters to put an economy back in balance.

One should exercise caution with the variables, however.  A value of piItemFactor below 25 will most likely cause monsters to stop dropping items as monsters have a hard-coded limit of 4 items dropped per death no matter what.  Also, the chance for a magical item to drop is incredibly tiny (0.5% - 2.5% per kill in most cases).  Increasing piMagicItemModifier may not have much obvious effect immediately, and decreasing it too much may completely eliminate the chance for some monsters to drop items.  In general, it should never drop below 10.

How Global Player Bonuses Work

You can set bonuses for players.  These can be useful for testing or for special events.

Advancement Bonuses

You can set a global bonus for advancment in the System object.

Variable
Default
Description
piAdvancementRate 100
 Sets the rate of advancement as a percent adjustement to the secondary chance to advance.

This variable only affects the secondary chance to advance, and affects it as a percent.  So, setting it to 50 makes it twice as hard to advance (50% of base), and setting it to 200 makes it twice as easy to advance (200% of base).  This variable affects all spells and skills.

Spellpower Bonuses

An admin can give spellpower bonuses to the entire server through the System object.

There are two variables in System which can affect spellpower to extreme ends.

Variable
Default
Description
piFullSpellpower FALSE If set to true, makes all spells cast with maximum (99) spellpower.
piNoSpellPower FALSE If set to true, makes all spells cast with no (0) spellpower.

piFullSpellpower takes precidence.

There are also two messages in System used to give specific bonuses to specific schools:
send object 0 SetBonusSpellpower school int <school> [bonus int <amount>] [add int <amount>]
This sets the bonus for the selected school.  The parameter bonus sets the bonus to that amount, and add adds that amount to the existing bonus.  Either bonus or add must be defined. If neither are defined, no change is made.  If both are defined, then bonus is used and add is discarded.  The return value is the new value of the bonus for that school.  Either number can be negative.

send object 0 GetBonusSpellpower school int <school>
This gets the current bonus for the school as a return value.

Note: the school constants, usable for the school variables above are: SS_SHALILLE, SS_QOR, SS_FAREN, SS_KRAANAN, SS_RIIJA, SS_JALA