PSwiki - User contributions [en]

Instances

2026-03-07T22:22:29Z

Talad: Created page with "== I'''nstance 0''' == This is the default instance where player are placed when created, and where all our NPCs and visible items are. Loaded by the server always. == '''Instance 1''' == Is reserved to: * guildhouse locks, which are real item placed on the ground, that connect the door with the actual guildhouse instance * Action location containers, example a forge connected to a 3d mesh in the level, maybe have a container representing the forge in instance 1. The..."

== I'''nstance 0''' ==
This is the default instance where player are placed when created, and where all our NPCs and visible items are.

Loaded by the server always.

== '''Instance 1''' ==
Is reserved to:

* guildhouse locks, which are real item placed on the ground, that connect the door with the actual guildhouse instance
* Action location containers, example a forge connected to a 3d mesh in the level, maybe have a container representing the forge in instance 1. The container will not be visible by the player directly, but will be accessed when he click on the action location

Loaded by the server always.

== '''Instances >1 and <first guildhouse''' ==
This at the moment is no man's lands because it's not loaded by the server at startup, and is not a guildhouse and so not loaded dynamically.

== '''Guildhouse Instances''' ==
Based on the lock item_instances id we determine the instance where the guildhouse is located. Anyway guildhouses have unique coordinates and are neven overlapping.

At the moment the lowest one is '''1000'''.

Loaded by the server on demand when the first player enters the guildhouse.

PSUnreal Config

2026-03-07T22:13:36Z

Talad: /* Dynamic elements */

== Static elements ==

* [[Config Races]]

* [[Config Character Creation]]

* [[How to define Sectors]]

* [[Music and Ambience Sounds]]
*[[Creatures and Attack sounds]]
*[[Creatures, Attack Types and Attacks]]

* Lights

* [[HowtoAddASpellToTheDatabase|Howto add a spell to the database.]]
*[[Combat and chase acceptance range]]
*[[Factions and Organizations]]
*[[Weapon Trails]]
*[[Voiceovers (audio files)]]

== Dynamic elements ==

* [[PSUnreal Proximity Triggers]]

* [[Random Generated events]]

* [[Hunt Locations and Natural Resources]]

* [[Levers and Interactable Objects]]

* [[Traps]]
* [[Instances]]
*[[Loot]]
*[[PSUnreal Guildhouses|Guildhouses (action locations)]]
*[[Setting Items]]
*[[Add new NPC]]
*[[Add Waypoints and paths]]
*[[Minigames]]
*[[Procedural Dungeon Generation]]
*[[Reload - Reloading at runtime]]
*[[PSUnreal Fishing Setup|Fishing Setup]]

== Npcs ==

* Behaviours: Nearly all we have is documented in [[NpcClient Design|this page]] and its sub pages
* [[KAs (Knowledge Areas) list and structure|Knowledge Areas]] (for dialogues)

== Quests ==

* [[Quest scripts syntax]]

== Mechanisms ==
TODO

Tribe Design

2026-02-17T21:35:42Z

Talad: Undo revision 25740 by Talad (talk)

= Tribe Design =

The tribe design is done using [[Behaviors_and_Reactions|NPC Behaviors]] and [[Tribe_Scripting|Recipes]]. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
Tribe -> Tribe : AddCyclicRecipes
loop For each member
alt For NPC's that have the tribe's idle behavior
Tribe -> Tribe : Get highest priority recipe
Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager
end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

Tribe members are normal NPCs. They all expand a base NPCType called 'AbstractTribesman', on which each tribe adds it's own particularities (e.g. when to go to sleep, what to do when they meet a stranger, etc). Read more on [[NPC Scripting]]. The 'AbstractTribesman' contains behaviors that describe generic actions: breeding, gathering, mining, fighting, exploring and working. (trading to be added soon). These generic behaviors use some data buffers to read data from during runtime in order to execute the same behavior on different data. (different mines, different fields, different building places, etc)

Upon parsing recipes, different perceptions are fired on the tribesmen. This process simulates a working society on which a superior entity assigns tasks to the population.

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

= Runtime =

==Step #1 (Loading)==

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

1) The Recipe Manager loads all available recipes from mysql:'tribe_recipes' and add those in a flat array "recipes", one entry per recipe.

2) psNPCManager::LoadTribes() loads from the database all the tribes from mysql:'tribes'

3) For each tribe psNPCManager::LoadTribes() loads all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*assets from mysql:'sc_tribe_assets'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

4) For each tribe it calls RecipeManager::AddTribe() , which parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

5) Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

==Step #2 (RunTime)==

(executed once on startup and each time a recipe is completed)

1) NPCManager is ticking all the tribes with frequency TRIBE_TICK (tribe.h) and calling Advance() on each tribe

2) Each tribe searches for idle members, to assign tasks in Tribe::Advance()

3) updates the waiting time of all the TOP level recipe (the ones listed in mysql:'tribes_recipe.algorithm' as loadRecipe())

4) select the best recipe based on lowest wait time and high priority (where priority is defined level in the recipe tree, the lowest the better)

The Tribal Object selects the top-priority recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
It checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list.
Requirement parsing can be done two ways:
* Distributed Parsing : The parser takes the first requirement and checks it + tries to achieve it. When the same recipe gets parsed again, the parser takes the second requirement (even if the first is still not met) and tries to achieve it. This way, the parser loops through requirements and tries to achieve all in parallel.
* Concentrated Parsing : The parser tries to achieve the first requirement on each recipe parse until it is met. After that it picks the second requirement and applies the same principle.

5) A new child of the RecipeTree is added as soon as the tribe decides that something can be executed (all requirements met). This is added to 'tribalRecipe' variable. Then the algorithm of this recipe is executed (for example percect NPC to go work), and the child is immediately removed from the tree. This mean that while the NPC is working, the tree does not contain that child anymore, so if another NPC becomes available, it will pick the NEXT requirement in line.

Example of Distributed vs Concentracted Parsing:

E.G.: We want our tribe to gain 150 of Coal, Silver, Gold and Platinum.

Using Distributed Parsing:
*Step 1: Assign miner to Coal.
*Step 2: Assign miner to Silver.
*Step 3: Assign miner to Gold.
*Step 4: Assign miner to Platinum.
*Step 5: Assign miner to Coal.
...

Using Concentrated Parsing: (in this example we consider each step gets the tribe 1 quantity of resource)
*Step 1: Assign miner to Coal.
...
*Step 150: Assign miner to Coal.
*Step 151: Assign miner to Silver.
...

==Step #3 (Recipe's Algorithm)==

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs. A complete set of algorithm and requirements functions can be found [[Tribe_Scripting|here]].

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

== Mining tribe ==

The mining tribe is defined in tribes table with:
* a tribal_recipe value pointing to tribe_recipe table which is defining the brain, aggressivity, growth, ...
* a set of members inside tribe_members table, each member is flagged with a tag, example "Miner" which then be used in the selection of workers for a specific task

The Brain definition above will point to sc_npctypes table, which will most likely derive from AbstractTribesman

AbstractTribesman will define the reactions/behaviors for example

<react event="tribe:explore" behavior="Explore" />
<react event="tribe:mine" behavior="MineResource" />

During the 'Explore' behavior, tribe members will move around the map. psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range. This perception will make the NPC find the mine.

After mining from an unknown deposit, the npcclient will receive a psWorkDoneMessage telling it what his npc just mined. This function renames the former 'mine' Memory with it's real deposit name.

Two things need to happen:

1) The tribe sends a member to explore for mining locations, this happens with

<react event="tribe:explore" behavior="Explore" />

2) The tribe sends a members to mine for a KNOWN resource location, this happens with

<react event="tribe:mine" behavior="MineResource" />

Important methods:
* psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range
* NPCType::FirePerception() is checking if this NPC should automemorize the new locations sensed
* Tribe::Memorize() where we add the location found to the NPC memory

The mining tribe will send his members to explore in search of resources. This is done with the Behavior "Explore" in the AbstractTribsmen NPC Type stored in sc_npctypes.

== Tribe reaction to attacks ==

In RecipeManager::CreateGlobalNPCType() we check the Unity Trait of the tribe: cowards / normal / united

Anything but cowards gets
reaction = "<react event=\"attack\" behavior=\"united_attacked\" delta=\"100\" />";

When a player attacks a member of a tribe , the line above triggers a behavior on the attack.

In AbstractTribesman this happens:
<behavior name="united_attacked" decay="10">
<talk text="The tribe is under attack!" target="false" />
<locate obj="tribe:target" range="100" />
<percept event="tribesman attacked" target="tribe" range="30" />
<percept event="fight" />
</behavior>

the important piece is target ="tribe" because this trigger a perception in the tribe in Tribe::SendPerception() that scans all the NPCs and sends the given perception = "tribesman attacked"

This is defined again in AbstractTribesman
<react event="tribesman attacked" behavior="normal_attacked" delta="100" do_not_interrupt="Chase"/>
and this points to a normal attack! Which just asks the npc to fight.
[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2026-02-16T22:53:35Z

Talad: /* Tribe reaction to attacks */

= Tribe Design =

The tribe design is done using [[Behaviors_and_Reactions|NPC Behaviors]] and [[Tribe_Scripting|Recipes]]. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
Tribe -> Tribe : AddCyclicRecipes
loop For each member
alt For NPC's that have the tribe's idle behavior
Tribe -> Tribe : Get highest priority recipe
Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager
end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

Tribe members are normal NPCs. They all expand a base NPCType called 'AbstractTribesman', on which each tribe adds it's own particularities (e.g. when to go to sleep, what to do when they meet a stranger, etc). Read more on [[NPC Scripting]]. The 'AbstractTribesman' contains behaviors that describe generic actions: breeding, gathering, mining, fighting, exploring and working. (trading to be added soon). These generic behaviors use some data buffers to read data from during runtime in order to execute the same behavior on different data. (different mines, different fields, different building places, etc)

Upon parsing recipes, different perceptions are fired on the tribesmen. This process simulates a working society on which a superior entity assigns tasks to the population.

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

= Runtime =

==Step #1 (Loading)==

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

1) The Recipe Manager loads all available recipes from mysql:'tribe_recipes' and add those in a flat array "recipes", one entry per recipe.

2) psNPCManager::LoadTribes() loads from the database all the tribes from mysql:'tribes'

3) For each tribe psNPCManager::LoadTribes() loads all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*assets from mysql:'sc_tribe_assets'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

4) For each tribe it calls RecipeManager::AddTribe() , which parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

5) Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

==Step #2 (RunTime)==

(executed once on startup and each time a recipe is completed)

1) NPCManager is ticking all the tribes with frequency TRIBE_TICK (tribe.h) and calling Advance() on each tribe

2) Each tribe searches for idle members, to assign tasks in Tribe::Advance()

3) updates the waiting time of all the TOP level recipe (the ones listed in mysql:'tribes_recipe.algorithm' as loadRecipe())

4) select the best recipe based on lowest wait time and high priority (where priority is defined level in the recipe tree, the lowest the better)

The Tribal Object selects the top-priority recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
It checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list.
Requirement parsing can be done two ways:
* Distributed Parsing : The parser takes the first requirement and checks it + tries to achieve it. When the same recipe gets parsed again, the parser takes the second requirement (even if the first is still not met) and tries to achieve it. This way, the parser loops through requirements and tries to achieve all in parallel.
* Concentrated Parsing : The parser tries to achieve the first requirement on each recipe parse until it is met. After that it picks the second requirement and applies the same principle.

5) A new child of the RecipeTree is added as soon as the tribe decides that something can be executed (all requirements met). This is added to 'tribalRecipe' variable. Then the algorithm of this recipe is executed (for example percect NPC to go work), and the child is immediately removed from the tree. This mean that while the NPC is working, the tree does not contain that child anymore, so if another NPC becomes available, it will pick the NEXT requirement in line.

Example of Distributed vs Concentracted Parsing:

E.G.: We want our tribe to gain 150 of Coal, Silver, Gold and Platinum.

Using Distributed Parsing:
*Step 1: Assign miner to Coal.
*Step 2: Assign miner to Silver.
*Step 3: Assign miner to Gold.
*Step 4: Assign miner to Platinum.
*Step 5: Assign miner to Coal.
...

Using Concentrated Parsing: (in this example we consider each step gets the tribe 1 quantity of resource)
*Step 1: Assign miner to Coal.
...
*Step 150: Assign miner to Coal.
*Step 151: Assign miner to Silver.
...

==Step #3 (Recipe's Algorithm)==

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs. A complete set of algorithm and requirements functions can be found [[Tribe_Scripting|here]].

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

== Mining tribe ==

The mining tribe is defined in tribes table with:
* a tribal_recipe value pointing to tribe_recipe table which is defining the brain, aggressivity, growth, ...
* a set of members inside tribe_members table, each member is flagged with a tag, example "Miner" which then be used in the selection of workers for a specific task

The Brain definition above will point to sc_npctypes table, which will most likely derive from AbstractTribesman

AbstractTribesman will define the reactions/behaviors for example

<react event="tribe:explore" behavior="Explore" />
<react event="tribe:mine" behavior="MineResource" />

During the 'Explore' behavior, tribe members will move around the map. psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range. This perception will make the NPC find the mine.

After mining from an unknown deposit, the npcclient will receive a psWorkDoneMessage telling it what his npc just mined. This function renames the former 'mine' Memory with it's real deposit name.

Two things need to happen:

1) The tribe sends a member to explore for mining locations, this happens with

<react event="tribe:explore" behavior="Explore" />

2) The tribe sends a members to mine for a KNOWN resource location, this happens with

<react event="tribe:mine" behavior="MineResource" />

Important methods:
* psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range
* NPCType::FirePerception() is checking if this NPC should automemorize the new locations sensed
* Tribe::Memorize() where we add the location found to the NPC memory

The mining tribe will send his members to explore in search of resources. This is done with the Behavior "Explore" in the AbstractTribsmen NPC Type stored in sc_npctypes.

== Tribe reaction to attacks ==

In RecipeManager::CreateGlobalNPCType() we check the Unity Trait of the tribe: cowards / normal / united

Anything but cowards gets
reaction = "<react event=\"attack\" behavior=\"united_attacked\" delta=\"100\" />";

When a player attacks a member of a tribe , the line above triggers a behavior on the attack.

In AbstractTribesman this happens:
<behavior name="united_attacked" decay="10">
<talk text="The tribe is under attack!" target="false" />
<locate obj="tribe:target" range="100" />
<percept event="tribesman attacked" target="tribe" range="30" />
<percept event="fight" />
</behavior>
[[Category:Engine documents]] [[Category:NPCClient Design]]

Tribe Design

2026-02-16T22:53:30Z

Talad: /* Tribe reaction to attacks */

Tribe Design

2026-02-10T23:23:55Z

Talad:

= Tribe Design =

The tribe design is done using [[Behaviors_and_Reactions|NPC Behaviors]] and [[Tribe_Scripting|Recipes]]. Tribe members are assigned tasks based on what the recipes dictates the tribe to achieve. This system uses a Recipe Manager which takes care of parsing recipes, breaking the initial recipe into subtasks and telling the npcs which action to take.

== Classes ==
<uml>
scale 0.8
Tribe "1" *-- "0..N" NPC : members
Tribe "1" *-- "0..N" NPC : deadMembers
Tribe "1" *-- "0..N" Resource : resources
Tribe "1" *-- "0..N" Memory : memories
Tribe "1" *-- "0..N" Asset : assets
Tribe "1" *-- "0..N" Knowledge : knowledge
Tribe "1" *-- "1..1" RecipeTreeNode : recipes
RecipeTreeNode *-- Recipe
RecipeManager "1" *-- "N..1" Recipe : all recipes
</uml>

''' Members '''

Tribe members (both dead & alive) are kept in an array in the Tribe Class. They are all represented by the NPC class. The tribal class only has methods to attach a tribe member. For spawning new members the server (gemSupervisor & entityManager classes) and the npcclient class are responsable.

Tribe members can have different types. (Discussion needed about tribe types)

Tribe members are being kept in the 'tribe_members' mysql table.

''' Resources '''

A resource is kept in a data structure (''Tribe::Resource'') containing it's name, nick and quantity. The tribe class has methods for adding, modifying, storing and completely deleting resources.

Resources are being kept in the 'sc_tribe_resources' mysql table.

''' Memories '''

A memory is a location of some importance to the tribe. (E.g. a mine, a field, an enemy, etc)

A memory is kept in a data structure (''Tribe::Memory'') containing it's location (sector & coords), it's name and a link to an NPC (which is NULL if the memory is public to all tribe members, or != NULL if it's private to a tribe member). The tribe object has methods to add, store, modify and search memories.

Tribe members also have a memory slot for keeping it's current task location. (see bufferMemory attribute of NPC class).

Tribe memories are being kept in the 'sc_tribe_memories' mysql table.

''' Assets '''

Assets are belongings of the tribe. They can represent buildings, items or spots to be built in the future.

An asset is represented by a data structure (''Tribe::Asset'') containing it's location (sector & coords), it's name, it's quantity (relevant just for items) and it's type (Building Spot, Building or Item). The tribe class has methods for adding, editing and deleting assets. It also has methods for managing buildings. (e.g. Replace a building spot with the actual building after the workers built it)

Tribe assets are being kept in the 'sc_tribe_assets' mysql table.

''' Knowledge '''

Knowledge represents the information the tribe has gathered and the technologies they can use. (E.g. Ironworks, pottery, horseback riding, alphabet, math, etc)

Technically, they are just strings used as tokens to prove the tribe has acquired knowledge or not.

Knowledge is kept in an array of strings.

Tribe knowledge is being kept in the 'sc_tribe_knowledge' mysql table.

''' Recipe Tree Node '''

This class represents a node of the recipe tree describing the tribe current tasks. Each recipe tree node contains a link to it's recipe, waiting times, current requirement, current algorithm step and relationship information regarding other recipes. (just as a standard Tree, it may have parents and descendants).

RecipeTreeNodes are not being stored in any database. They are just used during runtime as an AI for tribes.

''' Recipe '''

A recipe is a set of requirements and algorithm steps regarding a task that needs to be done. Recipes can vary from simple (Gather a resource) to very complex (Build an entire civilization).

Recipes are being stored in the 'tribe_recipes' mysql table.

== Sequences ==

=== Advance Sequence ===

Advance sequence is the heart of the Tribe system. The NPCClient will advance the brain 4 times a second. On each loop, this sequence takes care of special cases (e.g.: 0 npcs alive in tribe) and assigns tasks to idle members.

<uml>
-> NPCClient : Advance
activate NPCClient
loop For each tribe
NPCClient -> Tribe : Advance
activate Tribe
Tribe -> Tribe : AdvanceResources
Tribe -> Tribe : AddCyclicRecipes
loop For each member
alt For NPC's that have the tribe's idle behavior
Tribe -> Tribe : Get highest priority recipe
Tribe -> RecipeManager : Apply Recipe
activate RecipeManager
Tribe <- RecipeManager
deactivate RecipeManager
end
end
NPCClient <-- Tribe
deactivate Tribe
end
<-- NPCClient
deactivate NPCClient
</uml>

== Setting up tribes ==
There are 3 main database tables that need to be populated.

* [[TribesTable|tribes]]
** Each row represents one tribe, which must have a home position/sector and a radius in which to resurrect dead members.
** max_size sets the maximum number of members.
** wealth_resource sets the different types of resource that a tribe can mine in order to grow and/or sustain itself. This needs more work however the most important one is wealth_resource_growth which is the default rate at which a resource will grow without any work per second.
** reproduction_cost is the amount of resources required to reproduce.
** tribal_recipe loads the initial recipe that sets tribe traits and loads tribe goals (recipes)

* tribe_members
** Each row is an association between a PID (on the server side) and a tribe.

* tribe_recipes
** Each row represents a recipe (name,requirements,algorithm). This table needs to be loaded in order to order tribe members what to do. Not having recipes, or requesting a recipe that does not exist will result in a termination of the npcclient.

Additionally, tables for extra tribe info need to be created:
*sc_tribe_assets
*sc_tribe_knowledge
*sc_tribe_memories
*sc_tribe_resources

== Tribe day-to-day life ==

Tribe members are normal NPCs. They all expand a base NPCType called 'AbstractTribesman', on which each tribe adds it's own particularities (e.g. when to go to sleep, what to do when they meet a stranger, etc). Read more on [[NPC Scripting]]. The 'AbstractTribesman' contains behaviors that describe generic actions: breeding, gathering, mining, fighting, exploring and working. (trading to be added soon). These generic behaviors use some data buffers to read data from during runtime in order to execute the same behavior on different data. (different mines, different fields, different building places, etc)

Upon parsing recipes, different perceptions are fired on the tribesmen. This process simulates a working society on which a superior entity assigns tasks to the population.

== Tribe death ==
When all the members die, then a member will be resurrected if there are 10*reproduction_cost resources available.

= Runtime =

==Step #1 (Loading)==

(executed only once, on NPCClient's startup. No further interrogation on the database should be done)

On NPCClient's startup everything is loaded into the classes.

1) The Recipe Manager loads all available recipes from mysql:'tribe_recipes' and add those in a flat array "recipes", one entry per recipe.

2) psNPCManager::LoadTribes() loads from the database all the tribes from mysql:'tribes'

3) For each tribe psNPCManager::LoadTribes() loads all the information regarding the tribe:
*resources from mysql:'sc_tribe_resources'
*memories from mysql:'sc_tribe_memories'
*knowledge from mysql:'sc_tribe_knowledge'
*assets from mysql:'sc_tribe_assets'
*basic tribe information from mysql:'tribes' (including the ID of the tribal recipe, more details below)
*npc's are loaded by the psNPCClient and assigned to the tribe

4) For each tribe it calls RecipeManager::AddTribe() , which parses the requirements and keeps them in the Recipe Class. (Recipe::requirements<Recipe::Requirement>)

5) Further on, each Tribal Object is linked to the Recipe Manager. (a pointer is sent and loaded into a csArray)
For each tribe loaded, the Recipe Manager does the following:
* assembles a data structure named 'TribeData'
* links the tribal recipe belonging to this tribe to 'TribeData'
* parses the information in the tribal recipe and assign the stats to csStrings in 'TribeData'
* computes a tribal npctype having as parent the 'AbstractTribesman' npctype. The difference is done by adding reactions to whatever the tribe reacts to. (attacking any player nearby or simply greeting them, sleeping at day or at night, etc)

==Step #2 (RunTime)==

(executed once on startup and each time a recipe is completed)

1) NPCManager is ticking all the tribes with frequency TRIBE_TICK (tribe.h) and calling Advance() on each tribe

2) Each tribe searches for idle members, to assign tasks in Tribe::Advance()

3) updates the waiting time of all the TOP level recipe (the ones listed in mysql:'tribes_recipe.algorithm' as loadRecipe())

4) select the best recipe based on lowest wait time and high priority (where priority is defined level in the recipe tree, the lowest the better)

The Tribal Object selects the top-priority recipe which needs execution and sends it to the Recipe Manager.

The Recipe Manager parses the contents of the recipe:
It checks for requirements. If requirements are met it proceeds with parsing the algorithm (see step #3). If requirements are not met, it pushes the Recipes which achieves the requirement on top of the tribe's recipe list.
Requirement parsing can be done two ways:
* Distributed Parsing : The parser takes the first requirement and checks it + tries to achieve it. When the same recipe gets parsed again, the parser takes the second requirement (even if the first is still not met) and tries to achieve it. This way, the parser loops through requirements and tries to achieve all in parallel.
* Concentrated Parsing : The parser tries to achieve the first requirement on each recipe parse until it is met. After that it picks the second requirement and applies the same principle.

5) A new child of the RecipeTree is added as soon as the tribe decides that something can be executed (all requirements met). This is added to 'tribalRecipe' variable. Then the algorithm of this recipe is executed (for example percect NPC to go work), and the child is immediately removed from the tree. This mean that while the NPC is working, the tree does not contain that child anymore, so if another NPC becomes available, it will pick the NEXT requirement in line.

Example of Distributed vs Concentracted Parsing:

E.G.: We want our tribe to gain 150 of Coal, Silver, Gold and Platinum.

Using Distributed Parsing:
*Step 1: Assign miner to Coal.
*Step 2: Assign miner to Silver.
*Step 3: Assign miner to Gold.
*Step 4: Assign miner to Platinum.
*Step 5: Assign miner to Coal.
...

Using Concentrated Parsing: (in this example we consider each step gets the tribe 1 quantity of resource)
*Step 1: Assign miner to Coal.
...
*Step 150: Assign miner to Coal.
*Step 151: Assign miner to Silver.
...

==Step #3 (Recipe's Algorithm)==

(executed for each step the algorithm has, each time a recipe needs execution)

The Recipe has an algorithm stored as a csArray<csString>. When an algorithm needs an execution, the Recipe Manager takes each string and parses it. Depending on the rules we set, the Recipe Manager will tell the tribal object which perceptions to fire on their npcs. A complete set of algorithm and requirements functions can be found [[Tribe_Scripting|here]].

(E.g.: If the recipe's algorithm require us to send 10 workers to build a town hall, the tribal object will be told to fire a "go to work" perception on 10 worker tribesman)

== Mining tribe ==

The mining tribe is defined in tribes table with:
* a tribal_recipe value pointing to tribe_recipe table which is defining the brain, aggressivity, growth, ...
* a set of members inside tribe_members table, each member is flagged with a tag, example "Miner" which then be used in the selection of workers for a specific task

The Brain definition above will point to sc_npctypes table, which will most likely derive from AbstractTribesman

AbstractTribesman will define the reactions/behaviors for example

<react event="tribe:explore" behavior="Explore" />
<react event="tribe:mine" behavior="MineResource" />

During the 'Explore' behavior, tribe members will move around the map. psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range. This perception will make the NPC find the mine.

After mining from an unknown deposit, the npcclient will receive a psWorkDoneMessage telling it what his npc just mined. This function renames the former 'mine' Memory with it's real deposit name.

Two things need to happen:

1) The tribe sends a member to explore for mining locations, this happens with

<react event="tribe:explore" behavior="Explore" />

2) The tribe sends a members to mine for a KNOWN resource location, this happens with

<react event="tribe:mine" behavior="MineResource" />

Important methods:
* psNPCManager::PerceptProximityLocations() is called every second, triggering a LocationPerception with "location sensed" to all NPC in range
* NPCType::FirePerception() is checking if this NPC should automemorize the new locations sensed
* Tribe::Memorize() where we add the location found to the NPC memory

The mining tribe will send his members to explore in search of resources. This is done with the Behavior "Explore" in the AbstractTribsmen NPC Type stored in sc_npctypes.

== Tribe reaction to attacks ==

In RecipeManager::CreateGlobalNPCType() we check the Unity Trait of the tribe: cowards / normal / united

Anything but cowards gets

reaction = "<react event=\"attack\" behavior=\"united_attacked\" delta=\"100\" />";

[[Category:Engine documents]] [[Category:NPCClient Design]]

Creatures and Attack sounds

2026-01-28T23:35:27Z

Talad:

== Attack Sound ==
For humanoid and creatures we consider that they can use melee or use weapons. In the Combat_Montage of our player character, we have the attack animation. In the attack animation segment we have one events (Notify) at the start of type PSAnimNotifyAttackSound

[[File:PSAnimNotify.png]]

If you need to enable the attack sound on a creature, you need to add the PSAnimNotifyAttackSound in the attack Montage (not in the attack sequence).
In psAttack::Attack() we create a soundID with this rule:<blockquote>
if the weapon is melee then use the race: <race>-4 (because 4 is the melee skill ID)

otherwise use the weapon skill id: "w-" + <weapon skill>

Example: Stonehammer hitting with a Fist = 0-4

Example: Stonehammer hitting with a sword = w-0</blockquote>this soundID is then sent to all clients this way: we call BroadcastAttackAnimation() to send it to all players in range, and then we call ReceiveAttackAnimation() on clients BP, this is then calling PlayPSAnimMontage()

Inside PlayPSAnimMontage() we use the soundid

The class used is UPSAnimNotifyAttackSound

== Hit sound ==
When someone is hit.

in psAttack::AffectTarget() we create a soundID <Weapon Type> + "-" + <Material> + <hit:1 or block:0>

Material is defined in [[Race infoTable]].skin_type (0-flesh, 1-wood, 2-metal, 3-carapace, 4-fur, 5-slime)

Example: fist hitting carapare of a trepor: 4-3-1

Example: sword getting blocked by flesh: 0-0-0

this soundID is then sent to all clients this way: we call BroacastCombatResultSound() to send it to all players in range

The hit sounds are decoupled from the hit animation because they need to play regardless.

== Death Sound ==
If we want to have a sound when the creature dies, we have it in the Death Montage, on the death animation

[[File:Death Sound.png]]

Creatures and Attack sounds

2026-01-28T21:38:08Z

Talad: /* Attack Sound */

== Attack Sound ==
For humanoid and creatures we consider that they can use melee or use weapons. In the Combat_Montage of our player character, we have the attack animation. In the attack animation segment we have one events (Notify) at the start of type PSAnimNotifyAttackSound

[[File:PSAnimNotify.png]]

In psAttack::Attack() we create a soundID with this rule:<blockquote>
if the weapon is melee then use the race: <race>-4 (because 4 is the melee skill ID)

otherwise use the weapon skill id: "w-" + <weapon skill>

Example: Stonehammer hitting with a Fist = 0-4

Example: Stonehammer hitting with a sword = w-0</blockquote>this soundID is then sent to all clients this way: we call BroadcastAttackAnimation() to send it to all players in range, and then we call ReceiveAttackAnimation() on clients BP, this is then calling PlayPSAnimMontage()

Inside PlayPSAnimMontage() we use the soundid

The class used is UPSAnimNotifyAttackSound

== Hit sound ==
When someone is hit.

in psAttack::AffectTarget() we create a soundID <Weapon Type> + "-" + <Material> + <hit:1 or block:0>

Material is defined in [[Race infoTable]].skin_type (0-flesh, 1-wood, 2-metal, 3-carapace, 4-fur, 5-slime)

Example: fist hitting carapare of a trepor: 4-3-1

Example: sword getting blocked by flesh: 0-0-0

this soundID is then sent to all clients this way: we call BroacastCombatResultSound() to send it to all players in range

The hit sounds are decoupled from the hit animation because they need to play regardless.

== Death Sound ==
If we want to have a sound when the creature dies, we have it in the Death Montage, on the death animation

[[File:Death Sound.png]]

Tribe Scripting

2026-01-05T17:09:02Z

Talad: /* SpawnMember */

= Recipe Logic =

== Recipes ==
'''A recipe database entry'''
{| border="1"
!id
!name
!requirements
!algorithm
!persistent
|-
|used for db storing
|Name of the recipe
|requirement string containing all requirements
|algorithm string containing all algorithm steps
|If this flag is on, the recipe won't ever be deleted from the recipe tree. After parsing it, if no other recipe has a higher priority... it will be reparsed.
|}

== Usage of Recipes ==

Recipes is used to describe how [[tribes]] react. See [[Tribe Design]] for details.

On initialization, a tribal recipe is first loaded in respect of the information indicated by the 'tribal_recipe' field. (see [[TribesTable|tribes.sql]]). The tribal recipe is formed from 'Tribe Info' functions. (see below)

Based on those functions the npctype for each tribe is created and initial recipes are loaded.

Further on, each Recipe has two important sections: requirements and algorithm. Each of those two is represented by a long string (the maximum is set in the database to 1000 characters) of functions separated by a semi-colon ';'. Upon parsing the long string is split in respect of the semicolons (;) and the recipe manager analyzes each resulting function.

== Recipe-Tree Nodes ==

Inside a tribe object, recipes are stored as Recipe Tree Nodes. This class was created to facilitate the management of recipes and the way recipes are selected to be parsed.

All recipes are stored as leaves in a tree. This way we can always know their hierarchy and precedence.

Besides the obvious usage as a tree, recipe tree nodes also hold vital data for recipe parsing: last requirement parsed, last algorithm step parsed, remaining waiting time.

Let's consider an example of a tribe which has some building spots available and the task to build on those spots.

Having the tree above, it's easy to select the actions required to complete the task. We first get some more food. After that we get the required members, search for wood and stone, and finally build the buildings.

= Tribe Info =

== Brain ==

Syntax: brain(x);

Arguments:
* x brain eg. behaviour to use for the tribe.

Effect: Override the AbstractTribesman as the brain for the tribe.

For each tribe the server create an tribe_<tribe_id> behavior that inherit from the brain given i the brain command. If no brain entry is given the tribe behaviour will use the AbstractTribesman behaviour. This can be used to create tribes with special behaviours.

== Aggressivity ==

Syntax: aggressivity(x);

Arguments:
* x in { warlike, neutral, peaceful }

Effect: Decides the way the tribe reacts to other entities around it's members:
* Warlike -- Attack anything on sight.
* Neutral -- Attack only if members are attacked.
* Peaceful -- If tribe members are attack they flee, trying to escape.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype in respect of this function's argument.

== Growth ==
Syntax: growth(x)

Arguments:

* x in ?

Not implemented , at the moment all tribes have "conservatory" as value

== Unity ==
Syntax: unity(x)

Arguments:

* x in {*, cowards}

At the moment anything but "cowards" will trigger one member of the tribe to help another member when attacked.

== SleepPeriod ==

Syntax: sleepPeriod(x);

Arguments: x in { diurnal, nocturnal, nosleep }

{|
|-
|diurnal
|22:00 - 06:00
|Sleep during night
|-
|nocturnal
|08:00 - 18:00
|Sleep during day
|}

Effect: Makes the tribe members sleep at the given period of day.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype. The reaction should react to timeofday perceptions.

== LoadRecipe ==

Syntax: loadRecipe(x); loadRecipe(x,distributed);

Arguments:
* 'x' is a Recipe Name

Effect: Loads a recipe into the recipe tree. The new recipe's priority will be the current recipe's priority + 1.

== LoadCyclicRecipe ==

Syntax: loadCyclicRecipe(x,t);

Arguments:
* 'x' is a Recipe Name
* 't' is an int, representing the number of ticks (milliseconds) between recipe executions

Effect: Loads a recipe into the recipe tree once every 't' ticks, with highest priority.

= Requirements =

== Building ==

Syntax: building(x,y,r);

Arguments:
* 'x' is a building name.
* 'y' is an int defining the quantity of buildings needed.
* 'r' is the recipe needed to get the building if not available

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the building 'x' of quantity 'y'.

== Tribesman ==

Syntax: tribesman(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' regardless if they are busy or doing something else. If 'y' members are found, the requirement is considered met.

== TribesmanIdle ==

Syntax: tribesmanidle(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' with the current behavior equal to the tribe's idle behavior. (e.g. "do nothing" behavior) If 'y' members are found idle, the requirement is considered met.

== Resource ==

Syntax: resource(x,y,r);

Arguments:
* x is the resource name
* y is the resource quantity required
* r is the recipe needed to get the resource if not available

Effect & Mechanics: The tribal object checks for a 'y' quantity of 'x' resource. If this quantity is found then the resource is considered complete. $RESOURCE_AREA, $REPRODUCTION_RESOURCE and $REPRODUCTION_COST are valid variables.

Judging by the way natural resources are defined, any string declared in natural_resources.sql as a resource can be parsed and mined by the tribe. By default, any new mine found by the tribesmen is stored as a memory named 'mine'. Upon it's first mining action done on the 'mine' memory, a reward is granted to the npc. When the NPC gets home and gives that to the tribal object, the memory 'mine' is renamed after the reward. In conclusion, having a resource named 'Space Shuttle' is valid and works.

Note: The resource requirement just checks if enough resources are available. Use 'alterResource' function in your recipes in order to actually substract resource from the tribe bank.

== Knowledge ==

Syntax: knowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: As described in the [[Tribe Design]] document, knowledge are tokens that keep track on technologies developed by the tribe. It's valid to request any string as long as it would be possible for the tribe to develop the knowledge. Otherwise the requirement will never be met.

== Item ==

Syntax: item(x,y);

Arguments:
* 'x' is an item/building name.
* 'y' is an int defining the quantity of items needed.

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the item 'x' of quantity 'y'.

== Recipe ==

Syntax: recipe(x,y);

Arguments:
* 'x' is a recipe name.
* 'y' is an int defining the quantity of recipes needed.

Effect & Mechanics: Upon parsing this requirement, the parser just adds an 'y' number of 'x' recipes to the recipe tree.

This requirement isn't quite practical and should be avoided.

== Trader (Not available) ==

Syntax: trader(x);

Arguments:
* 'x' is an item name

Effect: This requirement should check the traders array for a nearby trader giving item 'x'.

== Memory ==

Syntax: memory(m,p,r);

Arguments:
* 'm' is a memory name
* 'p' is a probability between 0-100. Setting this to 10 make it 10% probably that the r will be run even if m is found.
* 'r' is a recipe that will be run if the memory isn't found.

Effect & Mechanics: Upon parsing this requirement, the parser checks the memory array for a memory called 'm'. If it is found, requirement is considered met. If it isn't found or the probability for failure has hit it will run the recipe 'r'.

= Algorithm Steps =

== AddKnowledge ==

Syntax: addKnowledge(x);

Arguments:
* 'x' can be any string.

Effect & Mechanics: Adds the 'x' token as a piece of knowledge in the knowledge array.

== AlterResource ==

Syntax: alterResource(x,y);

Arguments:
* 'x' is a resource name
* 'y' is an int describing quantity

Effect & Mechanics: Upon parsing this function, the parser modifies the quantity of resources available in the tribe.

Note: The 'y' value will be added to the current value in the tribe's bank. Use negative value to represent costs. (e.g. alterResource(gold,-20); in order to pay for a building)

== Attack ==

Syntax: attack();

Arguments: None.

Effect & Mechanics: It sends to previously selected members the 'tribe:attack' perception to attack a previously selected location. If the selected location is not an attackable entity they will simply move there and attack whatever is near.

== Gather ==

Syntax: gather();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected field and fires their 'tribe:gather' behavior.

== GoWork ==

Syntax: goWork(x);

Arguments:
* 'x' is an int defining the number of seconds the npcs should work for.

Effect & Mechanics: The 'goWork' function sends previously selected npcs to a previously selected location, set the npc buffer [Work_Duration] to 'x' and send 'tribe:work' behavior.

== Guard (Not available) ==

Note:
guard() function not implemented yet, use percept(selection, tribe:guard) instead.

Syntax: guard();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to guard the selected location. Members will just patrol the area and attack whatever poses a threat.

== LoadLocation ==

Syntax: loadLocation(x,y,z,r);

Arguments:
* 'x', 'y' and 'z' are a set of coordinates.
* 'r' is the location name.

Effect & Mechanics: add a new memory in the Database, adding a new location named "work" in the coordinates x,y,z.

== LocateMemory ==

Syntax: locateMemory(x,r);

Arguments:
* 'x' is a memory name.
* 'r' is a recipe to load if the memory 'x' isn't found.

Effect & Mechanics: It looks in the tribe's memory array for the memory called 'x' and loads it into the previous selected npc's buffers. It is vital to use it before basic functions like mine,gather,guard,attack that use the npc buffers to execute.

== LocateResource ==

Syntax: locateResource(x,r);

Arguments:
* 'x' is a resource name.
* 'r' the recipe to load if no resource 'x' is found

Effect & Mechanics: This function works like the above-mentioned 'locateMemory' function. The sole difference is that this function tries to locate resource 'x', and it case it fails it tries to locate memories 'mine' or 'field'. (which are the standard names of unprospected/undiscovered resource zones). In case nor 'mine' or 'field' are found, it sends the previous selected npcs to explore for them.

== LocateBuilding ==

Syntax: locateBuilding(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot on which there is an already constructed building. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

Example Tribe Script:

select(Worker,1);locateBuilding(Campfire);goWork(60);

== LocateBuildingSpot ==

Syntax: locateBuildingSpot(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot previously reserved via 'reserveBuildingSpot' function. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

This function also sets the building spot to INCONSTRUCTION. So a build command should be executed next.

The NPC can use the [[Behavior_Operations#Build Operation|Build Operation]] to build a building at the selected spot.

Example Tribe Script:

select(Worker,1);locateBuildingSpot(Campfire);percept(selection,tribe:build)

Example NPC Script:

<behavior name="DoBuild">
<locate obj="building_spot" />
<navigate />
<wait duration="$NBUFFER[Work_Duration]" />
<build />
<talk text="Nice work building this $NBUFFER[Building]" />
</behavior>
<react event="tribe:build" behavior="DoBuild" />

== Mate ==

Syntax: mate();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to their home and fires their 'tribe:breed' behavior.

Note: By default, the 'mate' functions requires no resources and has no checks. Use it in a recipe that checks that enough resources for breeding are available.

Examples:
select(any,1);
setBuffer(selection,Reproduce_Type,$member_type);
mate();
alterResource($REPRODUCTION_RESOURCE, -$REPRODUCTION_COST);

== Mine ==

Syntax: mine();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected mine and fires their 'tribe:mine' behavior.

== Percept ==

Syntax: percept(t,p);

Arguments:
* 't' is either selection or tribe
* 'p' is the perception to send

Effect & Mechanics: It sends a perception to previously selected members or to the tribe.

Examples:
select(any,1);
percept(selection,tribe:gather)
percept(tribe,tribe:flee)

== ReserveSpot ==

Syntax: reserveSpot(x,y,z,bname);

Arguments:
* 'x', 'y' and 'z' are coordinates in the same sector as the tribe
* 'bname' is the building name we want to reserve the spot for

Effect & Mechanics: This function is used so the scripter (you) can arrange the future village of the tribe. When creating a tribe, a recipe containing building spots should be wrote in order to pinpoint where building should be constructed in the future.

== Select ==

Syntax: select(x,y);

Arguments:
* 'x' is a tribe member type. Types can be crated using the [[Behavior_Operations#Reproduce_Operation|Reproduce Operation]]
* 'y' is an int defining the number of members to be selected.

Effect & Mechanics: The 'select' function is probably the most important algorithm step. It selects the members passed as arguments and keeps them in a temporary npc array so they can accept orders from the next algorithm steps. It actually works like selecting units and commanding them in a strategy game. After a 'select' function, all next algorithm steps apply to selected members only, until another 'select' command is issued or the recipe is completed.

Example:
// Will send 3 miners to mine for gold.
select(miner,3);
locateResource(gold,Explore);
mine();

== SetBuffer ==

Syntax: setBuffer(target,name,value);

Arguments:
* 'target' is either selection or tribe.
* 'name' is the name of the buffer to set.
* 'value' is the new value to set for Buffer.

For selection this resolve to NBUFFER[name] in recipes and $NBUFFER[name] in behaviors.
For tribes this resolve to TBUFFER[name] in recipes and $TBUFFER[name] in behaviors.

This set the buffers used by [[NPC Variables]] to replace buffers.

Example:

In an algorithm:
select(Worker,2);
setBuffer(selection,Work_Time,10);
percept(tribe:work);

In a NPC behavior:
<wait duration="$NBUFFER[Work_Time]" />

== SpawnMember ==
Syntax: spawnMember(x,y);

Arguments:
* 'x' is an integer and the ID of the master NPC to clone and spawn
* 'y' is a string identifying the type of member (example Warrior, Miner, Hunter, ...)

Effect & Mechanics: This function spawns a new member of the tribe, without requiring anything else, in contrast with mate() that requires an existing member to spawn another member. This function can be used to create the first member of the tribe.

Example:

"Consumer Evolve Tribe" recipe with requirements: tribesman(Warrior,1,Consumer Ancestor Spawn);

"Consumer Ancestor Spawn" recipe with no requirements and script: spawnMember(42, Warrior);

IMPORTANT: The master NPC ID, should be created in characters table + there must be an entry for this NPC in sc_npc_definitions table, with the AbstractTribesman. This will properly initialize the member of the tribe.

== Wait ==

Syntax: wait(x);

Arguments:
* 'x' is an float defining number seconds to halt recipe for.

Effect & Mechanics: This function sets the wait time for a recipe. By default, no recipes with a wait time bigger than 0 are reparsed. As a consequence, applying wait time to a recipe will make the parser halt the current recipe at the current algorithm step and parse other recipes that wait in line. The function will also fire the 'tribe:wait' reaction.

[[Category:Server Design]] [[Category:NPCClient Design]] [[Category:NPCClient Scripting]]

Tribe Scripting

2026-01-04T18:38:18Z

Talad: /* SpawnMember */

= Recipe Logic =

== Recipes ==
'''A recipe database entry'''
{| border="1"
!id
!name
!requirements
!algorithm
!persistent
|-
|used for db storing
|Name of the recipe
|requirement string containing all requirements
|algorithm string containing all algorithm steps
|If this flag is on, the recipe won't ever be deleted from the recipe tree. After parsing it, if no other recipe has a higher priority... it will be reparsed.
|}

== Usage of Recipes ==

Recipes is used to describe how [[tribes]] react. See [[Tribe Design]] for details.

On initialization, a tribal recipe is first loaded in respect of the information indicated by the 'tribal_recipe' field. (see [[TribesTable|tribes.sql]]). The tribal recipe is formed from 'Tribe Info' functions. (see below)

Based on those functions the npctype for each tribe is created and initial recipes are loaded.

Further on, each Recipe has two important sections: requirements and algorithm. Each of those two is represented by a long string (the maximum is set in the database to 1000 characters) of functions separated by a semi-colon ';'. Upon parsing the long string is split in respect of the semicolons (;) and the recipe manager analyzes each resulting function.

== Recipe-Tree Nodes ==

Inside a tribe object, recipes are stored as Recipe Tree Nodes. This class was created to facilitate the management of recipes and the way recipes are selected to be parsed.

All recipes are stored as leaves in a tree. This way we can always know their hierarchy and precedence.

Besides the obvious usage as a tree, recipe tree nodes also hold vital data for recipe parsing: last requirement parsed, last algorithm step parsed, remaining waiting time.

Let's consider an example of a tribe which has some building spots available and the task to build on those spots.

Having the tree above, it's easy to select the actions required to complete the task. We first get some more food. After that we get the required members, search for wood and stone, and finally build the buildings.

= Tribe Info =

== Brain ==

Syntax: brain(x);

Arguments:
* x brain eg. behaviour to use for the tribe.

Effect: Override the AbstractTribesman as the brain for the tribe.

For each tribe the server create an tribe_<tribe_id> behavior that inherit from the brain given i the brain command. If no brain entry is given the tribe behaviour will use the AbstractTribesman behaviour. This can be used to create tribes with special behaviours.

== Aggressivity ==

Syntax: aggressivity(x);

Arguments:
* x in { warlike, neutral, peaceful }

Effect: Decides the way the tribe reacts to other entities around it's members:
* Warlike -- Attack anything on sight.
* Neutral -- Attack only if members are attacked.
* Peaceful -- If tribe members are attack they flee, trying to escape.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype in respect of this function's argument.

== Growth ==
Syntax: growth(x)

Arguments:

* x in ?

Not implemented , at the moment all tribes have "conservatory" as value

== Unity ==
Syntax: unity(x)

Arguments:

* x in {*, cowards}

At the moment anything but "cowards" will trigger one member of the tribe to help another member when attacked.

== SleepPeriod ==

Syntax: sleepPeriod(x);

Arguments: x in { diurnal, nocturnal, nosleep }

{|
|-
|diurnal
|22:00 - 06:00
|Sleep during night
|-
|nocturnal
|08:00 - 18:00
|Sleep during day
|}

Effect: Makes the tribe members sleep at the given period of day.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype. The reaction should react to timeofday perceptions.

== LoadRecipe ==

Syntax: loadRecipe(x); loadRecipe(x,distributed);

Arguments:
* 'x' is a Recipe Name

Effect: Loads a recipe into the recipe tree. The new recipe's priority will be the current recipe's priority + 1.

== LoadCyclicRecipe ==

Syntax: loadCyclicRecipe(x,t);

Arguments:
* 'x' is a Recipe Name
* 't' is an int, representing the number of ticks (milliseconds) between recipe executions

Effect: Loads a recipe into the recipe tree once every 't' ticks, with highest priority.

= Requirements =

== Building ==

Syntax: building(x,y,r);

Arguments:
* 'x' is a building name.
* 'y' is an int defining the quantity of buildings needed.
* 'r' is the recipe needed to get the building if not available

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the building 'x' of quantity 'y'.

== Tribesman ==

Syntax: tribesman(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' regardless if they are busy or doing something else. If 'y' members are found, the requirement is considered met.

== TribesmanIdle ==

Syntax: tribesmanidle(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' with the current behavior equal to the tribe's idle behavior. (e.g. "do nothing" behavior) If 'y' members are found idle, the requirement is considered met.

== Resource ==

Syntax: resource(x,y,r);

Arguments:
* x is the resource name
* y is the resource quantity required
* r is the recipe needed to get the resource if not available

Effect & Mechanics: The tribal object checks for a 'y' quantity of 'x' resource. If this quantity is found then the resource is considered complete. $RESOURCE_AREA, $REPRODUCTION_RESOURCE and $REPRODUCTION_COST are valid variables.

Judging by the way natural resources are defined, any string declared in natural_resources.sql as a resource can be parsed and mined by the tribe. By default, any new mine found by the tribesmen is stored as a memory named 'mine'. Upon it's first mining action done on the 'mine' memory, a reward is granted to the npc. When the NPC gets home and gives that to the tribal object, the memory 'mine' is renamed after the reward. In conclusion, having a resource named 'Space Shuttle' is valid and works.

Note: The resource requirement just checks if enough resources are available. Use 'alterResource' function in your recipes in order to actually substract resource from the tribe bank.

== Knowledge ==

Syntax: knowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: As described in the [[Tribe Design]] document, knowledge are tokens that keep track on technologies developed by the tribe. It's valid to request any string as long as it would be possible for the tribe to develop the knowledge. Otherwise the requirement will never be met.

== Item ==

Syntax: item(x,y);

Arguments:
* 'x' is an item/building name.
* 'y' is an int defining the quantity of items needed.

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the item 'x' of quantity 'y'.

== Recipe ==

Syntax: recipe(x,y);

Arguments:
* 'x' is a recipe name.
* 'y' is an int defining the quantity of recipes needed.

Effect & Mechanics: Upon parsing this requirement, the parser just adds an 'y' number of 'x' recipes to the recipe tree.

This requirement isn't quite practical and should be avoided.

== Trader (Not available) ==

Syntax: trader(x);

Arguments:
* 'x' is an item name

Effect: This requirement should check the traders array for a nearby trader giving item 'x'.

== Memory ==

Syntax: memory(m,p,r);

Arguments:
* 'm' is a memory name
* 'p' is a probability between 0-100. Setting this to 10 make it 10% probably that the r will be run even if m is found.
* 'r' is a recipe that will be run if the memory isn't found.

Effect & Mechanics: Upon parsing this requirement, the parser checks the memory array for a memory called 'm'. If it is found, requirement is considered met. If it isn't found or the probability for failure has hit it will run the recipe 'r'.

= Algorithm Steps =

== AddKnowledge ==

Syntax: addKnowledge(x);

Arguments:
* 'x' can be any string.

Effect & Mechanics: Adds the 'x' token as a piece of knowledge in the knowledge array.

== AlterResource ==

Syntax: alterResource(x,y);

Arguments:
* 'x' is a resource name
* 'y' is an int describing quantity

Effect & Mechanics: Upon parsing this function, the parser modifies the quantity of resources available in the tribe.

Note: The 'y' value will be added to the current value in the tribe's bank. Use negative value to represent costs. (e.g. alterResource(gold,-20); in order to pay for a building)

== Attack ==

Syntax: attack();

Arguments: None.

Effect & Mechanics: It sends to previously selected members the 'tribe:attack' perception to attack a previously selected location. If the selected location is not an attackable entity they will simply move there and attack whatever is near.

== Gather ==

Syntax: gather();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected field and fires their 'tribe:gather' behavior.

== GoWork ==

Syntax: goWork(x);

Arguments:
* 'x' is an int defining the number of seconds the npcs should work for.

Effect & Mechanics: The 'goWork' function sends previously selected npcs to a previously selected location, set the npc buffer [Work_Duration] to 'x' and send 'tribe:work' behavior.

== Guard (Not available) ==

Note:
guard() function not implemented yet, use percept(selection, tribe:guard) instead.

Syntax: guard();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to guard the selected location. Members will just patrol the area and attack whatever poses a threat.

== LoadLocation ==

Syntax: loadLocation(x,y,z,r);

Arguments:
* 'x', 'y' and 'z' are a set of coordinates.
* 'r' is the location name.

Effect & Mechanics: add a new memory in the Database, adding a new location named "work" in the coordinates x,y,z.

== LocateMemory ==

Syntax: locateMemory(x,r);

Arguments:
* 'x' is a memory name.
* 'r' is a recipe to load if the memory 'x' isn't found.

Effect & Mechanics: It looks in the tribe's memory array for the memory called 'x' and loads it into the previous selected npc's buffers. It is vital to use it before basic functions like mine,gather,guard,attack that use the npc buffers to execute.

== LocateResource ==

Syntax: locateResource(x,r);

Arguments:
* 'x' is a resource name.
* 'r' the recipe to load if no resource 'x' is found

Effect & Mechanics: This function works like the above-mentioned 'locateMemory' function. The sole difference is that this function tries to locate resource 'x', and it case it fails it tries to locate memories 'mine' or 'field'. (which are the standard names of unprospected/undiscovered resource zones). In case nor 'mine' or 'field' are found, it sends the previous selected npcs to explore for them.

== LocateBuilding ==

Syntax: locateBuilding(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot on which there is an already constructed building. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

Example Tribe Script:

select(Worker,1);locateBuilding(Campfire);goWork(60);

== LocateBuildingSpot ==

Syntax: locateBuildingSpot(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot previously reserved via 'reserveBuildingSpot' function. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

This function also sets the building spot to INCONSTRUCTION. So a build command should be executed next.

The NPC can use the [[Behavior_Operations#Build Operation|Build Operation]] to build a building at the selected spot.

Example Tribe Script:

select(Worker,1);locateBuildingSpot(Campfire);percept(selection,tribe:build)

Example NPC Script:

<behavior name="DoBuild">
<locate obj="building_spot" />
<navigate />
<wait duration="$NBUFFER[Work_Duration]" />
<build />
<talk text="Nice work building this $NBUFFER[Building]" />
</behavior>
<react event="tribe:build" behavior="DoBuild" />

== Mate ==

Syntax: mate();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to their home and fires their 'tribe:breed' behavior.

Note: By default, the 'mate' functions requires no resources and has no checks. Use it in a recipe that checks that enough resources for breeding are available.

Examples:
select(any,1);
setBuffer(selection,Reproduce_Type,$member_type);
mate();
alterResource($REPRODUCTION_RESOURCE, -$REPRODUCTION_COST);

== Mine ==

Syntax: mine();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected mine and fires their 'tribe:mine' behavior.

== Percept ==

Syntax: percept(t,p);

Arguments:
* 't' is either selection or tribe
* 'p' is the perception to send

Effect & Mechanics: It sends a perception to previously selected members or to the tribe.

Examples:
select(any,1);
percept(selection,tribe:gather)
percept(tribe,tribe:flee)

== ReserveSpot ==

Syntax: reserveSpot(x,y,z,bname);

Arguments:
* 'x', 'y' and 'z' are coordinates in the same sector as the tribe
* 'bname' is the building name we want to reserve the spot for

Effect & Mechanics: This function is used so the scripter (you) can arrange the future village of the tribe. When creating a tribe, a recipe containing building spots should be wrote in order to pinpoint where building should be constructed in the future.

== Select ==

Syntax: select(x,y);

Arguments:
* 'x' is a tribe member type. Types can be crated using the [[Behavior_Operations#Reproduce_Operation|Reproduce Operation]]
* 'y' is an int defining the number of members to be selected.

Effect & Mechanics: The 'select' function is probably the most important algorithm step. It selects the members passed as arguments and keeps them in a temporary npc array so they can accept orders from the next algorithm steps. It actually works like selecting units and commanding them in a strategy game. After a 'select' function, all next algorithm steps apply to selected members only, until another 'select' command is issued or the recipe is completed.

Example:
// Will send 3 miners to mine for gold.
select(miner,3);
locateResource(gold,Explore);
mine();

== SetBuffer ==

Syntax: setBuffer(target,name,value);

Arguments:
* 'target' is either selection or tribe.
* 'name' is the name of the buffer to set.
* 'value' is the new value to set for Buffer.

For selection this resolve to NBUFFER[name] in recipes and $NBUFFER[name] in behaviors.
For tribes this resolve to TBUFFER[name] in recipes and $TBUFFER[name] in behaviors.

This set the buffers used by [[NPC Variables]] to replace buffers.

Example:

In an algorithm:
select(Worker,2);
setBuffer(selection,Work_Time,10);
percept(tribe:work);

In a NPC behavior:
<wait duration="$NBUFFER[Work_Time]" />

== SpawnMember ==
Syntax: spawnMember(x);

Arguments:
* 'x' is an integer and the ID of the master NPC to clone and spawn

Effect & Mechanics: This function spawns a new member of the tribe, without requiring anything else, in contrast with mate() that requires an existing member to spawn another member. This function can be used to create the first member of the tribe.

Example:

"Consumer Evolve Tribe" recipe with requirements: tribesman(number,1,Consumer Ancestor Spawn);

"Consumer Ancestor Spawn" recipe with no requirements and script: spawnMember(42);

IMPORTANT: The master NPC ID, should be created in characters table + there must be an entry for this NPC in sc_npc_definitions table, with the AbstractTribesman. This will properly initialize the member of the tribe.

== Wait ==

Syntax: wait(x);

Arguments:
* 'x' is an float defining number seconds to halt recipe for.

Effect & Mechanics: This function sets the wait time for a recipe. By default, no recipes with a wait time bigger than 0 are reparsed. As a consequence, applying wait time to a recipe will make the parser halt the current recipe at the current algorithm step and parse other recipes that wait in line. The function will also fire the 'tribe:wait' reaction.

[[Category:Server Design]] [[Category:NPCClient Design]] [[Category:NPCClient Scripting]]

Tribe Scripting

2026-01-03T23:16:08Z

Talad: /* Algorithm Steps */

= Recipe Logic =

== Recipes ==
'''A recipe database entry'''
{| border="1"
!id
!name
!requirements
!algorithm
!persistent
|-
|used for db storing
|Name of the recipe
|requirement string containing all requirements
|algorithm string containing all algorithm steps
|If this flag is on, the recipe won't ever be deleted from the recipe tree. After parsing it, if no other recipe has a higher priority... it will be reparsed.
|}

== Usage of Recipes ==

Recipes is used to describe how [[tribes]] react. See [[Tribe Design]] for details.

On initialization, a tribal recipe is first loaded in respect of the information indicated by the 'tribal_recipe' field. (see [[TribesTable|tribes.sql]]). The tribal recipe is formed from 'Tribe Info' functions. (see below)

Based on those functions the npctype for each tribe is created and initial recipes are loaded.

Further on, each Recipe has two important sections: requirements and algorithm. Each of those two is represented by a long string (the maximum is set in the database to 1000 characters) of functions separated by a semi-colon ';'. Upon parsing the long string is split in respect of the semicolons (;) and the recipe manager analyzes each resulting function.

== Recipe-Tree Nodes ==

Inside a tribe object, recipes are stored as Recipe Tree Nodes. This class was created to facilitate the management of recipes and the way recipes are selected to be parsed.

All recipes are stored as leaves in a tree. This way we can always know their hierarchy and precedence.

Besides the obvious usage as a tree, recipe tree nodes also hold vital data for recipe parsing: last requirement parsed, last algorithm step parsed, remaining waiting time.

Let's consider an example of a tribe which has some building spots available and the task to build on those spots.

Having the tree above, it's easy to select the actions required to complete the task. We first get some more food. After that we get the required members, search for wood and stone, and finally build the buildings.

= Tribe Info =

== Brain ==

Syntax: brain(x);

Arguments:
* x brain eg. behaviour to use for the tribe.

Effect: Override the AbstractTribesman as the brain for the tribe.

For each tribe the server create an tribe_<tribe_id> behavior that inherit from the brain given i the brain command. If no brain entry is given the tribe behaviour will use the AbstractTribesman behaviour. This can be used to create tribes with special behaviours.

== Aggressivity ==

Syntax: aggressivity(x);

Arguments:
* x in { warlike, neutral, peaceful }

Effect: Decides the way the tribe reacts to other entities around it's members:
* Warlike -- Attack anything on sight.
* Neutral -- Attack only if members are attacked.
* Peaceful -- If tribe members are attack they flee, trying to escape.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype in respect of this function's argument.

== Growth ==
Syntax: growth(x)

Arguments:

* x in ?

Not implemented , at the moment all tribes have "conservatory" as value

== Unity ==
Syntax: unity(x)

Arguments:

* x in {*, cowards}

At the moment anything but "cowards" will trigger one member of the tribe to help another member when attacked.

== SleepPeriod ==

Syntax: sleepPeriod(x);

Arguments: x in { diurnal, nocturnal, nosleep }

{|
|-
|diurnal
|22:00 - 06:00
|Sleep during night
|-
|nocturnal
|08:00 - 18:00
|Sleep during day
|}

Effect: Makes the tribe members sleep at the given period of day.

Mechanics: Upon parsing this function, an extra reaction is added to the tribal npctype. The reaction should react to timeofday perceptions.

== LoadRecipe ==

Syntax: loadRecipe(x); loadRecipe(x,distributed);

Arguments:
* 'x' is a Recipe Name

Effect: Loads a recipe into the recipe tree. The new recipe's priority will be the current recipe's priority + 1.

== LoadCyclicRecipe ==

Syntax: loadCyclicRecipe(x,t);

Arguments:
* 'x' is a Recipe Name
* 't' is an int, representing the number of ticks (milliseconds) between recipe executions

Effect: Loads a recipe into the recipe tree once every 't' ticks, with highest priority.

= Requirements =

== Building ==

Syntax: building(x,y,r);

Arguments:
* 'x' is a building name.
* 'y' is an int defining the quantity of buildings needed.
* 'r' is the recipe needed to get the building if not available

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the building 'x' of quantity 'y'.

== Tribesman ==

Syntax: tribesman(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' regardless if they are busy or doing something else. If 'y' members are found, the requirement is considered met.

== TribesmanIdle ==

Syntax: tribesmanidle(x,y,r);

Arguments:
* x is a tribesman type (types are not well-defined at the moment). Keyword 'any' is accepted too in order to define any member.
* y is an int defining the number of tribesmen needed
*r is the recipe needed to spawn a new member if not enough members are found

Effect & Mechanics: The tribal object checks for a number 'y' of tribesman typed 'x' with the current behavior equal to the tribe's idle behavior. (e.g. "do nothing" behavior) If 'y' members are found idle, the requirement is considered met.

== Resource ==

Syntax: resource(x,y,r);

Arguments:
* x is the resource name
* y is the resource quantity required
* r is the recipe needed to get the resource if not available

Effect & Mechanics: The tribal object checks for a 'y' quantity of 'x' resource. If this quantity is found then the resource is considered complete. $RESOURCE_AREA, $REPRODUCTION_RESOURCE and $REPRODUCTION_COST are valid variables.

Judging by the way natural resources are defined, any string declared in natural_resources.sql as a resource can be parsed and mined by the tribe. By default, any new mine found by the tribesmen is stored as a memory named 'mine'. Upon it's first mining action done on the 'mine' memory, a reward is granted to the npc. When the NPC gets home and gives that to the tribal object, the memory 'mine' is renamed after the reward. In conclusion, having a resource named 'Space Shuttle' is valid and works.

Note: The resource requirement just checks if enough resources are available. Use 'alterResource' function in your recipes in order to actually substract resource from the tribe bank.

== Knowledge ==

Syntax: knowledge(x);

Arguments: 'x' can be any string.

Effect & Mechanics: As described in the [[Tribe Design]] document, knowledge are tokens that keep track on technologies developed by the tribe. It's valid to request any string as long as it would be possible for the tribe to develop the knowledge. Otherwise the requirement will never be met.

== Item ==

Syntax: item(x,y);

Arguments:
* 'x' is an item/building name.
* 'y' is an int defining the quantity of items needed.

Effect & Mechanics: At the moment, items are 'magically' stored inside the tribal object. This object keeps track on items and buildings with the 'Asset' structure. 'x' can be any string with the condition that the tribe can actually gain the requested asset. Otherwise the requirement will never be met. Upon parsing this requirement, the tribal object checks it's asset arrays for the item 'x' of quantity 'y'.

== Recipe ==

Syntax: recipe(x,y);

Arguments:
* 'x' is a recipe name.
* 'y' is an int defining the quantity of recipes needed.

Effect & Mechanics: Upon parsing this requirement, the parser just adds an 'y' number of 'x' recipes to the recipe tree.

This requirement isn't quite practical and should be avoided.

== Trader (Not available) ==

Syntax: trader(x);

Arguments:
* 'x' is an item name

Effect: This requirement should check the traders array for a nearby trader giving item 'x'.

== Memory ==

Syntax: memory(m,p,r);

Arguments:
* 'm' is a memory name
* 'p' is a probability between 0-100. Setting this to 10 make it 10% probably that the r will be run even if m is found.
* 'r' is a recipe that will be run if the memory isn't found.

Effect & Mechanics: Upon parsing this requirement, the parser checks the memory array for a memory called 'm'. If it is found, requirement is considered met. If it isn't found or the probability for failure has hit it will run the recipe 'r'.

= Algorithm Steps =

== AddKnowledge ==

Syntax: addKnowledge(x);

Arguments:
* 'x' can be any string.

Effect & Mechanics: Adds the 'x' token as a piece of knowledge in the knowledge array.

== AlterResource ==

Syntax: alterResource(x,y);

Arguments:
* 'x' is a resource name
* 'y' is an int describing quantity

Effect & Mechanics: Upon parsing this function, the parser modifies the quantity of resources available in the tribe.

Note: The 'y' value will be added to the current value in the tribe's bank. Use negative value to represent costs. (e.g. alterResource(gold,-20); in order to pay for a building)

== Attack ==

Syntax: attack();

Arguments: None.

Effect & Mechanics: It sends to previously selected members the 'tribe:attack' perception to attack a previously selected location. If the selected location is not an attackable entity they will simply move there and attack whatever is near.

== Gather ==

Syntax: gather();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected field and fires their 'tribe:gather' behavior.

== GoWork ==

Syntax: goWork(x);

Arguments:
* 'x' is an int defining the number of seconds the npcs should work for.

Effect & Mechanics: The 'goWork' function sends previously selected npcs to a previously selected location, set the npc buffer [Work_Duration] to 'x' and send 'tribe:work' behavior.

== Guard (Not available) ==

Note:
guard() function not implemented yet, use percept(selection, tribe:guard) instead.

Syntax: guard();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to guard the selected location. Members will just patrol the area and attack whatever poses a threat.

== LoadLocation ==

Syntax: loadLocation(x,y,z,r);

Arguments:
* 'x', 'y' and 'z' are a set of coordinates.
* 'r' is the location name.

Effect & Mechanics: add a new memory in the Database, adding a new location named "work" in the coordinates x,y,z.

== LocateMemory ==

Syntax: locateMemory(x,r);

Arguments:
* 'x' is a memory name.
* 'r' is a recipe to load if the memory 'x' isn't found.

Effect & Mechanics: It looks in the tribe's memory array for the memory called 'x' and loads it into the previous selected npc's buffers. It is vital to use it before basic functions like mine,gather,guard,attack that use the npc buffers to execute.

== LocateResource ==

Syntax: locateResource(x,r);

Arguments:
* 'x' is a resource name.
* 'r' the recipe to load if no resource 'x' is found

Effect & Mechanics: This function works like the above-mentioned 'locateMemory' function. The sole difference is that this function tries to locate resource 'x', and it case it fails it tries to locate memories 'mine' or 'field'. (which are the standard names of unprospected/undiscovered resource zones). In case nor 'mine' or 'field' are found, it sends the previous selected npcs to explore for them.

== LocateBuilding ==

Syntax: locateBuilding(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot on which there is an already constructed building. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

Example Tribe Script:

select(Worker,1);locateBuilding(Campfire);goWork(60);

== LocateBuildingSpot ==

Syntax: locateBuildingSpot(x);

Arguments:
* 'x' is a building name.

Effect & Mechanics: This functions locates a building spot previously reserved via 'reserveBuildingSpot' function. It searches for building spots in the asset array and set the selected assess in the npc "building_spot" variable.

NBUFFER[Building] is set to x, and NBUFFER[Work_Duration] is set to the building time of the building.

This function also sets the building spot to INCONSTRUCTION. So a build command should be executed next.

The NPC can use the [[Behavior_Operations#Build Operation|Build Operation]] to build a building at the selected spot.

Example Tribe Script:

select(Worker,1);locateBuildingSpot(Campfire);percept(selection,tribe:build)

Example NPC Script:

<behavior name="DoBuild">
<locate obj="building_spot" />
<navigate />
<wait duration="$NBUFFER[Work_Duration]" />
<build />
<talk text="Nice work building this $NBUFFER[Building]" />
</behavior>
<react event="tribe:build" behavior="DoBuild" />

== Mate ==

Syntax: mate();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to their home and fires their 'tribe:breed' behavior.

Note: By default, the 'mate' functions requires no resources and has no checks. Use it in a recipe that checks that enough resources for breeding are available.

Examples:
select(any,1);
setBuffer(selection,Reproduce_Type,$member_type);
mate();
alterResource($REPRODUCTION_RESOURCE, -$REPRODUCTION_COST);

== Mine ==

Syntax: mine();

Arguments:
* None.

Effect & Mechanics: It sends previously selected members to a previously selected mine and fires their 'tribe:mine' behavior.

== Percept ==

Syntax: percept(t,p);

Arguments:
* 't' is either selection or tribe
* 'p' is the perception to send

Effect & Mechanics: It sends a perception to previously selected members or to the tribe.

Examples:
select(any,1);
percept(selection,tribe:gather)
percept(tribe,tribe:flee)

== ReserveSpot ==

Syntax: reserveSpot(x,y,z,bname);

Arguments:
* 'x', 'y' and 'z' are coordinates in the same sector as the tribe
* 'bname' is the building name we want to reserve the spot for

Effect & Mechanics: This function is used so the scripter (you) can arrange the future village of the tribe. When creating a tribe, a recipe containing building spots should be wrote in order to pinpoint where building should be constructed in the future.

== Select ==

Syntax: select(x,y);

Arguments:
* 'x' is a tribe member type. Types can be crated using the [[Behavior_Operations#Reproduce_Operation|Reproduce Operation]]
* 'y' is an int defining the number of members to be selected.

Effect & Mechanics: The 'select' function is probably the most important algorithm step. It selects the members passed as arguments and keeps them in a temporary npc array so they can accept orders from the next algorithm steps. It actually works like selecting units and commanding them in a strategy game. After a 'select' function, all next algorithm steps apply to selected members only, until another 'select' command is issued or the recipe is completed.

Example:
// Will send 3 miners to mine for gold.
select(miner,3);
locateResource(gold,Explore);
mine();

== SetBuffer ==

Syntax: setBuffer(target,name,value);

Arguments:
* 'target' is either selection or tribe.
* 'name' is the name of the buffer to set.
* 'value' is the new value to set for Buffer.

For selection this resolve to NBUFFER[name] in recipes and $NBUFFER[name] in behaviors.
For tribes this resolve to TBUFFER[name] in recipes and $TBUFFER[name] in behaviors.

This set the buffers used by [[NPC Variables]] to replace buffers.

Example:

In an algorithm:
select(Worker,2);
setBuffer(selection,Work_Time,10);
percept(tribe:work);

In a NPC behavior:
<wait duration="$NBUFFER[Work_Time]" />

== SpawnMember ==
Syntax: spawnMember(x);

Arguments:
* 'x' is an integer and the ID of the master NPC to clone and spawn

Effect & Mechanics: This function spawns a new member of the tribe, without requiring anything else, in contrast with mate() that requires an existing member to spawn another member. This function can be used to create the first member of the tribe.

Example:

"Consumer Evolve Tribe" recipe with requirements: tribesman(number,1,Consumer Ancestor Spawn);

"Consumer Ancestor Spawn" recipe with no requirements and script: spawnMember(156);

== Wait ==

Syntax: wait(x);

Arguments:
* 'x' is an float defining number seconds to halt recipe for.

Effect & Mechanics: This function sets the wait time for a recipe. By default, no recipes with a wait time bigger than 0 are reparsed. As a consequence, applying wait time to a recipe will make the parser halt the current recipe at the current algorithm step and parse other recipes that wait in line. The function will also fire the 'tribe:wait' reaction.

[[Category:Server Design]] [[Category:NPCClient Design]] [[Category:NPCClient Scripting]]

PSUnreal GDB Debug Hints

2026-01-01T22:37:26Z

Talad:

=== psItem ===
print (TCHAR*)item->current_stats->name

=== psCharacter ===
print (TCHAR*)client->name

== Jetbrains Rider debug ==
To have a conditional breakpoint for an FString use this: name==L"Trepor"

Players Guide/Magic

2025-12-29T22:37:05Z

Talad: /* Enchanted items */

The magical energy in [[Yliakum]] is divided into six ways of arcane: [[Players Guide/Magic#Crystal Way | Crystal Way]], [[Players Guide/Magic#Azure Way | Azure Way]], [[Players Guide/Magic#Red Way | Red Way]], [[Players Guide/Magic#Dark Way | Dark Way]], [[Players Guide/Magic#Brown Way | Brown Way]] and [[Players Guide/Magic#Blue Way | Blue Way]].
[[Image:Magecasting.jpeg|thumb|300px]]

==The Ways of Magic==
[[Image:Ways.png|left|150px]]
Each Way has a particular color and a [[Ingame Help#Stats and Skills | mental stat]] associated. The three mental stats linked to magic are: [[Players Guide#Stats and Skills|Charisma]], [[Players Guide#Stats and Skills|Intelligence]] and [[Players Guide#Stats and Skills|Willpower]]. They give bonuses to the casting of spells that pertain to that way.

Each way is composed of a set of spells and each spell can be casted by a wizard thanks to the combination of a set of runes, called [[Players Guide/Magic#The Glyphs | "glyphs"]]. The spells of a particular Way are related to the same energy and the same concepts (Water, Air or Healing, Drain). They produce either a direct damage or a damage over time on the opponent.

The ways are all somewhat linked by relationship of opposition or attraction. A specific way opposes another and is "friendly" with two others (ie. Crystal Way opposes Dark Way and is friendly with Blue and Azure Way).
Therefor, each spell giving a buff for a given time will provide at least a small way resistance (ie. Casting a Red Way "Strength" spell on yourself will also protect you slightly againt Blue Way).

----

===Crystal Way (CW)===
Users of this Way, get the pure energy of the [[Azure Sun|Crystal]], more directly than all other Ways. Famous for the ability to heal, and cure the most terrible wounds, people have said that if you reach a great knowledge, you can even bring back a person from death. Nonetheless there are many powerful offensive spells, particularly effective against evil and dark creatures. While warriors and farmers with injured animals are more then happy to see these practitioners around; around most towns people feel the appearance of these practitioners is a bad omen of bad times to come.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:CrystalWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| White || Energy, Life and Light || Buff Self & Allies, Direct Damage, Direct Healing || Charisma || Opposed to: Dark Way
Friendly with: Blue & Azure Way
|}

===Dark Way (DW)===
This Way is one that conquers more myth then any of the others. Its practitioners have a history of being the most innovative of any practitioners of the Ways of Magic, but with all innovation there is both good and bad. It's well known that many disasters and epidemics were caused by the adepts of this ancient Way. Holding some spells with terrifying effects, things can become even worse if you lose the control of its power. Some spells enable the control of horrific creatures, such as undead, demons and spirits, whilst some enable the caster to control objects and people in a subtle manner at distance.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:DarkWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Black || Entropy, Death and Darkness || Fear & Debuff, Drain, Direct Damage and Damage Over Time || Charisma || Opposed to: Crystal Way
Friendly with: Brown & Red Way
|}

===Azure Way (AW)===
Basically a sneaky and insidious energy, the Azure Way can control the will, the perceptions and the intentions of any intelligent being. It's power comes from the deep knowledge of the mind and the way to influence it, but it relies also on the mind's potential to influence the surrounding areas and objects, particularly all that is related to the air element.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:AzureWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Light Blue || Mind, Illusion and Air element ||Charm & Buff NPCs, Paralyzation, Minor Direct Damage and Damage Over Time || Will || Opposed to: Brown Way
Friendly with: Crystal & Red Way
|}

===Red Way (RW)===
The spellcaster is able to invoke the power of Chaos, and to bend to his/her/kra's will the devastating fury of fire, summoning it for its both damaging and purifying qualities. Spells of the Red Way can also instil courage and strength into companions or other creatures. Most spells in this Way are fire related, and the majority of metal workers have knowledge of it.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:RedWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Red || Strength, Chaos & Fire element||Major Direct Damage, Combat Buffs|| Will || Opposed to: Blue Way
Friendly with: Azure & Dark Way
|}

===Blue Way (BlW)===
Many diseases and poisons would be incurable without the help of the spells of this Way. The offensive and defensive potential of this art reside mainly on the control of the water element, but also of cold and ice that are strictly related to it. Equally inestimable are the divination spells that can provide very useful information on the past, present and future.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BlueWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Blue || Divination, Purification and Water element ||Immobilize, Major Damage Over Time, Healing Over Time, Polymorph|| Intelligence ||Opposed to: Red Way
Friendly with: Brown & Crystal Way
|}

===Brown Way (BrW)===
The glyphs of this Way give to the wizard the ability to cast different protective spells, to summon natural creatures and some monsters and to influence their will. This Way is really close to the element of Earth and can control all that's related to it. Users can call nature spirits for assistance or mark themselves and allies as friends of nature.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BrownWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Brown || Nature, Protective magic and Earth element ||Defensive Buff, Summon Monster, Direct Damage, Immobilization, Minor Polymorph|| Intelligence ||Opposed to: Azure Way
Friendly with: Blue & Dark Way
|}

==Casting a Spell==
===The Glyphs===
At the beginning of [[Players Guide/Yliakum History | Yliakum History]], the [[God|god]] [[Talad]], forged pure magical energy into shapes called "Glyphs". They form the base of Yliakum magic.

* No spell can be casted without a glyph.

They are found in nature with no real explanation, no one knows exactly why they form but when some type of energy is strongly present in one place a glyph can form. Glyphs patterns appear on very different materials from a leaf to the fur of an animal and usually on any type of rock.

During the centuries many glyphs have been found and studied by the wizards. They discovered that each glyph can create a spell effect and that several glyphs can be combined to obtain greater effects. To simplify casting of spells, the glyphs are associated with a concept (ie. "Weight") and wizards combine those concepts to form new spells (ie. "Weight" and "Negate" to become very light).

Nowadays, glyphs can be found rendering services to the people of Yliakum or can be bought to mages like [[Levrus Dahrenn]] in the [[Magic Shop | magic shop]] for the more basic of them. The more rare and powerfull glyphs can be obtained by joining a Way Circle (school of magic) and follow its path to the Mastery of a particular Way.

* The glyphs purchased or rewarded will appear in your [[Ingame Help#Inventory Window | Inventory]] and be visible in the Glyphs Window in your [[Ingame Help#Spell Book Window | Spell Book]].

[[File:Glyphs.jpg|500px]]

===Purification===
To use a glyph, the wizard must apply a process of Purification, which take some time. The Purification establish a strong link in between the wizard and his glyph. If he dies, the glyphs will be taken to the [[Death|Death Realm]] with him. A wizard can trade a glyph, but the recipient will need to purify the glyph as well to create a new magic link and be able to use it.

* To purify a glyph, open the Glyph window from your Spell Book.
* Drag the glyph and drop it on the button called: '''Purify'''.
* When the Purification is done, you will see a message in your Chat Window > System Tab and your glyph will be surrounded of a white aura.

===Researching a Spell===
[[Image:SpellbookVen.jpg|300px|thumb|left]]
Once you have one or more glyphs, you can start to research spells. To be discovred, a spell can ask one glyph or a combinaison of up to 3 glyphs.

Shown on this pic is the glyph window of your Spell Book. The six main boxes will content the glyphs of the six ways of magic. The small row of boxes at the bottom of the window is where you put glyphs in order to combine or purify them.
* To discover a spell, drag one or several glyphs in the small row of boxes at the bottom of the window and hit the button called: '''Research'''.
* When you effectivly discovred a spell, its name and description will appear.
* Once discovred, the spell will automatically be added in your Spell Book. You wont have to research it again to cast it.

In this example, the Blue Way glyph "Cold" has been placed in the box and the wizard has discovred the spell called "Freeze".
* If you fail to discover a spell it might be for several raison : the combinaison of glyphs isn't right; you have not trained that way of magic high enough; or the glyph isn't purified.
Researching a spell is dangerous for the wizard. In effect, it ask a lot of mental focus and the strong magical energy at work may wound an unwary magician.

===Casting===
There are two great categories of spells available to the wizards: the enhancing spells that we call "buffs" and the attack spells.

The enhancing spells like "Rock Armor" (Brown Way) are made to be cast on the wizard. They enhance one health or stamina or increase one defensive ability. Some of those spells can be cast on friends, like "Life Infusion" (CW).

The attack spells like "Flame Burst" (RW) are made to defeat enemies. Some are efficient in close range, some in very long range. Those spells can be cast on players too in case of [[General FAQ#Will there be Player vs. Player combat in PlaneShift?|PvP]] (player versus player).

The process to cast a spell is as follow:
* Select your character or an enemy [[Non-Player Character|NPC]]
* Open your spell book, select the spell you wish to cast and click '''Cast Spell'''.
There is many ways to make this operation less long. The quickest one is to create a [[Ingame Help#Shortcuts Window|shortcut]] of the spell you plan to use a lot.
* Once you clicked on the chosen spell, a count down window will appear. When it is finished, the spell will be cast.

[[Image:magepower.jpeg|left|thumb|400px]] [[Image:Magered.jpg|center|thumb|350px]]

==Magic Mechanism==

===Type of Damage===

Spells and Magical effects can have different type of effects:

'''Direct Damage''' (DD): direct damage is applied as soon as the spell has been cast. Red Way offensive spells usually deal direct damage.

'''Damage over Time''' (DoT): this damage is applied over a period of time. Starting from when the spells has been successfully cast and until the spell duration runs out, the target HPs are constantly reduced. Blue Way offensive spells usually deal damage over time. This type of damage usually deal more damage than an equivalent realm spell, on the other side the duration can allow the target to try to heal itself or dispel the offensive spell.

===Damage and Saving Throws===
When a spell deals damage may allow the opponent to roll a ''saving throw'' to reduce the amount of damage sustained; this ''saving throw'' is made by the server confronting the caster and the target knowledge of the spell's magic way (e.g. Crystal Magic) plus a random factor: the higher is the target's knowledge of the way the higher is the chance to succeed the roll. When a target successfully roll the save the spell damage is usually halved.
If a spell which deals damage does not allow for a ''saving throw'' roll, that spell will usually deal about 70% less damage than an equivalent spell (same realm and same magic way).

<div style="background: #efe; padding: 4px 4px; width: 1000px">
[[Image:Fountain.png|40px]] '''Tip: The higher is your knowledge in a way the higher is your chance to counter or avoid damage and effects of the same way.'''
</div>

===Magic Resistance===
...

===Spell Power (KFactor)===
''(under construction)''
The spell caster can decide to channel more mana into casting by setting the additional spell power, allowing the caster to cast a more powerful spell.

The additional spell power factor is expressed as a percentage value, from 0% to 100%. If you set an additional spell power factor of 50% then you will channel an additional 50% of the base mana requirement for a spell into the spell.

The more you push the additional spell power, the more you must have affinity with the ways and its associated Mental Stat to control the effects. The power level of the spell is raised by the additional spell power, so the spell will be more powerful.

The use of additional spell power has the side-effect that the spell can fizzle or even produce damages to the caster, depending on how much the spell goes out of control.

To set your additional spell power, use the slider in your Status Window.

===Spellcasting Time===
...

=Enchanted items=
Glyphs can be used in combination with special Enchanters to imbue crystals (ruby, sapphire, emerald and diamond) with magical powers. These crystals held or set on items during their particular crafting stage. Once set the enchanted gem bestow its magical power on the enchanted item.
Each gem can be enchanted with only one glyph at time, therefore a single item cannot be enchanted with more than a single way.

Please note that the modifiers found in randomly looted weapons are different from the ones you may obtain by crafting with glyphs.

The process is:

1) Get a ruby, sapphire, emerald or diamond crystal

2) Get a glyph you want to use for the enchantment. The glyphs is NOT destroyed in the proces.

3) You need to have one of these two books: "Enchanting Gems of Spirit" or "Enchanting Gems of Power"

4) You need access to a special equipment: "Enchanter of Power" (used with glyphs of Crystal, Brown, Blue Ways) or "Enchanter of Spirit" (used with glyphs of Dark, Red, Azure Ways).

5) Certain glyphs can be put only in certain gems

6) You put the glyph you want to use in your right hand, and the gem into the Enchanter container. Then you "Use" the Enchanter.

7) The result is an enchanted gem, for example Meteor Glyph + Sapphire Crystal with Enchanter of Spirit creates "Flaming Major Sapphire Crystal". So the item got a Prefix and an Adjective which provide magical properties. The gem has to be identified with a spell to read its properties.

8) You have to craft a weapon where you will set the socket with the gem. For example you arrive up to the "Battle Hammer Assembly", before making the final hammer. This is true for all crafted weapons, shields, armors and jewelry, as all have the "Assembly" or "Kit" stage before the final item is created.

9) You have to craft a Gem Socket. This can be of three types, of increasing quality and complexity to make: Standard, Superior and Perfect. This will determine the gems you can use with that socket. Standard -> Ruby, Superior -> Emerald and Sapphire, Perfect -> Diamond

10) You can put together the pieces, the gem socket and the kit to create the final enchanted item. This item will take the modifiers (magical properties) of the gem.

===Weapons & Shields===
Weapons usually '''empower''' the weapon's '''damage type''' and add a special ability. The following list associate the damage type with the related magic way:
* ''Blue Way & Red Way'': slash damage
* ''Crystal Way & Dark Way'': pierce damage
* ''Azure Way & Brown Way'': blunt damage

More powerful enchantments can also bestow the weapon the following effects:
* ''Blue Way'': deals extra frost damage (Red Way Magic Resistance protects against this extra damage)
* ''Crystal Way'': deals extra light damage and gives a Disorientation debuff (Dark Way Magic Resistance protects against this extra damage)
* ''Azure Way'': drains Mana (Brown Way Magic Resistance protects against this extra damage)
* ''Red Way'': deals extra fire damage (Blue Way Magic Resistance protects against this extra damage)
* ''Dark Way'': drains HP (Crystal Way Magic Resistance protects against this extra damage)
* ''Brown Way'': drains Strength (Azure Way Magic Resistance protects against this extra damage)

===Armors===
Enchanted Armors gives '''Magic Resistance''' against the way '''opposed''' to the enchanted glyph. More powerful glyphs can also give magic resistance against ways friendly toward the opposed way, therefore a single piece of armor can have magic resistance against up to '''three''' ways. Like weapons a magic way '''empower''' the related '''protection type'''.

===Jewelry===
Enchanted Jewels '''empower skills''' related to the magic way used to enchant, below there is the list of way related skills:

'''Azure Way'''
* Empathy
* Set Traps
* Find Traps
* Knives & Daggers
* Light Armor
'''Blue Way'''
* Pottery
* Masonry
* Fishing
* Heavy Armors
'''Brown Way'''
* Harvesting
* Leatherworking
* Tailoring
* Light Armor
'''Crystal Way'''
* Musical Instrument
* Hide in Shadows
* Drawing
* Medium Armor
'''Dark Way'''
* Pickpockets
* Repair Armors
* Backstab
* Medium Armor
'''Red Way'''
* Tool Making
* Blacksmith
* Jewelry Making
* Repair Tools
* Heavy Armor

=In Character References=
{| class="wikitable"
| style="background:#F5DEB3;" | [[image:lexicon.jpg]]
| style="background:#F5DEB3;" | In game, a couple of books refer to Magic. They can be found in the famous Hydlaa [[Library|library]] owned by the Ylian [[Jayose]] or in the magic shop of Levrus:
* ''History of Magic Vol 1: The Birth''
* ''History of Magic Vol 2: The Taming''
* ''History of Magic Vol.3: The Invasions''
* ''History of Magic Vol.4: The Heresy''
* ''History of Magic Vol.5: The Ways''
|}

* Go to [[Players_Guide#Game_Basics|Player Guide]]

[[Category:Magic]]
[[Category:Glyphs]]
[[Category:Game Guides]]
[[Category:Players Guide (Old)]]

Network load

2025-12-20T22:23:19Z

Talad:

=== Unreal engine 5.1.1 - PSServer 0.7.41 ===
5 players online after event with 15

> nload

Incoming:

Curr: 185.34 kBit/s

Avg: 184.02 kBit/s

Min: 152.20 kBit/s

Max: 355.02 kBit/s

Outgoing:

Curr: 29.88 kBit/s

Avg: 34.55 kBit/s

Min: 26.26 kBit/s

Max: 60.16 kBit/s

=== Unreal Engine 5.4.3 - PSServer 0.7.48 ===
Saturday event with 23 players online

> nload

Incoming:

Curr: 534.70 kBit/s

Avg: 587.16 kBit/s

Min: 482.02 kBit/s

Max: 739.51 kBit/s

Outgoing:

Curr: 320.27 kBit/s

Avg: 395.70 kBit/s

Min: 237.39 kBit/s

Max: 653.91 kBit/s

=== Unreal Engine 5.4.3 - PSServer 0.7.52 ===
Saturday event with 22 players online

Incoming:

Curr: 919.27 kBit/s

Avg: 706.23 kBit/s

Min: 367.48 kBit/s

Max: 2.03 MBit/s

Outgoing:

Curr: 160.20 kBit/s

Avg: 234.08 kBit/s

Min: 87.16 kBit/s

Max: 461.51 kBit/s

Crafting

2025-12-03T22:09:53Z

Talad:

Crafting, the art of creating something out of something else, is an ability that [[PlaneShift]] promotes.

==Crafts==
A lot of crafts are already available in game. Some are on the verge of being implemented.

====Crafts currently implemented====
* Alchemy ([[Players_Guide/Skills#Alchemy|Player Guide]])
* Blacksmith ([[Players_Guide/Skills#Blacksmith|Player Guide]])
** Armor Making ([[Players_Guide/Skills#Armor Making|Player Guide]])
** Blades Making (Player Guide : [[Players_Guide/Skills#Knife Making|Knife]], [[Players_Guide/Skills#Sword Making|Swords]], [[Players_Guide/Skills#Axe Making|Axe]])
** Mace Making (Player Guide : [[Players_Guide/Skills#Mace Making|Mace]])
** Shield Making ([[Players_Guide/Skills#Shield Making|Player Guide]])
* Bow-making ([[Players_Guide/Skills#Bow making|Player Guide]])
* Brewing ([[Players_Guide/Skills#Brewing|Player Guide]])
* [[Cooking]]
** [[Baking]]
* [[Fishing]]
* [[Harvesting]]
* [[Herbal]]
* Jewelry Making ([[Players_Guide/Skills#Jewelry Making|Player Guide]])
* [[Leatherworking]]
* [[Metallurgy]]
* [[Mining]]
* Musical Instruments ([[Players_Guide/Skills#Musical Instrument|Player Guide]])
* [[Repair Armors]]
* [[Repair Weapons]]

====Crafts not currently implemented====
* Drawing
* Gem-cutting ([[Players_Guide/Skills#Gem_cutting|Player Guide]])
* Glass-blowing ([[Players_Guide/Skills#Glassblowing|Player Guide]])
* Masonry ([[Players_Guide/Skills#Masonry|Player Guide]])
* Painting ([[Players_Guide/Skills#Painting|Player Guide]])
* Pottery ([[Players_Guide/Skills#Pottery|Player Guide]])
* Repair Tools
* Tailoring ([[Players_Guide/Skills#Tailoring|Player Guide]])
* Tool Making

==How do I...?==
Check your crafting page above.

See also [[Players Guide/Crafting]]

==Expanding Crafting==

Crafting can be expanded by players and contributors if they get the right knowledge on how to do it. Here you can find a spreadsheet which the developers use to add new crafting processes to the game. If you are interested in adding a new craft, you can populate this excel file and post it here or contact the devs about it. If you want to work with multiple people on it, we suggest you to import this excel file into google docs, and then give access to your team mates.

[http://www.planeshift.it/download/example_crafting_sheet.xls Example Crafting Excel.]

== Extra crafting properties ==
When you craft an item there is a chance based on the worker skill to get an extra prefix:

- Valuable

- Extravagant

- Priceless

It ranges from 3% to 5%

[[Category:Crafting|!]]
[[Category:Yliakum]]

Players Guide/Magic

2025-11-29T18:10:31Z

Talad: /* Enchanted items */

The magical energy in [[Yliakum]] is divided into six ways of arcane: [[Players Guide/Magic#Crystal Way | Crystal Way]], [[Players Guide/Magic#Azure Way | Azure Way]], [[Players Guide/Magic#Red Way | Red Way]], [[Players Guide/Magic#Dark Way | Dark Way]], [[Players Guide/Magic#Brown Way | Brown Way]] and [[Players Guide/Magic#Blue Way | Blue Way]].
[[Image:Magecasting.jpeg|thumb|300px]]

==The Ways of Magic==
[[Image:Ways.png|left|150px]]
Each Way has a particular color and a [[Ingame Help#Stats and Skills | mental stat]] associated. The three mental stats linked to magic are: [[Players Guide#Stats and Skills|Charisma]], [[Players Guide#Stats and Skills|Intelligence]] and [[Players Guide#Stats and Skills|Willpower]]. They give bonuses to the casting of spells that pertain to that way.

Each way is composed of a set of spells and each spell can be casted by a wizard thanks to the combination of a set of runes, called [[Players Guide/Magic#The Glyphs | "glyphs"]]. The spells of a particular Way are related to the same energy and the same concepts (Water, Air or Healing, Drain). They produce either a direct damage or a damage over time on the opponent.

The ways are all somewhat linked by relationship of opposition or attraction. A specific way opposes another and is "friendly" with two others (ie. Crystal Way opposes Dark Way and is friendly with Blue and Azure Way).
Therefor, each spell giving a buff for a given time will provide at least a small way resistance (ie. Casting a Red Way "Strength" spell on yourself will also protect you slightly againt Blue Way).

----

===Crystal Way (CW)===
Users of this Way, get the pure energy of the [[Azure Sun|Crystal]], more directly than all other Ways. Famous for the ability to heal, and cure the most terrible wounds, people have said that if you reach a great knowledge, you can even bring back a person from death. Nonetheless there are many powerful offensive spells, particularly effective against evil and dark creatures. While warriors and farmers with injured animals are more then happy to see these practitioners around; around most towns people feel the appearance of these practitioners is a bad omen of bad times to come.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:CrystalWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| White || Energy, Life and Light || Buff Self & Allies, Direct Damage, Direct Healing || Charisma || Opposed to: Dark Way
Friendly with: Blue & Azure Way
|}

===Dark Way (DW)===
This Way is one that conquers more myth then any of the others. Its practitioners have a history of being the most innovative of any practitioners of the Ways of Magic, but with all innovation there is both good and bad. It's well known that many disasters and epidemics were caused by the adepts of this ancient Way. Holding some spells with terrifying effects, things can become even worse if you lose the control of its power. Some spells enable the control of horrific creatures, such as undead, demons and spirits, whilst some enable the caster to control objects and people in a subtle manner at distance.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:DarkWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Black || Entropy, Death and Darkness || Fear & Debuff, Drain, Direct Damage and Damage Over Time || Charisma || Opposed to: Crystal Way
Friendly with: Brown & Red Way
|}

===Azure Way (AW)===
Basically a sneaky and insidious energy, the Azure Way can control the will, the perceptions and the intentions of any intelligent being. It's power comes from the deep knowledge of the mind and the way to influence it, but it relies also on the mind's potential to influence the surrounding areas and objects, particularly all that is related to the air element.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:AzureWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Light Blue || Mind, Illusion and Air element ||Charm & Buff NPCs, Paralyzation, Minor Direct Damage and Damage Over Time || Will || Opposed to: Brown Way
Friendly with: Crystal & Red Way
|}

===Red Way (RW)===
The spellcaster is able to invoke the power of Chaos, and to bend to his/her/kra's will the devastating fury of fire, summoning it for its both damaging and purifying qualities. Spells of the Red Way can also instil courage and strength into companions or other creatures. Most spells in this Way are fire related, and the majority of metal workers have knowledge of it.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:RedWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Red || Strength, Chaos & Fire element||Major Direct Damage, Combat Buffs|| Will || Opposed to: Blue Way
Friendly with: Azure & Dark Way
|}

===Blue Way (BlW)===
Many diseases and poisons would be incurable without the help of the spells of this Way. The offensive and defensive potential of this art reside mainly on the control of the water element, but also of cold and ice that are strictly related to it. Equally inestimable are the divination spells that can provide very useful information on the past, present and future.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BlueWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Blue || Divination, Purification and Water element ||Immobilize, Major Damage Over Time, Healing Over Time, Polymorph|| Intelligence ||Opposed to: Red Way
Friendly with: Brown & Crystal Way
|}

===Brown Way (BrW)===
The glyphs of this Way give to the wizard the ability to cast different protective spells, to summon natural creatures and some monsters and to influence their will. This Way is really close to the element of Earth and can control all that's related to it. Users can call nature spirits for assistance or mark themselves and allies as friends of nature.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BrownWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Brown || Nature, Protective magic and Earth element ||Defensive Buff, Summon Monster, Direct Damage, Immobilization, Minor Polymorph|| Intelligence ||Opposed to: Azure Way
Friendly with: Blue & Dark Way
|}

==Casting a Spell==
===The Glyphs===
At the beginning of [[Players Guide/Yliakum History | Yliakum History]], the [[God|god]] [[Talad]], forged pure magical energy into shapes called "Glyphs". They form the base of Yliakum magic.

* No spell can be casted without a glyph.

They are found in nature with no real explanation, no one knows exactly why they form but when some type of energy is strongly present in one place a glyph can form. Glyphs patterns appear on very different materials from a leaf to the fur of an animal and usually on any type of rock.

During the centuries many glyphs have been found and studied by the wizards. They discovered that each glyph can create a spell effect and that several glyphs can be combined to obtain greater effects. To simplify casting of spells, the glyphs are associated with a concept (ie. "Weight") and wizards combine those concepts to form new spells (ie. "Weight" and "Negate" to become very light).

Nowadays, glyphs can be found rendering services to the people of Yliakum or can be bought to mages like [[Levrus Dahrenn]] in the [[Magic Shop | magic shop]] for the more basic of them. The more rare and powerfull glyphs can be obtained by joining a Way Circle (school of magic) and follow its path to the Mastery of a particular Way.

* The glyphs purchased or rewarded will appear in your [[Ingame Help#Inventory Window | Inventory]] and be visible in the Glyphs Window in your [[Ingame Help#Spell Book Window | Spell Book]].

[[File:Glyphs.jpg|500px]]

===Purification===
To use a glyph, the wizard must apply a process of Purification, which take some time. The Purification establish a strong link in between the wizard and his glyph. If he dies, the glyphs will be taken to the [[Death|Death Realm]] with him. A wizard can trade a glyph, but the recipient will need to purify the glyph as well to create a new magic link and be able to use it.

* To purify a glyph, open the Glyph window from your Spell Book.
* Drag the glyph and drop it on the button called: '''Purify'''.
* When the Purification is done, you will see a message in your Chat Window > System Tab and your glyph will be surrounded of a white aura.

===Researching a Spell===
[[Image:SpellbookVen.jpg|300px|thumb|left]]
Once you have one or more glyphs, you can start to research spells. To be discovred, a spell can ask one glyph or a combinaison of up to 3 glyphs.

Shown on this pic is the glyph window of your Spell Book. The six main boxes will content the glyphs of the six ways of magic. The small row of boxes at the bottom of the window is where you put glyphs in order to combine or purify them.
* To discover a spell, drag one or several glyphs in the small row of boxes at the bottom of the window and hit the button called: '''Research'''.
* When you effectivly discovred a spell, its name and description will appear.
* Once discovred, the spell will automatically be added in your Spell Book. You wont have to research it again to cast it.

In this example, the Blue Way glyph "Cold" has been placed in the box and the wizard has discovred the spell called "Freeze".
* If you fail to discover a spell it might be for several raison : the combinaison of glyphs isn't right; you have not trained that way of magic high enough; or the glyph isn't purified.
Researching a spell is dangerous for the wizard. In effect, it ask a lot of mental focus and the strong magical energy at work may wound an unwary magician.

===Casting===
There are two great categories of spells available to the wizards: the enhancing spells that we call "buffs" and the attack spells.

The enhancing spells like "Rock Armor" (Brown Way) are made to be cast on the wizard. They enhance one health or stamina or increase one defensive ability. Some of those spells can be cast on friends, like "Life Infusion" (CW).

The attack spells like "Flame Burst" (RW) are made to defeat enemies. Some are efficient in close range, some in very long range. Those spells can be cast on players too in case of [[General FAQ#Will there be Player vs. Player combat in PlaneShift?|PvP]] (player versus player).

The process to cast a spell is as follow:
* Select your character or an enemy [[Non-Player Character|NPC]]
* Open your spell book, select the spell you wish to cast and click '''Cast Spell'''.
There is many ways to make this operation less long. The quickest one is to create a [[Ingame Help#Shortcuts Window|shortcut]] of the spell you plan to use a lot.
* Once you clicked on the chosen spell, a count down window will appear. When it is finished, the spell will be cast.

[[Image:magepower.jpeg|left|thumb|400px]] [[Image:Magered.jpg|center|thumb|350px]]

==Magic Mechanism==

===Type of Damage===

Spells and Magical effects can have different type of effects:

'''Direct Damage''' (DD): direct damage is applied as soon as the spell has been cast. Red Way offensive spells usually deal direct damage.

'''Damage over Time''' (DoT): this damage is applied over a period of time. Starting from when the spells has been successfully cast and until the spell duration runs out, the target HPs are constantly reduced. Blue Way offensive spells usually deal damage over time. This type of damage usually deal more damage than an equivalent realm spell, on the other side the duration can allow the target to try to heal itself or dispel the offensive spell.

===Damage and Saving Throws===
When a spell deals damage may allow the opponent to roll a ''saving throw'' to reduce the amount of damage sustained; this ''saving throw'' is made by the server confronting the caster and the target knowledge of the spell's magic way (e.g. Crystal Magic) plus a random factor: the higher is the target's knowledge of the way the higher is the chance to succeed the roll. When a target successfully roll the save the spell damage is usually halved.
If a spell which deals damage does not allow for a ''saving throw'' roll, that spell will usually deal about 70% less damage than an equivalent spell (same realm and same magic way).

<div style="background: #efe; padding: 4px 4px; width: 1000px">
[[Image:Fountain.png|40px]] '''Tip: The higher is your knowledge in a way the higher is your chance to counter or avoid damage and effects of the same way.'''
</div>

===Magic Resistance===
...

===Spell Power (KFactor)===
''(under construction)''
The spell caster can decide to channel more mana into casting by setting the additional spell power, allowing the caster to cast a more powerful spell.

The additional spell power factor is expressed as a percentage value, from 0% to 100%. If you set an additional spell power factor of 50% then you will channel an additional 50% of the base mana requirement for a spell into the spell.

The more you push the additional spell power, the more you must have affinity with the ways and its associated Mental Stat to control the effects. The power level of the spell is raised by the additional spell power, so the spell will be more powerful.

The use of additional spell power has the side-effect that the spell can fizzle or even produce damages to the caster, depending on how much the spell goes out of control.

To set your additional spell power, use the slider in your Status Window.

===Spellcasting Time===
...

=Enchanted items=
Glyphs can be used in combination with special Enchanters to imbue crystals (ruby, sapphire, emerald and diamond) with magical powers. These crystals held or set on items during their particular crafting stage. Once set the enchanted gem bestow its magical power on the enchanted item.
Each gem can be enchanted with only one glyph at time, therefore a single item cannot be enchanted with more than a single way.

Please note that the modifiers found in randomly looted weapons are different from the ones you may obtain by crafting with glyphs.

The process is:

1) Get a ruby, sapphire, emerald or diamond crystal

2) Get a glyph you want to use for the enchantment. The glyphs is NOT destroyed in the proces.

3) You need to have one of these two books: "Enchanting Gems of Spirit" or "Enchanting Gems of Power"

4) You need access to a special equipment: "Enchanter of Power" (used with glyphs of Crystal, Brown, Blue Ways) or "Enchanter of Spirit" (used with glyphs of Dark, Red, Azure Ways).

5) Certain glyphs can be put only in certain gems

6) You put the glyph you want to use in your right hand, and the gem into the Enchanter container. Then you "Use" the Enchanter.

7) The result is an enchanted gem, for example Meteor Glyph + Sapphire Crystal with Enchanter of Spirit creates "Flaming Major Sapphire Crystal". So the item got a Prefix and an Adjective which provide magical properties. The gem has to be identified with a spell to read its properties.

8) You have to craft a weapon where you will set the socket with the gem. For example you arrive up to the "Battle Hammer Assembly", before making the final hammer. This is true for all crafted weapons, shields, armors and jewelry, as all have the "Assembly" or "Kit" stage before the final item is created.

9) You have to craft a Gem Socket. This can be of three types, of increasing quality and complexity to make: Standard, Superior and Perfect.

10) You can put together the pieces, the gem socket and the kit to create the final enchanted item. This item will take the modifiers (magical properties) of the gem.

===Weapons & Shields===
Weapons usually '''empower''' the weapon's '''damage type''' and add a special ability. The following list associate the damage type with the related magic way:
* ''Blue Way & Red Way'': slash damage
* ''Crystal Way & Dark Way'': pierce damage
* ''Azure Way & Brown Way'': blunt damage

More powerful enchantments can also bestow the weapon the following effects:
* ''Blue Way'': deals extra frost damage (Red Way Magic Resistance protects against this extra damage)
* ''Crystal Way'': deals extra light damage and gives a Disorientation debuff (Dark Way Magic Resistance protects against this extra damage)
* ''Azure Way'': drains Mana (Brown Way Magic Resistance protects against this extra damage)
* ''Red Way'': deals extra fire damage (Blue Way Magic Resistance protects against this extra damage)
* ''Dark Way'': drains HP (Crystal Way Magic Resistance protects against this extra damage)
* ''Brown Way'': drains Strength (Azure Way Magic Resistance protects against this extra damage)

===Armors===
Enchanted Armors gives '''Magic Resistance''' against the way '''opposed''' to the enchanted glyph. More powerful glyphs can also give magic resistance against ways friendly toward the opposed way, therefore a single piece of armor can have magic resistance against up to '''three''' ways. Like weapons a magic way '''empower''' the related '''protection type'''.

===Jewelry===
Enchanted Jewels '''empower skills''' related to the magic way used to enchant, below there is the list of way related skills:

'''Azure Way'''
* Empathy
* Set Traps
* Find Traps
* Knives & Daggers
* Light Armor
'''Blue Way'''
* Pottery
* Masonry
* Fishing
* Heavy Armors
'''Brown Way'''
* Harvesting
* Leatherworking
* Tailoring
* Light Armor
'''Crystal Way'''
* Musical Instrument
* Hide in Shadows
* Drawing
* Medium Armor
'''Dark Way'''
* Pickpockets
* Repair Armors
* Backstab
* Medium Armor
'''Red Way'''
* Tool Making
* Blacksmith
* Jewelry Making
* Repair Tools
* Heavy Armor

=In Character References=
{| class="wikitable"
| style="background:#F5DEB3;" | [[image:lexicon.jpg]]
| style="background:#F5DEB3;" | In game, a couple of books refer to Magic. They can be found in the famous Hydlaa [[Library|library]] owned by the Ylian [[Jayose]] or in the magic shop of Levrus:
* ''History of Magic Vol 1: The Birth''
* ''History of Magic Vol 2: The Taming''
* ''History of Magic Vol.3: The Invasions''
* ''History of Magic Vol.4: The Heresy''
* ''History of Magic Vol.5: The Ways''
|}

* Go to [[Players_Guide#Game_Basics|Player Guide]]

[[Category:Magic]]
[[Category:Glyphs]]
[[Category:Game Guides]]
[[Category:Players Guide (Old)]]

Players Guide/Magic

2025-11-29T17:55:07Z

Talad: /* Enchanted items */

The magical energy in [[Yliakum]] is divided into six ways of arcane: [[Players Guide/Magic#Crystal Way | Crystal Way]], [[Players Guide/Magic#Azure Way | Azure Way]], [[Players Guide/Magic#Red Way | Red Way]], [[Players Guide/Magic#Dark Way | Dark Way]], [[Players Guide/Magic#Brown Way | Brown Way]] and [[Players Guide/Magic#Blue Way | Blue Way]].
[[Image:Magecasting.jpeg|thumb|300px]]

==The Ways of Magic==
[[Image:Ways.png|left|150px]]
Each Way has a particular color and a [[Ingame Help#Stats and Skills | mental stat]] associated. The three mental stats linked to magic are: [[Players Guide#Stats and Skills|Charisma]], [[Players Guide#Stats and Skills|Intelligence]] and [[Players Guide#Stats and Skills|Willpower]]. They give bonuses to the casting of spells that pertain to that way.

Each way is composed of a set of spells and each spell can be casted by a wizard thanks to the combination of a set of runes, called [[Players Guide/Magic#The Glyphs | "glyphs"]]. The spells of a particular Way are related to the same energy and the same concepts (Water, Air or Healing, Drain). They produce either a direct damage or a damage over time on the opponent.

The ways are all somewhat linked by relationship of opposition or attraction. A specific way opposes another and is "friendly" with two others (ie. Crystal Way opposes Dark Way and is friendly with Blue and Azure Way).
Therefor, each spell giving a buff for a given time will provide at least a small way resistance (ie. Casting a Red Way "Strength" spell on yourself will also protect you slightly againt Blue Way).

----

===Crystal Way (CW)===
Users of this Way, get the pure energy of the [[Azure Sun|Crystal]], more directly than all other Ways. Famous for the ability to heal, and cure the most terrible wounds, people have said that if you reach a great knowledge, you can even bring back a person from death. Nonetheless there are many powerful offensive spells, particularly effective against evil and dark creatures. While warriors and farmers with injured animals are more then happy to see these practitioners around; around most towns people feel the appearance of these practitioners is a bad omen of bad times to come.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:CrystalWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| White || Energy, Life and Light || Buff Self & Allies, Direct Damage, Direct Healing || Charisma || Opposed to: Dark Way
Friendly with: Blue & Azure Way
|}

===Dark Way (DW)===
This Way is one that conquers more myth then any of the others. Its practitioners have a history of being the most innovative of any practitioners of the Ways of Magic, but with all innovation there is both good and bad. It's well known that many disasters and epidemics were caused by the adepts of this ancient Way. Holding some spells with terrifying effects, things can become even worse if you lose the control of its power. Some spells enable the control of horrific creatures, such as undead, demons and spirits, whilst some enable the caster to control objects and people in a subtle manner at distance.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:DarkWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Black || Entropy, Death and Darkness || Fear & Debuff, Drain, Direct Damage and Damage Over Time || Charisma || Opposed to: Crystal Way
Friendly with: Brown & Red Way
|}

===Azure Way (AW)===
Basically a sneaky and insidious energy, the Azure Way can control the will, the perceptions and the intentions of any intelligent being. It's power comes from the deep knowledge of the mind and the way to influence it, but it relies also on the mind's potential to influence the surrounding areas and objects, particularly all that is related to the air element.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:AzureWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Light Blue || Mind, Illusion and Air element ||Charm & Buff NPCs, Paralyzation, Minor Direct Damage and Damage Over Time || Will || Opposed to: Brown Way
Friendly with: Crystal & Red Way
|}

===Red Way (RW)===
The spellcaster is able to invoke the power of Chaos, and to bend to his/her/kra's will the devastating fury of fire, summoning it for its both damaging and purifying qualities. Spells of the Red Way can also instil courage and strength into companions or other creatures. Most spells in this Way are fire related, and the majority of metal workers have knowledge of it.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:RedWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Red || Strength, Chaos & Fire element||Major Direct Damage, Combat Buffs|| Will || Opposed to: Blue Way
Friendly with: Azure & Dark Way
|}

===Blue Way (BlW)===
Many diseases and poisons would be incurable without the help of the spells of this Way. The offensive and defensive potential of this art reside mainly on the control of the water element, but also of cold and ice that are strictly related to it. Equally inestimable are the divination spells that can provide very useful information on the past, present and future.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BlueWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Blue || Divination, Purification and Water element ||Immobilize, Major Damage Over Time, Healing Over Time, Polymorph|| Intelligence ||Opposed to: Red Way
Friendly with: Brown & Crystal Way
|}

===Brown Way (BrW)===
The glyphs of this Way give to the wizard the ability to cast different protective spells, to summon natural creatures and some monsters and to influence their will. This Way is really close to the element of Earth and can control all that's related to it. Users can call nature spirits for assistance or mark themselves and allies as friends of nature.
{| width=100% {{Prettytable}}
!rowspan="2" width="40" | [[Image:BrownWay.png|32px]]
!width="60"|Glyph Colour
!width="60"|Focus
!width="60"|Gameplay
!width="60"|Mental Stat
!width="90"|Relationships
|-
| Brown || Nature, Protective magic and Earth element ||Defensive Buff, Summon Monster, Direct Damage, Immobilization, Minor Polymorph|| Intelligence ||Opposed to: Azure Way
Friendly with: Blue & Dark Way
|}

==Casting a Spell==
===The Glyphs===
At the beginning of [[Players Guide/Yliakum History | Yliakum History]], the [[God|god]] [[Talad]], forged pure magical energy into shapes called "Glyphs". They form the base of Yliakum magic.

* No spell can be casted without a glyph.

They are found in nature with no real explanation, no one knows exactly why they form but when some type of energy is strongly present in one place a glyph can form. Glyphs patterns appear on very different materials from a leaf to the fur of an animal and usually on any type of rock.

During the centuries many glyphs have been found and studied by the wizards. They discovered that each glyph can create a spell effect and that several glyphs can be combined to obtain greater effects. To simplify casting of spells, the glyphs are associated with a concept (ie. "Weight") and wizards combine those concepts to form new spells (ie. "Weight" and "Negate" to become very light).

Nowadays, glyphs can be found rendering services to the people of Yliakum or can be bought to mages like [[Levrus Dahrenn]] in the [[Magic Shop | magic shop]] for the more basic of them. The more rare and powerfull glyphs can be obtained by joining a Way Circle (school of magic) and follow its path to the Mastery of a particular Way.

* The glyphs purchased or rewarded will appear in your [[Ingame Help#Inventory Window | Inventory]] and be visible in the Glyphs Window in your [[Ingame Help#Spell Book Window | Spell Book]].

[[File:Glyphs.jpg|500px]]

===Purification===
To use a glyph, the wizard must apply a process of Purification, which take some time. The Purification establish a strong link in between the wizard and his glyph. If he dies, the glyphs will be taken to the [[Death|Death Realm]] with him. A wizard can trade a glyph, but the recipient will need to purify the glyph as well to create a new magic link and be able to use it.

* To purify a glyph, open the Glyph window from your Spell Book.
* Drag the glyph and drop it on the button called: '''Purify'''.
* When the Purification is done, you will see a message in your Chat Window > System Tab and your glyph will be surrounded of a white aura.

===Researching a Spell===
[[Image:SpellbookVen.jpg|300px|thumb|left]]
Once you have one or more glyphs, you can start to research spells. To be discovred, a spell can ask one glyph or a combinaison of up to 3 glyphs.

Shown on this pic is the glyph window of your Spell Book. The six main boxes will content the glyphs of the six ways of magic. The small row of boxes at the bottom of the window is where you put glyphs in order to combine or purify them.
* To discover a spell, drag one or several glyphs in the small row of boxes at the bottom of the window and hit the button called: '''Research'''.
* When you effectivly discovred a spell, its name and description will appear.
* Once discovred, the spell will automatically be added in your Spell Book. You wont have to research it again to cast it.

In this example, the Blue Way glyph "Cold" has been placed in the box and the wizard has discovred the spell called "Freeze".
* If you fail to discover a spell it might be for several raison : the combinaison of glyphs isn't right; you have not trained that way of magic high enough; or the glyph isn't purified.
Researching a spell is dangerous for the wizard. In effect, it ask a lot of mental focus and the strong magical energy at work may wound an unwary magician.

===Casting===
There are two great categories of spells available to the wizards: the enhancing spells that we call "buffs" and the attack spells.

The enhancing spells like "Rock Armor" (Brown Way) are made to be cast on the wizard. They enhance one health or stamina or increase one defensive ability. Some of those spells can be cast on friends, like "Life Infusion" (CW).

The attack spells like "Flame Burst" (RW) are made to defeat enemies. Some are efficient in close range, some in very long range. Those spells can be cast on players too in case of [[General FAQ#Will there be Player vs. Player combat in PlaneShift?|PvP]] (player versus player).

The process to cast a spell is as follow:
* Select your character or an enemy [[Non-Player Character|NPC]]
* Open your spell book, select the spell you wish to cast and click '''Cast Spell'''.
There is many ways to make this operation less long. The quickest one is to create a [[Ingame Help#Shortcuts Window|shortcut]] of the spell you plan to use a lot.
* Once you clicked on the chosen spell, a count down window will appear. When it is finished, the spell will be cast.

[[Image:magepower.jpeg|left|thumb|400px]] [[Image:Magered.jpg|center|thumb|350px]]

==Magic Mechanism==

===Type of Damage===

Spells and Magical effects can have different type of effects:

'''Direct Damage''' (DD): direct damage is applied as soon as the spell has been cast. Red Way offensive spells usually deal direct damage.

'''Damage over Time''' (DoT): this damage is applied over a period of time. Starting from when the spells has been successfully cast and until the spell duration runs out, the target HPs are constantly reduced. Blue Way offensive spells usually deal damage over time. This type of damage usually deal more damage than an equivalent realm spell, on the other side the duration can allow the target to try to heal itself or dispel the offensive spell.

===Damage and Saving Throws===
When a spell deals damage may allow the opponent to roll a ''saving throw'' to reduce the amount of damage sustained; this ''saving throw'' is made by the server confronting the caster and the target knowledge of the spell's magic way (e.g. Crystal Magic) plus a random factor: the higher is the target's knowledge of the way the higher is the chance to succeed the roll. When a target successfully roll the save the spell damage is usually halved.
If a spell which deals damage does not allow for a ''saving throw'' roll, that spell will usually deal about 70% less damage than an equivalent spell (same realm and same magic way).

<div style="background: #efe; padding: 4px 4px; width: 1000px">
[[Image:Fountain.png|40px]] '''Tip: The higher is your knowledge in a way the higher is your chance to counter or avoid damage and effects of the same way.'''
</div>

===Magic Resistance===
...

===Spell Power (KFactor)===
''(under construction)''
The spell caster can decide to channel more mana into casting by setting the additional spell power, allowing the caster to cast a more powerful spell.

The additional spell power factor is expressed as a percentage value, from 0% to 100%. If you set an additional spell power factor of 50% then you will channel an additional 50% of the base mana requirement for a spell into the spell.

The more you push the additional spell power, the more you must have affinity with the ways and its associated Mental Stat to control the effects. The power level of the spell is raised by the additional spell power, so the spell will be more powerful.

The use of additional spell power has the side-effect that the spell can fizzle or even produce damages to the caster, depending on how much the spell goes out of control.

To set your additional spell power, use the slider in your Status Window.

===Spellcasting Time===
...

=Enchanted items=
Glyphs can be used in combination with special Enchanters to imbue crystals (ruby, sapphire, emerald and diamond) with magical powers. These crystals held or set on items during their particular crafting stage. Once set the enchanted gem bestow its magical power on the enchanted item.
Each gem can be enchanted with only one glyph at time, therefore a single item cannot be enchanted with more than a single way.

The process is:

1) Get a ruby, sapphire, emerald or diamond crystal

2) Get a glyph you want to use for the enchantment. The glyphs is NOT destroyed in the proces.

3) You need to have one of these two books: "Enchanting Gems of Spirit" or "Enchanting Gems of Power"

4) You need access to a special equipment: "Enchanter of Power" (used with glyphs of Crystal, Brown, Blue Ways) or "Enchanter of Spirit" (used with glyphs of Dark, Red, Azure Ways).

5) Certain glyphs can be put only in certain gems

6) You put the glyph you want to use in your right hand, and the gem into the Enchanter container. Then you "Use" the Enchanter.

7) The result is an enchanted gem, for example Meteor Glyph + Sapphire Crystal with Enchanter of Spirit creates "Flaming Major Sapphire Crystal". So the item got a Prefix and an Adjective which provide magical properties. The gem has to be identified with a spell to read its properties.

8) You have to craft a weapon where you will set the socket with the gem. For example you arrive up to the "Battle Hammer Assembly", before making the final hammer. This is true for all crafted weapons, shields, armors and jewelry, as all have the "Assembly" or "Kit" stage before the final item is created.

9) You have to craft a Gem Socket. This can be of three types, of increasing quality and complexity to make: Standard, Superior and Perfect.

10) You can put together the pieces, the gem socket and the kit to create the final enchanted item. This item will take the modifiers (magical properties) of the gem.

===Weapons & Shields===
Weapons usually '''empower''' the weapon's '''damage type''' and add a special ability. The following list associate the damage type with the related magic way:
* ''Blue Way & Red Way'': slash damage
* ''Crystal Way & Dark Way'': pierce damage
* ''Azure Way & Brown Way'': blunt damage

More powerful enchantments can also bestow the weapon the following effects:
* ''Blue Way'': deals extra frost damage (Red Way Magic Resistance protects against this extra damage)
* ''Crystal Way'': deals extra light damage and gives a Disorientation debuff (Dark Way Magic Resistance protects against this extra damage)
* ''Azure Way'': drains Mana (Brown Way Magic Resistance protects against this extra damage)
* ''Red Way'': deals extra fire damage (Blue Way Magic Resistance protects against this extra damage)
* ''Dark Way'': drains HP (Crystal Way Magic Resistance protects against this extra damage)
* ''Brown Way'': drains Strength (Azure Way Magic Resistance protects against this extra damage)

===Armors===
Enchanted Armors gives '''Magic Resistance''' against the way '''opposed''' to the enchanted glyph. More powerful glyphs can also give magic resistance against ways friendly toward the opposed way, therefore a single piece of armor can have magic resistance against up to '''three''' ways. Like weapons a magic way '''empower''' the related '''protection type'''.

===Jewelry===
Enchanted Jewels '''empower skills''' related to the magic way used to enchant, below there is the list of way related skills:

'''Azure Way'''
* Empathy
* Set Traps
* Find Traps
* Knives & Daggers
* Light Armor
'''Blue Way'''
* Pottery
* Masonry
* Fishing
* Heavy Armors
'''Brown Way'''
* Harvesting
* Leatherworking
* Tailoring
* Light Armor
'''Crystal Way'''
* Musical Instrument
* Hide in Shadows
* Drawing
* Medium Armor
'''Dark Way'''
* Pickpockets
* Repair Armors
* Backstab
* Medium Armor
'''Red Way'''
* Tool Making
* Blacksmith
* Jewelry Making
* Repair Tools
* Heavy Armor

=In Character References=
{| class="wikitable"
| style="background:#F5DEB3;" | [[image:lexicon.jpg]]
| style="background:#F5DEB3;" | In game, a couple of books refer to Magic. They can be found in the famous Hydlaa [[Library|library]] owned by the Ylian [[Jayose]] or in the magic shop of Levrus:
* ''History of Magic Vol 1: The Birth''
* ''History of Magic Vol 2: The Taming''
* ''History of Magic Vol.3: The Invasions''
* ''History of Magic Vol.4: The Heresy''
* ''History of Magic Vol.5: The Ways''
|}

* Go to [[Players_Guide#Game_Basics|Player Guide]]

[[Category:Magic]]
[[Category:Glyphs]]
[[Category:Game Guides]]
[[Category:Players Guide (Old)]]

Maps editing workflow

2025-11-24T21:47:58Z

Talad:

== How Landscape is setup ==
In the outliner we have a Landscape Object. If you click on it, you see the details it's linked to a MI_Landscape.

MI_Landscape contains all the parameters including the visibility of rocks , grass, etc...

The actual meshes are part of "Landscape Grass Type" a special object that can contain a mesh, its density, culling distance, etc...

M_Landscape has a special node called : "Landscape Grass" of type "Landscape Grass Output". It the detail panel of this node, there are all the "Landscape Grass Type" linked with a name (which is the name of the layer).

=== Landscape limits ===
Vertically our landscape can go from -250 meters up to +250 meters, if you try to go beyond these values you just get flat terrain at the max height and you cant go beyond.

Our maps at the moment have the lowest point to the south of Homestead where it reach -177 meters. Plus we need to consider the Death Ream boundaries, that reach at the moment -199 meters.

We have set the Kill Z value to -185 meters.

=== Notes ===

* BuiltData files are storing:
** lightmap textures (created by Build Lighting only)
** volumetric light probes / samples (created by Build Lighting only)
* umap files are storing:
** navigation paths (created by Build Paths)

=== Map creation flow ===
You should never upload BuiltData file in SVN. Those will be regenerated when we create the shipping release.

If you want to test locally the full game including lights then you need to:

* Load all the levels and Build Lighting only, this gives the best result on map borders, but I think you can avoid it

OR

* Load Persistent Level + one or more maps you want relit, and Build Lighting only. In this case the single maps will be ok, but the borders between maps will not

If you want to test locally the full game including NPC movement then you need to:

* Follow Option 1 in [[PSUnreal Navigation Meshes|this page]].

Skybox and Lights setup

2025-11-20T22:17:22Z

Talad:

== Elements contributing to day / night cycle ==

* DirectionalLight, actor in the Persistent Level (Yliakum). Casting light globally in a certain direction.
** Intensity
** Light Color
* SkyLight, actor in the Persistent Level. Stores the color of the skybox and influence all items in the game with indirect light based on the skybox color.
** Intensity
* bp_sky, actor in the Persistent Level, which contains all the logic for rain/snow/fog/... , clouds, time of the day, the actual skybox which is a static mesh (dome).
** Light, scalar parameter on the Material applied to the skybox mesh
* ExponentialHeightFog, actor in the Persistent Level, managing the fog. Careful to change its color at night, or the skydome will stay lit.
** Light color
*"PostProcessVolumeWholeGame", this is applied to the whole game, any level. It has Min Brightness=0.5 and Max Brightness=4. If you want your level in game to look like in the editor you need to be sure in game you have the same min/max settings
*Exposure, made of Min Brightness=0.5 and Max Brightness=4. Min Brightness changes based on the time of the day. Max Brightness is fixed = 4.

== 5.1.1 Build All Bug ==
In Unreal engine 5.x if you click on "Build All Levels" it will actually break the relight. The same if you click on "Build Geometry" as all the BP containing lights will disappear from the editor until you relaunch it. This causes the lights in BP not to be recalculated.

The solution is to click on "Built Lighting Only".

== Static vs Dynamic lights ==

I tried with many different settings and Lightmass is crashing on our hydlaa level very often. Trying to create a minimal set of objects exposing the crash seems not possible, as when you delete some objects may stop crashing, but then deleting more seems to stop crashing, so looks like the combination of meshes, not one particular mesh.

The crash happen with SkyLight and DirectionalLight set as Stationary and also with SkyLight as Stationary and DirectionalLight set as Moveable.

The crash does NOT happen with '''SkyLight as Moveable''' and DirectionalLight set as Stationary. So we tried this setting, the problem is the size of the generated BuiltData files.

{| class="wikitable"
|-
! Map !! Skylight Moveable, Directional Static !! Both Moveable
|-
| Hydlaa plaza || 530Mb || 139Mb
|-
| Gugrontid || 372Mb|| 13Mb
|-
| Ojaveda|| 92.5Mb || 53Mb
|-
| Amdeneir|| 744Mb|| 38Mb
|}
Given the sizes above, at the end we decided to keep both '''SkyLight and DirectionalLight set as Moveable'''.

== up to 0.7.7 release values ==

At noon:
* Fog Inscattering Color: (R=0.313989,G=0.467784,B=0.887923,A=1.000000)
* Skybox Light: 2.0
* Skylight Intensity: 1.5
* Skylight Color: (R=0.853051,G=0.958179,B=1.000000,A=1.000000)
* DirectionalLight Intensity: 4.965001

At night:
* Fog Inscattering Color: (R=0.023549,G=0.035084,B=0.066594,A=0.075000)
* Skybox Light: 0.15
* Skylight Intensity: 0.1125
* Skylight Color: (R=0.988979,G=0.996863,B=1.000000,A=1.000000)
* DirectionalLight Intensity: 0.3

== values from 0.7.8 release ==

At noon:
* Skybox Light: 1.0
* Skylight Intensity: 1
* DirectionalLight Intensity: 2

At night:
* Fog Inscattering Color: 0
* Skybox Light: 0.04
* Skylight Intensity: 0.07
* DirectionalLight Intensity: 0.07

== Rebuild lights - size and timings ==
Foliage set as static lighting
{| class="wikitable"
|+
!Level
!Skylight Moveable
!BuiltData size
!Skylight Stationary
!BuiltData size
!Date
|-
|Hydlaa_X08_Y04
|10 minutes
|132Mb
|39 minutes
|1493 Mb
|19 April 2022
|-
|Ojaveda_X11_Y04
|4 minutes
|43Mb
|6 minutes
|84Mb
|19 April 2022
|-
|
|
|
|
|
|
|}
After changing foliage to moveable
{| class="wikitable"
!Level
!Skylight Moveable
!BuiltData size
!Skylight Stationary
!BuiltData size
!Date
|-
|Hydlaa_X08_Y04
|?
|?
|7 minutes
|201 Mb
|24 April 2022
|}

== Changes 0.7.19 release ==

Lights update based on Rycer feedback.

[X] Change on the Persistent Level: World Settings -> Volume Lighting Method -> Volumetric Lighmap

[X] Keep the Directional Light as Moveable. Change the skylight to stationary (was moveable). Persistent Level -> skylight

[X] Disable Distance field, since they would be no longer needed with static lighting. Project Settings -> Engine -> Rendering -> Generate Mesh Distance Fields

[X] Keep the landscape lightmap resolution to 1

[X] Trees, go to Foliage mode, and then click on all meshes part of foliage and set Mobility as "moveable"

[X] Persistent Level (Yliakum Map file) -> WorldSettings -> Lightmass -> Volumetric Lightmap Details -> 400 (was 200)

[X] Added an Unbound Post Process Volume (PostProcessVolumeWholeGame) with Lens->Exposure->min/max Brightness, min=0.5, max=4 . Set with Infinite extent = true

[X] World Settings -> Lightmass -> Num Sky Lighting Bounces to 5 (it was 1)

[X] No Change. Change the static lighting lod to 1 or 2 on landscape only if lightmass crashes

[X] No change. Grass is already dynamic because its placed by the engine

[X] No change. Seems our lightmap resolution is between 32 and 64, overriden by the engine or some of us.

[NO, it was causing too large lightmaps on hydlaa_level] Trees, go to Foliage mode, and then click on all meshes part of foliage and set Mobility as "static" and change Lighting mode to "Force Volumetric", Keep it as lightmap resolution of 8.

Additional Notes:

5) Because of a low lightmap resolution, make the point lights (torches and similar) a combination of a static and dynamic light. One low brightness, high radius static point light (for bounced lighting) and a second light - bright, dynamic with a short radius

6) Careful use of reflection capture. Ideally one per building, some will require more. It would be useful to change their resolution to 64 or even 32 to save memory.

7) Split some underground areas to new streamed sublevels for less streaming hitches, performance optimization and faster loading.

== Changes 0.7.20 release ==
[X] Change on the Persistent Level: World Settings -> Volume Lighting Method -> Sparse Volume Lighting Samples

== Changes 0.7.40 release ==
Since long time I was getting this error during relight: "InstancedFoliageActor_0 Large actor receives a pre-shadow and will cause an extreme performance hit unless bCastDynamicShadow is set to false."

I changed Crystal_Light29 from Stationary to Static, and the error went away. We should not have stationary lights impacting landscape.

== 0.7.52 test for full dynamic lights ==
1) I deleted all the *Builtdata* files (or I was gettting an error on save)

2) Turn on "World Settings"->"Force No Precomputed Lighting"

3) Build -> "Build LIghting only" (this will basically remove all the lightmaps in case you have any)

4) Resave all.

Optimization with Lightmaps, LOD, and Collisions

2025-11-14T09:43:37Z

Talad:

== Lightmap Density ==
To check lightmap density, click the Lit menu, then "Optimization Viewmode" then "Lightmap density" , or alt+0.

This view mode uses a color scale and grid texture to simplify balancing lightmap resolutions, and also identify mapping errors. In this layout, blue is too low res, green is optimal, and red is too high res. Occasionally errors will create purple when there is overlap or sever distortion.

In the case of correct mapping but incorrect scale, lightmap resolution should be changed from the default 64 to a size that shifts the color to green, done under "General Settings" -> "Light Map Resolution" in the the mesh details panel.

Please note you can change this setting at runtime and you see the color changing in the viewport, without the need to rebuild lights.

== Lightmap generation ==
If you use "Generate Lightmap UVs" setting, then Unreal will read the "Source Lightmap Index" (usually 0) where your base color UV are stored, and will generate a new lightmap UV to be stored in "Destination Lightmap index" (usually 1).

You still have to be sure that your "Light Map Coordinate Index" is pointing to the proper destination Index (example 1). This is the one used to generate the lightmap texture.

If you want to import custom UV lightmap, then you need to uncheck "Generate Lightmap UVs" setting and add a new UV layer in Blender to represent your lightmap UV. You can generate it in Blender using Data->UV Maps -> Add a new one, then use "Unwrap" -> "Smart UV Project". This will not create any overlapping UVs.

Official documentation is here:

https://dev.epicgames.com/documentation/en-us/unreal-engine/understanding-lightmapping-in-unreal-engine

== Others notes ==
For the purple errors, the mesh needs a lightmap unwrapped in blender, typically because it already has multiple internal UV maps and can't properly autogenerate to a new channel. To fix this, first make sure the correct channel is assigned, by looking at the mesh uv channels and determining if there is a proper lightmap channel already. These typically show every face mapped individually and quite small in a large array.

If there is no proper lightmap, open the mesh in blender and use unwrap lightmap uvs, making sure to unwrap to a new channel and not over the main texture channel. Once done, reimport without autogeneration of lightmaps on, and select the new channel for lightmap baking.

For LOD, or level of detail, unreal engine has a good auto LOD generator that can be used bot for distance meshes and higher quality collision meshes where appropriate. First, set the asset to the correct LOD group, which will auto generate the LODs. Then, check the new LODs and test them at their set distances to make sure the swap is clean between them, and that the generation process didn't distort the profile too much. If it did, play with the reduction settings by changing the percent decrease slider until you have the right balance.

Additionally, these new lower LOD models can be applied as a complex collision mesh, which for certain assets like buildings gives a better performance than using LOD0 as a complex collision mesh, but offers higher fidelity for things like columns that auto convex collision doesn't work well for.

Quest scripts syntax

2025-11-04T21:22:54Z

Talad: /* Prerequisites */

= Structure of a quest script =
Quests are written out in chunks called steps. Each step covering the requirements of the previous one.

= Things to know before you start =
Quest scripts should written ideally in a text editor and now in MS Word or similar so that no illegal characters make it into the quest dialog which would result in errors when viewed in game.

Quotes are usually the ones which break the scripts and :

• Only ' " should be used

• ‘ ’ ” “ … These should not be present in the text at all.

Any line of text in the script which begins with a ‘#’ character is ignored by the server and only acts as a comment by the author so that they can leave explanations as to what is happening, or, give information about the step number.

The start of a ‘step’ is defined by a series of three dots ‘...’ Everything after this text up until the next ‘...’ is included in the step. The only unique case is the first step, this does not need ‘...’ and includes all the text before the first ‘...’

== Important rules concerning steps ==

* Every step in the quest should be explicitly completed or locked correctly. Example: "Complete Quest Name Step #" before the Quest is completed.
* A step can require the completion of another step by the command: "Requires completion of Quest Name Step #"
* Step 1 does not exist, step 1 is part of the start script (where you use the command "give me a quest") and cannot be used as a require completion of step number.
* You may have multiple Require Completes at the beginning of a step.
* A step may also require another step NOT to have been completed with the command: "Require no completion of Quest Name Step #".
* The Quest name must be exact! It is case sensitive. The same goes for NPC names.
* Each step should be commented like this: "# Step 2 - A description of actions of this step". # Marks it as a comment not processed by the engine.
* You can also check for statements with this syntax: "Require <no/not> operator1 | <no/not> operator2 | ...| <no/not> operatorN." Where operator is a prerequisite (see below the prerequisite chapter), from completion of to time of day etc. The | represents the OR. ''Example: "Require completion of Questname Step 3 | completion of Questname Step 7."''

Let's see an example before beginning the explanation. The following example is made of two steps.

'''Example: Structure 1'''
P: Short Trigger.

Menu: Do you have any work for me to do?

NPC Name: Yes I do. Just breathe one time.

Assign Quest.

...

P: Ok, I did it!

NPC Name: Great, your quest is completed.

== Syntax Basics ==

=== Comments ===
To create a comment line you must start the line with a "#". These lines are not evaluated by the engine as things that need to be done. These comment lines show what is going on and what are the intentions of the quest writer. This is important because more than one person are often working on a quest script, or eventually for laterbug fixing it will be easier to find the exact problem without reading the entire quest.

Each step in a quest should be started by a comment like this "#Step 2 - Description of step.". You can use comments to more that just noting the step number. Any where within the script you can add comments to help your fellow scripters understand the code. We will use comments to explain things within the scripts here.

=== Trigger and Menu ===
The trigger is for the engine, while the menu is what shows up in the player quest menu. The trigger is defined by a "P:".

P: use to be what the player typed to trigger the step, but with the menu system are now used as a description of what step the player is choosing, for example P:yeshelp. (slide 3). The only time you must use exact text is when a player types the answer to a question you pose them

Because you are talking to the engine it must be exact a colon after the "P:" and a period at the end of the sentence. This is also true of the Menu in every case in which the player (P) says something to the NPC in question "P: Short Trigger." comes first, then below comes the "Menu:" line, with exactly the same requirements.

"Menu": Text is what the player sees when they look at the quest menu.

Please remember that the engine does not think, it reacts to the written cues, so the syntax MUST be exact. The first player statement gives the engine the quest name. The Menu allows the player to ask for the quest from the NPC.

Having the two "P:" and two "Menu:" on the same line informs the engine that the player has two different options. It is standard that the "P:" line is above the "Menu:" line and the "No." answer comes first.

These lines trigger the NPC response. In more elaborate quests the "Menu:" line may have variations on the No. or Yes. response. However remember KISS (Keep It Simple Stupid) is generally a good thing to keep in mind when you are beginning. You can have many options, but remember each "P:" must have a matching "Menu:" and they must be put in the same order

In order to include a free textfield, you will have to include a quotation mark after the menu. The <?> has to be followed by <=> and a text. This will produce a printout of the text and the user will be able to enter a free text. E.g. "Menu: ?=What shall Jardet do?" This will result in the text "What shall Jardet do?" being printed, followed by free form input.

P: *. P: rock pick.
Menu: ?=Please tell me your answer.
Smith: No, you didn't get the right answer.
Smith: Yes, it's a rock pick!.

P: Nothirstyinterst. P: Yesthirstyintrest.
Menu: No, sounds like work. Menu: Sure, I can get it for you.
Serana Tuvi: Alright. I will see you around then, stranger.
Serana Tuvi: Ah, good good.

'''Note:''' Remember the : after the P and Menu are important, as is the . at the end of the line.

'''Note:''' For triggers used to start quests, never use NPC names into it, because this will confuse the engine, and the trigger will not be recognized.

'''Note:''' Every P: used in one step must be on the same line

'''Note:''' Every Menu: used in one step must be on the same line

'''Note:''' Every NPC: used in one step must be on different lines.

=== NPC Response ===
Aono Rikas: here you can add a response.

The line above is interpreted as an answer from the NPC and the engine will extract the name before the colon (:) + space as the NPC involved in this step of the quest. From now on, we will call this a response.

The full name of the NPC is required, just the first name will not work. If it is only one name e.g Harnquist use that, and if your NPC somehow ends up with three names use all of them.

In the first step of a quest the NPC statement will end in a question mark and is triggered by the first 2 lines. Responses are linked to each of the Triggers and Menus. So if you have two triggers you need two menu options and two NPC responses. All arranged in the same order.

=== Dialogues ===
The dialogues are the most important part of the quest for a player to get immersed. So let us talk about how to make the dialogue.

* Every punctuation, exclamation mark and question mark will create a short pause in the dialogue and create a new line.
* To create actions all you have to do is to use square brackets within the dialogue like this "Blablabla [NPC Name picks his nose] Bla bla blabla"

You may use also these commands:

$playerrace can be used in an impersonal and a personal manner in terms of context, consider its usage carefully.

$sir which gives you "Sir" or "Madam" or "Gemma" depending on the gender of the player's character. Again, this can be used to positive and negative effect. Be mindful of the NPCâ€™s tone. (Gemma is the honorific for Kran.)

$playername clearly not to be used in newbie quests, have NPC establish rapport use this in second quest or even the third time a player works with a given NPC.

Give me a quest..

= A sample quest script =

== The first step ==
As previously mentioned Step 1 does not exist, it is just the start of the quest, and can not be required by subsequent steps. The Start of the Quest will look something like the example at the beginning (Structure 1).

The same example can also be scripted like this:

'''Example: Structure 2'''
P: Short trigger.

Menu: Initial question, give me a quest.

NPC Name: Yes, I do have a quest for you. I need you to give Item of Importance to NPC2 Name.

P: Yes P: No.

Menu: Yes, I will do that. Menu: No way stupid.

NPC Name: This is the response from the NPC if answer is Yes.

Give 1 Item of Importance.

Assign Quest.

NPC Name: This is the response from the NPC if answer is No.

In Structure 2 the answers "No" and "Yes" are inverted, like the two "Menu:" commands, so it will give the same result as Structure 1. (Answer No: nothing happens. Answer Yes: the player will get 1Item of Importance and the Quest.)

Now, let us use a more detailed example. We will make a very simple quest: Aono wants to deliver a bottle of milk to Orchibaly. The player can choose the quest from Aono's quest menu. Orchibaly will then give the player 2 pies and a receipt to give back to Aono. The first step will be the step that assigns the quest. The P: tells the engine that this line represents something the player will say to the NPC, but what you must pay extra attention to is the "Menu:" This will be what the player will see as an option in the quest menu. If there are several options you will have to create one "P:" and a "Menu:" for each of them.

Here we firstly gives the player the option to ask for the quest. Then Aono describes the nature of the quest and the player can choose yes or no. Right after the "Menu:" line the NPC responsewill be put. In this example Aono will reply: "Well, I will get someone else to do it for me." if the player says no or "That's great. Here is the milk. Be sure not to spill it. TellOrchibaly I sent you.", give the player 1 Milk Bottle and assign the quest.

'''Example: Assign Quest'''
# Quest: Delivery for Aono Rikas

# Quest Description: Sample Quest.

# The rest of the header will not be covered here.

# Step 1 Aono Rikas in Hydlaa needs someone to deliver milk to Orchibally Gurpleferd in Ojaveda.

P: Delivery for Aono Rikas.

Menu: Are there any jobs you need done?

Aono Rikas: Well, yes. I need some milk delivered to Orchibaly in Ojaveda. Can you do this for me?

P: No. P: Yes.

Menu: No. Menu: Yes.

Aono Rikas: Well I will get someone else to do it for me.

Aono Rikas: That's great. Here is the milk. Be sure not to spill it. Tell Orchibaly I sent you.

Give 1 Milk Bottle.

Assign Quest.

A quest can be automatically assigned or there can be a step at the beginning of the quest to ask the player if he accepts it.

If you want to assign it automatically use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here.
Assign quest.

If you want to ask the player use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here, with the question if you want to help.
P: nohelp. P: yeshelp.
Menu: I don't want to. Menu: Yes I will help.
NPC: Fine... Go away.
NPC: Good great.
Assign quest.

'''Note:''' The “Assign quest.” command will only trigger after the second NPC: dialogue line is triggered, nothing happens if the first is triggered.

== The next step ==
To separate the step we use "..." and then a comment on what step it is and what the step is about. If you don't want this step to be repeatable you will also have to add "NoRepeat" after the "...". The second step does not need a completion of Step 1, because Step 1 does not exist so to speak. The structure will be more or less the same as for the initial step.

Let us continue our Delivery for Aono Quest. We have assigned the quest and the player has been given 1 Milk Bottle to give to Orchibaly. Now the player must give that milk to Orchibaly. Either by using the give GUI or by using the quest menu. The first thing we have to do here is to set up the give trigger. If the player gives Orchibaly the milk, he will answer "Oh, yes the milk. Please give it to me. Now i need you to deliver these two pies and this receipt back toAono.", Give the player 2 pies and a Receipt from Orchibaly. The step is then completed.

In this example although the player is given two pies no "s" is added to the line. This is important, especially because most writers tend to add a plural automatically to plural items. Remember the engine does not. An item is designated in the singular, the engine always interprets it in the singular regardless of the number included. The numbers are again not spelt out and Arabic numerals used. Remember that each "Player gives"-command must have menu option in the next line.

'''Example: Step 2'''
... NoRepeat

# Step 2 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this bottle of milk.

Orchibaly Gurpleferd: Thanks, please give it to me. Now deliver two pies and a receipt back to Aono.

Give 2 Pie. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 2.

Completing a step

At the end of a step remember to insert the line:

"Complete Delivery for Aono Rikas Step 2."

Note the use of Capitals, the use of the quest name, the use of the appropriate numeral and the period at the end of the sentence. The line marks the step as complete and allows the player and the quest to move forward.

== Last step ==
To make sure the player has completed the previous step we start with "Require completion of delivery for Aono step 2.". Then we move on to the trigger which is the player giving 2 pies and the receipt to Aono. Aono answers "Ah, pie. Thank you. Please accept this for your time.", gives the player a pie and 100Tria. The step is closed and so is the quest with "Complete Delivery for Aono Rikas."

'''Example: Last Step'''
...NoRepeat.

# Step 3 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of delivery for Aono step 2.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here are your pies and your receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

'''NOTE:''' If you use multiple options in the last step of a quest you have to explicitly complete the quest with a command for the first option.

'''Example: Last step with multiple options'''

P: No. P: Yes.

Merchant: Quest doesn't complete automatically so make sure you have added a complete line for this response.

Complete Harnquist Needs Gold Step 2. Complete Harnquist Needs Gold.

Merchant: Quest completes automatically because it is the last line in quest so no complete line is required.

Complete Harnquist Needs Gold Step 2.

If you omit the Complete Step and Complete Quest line, the quest will not end properly when choosing "no".

== Branches of a quest (Non exclusive) ==
Some times you want to have several different outcomes for a quest. Let us use the Delivery quest once again. If the first NPC says that you must NOT give the milk to some one else... specially NPC3. Then you should also add the option for the player to actually give the milk to NPC3 . This will complicate your script a bit, but is not as hard as it might seem. Most of the job is done by placing the right "Require completion of" and "Require no completion of" commands.

Let us take a look at that Delivery Quest again. Now we want to add an option for the player to give the milk to Reffitia instead. Reffitia will shake the milk until it becomes butter and this will make Orchibaly angry and demand a new bottle of milk. To do that we will have to add a few more steps and we will start from step 2 as step 1 will be the same as above.

The Third step will be our previous Step 2. And the last step will be the same. Though Aono should mention something like: "Make sure you don't give that milk toReffitia." in Step 1.

IMPORTANT NOTE: This is a non exclusive branching, meaning that the first branch is available also when executing the second one.

IMPORTANT NOTE: We will not add an additional step for the player to get milk again from Aono, but the player have to figure out another way to get hold of it (Buy from an NPC).

'''Example: Branching'''
... NoRepeat

# Step 2 - Alternative is to give the milk to refittia

Player gives 1 Milk Bottle to Reffitia

Menu: Here Reffitia, take this milk.

Reffitia Thamal: Ah! Orchibaly's milk. Here, now you can give the bottle to Orchibaly.

Give 1 Bottle of Butter.

Complete Delivery for Aono Rikas Step 2.

... NoRepeat

# Step 3 - Player gives bottle of butter to Orchy.
# The player then have to find another way of getting a bottle of milk (buy from NPC?)

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 4.

... NoRepeat

# Step 5 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Alternative outcome ==
If we wanted the quest to have a different outcome if the player gives the milk to Reffitia than to Orchibaly we would need to get creative with the require commands. Let us say that if the player gives butter to Orchibaly he will give "bad pies" so when Aono receives them and takes a taste he will be very angry and no reward is given. To do this we will have to add just one more step. Let us start with step 3. Here we will have to change only the NPC response a bit to something like "Milk? This is butter. Have you been shaking the bottle all the way over here? This is completely useless to me, butter I have more than enough of. Any way someMenki came with another bottle just before you. Here takes these pies to Aono . Oh, and don't forget this receipt.". Step 4 will be the step where the player gives the bad pies to Aono, this step will complete the quest. Step 5 and 6 are the outcome if the player gives the milk directly toOrchibaly. Notice that Step 5 require a NO completion of Step 4. This is actually not necessary for this script, because the previous the other branch of the quest, ending in step 4 closes the quest it self.

'''Example: Alternative Outcome'''
# Step 3 - Player gives bottle of butter to Orchy. And receives 2 pies and a receipt

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Give 2 Pie. Give 1 Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the "bad" pies and the receipt to Aono. Receives gunk as reward and Quest is completed.

Require completion of Delivery for Aono Rikas Step 3

Player gives Orchibaly Gurpleferd 2 Pie, 1 Receipt from Orchibaly.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. [Aono takes a bite at the pie] You have tricked me!

Give 1 Gunk.

Complete Delivery for Aono Rikas Step 4.

Complete Delivery for Aono Rikas.

...
# Step 5 - Player gives the milk directly to Orchibaly.

Require no completion of Delivery for Aono Step 4.

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 5.

... NoRepeat

# Step 6 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Quest Timeout (Passing of time) ==
If you want to allow a certain part of the quest to wait a certain amount of time before it can be a executed, you can use this script:<blockquote>Run script give_quest_timeout <<'Time until Harnquist is ready',6>></blockquote>this will create a temporary active magic with name 'Time until Harnquist is ready' which will last for 6 minutes.

Then in the prerequisite of the step have this:<blockquote># Step 12.

Require active magic Time until Harnquist is ready.

P: swordnotready.

Menu: Is Vresa's sword ready yet?

Harnquist: No, not yet.

...

# Step 13.

Require no active magic Time until Harnquist is ready.

P: about Vresa sword.

Menu: Is Vresa's sword ready?

Harnquist: Yes, Vresa's sword is done. </blockquote>

= Important commands and expressions used =

== Assign Quest. ==
This line tells the engine to assign the quest to the player and generally results in the "YOU GOT A QUEST". and placing the quest in the player's quest log, under "uncompleted". Again remember to be exact here, Capitalize the two words and put a "." at the end. It cannot be emphasized enough that the engine only interprets what it sees and the way it sees it. If you are not precise the quest will NOT happen or in the cases of the next steps move forward.

== ... ==
The three dots mark the beginning of a new step. Better, the three dots create a new step. So you need a "three dots" line before every "Complete Quest Name Step #"

== NoRepeat. ==
This line means that the quest step cannot be done over and over. Note that there are three periods "..." a space and 'NoRepeat.' is one word not two. Each part of this sentence is required in exactly this form.

Basically "..." tells the engine that some time can pass before the next lines are used.

NoRepeat allows this quest step to be only done one time. This also applies to actions as seen in later steps. (in reality NoRepeat is a synonym for Require no completion of "this step")

== Require completion of Quest Name Step #. ==
This command is like a closed door. To open it and enter in the current step the player needs to complete the step number #. You can also refer to a future step (for example, you're on step 4 and add "Require completion of Quest Name Step 8.")

== Require no completion of Quest Name Step #. ==
This command is like an open door. The player is free to continue the quest and entering the current step, UNLESS he completed the step number #. Completing the step number # will close the door. Forever! You can also refer to a future step.

== Complete Quest Name Step #. ==
This command completes a step, # being the step number. You can complete one step in another one. But remember to insert one "..." line for every "Complete Quest Name Step #." line.

== Complete Quest Name. ==
This command will end the quest. After this the quest will be deleted from the uncompleted quest list and appear in the Completed quest list.

== P: ==
The trigger is actually a ghost from the previous scripting system, but it is still needed (for now). Before the player had to type the exact trigger stated after the "P:". Now they click the option from "Menu:". Triggers must be four words or less. Triggers must end with a period, no other punctuation is allowed (question marks especially are known to break aquest on the server).

If you want multiple phrases to activate the same trigger, you can just separate the phrases by a period; for example: "P: about guards. about hydlaa guards. about hydlaa militia." In this case the NPC's response will be fired on any of the three options. This technique can be used also when you have multiple choices: "P: one. two. P: more.". Both 'one' and 'two' will trigger the first response, while 'more' will trigger the second.

WARNING: Triggers cannot contain any of the following words: a, am, an, and, any, anything, are, do, I, is, isnâ€™t, please, that, the, this, to, too.

They also may not contain the name of the NPC you're talking to as that'll be stripped.

These words just take up space in a trigger as they are dropped by the engine when evaluating player response. To make the best use of your word counts ignore them when writing your triggers.

Example: If you wanted the player to say 'please help Levrus' the trigger would become 'help levrus' as please would be an ignored word.

WARNING: If a player needs to write "NPC needs this" syntax it as "NPC wants this".

== Menu: ==
That's easy. After this command you can add the sentence said by the player in game. This sentence will appear on the screen and could be selected when one talks to the NPC.

Remember that for every menu line you need to create a response from the NPC.

== Give ==
Give is a very useful command. It tells the engine to give the player items. Be it rewards or special items needed for the quest. When you reward a player, you can basically give items and/or experience. The syntax to award 1500 experience points would be: "Give 1500 Exp." Note that "Exp" is case-sensitive. You can also reward items AND experience, using this syntax: "Give Leather Gloves. Give 1500 Exp." Remember that you can only have two give commands on the same line, but you can have multiple lines, Remember to keep a clean style, it is prefered to only have one item per line.

'''Example: Give more than two items'''
Give 1 Leather Gloves.
Give 1500 Exp.
Give 1 Apple.

You can also add a number if you need to give more than one item (like you do for experience) example: "Give 5 Iron Ingot." It is not necessary in the case of one item to include the numeral, however it is good practice to do so as numerals tell the engine how many and should be written as a numeral, a word will NOT work as the engine cannot interpret it as such. Remember that all special items must be declared in the script header.

Another option you have is to give one item OR another. The following will pop up a window in which the player has to choose just one item:

'''Example: Give the player a choice between items'''
Give Cold or Arrow or Energy.
'''WARNING:''' At this time, don't use the following in an OR option: Tria, hexa, octa, circles, or items without a graphic. Also, for now, do NOT put quantities in front of items that are given using the "OR" parameter. An example of what NOT to do: "Give 1 Cold or 1 Arrow or 1 Energy." This will lock the server right up. An example of what SHOULD be done: "Give Cold or Arrow or Energy." (Check this statement if it is correct. --Katu)

== Player gives NPC Name 1 Item ==
This can be used as a trigger (instead of the "P:"). It tells the engine to trigger the NPC dialogue when one or any fixed amount of a special item.

When a player have to give multiple items just add them to the original line using a comma:

'''Example Player gives item'''
Player gives Harnquist Water Pouch, 1 Pie.

'''WARNING:''' Item name rules must be followed at all times.

Notice that the item name is "Iron Ingot", so "Iron Ingots" will not work, even if itâ€™s the correct plural form. Keep all names singular.

Also, do not use a number (3, 14, etc) in the name of an item. An item called 3 Circles Receipt will probably generate problems when we script "Give 3 Circles Receipt." It is better named "Three Circles Receipt."

Numbers should be spelled out everywhere unless you are referring to the quantity given or dealing with a trigger (give me 5 apples. give me five apples.) as both would be correct in a trigger.

Character limit for an item name is 60 characters.

Do not use an s' in an item name, like "Levrus' Left Shoe," use "Left Shoe of Levrus" or a similar substitute instead.

== Set variable Require variable ==
You can set a variable to be later used by the quest or other quests. Variables are set on the character and visible from all quests.
Smith: Here is your winch access
Setvariable Quest_Winch_Access 1

You can then require a variable to be set as prerequisite of a quest step.
Require variable Quest_Winch_Access.
P: access.
Menu: I have access
Bobaus: Ok, good.

== Require Compendium ==
You can require the player to have a certain knowledge in the Compendium.
Require compendium creature StoneHammer
P: comps
Menu: I know everything about the StoneHammers!
Fighter3: WOW
...
Require no compendium creature StoneHammer
P: nocomps
Menu: Sorry I dont know anything about StoneHammers!
Fighter3: Ah, study more!

The syntax is: compendium <creature/plant/mineral> <name>

== Rewards at the end of the quest ==
When completing a quest, the player usually gets experience and money, or some items. In particular for experience and money you should use the following scripts. This allows us to split the rewards on a scale from 1 to 10 and then to tweak the actual values in the engine. The values in brackets indicate the complexity of the quest. The more complex the more rewards the player will get.

Run script give_quest_money <<3>>.
Run script give_quest_exp <<2>>.
You can also award faction points by using "give_quest_faction" , the number given is multiplied by 5 so if you want +5 point, you need 1 on the second parameter:
Run script give_quest_faction <<'Essential Trail', 1>>.
We have script also to push the faction point up to a given value, if you are already higher, this script will do nothing.
Run script give_quest_faction_level <<'Essential Trail', 2>>.
value = 1-> max faction points = 10;

value = 2-> max faction points = 20;

value = 3-> max faction points = 35;

value = 4-> max faction points = 55;

value = 5-> max faction points = 75;

value = 6-> max faction points = 100;

value = 7-> max faction points = 125;

value = 8-> max faction points = 150;

value = 9-> max faction points = 200;

If you want to assign a faction title you can use this script. In the example it will assign the second title.
Run script give_quest_faction_title <<'Essential Trail', 2>>.

=== The header ===
The header should contain a lot of information. All the information is commented out by a "#". The example below is from one of the mount quests.

First section is information about the quest itself. Name of the quest, a short description and category. Categories will be discussed in detail later on.

The next sections are for unique items used in the quest, name of the item followed by the description.

The third section is for recording versions of the script and all naming authors. Also who last edited the quest should be noted.

The last section is for additional metadata which will be added to the quest in the database (not part of the db) and will be used by the engine to determine lockouts and prerequisites. Here it locks all players from doing the quest again and locks all other players to take the quest with 60 seconds.

Lastly we tell the engine that the player have to complete the Ring of Familiar quest before this one. Note that these comments aren't taken by the engine; it's the duty of who loads the quest to fill the correct entries with the data found in the header: so it's just a way to keep all data together on the script.

'''Example: Header'''
# Quest name: Drifting for a Drifter
# Quest Description: Taemian wants to sell you a mount
# Quest Category: General
# ----------------------
# Quest Items: Item name/Item description
# Taemian's Pouch: - Pouch with all sorts of coins
# Green Gem of the Drifter - A magical gem with a green glow
# Unsigned Drifter Permit - A permit that still needs to be signed by Datal
# Signed Drifter Permit - A permit that has been signed by Datal
# ----------------------
# Variables used in this quest
# ----------------------
# Quest specific variables used in this quest
# ----------------------
# Author(s): Ravna, Katu, weltall
# Current Version: 1.01
# Player lockout: -1
# Quest lockout: 60
# Prerequisites: <nowiki><pre><completed quest="Ring of Familiar"/></pre></nowiki>
# Variables used: Quest_Variable_Name used to do.....
# ----------------------
# Version history and change log
# Last edited by: weltall
# Version 1.00: Initial draft - 05/01/2010 - Katu.
# Version 1.01: Added extra steps - 1/22/2011 - Venalan.
# ----------------------

==== Quest Lockouts ====
Each quest has two different lockout types:

* Player lockout: When this parameter is set, the engine will wait the specified amount of seconds before allowing the same player to redo the same quest. If you want a quest to be available to each player only one time, then set the lockout to -1. Setting it to 600 will have the engine wait 10 minutes before unlocking the quest again.
* Quest lockout: When this parameter is set, the engine will wait the specified amount of seconds before reactivating the quest for ALL players. This means no one can start the same quest during this period, but the ones that had it already active can complete it.

Usually we want quests to be unique to players, so most have a player lockout -1, except the very simple ones. Try always to think if itâ€™s meaningful for that player to redo it. (For example, Harnquist can require iron ore more than once, but won't need to teach you how to make a sword more than once.)

=== Prerequisites ===
Another more complex version of the prerequisites is the: REQUIRE MIN <number>: this tells the engine that there are specific requirements to be fulfilled before the player is able to get the quest. This script indicated it requires a minimum number of quests to be completed in a given list.

Example: require min 2 of Quest1, Quest2, Quest3.

To match this prerequisite the player can complete Quest1 and Quest3 or 2 and 3, or all 3. The request is minimum 2 in the given list.

CATEGORY MIN <number>: quests have an attribute called "category", we use it to identify the difficulty of quests, but can be used of any other purpose, for example one can say that a group of quests is "Evil" or "Laanx related" or " Newbie". Just one category is allowed per quest. This prerequisite allows you to specify the category and the minimum number of quests completed in that category.

A sample of the coding used to set prerequisites for a quest (All on one line):

'''Example: Prerequisites'''
<nowiki><pre><and></nowiki>
<completed quest="Test Quest One"/>
<completed quest="Test Quest Two"/>
<completed quest="Test Quest Three"/>
<assigned quest="Test Quest Four"/>
<not><completed quest="Delivery for Aono Riskas"/></not>
<not><completed quest="Gorbiak Disease"/></not>
</and><nowiki></pre></nowiki>

This sample requires that the player have completed Test Quests 1 through 3, have Test Quest 4 assigned (not completed) and have NOT completed Fancy Dancing and High-Class Aspirations. To get these arranged correctly can take some practice if one is not familiar with working with booleans, so it is best to include a plain-English comments of what you wish your pre-requisites to be in addition to the one with the "pre" coding statements.

Checks if the player has a certain item equipped . To be documented better

else if (!strncasecmp(block,"equipped",8))

=== Untested Prerequisites ===
Please contact engine in case you want to use any of these prerequisites, because those are untested.

"time of day" // require time of day starthh-endhh (working)

"trait" //require trait name in place

"guild" //NOTE: the both argument is implicitly defined

"active magic" (working)

"known spell"

"race" (working)

"gender" (working)

"married"

"possessed" (working)

"skill" //Require skill <buffed> name <skillmin>-<skillmax>. (working)

"variable" //Require variable name. (working)

= Notes on Creating Quest Files (Rules and Header Information) =

* The quest documents you submit should always be in notepad format: this is to avoid special characters added by Word or other text editors, most notably "smart quotes" which will appear as squares in game. Notepad++ is recommended, HIGHLY recommended.
* Use only ANSI encoding.
* The file name when saving the quest should begin with 'Quest' , then have the name of the quest. For example: Quest Hinoserri Cannot See.txt
* Titles of quests should follow some scheme of capitalization. There are many sets of rules, but a quick and easy format is to capitalize the first word and then all other words, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor.
* Each quest script begins with the title and a one or two sentence description; this is what the player reads so keep that in mind. The proper way to do this is to "comment out" your description and quest title, this is done by beginning a line with the number sign or pound symbol (#). Also, any quest item created for your quest should have a description written into the quest. Notes on quest items should also be commented out. Lastly, there should also be a "Quest Category" line that must be commented out as well. Approved quest categories are: Alchemy, Black Flame, Chain (don't use this one unless told), Cooking, Death Realm, Easy, Gugrontid, Magic Ways, Medium, Metal Working, Newbie, Repeatable. This is a work in progress, so if you have any questions ask an associate dev or developer. No quest can have more than one category - pick one and ONLY one. New quest categories must be approved by the associate devs/devs before use.

Random Generated events

2025-08-20T14:20:34Z

Talad: /* All Tags */

A new capability has been added to PSUnreal about generating random events in the game.

==== Event location ====
An event is defined to happen in an "area type", it can be for example "forest" or "tavern" or specific location. There is relationiship beween [[Random eventsTable|random_events]].area and [[Random event locsTable|random_event_locs]].event_areatype.

If you want the event to happen in a specific path network waypoint, you can specify a [[Random eventsTable|random_events]].area with this syntax: wp:<waypoint1|waypoint2|...>

==== Event Probability ====
In addition there is also [[Random event locsTable|random_event_locs]].event_probability which is a % of chance of that event happening.

Database structure:
* [[Random eventsTable|random_events]] table

Scripting:
* Prerequisites (random_events.prerequisite)
** The same syntax of quest prerequisites can be used with the following additions:
*** <skillsinrange name="Sword" min="10" max="20" range="10"> (works as skill but checks all the players in range and sum up their skills). If the name is empty it sums up the total skills of all players in range.
* Script for the event (random_events.script)

==== Race and traits ====
Race and traits are numerical as defined in the database. Maybe in the future we make it text. Check [[Races and Traits IDs|here]] for the list.

==== Options: ====

* You can specify a name and lastname in the <spawnnpc> tag, if omitted the NPC will have a random name and lastname.
* You can have a description, useful if you are specifying the name and the race of the NPC. If not specified it will empty.
* You can specify certain traits, if missing, the server will randomize by choosing the ones available for the given race.
'''Inventory:'''

The valid locations for inventory items are: "righthand,lefthand,helm,rightfinger,leftfinger,neck,back,arms,gloves,boots,legs,belt,bracers,torso,mind" . For bothhands we need TO CHECK it.

==== Example: ====
<nowiki><time seconds="0"></nowiki>
<spawnnpc id="1" name="Erisal" lastname="Baloe" race="0|1|2|3|5|6|7|9|10|11" invulnerable="yes" hp="400" mana="400" loot_category="22" locx="1" locy="1" locz="0" description="A young dermorian girl, with a nice smile." traits="42|363|380">
<inventory>
<item name="Small Battle Axe" location="righthand"/>
<item name="Falchion" location="bulk1" quantity="65"/>
<item name="Chainmail Legs Armor" location="legs"/>
</inventory>
<skills>
<skill name="Sword" value="50"/>
</skills>
<stats str="80" agi="70" end="60" int="75" wil="55" cha="90"/>
<kas>
<ka name="Merchant" priority="1"/>
</kas>
<specifickas>
<trigger trigger="greetings" response1="Hello" response2="How are you?"/>
</specifickas>
<merchant>
<category name="Weapons"/>
<category name="Armor"/>
</merchant>
<trainer>
<skill name="Strength" min_rank="0" max_rank="20" min_faction="0"/>
</trainer>
<factions>
<faction name="orcs" value="50"/>
</factions>
<variables>
<variable name="scale" value="1.5"/>
</variables>
<npctype name="performer" parent="Fighter" >
<behavior name="start_show" completion_decay="0" growth="0" initial="0">
<emote cmd="/bow" />
<talk text="Welcome to my show" target="false" />
<busy/>
</behavior>
<behavior name="show" completion_decay="0" growth="0" initial="0">
<emote cmd="/greet" />
<wait duration="30" anim="play" />
</behavior>
<behavior name="showidle">
<idle />
</behavior>
</npctype>
</spawnnpc>
<spawnitem id="2" name="Long Bow" pickup="yes">
<location x="1" y="1" z="0"/>
</spawnitem>
<nowiki></time></nowiki>
<nowiki><time seconds="30"></nowiki>
<trigger behavior="start_show" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="45"></nowiki>
<trigger behavior="show" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="60"></nowiki>
<trigger behavior="showidle" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="70"></nowiki>
<destroynpc id="1"/>
<destroyitem id="2"/>
<schedulenext/>
<nowiki></time></nowiki>

== All Tags ==

'''<code><nowiki><time></nowiki></code>'''

* Defines a timed step of the event.
* '''Attributes:'''
** <code>seconds</code> → number of seconds after the event start when this block of actions should be executed.
* '''Children:''' can contain
** <code>spawnnpc</code>
** <code>spawnitem</code>
** <code>trigger</code>
** <code>destroynpc</code>
** <code>destroyitem</code>
** <code>schedulenext</code>
** <code>message</code>
** <code>sound</code>
----

'''<code><spawnnpc></code>'''

* Spawns a new NPC into the event.
* '''Attributes:''' handled in <code>psRandomEventsNPC::LoadXML()</code>

'''Attributes:'''
* <code>id</code> → '''(required)''' numeric identifier for this NPC within the event. Must be non-zero.
* <code>name</code> → optional first name. If empty, a random name will be generated.
* <code>lastname</code> → optional last name.
* <code>race</code> → '''(required)''' one or more race IDs (separated by <code>|</code>). All races must exist in the database.
* <code>description</code> → optional text description of the NPC.
* <code>invulnerable</code> → <code>"yes"</code> or <code>"no"</code>. Determines if the NPC can be damaged.
* <code>HP</code> → starting hit points.
* <code>Mana</code> → starting mana points.
* <code>loot_category</code> → numeric loot category ID used for drop tables.
* <code>locx</code>, <code>locy</code>, <code>locz</code> → spawn location coordinates.
* <code>rot</code> → rotation (facing direction) in degrees.
* <code>traits</code> → optional set of trait IDs, separated by <code>|</code>. Only valid if a single race is defined.

'''Child Tags:'''

* <code><inventory></code>
** Contains <code><item></code> entries.
** '''Attributes (item):'''
*** <code>name</code> → item name (must exist).
*** <code>location</code> → inventory slot name (must exist in slot hash).
*** <code>quantity</code> → number of items.
* <code><skills></code>
** Contains <code><skill></code> entries.
** '''Attributes (skill):'''
*** <code>name</code> → skill name (must exist).
*** <code>value</code> → starting value.
* <code><kas></code>
** Contains <code><ka></code> entries.
** '''Attributes (ka):'''
*** <code>name</code> → knowledge area name (must exist).
*** <code>priority</code> → priority number.
* <code><specifickas></code>
** Contains <code><trigger></code> entries.
** '''Attributes (trigger):'''
*** <code>trigger</code> → text that activates the response.
*** <code>response1..5</code> → one or more response lines. <code>response1</code> must be present.
* <code><merchant></code>
** Contains <code><category></code> entries.
** '''Attributes (category):'''
*** <code>name</code> → merchant category name (e.g., <code>"Weapons - Shortsword"</code>).
* <code><trainer></code>
** Contains <code><skill></code> entries.
** '''Attributes (skill):'''
*** <code>name</code> → skill name (must exist).
*** <code>min_rank</code> → minimum rank the trainer teaches.
*** <code>max_rank</code> → maximum rank.
*** <code>min_faction</code> → minimum faction value required.
* <code><factions></code>
** Contains <code><faction></code> entries.
** '''Attributes (faction):'''
*** <code>name</code> → faction name (must exist).
*** <code>value</code> → starting standing with that faction.
* <code><variables></code>
** Contains <code><variable></code> entries.
** '''Attributes (variable):'''
*** <code>name</code> → variable key.
*** <code>value</code> → variable value (string or number).
* <code><npctype></code>
** Defines NPC brain/type using external <code>NPCType</code>. Attributes/structure depend on <code>NPCType::Load()</code>.

----'''<code><spawnitem></code>'''

* Spawns a new item into the event.
* '''Attributes:''' handled in <code>psRandomEventsItem::LoadXML()</code>

'''Attributes:'''
* <code>id</code> → '''(required)''' numeric identifier for this item within the event. Must be non-zero.
* <code>name</code> → '''(required)''' item name (must exist in database).
* <code>pickup</code> → <code>"yes"</code> or <code>"no"</code>. Determines if the item can be picked up by players.

'''Child Tags:'''

* <code><location></code>
** '''Attributes:'''
*** <code>x</code>, <code>y</code>, <code>z</code> → world coordinates where the item should spawn. (Values are multiplied by 100 internally to convert to centimeters.)

----'''<code><trigger></code>'''

* Sends a behavior trigger to a spawned NPC.
* '''Attributes:'''
** <code>behavior</code> → name of the behavior to trigger (e.g., <code>"start_show"</code>).
** <code>npc</code> → the numeric ID of the NPC that should execute this behavior.

----'''<code><destroynpc></code>'''

* Removes an NPC from the event.
* '''Attributes:'''
** <code>id</code> → numeric ID of the NPC to destroy.

----'''<code><destroyitem></code>'''

* Removes an item from the event.
* '''Attributes:'''
** <code>id</code> → numeric ID of the item to destroy.

----'''<code><schedulenext></code>'''

* Marks that after this timed step, the next event in the sequence should be scheduled automatically.
* '''Attributes:''' none.
----'''<code><message></code>'''

* Sends a message to the client visible on screen and in the chat
* '''Attributes:'''
** <code>text</code> → the text to display

----'''<code><sound></code>'''
* Plays a sound to the client visible on screen and in the chat
* '''Attributes:'''
** <code>sound</code> → the sound to play
** <code>location</code> → can be "player" or "event". If "player" the sound will be centered on the player, if "event" it will be at the starting location of the event
** <code>attenuation</code> → If the sound should use 3d spatial attenuation or not

Random Generated events

2025-08-20T13:44:18Z

Talad: /* All Tags */

A new capability has been added to PSUnreal about generating random events in the game.

==== Event location ====
An event is defined to happen in an "area type", it can be for example "forest" or "tavern" or specific location. There is relationiship beween [[Random eventsTable|random_events]].area and [[Random event locsTable|random_event_locs]].event_areatype.

If you want the event to happen in a specific path network waypoint, you can specify a [[Random eventsTable|random_events]].area with this syntax: wp:<waypoint1|waypoint2|...>

==== Event Probability ====
In addition there is also [[Random event locsTable|random_event_locs]].event_probability which is a % of chance of that event happening.

Database structure:
* [[Random eventsTable|random_events]] table

Scripting:
* Prerequisites (random_events.prerequisite)
** The same syntax of quest prerequisites can be used with the following additions:
*** <skillsinrange name="Sword" min="10" max="20" range="10"> (works as skill but checks all the players in range and sum up their skills). If the name is empty it sums up the total skills of all players in range.
* Script for the event (random_events.script)

==== Race and traits ====
Race and traits are numerical as defined in the database. Maybe in the future we make it text. Check [[Races and Traits IDs|here]] for the list.

==== Options: ====

* You can specify a name and lastname in the <spawnnpc> tag, if omitted the NPC will have a random name and lastname.
* You can have a description, useful if you are specifying the name and the race of the NPC. If not specified it will empty.
* You can specify certain traits, if missing, the server will randomize by choosing the ones available for the given race.
'''Inventory:'''

The valid locations for inventory items are: "righthand,lefthand,helm,rightfinger,leftfinger,neck,back,arms,gloves,boots,legs,belt,bracers,torso,mind" . For bothhands we need TO CHECK it.

==== Example: ====
<nowiki><time seconds="0"></nowiki>
<spawnnpc id="1" name="Erisal" lastname="Baloe" race="0|1|2|3|5|6|7|9|10|11" invulnerable="yes" hp="400" mana="400" loot_category="22" locx="1" locy="1" locz="0" description="A young dermorian girl, with a nice smile." traits="42|363|380">
<inventory>
<item name="Small Battle Axe" location="righthand"/>
<item name="Falchion" location="bulk1" quantity="65"/>
<item name="Chainmail Legs Armor" location="legs"/>
</inventory>
<skills>
<skill name="Sword" value="50"/>
</skills>
<stats str="80" agi="70" end="60" int="75" wil="55" cha="90"/>
<kas>
<ka name="Merchant" priority="1"/>
</kas>
<specifickas>
<trigger trigger="greetings" response1="Hello" response2="How are you?"/>
</specifickas>
<merchant>
<category name="Weapons"/>
<category name="Armor"/>
</merchant>
<trainer>
<skill name="Strength" min_rank="0" max_rank="20" min_faction="0"/>
</trainer>
<factions>
<faction name="orcs" value="50"/>
</factions>
<variables>
<variable name="scale" value="1.5"/>
</variables>
<npctype name="performer" parent="Fighter" >
<behavior name="start_show" completion_decay="0" growth="0" initial="0">
<emote cmd="/bow" />
<talk text="Welcome to my show" target="false" />
<busy/>
</behavior>
<behavior name="show" completion_decay="0" growth="0" initial="0">
<emote cmd="/greet" />
<wait duration="30" anim="play" />
</behavior>
<behavior name="showidle">
<idle />
</behavior>
</npctype>
</spawnnpc>
<spawnitem id="2" name="Long Bow" pickup="yes">
<location x="1" y="1" z="0"/>
</spawnitem>
<nowiki></time></nowiki>
<nowiki><time seconds="30"></nowiki>
<trigger behavior="start_show" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="45"></nowiki>
<trigger behavior="show" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="60"></nowiki>
<trigger behavior="showidle" npc="1"/>
<nowiki></time></nowiki>
<nowiki><time seconds="70"></nowiki>
<destroynpc id="1"/>
<destroyitem id="2"/>
<schedulenext/>
<nowiki></time></nowiki>

== All Tags ==

'''<code><nowiki><time></nowiki></code>'''

* Defines a timed step of the event.
* '''Attributes:'''
** <code>seconds</code> → number of seconds after the event start when this block of actions should be executed.
* '''Children:''' can contain <code>spawnnpc</code>, <code>spawnitem</code>, <code>trigger</code>, <code>destroynpc</code>, <code>destroyitem</code>, <code>schedulenext</code>.

----

'''<code><spawnnpc></code>'''

* Spawns a new NPC into the event.
* '''Attributes:''' handled in <code>psRandomEventsNPC::LoadXML()</code>

'''Attributes:'''
* <code>id</code> → '''(required)''' numeric identifier for this NPC within the event. Must be non-zero.
* <code>name</code> → optional first name. If empty, a random name will be generated.
* <code>lastname</code> → optional last name.
* <code>race</code> → '''(required)''' one or more race IDs (separated by <code>|</code>). All races must exist in the database.
* <code>description</code> → optional text description of the NPC.
* <code>invulnerable</code> → <code>"yes"</code> or <code>"no"</code>. Determines if the NPC can be damaged.
* <code>HP</code> → starting hit points.
* <code>Mana</code> → starting mana points.
* <code>loot_category</code> → numeric loot category ID used for drop tables.
* <code>locx</code>, <code>locy</code>, <code>locz</code> → spawn location coordinates.
* <code>rot</code> → rotation (facing direction) in degrees.
* <code>traits</code> → optional set of trait IDs, separated by <code>|</code>. Only valid if a single race is defined.

'''Child Tags:'''

* <code><inventory></code>
** Contains <code><item></code> entries.
** '''Attributes (item):'''
*** <code>name</code> → item name (must exist).
*** <code>location</code> → inventory slot name (must exist in slot hash).
*** <code>quantity</code> → number of items.
* <code><skills></code>
** Contains <code><skill></code> entries.
** '''Attributes (skill):'''
*** <code>name</code> → skill name (must exist).
*** <code>value</code> → starting value.
* <code><kas></code>
** Contains <code><ka></code> entries.
** '''Attributes (ka):'''
*** <code>name</code> → knowledge area name (must exist).
*** <code>priority</code> → priority number.
* <code><specifickas></code>
** Contains <code><trigger></code> entries.
** '''Attributes (trigger):'''
*** <code>trigger</code> → text that activates the response.
*** <code>response1..5</code> → one or more response lines. <code>response1</code> must be present.
* <code><merchant></code>
** Contains <code><category></code> entries.
** '''Attributes (category):'''
*** <code>name</code> → merchant category name (e.g., <code>"Weapons - Shortsword"</code>).
* <code><trainer></code>
** Contains <code><skill></code> entries.
** '''Attributes (skill):'''
*** <code>name</code> → skill name (must exist).
*** <code>min_rank</code> → minimum rank the trainer teaches.
*** <code>max_rank</code> → maximum rank.
*** <code>min_faction</code> → minimum faction value required.
* <code><factions></code>
** Contains <code><faction></code> entries.
** '''Attributes (faction):'''
*** <code>name</code> → faction name (must exist).
*** <code>value</code> → starting standing with that faction.
* <code><variables></code>
** Contains <code><variable></code> entries.
** '''Attributes (variable):'''
*** <code>name</code> → variable key.
*** <code>value</code> → variable value (string or number).
* <code><npctype></code>
** Defines NPC brain/type using external <code>NPCType</code>. Attributes/structure depend on <code>NPCType::Load()</code>.

----'''<code><spawnitem></code>'''

* Spawns a new item into the event.
* '''Attributes:''' handled in <code>psRandomEventsItem::LoadXML()</code>

'''Attributes:'''
* <code>id</code> → '''(required)''' numeric identifier for this item within the event. Must be non-zero.
* <code>name</code> → '''(required)''' item name (must exist in database).
* <code>pickup</code> → <code>"yes"</code> or <code>"no"</code>. Determines if the item can be picked up by players.

'''Child Tags:'''

* <code><location></code>
** '''Attributes:'''
*** <code>x</code>, <code>y</code>, <code>z</code> → world coordinates where the item should spawn. (Values are multiplied by 100 internally to convert to centimeters.)

----'''<code><trigger></code>'''

* Sends a behavior trigger to a spawned NPC.
* '''Attributes:'''
** <code>behavior</code> → name of the behavior to trigger (e.g., <code>"start_show"</code>).
** <code>npc</code> → the numeric ID of the NPC that should execute this behavior.

----'''<code><destroynpc></code>'''

* Removes an NPC from the event.
* '''Attributes:'''
** <code>id</code> → numeric ID of the NPC to destroy.

----'''<code><destroyitem></code>'''

* Removes an item from the event.
* '''Attributes:'''
** <code>id</code> → numeric ID of the item to destroy.

----'''<code><schedulenext></code>'''

* Marks that after this timed step, the next event in the sequence should be scheduled automatically.
* '''Attributes:''' none.

Random Generated events

2025-08-20T13:37:43Z

Talad: /* Example: */

Quest scripts syntax

2025-08-02T18:02:22Z

Talad: /* Trigger and Menu */

= Structure of a quest script =
Quests are written out in chunks called steps. Each step covering the requirements of the previous one.

= Things to know before you start =
Quest scripts should written ideally in a text editor and now in MS Word or similar so that no illegal characters make it into the quest dialog which would result in errors when viewed in game.

Quotes are usually the ones which break the scripts and :

• Only ' " should be used

• ‘ ’ ” “ … These should not be present in the text at all.

Any line of text in the script which begins with a ‘#’ character is ignored by the server and only acts as a comment by the author so that they can leave explanations as to what is happening, or, give information about the step number.

The start of a ‘step’ is defined by a series of three dots ‘...’ Everything after this text up until the next ‘...’ is included in the step. The only unique case is the first step, this does not need ‘...’ and includes all the text before the first ‘...’

== Important rules concerning steps ==

* Every step in the quest should be explicitly completed or locked correctly. Example: "Complete Quest Name Step #" before the Quest is completed.
* A step can require the completion of another step by the command: "Requires completion of Quest Name Step #"
* Step 1 does not exist, step 1 is part of the start script (where you use the command "give me a quest") and cannot be used as a require completion of step number.
* You may have multiple Require Completes at the beginning of a step.
* A step may also require another step NOT to have been completed with the command: "Require no completion of Quest Name Step #".
* The Quest name must be exact! It is case sensitive. The same goes for NPC names.
* Each step should be commented like this: "# Step 2 - A description of actions of this step". # Marks it as a comment not processed by the engine.
* You can also check for statements with this syntax: "Require <no/not> operator1 | <no/not> operator2 | ...| <no/not> operatorN." Where operator is a prerequisite (see below the prerequisite chapter), from completion of to time of day etc. The | represents the OR. ''Example: "Require completion of Questname Step 3 | completion of Questname Step 7."''

Let's see an example before beginning the explanation. The following example is made of two steps.

'''Example: Structure 1'''
P: Short Trigger.

Menu: Do you have any work for me to do?

NPC Name: Yes I do. Just breathe one time.

Assign Quest.

...

P: Ok, I did it!

NPC Name: Great, your quest is completed.

== Syntax Basics ==

=== Comments ===
To create a comment line you must start the line with a "#". These lines are not evaluated by the engine as things that need to be done. These comment lines show what is going on and what are the intentions of the quest writer. This is important because more than one person are often working on a quest script, or eventually for laterbug fixing it will be easier to find the exact problem without reading the entire quest.

Each step in a quest should be started by a comment like this "#Step 2 - Description of step.". You can use comments to more that just noting the step number. Any where within the script you can add comments to help your fellow scripters understand the code. We will use comments to explain things within the scripts here.

=== Trigger and Menu ===
The trigger is for the engine, while the menu is what shows up in the player quest menu. The trigger is defined by a "P:".

P: use to be what the player typed to trigger the step, but with the menu system are now used as a description of what step the player is choosing, for example P:yeshelp. (slide 3). The only time you must use exact text is when a player types the answer to a question you pose them

Because you are talking to the engine it must be exact a colon after the "P:" and a period at the end of the sentence. This is also true of the Menu in every case in which the player (P) says something to the NPC in question "P: Short Trigger." comes first, then below comes the "Menu:" line, with exactly the same requirements.

"Menu": Text is what the player sees when they look at the quest menu.

Please remember that the engine does not think, it reacts to the written cues, so the syntax MUST be exact. The first player statement gives the engine the quest name. The Menu allows the player to ask for the quest from the NPC.

Having the two "P:" and two "Menu:" on the same line informs the engine that the player has two different options. It is standard that the "P:" line is above the "Menu:" line and the "No." answer comes first.

These lines trigger the NPC response. In more elaborate quests the "Menu:" line may have variations on the No. or Yes. response. However remember KISS (Keep It Simple Stupid) is generally a good thing to keep in mind when you are beginning. You can have many options, but remember each "P:" must have a matching "Menu:" and they must be put in the same order

In order to include a free textfield, you will have to include a quotation mark after the menu. The <?> has to be followed by <=> and a text. This will produce a printout of the text and the user will be able to enter a free text. E.g. "Menu: ?=What shall Jardet do?" This will result in the text "What shall Jardet do?" being printed, followed by free form input.

P: *. P: rock pick.
Menu: ?=Please tell me your answer.
Smith: No, you didn't get the right answer.
Smith: Yes, it's a rock pick!.

P: Nothirstyinterst. P: Yesthirstyintrest.
Menu: No, sounds like work. Menu: Sure, I can get it for you.
Serana Tuvi: Alright. I will see you around then, stranger.
Serana Tuvi: Ah, good good.

'''Note:''' Remember the : after the P and Menu are important, as is the . at the end of the line.

'''Note:''' For triggers used to start quests, never use NPC names into it, because this will confuse the engine, and the trigger will not be recognized.

'''Note:''' Every P: used in one step must be on the same line

'''Note:''' Every Menu: used in one step must be on the same line

'''Note:''' Every NPC: used in one step must be on different lines.

=== NPC Response ===
Aono Rikas: here you can add a response.

The line above is interpreted as an answer from the NPC and the engine will extract the name before the colon (:) + space as the NPC involved in this step of the quest. From now on, we will call this a response.

The full name of the NPC is required, just the first name will not work. If it is only one name e.g Harnquist use that, and if your NPC somehow ends up with three names use all of them.

In the first step of a quest the NPC statement will end in a question mark and is triggered by the first 2 lines. Responses are linked to each of the Triggers and Menus. So if you have two triggers you need two menu options and two NPC responses. All arranged in the same order.

=== Dialogues ===
The dialogues are the most important part of the quest for a player to get immersed. So let us talk about how to make the dialogue.

* Every punctuation, exclamation mark and question mark will create a short pause in the dialogue and create a new line.
* To create actions all you have to do is to use square brackets within the dialogue like this "Blablabla [NPC Name picks his nose] Bla bla blabla"

You may use also these commands:

$playerrace can be used in an impersonal and a personal manner in terms of context, consider its usage carefully.

$sir which gives you "Sir" or "Madam" or "Gemma" depending on the gender of the player's character. Again, this can be used to positive and negative effect. Be mindful of the NPCâ€™s tone. (Gemma is the honorific for Kran.)

$playername clearly not to be used in newbie quests, have NPC establish rapport use this in second quest or even the third time a player works with a given NPC.

Give me a quest..

= A sample quest script =

== The first step ==
As previously mentioned Step 1 does not exist, it is just the start of the quest, and can not be required by subsequent steps. The Start of the Quest will look something like the example at the beginning (Structure 1).

The same example can also be scripted like this:

'''Example: Structure 2'''
P: Short trigger.

Menu: Initial question, give me a quest.

NPC Name: Yes, I do have a quest for you. I need you to give Item of Importance to NPC2 Name.

P: Yes P: No.

Menu: Yes, I will do that. Menu: No way stupid.

NPC Name: This is the response from the NPC if answer is Yes.

Give 1 Item of Importance.

Assign Quest.

NPC Name: This is the response from the NPC if answer is No.

In Structure 2 the answers "No" and "Yes" are inverted, like the two "Menu:" commands, so it will give the same result as Structure 1. (Answer No: nothing happens. Answer Yes: the player will get 1Item of Importance and the Quest.)

Now, let us use a more detailed example. We will make a very simple quest: Aono wants to deliver a bottle of milk to Orchibaly. The player can choose the quest from Aono's quest menu. Orchibaly will then give the player 2 pies and a receipt to give back to Aono. The first step will be the step that assigns the quest. The P: tells the engine that this line represents something the player will say to the NPC, but what you must pay extra attention to is the "Menu:" This will be what the player will see as an option in the quest menu. If there are several options you will have to create one "P:" and a "Menu:" for each of them.

Here we firstly gives the player the option to ask for the quest. Then Aono describes the nature of the quest and the player can choose yes or no. Right after the "Menu:" line the NPC responsewill be put. In this example Aono will reply: "Well, I will get someone else to do it for me." if the player says no or "That's great. Here is the milk. Be sure not to spill it. TellOrchibaly I sent you.", give the player 1 Milk Bottle and assign the quest.

'''Example: Assign Quest'''
# Quest: Delivery for Aono Rikas

# Quest Description: Sample Quest.

# The rest of the header will not be covered here.

# Step 1 Aono Rikas in Hydlaa needs someone to deliver milk to Orchibally Gurpleferd in Ojaveda.

P: Delivery for Aono Rikas.

Menu: Are there any jobs you need done?

Aono Rikas: Well, yes. I need some milk delivered to Orchibaly in Ojaveda. Can you do this for me?

P: No. P: Yes.

Menu: No. Menu: Yes.

Aono Rikas: Well I will get someone else to do it for me.

Aono Rikas: That's great. Here is the milk. Be sure not to spill it. Tell Orchibaly I sent you.

Give 1 Milk Bottle.

Assign Quest.

A quest can be automatically assigned or there can be a step at the beginning of the quest to ask the player if he accepts it.

If you want to assign it automatically use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here.
Assign quest.

If you want to ask the player use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here, with the question if you want to help.
P: nohelp. P: yeshelp.
Menu: I don't want to. Menu: Yes I will help.
NPC: Fine... Go away.
NPC: Good great.
Assign quest.

'''Note:''' The “Assign quest.” command will only trigger after the second NPC: dialogue line is triggered, nothing happens if the first is triggered.

== The next step ==
To separate the step we use "..." and then a comment on what step it is and what the step is about. If you don't want this step to be repeatable you will also have to add "NoRepeat" after the "...". The second step does not need a completion of Step 1, because Step 1 does not exist so to speak. The structure will be more or less the same as for the initial step.

Let us continue our Delivery for Aono Quest. We have assigned the quest and the player has been given 1 Milk Bottle to give to Orchibaly. Now the player must give that milk to Orchibaly. Either by using the give GUI or by using the quest menu. The first thing we have to do here is to set up the give trigger. If the player gives Orchibaly the milk, he will answer "Oh, yes the milk. Please give it to me. Now i need you to deliver these two pies and this receipt back toAono.", Give the player 2 pies and a Receipt from Orchibaly. The step is then completed.

In this example although the player is given two pies no "s" is added to the line. This is important, especially because most writers tend to add a plural automatically to plural items. Remember the engine does not. An item is designated in the singular, the engine always interprets it in the singular regardless of the number included. The numbers are again not spelt out and Arabic numerals used. Remember that each "Player gives"-command must have menu option in the next line.

'''Example: Step 2'''
... NoRepeat

# Step 2 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this bottle of milk.

Orchibaly Gurpleferd: Thanks, please give it to me. Now deliver two pies and a receipt back to Aono.

Give 2 Pie. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 2.

Completing a step

At the end of a step remember to insert the line:

"Complete Delivery for Aono Rikas Step 2."

Note the use of Capitals, the use of the quest name, the use of the appropriate numeral and the period at the end of the sentence. The line marks the step as complete and allows the player and the quest to move forward.

== Last step ==
To make sure the player has completed the previous step we start with "Require completion of delivery for Aono step 2.". Then we move on to the trigger which is the player giving 2 pies and the receipt to Aono. Aono answers "Ah, pie. Thank you. Please accept this for your time.", gives the player a pie and 100Tria. The step is closed and so is the quest with "Complete Delivery for Aono Rikas."

'''Example: Last Step'''
...NoRepeat.

# Step 3 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of delivery for Aono step 2.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here are your pies and your receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

'''NOTE:''' If you use multiple options in the last step of a quest you have to explicitly complete the quest with a command for the first option.

'''Example: Last step with multiple options'''

P: No. P: Yes.

Merchant: Quest doesn't complete automatically so make sure you have added a complete line for this response.

Complete Harnquist Needs Gold Step 2. Complete Harnquist Needs Gold.

Merchant: Quest completes automatically because it is the last line in quest so no complete line is required.

Complete Harnquist Needs Gold Step 2.

If you omit the Complete Step and Complete Quest line, the quest will not end properly when choosing "no".

== Branches of a quest (Non exclusive) ==
Some times you want to have several different outcomes for a quest. Let us use the Delivery quest once again. If the first NPC says that you must NOT give the milk to some one else... specially NPC3. Then you should also add the option for the player to actually give the milk to NPC3 . This will complicate your script a bit, but is not as hard as it might seem. Most of the job is done by placing the right "Require completion of" and "Require no completion of" commands.

Let us take a look at that Delivery Quest again. Now we want to add an option for the player to give the milk to Reffitia instead. Reffitia will shake the milk until it becomes butter and this will make Orchibaly angry and demand a new bottle of milk. To do that we will have to add a few more steps and we will start from step 2 as step 1 will be the same as above.

The Third step will be our previous Step 2. And the last step will be the same. Though Aono should mention something like: "Make sure you don't give that milk toReffitia." in Step 1.

IMPORTANT NOTE: This is a non exclusive branching, meaning that the first branch is available also when executing the second one.

IMPORTANT NOTE: We will not add an additional step for the player to get milk again from Aono, but the player have to figure out another way to get hold of it (Buy from an NPC).

'''Example: Branching'''
... NoRepeat

# Step 2 - Alternative is to give the milk to refittia

Player gives 1 Milk Bottle to Reffitia

Menu: Here Reffitia, take this milk.

Reffitia Thamal: Ah! Orchibaly's milk. Here, now you can give the bottle to Orchibaly.

Give 1 Bottle of Butter.

Complete Delivery for Aono Rikas Step 2.

... NoRepeat

# Step 3 - Player gives bottle of butter to Orchy.
# The player then have to find another way of getting a bottle of milk (buy from NPC?)

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 4.

... NoRepeat

# Step 5 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Alternative outcome ==
If we wanted the quest to have a different outcome if the player gives the milk to Reffitia than to Orchibaly we would need to get creative with the require commands. Let us say that if the player gives butter to Orchibaly he will give "bad pies" so when Aono receives them and takes a taste he will be very angry and no reward is given. To do this we will have to add just one more step. Let us start with step 3. Here we will have to change only the NPC response a bit to something like "Milk? This is butter. Have you been shaking the bottle all the way over here? This is completely useless to me, butter I have more than enough of. Any way someMenki came with another bottle just before you. Here takes these pies to Aono . Oh, and don't forget this receipt.". Step 4 will be the step where the player gives the bad pies to Aono, this step will complete the quest. Step 5 and 6 are the outcome if the player gives the milk directly toOrchibaly. Notice that Step 5 require a NO completion of Step 4. This is actually not necessary for this script, because the previous the other branch of the quest, ending in step 4 closes the quest it self.

'''Example: Alternative Outcome'''
# Step 3 - Player gives bottle of butter to Orchy. And receives 2 pies and a receipt

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Give 2 Pie. Give 1 Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the "bad" pies and the receipt to Aono. Receives gunk as reward and Quest is completed.

Require completion of Delivery for Aono Rikas Step 3

Player gives Orchibaly Gurpleferd 2 Pie, 1 Receipt from Orchibaly.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. [Aono takes a bite at the pie] You have tricked me!

Give 1 Gunk.

Complete Delivery for Aono Rikas Step 4.

Complete Delivery for Aono Rikas.

...
# Step 5 - Player gives the milk directly to Orchibaly.

Require no completion of Delivery for Aono Step 4.

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 5.

... NoRepeat

# Step 6 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Quest Timeout (Passing of time) ==
If you want to allow a certain part of the quest to wait a certain amount of time before it can be a executed, you can use this script:<blockquote>Run script give_quest_timeout <<'Time until Harnquist is ready',6>></blockquote>this will create a temporary active magic with name 'Time until Harnquist is ready' which will last for 6 minutes.

Then in the prerequisite of the step have this:<blockquote># Step 12.

Require active magic Time until Harnquist is ready.

P: swordnotready.

Menu: Is Vresa's sword ready yet?

Harnquist: No, not yet.

...

# Step 13.

Require no active magic Time until Harnquist is ready.

P: about Vresa sword.

Menu: Is Vresa's sword ready?

Harnquist: Yes, Vresa's sword is done. </blockquote>

= Important commands and expressions used =

== Assign Quest. ==
This line tells the engine to assign the quest to the player and generally results in the "YOU GOT A QUEST". and placing the quest in the player's quest log, under "uncompleted". Again remember to be exact here, Capitalize the two words and put a "." at the end. It cannot be emphasized enough that the engine only interprets what it sees and the way it sees it. If you are not precise the quest will NOT happen or in the cases of the next steps move forward.

== ... ==
The three dots mark the beginning of a new step. Better, the three dots create a new step. So you need a "three dots" line before every "Complete Quest Name Step #"

== NoRepeat. ==
This line means that the quest step cannot be done over and over. Note that there are three periods "..." a space and 'NoRepeat.' is one word not two. Each part of this sentence is required in exactly this form.

Basically "..." tells the engine that some time can pass before the next lines are used.

NoRepeat allows this quest step to be only done one time. This also applies to actions as seen in later steps. (in reality NoRepeat is a synonym for Require no completion of "this step")

== Require completion of Quest Name Step #. ==
This command is like a closed door. To open it and enter in the current step the player needs to complete the step number #. You can also refer to a future step (for example, you're on step 4 and add "Require completion of Quest Name Step 8.")

== Require no completion of Quest Name Step #. ==
This command is like an open door. The player is free to continue the quest and entering the current step, UNLESS he completed the step number #. Completing the step number # will close the door. Forever! You can also refer to a future step.

== Complete Quest Name Step #. ==
This command completes a step, # being the step number. You can complete one step in another one. But remember to insert one "..." line for every "Complete Quest Name Step #." line.

== Complete Quest Name. ==
This command will end the quest. After this the quest will be deleted from the uncompleted quest list and appear in the Completed quest list.

== P: ==
The trigger is actually a ghost from the previous scripting system, but it is still needed (for now). Before the player had to type the exact trigger stated after the "P:". Now they click the option from "Menu:". Triggers must be four words or less. Triggers must end with a period, no other punctuation is allowed (question marks especially are known to break aquest on the server).

If you want multiple phrases to activate the same trigger, you can just separate the phrases by a period; for example: "P: about guards. about hydlaa guards. about hydlaa militia." In this case the NPC's response will be fired on any of the three options. This technique can be used also when you have multiple choices: "P: one. two. P: more.". Both 'one' and 'two' will trigger the first response, while 'more' will trigger the second.

WARNING: Triggers cannot contain any of the following words: a, am, an, and, any, anything, are, do, I, is, isnâ€™t, please, that, the, this, to, too.

They also may not contain the name of the NPC you're talking to as that'll be stripped.

These words just take up space in a trigger as they are dropped by the engine when evaluating player response. To make the best use of your word counts ignore them when writing your triggers.

Example: If you wanted the player to say 'please help Levrus' the trigger would become 'help levrus' as please would be an ignored word.

WARNING: If a player needs to write "NPC needs this" syntax it as "NPC wants this".

== Menu: ==
That's easy. After this command you can add the sentence said by the player in game. This sentence will appear on the screen and could be selected when one talks to the NPC.

Remember that for every menu line you need to create a response from the NPC.

== Give ==
Give is a very useful command. It tells the engine to give the player items. Be it rewards or special items needed for the quest. When you reward a player, you can basically give items and/or experience. The syntax to award 1500 experience points would be: "Give 1500 Exp." Note that "Exp" is case-sensitive. You can also reward items AND experience, using this syntax: "Give Leather Gloves. Give 1500 Exp." Remember that you can only have two give commands on the same line, but you can have multiple lines, Remember to keep a clean style, it is prefered to only have one item per line.

'''Example: Give more than two items'''
Give 1 Leather Gloves.
Give 1500 Exp.
Give 1 Apple.

You can also add a number if you need to give more than one item (like you do for experience) example: "Give 5 Iron Ingot." It is not necessary in the case of one item to include the numeral, however it is good practice to do so as numerals tell the engine how many and should be written as a numeral, a word will NOT work as the engine cannot interpret it as such. Remember that all special items must be declared in the script header.

Another option you have is to give one item OR another. The following will pop up a window in which the player has to choose just one item:

'''Example: Give the player a choice between items'''
Give Cold or Arrow or Energy.
'''WARNING:''' At this time, don't use the following in an OR option: Tria, hexa, octa, circles, or items without a graphic. Also, for now, do NOT put quantities in front of items that are given using the "OR" parameter. An example of what NOT to do: "Give 1 Cold or 1 Arrow or 1 Energy." This will lock the server right up. An example of what SHOULD be done: "Give Cold or Arrow or Energy." (Check this statement if it is correct. --Katu)

== Player gives NPC Name 1 Item ==
This can be used as a trigger (instead of the "P:"). It tells the engine to trigger the NPC dialogue when one or any fixed amount of a special item.

When a player have to give multiple items just add them to the original line using a comma:

'''Example Player gives item'''
Player gives Harnquist Water Pouch, 1 Pie.

'''WARNING:''' Item name rules must be followed at all times.

Notice that the item name is "Iron Ingot", so "Iron Ingots" will not work, even if itâ€™s the correct plural form. Keep all names singular.

Also, do not use a number (3, 14, etc) in the name of an item. An item called 3 Circles Receipt will probably generate problems when we script "Give 3 Circles Receipt." It is better named "Three Circles Receipt."

Numbers should be spelled out everywhere unless you are referring to the quantity given or dealing with a trigger (give me 5 apples. give me five apples.) as both would be correct in a trigger.

Character limit for an item name is 60 characters.

Do not use an s' in an item name, like "Levrus' Left Shoe," use "Left Shoe of Levrus" or a similar substitute instead.

== Set variable Require variable ==
You can set a variable to be later used by the quest or other quests. Variables are set on the character and visible from all quests.
Smith: Here is your winch access
Setvariable Quest_Winch_Access 1

You can then require a variable to be set as prerequisite of a quest step.
Require variable Quest_Winch_Access.
P: access.
Menu: I have access
Bobaus: Ok, good.

== Require Compendium ==
You can require the player to have a certain knowledge in the Compendium.
Require compendium creature StoneHammer
P: comps
Menu: I know everything about the StoneHammers!
Fighter3: WOW
...
Require no compendium creature StoneHammer
P: nocomps
Menu: Sorry I dont know anything about StoneHammers!
Fighter3: Ah, study more!

The syntax is: compendium <creature/plant/mineral> <name>

== Rewards at the end of the quest ==
When completing a quest, the player usually gets experience and money, or some items. In particular for experience and money you should use the following scripts. This allows us to split the rewards on a scale from 1 to 10 and then to tweak the actual values in the engine. The values in brackets indicate the complexity of the quest. The more complex the more rewards the player will get.

Run script give_quest_money <<3>>.
Run script give_quest_exp <<2>>.
You can also award faction points by using "give_quest_faction" , the number given is multiplied by 5 so if you want +5 point, you need 1 on the second parameter:
Run script give_quest_faction <<'Essential Trail', 1>>.
We have script also to push the faction point up to a given value, if you are already higher, this script will do nothing.
Run script give_quest_faction_level <<'Essential Trail', 2>>.
value = 1-> max faction points = 10;

value = 2-> max faction points = 20;

value = 3-> max faction points = 35;

value = 4-> max faction points = 55;

value = 5-> max faction points = 75;

value = 6-> max faction points = 100;

value = 7-> max faction points = 125;

value = 8-> max faction points = 150;

value = 9-> max faction points = 200;

If you want to assign a faction title you can use this script. In the example it will assign the second title.
Run script give_quest_faction_title <<'Essential Trail', 2>>.

=== The header ===
The header should contain a lot of information. All the information is commented out by a "#". The example below is from one of the mount quests.

First section is information about the quest itself. Name of the quest, a short description and category. Categories will be discussed in detail later on.

The next sections are for unique items used in the quest, name of the item followed by the description.

The third section is for recording versions of the script and all naming authors. Also who last edited the quest should be noted.

The last section is for additional metadata which will be added to the quest in the database (not part of the db) and will be used by the engine to determine lockouts and prerequisites. Here it locks all players from doing the quest again and locks all other players to take the quest with 60 seconds.

Lastly we tell the engine that the player have to complete the Ring of Familiar quest before this one. Note that these comments aren't taken by the engine; it's the duty of who loads the quest to fill the correct entries with the data found in the header: so it's just a way to keep all data together on the script.

'''Example: Header'''
# Quest name: Drifting for a Drifter
# Quest Description: Taemian wants to sell you a mount
# Quest Category: General
# ----------------------
# Quest Items: Item name/Item description
# Taemian's Pouch: - Pouch with all sorts of coins
# Green Gem of the Drifter - A magical gem with a green glow
# Unsigned Drifter Permit - A permit that still needs to be signed by Datal
# Signed Drifter Permit - A permit that has been signed by Datal
# ----------------------
# Variables used in this quest
# ----------------------
# Quest specific variables used in this quest
# ----------------------
# Author(s): Ravna, Katu, weltall
# Current Version: 1.01
# Player lockout: -1
# Quest lockout: 60
# Prerequisites: <nowiki><pre><completed quest="Ring of Familiar"/></pre></nowiki>
# Variables used: Quest_Variable_Name used to do.....
# ----------------------
# Version history and change log
# Last edited by: weltall
# Version 1.00: Initial draft - 05/01/2010 - Katu.
# Version 1.01: Added extra steps - 1/22/2011 - Venalan.
# ----------------------

==== Quest Lockouts ====
Each quest has two different lockout types:

* Player lockout: When this parameter is set, the engine will wait the specified amount of seconds before allowing the same player to redo the same quest. If you want a quest to be available to each player only one time, then set the lockout to -1. Setting it to 600 will have the engine wait 10 minutes before unlocking the quest again.
* Quest lockout: When this parameter is set, the engine will wait the specified amount of seconds before reactivating the quest for ALL players. This means no one can start the same quest during this period, but the ones that had it already active can complete it.

Usually we want quests to be unique to players, so most have a player lockout -1, except the very simple ones. Try always to think if itâ€™s meaningful for that player to redo it. (For example, Harnquist can require iron ore more than once, but won't need to teach you how to make a sword more than once.)

=== Prerequisites ===
Another more complex version of the prerequisites is the: REQUIRE MIN <number>: this tells the engine that there are specific requirements to be fulfilled before the player is able to get the quest. This script indicated it requires a minimum number of quests to be completed in a given list.

Example: require min 2 of Quest1, Quest2, Quest3.

To match this prerequisite the player can complete Quest1 and Quest3 or 2 and 3, or all 3. The request is minimum 2 in the given list.

CATEGORY MIN <number>: quests have an attribute called "category", we use it to identify the difficulty of quests, but can be used of any other purpose, for example one can say that a group of quests is "Evil" or "Laanx related" or " Newbie". Just one category is allowed per quest. This prerequisite allows you to specify the category and the minimum number of quests completed in that category.

A sample of the coding used to set prerequisites for a quest (All on one line):

'''Example: Prerequisites'''
<nowiki><pre><and></nowiki>
<completed quest="Test Quest One"/>
<completed quest="Test Quest Two"/>
<completed quest="Test Quest Three"/>
<completed quest="Test Quest Four"/>
<not><completed quest="Delivery for Aono Riskas"/></not>
<not><completed quest="Gorbiak Disease"/></not>
</and><nowiki></pre></nowiki>

This sample requires that the player have completed Test Quests 1 through 4 and have NOT completed Fancy Dancing and High-Class Aspirations. To get these arranged correctly can take some practice if one is not familiar with working with booleans, so it is best to include a plain-English comments of what you wish your pre-requisites to be in addition to the one with the "pre" coding statements.

Checks if the player has a certain item equipped . To be documented better

else if (!strncasecmp(block,"equipped",8))

=== Untested Prerequisites ===
Please contact engine in case you want to use any of these prerequisites, because those are untested.

"time of day" // require time of day starthh-endhh (working)

"trait" //require trait name in place

"guild" //NOTE: the both argument is implicitly defined

"active magic" (working)

"known spell"

"race" (working)

"gender" (working)

"married"

"possessed" (working)

"skill" //Require skill <buffed> name <skillmin>-<skillmax>. (working)

"variable" //Require variable name. (working)

= Notes on Creating Quest Files (Rules and Header Information) =

* The quest documents you submit should always be in notepad format: this is to avoid special characters added by Word or other text editors, most notably "smart quotes" which will appear as squares in game. Notepad++ is recommended, HIGHLY recommended.
* Use only ANSI encoding.
* The file name when saving the quest should begin with 'Quest' , then have the name of the quest. For example: Quest Hinoserri Cannot See.txt
* Titles of quests should follow some scheme of capitalization. There are many sets of rules, but a quick and easy format is to capitalize the first word and then all other words, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor.
* Each quest script begins with the title and a one or two sentence description; this is what the player reads so keep that in mind. The proper way to do this is to "comment out" your description and quest title, this is done by beginning a line with the number sign or pound symbol (#). Also, any quest item created for your quest should have a description written into the quest. Notes on quest items should also be commented out. Lastly, there should also be a "Quest Category" line that must be commented out as well. Approved quest categories are: Alchemy, Black Flame, Chain (don't use this one unless told), Cooking, Death Realm, Easy, Gugrontid, Magic Ways, Medium, Metal Working, Newbie, Repeatable. This is a work in progress, so if you have any questions ask an associate dev or developer. No quest can have more than one category - pick one and ONLY one. New quest categories must be approved by the associate devs/devs before use.

Quest scripts syntax

2025-08-02T18:02:18Z

Talad: /* Trigger and Menu */

= Structure of a quest script =
Quests are written out in chunks called steps. Each step covering the requirements of the previous one.

= Things to know before you start =
Quest scripts should written ideally in a text editor and now in MS Word or similar so that no illegal characters make it into the quest dialog which would result in errors when viewed in game.

Quotes are usually the ones which break the scripts and :

• Only ' " should be used

• ‘ ’ ” “ … These should not be present in the text at all.

Any line of text in the script which begins with a ‘#’ character is ignored by the server and only acts as a comment by the author so that they can leave explanations as to what is happening, or, give information about the step number.

The start of a ‘step’ is defined by a series of three dots ‘...’ Everything after this text up until the next ‘...’ is included in the step. The only unique case is the first step, this does not need ‘...’ and includes all the text before the first ‘...’

== Important rules concerning steps ==

* Every step in the quest should be explicitly completed or locked correctly. Example: "Complete Quest Name Step #" before the Quest is completed.
* A step can require the completion of another step by the command: "Requires completion of Quest Name Step #"
* Step 1 does not exist, step 1 is part of the start script (where you use the command "give me a quest") and cannot be used as a require completion of step number.
* You may have multiple Require Completes at the beginning of a step.
* A step may also require another step NOT to have been completed with the command: "Require no completion of Quest Name Step #".
* The Quest name must be exact! It is case sensitive. The same goes for NPC names.
* Each step should be commented like this: "# Step 2 - A description of actions of this step". # Marks it as a comment not processed by the engine.
* You can also check for statements with this syntax: "Require <no/not> operator1 | <no/not> operator2 | ...| <no/not> operatorN." Where operator is a prerequisite (see below the prerequisite chapter), from completion of to time of day etc. The | represents the OR. ''Example: "Require completion of Questname Step 3 | completion of Questname Step 7."''

Let's see an example before beginning the explanation. The following example is made of two steps.

'''Example: Structure 1'''
P: Short Trigger.

Menu: Do you have any work for me to do?

NPC Name: Yes I do. Just breathe one time.

Assign Quest.

...

P: Ok, I did it!

NPC Name: Great, your quest is completed.

== Syntax Basics ==

=== Comments ===
To create a comment line you must start the line with a "#". These lines are not evaluated by the engine as things that need to be done. These comment lines show what is going on and what are the intentions of the quest writer. This is important because more than one person are often working on a quest script, or eventually for laterbug fixing it will be easier to find the exact problem without reading the entire quest.

Each step in a quest should be started by a comment like this "#Step 2 - Description of step.". You can use comments to more that just noting the step number. Any where within the script you can add comments to help your fellow scripters understand the code. We will use comments to explain things within the scripts here.

=== Trigger and Menu ===
The trigger is for the engine, while the menu is what shows up in the player quest menu. The trigger is defined by a "P:".

P: use to be what the player typed to trigger the step, but with the menu system are now used as a description of what step the player is choosing, for example P:yeshelp. (slide 3). The only time you must use exact text is when a player types the answer to a question you pose them

Because you are talking to the engine it must be exact a colon after the "P:" and a period at the end of the sentence. This is also true of the Menu in every case in which the player (P) says something to the NPC in question "P: Short Trigger." comes first, then below comes the "Menu:" line, with exactly the same requirements.

"Menu": Text is what the player sees when they look at the quest menu.

Please remember that the engine does not think, it reacts to the written cues, so the syntax MUST be exact. The first player statement gives the engine the quest name. The Menu allows the player to ask for the quest from the NPC.

Having the two "P:" and two "Menu:" on the same line informs the engine that the player has two different options. It is standard that the "P:" line is above the "Menu:" line and the "No." answer comes first.

These lines trigger the NPC response. In more elaborate quests the "Menu:" line may have variations on the No. or Yes. response. However remember KISS (Keep It Simple Stupid) is generally a good thing to keep in mind when you are beginning. You can have many options, but remember each "P:" must have a matching "Menu:" and they must be put in the same order

In order to include a free textfield, you will have to include a quotation mark after the menu. The <?> has to be followed by <=> and a text. This will produce a printout of the text and the user will be able to enter a free text. E.g. "Menu: ?=What shall Jardet do?" This will result in the text "What shall Jardet do?" being printed, followed by free form input.

P: *. P: rock pick.
Menu: ?=Please tell me your answer.
Smith: No, you didn't get the right answer.
Smith: Yes, it's a rock pick!.
Multi trigger:
P: Nothirstyinterst. P: Yesthirstyintrest.
Menu: No, sounds like work. Menu: Sure, I can get it for you.
Serana Tuvi: Alright. I will see you around then, stranger.
Serana Tuvi: Ah, good good.

'''Note:''' Remember the : after the P and Menu are important, as is the . at the end of the line.

'''Note:''' For triggers used to start quests, never use NPC names into it, because this will confuse the engine, and the trigger will not be recognized.

'''Note:''' Every P: used in one step must be on the same line

'''Note:''' Every Menu: used in one step must be on the same line

'''Note:''' Every NPC: used in one step must be on different lines.

=== NPC Response ===
Aono Rikas: here you can add a response.

The line above is interpreted as an answer from the NPC and the engine will extract the name before the colon (:) + space as the NPC involved in this step of the quest. From now on, we will call this a response.

The full name of the NPC is required, just the first name will not work. If it is only one name e.g Harnquist use that, and if your NPC somehow ends up with three names use all of them.

In the first step of a quest the NPC statement will end in a question mark and is triggered by the first 2 lines. Responses are linked to each of the Triggers and Menus. So if you have two triggers you need two menu options and two NPC responses. All arranged in the same order.

=== Dialogues ===
The dialogues are the most important part of the quest for a player to get immersed. So let us talk about how to make the dialogue.

* Every punctuation, exclamation mark and question mark will create a short pause in the dialogue and create a new line.
* To create actions all you have to do is to use square brackets within the dialogue like this "Blablabla [NPC Name picks his nose] Bla bla blabla"

You may use also these commands:

$playerrace can be used in an impersonal and a personal manner in terms of context, consider its usage carefully.

$sir which gives you "Sir" or "Madam" or "Gemma" depending on the gender of the player's character. Again, this can be used to positive and negative effect. Be mindful of the NPCâ€™s tone. (Gemma is the honorific for Kran.)

$playername clearly not to be used in newbie quests, have NPC establish rapport use this in second quest or even the third time a player works with a given NPC.

Give me a quest..

= A sample quest script =

== The first step ==
As previously mentioned Step 1 does not exist, it is just the start of the quest, and can not be required by subsequent steps. The Start of the Quest will look something like the example at the beginning (Structure 1).

The same example can also be scripted like this:

'''Example: Structure 2'''
P: Short trigger.

Menu: Initial question, give me a quest.

NPC Name: Yes, I do have a quest for you. I need you to give Item of Importance to NPC2 Name.

P: Yes P: No.

Menu: Yes, I will do that. Menu: No way stupid.

NPC Name: This is the response from the NPC if answer is Yes.

Give 1 Item of Importance.

Assign Quest.

NPC Name: This is the response from the NPC if answer is No.

In Structure 2 the answers "No" and "Yes" are inverted, like the two "Menu:" commands, so it will give the same result as Structure 1. (Answer No: nothing happens. Answer Yes: the player will get 1Item of Importance and the Quest.)

Now, let us use a more detailed example. We will make a very simple quest: Aono wants to deliver a bottle of milk to Orchibaly. The player can choose the quest from Aono's quest menu. Orchibaly will then give the player 2 pies and a receipt to give back to Aono. The first step will be the step that assigns the quest. The P: tells the engine that this line represents something the player will say to the NPC, but what you must pay extra attention to is the "Menu:" This will be what the player will see as an option in the quest menu. If there are several options you will have to create one "P:" and a "Menu:" for each of them.

Here we firstly gives the player the option to ask for the quest. Then Aono describes the nature of the quest and the player can choose yes or no. Right after the "Menu:" line the NPC responsewill be put. In this example Aono will reply: "Well, I will get someone else to do it for me." if the player says no or "That's great. Here is the milk. Be sure not to spill it. TellOrchibaly I sent you.", give the player 1 Milk Bottle and assign the quest.

'''Example: Assign Quest'''
# Quest: Delivery for Aono Rikas

# Quest Description: Sample Quest.

# The rest of the header will not be covered here.

# Step 1 Aono Rikas in Hydlaa needs someone to deliver milk to Orchibally Gurpleferd in Ojaveda.

P: Delivery for Aono Rikas.

Menu: Are there any jobs you need done?

Aono Rikas: Well, yes. I need some milk delivered to Orchibaly in Ojaveda. Can you do this for me?

P: No. P: Yes.

Menu: No. Menu: Yes.

Aono Rikas: Well I will get someone else to do it for me.

Aono Rikas: That's great. Here is the milk. Be sure not to spill it. Tell Orchibaly I sent you.

Give 1 Milk Bottle.

Assign Quest.

A quest can be automatically assigned or there can be a step at the beginning of the quest to ask the player if he accepts it.

If you want to assign it automatically use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here.
Assign quest.

If you want to ask the player use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here, with the question if you want to help.
P: nohelp. P: yeshelp.
Menu: I don't want to. Menu: Yes I will help.
NPC: Fine... Go away.
NPC: Good great.
Assign quest.

'''Note:''' The “Assign quest.” command will only trigger after the second NPC: dialogue line is triggered, nothing happens if the first is triggered.

== The next step ==
To separate the step we use "..." and then a comment on what step it is and what the step is about. If you don't want this step to be repeatable you will also have to add "NoRepeat" after the "...". The second step does not need a completion of Step 1, because Step 1 does not exist so to speak. The structure will be more or less the same as for the initial step.

Let us continue our Delivery for Aono Quest. We have assigned the quest and the player has been given 1 Milk Bottle to give to Orchibaly. Now the player must give that milk to Orchibaly. Either by using the give GUI or by using the quest menu. The first thing we have to do here is to set up the give trigger. If the player gives Orchibaly the milk, he will answer "Oh, yes the milk. Please give it to me. Now i need you to deliver these two pies and this receipt back toAono.", Give the player 2 pies and a Receipt from Orchibaly. The step is then completed.

In this example although the player is given two pies no "s" is added to the line. This is important, especially because most writers tend to add a plural automatically to plural items. Remember the engine does not. An item is designated in the singular, the engine always interprets it in the singular regardless of the number included. The numbers are again not spelt out and Arabic numerals used. Remember that each "Player gives"-command must have menu option in the next line.

'''Example: Step 2'''
... NoRepeat

# Step 2 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this bottle of milk.

Orchibaly Gurpleferd: Thanks, please give it to me. Now deliver two pies and a receipt back to Aono.

Give 2 Pie. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 2.

Completing a step

At the end of a step remember to insert the line:

"Complete Delivery for Aono Rikas Step 2."

Note the use of Capitals, the use of the quest name, the use of the appropriate numeral and the period at the end of the sentence. The line marks the step as complete and allows the player and the quest to move forward.

== Last step ==
To make sure the player has completed the previous step we start with "Require completion of delivery for Aono step 2.". Then we move on to the trigger which is the player giving 2 pies and the receipt to Aono. Aono answers "Ah, pie. Thank you. Please accept this for your time.", gives the player a pie and 100Tria. The step is closed and so is the quest with "Complete Delivery for Aono Rikas."

'''Example: Last Step'''
...NoRepeat.

# Step 3 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of delivery for Aono step 2.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here are your pies and your receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

'''NOTE:''' If you use multiple options in the last step of a quest you have to explicitly complete the quest with a command for the first option.

'''Example: Last step with multiple options'''

P: No. P: Yes.

Merchant: Quest doesn't complete automatically so make sure you have added a complete line for this response.

Complete Harnquist Needs Gold Step 2. Complete Harnquist Needs Gold.

Merchant: Quest completes automatically because it is the last line in quest so no complete line is required.

Complete Harnquist Needs Gold Step 2.

If you omit the Complete Step and Complete Quest line, the quest will not end properly when choosing "no".

== Branches of a quest (Non exclusive) ==
Some times you want to have several different outcomes for a quest. Let us use the Delivery quest once again. If the first NPC says that you must NOT give the milk to some one else... specially NPC3. Then you should also add the option for the player to actually give the milk to NPC3 . This will complicate your script a bit, but is not as hard as it might seem. Most of the job is done by placing the right "Require completion of" and "Require no completion of" commands.

Let us take a look at that Delivery Quest again. Now we want to add an option for the player to give the milk to Reffitia instead. Reffitia will shake the milk until it becomes butter and this will make Orchibaly angry and demand a new bottle of milk. To do that we will have to add a few more steps and we will start from step 2 as step 1 will be the same as above.

The Third step will be our previous Step 2. And the last step will be the same. Though Aono should mention something like: "Make sure you don't give that milk toReffitia." in Step 1.

IMPORTANT NOTE: This is a non exclusive branching, meaning that the first branch is available also when executing the second one.

IMPORTANT NOTE: We will not add an additional step for the player to get milk again from Aono, but the player have to figure out another way to get hold of it (Buy from an NPC).

'''Example: Branching'''
... NoRepeat

# Step 2 - Alternative is to give the milk to refittia

Player gives 1 Milk Bottle to Reffitia

Menu: Here Reffitia, take this milk.

Reffitia Thamal: Ah! Orchibaly's milk. Here, now you can give the bottle to Orchibaly.

Give 1 Bottle of Butter.

Complete Delivery for Aono Rikas Step 2.

... NoRepeat

# Step 3 - Player gives bottle of butter to Orchy.
# The player then have to find another way of getting a bottle of milk (buy from NPC?)

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 4.

... NoRepeat

# Step 5 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Alternative outcome ==
If we wanted the quest to have a different outcome if the player gives the milk to Reffitia than to Orchibaly we would need to get creative with the require commands. Let us say that if the player gives butter to Orchibaly he will give "bad pies" so when Aono receives them and takes a taste he will be very angry and no reward is given. To do this we will have to add just one more step. Let us start with step 3. Here we will have to change only the NPC response a bit to something like "Milk? This is butter. Have you been shaking the bottle all the way over here? This is completely useless to me, butter I have more than enough of. Any way someMenki came with another bottle just before you. Here takes these pies to Aono . Oh, and don't forget this receipt.". Step 4 will be the step where the player gives the bad pies to Aono, this step will complete the quest. Step 5 and 6 are the outcome if the player gives the milk directly toOrchibaly. Notice that Step 5 require a NO completion of Step 4. This is actually not necessary for this script, because the previous the other branch of the quest, ending in step 4 closes the quest it self.

'''Example: Alternative Outcome'''
# Step 3 - Player gives bottle of butter to Orchy. And receives 2 pies and a receipt

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Give 2 Pie. Give 1 Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the "bad" pies and the receipt to Aono. Receives gunk as reward and Quest is completed.

Require completion of Delivery for Aono Rikas Step 3

Player gives Orchibaly Gurpleferd 2 Pie, 1 Receipt from Orchibaly.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. [Aono takes a bite at the pie] You have tricked me!

Give 1 Gunk.

Complete Delivery for Aono Rikas Step 4.

Complete Delivery for Aono Rikas.

...
# Step 5 - Player gives the milk directly to Orchibaly.

Require no completion of Delivery for Aono Step 4.

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 5.

... NoRepeat

# Step 6 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Quest Timeout (Passing of time) ==
If you want to allow a certain part of the quest to wait a certain amount of time before it can be a executed, you can use this script:<blockquote>Run script give_quest_timeout <<'Time until Harnquist is ready',6>></blockquote>this will create a temporary active magic with name 'Time until Harnquist is ready' which will last for 6 minutes.

Then in the prerequisite of the step have this:<blockquote># Step 12.

Require active magic Time until Harnquist is ready.

P: swordnotready.

Menu: Is Vresa's sword ready yet?

Harnquist: No, not yet.

...

# Step 13.

Require no active magic Time until Harnquist is ready.

P: about Vresa sword.

Menu: Is Vresa's sword ready?

Harnquist: Yes, Vresa's sword is done. </blockquote>

= Important commands and expressions used =

== Assign Quest. ==
This line tells the engine to assign the quest to the player and generally results in the "YOU GOT A QUEST". and placing the quest in the player's quest log, under "uncompleted". Again remember to be exact here, Capitalize the two words and put a "." at the end. It cannot be emphasized enough that the engine only interprets what it sees and the way it sees it. If you are not precise the quest will NOT happen or in the cases of the next steps move forward.

== ... ==
The three dots mark the beginning of a new step. Better, the three dots create a new step. So you need a "three dots" line before every "Complete Quest Name Step #"

== NoRepeat. ==
This line means that the quest step cannot be done over and over. Note that there are three periods "..." a space and 'NoRepeat.' is one word not two. Each part of this sentence is required in exactly this form.

Basically "..." tells the engine that some time can pass before the next lines are used.

NoRepeat allows this quest step to be only done one time. This also applies to actions as seen in later steps. (in reality NoRepeat is a synonym for Require no completion of "this step")

== Require completion of Quest Name Step #. ==
This command is like a closed door. To open it and enter in the current step the player needs to complete the step number #. You can also refer to a future step (for example, you're on step 4 and add "Require completion of Quest Name Step 8.")

== Require no completion of Quest Name Step #. ==
This command is like an open door. The player is free to continue the quest and entering the current step, UNLESS he completed the step number #. Completing the step number # will close the door. Forever! You can also refer to a future step.

== Complete Quest Name Step #. ==
This command completes a step, # being the step number. You can complete one step in another one. But remember to insert one "..." line for every "Complete Quest Name Step #." line.

== Complete Quest Name. ==
This command will end the quest. After this the quest will be deleted from the uncompleted quest list and appear in the Completed quest list.

== P: ==
The trigger is actually a ghost from the previous scripting system, but it is still needed (for now). Before the player had to type the exact trigger stated after the "P:". Now they click the option from "Menu:". Triggers must be four words or less. Triggers must end with a period, no other punctuation is allowed (question marks especially are known to break aquest on the server).

If you want multiple phrases to activate the same trigger, you can just separate the phrases by a period; for example: "P: about guards. about hydlaa guards. about hydlaa militia." In this case the NPC's response will be fired on any of the three options. This technique can be used also when you have multiple choices: "P: one. two. P: more.". Both 'one' and 'two' will trigger the first response, while 'more' will trigger the second.

WARNING: Triggers cannot contain any of the following words: a, am, an, and, any, anything, are, do, I, is, isnâ€™t, please, that, the, this, to, too.

They also may not contain the name of the NPC you're talking to as that'll be stripped.

These words just take up space in a trigger as they are dropped by the engine when evaluating player response. To make the best use of your word counts ignore them when writing your triggers.

Example: If you wanted the player to say 'please help Levrus' the trigger would become 'help levrus' as please would be an ignored word.

WARNING: If a player needs to write "NPC needs this" syntax it as "NPC wants this".

== Menu: ==
That's easy. After this command you can add the sentence said by the player in game. This sentence will appear on the screen and could be selected when one talks to the NPC.

Remember that for every menu line you need to create a response from the NPC.

== Give ==
Give is a very useful command. It tells the engine to give the player items. Be it rewards or special items needed for the quest. When you reward a player, you can basically give items and/or experience. The syntax to award 1500 experience points would be: "Give 1500 Exp." Note that "Exp" is case-sensitive. You can also reward items AND experience, using this syntax: "Give Leather Gloves. Give 1500 Exp." Remember that you can only have two give commands on the same line, but you can have multiple lines, Remember to keep a clean style, it is prefered to only have one item per line.

'''Example: Give more than two items'''
Give 1 Leather Gloves.
Give 1500 Exp.
Give 1 Apple.

You can also add a number if you need to give more than one item (like you do for experience) example: "Give 5 Iron Ingot." It is not necessary in the case of one item to include the numeral, however it is good practice to do so as numerals tell the engine how many and should be written as a numeral, a word will NOT work as the engine cannot interpret it as such. Remember that all special items must be declared in the script header.

Another option you have is to give one item OR another. The following will pop up a window in which the player has to choose just one item:

'''Example: Give the player a choice between items'''
Give Cold or Arrow or Energy.
'''WARNING:''' At this time, don't use the following in an OR option: Tria, hexa, octa, circles, or items without a graphic. Also, for now, do NOT put quantities in front of items that are given using the "OR" parameter. An example of what NOT to do: "Give 1 Cold or 1 Arrow or 1 Energy." This will lock the server right up. An example of what SHOULD be done: "Give Cold or Arrow or Energy." (Check this statement if it is correct. --Katu)

== Player gives NPC Name 1 Item ==
This can be used as a trigger (instead of the "P:"). It tells the engine to trigger the NPC dialogue when one or any fixed amount of a special item.

When a player have to give multiple items just add them to the original line using a comma:

'''Example Player gives item'''
Player gives Harnquist Water Pouch, 1 Pie.

'''WARNING:''' Item name rules must be followed at all times.

Notice that the item name is "Iron Ingot", so "Iron Ingots" will not work, even if itâ€™s the correct plural form. Keep all names singular.

Also, do not use a number (3, 14, etc) in the name of an item. An item called 3 Circles Receipt will probably generate problems when we script "Give 3 Circles Receipt." It is better named "Three Circles Receipt."

Numbers should be spelled out everywhere unless you are referring to the quantity given or dealing with a trigger (give me 5 apples. give me five apples.) as both would be correct in a trigger.

Character limit for an item name is 60 characters.

Do not use an s' in an item name, like "Levrus' Left Shoe," use "Left Shoe of Levrus" or a similar substitute instead.

== Set variable Require variable ==
You can set a variable to be later used by the quest or other quests. Variables are set on the character and visible from all quests.
Smith: Here is your winch access
Setvariable Quest_Winch_Access 1

You can then require a variable to be set as prerequisite of a quest step.
Require variable Quest_Winch_Access.
P: access.
Menu: I have access
Bobaus: Ok, good.

== Require Compendium ==
You can require the player to have a certain knowledge in the Compendium.
Require compendium creature StoneHammer
P: comps
Menu: I know everything about the StoneHammers!
Fighter3: WOW
...
Require no compendium creature StoneHammer
P: nocomps
Menu: Sorry I dont know anything about StoneHammers!
Fighter3: Ah, study more!

The syntax is: compendium <creature/plant/mineral> <name>

== Rewards at the end of the quest ==
When completing a quest, the player usually gets experience and money, or some items. In particular for experience and money you should use the following scripts. This allows us to split the rewards on a scale from 1 to 10 and then to tweak the actual values in the engine. The values in brackets indicate the complexity of the quest. The more complex the more rewards the player will get.

Run script give_quest_money <<3>>.
Run script give_quest_exp <<2>>.
You can also award faction points by using "give_quest_faction" , the number given is multiplied by 5 so if you want +5 point, you need 1 on the second parameter:
Run script give_quest_faction <<'Essential Trail', 1>>.
We have script also to push the faction point up to a given value, if you are already higher, this script will do nothing.
Run script give_quest_faction_level <<'Essential Trail', 2>>.
value = 1-> max faction points = 10;

value = 2-> max faction points = 20;

value = 3-> max faction points = 35;

value = 4-> max faction points = 55;

value = 5-> max faction points = 75;

value = 6-> max faction points = 100;

value = 7-> max faction points = 125;

value = 8-> max faction points = 150;

value = 9-> max faction points = 200;

If you want to assign a faction title you can use this script. In the example it will assign the second title.
Run script give_quest_faction_title <<'Essential Trail', 2>>.

=== The header ===
The header should contain a lot of information. All the information is commented out by a "#". The example below is from one of the mount quests.

First section is information about the quest itself. Name of the quest, a short description and category. Categories will be discussed in detail later on.

The next sections are for unique items used in the quest, name of the item followed by the description.

The third section is for recording versions of the script and all naming authors. Also who last edited the quest should be noted.

The last section is for additional metadata which will be added to the quest in the database (not part of the db) and will be used by the engine to determine lockouts and prerequisites. Here it locks all players from doing the quest again and locks all other players to take the quest with 60 seconds.

Lastly we tell the engine that the player have to complete the Ring of Familiar quest before this one. Note that these comments aren't taken by the engine; it's the duty of who loads the quest to fill the correct entries with the data found in the header: so it's just a way to keep all data together on the script.

'''Example: Header'''
# Quest name: Drifting for a Drifter
# Quest Description: Taemian wants to sell you a mount
# Quest Category: General
# ----------------------
# Quest Items: Item name/Item description
# Taemian's Pouch: - Pouch with all sorts of coins
# Green Gem of the Drifter - A magical gem with a green glow
# Unsigned Drifter Permit - A permit that still needs to be signed by Datal
# Signed Drifter Permit - A permit that has been signed by Datal
# ----------------------
# Variables used in this quest
# ----------------------
# Quest specific variables used in this quest
# ----------------------
# Author(s): Ravna, Katu, weltall
# Current Version: 1.01
# Player lockout: -1
# Quest lockout: 60
# Prerequisites: <nowiki><pre><completed quest="Ring of Familiar"/></pre></nowiki>
# Variables used: Quest_Variable_Name used to do.....
# ----------------------
# Version history and change log
# Last edited by: weltall
# Version 1.00: Initial draft - 05/01/2010 - Katu.
# Version 1.01: Added extra steps - 1/22/2011 - Venalan.
# ----------------------

==== Quest Lockouts ====
Each quest has two different lockout types:

* Player lockout: When this parameter is set, the engine will wait the specified amount of seconds before allowing the same player to redo the same quest. If you want a quest to be available to each player only one time, then set the lockout to -1. Setting it to 600 will have the engine wait 10 minutes before unlocking the quest again.
* Quest lockout: When this parameter is set, the engine will wait the specified amount of seconds before reactivating the quest for ALL players. This means no one can start the same quest during this period, but the ones that had it already active can complete it.

Usually we want quests to be unique to players, so most have a player lockout -1, except the very simple ones. Try always to think if itâ€™s meaningful for that player to redo it. (For example, Harnquist can require iron ore more than once, but won't need to teach you how to make a sword more than once.)

=== Prerequisites ===
Another more complex version of the prerequisites is the: REQUIRE MIN <number>: this tells the engine that there are specific requirements to be fulfilled before the player is able to get the quest. This script indicated it requires a minimum number of quests to be completed in a given list.

Example: require min 2 of Quest1, Quest2, Quest3.

To match this prerequisite the player can complete Quest1 and Quest3 or 2 and 3, or all 3. The request is minimum 2 in the given list.

CATEGORY MIN <number>: quests have an attribute called "category", we use it to identify the difficulty of quests, but can be used of any other purpose, for example one can say that a group of quests is "Evil" or "Laanx related" or " Newbie". Just one category is allowed per quest. This prerequisite allows you to specify the category and the minimum number of quests completed in that category.

A sample of the coding used to set prerequisites for a quest (All on one line):

'''Example: Prerequisites'''
<nowiki><pre><and></nowiki>
<completed quest="Test Quest One"/>
<completed quest="Test Quest Two"/>
<completed quest="Test Quest Three"/>
<completed quest="Test Quest Four"/>
<not><completed quest="Delivery for Aono Riskas"/></not>
<not><completed quest="Gorbiak Disease"/></not>
</and><nowiki></pre></nowiki>

This sample requires that the player have completed Test Quests 1 through 4 and have NOT completed Fancy Dancing and High-Class Aspirations. To get these arranged correctly can take some practice if one is not familiar with working with booleans, so it is best to include a plain-English comments of what you wish your pre-requisites to be in addition to the one with the "pre" coding statements.

Checks if the player has a certain item equipped . To be documented better

else if (!strncasecmp(block,"equipped",8))

=== Untested Prerequisites ===
Please contact engine in case you want to use any of these prerequisites, because those are untested.

"time of day" // require time of day starthh-endhh (working)

"trait" //require trait name in place

"guild" //NOTE: the both argument is implicitly defined

"active magic" (working)

"known spell"

"race" (working)

"gender" (working)

"married"

"possessed" (working)

"skill" //Require skill <buffed> name <skillmin>-<skillmax>. (working)

"variable" //Require variable name. (working)

= Notes on Creating Quest Files (Rules and Header Information) =

* The quest documents you submit should always be in notepad format: this is to avoid special characters added by Word or other text editors, most notably "smart quotes" which will appear as squares in game. Notepad++ is recommended, HIGHLY recommended.
* Use only ANSI encoding.
* The file name when saving the quest should begin with 'Quest' , then have the name of the quest. For example: Quest Hinoserri Cannot See.txt
* Titles of quests should follow some scheme of capitalization. There are many sets of rules, but a quick and easy format is to capitalize the first word and then all other words, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor.
* Each quest script begins with the title and a one or two sentence description; this is what the player reads so keep that in mind. The proper way to do this is to "comment out" your description and quest title, this is done by beginning a line with the number sign or pound symbol (#). Also, any quest item created for your quest should have a description written into the quest. Notes on quest items should also be commented out. Lastly, there should also be a "Quest Category" line that must be commented out as well. Approved quest categories are: Alchemy, Black Flame, Chain (don't use this one unless told), Cooking, Death Realm, Easy, Gugrontid, Magic Ways, Medium, Metal Working, Newbie, Repeatable. This is a work in progress, so if you have any questions ask an associate dev or developer. No quest can have more than one category - pick one and ONLY one. New quest categories must be approved by the associate devs/devs before use.

Quest scripts syntax

2025-08-02T17:21:29Z

Talad: /* Rewards at the end of the quest */

= Structure of a quest script =
Quests are written out in chunks called steps. Each step covering the requirements of the previous one.

= Things to know before you start =
Quest scripts should written ideally in a text editor and now in MS Word or similar so that no illegal characters make it into the quest dialog which would result in errors when viewed in game.

Quotes are usually the ones which break the scripts and :

• Only ' " should be used

• ‘ ’ ” “ … These should not be present in the text at all.

Any line of text in the script which begins with a ‘#’ character is ignored by the server and only acts as a comment by the author so that they can leave explanations as to what is happening, or, give information about the step number.

The start of a ‘step’ is defined by a series of three dots ‘...’ Everything after this text up until the next ‘...’ is included in the step. The only unique case is the first step, this does not need ‘...’ and includes all the text before the first ‘...’

== Important rules concerning steps ==

* Every step in the quest should be explicitly completed or locked correctly. Example: "Complete Quest Name Step #" before the Quest is completed.
* A step can require the completion of another step by the command: "Requires completion of Quest Name Step #"
* Step 1 does not exist, step 1 is part of the start script (where you use the command "give me a quest") and cannot be used as a require completion of step number.
* You may have multiple Require Completes at the beginning of a step.
* A step may also require another step NOT to have been completed with the command: "Require no completion of Quest Name Step #".
* The Quest name must be exact! It is case sensitive. The same goes for NPC names.
* Each step should be commented like this: "# Step 2 - A description of actions of this step". # Marks it as a comment not processed by the engine.
* You can also check for statements with this syntax: "Require <no/not> operator1 | <no/not> operator2 | ...| <no/not> operatorN." Where operator is a prerequisite (see below the prerequisite chapter), from completion of to time of day etc. The | represents the OR. ''Example: "Require completion of Questname Step 3 | completion of Questname Step 7."''

Let's see an example before beginning the explanation. The following example is made of two steps.

'''Example: Structure 1'''
P: Short Trigger.

Menu: Do you have any work for me to do?

NPC Name: Yes I do. Just breathe one time.

Assign Quest.

...

P: Ok, I did it!

NPC Name: Great, your quest is completed.

== Syntax Basics ==

=== Comments ===
To create a comment line you must start the line with a "#". These lines are not evaluated by the engine as things that need to be done. These comment lines show what is going on and what are the intentions of the quest writer. This is important because more than one person are often working on a quest script, or eventually for laterbug fixing it will be easier to find the exact problem without reading the entire quest.

Each step in a quest should be started by a comment like this "#Step 2 - Description of step.". You can use comments to more that just noting the step number. Any where within the script you can add comments to help your fellow scripters understand the code. We will use comments to explain things within the scripts here.

=== Trigger and Menu ===
The trigger is for the engine, while the menu is what shows up in the player quest menu. The trigger is defined by a "P:".

P: use to be what the player typed to trigger the step, but with the menu system are now used as a description of what step the player is choosing, for example P:yeshelp. (slide 3). The only time you must use exact text is when a player types the answer to a question you pose them

Because you are talking to the engine it must be exact a colon after the "P:" and a period at the end of the sentence. This is also true of the Menu in every case in which the player (P) says something to the NPC in question "P: Short Trigger." comes first, then below comes the "Menu:" line, with exactly the same requirements.

"Menu": Text is what the player sees when they look at the quest menu.

Please remember that the engine does not think, it reacts to the written cues, so the syntax MUST be exact. The first player statement gives the engine the quest name. The Menu allows the player to ask for the quest from the NPC.

Having the two "P:" and two "Menu:" on the same line informs the engine that the player has two different options. It is standard that the "P:" line is above the "Menu:" line and the "No." answer comes first.

These lines trigger the NPC response. In more elaborate quests the "Menu:" line may have variations on the No. or Yes. response. However remember KISS (Keep It Simple Stupid) is generally a good thing to keep in mind when you are beginning. You can have many options, but remember each "P:" must have a matching "Menu:" and they must be put in the same order

In order to include a free textfield, you will have to include a quotation mark after the menu. The <?> has to be followed by <=> and a text. This will produce a printout of the text and the user will be able to enter a free text. E.g. "Menu: ?=What shall Jardet do?" This will result in the text "What shall Jardet do?" being printed, followed by free form input.

P: *. P: rock pick.
Menu: ?=Please tell me your answer.
Smith: No, you didn't get the right answer.
Smith: Yes, it's a rock pick!.

'''Note:''' Remember the : after the P and Menu are important, as is the . at the end of the line.

'''Note:''' For triggers used to start quests, never use NPC names into it, because this will confuse the engine, and the trigger will not be recognized.

'''Note:''' Every P: used in one step must be on the same line

'''Note:''' Every Menu: used in one step must be on the same line

'''Note:''' Every NPC: used in one step must be on different lines.

=== NPC Response ===
Aono Rikas: here you can add a response.

The line above is interpreted as an answer from the NPC and the engine will extract the name before the colon (:) + space as the NPC involved in this step of the quest. From now on, we will call this a response.

The full name of the NPC is required, just the first name will not work. If it is only one name e.g Harnquist use that, and if your NPC somehow ends up with three names use all of them.

In the first step of a quest the NPC statement will end in a question mark and is triggered by the first 2 lines. Responses are linked to each of the Triggers and Menus. So if you have two triggers you need two menu options and two NPC responses. All arranged in the same order.

=== Dialogues ===
The dialogues are the most important part of the quest for a player to get immersed. So let us talk about how to make the dialogue.

* Every punctuation, exclamation mark and question mark will create a short pause in the dialogue and create a new line.
* To create actions all you have to do is to use square brackets within the dialogue like this "Blablabla [NPC Name picks his nose] Bla bla blabla"

You may use also these commands:

$playerrace can be used in an impersonal and a personal manner in terms of context, consider its usage carefully.

$sir which gives you "Sir" or "Madam" or "Gemma" depending on the gender of the player's character. Again, this can be used to positive and negative effect. Be mindful of the NPCâ€™s tone. (Gemma is the honorific for Kran.)

$playername clearly not to be used in newbie quests, have NPC establish rapport use this in second quest or even the third time a player works with a given NPC.

Give me a quest..

= A sample quest script =

== The first step ==
As previously mentioned Step 1 does not exist, it is just the start of the quest, and can not be required by subsequent steps. The Start of the Quest will look something like the example at the beginning (Structure 1).

The same example can also be scripted like this:

'''Example: Structure 2'''
P: Short trigger.

Menu: Initial question, give me a quest.

NPC Name: Yes, I do have a quest for you. I need you to give Item of Importance to NPC2 Name.

P: Yes P: No.

Menu: Yes, I will do that. Menu: No way stupid.

NPC Name: This is the response from the NPC if answer is Yes.

Give 1 Item of Importance.

Assign Quest.

NPC Name: This is the response from the NPC if answer is No.

In Structure 2 the answers "No" and "Yes" are inverted, like the two "Menu:" commands, so it will give the same result as Structure 1. (Answer No: nothing happens. Answer Yes: the player will get 1Item of Importance and the Quest.)

Now, let us use a more detailed example. We will make a very simple quest: Aono wants to deliver a bottle of milk to Orchibaly. The player can choose the quest from Aono's quest menu. Orchibaly will then give the player 2 pies and a receipt to give back to Aono. The first step will be the step that assigns the quest. The P: tells the engine that this line represents something the player will say to the NPC, but what you must pay extra attention to is the "Menu:" This will be what the player will see as an option in the quest menu. If there are several options you will have to create one "P:" and a "Menu:" for each of them.

Here we firstly gives the player the option to ask for the quest. Then Aono describes the nature of the quest and the player can choose yes or no. Right after the "Menu:" line the NPC responsewill be put. In this example Aono will reply: "Well, I will get someone else to do it for me." if the player says no or "That's great. Here is the milk. Be sure not to spill it. TellOrchibaly I sent you.", give the player 1 Milk Bottle and assign the quest.

'''Example: Assign Quest'''
# Quest: Delivery for Aono Rikas

# Quest Description: Sample Quest.

# The rest of the header will not be covered here.

# Step 1 Aono Rikas in Hydlaa needs someone to deliver milk to Orchibally Gurpleferd in Ojaveda.

P: Delivery for Aono Rikas.

Menu: Are there any jobs you need done?

Aono Rikas: Well, yes. I need some milk delivered to Orchibaly in Ojaveda. Can you do this for me?

P: No. P: Yes.

Menu: No. Menu: Yes.

Aono Rikas: Well I will get someone else to do it for me.

Aono Rikas: That's great. Here is the milk. Be sure not to spill it. Tell Orchibaly I sent you.

Give 1 Milk Bottle.

Assign Quest.

A quest can be automatically assigned or there can be a step at the beginning of the quest to ask the player if he accepts it.

If you want to assign it automatically use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here.
Assign quest.

If you want to ask the player use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here, with the question if you want to help.
P: nohelp. P: yeshelp.
Menu: I don't want to. Menu: Yes I will help.
NPC: Fine... Go away.
NPC: Good great.
Assign quest.

'''Note:''' The “Assign quest.” command will only trigger after the second NPC: dialogue line is triggered, nothing happens if the first is triggered.

== The next step ==
To separate the step we use "..." and then a comment on what step it is and what the step is about. If you don't want this step to be repeatable you will also have to add "NoRepeat" after the "...". The second step does not need a completion of Step 1, because Step 1 does not exist so to speak. The structure will be more or less the same as for the initial step.

Let us continue our Delivery for Aono Quest. We have assigned the quest and the player has been given 1 Milk Bottle to give to Orchibaly. Now the player must give that milk to Orchibaly. Either by using the give GUI or by using the quest menu. The first thing we have to do here is to set up the give trigger. If the player gives Orchibaly the milk, he will answer "Oh, yes the milk. Please give it to me. Now i need you to deliver these two pies and this receipt back toAono.", Give the player 2 pies and a Receipt from Orchibaly. The step is then completed.

In this example although the player is given two pies no "s" is added to the line. This is important, especially because most writers tend to add a plural automatically to plural items. Remember the engine does not. An item is designated in the singular, the engine always interprets it in the singular regardless of the number included. The numbers are again not spelt out and Arabic numerals used. Remember that each "Player gives"-command must have menu option in the next line.

'''Example: Step 2'''
... NoRepeat

# Step 2 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this bottle of milk.

Orchibaly Gurpleferd: Thanks, please give it to me. Now deliver two pies and a receipt back to Aono.

Give 2 Pie. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 2.

Completing a step

At the end of a step remember to insert the line:

"Complete Delivery for Aono Rikas Step 2."

Note the use of Capitals, the use of the quest name, the use of the appropriate numeral and the period at the end of the sentence. The line marks the step as complete and allows the player and the quest to move forward.

== Last step ==
To make sure the player has completed the previous step we start with "Require completion of delivery for Aono step 2.". Then we move on to the trigger which is the player giving 2 pies and the receipt to Aono. Aono answers "Ah, pie. Thank you. Please accept this for your time.", gives the player a pie and 100Tria. The step is closed and so is the quest with "Complete Delivery for Aono Rikas."

'''Example: Last Step'''
...NoRepeat.

# Step 3 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of delivery for Aono step 2.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here are your pies and your receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

'''NOTE:''' If you use multiple options in the last step of a quest you have to explicitly complete the quest with a command for the first option.

'''Example: Last step with multiple options'''

P: No. P: Yes.

Merchant: Quest doesn't complete automatically so make sure you have added a complete line for this response.

Complete Harnquist Needs Gold Step 2. Complete Harnquist Needs Gold.

Merchant: Quest completes automatically because it is the last line in quest so no complete line is required.

Complete Harnquist Needs Gold Step 2.

If you omit the Complete Step and Complete Quest line, the quest will not end properly when choosing "no".

== Branches of a quest (Non exclusive) ==
Some times you want to have several different outcomes for a quest. Let us use the Delivery quest once again. If the first NPC says that you must NOT give the milk to some one else... specially NPC3. Then you should also add the option for the player to actually give the milk to NPC3 . This will complicate your script a bit, but is not as hard as it might seem. Most of the job is done by placing the right "Require completion of" and "Require no completion of" commands.

Let us take a look at that Delivery Quest again. Now we want to add an option for the player to give the milk to Reffitia instead. Reffitia will shake the milk until it becomes butter and this will make Orchibaly angry and demand a new bottle of milk. To do that we will have to add a few more steps and we will start from step 2 as step 1 will be the same as above.

The Third step will be our previous Step 2. And the last step will be the same. Though Aono should mention something like: "Make sure you don't give that milk toReffitia." in Step 1.

IMPORTANT NOTE: This is a non exclusive branching, meaning that the first branch is available also when executing the second one.

IMPORTANT NOTE: We will not add an additional step for the player to get milk again from Aono, but the player have to figure out another way to get hold of it (Buy from an NPC).

'''Example: Branching'''
... NoRepeat

# Step 2 - Alternative is to give the milk to refittia

Player gives 1 Milk Bottle to Reffitia

Menu: Here Reffitia, take this milk.

Reffitia Thamal: Ah! Orchibaly's milk. Here, now you can give the bottle to Orchibaly.

Give 1 Bottle of Butter.

Complete Delivery for Aono Rikas Step 2.

... NoRepeat

# Step 3 - Player gives bottle of butter to Orchy.
# The player then have to find another way of getting a bottle of milk (buy from NPC?)

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 4.

... NoRepeat

# Step 5 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Alternative outcome ==
If we wanted the quest to have a different outcome if the player gives the milk to Reffitia than to Orchibaly we would need to get creative with the require commands. Let us say that if the player gives butter to Orchibaly he will give "bad pies" so when Aono receives them and takes a taste he will be very angry and no reward is given. To do this we will have to add just one more step. Let us start with step 3. Here we will have to change only the NPC response a bit to something like "Milk? This is butter. Have you been shaking the bottle all the way over here? This is completely useless to me, butter I have more than enough of. Any way someMenki came with another bottle just before you. Here takes these pies to Aono . Oh, and don't forget this receipt.". Step 4 will be the step where the player gives the bad pies to Aono, this step will complete the quest. Step 5 and 6 are the outcome if the player gives the milk directly toOrchibaly. Notice that Step 5 require a NO completion of Step 4. This is actually not necessary for this script, because the previous the other branch of the quest, ending in step 4 closes the quest it self.

'''Example: Alternative Outcome'''
# Step 3 - Player gives bottle of butter to Orchy. And receives 2 pies and a receipt

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Give 2 Pie. Give 1 Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the "bad" pies and the receipt to Aono. Receives gunk as reward and Quest is completed.

Require completion of Delivery for Aono Rikas Step 3

Player gives Orchibaly Gurpleferd 2 Pie, 1 Receipt from Orchibaly.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. [Aono takes a bite at the pie] You have tricked me!

Give 1 Gunk.

Complete Delivery for Aono Rikas Step 4.

Complete Delivery for Aono Rikas.

...
# Step 5 - Player gives the milk directly to Orchibaly.

Require no completion of Delivery for Aono Step 4.

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 5.

... NoRepeat

# Step 6 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Quest Timeout (Passing of time) ==
If you want to allow a certain part of the quest to wait a certain amount of time before it can be a executed, you can use this script:<blockquote>Run script give_quest_timeout <<'Time until Harnquist is ready',6>></blockquote>this will create a temporary active magic with name 'Time until Harnquist is ready' which will last for 6 minutes.

Then in the prerequisite of the step have this:<blockquote># Step 12.

Require active magic Time until Harnquist is ready.

P: swordnotready.

Menu: Is Vresa's sword ready yet?

Harnquist: No, not yet.

...

# Step 13.

Require no active magic Time until Harnquist is ready.

P: about Vresa sword.

Menu: Is Vresa's sword ready?

Harnquist: Yes, Vresa's sword is done. </blockquote>

= Important commands and expressions used =

== Assign Quest. ==
This line tells the engine to assign the quest to the player and generally results in the "YOU GOT A QUEST". and placing the quest in the player's quest log, under "uncompleted". Again remember to be exact here, Capitalize the two words and put a "." at the end. It cannot be emphasized enough that the engine only interprets what it sees and the way it sees it. If you are not precise the quest will NOT happen or in the cases of the next steps move forward.

== ... ==
The three dots mark the beginning of a new step. Better, the three dots create a new step. So you need a "three dots" line before every "Complete Quest Name Step #"

== NoRepeat. ==
This line means that the quest step cannot be done over and over. Note that there are three periods "..." a space and 'NoRepeat.' is one word not two. Each part of this sentence is required in exactly this form.

Basically "..." tells the engine that some time can pass before the next lines are used.

NoRepeat allows this quest step to be only done one time. This also applies to actions as seen in later steps. (in reality NoRepeat is a synonym for Require no completion of "this step")

== Require completion of Quest Name Step #. ==
This command is like a closed door. To open it and enter in the current step the player needs to complete the step number #. You can also refer to a future step (for example, you're on step 4 and add "Require completion of Quest Name Step 8.")

== Require no completion of Quest Name Step #. ==
This command is like an open door. The player is free to continue the quest and entering the current step, UNLESS he completed the step number #. Completing the step number # will close the door. Forever! You can also refer to a future step.

== Complete Quest Name Step #. ==
This command completes a step, # being the step number. You can complete one step in another one. But remember to insert one "..." line for every "Complete Quest Name Step #." line.

== Complete Quest Name. ==
This command will end the quest. After this the quest will be deleted from the uncompleted quest list and appear in the Completed quest list.

== P: ==
The trigger is actually a ghost from the previous scripting system, but it is still needed (for now). Before the player had to type the exact trigger stated after the "P:". Now they click the option from "Menu:". Triggers must be four words or less. Triggers must end with a period, no other punctuation is allowed (question marks especially are known to break aquest on the server).

If you want multiple phrases to activate the same trigger, you can just separate the phrases by a period; for example: "P: about guards. about hydlaa guards. about hydlaa militia." In this case the NPC's response will be fired on any of the three options. This technique can be used also when you have multiple choices: "P: one. two. P: more.". Both 'one' and 'two' will trigger the first response, while 'more' will trigger the second.

WARNING: Triggers cannot contain any of the following words: a, am, an, and, any, anything, are, do, I, is, isnâ€™t, please, that, the, this, to, too.

They also may not contain the name of the NPC you're talking to as that'll be stripped.

These words just take up space in a trigger as they are dropped by the engine when evaluating player response. To make the best use of your word counts ignore them when writing your triggers.

Example: If you wanted the player to say 'please help Levrus' the trigger would become 'help levrus' as please would be an ignored word.

WARNING: If a player needs to write "NPC needs this" syntax it as "NPC wants this".

== Menu: ==
That's easy. After this command you can add the sentence said by the player in game. This sentence will appear on the screen and could be selected when one talks to the NPC.

Remember that for every menu line you need to create a response from the NPC.

== Give ==
Give is a very useful command. It tells the engine to give the player items. Be it rewards or special items needed for the quest. When you reward a player, you can basically give items and/or experience. The syntax to award 1500 experience points would be: "Give 1500 Exp." Note that "Exp" is case-sensitive. You can also reward items AND experience, using this syntax: "Give Leather Gloves. Give 1500 Exp." Remember that you can only have two give commands on the same line, but you can have multiple lines, Remember to keep a clean style, it is prefered to only have one item per line.

'''Example: Give more than two items'''
Give 1 Leather Gloves.
Give 1500 Exp.
Give 1 Apple.

You can also add a number if you need to give more than one item (like you do for experience) example: "Give 5 Iron Ingot." It is not necessary in the case of one item to include the numeral, however it is good practice to do so as numerals tell the engine how many and should be written as a numeral, a word will NOT work as the engine cannot interpret it as such. Remember that all special items must be declared in the script header.

Another option you have is to give one item OR another. The following will pop up a window in which the player has to choose just one item:

'''Example: Give the player a choice between items'''
Give Cold or Arrow or Energy.
'''WARNING:''' At this time, don't use the following in an OR option: Tria, hexa, octa, circles, or items without a graphic. Also, for now, do NOT put quantities in front of items that are given using the "OR" parameter. An example of what NOT to do: "Give 1 Cold or 1 Arrow or 1 Energy." This will lock the server right up. An example of what SHOULD be done: "Give Cold or Arrow or Energy." (Check this statement if it is correct. --Katu)

== Player gives NPC Name 1 Item ==
This can be used as a trigger (instead of the "P:"). It tells the engine to trigger the NPC dialogue when one or any fixed amount of a special item.

When a player have to give multiple items just add them to the original line using a comma:

'''Example Player gives item'''
Player gives Harnquist Water Pouch, 1 Pie.

'''WARNING:''' Item name rules must be followed at all times.

Notice that the item name is "Iron Ingot", so "Iron Ingots" will not work, even if itâ€™s the correct plural form. Keep all names singular.

Also, do not use a number (3, 14, etc) in the name of an item. An item called 3 Circles Receipt will probably generate problems when we script "Give 3 Circles Receipt." It is better named "Three Circles Receipt."

Numbers should be spelled out everywhere unless you are referring to the quantity given or dealing with a trigger (give me 5 apples. give me five apples.) as both would be correct in a trigger.

Character limit for an item name is 60 characters.

Do not use an s' in an item name, like "Levrus' Left Shoe," use "Left Shoe of Levrus" or a similar substitute instead.

== Set variable Require variable ==
You can set a variable to be later used by the quest or other quests. Variables are set on the character and visible from all quests.
Smith: Here is your winch access
Setvariable Quest_Winch_Access 1

You can then require a variable to be set as prerequisite of a quest step.
Require variable Quest_Winch_Access.
P: access.
Menu: I have access
Bobaus: Ok, good.

== Require Compendium ==
You can require the player to have a certain knowledge in the Compendium.
Require compendium creature StoneHammer
P: comps
Menu: I know everything about the StoneHammers!
Fighter3: WOW
...
Require no compendium creature StoneHammer
P: nocomps
Menu: Sorry I dont know anything about StoneHammers!
Fighter3: Ah, study more!

The syntax is: compendium <creature/plant/mineral> <name>

== Rewards at the end of the quest ==
When completing a quest, the player usually gets experience and money, or some items. In particular for experience and money you should use the following scripts. This allows us to split the rewards on a scale from 1 to 10 and then to tweak the actual values in the engine. The values in brackets indicate the complexity of the quest. The more complex the more rewards the player will get.

Run script give_quest_money <<3>>.
Run script give_quest_exp <<2>>.
You can also award faction points by using "give_quest_faction" , the number given is multiplied by 5 so if you want +5 point, you need 1 on the second parameter:
Run script give_quest_faction <<'Essential Trail', 1>>.
We have script also to push the faction point up to a given value, if you are already higher, this script will do nothing.
Run script give_quest_faction_level <<'Essential Trail', 2>>.
value = 1-> max faction points = 10;

value = 2-> max faction points = 20;

value = 3-> max faction points = 35;

value = 4-> max faction points = 55;

value = 5-> max faction points = 75;

value = 6-> max faction points = 100;

value = 7-> max faction points = 125;

value = 8-> max faction points = 150;

value = 9-> max faction points = 200;

If you want to assign a faction title you can use this script. In the example it will assign the second title.
Run script give_quest_faction_title <<'Essential Trail', 2>>.

=== The header ===
The header should contain a lot of information. All the information is commented out by a "#". The example below is from one of the mount quests.

First section is information about the quest itself. Name of the quest, a short description and category. Categories will be discussed in detail later on.

The next sections are for unique items used in the quest, name of the item followed by the description.

The third section is for recording versions of the script and all naming authors. Also who last edited the quest should be noted.

The last section is for additional metadata which will be added to the quest in the database (not part of the db) and will be used by the engine to determine lockouts and prerequisites. Here it locks all players from doing the quest again and locks all other players to take the quest with 60 seconds.

Lastly we tell the engine that the player have to complete the Ring of Familiar quest before this one. Note that these comments aren't taken by the engine; it's the duty of who loads the quest to fill the correct entries with the data found in the header: so it's just a way to keep all data together on the script.

'''Example: Header'''
# Quest name: Drifting for a Drifter
# Quest Description: Taemian wants to sell you a mount
# Quest Category: General
# ----------------------
# Quest Items: Item name/Item description
# Taemian's Pouch: - Pouch with all sorts of coins
# Green Gem of the Drifter - A magical gem with a green glow
# Unsigned Drifter Permit - A permit that still needs to be signed by Datal
# Signed Drifter Permit - A permit that has been signed by Datal
# ----------------------
# Variables used in this quest
# ----------------------
# Quest specific variables used in this quest
# ----------------------
# Author(s): Ravna, Katu, weltall
# Current Version: 1.01
# Player lockout: -1
# Quest lockout: 60
# Prerequisites: <nowiki><pre><completed quest="Ring of Familiar"/></pre></nowiki>
# Variables used: Quest_Variable_Name used to do.....
# ----------------------
# Version history and change log
# Last edited by: weltall
# Version 1.00: Initial draft - 05/01/2010 - Katu.
# Version 1.01: Added extra steps - 1/22/2011 - Venalan.
# ----------------------

==== Quest Lockouts ====
Each quest has two different lockout types:

* Player lockout: When this parameter is set, the engine will wait the specified amount of seconds before allowing the same player to redo the same quest. If you want a quest to be available to each player only one time, then set the lockout to -1. Setting it to 600 will have the engine wait 10 minutes before unlocking the quest again.
* Quest lockout: When this parameter is set, the engine will wait the specified amount of seconds before reactivating the quest for ALL players. This means no one can start the same quest during this period, but the ones that had it already active can complete it.

Usually we want quests to be unique to players, so most have a player lockout -1, except the very simple ones. Try always to think if itâ€™s meaningful for that player to redo it. (For example, Harnquist can require iron ore more than once, but won't need to teach you how to make a sword more than once.)

=== Prerequisites ===
Another more complex version of the prerequisites is the: REQUIRE MIN <number>: this tells the engine that there are specific requirements to be fulfilled before the player is able to get the quest. This script indicated it requires a minimum number of quests to be completed in a given list.

Example: require min 2 of Quest1, Quest2, Quest3.

To match this prerequisite the player can complete Quest1 and Quest3 or 2 and 3, or all 3. The request is minimum 2 in the given list.

CATEGORY MIN <number>: quests have an attribute called "category", we use it to identify the difficulty of quests, but can be used of any other purpose, for example one can say that a group of quests is "Evil" or "Laanx related" or " Newbie". Just one category is allowed per quest. This prerequisite allows you to specify the category and the minimum number of quests completed in that category.

A sample of the coding used to set prerequisites for a quest (All on one line):

'''Example: Prerequisites'''
<nowiki><pre><and></nowiki>
<completed quest="Test Quest One"/>
<completed quest="Test Quest Two"/>
<completed quest="Test Quest Three"/>
<completed quest="Test Quest Four"/>
<not><completed quest="Delivery for Aono Riskas"/></not>
<not><completed quest="Gorbiak Disease"/></not>
</and><nowiki></pre></nowiki>

This sample requires that the player have completed Test Quests 1 through 4 and have NOT completed Fancy Dancing and High-Class Aspirations. To get these arranged correctly can take some practice if one is not familiar with working with booleans, so it is best to include a plain-English comments of what you wish your pre-requisites to be in addition to the one with the "pre" coding statements.

Checks if the player has a certain item equipped . To be documented better

else if (!strncasecmp(block,"equipped",8))

=== Untested Prerequisites ===
Please contact engine in case you want to use any of these prerequisites, because those are untested.

"time of day" // require time of day starthh-endhh (working)

"trait" //require trait name in place

"guild" //NOTE: the both argument is implicitly defined

"active magic" (working)

"known spell"

"race" (working)

"gender" (working)

"married"

"possessed" (working)

"skill" //Require skill <buffed> name <skillmin>-<skillmax>. (working)

"variable" //Require variable name. (working)

= Notes on Creating Quest Files (Rules and Header Information) =

* The quest documents you submit should always be in notepad format: this is to avoid special characters added by Word or other text editors, most notably "smart quotes" which will appear as squares in game. Notepad++ is recommended, HIGHLY recommended.
* Use only ANSI encoding.
* The file name when saving the quest should begin with 'Quest' , then have the name of the quest. For example: Quest Hinoserri Cannot See.txt
* Titles of quests should follow some scheme of capitalization. There are many sets of rules, but a quick and easy format is to capitalize the first word and then all other words, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor.
* Each quest script begins with the title and a one or two sentence description; this is what the player reads so keep that in mind. The proper way to do this is to "comment out" your description and quest title, this is done by beginning a line with the number sign or pound symbol (#). Also, any quest item created for your quest should have a description written into the quest. Notes on quest items should also be commented out. Lastly, there should also be a "Quest Category" line that must be commented out as well. Approved quest categories are: Alchemy, Black Flame, Chain (don't use this one unless told), Cooking, Death Realm, Easy, Gugrontid, Magic Ways, Medium, Metal Working, Newbie, Repeatable. This is a work in progress, so if you have any questions ask an associate dev or developer. No quest can have more than one category - pick one and ONLY one. New quest categories must be approved by the associate devs/devs before use.

Quest scripts syntax

2025-08-02T17:19:28Z

Talad: /* Rewards at the end of the quest */

= Structure of a quest script =
Quests are written out in chunks called steps. Each step covering the requirements of the previous one.

= Things to know before you start =
Quest scripts should written ideally in a text editor and now in MS Word or similar so that no illegal characters make it into the quest dialog which would result in errors when viewed in game.

Quotes are usually the ones which break the scripts and :

• Only ' " should be used

• ‘ ’ ” “ … These should not be present in the text at all.

Any line of text in the script which begins with a ‘#’ character is ignored by the server and only acts as a comment by the author so that they can leave explanations as to what is happening, or, give information about the step number.

The start of a ‘step’ is defined by a series of three dots ‘...’ Everything after this text up until the next ‘...’ is included in the step. The only unique case is the first step, this does not need ‘...’ and includes all the text before the first ‘...’

== Important rules concerning steps ==

* Every step in the quest should be explicitly completed or locked correctly. Example: "Complete Quest Name Step #" before the Quest is completed.
* A step can require the completion of another step by the command: "Requires completion of Quest Name Step #"
* Step 1 does not exist, step 1 is part of the start script (where you use the command "give me a quest") and cannot be used as a require completion of step number.
* You may have multiple Require Completes at the beginning of a step.
* A step may also require another step NOT to have been completed with the command: "Require no completion of Quest Name Step #".
* The Quest name must be exact! It is case sensitive. The same goes for NPC names.
* Each step should be commented like this: "# Step 2 - A description of actions of this step". # Marks it as a comment not processed by the engine.
* You can also check for statements with this syntax: "Require <no/not> operator1 | <no/not> operator2 | ...| <no/not> operatorN." Where operator is a prerequisite (see below the prerequisite chapter), from completion of to time of day etc. The | represents the OR. ''Example: "Require completion of Questname Step 3 | completion of Questname Step 7."''

Let's see an example before beginning the explanation. The following example is made of two steps.

'''Example: Structure 1'''
P: Short Trigger.

Menu: Do you have any work for me to do?

NPC Name: Yes I do. Just breathe one time.

Assign Quest.

...

P: Ok, I did it!

NPC Name: Great, your quest is completed.

== Syntax Basics ==

=== Comments ===
To create a comment line you must start the line with a "#". These lines are not evaluated by the engine as things that need to be done. These comment lines show what is going on and what are the intentions of the quest writer. This is important because more than one person are often working on a quest script, or eventually for laterbug fixing it will be easier to find the exact problem without reading the entire quest.

Each step in a quest should be started by a comment like this "#Step 2 - Description of step.". You can use comments to more that just noting the step number. Any where within the script you can add comments to help your fellow scripters understand the code. We will use comments to explain things within the scripts here.

=== Trigger and Menu ===
The trigger is for the engine, while the menu is what shows up in the player quest menu. The trigger is defined by a "P:".

P: use to be what the player typed to trigger the step, but with the menu system are now used as a description of what step the player is choosing, for example P:yeshelp. (slide 3). The only time you must use exact text is when a player types the answer to a question you pose them

Because you are talking to the engine it must be exact a colon after the "P:" and a period at the end of the sentence. This is also true of the Menu in every case in which the player (P) says something to the NPC in question "P: Short Trigger." comes first, then below comes the "Menu:" line, with exactly the same requirements.

"Menu": Text is what the player sees when they look at the quest menu.

Please remember that the engine does not think, it reacts to the written cues, so the syntax MUST be exact. The first player statement gives the engine the quest name. The Menu allows the player to ask for the quest from the NPC.

Having the two "P:" and two "Menu:" on the same line informs the engine that the player has two different options. It is standard that the "P:" line is above the "Menu:" line and the "No." answer comes first.

These lines trigger the NPC response. In more elaborate quests the "Menu:" line may have variations on the No. or Yes. response. However remember KISS (Keep It Simple Stupid) is generally a good thing to keep in mind when you are beginning. You can have many options, but remember each "P:" must have a matching "Menu:" and they must be put in the same order

In order to include a free textfield, you will have to include a quotation mark after the menu. The <?> has to be followed by <=> and a text. This will produce a printout of the text and the user will be able to enter a free text. E.g. "Menu: ?=What shall Jardet do?" This will result in the text "What shall Jardet do?" being printed, followed by free form input.

P: *. P: rock pick.
Menu: ?=Please tell me your answer.
Smith: No, you didn't get the right answer.
Smith: Yes, it's a rock pick!.

'''Note:''' Remember the : after the P and Menu are important, as is the . at the end of the line.

'''Note:''' For triggers used to start quests, never use NPC names into it, because this will confuse the engine, and the trigger will not be recognized.

'''Note:''' Every P: used in one step must be on the same line

'''Note:''' Every Menu: used in one step must be on the same line

'''Note:''' Every NPC: used in one step must be on different lines.

=== NPC Response ===
Aono Rikas: here you can add a response.

The line above is interpreted as an answer from the NPC and the engine will extract the name before the colon (:) + space as the NPC involved in this step of the quest. From now on, we will call this a response.

The full name of the NPC is required, just the first name will not work. If it is only one name e.g Harnquist use that, and if your NPC somehow ends up with three names use all of them.

In the first step of a quest the NPC statement will end in a question mark and is triggered by the first 2 lines. Responses are linked to each of the Triggers and Menus. So if you have two triggers you need two menu options and two NPC responses. All arranged in the same order.

=== Dialogues ===
The dialogues are the most important part of the quest for a player to get immersed. So let us talk about how to make the dialogue.

* Every punctuation, exclamation mark and question mark will create a short pause in the dialogue and create a new line.
* To create actions all you have to do is to use square brackets within the dialogue like this "Blablabla [NPC Name picks his nose] Bla bla blabla"

You may use also these commands:

$playerrace can be used in an impersonal and a personal manner in terms of context, consider its usage carefully.

$sir which gives you "Sir" or "Madam" or "Gemma" depending on the gender of the player's character. Again, this can be used to positive and negative effect. Be mindful of the NPCâ€™s tone. (Gemma is the honorific for Kran.)

$playername clearly not to be used in newbie quests, have NPC establish rapport use this in second quest or even the third time a player works with a given NPC.

Give me a quest..

= A sample quest script =

== The first step ==
As previously mentioned Step 1 does not exist, it is just the start of the quest, and can not be required by subsequent steps. The Start of the Quest will look something like the example at the beginning (Structure 1).

The same example can also be scripted like this:

'''Example: Structure 2'''
P: Short trigger.

Menu: Initial question, give me a quest.

NPC Name: Yes, I do have a quest for you. I need you to give Item of Importance to NPC2 Name.

P: Yes P: No.

Menu: Yes, I will do that. Menu: No way stupid.

NPC Name: This is the response from the NPC if answer is Yes.

Give 1 Item of Importance.

Assign Quest.

NPC Name: This is the response from the NPC if answer is No.

In Structure 2 the answers "No" and "Yes" are inverted, like the two "Menu:" commands, so it will give the same result as Structure 1. (Answer No: nothing happens. Answer Yes: the player will get 1Item of Importance and the Quest.)

Now, let us use a more detailed example. We will make a very simple quest: Aono wants to deliver a bottle of milk to Orchibaly. The player can choose the quest from Aono's quest menu. Orchibaly will then give the player 2 pies and a receipt to give back to Aono. The first step will be the step that assigns the quest. The P: tells the engine that this line represents something the player will say to the NPC, but what you must pay extra attention to is the "Menu:" This will be what the player will see as an option in the quest menu. If there are several options you will have to create one "P:" and a "Menu:" for each of them.

Here we firstly gives the player the option to ask for the quest. Then Aono describes the nature of the quest and the player can choose yes or no. Right after the "Menu:" line the NPC responsewill be put. In this example Aono will reply: "Well, I will get someone else to do it for me." if the player says no or "That's great. Here is the milk. Be sure not to spill it. TellOrchibaly I sent you.", give the player 1 Milk Bottle and assign the quest.

'''Example: Assign Quest'''
# Quest: Delivery for Aono Rikas

# Quest Description: Sample Quest.

# The rest of the header will not be covered here.

# Step 1 Aono Rikas in Hydlaa needs someone to deliver milk to Orchibally Gurpleferd in Ojaveda.

P: Delivery for Aono Rikas.

Menu: Are there any jobs you need done?

Aono Rikas: Well, yes. I need some milk delivered to Orchibaly in Ojaveda. Can you do this for me?

P: No. P: Yes.

Menu: No. Menu: Yes.

Aono Rikas: Well I will get someone else to do it for me.

Aono Rikas: That's great. Here is the milk. Be sure not to spill it. Tell Orchibaly I sent you.

Give 1 Milk Bottle.

Assign Quest.

A quest can be automatically assigned or there can be a step at the beginning of the quest to ask the player if he accepts it.

If you want to assign it automatically use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here.
Assign quest.

If you want to ask the player use this format:

P: give me a quest. Or any quest trigger.
Menu: what the play sees go here.
NPC: What the NPC says goes here, with the question if you want to help.
P: nohelp. P: yeshelp.
Menu: I don't want to. Menu: Yes I will help.
NPC: Fine... Go away.
NPC: Good great.
Assign quest.

'''Note:''' The “Assign quest.” command will only trigger after the second NPC: dialogue line is triggered, nothing happens if the first is triggered.

== The next step ==
To separate the step we use "..." and then a comment on what step it is and what the step is about. If you don't want this step to be repeatable you will also have to add "NoRepeat" after the "...". The second step does not need a completion of Step 1, because Step 1 does not exist so to speak. The structure will be more or less the same as for the initial step.

Let us continue our Delivery for Aono Quest. We have assigned the quest and the player has been given 1 Milk Bottle to give to Orchibaly. Now the player must give that milk to Orchibaly. Either by using the give GUI or by using the quest menu. The first thing we have to do here is to set up the give trigger. If the player gives Orchibaly the milk, he will answer "Oh, yes the milk. Please give it to me. Now i need you to deliver these two pies and this receipt back toAono.", Give the player 2 pies and a Receipt from Orchibaly. The step is then completed.

In this example although the player is given two pies no "s" is added to the line. This is important, especially because most writers tend to add a plural automatically to plural items. Remember the engine does not. An item is designated in the singular, the engine always interprets it in the singular regardless of the number included. The numbers are again not spelt out and Arabic numerals used. Remember that each "Player gives"-command must have menu option in the next line.

'''Example: Step 2'''
... NoRepeat

# Step 2 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this bottle of milk.

Orchibaly Gurpleferd: Thanks, please give it to me. Now deliver two pies and a receipt back to Aono.

Give 2 Pie. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 2.

Completing a step

At the end of a step remember to insert the line:

"Complete Delivery for Aono Rikas Step 2."

Note the use of Capitals, the use of the quest name, the use of the appropriate numeral and the period at the end of the sentence. The line marks the step as complete and allows the player and the quest to move forward.

== Last step ==
To make sure the player has completed the previous step we start with "Require completion of delivery for Aono step 2.". Then we move on to the trigger which is the player giving 2 pies and the receipt to Aono. Aono answers "Ah, pie. Thank you. Please accept this for your time.", gives the player a pie and 100Tria. The step is closed and so is the quest with "Complete Delivery for Aono Rikas."

'''Example: Last Step'''
...NoRepeat.

# Step 3 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of delivery for Aono step 2.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here are your pies and your receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

'''NOTE:''' If you use multiple options in the last step of a quest you have to explicitly complete the quest with a command for the first option.

'''Example: Last step with multiple options'''

P: No. P: Yes.

Merchant: Quest doesn't complete automatically so make sure you have added a complete line for this response.

Complete Harnquist Needs Gold Step 2. Complete Harnquist Needs Gold.

Merchant: Quest completes automatically because it is the last line in quest so no complete line is required.

Complete Harnquist Needs Gold Step 2.

If you omit the Complete Step and Complete Quest line, the quest will not end properly when choosing "no".

== Branches of a quest (Non exclusive) ==
Some times you want to have several different outcomes for a quest. Let us use the Delivery quest once again. If the first NPC says that you must NOT give the milk to some one else... specially NPC3. Then you should also add the option for the player to actually give the milk to NPC3 . This will complicate your script a bit, but is not as hard as it might seem. Most of the job is done by placing the right "Require completion of" and "Require no completion of" commands.

Let us take a look at that Delivery Quest again. Now we want to add an option for the player to give the milk to Reffitia instead. Reffitia will shake the milk until it becomes butter and this will make Orchibaly angry and demand a new bottle of milk. To do that we will have to add a few more steps and we will start from step 2 as step 1 will be the same as above.

The Third step will be our previous Step 2. And the last step will be the same. Though Aono should mention something like: "Make sure you don't give that milk toReffitia." in Step 1.

IMPORTANT NOTE: This is a non exclusive branching, meaning that the first branch is available also when executing the second one.

IMPORTANT NOTE: We will not add an additional step for the player to get milk again from Aono, but the player have to figure out another way to get hold of it (Buy from an NPC).

'''Example: Branching'''
... NoRepeat

# Step 2 - Alternative is to give the milk to refittia

Player gives 1 Milk Bottle to Reffitia

Menu: Here Reffitia, take this milk.

Reffitia Thamal: Ah! Orchibaly's milk. Here, now you can give the bottle to Orchibaly.

Give 1 Bottle of Butter.

Complete Delivery for Aono Rikas Step 2.

... NoRepeat

# Step 3 - Player gives bottle of butter to Orchy.
# The player then have to find another way of getting a bottle of milk (buy from NPC?)

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the milk to Orchibaly

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 4.

... NoRepeat

# Step 5 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Alternative outcome ==
If we wanted the quest to have a different outcome if the player gives the milk to Reffitia than to Orchibaly we would need to get creative with the require commands. Let us say that if the player gives butter to Orchibaly he will give "bad pies" so when Aono receives them and takes a taste he will be very angry and no reward is given. To do this we will have to add just one more step. Let us start with step 3. Here we will have to change only the NPC response a bit to something like "Milk? This is butter. Have you been shaking the bottle all the way over here? This is completely useless to me, butter I have more than enough of. Any way someMenki came with another bottle just before you. Here takes these pies to Aono . Oh, and don't forget this receipt.". Step 4 will be the step where the player gives the bad pies to Aono, this step will complete the quest. Step 5 and 6 are the outcome if the player gives the milk directly toOrchibaly. Notice that Step 5 require a NO completion of Step 4. This is actually not necessary for this script, because the previous the other branch of the quest, ending in step 4 closes the quest it self.

'''Example: Alternative Outcome'''
# Step 3 - Player gives bottle of butter to Orchy. And receives 2 pies and a receipt

Require completion of Delivery for Aono Rikas Step 2.

Player gives Orchibaly Gurpleferd 1 Bottle of Butter.

Menu: Um, here is the milk from Aono.

Orchibaly Gurpleferd: Milk? This is butter. You better get me another bottle of milk, fast!

Give 2 Pie. Give 1 Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 3.

... NoRepeat

# Step 4 - Player gives the "bad" pies and the receipt to Aono. Receives gunk as reward and Quest is completed.

Require completion of Delivery for Aono Rikas Step 3

Player gives Orchibaly Gurpleferd 2 Pie, 1 Receipt from Orchibaly.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. [Aono takes a bite at the pie] You have tricked me!

Give 1 Gunk.

Complete Delivery for Aono Rikas Step 4.

Complete Delivery for Aono Rikas.

...
# Step 5 - Player gives the milk directly to Orchibaly.

Require no completion of Delivery for Aono Step 4.

Player gives Orchibaly Gurpleferd 1 Milk Bottle.

Menu: Aono asked me to give you this milk.

Orchibaly Gurpleferd: Oh, yes the milk. Now i need you to deliver these two pies and this receipt back to Aono.

Give 2 Pies. Give Receipt from Orchibaly.

Complete Delivery for Aono Rikas Step 5.

... NoRepeat

# Step 6 - Player has now returned to Aono in Hydlaa. Player must now give Aono the 2 Pies and 1 Receipt.

Require completion of Delivery for Aono Rikas Step 4.

Player gives Aono Rikas 2 Pie, 1 Receipt.

Menu: Here take these pies and the receipt.

Aono Rikas: Ah, pie. Thank you. Please accept this for your time.

Give 100 Tria. Give 1 Pie.

Complete Delivery for Aono Rikas.

== Quest Timeout (Passing of time) ==
If you want to allow a certain part of the quest to wait a certain amount of time before it can be a executed, you can use this script:<blockquote>Run script give_quest_timeout <<'Time until Harnquist is ready',6>></blockquote>this will create a temporary active magic with name 'Time until Harnquist is ready' which will last for 6 minutes.

Then in the prerequisite of the step have this:<blockquote># Step 12.

Require active magic Time until Harnquist is ready.

P: swordnotready.

Menu: Is Vresa's sword ready yet?

Harnquist: No, not yet.

...

# Step 13.

Require no active magic Time until Harnquist is ready.

P: about Vresa sword.

Menu: Is Vresa's sword ready?

Harnquist: Yes, Vresa's sword is done. </blockquote>

= Important commands and expressions used =

== Assign Quest. ==
This line tells the engine to assign the quest to the player and generally results in the "YOU GOT A QUEST". and placing the quest in the player's quest log, under "uncompleted". Again remember to be exact here, Capitalize the two words and put a "." at the end. It cannot be emphasized enough that the engine only interprets what it sees and the way it sees it. If you are not precise the quest will NOT happen or in the cases of the next steps move forward.

== ... ==
The three dots mark the beginning of a new step. Better, the three dots create a new step. So you need a "three dots" line before every "Complete Quest Name Step #"

== NoRepeat. ==
This line means that the quest step cannot be done over and over. Note that there are three periods "..." a space and 'NoRepeat.' is one word not two. Each part of this sentence is required in exactly this form.

Basically "..." tells the engine that some time can pass before the next lines are used.

NoRepeat allows this quest step to be only done one time. This also applies to actions as seen in later steps. (in reality NoRepeat is a synonym for Require no completion of "this step")

== Require completion of Quest Name Step #. ==
This command is like a closed door. To open it and enter in the current step the player needs to complete the step number #. You can also refer to a future step (for example, you're on step 4 and add "Require completion of Quest Name Step 8.")

== Require no completion of Quest Name Step #. ==
This command is like an open door. The player is free to continue the quest and entering the current step, UNLESS he completed the step number #. Completing the step number # will close the door. Forever! You can also refer to a future step.

== Complete Quest Name Step #. ==
This command completes a step, # being the step number. You can complete one step in another one. But remember to insert one "..." line for every "Complete Quest Name Step #." line.

== Complete Quest Name. ==
This command will end the quest. After this the quest will be deleted from the uncompleted quest list and appear in the Completed quest list.

== P: ==
The trigger is actually a ghost from the previous scripting system, but it is still needed (for now). Before the player had to type the exact trigger stated after the "P:". Now they click the option from "Menu:". Triggers must be four words or less. Triggers must end with a period, no other punctuation is allowed (question marks especially are known to break aquest on the server).

If you want multiple phrases to activate the same trigger, you can just separate the phrases by a period; for example: "P: about guards. about hydlaa guards. about hydlaa militia." In this case the NPC's response will be fired on any of the three options. This technique can be used also when you have multiple choices: "P: one. two. P: more.". Both 'one' and 'two' will trigger the first response, while 'more' will trigger the second.

WARNING: Triggers cannot contain any of the following words: a, am, an, and, any, anything, are, do, I, is, isnâ€™t, please, that, the, this, to, too.

They also may not contain the name of the NPC you're talking to as that'll be stripped.

These words just take up space in a trigger as they are dropped by the engine when evaluating player response. To make the best use of your word counts ignore them when writing your triggers.

Example: If you wanted the player to say 'please help Levrus' the trigger would become 'help levrus' as please would be an ignored word.

WARNING: If a player needs to write "NPC needs this" syntax it as "NPC wants this".

== Menu: ==
That's easy. After this command you can add the sentence said by the player in game. This sentence will appear on the screen and could be selected when one talks to the NPC.

Remember that for every menu line you need to create a response from the NPC.

== Give ==
Give is a very useful command. It tells the engine to give the player items. Be it rewards or special items needed for the quest. When you reward a player, you can basically give items and/or experience. The syntax to award 1500 experience points would be: "Give 1500 Exp." Note that "Exp" is case-sensitive. You can also reward items AND experience, using this syntax: "Give Leather Gloves. Give 1500 Exp." Remember that you can only have two give commands on the same line, but you can have multiple lines, Remember to keep a clean style, it is prefered to only have one item per line.

'''Example: Give more than two items'''
Give 1 Leather Gloves.
Give 1500 Exp.
Give 1 Apple.

You can also add a number if you need to give more than one item (like you do for experience) example: "Give 5 Iron Ingot." It is not necessary in the case of one item to include the numeral, however it is good practice to do so as numerals tell the engine how many and should be written as a numeral, a word will NOT work as the engine cannot interpret it as such. Remember that all special items must be declared in the script header.

Another option you have is to give one item OR another. The following will pop up a window in which the player has to choose just one item:

'''Example: Give the player a choice between items'''
Give Cold or Arrow or Energy.
'''WARNING:''' At this time, don't use the following in an OR option: Tria, hexa, octa, circles, or items without a graphic. Also, for now, do NOT put quantities in front of items that are given using the "OR" parameter. An example of what NOT to do: "Give 1 Cold or 1 Arrow or 1 Energy." This will lock the server right up. An example of what SHOULD be done: "Give Cold or Arrow or Energy." (Check this statement if it is correct. --Katu)

== Player gives NPC Name 1 Item ==
This can be used as a trigger (instead of the "P:"). It tells the engine to trigger the NPC dialogue when one or any fixed amount of a special item.

When a player have to give multiple items just add them to the original line using a comma:

'''Example Player gives item'''
Player gives Harnquist Water Pouch, 1 Pie.

'''WARNING:''' Item name rules must be followed at all times.

Notice that the item name is "Iron Ingot", so "Iron Ingots" will not work, even if itâ€™s the correct plural form. Keep all names singular.

Also, do not use a number (3, 14, etc) in the name of an item. An item called 3 Circles Receipt will probably generate problems when we script "Give 3 Circles Receipt." It is better named "Three Circles Receipt."

Numbers should be spelled out everywhere unless you are referring to the quantity given or dealing with a trigger (give me 5 apples. give me five apples.) as both would be correct in a trigger.

Character limit for an item name is 60 characters.

Do not use an s' in an item name, like "Levrus' Left Shoe," use "Left Shoe of Levrus" or a similar substitute instead.

== Set variable Require variable ==
You can set a variable to be later used by the quest or other quests. Variables are set on the character and visible from all quests.
Smith: Here is your winch access
Setvariable Quest_Winch_Access 1

You can then require a variable to be set as prerequisite of a quest step.
Require variable Quest_Winch_Access.
P: access.
Menu: I have access
Bobaus: Ok, good.

== Require Compendium ==
You can require the player to have a certain knowledge in the Compendium.
Require compendium creature StoneHammer
P: comps
Menu: I know everything about the StoneHammers!
Fighter3: WOW
...
Require no compendium creature StoneHammer
P: nocomps
Menu: Sorry I dont know anything about StoneHammers!
Fighter3: Ah, study more!

The syntax is: compendium <creature/plant/mineral> <name>

== Rewards at the end of the quest ==
When completing a quest, the player usually gets experience and money, or some items. In particular for experience and money you should use the following scripts. This allows us to split the rewards on a scale from 1 to 10 and then to tweak the actual values in the engine. The values in brackets indicate the complexity of the quest. The more complex the more rewards the player will get.

Run script give_quest_money <<3>>.
Run script give_quest_exp <<2>>.
You can also award faction points by using "give_quest_faction" , the number given is multiplied by 5 so if you want +5 point, you need 1 on the second parameter:
Run script give_quest_faction <<'Essential Trail', 20>>.
We have script also to push the faction point up to a given value, if you are already higher, this script will do nothing.
Run script give_quest_faction_level <<'Essential Trail', 2>>.
value = 1-> max faction points = 10;

value = 2-> max faction points = 20;

value = 3-> max faction points = 35;

value = 4-> max faction points = 55;

value = 5-> max faction points = 75;

value = 6-> max faction points = 100;

value = 7-> max faction points = 125;

value = 8-> max faction points = 150;

value = 9-> max faction points = 200;

If you want to assign a faction title you can use this script. In the example it will assign the second title.
Run script give_quest_faction_title <<'Essential Trail', 2>>.

=== The header ===
The header should contain a lot of information. All the information is commented out by a "#". The example below is from one of the mount quests.

First section is information about the quest itself. Name of the quest, a short description and category. Categories will be discussed in detail later on.

The next sections are for unique items used in the quest, name of the item followed by the description.

The third section is for recording versions of the script and all naming authors. Also who last edited the quest should be noted.

The last section is for additional metadata which will be added to the quest in the database (not part of the db) and will be used by the engine to determine lockouts and prerequisites. Here it locks all players from doing the quest again and locks all other players to take the quest with 60 seconds.

Lastly we tell the engine that the player have to complete the Ring of Familiar quest before this one. Note that these comments aren't taken by the engine; it's the duty of who loads the quest to fill the correct entries with the data found in the header: so it's just a way to keep all data together on the script.

'''Example: Header'''
# Quest name: Drifting for a Drifter
# Quest Description: Taemian wants to sell you a mount
# Quest Category: General
# ----------------------
# Quest Items: Item name/Item description
# Taemian's Pouch: - Pouch with all sorts of coins
# Green Gem of the Drifter - A magical gem with a green glow
# Unsigned Drifter Permit - A permit that still needs to be signed by Datal
# Signed Drifter Permit - A permit that has been signed by Datal
# ----------------------
# Variables used in this quest
# ----------------------
# Quest specific variables used in this quest
# ----------------------
# Author(s): Ravna, Katu, weltall
# Current Version: 1.01
# Player lockout: -1
# Quest lockout: 60
# Prerequisites: <nowiki><pre><completed quest="Ring of Familiar"/></pre></nowiki>
# Variables used: Quest_Variable_Name used to do.....
# ----------------------
# Version history and change log
# Last edited by: weltall
# Version 1.00: Initial draft - 05/01/2010 - Katu.
# Version 1.01: Added extra steps - 1/22/2011 - Venalan.
# ----------------------

==== Quest Lockouts ====
Each quest has two different lockout types:

* Player lockout: When this parameter is set, the engine will wait the specified amount of seconds before allowing the same player to redo the same quest. If you want a quest to be available to each player only one time, then set the lockout to -1. Setting it to 600 will have the engine wait 10 minutes before unlocking the quest again.
* Quest lockout: When this parameter is set, the engine will wait the specified amount of seconds before reactivating the quest for ALL players. This means no one can start the same quest during this period, but the ones that had it already active can complete it.

Usually we want quests to be unique to players, so most have a player lockout -1, except the very simple ones. Try always to think if itâ€™s meaningful for that player to redo it. (For example, Harnquist can require iron ore more than once, but won't need to teach you how to make a sword more than once.)

=== Prerequisites ===
Another more complex version of the prerequisites is the: REQUIRE MIN <number>: this tells the engine that there are specific requirements to be fulfilled before the player is able to get the quest. This script indicated it requires a minimum number of quests to be completed in a given list.

Example: require min 2 of Quest1, Quest2, Quest3.

To match this prerequisite the player can complete Quest1 and Quest3 or 2 and 3, or all 3. The request is minimum 2 in the given list.

CATEGORY MIN <number>: quests have an attribute called "category", we use it to identify the difficulty of quests, but can be used of any other purpose, for example one can say that a group of quests is "Evil" or "Laanx related" or " Newbie". Just one category is allowed per quest. This prerequisite allows you to specify the category and the minimum number of quests completed in that category.

A sample of the coding used to set prerequisites for a quest (All on one line):

'''Example: Prerequisites'''
<nowiki><pre><and></nowiki>
<completed quest="Test Quest One"/>
<completed quest="Test Quest Two"/>
<completed quest="Test Quest Three"/>
<completed quest="Test Quest Four"/>
<not><completed quest="Delivery for Aono Riskas"/></not>
<not><completed quest="Gorbiak Disease"/></not>
</and><nowiki></pre></nowiki>

This sample requires that the player have completed Test Quests 1 through 4 and have NOT completed Fancy Dancing and High-Class Aspirations. To get these arranged correctly can take some practice if one is not familiar with working with booleans, so it is best to include a plain-English comments of what you wish your pre-requisites to be in addition to the one with the "pre" coding statements.

Checks if the player has a certain item equipped . To be documented better

else if (!strncasecmp(block,"equipped",8))

=== Untested Prerequisites ===
Please contact engine in case you want to use any of these prerequisites, because those are untested.

"time of day" // require time of day starthh-endhh (working)

"trait" //require trait name in place

"guild" //NOTE: the both argument is implicitly defined

"active magic" (working)

"known spell"

"race" (working)

"gender" (working)

"married"

"possessed" (working)

"skill" //Require skill <buffed> name <skillmin>-<skillmax>. (working)

"variable" //Require variable name. (working)

= Notes on Creating Quest Files (Rules and Header Information) =

* The quest documents you submit should always be in notepad format: this is to avoid special characters added by Word or other text editors, most notably "smart quotes" which will appear as squares in game. Notepad++ is recommended, HIGHLY recommended.
* Use only ANSI encoding.
* The file name when saving the quest should begin with 'Quest' , then have the name of the quest. For example: Quest Hinoserri Cannot See.txt
* Titles of quests should follow some scheme of capitalization. There are many sets of rules, but a quick and easy format is to capitalize the first word and then all other words, except a, an, the, at, by, for, in, of, on, to, up, and, as, but, it, or, and nor.
* Each quest script begins with the title and a one or two sentence description; this is what the player reads so keep that in mind. The proper way to do this is to "comment out" your description and quest title, this is done by beginning a line with the number sign or pound symbol (#). Also, any quest item created for your quest should have a description written into the quest. Notes on quest items should also be commented out. Lastly, there should also be a "Quest Category" line that must be commented out as well. Approved quest categories are: Alchemy, Black Flame, Chain (don't use this one unless told), Cooking, Death Realm, Easy, Gugrontid, Magic Ways, Medium, Metal Working, Newbie, Repeatable. This is a work in progress, so if you have any questions ask an associate dev or developer. No quest can have more than one category - pick one and ONLY one. New quest categories must be approved by the associate devs/devs before use.

ProgressionEvents

2025-07-17T16:17:45Z

Talad:

==Progression Events Objects and Variables==
Be sure to read also [[ProgressionEvents Objects and Variables|this page]] as it describes which objects are scriptable inside a progression event and which variables you can access.

== ActionOp ==
ActionOp activate any inactive entrance and create a key for it.

Activates any inactive entrance action location of the specified entrance type and places into players inventory a key for the lock instance ID defined in that action location entrance.

- Syntax:

<action sector="%s" stat="%s"/>

sector = "%s" sector string to qualify search for inactive entrances

stat = "%s" name of item type for new key to the lock of the entrance

- Examples:

<action sector="guildlaw" stat="Small Key"/>

This quest script activates any inactive action location for sector guildlaw and gives a "Small Key" item.

== AnimalAffinityOp ==
<animal-affinity aim="Actor" name="reptile" value="2"/>

This is primarily used for character creation, as these effects are permanent. There is no way to buff this currently.

==AnimationOp==
This is a run once animation command. The animation name is not validated, only client knows if it has the animation.

Syntax:
<animation aim="Target" name="animationX" />

'''Target''' = the operation's target
'''value''' = the animation name, these can be: attack, craft, craft_hammer, ...

== CancelOp ==
A way to cancel active spells.

<cancel type="all">

<spell type="buff" name="Defensive Wind"/>

<spell type="buff" name="Flame Spire"/>

</cancel>

There are three types:

- "all" ... cancels all listed spells.

- "ordered" ... cancels the first listed spell that's actually active.

- "random" ... cancels a random spell from the list (one which is active).

== CodexEntryOp ==
Adds one map to the Compendium for this player.

<codex aim="Actor" type="map/npc" id="1" />

==CreateFamiliarOp==
Create familiar for actor.

Syntax: <create-familiar aim="Actor" masterId="masterId" />

Examples:

Create a familiar near actor and send message:

<create-familiar aim="Actor" masterId="1001"/><msg text="Your new familiar appears nearby."/>

==CreateNPCOp==
Create an NPC at given location, temporary or permanent. Used for Summon Pet Pedestal with beast master.

Syntax: <create-npc aim="Actor" raceID="raceId" lifeInSeconds="30"/>

lifeInSeconds is how long the NPC will stay alive, if 0 it's permanent.

==DestroyOp==
The object that is going to be destroyed must be defined in the supplied MathEnvironment.

Example: <destroy aim="SomeObjectName"/>

SomeObjectName needs to be replaced by the object name that is used to register the object in the MathEnvironment. So the name identifies the object to be destroyed.

==ExperienceOp==
Adjust the experience of the target.

Syntax:
<exp type="allocate_last" value="#"/>

'''allocate_type''' = "allocate_last" means allocate damage last otherwise damage is allocated

'''value''' = "#" amount of experience to give single player or share with others

==FactionOp==
Example: <faction aim="Actor" name="Klyros" value="5"/>

This adds 5 to actor's Klyros faction.

==FactionTitleOp==
Example: <factiontitle aim="Actor" name="Applied Knowledge" value="5"/>

This adds the title number 5 for the faction Applied Knowledge to the actor.

==ForceOp==
Example: <force name="SomeName" source="SomeSource" target=""/\>

applies a force in an area, centered on the given actor.

This is NOT WORKING properly atm. It was a test for AoE effects.

==FxOp==
The effect is either created at the target (attached) or in front of it (unattached).

If the effect is not attached:
<fx type="unattached" name="SomeName" source="SomeSource" target=""/>

or if the effect is attached:

<fx name="SomeName" source="SomeSource" target=""/>

scale="value" is optional and gives the scaling factor for the effect.

Example: <fx source="Caster" target="Target" name="summon_missile" type="unattached"/>

== HPOp ==
direct HP damage. Unlike other vitals, <hp> can specify an optional attacker who will be recorded in the target's damage history.

Examples:

<hp attacker="Caster" aim="Target" value="-5*Power"/>

<hp aim="Target" value="15"/>

==HPRateAOp==
Change the HP statistics of a character in Applied mode.

Syntax:
<hp-rate value="..."/>

'''value''' = "..." a mathscript defined value.

Examples:
Increase the Actor HP rate by 10 points:
<hp-rate value="10"/>

==IfOp==
This operation allow to asses a condition and execute other operations if the result return true or false. It's a classic if/then/else operation.

Syntax:
<if t="...">
<then>...</then>
<else>...</else>
</if>
'''t''' = "..." a mathscript condition to verify.

Examples:
Check if 'Water Barrier' spell is active on the target and send a message based on that:
<if t="Target:ActiveSpellCount('Water Barrier') < 1">
<then>
<msg aim="Target" text="${Target} is not under Water Barrier spell."/>
</then>
<else>
<msg aim="Target" text="${Target} is under Water Barrier spell."/>
</else>
</if>

==ItemOp==
Creates an item in the player inventory

Syntax:

<item aim="Actor" name="Tria" location="inventory" count="23" />
<item aim="Actor" name="Ruby Crystal" location="inventory" count="5" />

==KeyOp==
There are two functions of this script. The make function will create a new master key for the specified lock. The modify function will change existing key to work with lock.

== LetOp ==
This operation allow to setup one or more variable which can be used inside the let operation block.

Syntax:
<let vars="..."/> or <let vars="...">...</let>
'''vars''' = "..." define a mathscript environment.

Examples:
Setup Roll (random 0-100), Will and Power variables:
<let vars="Roll=rnd(100);Will=Target:GetSkillValue(51); Power=0.8^(0.1*Will)*Roll;">
...
</let>

==LootSetOp==
Based on the a loot rule ID, generates all the items needed and add those into the player inventory or drops to the ground

Syntax:

<loot aim="Actor" lootid="<lootid1,lootid2,lootid3>" location="inventory|ground" />

lootid corresponds to an entry into [[Loot rulesTable|loot_rules]] table. Can be a single ID, or a series of IDs comma-separated. If there are multiple IDs, the loot will randomize and pick one.

==MechanismMsgOp==
activate a mechanism:

Example: <mechanism aim="Target" mesh="Mesh" move="Move" rot="Rot" />

== MinigameOp ==
MinigameOp - starts a new minigame

Example: <minigame aim="Target" name="Dice" itemloc="righthand"/>

itemloc points to the NPC slot where we search for a minigame item to start the game.

== MsgOp ==
Used to send a system message to the user client. Variables ($variable_name) con be used inside the text.

Syntax:
<msg aim="..." text="..." type="ok|error" />

'''aim''' = "..." the operation's target, depending on the environment can be ''Actor'' or ''Target'', inside a spell script ''Caster'' is a valid target.

'''text''' = "..." the text to display.

'''type''' = "ok|error" the type field is optional and tell the server if the message is an ordinary message or if an error or confirmation message to display on screen. Without this option the message is diplayed in the system message chat tab.

Examples:
Raise the Actor's strength by 10 points and send a message to the user:
<str aim="Actor" value="10"/>
<msg aim="Actor" text="$Actor's strength has been increased by 10 points."/>

==NPCCmdOp==
NPCCmdOp - one-time npc command sending:

Example: <npccmd aim="Caster" cmd="spam spam spam spam...!"/>

== SkillOp ==
Used to affect a character skill (Alchemy, Melee, Herbal, ...).
This is used to change a character's skill live in game.
[[ProgressionEvents#SkillAOp|SkillAOp]] are buffable (see ApplicativeScript).

Used to affect in Applied Mode.

Syntax:
<skill aim="..." value="..."/>

'''aim''' = "..." the operation's target, depending on the environment can be ''Actor'' or ''Target'', inside a spell script ''Caster'' is a valid target.

'''value''' = "..." a mathscript defined value.

Example:
<skill aim="Actor" name="Red Way" value="-10"/>
<skill aim="Actor" name="Brown Way" value="10"/>

==SkillAOp ==
Used to affect a character skill (Alchemy, Melee, Herbal, ...) in Applied Mode.

This command works like a [[ProgressionEvents#SkillOp|Skill Operation]]. No aim or Target needs to be declared.

Example:
<skill name="Red Way" value="-10"/>
<skill name="Brown Way" value="10"/>

==SleepOp==
make the player sleep

Example: <sleep aim="Target" quality="1" />

== StatsOp==
Used to affect a character stat (agility, intelligence, ...).
This is used to change a character's stats live in game.
[[ProgressionEvents#StatsAOp|StatsAOp]] are buffable (see ApplicativeScript).

Syntax:
<agi aim="..." value="..."/> or
<end aim="..." value="..."/> or
<str aim="..." value="..."/> or
<cha aim="..." value="..."/> or
<int aim="..." value="..."/> or
<wil aim="..." value="..."/> or
'''aim''' = "..." the operation's target, depending on the environment can be ''Actor'' or ''Target'', inside a spell script ''Caster'' is a valid target.

'''value''' = "..." a mathscript defined value.

Examples:
Reduce Actor's physical stats by 10% and raise mental stats by 10 points:
<str aim="Actor" value="-0.1*Actor:GetSkillValue(50)"/>
<agi aim="Actor" value="-0.1*Actor:GetSkillValue(46)"/>
<end aim="Actor" value="-0.1*Actor:GetSkillValue(48)"/>
<cha aim="Actor" value="10"/>
<int aim="Actor" value="10"/>
<wil aim="Actor" value="10"/>

==StatsAOp==
Used to affect a character stat (agility, intelligence, ...) in Applied Mode.

This command works like a [[ProgressionEvents#StatsOp|Stats Operation]]. No aim or Target needs to be declared.

Example:
<str value="-0.1*Actor:GetSkillValue(50)"/>
<agi value="-0.1*Actor:GetSkillValue(46)"/>
<end value="-0.1*Actor:GetSkillValue(48)"/>
<cha value="10"/>
<int value="10"/>
<wil value="10"/>

==TeleportOp==
Example:
<teleport aim="Target" sector="bdroad2" x="-178.17" y="48.19" z="551.82" instance="0" />

== TeleportDungeonOp ==
Is a teleport operation for a named procedural dungeon. It finds dungeon position by name asking DungeonSpawnManager

Example:
<teleportdungeon aim="Actor" name="dungeon1" background="" delay="1" x1="0" y1="0" x2="0" y2="0" widget="warp" />

== TraitOp ==
Used to create a change in character traits.
This is used to change a character's appearance live in game.
It takes the trait ID number and sends a broadcast out to all the players in range about the change.

Syntax:
<trait value="#"/>
value = "#" index id key into traits table
Examples:
You apply trait 100 (grey hair) to actor and send message:
<trait value="100" /><msg aim="actor" text="You drop the liquid on your hair."/>

==TutorialMsgOp==
TutorialMsgOp activates a tutorial window on the client with the specified message. The message is taken from tips table in the database.

Example: <tutorialmsg aim="Target" num="TutorialTipID"/>

==VariableSetOp ==
This is permanent. Note that if the variable is set already it will be overwritten.

Example: \<variable aim="Actor" name="LOVEDBYKLYROS" value="true"/>

This sets the variable LOVEDBYKLYROS and sets it's value to "true".

==VariableUnSetOp==
Example: <variable aim="Actor" name="LOVEDBYKLYROS" />

unset the variable LOVEDBYKLYROS
==VitalOp==
imperative mana & stamina, but not HP

Example: <mana aim="Caster" value="-5"/>

==VitalAOp==
Change the vital statistics (HP, Mana, ... but not Hit Points) of a character in Applied mode.

Syntax:
<mana-rate value="..."/> or
<pstamina-rate value="..."/> or
<mstamina-rate value="..."/> or
<hp-max value="..."/> or
<mana-max value="..."/> or
<pstamina-max value="..."/> or
<mstamina-max value="..."/> or

'''value''' = "..." a mathscript defined value.

Examples:
Increase the Actor vitals by 10 points:
<mana-rate value="10"/>
<pstamina-rate value="10"/>
<mstamina-rate value="10"/>
<hp-max value="10"/>
<mana-max value="10"/>
<pstamina-max value="10"/>
<mstamina-max value="10"/>

[[Category:Engine documents]]

Config Races

2025-06-27T20:12:19Z

Talad: /* Add new race */

== Add new race ==

Adding a new entry in [[Race infoTable]]

Adding a new entry in [[Race spawnsTable|Race spawnTable]]

Add special loot in [[Loot rulesTable|Loot rules Table]] and [[Loot rule detailsTable|Loot rules details Table]]

== Configure a race ==

Change the base mesh:
* [[Race infoTable|race_info]].cstr_mesh (example "ylianm") has to match with the Content/Blueprints or Content/Blueprints/Npcs where we search an actor BP with name <mesh>Character, (example "ylianmCharacter")

Change the texture variation:
* The [[Race infoTable|race_info]].cstr_base_texture (example "Trepor3") needs an entry in DataTable'/Game/data/dt_textures.dt_textures' pointing to the actual MaterialInstance in Unreal

Change starting stats:
* The [[Race infoTable|race_info]].start_* fields contain the values used

Change the regeneration for mental and physical stamina:
* The [[Race infoTable|race_info]].base_* fields contain the values used

Change Default Armor and Weapons:
* NOTE: Should be used only for monsters, used if no other armor or weapon is worn/wielded
* [[Race infoTable|race_info]].armor_id and weapon_id are pointing to a valid [[ItemStatsTable|item_stats]].id item

Change Scale of the character:
* [[Race infoTable|race_info]].scale field contain the value used

Change the Speed of the character:
* The [[Race infoTable|race_info]].speed_* fields contain the values used for the different stances

Change the type of skin to react in combat:
* The [[Race infoTable|race_info]].skin_type. Used to determine sound when hitting this creature

Change the max height of step allowed:
* UEEditor->CharacterBP->CharacterMovement->Walking->Max Step Height

Change the character bounding box:
* UEEditor->CharacterBP-> Change the size of the Capsule component. used for all collisions

PSUnreal Foliage

2025-06-26T21:38:10Z

Talad:

=== Lights settings ===
Set all foliage to Moveable

=== Culling settings ===
Depending on the size of the foliage we have standard culling distances

Flowers and small plants: 50 meters

Bushes: 100 meters

Trees: 500 meters (for now, let's see how much they pop)

=== Procedural Foliage Volume ===
To work it needs the Collision setting to be set as "OverlapAllDynamic".

But then it needs to be set as "NoCollision" or in game we will have issues on dropping items.

WARNING: When you generate foliage a new instanced foliage object is created, and it's created at 0 0 0 by default. This increases the Level Boundaries by much and causes the level to be loaded by streaming levels based on the wrong boundaries. The way to fix it is to:

* Open the single sublevel, not the whole persistent level
* Go in foliage mode
* select all foliage with the lasso tool
* go in Select mode
* select the InstanceFoliage object and move it within the boundaries of the level
* Go in foliage mode
* All foliage is still selected, and you just move it by a bit (any amount), then press CTRL-Z. Incredibly enough the CTR-Z set the position of the foliage where is should have been!
* Reopen the persistent level and load in the sublevel you modified, you will see the request to save as it's modified, save it.

PlaneShift2D

2025-06-11T11:23:06Z

Talad: /* 1998 - Stopped */

==1992 - The inception==

Back in 1992, [[Luca Pancallo]] was playing to a lot of text MUDs (Multi User Dungeon) games trying to conciliate the love for computer games RPGs (like the stunning Eye of the Beholder) and the new power of the internet. MUDs were a good start and usually nice to play, but he felt those were all lacking a lot for background, roleplay and generally consistency that could bring the realism of the virtual world to new heights. (I remember a fantasy text MUD with microwave ovens attacking you :) ). In addition he really wanted to add some graphics to this kind of game to have a more immersive experience. From this need PlaneShift 2D was born.

The basic idea was to get the server technology used by MUDs (mainly LPC language) and add on top of it a graphical interface, plus adding a great background with well thought races and places.

Luca started to download all kinds of MUD engines and to modify them to his needs, studying them to see which one could be the best to use for PlaneShift.

==1994 - The first team==

[[Image:PS2D-1.jpg|right|thumb|400px|Client main page]]
Apart from programmers at least 2 people were needed, 1 talented artist and 1 storyteller.

For the 3D artist there was no doubts, an old friend of high-school (Stefano Oggeri) was the perfect guy, rpg-lover and 3d gfx addicted. At that time he was working mainly with POVRay and the first versions of 3dstudio. But the final results were already quite stunning. He joined immediately the project.

For setting, Luca found Mauro Zanetti, an active rpg gamer and organizer of many fantasy related events in our country (Italy). They met inside an pen and paper rpg club, and Luca proposed him to join. He was eager to help and in few weeks he joined the project.

Searching amongst friends of friends, Luca found Danilo Moretti, a talented 2D artist that joined the project as concept artists, creating all races and many nice views of Yliakum.

The first team was born and really made of talented people. Stefano started to create amazing pictures of the world and Mauro wrote the basics of the underground world, detailing the races and the places you can still find today in PlaneShift 3D.

The programming side was handled by Luca, adding new functions on top of an already existing LPC engine, and building a C++ graphical interface to support the user interaction with the world.

The main idea was to have a 3d rendered (still) image for each of the locations and a minimap guiding you in the world. Plus a list of NPCs and other players that were in the same location.

Below [now on the right,] there is a pic of the client's main page. On the top left there were the button to access the other screens, on the left the minimap, created automatically. At the center the screen that will visualize the various places visited, on the right, a list of characters present in the same location. On the bottom all text written by player and received by server.

{{ClearBreak}}

==1996 - The first official public exposure==

[[Image:PS2D-3.jpg|right|thumb|400px|The working client main page]]
When the client was "nearly" working, we started to see if someone was interested in it. The first contact was with Galactica, a big internet and content provider. They were amazed by our idea, and we managed to participate with them to the most important computer expo in Italy (SMAU '96).

We were very excited about the expo, and we worked around the clock the week before the event, to have a working client with good and playable content.

On the expo we had a main server machine and few clients were visitors could connect and play. For the expo the interfaces ready were the main screen and the inventory screen (see on the right)

You can see how the art of the characters is basically the same as today!
[[File:Ps2d 3.jpg|thumb|401x401px|Inventory]]

{{ClearBreak}}

==1997 - Another expo!==

[[Image:PS2D-4.jpg|right|thumb|400px|The skills screen]]
Given the great public response for the client, we decided to go commercial, searching a contract. We found a company interested in the deal, one of the biggest communication companies in Italy. They decided to invest in our project, and we asked them to be present at the same computer expo in 1997.

Meanwhile we managed to add new screens and features to the game, like the skills one:

If you search on the web you can probably still find the old web page somewhere. Anyway we provide one here for your nostalgic enjoyment. The web site was completely in italian (try to read it with some web translator). The page is around 1998, one of the last seen online for the PlaneShift 2D project.
[[File:Old Mud Page banner.png|none|thumb|400x400px]]
{{ClearBreak}}

==1998 - Stopped==

Around 1998 we were trying to finalize the commercial contract for the game, but a major problem hit the company we were speaking to. Basically all the top and middle level management of the entertainment section was changed and the new ones were so busy in reshaping the company that really didn't care about PlaneShift. We tried to wait a few months to see if something would change, but nothing happened. The hit was big, also because many of us were in the right age to plan their future, and so each took a different direction, no more related to PlaneShift. The project was stopped completely, no one single line of code written after that date.

The pain on each of us was big, everyone saw that was the way to go, the game of the future, the place to invest money and efforts. But none of us was rich or crazy enough to start a company for it.

==2000 - Something new, something old==

PlaneShift never left the heart of Luca, that after some distractions, decided to restart the PlaneShift project, with a stronger organization, an internet wide team, and no more commercial tricks. Graphical 2D MUDs were spreading, but still not very exciting, PS 2D was still a lot better in comparison. 3D games were the major new wave of entertainment on the internet, and this was immediately taken as the new direction of the project.

All the ideas and background created for the old project could be reused and the will to create a realistic virtual world were people could have fun and create their "other" living was even stronger than before. The new gfx hardware could provide a great new level of impersonation and the vision for the new game was ready.

PlaneShift 3D was born!

The rest is part of present history, and you can read it in the ps news web pages.

Why we wrote this? Well, basically to let you know a bit more of our roots, that surely still affects today our beliefs and our development spirit.

Hope you enjoyed it! Let's make PlaneShift the game it deserves to be!

[[Category:PS History]]

File:Old Mud Page banner.png

2025-06-11T11:22:01Z

Talad:

The old page of PlaneShift 2D Mud

File:Ps2d 3.jpg

2025-06-11T11:17:13Z

Talad:

ps 2d inventory

PlaneShift

2025-06-11T11:12:20Z

Talad: /* Azure Spirit (0.6) */

PlaneShift is a Massively Multiplayer Online Role Playing Game immersed in a 3D virtual fantasy world which is FULLY FREE to play. There are no limitations in skills, ranks, abilities, items you can gain with your free account; no time limits; no locked premium content or additional constraints. Servers and bandwidth are donated by sponsors. The developers, Atomic Blue, are a group of RPG enthusiasts whose efforts and contributions are voluntary, not paid. 

At the present state of development, PlaneShift is not a complete game, but it has all the systems needed for enjoyable play, including combat, magic, crafting, quests and detailed settings. A downloadable client program allows you to to immerse your character in vibrant 3D surroundings. Today you can explore the virtual world, interact with other players or with server controlled creatures, fight monsters, cast spells, solve quests and puzzles, improve your character, gain magical items, craft new items and more. The game is still under heavy development, so you may easily find bugs, glitches and missing features. Our model is to keep the game open for the public, so you can give feedback on the features you want us to develop and help shape the future of the game. We are working to create an interactive world with politics and an economy, and improve the artificial intelligence of server-controlled non-player-characters that bring our world to life! 

Our virtual domain is persistent, and this means you can connect to it at any hour of the day and you will always find players and NPCs wandering our realms. Your character and progress is stored on the server, so you never have to worry about saving the game. A player can start from humble beginnings and advance to greatness in whatever path they may choose.

Remember that PlaneShift is a Role Playing Game - be sure to read our Roleplay guidelines! We think the RPG part of the MMORPG definition has a meaning! 

PlaneShift is Open Source for the client and server code, so anyone can contribute to its development! If you want to help, see how to join our team [http://www.planeshift.it/Join%20Us here], or consider making a [http://www.planeshift.it/Donate donation]. 

==Idea and previous history==
The history of PlaneShift before it became 3D is described in [[PlaneShift2D]].

==Versions==

===[[Atomic Blue]] (0.1)===
The very first PlaneShift version.

2 May 2002

===[[Molecular Blue]] (0.2)===
The second version of PlaneShift.

7 March 2003

===[[Crystal Blue]] (0.3)===
Tria is now the new currency. Ojaveda is born and the first Dsar, Akkaio, is added as home of all Enkidukai. Over the course of development the first craftings are introduced.

24 December 2004

===[[Steel Blue]] (0.4)===
Gugrontid the home town of Kran was added.

3 March 2008

===[[Arcane Chrysalis]] (0.5)===
late 2009

===[[Azure Spirit]] (0.6)===
Last PSLegacy version. Male [[Nolthrir]] model and 11 new [[Ingame_Help#Magic.2C_Glyphs_and_Spells|spells]] were added; a new map, a new creature and many platinum-steel weapons ([[crafting]]) are now available; many [[NPC]] behaviours were updated (so newly created characters will not be attacked by relatively weak, but aggressive, NPCs able to kill them).

November 2013

=== PSunreal (0.7) ===
Current version of the game redone with Unreal Engine.

Internal only: May 10th 2020

Distributed to limited users: November 25th 2020

==Game features==
The following list represents some of the features of the final product. Please remember that today PlaneShift is still under heavy development. 

* 10 playable races with unique traits!
* Unlimited professions through a skill system
* Original magic system with six Ways of magic
* Hundreds of spells
* Numerous huge worlds to explore
* A great number of quests to test your wit and skill
* Monsters and NPCs with good AI that produce game events
* A world that evolves with or without player interaction
* Own your guild house
* Politics and economy
* ... and much much more!

[[Category:PS History|!]]

PlaneShift

2025-06-10T19:05:24Z

Talad: /* Arcane Chrysalis (0.5) */

PlaneShift is a Massively Multiplayer Online Role Playing Game immersed in a 3D virtual fantasy world which is FULLY FREE to play. There are no limitations in skills, ranks, abilities, items you can gain with your free account; no time limits; no locked premium content or additional constraints. Servers and bandwidth are donated by sponsors. The developers, Atomic Blue, are a group of RPG enthusiasts whose efforts and contributions are voluntary, not paid. 

At the present state of development, PlaneShift is not a complete game, but it has all the systems needed for enjoyable play, including combat, magic, crafting, quests and detailed settings. A downloadable client program allows you to to immerse your character in vibrant 3D surroundings. Today you can explore the virtual world, interact with other players or with server controlled creatures, fight monsters, cast spells, solve quests and puzzles, improve your character, gain magical items, craft new items and more. The game is still under heavy development, so you may easily find bugs, glitches and missing features. Our model is to keep the game open for the public, so you can give feedback on the features you want us to develop and help shape the future of the game. We are working to create an interactive world with politics and an economy, and improve the artificial intelligence of server-controlled non-player-characters that bring our world to life! 

Our virtual domain is persistent, and this means you can connect to it at any hour of the day and you will always find players and NPCs wandering our realms. Your character and progress is stored on the server, so you never have to worry about saving the game. A player can start from humble beginnings and advance to greatness in whatever path they may choose.

Remember that PlaneShift is a Role Playing Game - be sure to read our Roleplay guidelines! We think the RPG part of the MMORPG definition has a meaning! 

PlaneShift is Open Source for the client and server code, so anyone can contribute to its development! If you want to help, see how to join our team [http://www.planeshift.it/Join%20Us here], or consider making a [http://www.planeshift.it/Donate donation]. 

==Idea and previous history==
The history of PlaneShift before it became 3D is described in [[PlaneShift2D]].

==Versions==

===[[Atomic Blue]] (0.1)===
The very first PlaneShift version.

2 May 2002

===[[Molecular Blue]] (0.2)===
The second version of PlaneShift.

7 March 2003

===[[Crystal Blue]] (0.3)===
Tria is now the new currency. Ojaveda is born and the first Dsar, Akkaio, is added as home of all Enkidukai. Over the course of development the first craftings are introduced.

24 December 2004

===[[Steel Blue]] (0.4)===
Gugrontid the home town of Kran was added.

3 March 2008

===[[Arcane Chrysalis]] (0.5)===
late 2009

===[[Azure Spirit]] (0.6)===
Last PSLegacy version. Male [[Nolthrir]] model and 11 new [[Ingame_Help#Magic.2C_Glyphs_and_Spells|spells]] were added; a new map, a new creature and many platinum-steel weapons ([[crafting]]) are now available; many [[NPC]] behaviours were updated (so newly created characters will not be attacked by relatively weak, but aggressive, NPCs able to kill them).

=== PSunreal (0.7) ===
Current version of the game redone with Unreal Engine.

==Game features==
The following list represents some of the features of the final product. Please remember that today PlaneShift is still under heavy development. 

* 10 playable races with unique traits!
* Unlimited professions through a skill system
* Original magic system with six Ways of magic
* Hundreds of spells
* Numerous huge worlds to explore
* A great number of quests to test your wit and skill
* Monsters and NPCs with good AI that produce game events
* A world that evolves with or without player interaction
* Own your guild house
* Politics and economy
* ... and much much more!

[[Category:PS History|!]]

Arcane Chrysalis

2025-06-10T19:04:04Z

Talad:

[[File:Chrysalis splashfinal 1024.jpg|none|thumb]]
The fifth version of [[PlaneShift]], '''Arcane Chrysalis''', was released in late 2009. 
=Changelog=
==New Features==
*Support for single-player minigames.
*Minigames now report feedback to the watchers when moves are made.
*Minigames can now have various boards (White, Black: Plain, Checked)
*You can now change the colour of Text, Lines and Curves in Sketches.
*You now enter a special NPC Camera Mode when talking to NPCs.
*New /drop command. You can drop items, money and specify "all" to drop all items of the same kind.
*You can specify "noguard" to /drop commands to drop items unguarded.
*You can use /guard on/off on items to guard/unguard them.
*You may now need a certain skill (and rank) for picking up items.
*You can now optionally be notified on guildmember login/out. 
==Art==
*New additions to the Winch map.
*A new leather armour for Nolthrir females.
*A new relighted version of the Akkaio map, because of some problems players had with the road to Ojaveda.
*New icons for the Sketch Window.
*A better rotating wheel in the sewers.
*Fixed many spell effects to work on all supported operating systems. 
==Settings==
*Huge number of Settings related bugs closed. 
==Changes That Have Been Made==
====Engine====
*PlaneShift now uses the latest version of the 1.4 branch of the [[CrystalSpace|Crystal Space]] 3D Engine.
*Renamed the updater function CheckIntegrity to --repair.
*Improved server threading.
*Various other work.
====Commands====
*/show_gm -> /show gm
*/show_active_magic -> /show activemagic
*/petition_manage > /managepetitions
*/advisor_list -> /advisor list
*/advisormode -> /advisor on/off
*/list_advice_requests -> /advisor requests
*/advisormode listsessions -> /advisor sessions
*/advisor -> /help
*/petition_list -> /show petition
*/target_context -> /targetcontext
*/who will now filter for more than one word ("/who game master")
====Chat====
*All chat types, except chat going to the Main and System tabs, have brackets like [Guild] or [Tell] in the chat logs.
*Option to display those brackets in-game as well.
*Options to mix text colours, so for example the colour of whatever chat action you're using is mixed with your own default "my chat" colour.
*The colour of your own sent chat is configurable.
*Configurable NPC chat colour.
*"X tells group: y" -> "X says: y"
*"Guildchat from x: y" -> "X says: y"
*"Auction from X: y" -> "X auctions: y"
*The usage of /me, /my and the usage of those actions within other actions (like /shout or /auction) is now consistent through chatbubbles, chatwindow and logs.
====GMs and Devs====
GMs vs. Items:
*GMs can now use /modify to change the transient(disappears after some time when dropped) flag of an item.
*You can now make items unpickable using /modify.
*Added /target_name for GM1 and higher to report the names of all targeted items.
*Using the :area: syntax on a command pops up a window asking if you want to continue.
*<nowiki>:Area: (apply command to all entities within area) syntax now available for GM2 and up.</nowiki>
*If you want to pickup non-pickable items with :area:, specify pickupall.
*GMs can now use /unstackable to (dis)allow stacking of items.
*GMs can now teleport items though instances.
*GM2 and up can become guardians of all items, whether guarded or not.
GMs vs. Players:
*/setskill now shows to the GM and the player what skills where changed and from what value to what value.
*With /setskill you can use the addition "-1" to get the base skills of a player.
*GMs can now use /quest on offline players.
*GMs can now unassign themselves from petitions.
*GMs can now enable or disable quests with /disablequest.
*/marriageinfo now also works on offline players.
*You can now teleport players to another instance by adding "there" to the teleport command.
*If you give a stack to a player with /giveitem, it will show the amount given.
*You can now award unlimited experience instead of max 100 PP as before.
GMs vs. NPCs:
*You can now teleport to an NPC by only specifying the first name.
*You can now use /killnpc with PIDs again.
*NPCs can now be teleported while NPCclient is active again.
*Devs can use /updaterespawn again to change the spawning location of NPCs and across instances.
GMs vs. Various Stuff:
*GM3 can now morph themselves, but not others.
*When you morph yourself, your description will also be updated to reflect the race.
*Many admin commands standardized to work with the default command syntaxes which can be found in help.xml
====Various====
*Removing a player from a guild now shows who removed the player.
*You can now access the Bag window by using a key, default "v".
*Dying in the Death Realm will no longer reset mana to 100%.
*Made the modding of various windows easier.
*Locking of chests now more secure.
*You can use the # symbol in shortcuts to make comments.
*You can no longer select a gender as Kran.
*You will no longer be able to hit NPCs like rats "on the helm".
*Now bad words filtering is also applied to advice sessions.
*Instead of /add_ignore and /remove_ignore you now have the plain /ignore command, which toggles ignore status.
*If you add "add" or "remove" to the /ignore command, it will force that operation. Same behaviour for /buddy.
*Specifying no name will open up the ignore window. 
==Bugs That Have Been Fixed==
*Characters' hair will have colour again!
*Now you won't get invalid pets anymore if you created one when NPCclient was offline.
*Opening crates/chests does not crash the server anymore.
*Mana is now properly calculated when under the death penalty.
*Stamina no longer drops when standing still.
*Casting spells while running no longer increases stamina.
*Fixed a bug where weapons would degrade a lot if you repaired them.
*Fixed the annoying "Map not found!" bug.
*NPCs will no longer keep rotating/sliding after they've been killed.
*Fixed a bug where players could end up in instance 0 after a relog even if they were in another before.
*Fixed a bug where your new position in the world wasn't saved after teleporting or being teleported.
*Fixed a bug where you wouldn't be able to trade after you challenged someone who then logged off.
*Fixed players crashing out of the game due to GMs morphing with active effects (like magic).
*Fixed a bug where you couldn't add items to a container even if the guardian was far away.
*Fixed an exploit where you could regenerate stamina while crafting.
*Fixed a bug where an NPC wouldn't respond to certain questions.
*Fixed garbled movement after using /loot.
*Your tells will not appear in the chatbubble of the person you're sending them to anymore.
*Fixed bogus <nowiki>* *</nowiki> being added to /me actions used in /shout or /auction.
*Fixed the frames-per-second cap to actually work. This has some side-effects though, see new bugs Wink
*Many other bugs fixed Smiley 
=Further Arcane Chrysalis Releases=
*[http://www.hydlaaplaza.com/smf/index.php?topic=36923.0 Release 0.5.2] (2010)
*[http://www.hydlaaplaza.com/smf/index.php?topic=37453.0 Release 0.5.4] (2010)
*[http://www.hydlaaplaza.com/smf/index.php?topic=38839.0 Release 0.5.5] (2010)
*[http://www.hydlaaplaza.com/smf/index.php?topic=39183.0 Release 0.5.6] (2011)
*[http://www.hydlaaplaza.com/smf/index.php?topic=39581.0 Release 0.5.7] (2011)
*[http://www.hydlaaplaza.com/smf/index.php?topic=40481.0 Release 0.5.8] (2011)
*[http://www.hydlaaplaza.com/smf/index.php?topic=40781.0 Release 0.5.9] (2012)
*[http://www.hydlaaplaza.com/smf/index.php?topic=40869.0 Release 0.5.9.1] (2012)
*[http://www.hydlaaplaza.com/smf/index.php?topic=41069.0 Release 0.5.9.2] (2012)
*[http://www.hydlaaplaza.com/smf/index.php?topic=41180.0 Release 0.5.9.4] (2013)

[[Category:PS History]]

File:Chrysalis splashfinal 1024.jpg

2025-06-10T19:03:08Z

Talad:

Crystal Blue

2025-06-10T17:54:54Z

Talad:

'''Crystal Blue''' Is the code name for the third major release of [[PlaneShift]].
[[File:Cbsplash.jpg|none|thumb]]

== Screenshots ==
<gallery>
Image:Cb1.jpg|North hydlaa path
Image:Cb2.jpg|Hydlaa Overview
Image:Cb3.jpg|Paths
Image:Cb4.jpg|Magic Shop
Image:shot_combat.jpg|Combat
</gallery>
==0.3.004==
{{Calendar|24|December|2004}}
* new [[CrystalSpace]] (3D graphics) engine
* using skeletal models and animations
* introducing magic
* introducing combat

{{ClearBreak}}

==0.3.005==
{{Calendar|~30|December|2004}}

{{ClearBreak}}

==0.3.006==
{{Calendar|22|January|2005}}

{{ClearBreak}}

==0.3.007==
{{Calendar|10|February|2005}}

* Klyros model added.
* Added a set of items including food and loot items.

{{ClearBreak}}

==0.3.010==
{{Calendar|18|May|2005}}
===Major User-Visible Features===
*New area of East Hydlaa is available (Jayose has been relocated). New NPCs will be added there soon.
*Character traits - current only 1 new elf skin. You can now customize the face of your char (dermorian only). Now that the feature is in place, we will add more faces for other chars as well.
*New crafting system - shields only at the moment
*New complete GUI skinning system
*One additional skin available thanks to Cherppow. (to change it, you can rename planeshift/art/skin/elves.zip into planeshift/art/skin/default.zip)
*New loading screens
*Added duel points and advisor points to skill window info displayed.
*Added some new button art to look better.
*Added duel-point penalty for spamming duel invites.
*Added command to see /duel_points
*You don't get skill practise for attacking other players now.
*Train icon added in the interaction menu with trainers
*Added /changeguildname
*German manual
*Message window will now no longer jump to the end when a message is added.
*/quit now prompts before quitting
*Added link to login page that shows where to register a new account.
*License of the package changed from PlaneShift Team to Atomic Blue.

===Major User-Visible Fixes===
*A number of bug fixed on Hydlaa level.
*Updated/fixed some spell effects
*Fixed that you could freely PK players that were just joining the game
*Fixed that if you opened a window during autorun, you could run forever regardless of stamina.
*Fixed that when you died, you could still turn your remains with mouselook.
*When a character is attacked, its stance resets to "full defense".
*Fixed that tab completition was sometimes changing chat command to /tell from e.g. /say.
*Fixed that when negative HP rates lowered HP to zero, the character was not killed.
*Fixed that vitals were not adjusted when they were at maximum value.
*This means that negative rates (e.g. spells) were not always applied.

===Known bugs===
*Flickering of a rectangle region near the connection between hydlaa plaza and the new East Hydlaa map
*Pssetup may crash on some systems
*Chat sometimes doesn't scroll down to follow new text
*Using the "load all levels" option will give you some wrong textures here and there (example laanx temple).

===Update===
{{Calendar|3|June|2005}}
* Laanx temple has been expanded adding a new room in the upper level.
* The sewers have been lit up a bit, and many torches have been added and fixed.
* Jayose library has been expanded, with new shelves types and more space to walk.
* We added few new faces variations for the Ynnwn male characters. You can see those new faces in the char creation.
* The game now supports the feature to add a description to any static object (like trees, statues, roads, stones, furniture, etc...). We just started using it, but you can right click on the book in the new room of laanx temple to get its description. We plan to add many descriptions to give more deepness to the background.

{{ClearBreak}}

==0.3.011==
{{Calendar|4|August|2005}}

* Unique treasure generation.
* Fine-tuning of the progression rules.
* New quest system.
* Visual fixes on Hydlaa level, and some additions to the magic shop.
* WIPE: all characters deleted.

{{ClearBreak}}

==0.3.012==
{{Calendar|24|October|2005}}
===Features===
*Pets (familiars) added. New /pet command controls them.
*Frame rate limit added to Options. Frame rate limit is 62.5fps by default.
*Hair color for new characters can be changed. Existing characters will have to buy and use dye when it becomes available.
*Skills window has been reworked into categories. The category tab will blink if there is a skill available from the trainer.
*Gave GMs the ability to award XP for completing GM-created events.
*Right-click quick chat pop-up menu has been disabled.
*If you /use with an argument it wil assume you are trying to consume.
*/equip defaults to 1 item being used
*Support added for chained quests
*Some fixes so guild notes are actually usable:
** The gui now sends the targeted person's charcter id instead of your own, so it is possible to send notes.
** Private notes are only viewable by that character, and can be sent by any member of the guild. They are appended, not the best formatting, but it works for now.
*Creating a guild now has a confirmation dialog that explains the requirements.
*Re-wrote invite spam-blocker:
** Now only triggered on declines, so as to not block legitimate invites.
** Penalties now increase with each decline:
**# 1 min lockout
**# 5 min + warning
**# 10 min + 10 advisor point fine + 10 duel point fine, if duel spam + death
**# 30 point fine(s) + death + kick from server
** Penalties expire with gameplay time, and can be lowered by getting an accept from a player with no penalties and a enough advisor points.
** Penalty level is saved to the player's account entry in the database, so repeat offenders can't escape it. (relog resets to 3rd level)
*Enhancements to the looting system:
** Roll for loot enforcement: If a player in a group attempts to take instead of roll for any loot, the roll winner will be prompted to allow the action.
** Range restriction for rolling: Only group members within 30 meters (10 times normal loot range) can win a roll for loot.
*Implemented discard quest feature.
*/my command added
*Updater improved to be more efficient
*Add $target to shortcuts. Inserts the name of the player or object currently targeted into a command to replace each $target.
*Made it so if a spell -can- be cast on you (say, Life Infusion), and you have no target, it casts on yourself
*Improved NPC fighting behaviour so it's not cancelled by the server when the NPC leaves the range.
*Improved NPC navigation - they should hug walls less now.
*Add new icon to NPC right-click interact menu to chat to the NPC. Switches cursor to the chat window.
*Exiting the death realm now spawns you at your racial spawn point.
*/marriage command added

===Bug Fixes===
*Various inventory and exchange bugs fixed where items could be lost.
*Fixed a bug where lacking a 0th shortcut would make the shortcut window have errors.
*Negative values for stats/skills at character creation are now checked for.
*Message versioning to prevent player stats jumping around due to out of order UDP
*It is now possible to strafe and rotate
*Name labels are updated when name is changed
*Guild labels are updated when guild is changed
*Fixed fall damage
*Fixed that new looted items were not accessible until inventory was opened.
*Re-enabled mouse run
*Fixed that it was possible to cast healing spells on a target with 100% HP.
*Add /die command to commit suicide. If used in a duel, you automatically yield.
*Fixed bug where trying to deequip while dead creates ghost item
*Fix for recent problem of users being unable to zone.
*Fix for bug that prevents the casting of a spell after it was interrupted.
*Training exploit fixed
*Fixed bug "During a guild war one guild yielded and the other 2 guild didn't get the Karma Points".
*Fixed: complains at you if you try to cast Defensive Wind while targetting an enemy...saying it only can be cast on you. Made it cast such spells on you, regardless of what's targeted.
*Fixed bug that "Married to: xyz" was added again and again to your char desc when you edit it.
*Fixed bug that the character was not removed from his guild when it's deleted and you keep seeing it in the guild until the server is restarted.
*Fixed bug that players can start trading with other players without their permission and can annoy them in between fights etc.
*Various sound and music fixes

{{ClearBreak}}

==0.3.013==
{{Calendar|25|February|2006}}
===New Features===
*New mental and physical stamina system
*Many improvements to the GM system
*Multi-part and multi-path quests
*Many quest system improvements
*Added money to mini inventory window. (trades, etc)
*Some improvements to the GUI; simplified info window
*Added the ability for NPCs to use more animations
*Added more sound effects for actions
*Client now supports visible clothing/armor changes
*Client now supports customizable hair styles
*Updated in-game help to list all commands
*Right-click (by default) can now be used in all containers/inventories to view the item or a container's contents.
*Added font scaling option (set via setup)
*NPC dialogue now uses Wordnet, which will allow for more realistic communication
*Added snow support. Added rain support to Mac client.
*Labels will only show when in range to identify an object. (also helps performance by not drawing for far off objects) Dead objects now have red.
*New ban system which should keep greifers from just creating new accounts
*New mesh generation system to allow for more foliage in maps, some test one added to hydlaa and ojaroad
*New updater system, which doesn't download the repository unless it needs to. This will help the bandwidth of our servers and those with slower connections.
*Client can now automaticaly notify players when new updates are available, at the character selection screen.
*Many fixes for the crafting system. We are close to have it working for real.

===Fixes===
*Fixes for /dequip command in shortcuts
*Various crash fixes (too many to list)
*Many performance fixes.
*Fixed weather and fog glitches/crashes
*Fixed exploit where people could logout mid-battle
*Temporarly removed advisor points scoring system to stop competitions. Advisor points are now on account, not on char.
*Many fixes to the sound system. Sounds should be much better, and play when they're supposed to. Switched to new renderer, which is more stable.
*Issues with skill window tabs
*Issues with using weapons with stat/skill requirements
*Could "complete" an empty trade
*Fixes to entity labels. Added command "/repaintlabels force" as a tool to repaint more severe problems if they still happen.
*Fixed darkness bug
*New map lighting system in CS, which should clear up a few lighting issues. All maps relighted
*Fixed various bugs in NPCclient making NPCs act strangely
*Made pets unattackable
*Fixes for character creation system
*Fixed bugs with stamina not working at certain times
*Many fixes related to items, inventories, and containers. Items shouldn't dissapear anymore, and weights should be handled without errors.
*Better working configuration of keys and mouse buttons
*Fixed many, many, memory leaks in both PS and CS. The client should be able to run without having to be restarted very often and should be more efficient in using memory.
*Disabled invites while dueling, to prevent using them as a distraction to cheat
*Changing weapons mid battle will make you skip a turn, to prevent some exploits
*Fixed chat history to not loose current line by accident
*Fixed bug where sound effects would try to load when sound was off
*/who will only show up to 30 players based on the given filter, to fix issues with showing too many

{{ClearBreak}}

==0.3.014==
{{Calendar|9|April|2006}}
===New Features===
*New items, new armor skins.
*Support for armors that require a different armor model (think spiky armor)
*More GM system improvements (ex: GMs are now invisible by default)
*Weather system improvements (ex: can now fade in all spiffy-like)
*New tutorial system. Will now give help the first time you do new things.
*New proximity-based NPC dialogue system. NPCs can now be made to talk to you automatically when you move close to them.
*NPCs can now talk publicly, instead of only in /tells.
*Added "/screenshot nogui" feature to take clean shots, ignoring onscreen stuff.
*Glyphs now need to be repurified for new owners.
*Will now send notification on training from mining/crafting/etc.
*New options window in the updater to make setup easier
*Additions to the pet system
*Elves GUI set to default, just to show it to the ones that never tried it.

===Fixes===
*Fixes to the marriage system
*Fixed crash loading into a bad location
*Fixed an exploit where weakness could be used on someone to make them drop items
*Crafting system fixes; it should be ready soon
*Fixed bug where NPCs could spawn without full health
*Weather system fixes
*Fixed pet cloning bugs
*Fixes to name label alignments
*Updater self-updating is now back on
*Fixed a rare bug giving a 1 HP max
*Fixed tooltips not disappearing correctly
*Fixed an exploit in the pet name changing that could crash the server
*Turned spam-protection on for trade invites
*Fixed a bug cutting off long names in the buddy list
*Fixed a few updater bugs/crashes

{{ClearBreak}}

==0.3.014b==
{{Calendar|13|April|2006}}
*Fixed darkness in sewers
*Added more items to Harnquist smith shop and to Levrus alchemy laboratory for future crafting usage.
*Fixed few player textures (stonebm)
*New updater version

{{ClearBreak}}

==0.3.015==
{{Calendar|4|July|2006}}

===New features===
* More crafting system implementations, this will allow to create weapons and shields in game.
* Weapons and armors now decay with use and can be repaired. Crafted items have a better quality, so they decay slower.
* New scripting operations to add support for new spells like transmutation and invisibility (the spells are not yet in, but the engine now supports those)
* Multiple engine and art optimizations. We moved our format to a binary one to have better loading times, previously most of the time needed for loading was spent in parsing our XML levels. Now we have DDS textures, binary XML maps, and ptmalloc in CS. Maps load signifigantly faster and the package is smaller even with all the new content.
* New control and movement systems:
** Fixes many bugs, including the main collision detection issue.
** New stamina system which takes into account terrain steepness
** Now shows strafe animation (for the races that have it so far)
** Added sneak mode to creep around slowly (not all races have anim yet)
* Finally fixed the handness of characters. All characters correctly attack with right hand.

===New content===
* New "Bronze Doors" region
* Four new outdoor terrain maps (one based on the old Oja Road)
* World has been rearranged to move Akkaio from its temporary location to East of Hydlaa
* New armor textures:
** Each race should have a full set for leather armor now
** Added chainmail textures and items
* Initial support for plate armor
* New trait customizations for some races, including new skins for enkis
* New pet species and new animal affinity system
* NPCs support more scripting. Capable of being set to pickup items.
* Optional "lossless" parameter for /screenshot to save as PNG
* Added font size option to the config windows for certain windows
* New sound emitter generator used to add many of the insect sounds in the maps

===Notable fixes and improvements===
* Improved caching system on server
* Fixes for action locations
* More work on tutorial system
* Multiple fixes and improvements in sounds system
* Fixes and improvements for NPC pathfinding
* Improved entity loading in client to prevent freezing
* Fixed backwards left/right hand issues
* Some GM system improvements
* Added clear button to the shortcut editing window
* Optimized networking messages to lower total traffic by as much as 1/3, by size
* /report command is now working and works retroactively to include recent messages

===Other bugfixes===
* Fixed display bug when resizing buddy window
* Fixed display bug when selecting quest notes
* Fixed crash on pet dismiss with stat window
* Fixed bug in pssetup where the skin sample wasn't loaded
* Fixed bug where auto-full-defense couldn't fight back when stance was changed
* Fixed bug where failed transform message was not being displayed
* Fixed bug where managing a secret guild could make guild labels shown
* Fixed bugs where equip/dequip effects would persist or stack
* Fixed bug where camera mode would reset when going to the options
* Fixed bug where the option to show/hide guild labels required a restart
* Fixed bug where players could add money to containers that can't remove them
* Fixed bug where loading errors could start an infinte loop, instead of stopping
* Fixed crash in pssetup if no map is selected in relight
* Fixed bug where morphing would show equipment wrong on morphee's client
* Fixed bug where long generated names would make next name fall off the left
* Fixed bug causing duplicate entries in new character descriptions
* Fixed bug where you couldn't attack in PvP unless groupped with their last attacker
* Fixed bug where stance button could stay highlighted if not allowed to attack
* Fixed possible crash on new character upload
* Fixed bug where the skill window could popup after closing
* Fixed display bugs when a window is near the control bar

{{ClearBreak}}

==0.3.016==
{{Calendar|14|September|2006}}
===Design and content===
*Chat window updated, specific NPC tab, all visibile/audible messages moved to Main Tab, all detailed combat moved to system tab, combat details now only shown to user and group.
*Added support for character helms. Added base set of helms, but few races still missing.
*Mini-games system added, with ability to display a board, change pieces, configurable layouts.
*Method of calculation cast success now set as a formula.
*New animations added to complete the base set, few races still missing.
*Added support for monsters variations
*Added base armor for races. Kran has now a natural armor, monsters have various natural armors based on their race.
*Item quality is now averaged on stacking.
*Item resistance for crafted items set as 0.5

===Bug Fixes===
*Errors about unresolved item containers.
*Many fixes and improvements to crafting.
*Fixed crash if people tried to trade items while repairing them.
*Pathing of NPC fixed.
*Fixed stances of NPCs after respawn.

{{ClearBreak}}

==0.3.017==
{{Calendar|22|November|2006}}
===Engine===
*Improvements to minigames
*Improvements to NPCs AI, they are now able to explore, search and identify resources, finally harvest.
*Fixed crafted item quality
*Partial rewrite of crafting functionalities, will be easier to manage/expand for us
*Fixed few bugs on NPC movement
*Upgraded the cal3d animation engine to version 0.11
*Upgraded the [[CrystalSpace]] 3d rendering engine to 1.0
*Usage of the new particle system
*Fixed char selection screen to display equipped items
*Added button to Glyph window for spell research
*Added capability to manage area spells
*Added Active magic window
*Containers can now hold glyphs without disrupting casting

===Art===
*Added new animations for female ynnwn
*Added new monsters variations
*Added helms for all races (except ynnwn male)
*Added new Kran animations
*Upgraded particle effects for the new system (still to tweak)

{{ClearBreak}}

==0.3.018==
{{Calendar|7|February|2007}}
* New area south of hydlaa, called the winch.
* Hair styles support added. For now just the female ynnwn has different hair styles, but more will be added later
* New animations for some characters, like ynnwn male.
* New items and icons shipped into the client
* Lot of new quests loaded
* New faction system, you can see a first implementation in your skills window, under factions.
* GMs can register official events on the server, players participating to events can access events tab in quests window.
* Added new map function, to display/create maps
* First implementation of locks and keys (not fully usable yet)
* Many bug fixes and improvements

{{ClearBreak}}

==0.3.019==
{{Calendar|11|July|2007}}
===Content===
* Reached mark of 100 quests.
* Complete review of quests, all of them are working in game now
* Greatly improved dictionary of NPCs, and common responses
* Added new creatures: derghir, tloke, kikiri
* Made available variations of many creatures
* Added dermorian female player character model
* Added 4 Kran skins
* Improved dermorian male character
* Added plate armor for many chars
* Added new skins for enkidukai clans
* Added spell casting effects
* Added lot of new items, like bludgeoning weapons, amulets, rings, plants
* Added missing animations to player characters

===Engine===
* Shadows are now present under characters and objects!
* Chat bubbles are used on players and NPCs during dialogs
* Completely remade how inventory works server-side for more robust management
* Enabled generation of random loot, you will see lot of new items!
* Improved NPC movement and AI
* Improvement to guild management (we will reveal more in the next weeks)
* Improvements to sketches, you can now edit your own sketches
* Improvements to books, you can now edit your own books

{{ClearBreak}}

==0.3.020==
{{Calendar|14|October|2007}}
===New Features===
*Duels aren’t deadly anymore. You will knock a player down and then you will receive a message asking if you want to kill the player or not.
*Banking: Players will now be able to open a personal bank account. Guildleaders will also be able to open a guild bank account and set permission who can access the account. Not enabled yet in-game.
*New characters will now enter a tutorial-world when they login.
*The Death Realm is now cursed! Not enabled yet in-game.
*Authors are now able to name their books.
*Only the author of a book or sketch can now edit it. This ONLY applies to books and sketches bought AFTER the .20 release!
*Equipping helmets will now remove the hair mesh.
*Various fonts were changed to ones with a better (GPL) license.
*Work started on taxing.

===Art===
*Various maps now use the new "Lighter2" lightmap system for creating light and shadows.
*Various maps now use a newer 3d format (genmeshes instead of thingmeshes).
*More icons and meshes for items have been added.
*A tutorial area has been added for new players. The tutorial has to be completed by new players before moving to the game world.
*The tavern has been expanded.

===Changes===
====GUI====
*Mouserun has been enabled by default to aid new players. It can be turned off by un-assigning the "LeftClick" in Options->Controls->Keys->Camera->MouseRun.
*The order of the main menu icons has been changed to make it more intuitive. Obviously this will need getting used to for long-time players.
*Many changes and updates to the Planeshift Advanced Windowing System, this is the code backend of the graphical user interface.
*The book writing window now looks better.
*Chatbubbles are prettier.
*The last used spell is now highlighted in the spells window.
*When your name is mentioned the specific tab will now flash in way recognizable from the normal way.
*The tutorial window now looks better.
*Equipped items won’t show up in Buy/Sell window anymore.
*You can now have up to 200 shortcuts.
*You’re now prompted for a password when you try to delete your character.
*Various fixes to the graphical user interface.
*The item description window now shows item sizes.
*The total amount of trias is now displayed in the skillwindow.
*The guild invitation window always stays on top now.
*Several improvements for weather and especially fog.
*Fog now reduces your viewing distance, so it is actually "thick" now.

====Sound====
*Changes to most environment sounds, for fading and distance values.
*New sound setups for the Winch and the Bronze Doors.
*A new sound for the "DRCitadel" in the Death Realm.

====Movement and Combat====
*You will get the “too tired” message at 10% stamina now.
*Stamina now regenerates faster when sitting.
*Natural armour is now counted as a bonus to normal armour, instead of something that is replaced when you equip bought armour.
*Now you cannot use “/attack 1” anymore but you should use “/attack bloody” instead.
*You won’t be able to lure NPCs anymore by just pressing the attack button.
*A toggle key for running/walking can be used when you have autorun enabled(r), you must enabled it under Options first.
*Passing a region border no longer stops you from running.

===Engine===
*Planeshift now uses version 1.2 of The Crystal Space 3D engine and the Crystal Entity Layer environment.
*Meshes, textures and materials are now deleted when they aren’t needed anymore, this improves memory usage.
*The client now loads less models and textures during startup causing it to launch much faster, they are loaded on-demand now.
*Many changes and fixes to map loading and unloading, making it better and faster.
*Some optimizations in network code to make the server faster.

===Various===
*You can now trade while sitting.
*Players can now stack items together regardless of quality and creator.
*An error message on /unstick now displays how long you have to wait until you can use /unstick again.
*The /pos command for showing your position now shows your instance too.
*Advisors can now see who other advisors are.
*The timeout for advisor sessions has been doubled.

===Fixed Bugs===
*You can now type in the auction tab again instead of having to use /auction.
*Several server crashes.
*Several fixes to make sure players won’t get stuck in instances anymore.
*Players can now loot when killing mobs with a Damage Over Time spell.
*Various fixes to the marriage system.
*The command “z” to sit now always works, sometimes you had to press it twice.
*Fixes to movement code so you should get stuck less often.
*Some fixes to the /unstick command
*Many changes and fixes to the locking and unlocking of doors.
*It is not possible anymore to fish for gold.
*Sometimes you had to press “r” twice to enable autorun, this is now made more elegant.
*The preview of skins now works in pssetup.
*Advisor messages now actually display the right information.
*The FPS cap and the distance cap now actually work.
*You can now close the sketch window with the red cross.
*If you use quotes ("") in a sketch, the entire sketch isn't wiped anymore.

===Know Issues===
*After a partial stack within the furnace is moved, only the amount that you moved will be melted. The rest can be lost.
*After all art and engine related changes, users may experience more lag than usual at times. You can fix this by decreasing Distance under "Options-->Graphics-->Details".
*When moving to a new map, the progress bar of the loading screen will not show the progress correctly.
*Some issues with guildhouses access rights.
*When mouserun is enabled, sometimes clicking on the GUI or on an NPC will cause your character to move too.

[[Category:PS History]]

Crystal Blue

2025-06-10T17:51:46Z

Talad:

'''Crystal Blue''' Is the code name for the third major release of [[PlaneShift]].
[[File:Cbsplash.jpg|none|thumb]]

==0.3.004==
{{Calendar|24|December|2004}}
* new [[CrystalSpace]] (3D graphics) engine
* using skeletal models and animations
* introducing magic
* introducing combat

{{ClearBreak}}

==0.3.005==
{{Calendar|~30|December|2004}}

{{ClearBreak}}

==0.3.006==
{{Calendar|22|January|2005}}

{{ClearBreak}}

==0.3.007==
{{Calendar|10|February|2005}}

* Klyros model added.
* Added a set of items including food and loot items.

{{ClearBreak}}

==0.3.010==
{{Calendar|18|May|2005}}
===Major User-Visible Features===
*New area of East Hydlaa is available (Jayose has been relocated). New NPCs will be added there soon.
*Character traits - current only 1 new elf skin. You can now customize the face of your char (dermorian only). Now that the feature is in place, we will add more faces for other chars as well.
*New crafting system - shields only at the moment
*New complete GUI skinning system
*One additional skin available thanks to Cherppow. (to change it, you can rename planeshift/art/skin/elves.zip into planeshift/art/skin/default.zip)
*New loading screens
*Added duel points and advisor points to skill window info displayed.
*Added some new button art to look better.
*Added duel-point penalty for spamming duel invites.
*Added command to see /duel_points
*You don't get skill practise for attacking other players now.
*Train icon added in the interaction menu with trainers
*Added /changeguildname
*German manual
*Message window will now no longer jump to the end when a message is added.
*/quit now prompts before quitting
*Added link to login page that shows where to register a new account.
*License of the package changed from PlaneShift Team to Atomic Blue.

===Major User-Visible Fixes===
*A number of bug fixed on Hydlaa level.
*Updated/fixed some spell effects
*Fixed that you could freely PK players that were just joining the game
*Fixed that if you opened a window during autorun, you could run forever regardless of stamina.
*Fixed that when you died, you could still turn your remains with mouselook.
*When a character is attacked, its stance resets to "full defense".
*Fixed that tab completition was sometimes changing chat command to /tell from e.g. /say.
*Fixed that when negative HP rates lowered HP to zero, the character was not killed.
*Fixed that vitals were not adjusted when they were at maximum value.
*This means that negative rates (e.g. spells) were not always applied.

===Known bugs===
*Flickering of a rectangle region near the connection between hydlaa plaza and the new East Hydlaa map
*Pssetup may crash on some systems
*Chat sometimes doesn't scroll down to follow new text
*Using the "load all levels" option will give you some wrong textures here and there (example laanx temple).

===Update===
{{Calendar|3|June|2005}}
* Laanx temple has been expanded adding a new room in the upper level.
* The sewers have been lit up a bit, and many torches have been added and fixed.
* Jayose library has been expanded, with new shelves types and more space to walk.
* We added few new faces variations for the Ynnwn male characters. You can see those new faces in the char creation.
* The game now supports the feature to add a description to any static object (like trees, statues, roads, stones, furniture, etc...). We just started using it, but you can right click on the book in the new room of laanx temple to get its description. We plan to add many descriptions to give more deepness to the background.

{{ClearBreak}}

==0.3.011==
{{Calendar|4|August|2005}}

* Unique treasure generation.
* Fine-tuning of the progression rules.
* New quest system.
* Visual fixes on Hydlaa level, and some additions to the magic shop.
* WIPE: all characters deleted.

{{ClearBreak}}

==0.3.012==
{{Calendar|24|October|2005}}
===Features===
*Pets (familiars) added. New /pet command controls them.
*Frame rate limit added to Options. Frame rate limit is 62.5fps by default.
*Hair color for new characters can be changed. Existing characters will have to buy and use dye when it becomes available.
*Skills window has been reworked into categories. The category tab will blink if there is a skill available from the trainer.
*Gave GMs the ability to award XP for completing GM-created events.
*Right-click quick chat pop-up menu has been disabled.
*If you /use with an argument it wil assume you are trying to consume.
*/equip defaults to 1 item being used
*Support added for chained quests
*Some fixes so guild notes are actually usable:
** The gui now sends the targeted person's charcter id instead of your own, so it is possible to send notes.
** Private notes are only viewable by that character, and can be sent by any member of the guild. They are appended, not the best formatting, but it works for now.
*Creating a guild now has a confirmation dialog that explains the requirements.
*Re-wrote invite spam-blocker:
** Now only triggered on declines, so as to not block legitimate invites.
** Penalties now increase with each decline:
**# 1 min lockout
**# 5 min + warning
**# 10 min + 10 advisor point fine + 10 duel point fine, if duel spam + death
**# 30 point fine(s) + death + kick from server
** Penalties expire with gameplay time, and can be lowered by getting an accept from a player with no penalties and a enough advisor points.
** Penalty level is saved to the player's account entry in the database, so repeat offenders can't escape it. (relog resets to 3rd level)
*Enhancements to the looting system:
** Roll for loot enforcement: If a player in a group attempts to take instead of roll for any loot, the roll winner will be prompted to allow the action.
** Range restriction for rolling: Only group members within 30 meters (10 times normal loot range) can win a roll for loot.
*Implemented discard quest feature.
*/my command added
*Updater improved to be more efficient
*Add $target to shortcuts. Inserts the name of the player or object currently targeted into a command to replace each $target.
*Made it so if a spell -can- be cast on you (say, Life Infusion), and you have no target, it casts on yourself
*Improved NPC fighting behaviour so it's not cancelled by the server when the NPC leaves the range.
*Improved NPC navigation - they should hug walls less now.
*Add new icon to NPC right-click interact menu to chat to the NPC. Switches cursor to the chat window.
*Exiting the death realm now spawns you at your racial spawn point.
*/marriage command added

===Bug Fixes===
*Various inventory and exchange bugs fixed where items could be lost.
*Fixed a bug where lacking a 0th shortcut would make the shortcut window have errors.
*Negative values for stats/skills at character creation are now checked for.
*Message versioning to prevent player stats jumping around due to out of order UDP
*It is now possible to strafe and rotate
*Name labels are updated when name is changed
*Guild labels are updated when guild is changed
*Fixed fall damage
*Fixed that new looted items were not accessible until inventory was opened.
*Re-enabled mouse run
*Fixed that it was possible to cast healing spells on a target with 100% HP.
*Add /die command to commit suicide. If used in a duel, you automatically yield.
*Fixed bug where trying to deequip while dead creates ghost item
*Fix for recent problem of users being unable to zone.
*Fix for bug that prevents the casting of a spell after it was interrupted.
*Training exploit fixed
*Fixed bug "During a guild war one guild yielded and the other 2 guild didn't get the Karma Points".
*Fixed: complains at you if you try to cast Defensive Wind while targetting an enemy...saying it only can be cast on you. Made it cast such spells on you, regardless of what's targeted.
*Fixed bug that "Married to: xyz" was added again and again to your char desc when you edit it.
*Fixed bug that the character was not removed from his guild when it's deleted and you keep seeing it in the guild until the server is restarted.
*Fixed bug that players can start trading with other players without their permission and can annoy them in between fights etc.
*Various sound and music fixes

{{ClearBreak}}

==0.3.013==
{{Calendar|25|February|2006}}
===New Features===
*New mental and physical stamina system
*Many improvements to the GM system
*Multi-part and multi-path quests
*Many quest system improvements
*Added money to mini inventory window. (trades, etc)
*Some improvements to the GUI; simplified info window
*Added the ability for NPCs to use more animations
*Added more sound effects for actions
*Client now supports visible clothing/armor changes
*Client now supports customizable hair styles
*Updated in-game help to list all commands
*Right-click (by default) can now be used in all containers/inventories to view the item or a container's contents.
*Added font scaling option (set via setup)
*NPC dialogue now uses Wordnet, which will allow for more realistic communication
*Added snow support. Added rain support to Mac client.
*Labels will only show when in range to identify an object. (also helps performance by not drawing for far off objects) Dead objects now have red.
*New ban system which should keep greifers from just creating new accounts
*New mesh generation system to allow for more foliage in maps, some test one added to hydlaa and ojaroad
*New updater system, which doesn't download the repository unless it needs to. This will help the bandwidth of our servers and those with slower connections.
*Client can now automaticaly notify players when new updates are available, at the character selection screen.
*Many fixes for the crafting system. We are close to have it working for real.

===Fixes===
*Fixes for /dequip command in shortcuts
*Various crash fixes (too many to list)
*Many performance fixes.
*Fixed weather and fog glitches/crashes
*Fixed exploit where people could logout mid-battle
*Temporarly removed advisor points scoring system to stop competitions. Advisor points are now on account, not on char.
*Many fixes to the sound system. Sounds should be much better, and play when they're supposed to. Switched to new renderer, which is more stable.
*Issues with skill window tabs
*Issues with using weapons with stat/skill requirements
*Could "complete" an empty trade
*Fixes to entity labels. Added command "/repaintlabels force" as a tool to repaint more severe problems if they still happen.
*Fixed darkness bug
*New map lighting system in CS, which should clear up a few lighting issues. All maps relighted
*Fixed various bugs in NPCclient making NPCs act strangely
*Made pets unattackable
*Fixes for character creation system
*Fixed bugs with stamina not working at certain times
*Many fixes related to items, inventories, and containers. Items shouldn't dissapear anymore, and weights should be handled without errors.
*Better working configuration of keys and mouse buttons
*Fixed many, many, memory leaks in both PS and CS. The client should be able to run without having to be restarted very often and should be more efficient in using memory.
*Disabled invites while dueling, to prevent using them as a distraction to cheat
*Changing weapons mid battle will make you skip a turn, to prevent some exploits
*Fixed chat history to not loose current line by accident
*Fixed bug where sound effects would try to load when sound was off
*/who will only show up to 30 players based on the given filter, to fix issues with showing too many

{{ClearBreak}}

==0.3.014==
{{Calendar|9|April|2006}}
===New Features===
*New items, new armor skins.
*Support for armors that require a different armor model (think spiky armor)
*More GM system improvements (ex: GMs are now invisible by default)
*Weather system improvements (ex: can now fade in all spiffy-like)
*New tutorial system. Will now give help the first time you do new things.
*New proximity-based NPC dialogue system. NPCs can now be made to talk to you automatically when you move close to them.
*NPCs can now talk publicly, instead of only in /tells.
*Added "/screenshot nogui" feature to take clean shots, ignoring onscreen stuff.
*Glyphs now need to be repurified for new owners.
*Will now send notification on training from mining/crafting/etc.
*New options window in the updater to make setup easier
*Additions to the pet system
*Elves GUI set to default, just to show it to the ones that never tried it.

===Fixes===
*Fixes to the marriage system
*Fixed crash loading into a bad location
*Fixed an exploit where weakness could be used on someone to make them drop items
*Crafting system fixes; it should be ready soon
*Fixed bug where NPCs could spawn without full health
*Weather system fixes
*Fixed pet cloning bugs
*Fixes to name label alignments
*Updater self-updating is now back on
*Fixed a rare bug giving a 1 HP max
*Fixed tooltips not disappearing correctly
*Fixed an exploit in the pet name changing that could crash the server
*Turned spam-protection on for trade invites
*Fixed a bug cutting off long names in the buddy list
*Fixed a few updater bugs/crashes

{{ClearBreak}}

==0.3.014b==
{{Calendar|13|April|2006}}
*Fixed darkness in sewers
*Added more items to Harnquist smith shop and to Levrus alchemy laboratory for future crafting usage.
*Fixed few player textures (stonebm)
*New updater version

{{ClearBreak}}

==0.3.015==
{{Calendar|4|July|2006}}

===New features===
* More crafting system implementations, this will allow to create weapons and shields in game.
* Weapons and armors now decay with use and can be repaired. Crafted items have a better quality, so they decay slower.
* New scripting operations to add support for new spells like transmutation and invisibility (the spells are not yet in, but the engine now supports those)
* Multiple engine and art optimizations. We moved our format to a binary one to have better loading times, previously most of the time needed for loading was spent in parsing our XML levels. Now we have DDS textures, binary XML maps, and ptmalloc in CS. Maps load signifigantly faster and the package is smaller even with all the new content.
* New control and movement systems:
** Fixes many bugs, including the main collision detection issue.
** New stamina system which takes into account terrain steepness
** Now shows strafe animation (for the races that have it so far)
** Added sneak mode to creep around slowly (not all races have anim yet)
* Finally fixed the handness of characters. All characters correctly attack with right hand.

===New content===
* New "Bronze Doors" region
* Four new outdoor terrain maps (one based on the old Oja Road)
* World has been rearranged to move Akkaio from its temporary location to East of Hydlaa
* New armor textures:
** Each race should have a full set for leather armor now
** Added chainmail textures and items
* Initial support for plate armor
* New trait customizations for some races, including new skins for enkis
* New pet species and new animal affinity system
* NPCs support more scripting. Capable of being set to pickup items.
* Optional "lossless" parameter for /screenshot to save as PNG
* Added font size option to the config windows for certain windows
* New sound emitter generator used to add many of the insect sounds in the maps

===Notable fixes and improvements===
* Improved caching system on server
* Fixes for action locations
* More work on tutorial system
* Multiple fixes and improvements in sounds system
* Fixes and improvements for NPC pathfinding
* Improved entity loading in client to prevent freezing
* Fixed backwards left/right hand issues
* Some GM system improvements
* Added clear button to the shortcut editing window
* Optimized networking messages to lower total traffic by as much as 1/3, by size
* /report command is now working and works retroactively to include recent messages

===Other bugfixes===
* Fixed display bug when resizing buddy window
* Fixed display bug when selecting quest notes
* Fixed crash on pet dismiss with stat window
* Fixed bug in pssetup where the skin sample wasn't loaded
* Fixed bug where auto-full-defense couldn't fight back when stance was changed
* Fixed bug where failed transform message was not being displayed
* Fixed bug where managing a secret guild could make guild labels shown
* Fixed bugs where equip/dequip effects would persist or stack
* Fixed bug where camera mode would reset when going to the options
* Fixed bug where the option to show/hide guild labels required a restart
* Fixed bug where players could add money to containers that can't remove them
* Fixed bug where loading errors could start an infinte loop, instead of stopping
* Fixed crash in pssetup if no map is selected in relight
* Fixed bug where morphing would show equipment wrong on morphee's client
* Fixed bug where long generated names would make next name fall off the left
* Fixed bug causing duplicate entries in new character descriptions
* Fixed bug where you couldn't attack in PvP unless groupped with their last attacker
* Fixed bug where stance button could stay highlighted if not allowed to attack
* Fixed possible crash on new character upload
* Fixed bug where the skill window could popup after closing
* Fixed display bugs when a window is near the control bar

{{ClearBreak}}

==0.3.016==
{{Calendar|14|September|2006}}
===Design and content===
*Chat window updated, specific NPC tab, all visibile/audible messages moved to Main Tab, all detailed combat moved to system tab, combat details now only shown to user and group.
*Added support for character helms. Added base set of helms, but few races still missing.
*Mini-games system added, with ability to display a board, change pieces, configurable layouts.
*Method of calculation cast success now set as a formula.
*New animations added to complete the base set, few races still missing.
*Added support for monsters variations
*Added base armor for races. Kran has now a natural armor, monsters have various natural armors based on their race.
*Item quality is now averaged on stacking.
*Item resistance for crafted items set as 0.5

===Bug Fixes===
*Errors about unresolved item containers.
*Many fixes and improvements to crafting.
*Fixed crash if people tried to trade items while repairing them.
*Pathing of NPC fixed.
*Fixed stances of NPCs after respawn.

{{ClearBreak}}

==0.3.017==
{{Calendar|22|November|2006}}
===Engine===
*Improvements to minigames
*Improvements to NPCs AI, they are now able to explore, search and identify resources, finally harvest.
*Fixed crafted item quality
*Partial rewrite of crafting functionalities, will be easier to manage/expand for us
*Fixed few bugs on NPC movement
*Upgraded the cal3d animation engine to version 0.11
*Upgraded the [[CrystalSpace]] 3d rendering engine to 1.0
*Usage of the new particle system
*Fixed char selection screen to display equipped items
*Added button to Glyph window for spell research
*Added capability to manage area spells
*Added Active magic window
*Containers can now hold glyphs without disrupting casting

===Art===
*Added new animations for female ynnwn
*Added new monsters variations
*Added helms for all races (except ynnwn male)
*Added new Kran animations
*Upgraded particle effects for the new system (still to tweak)

{{ClearBreak}}

==0.3.018==
{{Calendar|7|February|2007}}
* New area south of hydlaa, called the winch.
* Hair styles support added. For now just the female ynnwn has different hair styles, but more will be added later
* New animations for some characters, like ynnwn male.
* New items and icons shipped into the client
* Lot of new quests loaded
* New faction system, you can see a first implementation in your skills window, under factions.
* GMs can register official events on the server, players participating to events can access events tab in quests window.
* Added new map function, to display/create maps
* First implementation of locks and keys (not fully usable yet)
* Many bug fixes and improvements

{{ClearBreak}}

==0.3.019==
{{Calendar|11|July|2007}}
===Content===
* Reached mark of 100 quests.
* Complete review of quests, all of them are working in game now
* Greatly improved dictionary of NPCs, and common responses
* Added new creatures: derghir, tloke, kikiri
* Made available variations of many creatures
* Added dermorian female player character model
* Added 4 Kran skins
* Improved dermorian male character
* Added plate armor for many chars
* Added new skins for enkidukai clans
* Added spell casting effects
* Added lot of new items, like bludgeoning weapons, amulets, rings, plants
* Added missing animations to player characters

===Engine===
* Shadows are now present under characters and objects!
* Chat bubbles are used on players and NPCs during dialogs
* Completely remade how inventory works server-side for more robust management
* Enabled generation of random loot, you will see lot of new items!
* Improved NPC movement and AI
* Improvement to guild management (we will reveal more in the next weeks)
* Improvements to sketches, you can now edit your own sketches
* Improvements to books, you can now edit your own books

{{ClearBreak}}

==0.3.020==
{{Calendar|14|October|2007}}
===New Features===
*Duels aren’t deadly anymore. You will knock a player down and then you will receive a message asking if you want to kill the player or not.
*Banking: Players will now be able to open a personal bank account. Guildleaders will also be able to open a guild bank account and set permission who can access the account. Not enabled yet in-game.
*New characters will now enter a tutorial-world when they login.
*The Death Realm is now cursed! Not enabled yet in-game.
*Authors are now able to name their books.
*Only the author of a book or sketch can now edit it. This ONLY applies to books and sketches bought AFTER the .20 release!
*Equipping helmets will now remove the hair mesh.
*Various fonts were changed to ones with a better (GPL) license.
*Work started on taxing.

===Art===
*Various maps now use the new "Lighter2" lightmap system for creating light and shadows.
*Various maps now use a newer 3d format (genmeshes instead of thingmeshes).
*More icons and meshes for items have been added.
*A tutorial area has been added for new players. The tutorial has to be completed by new players before moving to the game world.
*The tavern has been expanded.

===Changes===
====GUI====
*Mouserun has been enabled by default to aid new players. It can be turned off by un-assigning the "LeftClick" in Options->Controls->Keys->Camera->MouseRun.
*The order of the main menu icons has been changed to make it more intuitive. Obviously this will need getting used to for long-time players.
*Many changes and updates to the Planeshift Advanced Windowing System, this is the code backend of the graphical user interface.
*The book writing window now looks better.
*Chatbubbles are prettier.
*The last used spell is now highlighted in the spells window.
*When your name is mentioned the specific tab will now flash in way recognizable from the normal way.
*The tutorial window now looks better.
*Equipped items won’t show up in Buy/Sell window anymore.
*You can now have up to 200 shortcuts.
*You’re now prompted for a password when you try to delete your character.
*Various fixes to the graphical user interface.
*The item description window now shows item sizes.
*The total amount of trias is now displayed in the skillwindow.
*The guild invitation window always stays on top now.
*Several improvements for weather and especially fog.
*Fog now reduces your viewing distance, so it is actually "thick" now.

====Sound====
*Changes to most environment sounds, for fading and distance values.
*New sound setups for the Winch and the Bronze Doors.
*A new sound for the "DRCitadel" in the Death Realm.

====Movement and Combat====
*You will get the “too tired” message at 10% stamina now.
*Stamina now regenerates faster when sitting.
*Natural armour is now counted as a bonus to normal armour, instead of something that is replaced when you equip bought armour.
*Now you cannot use “/attack 1” anymore but you should use “/attack bloody” instead.
*You won’t be able to lure NPCs anymore by just pressing the attack button.
*A toggle key for running/walking can be used when you have autorun enabled(r), you must enabled it under Options first.
*Passing a region border no longer stops you from running.

===Engine===
*Planeshift now uses version 1.2 of The Crystal Space 3D engine and the Crystal Entity Layer environment.
*Meshes, textures and materials are now deleted when they aren’t needed anymore, this improves memory usage.
*The client now loads less models and textures during startup causing it to launch much faster, they are loaded on-demand now.
*Many changes and fixes to map loading and unloading, making it better and faster.
*Some optimizations in network code to make the server faster.

===Various===
*You can now trade while sitting.
*Players can now stack items together regardless of quality and creator.
*An error message on /unstick now displays how long you have to wait until you can use /unstick again.
*The /pos command for showing your position now shows your instance too.
*Advisors can now see who other advisors are.
*The timeout for advisor sessions has been doubled.

===Fixed Bugs===
*You can now type in the auction tab again instead of having to use /auction.
*Several server crashes.
*Several fixes to make sure players won’t get stuck in instances anymore.
*Players can now loot when killing mobs with a Damage Over Time spell.
*Various fixes to the marriage system.
*The command “z” to sit now always works, sometimes you had to press it twice.
*Fixes to movement code so you should get stuck less often.
*Some fixes to the /unstick command
*Many changes and fixes to the locking and unlocking of doors.
*It is not possible anymore to fish for gold.
*Sometimes you had to press “r” twice to enable autorun, this is now made more elegant.
*The preview of skins now works in pssetup.
*Advisor messages now actually display the right information.
*The FPS cap and the distance cap now actually work.
*You can now close the sketch window with the red cross.
*If you use quotes ("") in a sketch, the entire sketch isn't wiped anymore.

===Know Issues===
*After a partial stack within the furnace is moved, only the amount that you moved will be melted. The rest can be lost.
*After all art and engine related changes, users may experience more lag than usual at times. You can fix this by decreasing Distance under "Options-->Graphics-->Details".
*When moving to a new map, the progress bar of the loading screen will not show the progress correctly.
*Some issues with guildhouses access rights.
*When mouserun is enabled, sometimes clicking on the GUI or on an NPC will cause your character to move too.

[[Category:PS History]]

Molecular Blue

2025-06-10T17:49:45Z

Talad:

'''Molecular Blue''' is the code name that was given ex post to the second major releases of [[PlaneShift]].

The first numbered release documented in the news [http://www.planeshift.it/news_2003.html] was
0.2.007 the previous releases are dealt with here as 0.2.000+.
[[File:Mbsplash.jpg|none|thumb]]

==Screenshots==
<gallery>
Image:PSMB-1.jpg|View over Hydlaa
Image:PSMB-2.jpg|At Jayose's
Image:PSMB-3.jpg|Players at the Laanx well
Image:PSMB-4.jpg|The Laanx caves
Image:PSMB-5.jpg|North gate
Image:PSMB-6.jpg|Tavern
Image:PSMB-7.jpg|Jayose and a customer
Image:PSMB-8.jpg|Laanx temple
</gallery>

==0.2.000+==
{{Calendar|7|March|2003}}

{{ClearBreak}}

==0.2.007==
{{Calendar|14|March|2003}}

{{ClearBreak}}

==0.2.010==
{{Calendar|14|April|2003}}

{{ClearBreak}}

[[Category:PS History]]

File:Mbsplash.jpg

2025-06-10T17:48:13Z

Talad:

File:Shot combat.jpg

2025-06-10T17:47:48Z

Talad:

File:Cb4.jpg

2025-06-10T17:47:40Z

Talad:

File:Cb3.jpg

2025-06-10T17:47:31Z

Talad:

File:Cb2.jpg

2025-06-10T17:47:22Z

Talad:

File:Cb1.jpg

2025-06-10T17:47:14Z

Talad:

File:Cbsplash.jpg

2025-06-10T17:47:02Z

Talad:

PlaneShift

2025-06-10T17:46:11Z

Talad: /* Versions */

PlaneShift is a Massively Multiplayer Online Role Playing Game immersed in a 3D virtual fantasy world which is FULLY FREE to play. There are no limitations in skills, ranks, abilities, items you can gain with your free account; no time limits; no locked premium content or additional constraints. Servers and bandwidth are donated by sponsors. The developers, Atomic Blue, are a group of RPG enthusiasts whose efforts and contributions are voluntary, not paid. 

At the present state of development, PlaneShift is not a complete game, but it has all the systems needed for enjoyable play, including combat, magic, crafting, quests and detailed settings. A downloadable client program allows you to to immerse your character in vibrant 3D surroundings. Today you can explore the virtual world, interact with other players or with server controlled creatures, fight monsters, cast spells, solve quests and puzzles, improve your character, gain magical items, craft new items and more. The game is still under heavy development, so you may easily find bugs, glitches and missing features. Our model is to keep the game open for the public, so you can give feedback on the features you want us to develop and help shape the future of the game. We are working to create an interactive world with politics and an economy, and improve the artificial intelligence of server-controlled non-player-characters that bring our world to life! 

Our virtual domain is persistent, and this means you can connect to it at any hour of the day and you will always find players and NPCs wandering our realms. Your character and progress is stored on the server, so you never have to worry about saving the game. A player can start from humble beginnings and advance to greatness in whatever path they may choose.

Remember that PlaneShift is a Role Playing Game - be sure to read our Roleplay guidelines! We think the RPG part of the MMORPG definition has a meaning! 

PlaneShift is Open Source for the client and server code, so anyone can contribute to its development! If you want to help, see how to join our team [http://www.planeshift.it/Join%20Us here], or consider making a [http://www.planeshift.it/Donate donation]. 

==Idea and previous history==
The history of PlaneShift before it became 3D is described in [[PlaneShift2D]].

==Versions==

===[[Atomic Blue]] (0.1)===
The very first PlaneShift version.

2 May 2002

===[[Molecular Blue]] (0.2)===
The second version of PlaneShift.

7 March 2003

===[[Crystal Blue]] (0.3)===
Tria is now the new currency. Ojaveda is born and the first Dsar, Akkaio, is added as home of all Enkidukai. Over the course of development the first craftings are introduced.

24 December 2004

===[[Steel Blue]] (0.4)===
Gugrontid the home town of Kran was added.

3 March 2008

===[[Arcane Chrysalis]] (0.5)===

===[[Azure Spirit]] (0.6)===
Current version. Male [[Nolthrir]] model and 11 new [[Ingame_Help#Magic.2C_Glyphs_and_Spells|spells]] were added; a new map, a new creature and many platinum-steel weapons ([[crafting]]) are now available; many [[NPC]] behaviours were updated (so newly created characters will not be attacked by relatively weak, but aggressive, NPCs able to kill them).

==Game features==
The following list represents some of the features of the final product. Please remember that today PlaneShift is still under heavy development. 

* 10 playable races with unique traits!
* Unlimited professions through a skill system
* Original magic system with six Ways of magic
* Hundreds of spells
* Numerous huge worlds to explore
* A great number of quests to test your wit and skill
* Monsters and NPCs with good AI that produce game events
* A world that evolves with or without player interaction
* Own your guild house
* Politics and economy
* ... and much much more!

[[Category:PS History|!]]

PS Voiceovers

2025-06-04T19:30:20Z

Talad: /* Dryken entity (second try): */

== '''Introduction''' ==

The current PlaneShift release allows Non Player Character voices. The NPCs can greet and speak with players using real voices.

We want as first step to have greetings of all NPCs in game voiced.

We may or may not use accents depending on availability of voice donors, anyway some accents can be made up, and that’s ok.

'''Accents by race:'''

NOTE: a voiceover is better than no voiceover. So the list below is what we would like to have, but we can still use just your voice for any character.

* Ylian: American English/Southern
* Nolthrir: Spanish (fallback italian)
* Dermorian: French ([https://accent.gmu.edu/browse_language.php?function=detail&speakerid=1729 male sample] [https://accent.gmu.edu/browse_language.php?function=detail&speakerid=2536 female sample])
* Stonebreaker/Hammerwielder: Scottish/Irish (fallback german)
* Diaboli: Eastern European ([http://accent.gmu.edu/browse_language.php?function=detail&speakerid=299 male sample] [http://accent.gmu.edu/browse_language.php?function=detail&speakerid=305 female sample]) (fallback german or scottish/irish)
* Kran: American English but run through a metallic filter (fallback american english)
* Klyros: Italian
* Enkidukai: Arabic / Asian
* Lemur: British English

Should we use indian, chinese or japanese? Those are pretty recognizeable.

For instructions on how to record a voiceover please [http://planeshift.ezpcusa.com/voice/ click here].

== How to make an accent? ==

Well, it's better if you are from the specific country, but some accents can be faked.

[http://accent.gmu.edu/browse_language.php Here is a great resource] of accents all over the world. We should select the best clips and add it to the list above.

Also if you think you have an accent record it!

== How to pronounce special names and locations ==

Here is a short clip on how I (Luca) pronounce the names of races and few places. If you do a voiceover will be good to use those.

[http://www.planeshift.it/download/prospects/ps_spelling_names.mp3 Names pronunciation]

== Tutorial voiceover ==

The tutorial has been improved with some small but important changes, and we need to re-record the voices to follow the new text for the following NPCs.

Please read the transcripts and submit your samples.

Abelia: Ynnwn female ( [[full Abelia transcript]] ) DONE! by VideoSymphony

Naeve: Hammerwielder female ( [[full Naeve transcript]] ) DONE! by PS player

Ibhaar: Ynnwn male ( [[full Ibhaar transcript]] ) DONE! by VideoSymphony

Orphia: Dermorian female ( [[full Orphia transcript]] ) DONE! edited old voice

Xargon: Klyros male ( [[full Xargon transcript]] ) DONE! by PS devs

Xenak: Klyros male ( [[full Xenak transcript]] ) DONE! by PS devs

Please sign up and discuss about it [http://www.hydlaaplaza.com/smf/index.php?topic=38600.0 here].

To submit a sample of your voice, please use [http://planeshift.ezpcusa.com/voice/ this page]. We will contact you soon!

== Greetings/Goodbye ==

We want to have the greetings and goodbyes recorded for all our NPCs.

To find out the phrases they use do the following:
* install the game!
* log in game and choose one NPC
* click on him, then go to the chat windows, and select the NPC tab, and type "Hi". he will answer with some text.
* Retype "Hi" few times and he will probably answer with different phrases (usually there are 1-3).
* Record the audio for the phrases you got.
* accents as above. upload as above.
* Edit this page and type in the NPC name you recorded, so others will know that's done already.
* Do the same with "goodbye", most NPC miss the "goodbye", so you will most likely get a standard answer taken from the general response database.

== Notes for Audacity ==

=== Robot voice: ===

* Delay: delay level per echo -10 , delay time 0.01 , pitch/tempo, pitch change 0, Number of echoes 30, allow duration YES.
* Ctrl+R (10 times)
* Normalize, normalize peak to -1.0 dB
* Pitch -> -26 Percent change
* Reverb -> Room size 20%, Pre delay 15, Reverb 50%, Damping 50%, Tone Low 68, Tone High 100, Wet Gain -2, Dry Gain -1, Stereo Width 83%

=== Dryken entity: ===

* Pitch -> -20%
* PaulStretch -> 2.0, 0.2
* Change Tempo -> +50 percent change
* Bass and Treble -> Bass: +12 Treble: -5
* Reverb -> Room size 42%, Pre delay 80, Reverb 60%, Damping 50%, Tone Low 74, Tone High 77, Wet Gain -2, Dry Gain -3, Stereo Width 50%

=== Dryken entity (second try): ===

*Pitch -> -20%
* Tremolo -> Triangle, start: 10, wet:50, frequency: 45

=== Kran voice: ===

*Pitch -> -3 semitones
*Volume -2db
* Duplicate track, on second track:
** Tremolo -> Triangle, start: 10, wet:90, frequency: 35
** Effect->Invert
** Volume -6db

Others:

Tremolo -> Sine , 53, 94, 40

== Tests on AI voice generation (May 2025) ==

{| class="wikitable"
|+
!Service
!Custom voice design through prompt
!Supports all our accents
!Emotions
!Sounds
!Age
!voice type
!Save Voice for later use
|-
|'''Resemble AI'''
|YES
|Indian good, scottish good, spanish bad, italian mixed (one voice very cartoonish "but a now") other bad, french bad, british good, german ok, japanese the best. South american good, ukrainian good.
|excited good, scared good
|(hums) +(murmurs) +
(sighs)
(sobs) +
(grunts)
(whinces) +
(moans) -
(babbles) +
|Young so so, Old ok
|Raspy so so
|YES
|-
|ElevenLabs
|YES
|Indian so so , scottish so so, spanish bad, italian bad, french zero, british bad, german zero, japanese zero, chinese zero, south american zero, ukrainian zero.
|excited good, sad good, scared zero.
|
|Young good, Old good
|Raspy so so
|YES
|-
|Hume AI
|YES
|tried ukraine, france, spanish, german, all basically zero.
|
|
|
|
|YES
|-
|Replica Studios
|Partially, starts from prompt, but then seems to just mix existing voices
|
|
|
|
|
|
|-
|PlayHT
|NO, only predefined
|
|
|
|
|
|
|-
|Murf.ai
|NO, only predefined
|
|
|
|
|
|
|-
|Lovo.ai
|NO, only predefined
|
|
|
|
|
|
|-
|minimax.io/audio
|NO, only predefined
|
|
|
|
|
|
|}