------------------------------------------------------------------------------
Spellcasting                                     using the spellcasting system
                                                           Starhound 3/30/2017
------------------------------------------------------------------------------

    This file outlines and describes concepts related to proper and
balanced spell formulation utilizing the new spellcasting system
standards.

    Note: some functions and constructions are too long to
have a single line due to the 80 character width limitation
on man pages.  If this happens, the function will be broken
into two lines, the bottom being indented four spaces forward.

[ General Concepts ]

    Parts of a spell are broken into sections which are defined as
spell steps.  In each step, the caster performs or initializes a
telesmatic process, eventually building up to a specific effect.
Each of these steps can vary greatly in ways one can construct
and formulate them, you have entire control of how the
spellcasting process acts during the time of the step.  This
amount of control offers the highest degree of customization
from not only step to step, or spell to spell, but affiliation to
affiliation.  However, as a draw back, some methods used
to utilize this spellcasting system might not be instantly
obvious.

[ File Inheritance ]

   All spells must include the following header files :

	#include <Project_Name.h>
	#include <daemon.h>
	#include <spell_step.h>
	#include <spellcasting_process.h>
	#include <spells.h>

    As well as the Spell.c definition file located in the /def
folder in the project. Which appears directly under the
section of the file we include the list of header files.

	inherit Project_Example_Definition(“Spell”);

[ Overloading Functions ]

    Before you initialize the spellcasting process, you
might want specific control on things like, what the
spell can be cast on, to check the target(s) of a
spell to ensure they’re valid, or if the
caster is using a valid spell argument or component.
Specific and detailed usage of these functions will be
described later, but for now you must overload the
necessary functions to your spell construction, usually
placed directly under the line of where you defined
the spell file inheritance.  Only spell_complete is
needed for the most basic of attack spells, as there
are methods to filter out valid and invalid times
one can cast spells with the usage of flags.  Note
that you only need overload the functions that your
spell will utilize.

Examples:

    inherit Project_Example_Definition(“Spell”);

    void spell_complete(descriptor process);

    varargs mixed spell_check_components_rule(object array components,
        object who, status initial);

    mixed spell_check_targets_rule(object array targets, object who,
        status initial);

    object array spell_generate_default_targets_rule(object who);

    varargs mixed spell_check_arguments_rule(mixed arguments,
        object who, status initial);

    Methods like automatically generating component usage
can also be performed, however it is generally discouraged as
using default targeting can allow us to prevent the caster from
also specifying targets.  It is also worth mentioning that keeping a
consistent naming scheme for these functions is moderately desired,
as it allows other developers to easily understand your spell and its
processes.

[ Configure ]

    A good portion of the code for a spell is placed on configure(),
this is where we define spell steps and other key spell settings.
The following sections marked with double brackets are all
settings and concepts housed in configure on a spell.

[[ Spell Names ]]

    For hermetic spellcasters, all spells must have two separate
names. A regular spell name which must be pronounced in Latin,
and a common spell name, written in plain English.  It is best
practice to define these values first.

Example:

void configure() {
    ::configure();
    set_spell_name(“magicae telum”);
    set_spell_common_name(“magick bolt”);
}

[[ Spell Types ]]

    Each spell must be categorized into an overall generic
class dependent upon the spells’ effect.  Usually common
sense plays a large factor here, if the spell fires off only a
special attack, it is an “attack” spell, or if the spell only adds
some form of enchantment to an object, it is an “enchantment”
spell.  This function simply takes a string as a argument, the
string being the specified spell type.

Example:

	set_spell_type(“attack”);

[[ Spell Summary ]]

    A brief description of the spell, usually no longer
than a handful of words

Examples:

    set_spell_summary(“magickal dart attack”);

[[ Spell Targets/Components/Arguments Flags ]]

    These three aspects of a spell can have predefined
flags set for them as a method to impose restrictions
on how the caster can use these parts of the system.
Typically defined after the spell type as they are the
foundation for how a spell can be cast.

Examples:
	//will require the target to be the caster or a object that is
	//befriended to the caster
	set_spell_targets_flags(Spell_Targets_Flags_Single_Friendly);

	//will require the caster to specify a single, common object contained
	//in their inventory to cast the spell
	set_spell_components_flags(Spell_Components_Flags_Single_Mundane_Inventory);

	//will require the caster to specify arguments for the spell
	set_spell_arguments_flags(Spell_Arguments_Flag_Required);

    The following list describes all the possibilities one can have in these
fields.

Spell_Components_Flag_Inventory
Spell_Components_Flag_Environment
Spell_Components_Flag_Magickal
Spell_Components_Flag_Mundane
Spell_Components_Flag_Single
Spell_Components_Flag_Equipped
Spell_Components_Flag_Unequipped
Spell_Components_Flag_Static
Spell_Components_Flag_Indestructible
Spell_Components_Flag_Required
Spell_Components_Flag_None
Spell_Components_Flag_Reacquire
Spell_Components_Flag_Track
Spell_Components_Flag_Nonmanifestation
Spell_Components_Flags_Single_Mundane_Inventory

Spell_Targets_Flag_Inventory
Spell_Targets_Flag_Environment
Spell_Targets_Flag_Living
Spell_Targets_Flag_Nonliving
Spell_Targets_Flag_Single
Spell_Targets_Flag_Nonself
Spell_Targets_Flag_Equipped
Spell_Targets_Flag_Unequipped
Spell_Targets_Flag_Friendly
Spell_Targets_Flag_Hostile
Spell_Targets_Flag_Static
Spell_Targets_Flag_Indestructible
Spell_Targets_Flag_Required
Spell_Targets_Flag_None
Spell_Targets_Flag_Reacquire
Spell_Targets_Flag_Track
Spell_Targets_Flag_Handle_Automatically
Spell_Targets_Flag_Trusting
Spell_Targets_Flags_Single_Friendly
Spell_Targets_Flags_Single_Friendly_Exclude_Self
Spell_Targets_Flags_Single_Trusting
Spell_Targets_Flags_Single_Trusting_Exclude_Self
Spell_Targets_Flags_Single_Hostile
Spell_Targets_Flags_Environment_Nonliving

Spell_Arguments_Flag_None
Spell_Arguments_Flag_Required
Spell_Arguments_Flag_Optional

    Should you wish to combine multipule flags from the same
category, simply:

set_spell_targets_flags(Spell_Targets_Flag_Single |
    Spell_Targets_Flag_Required);

    But always attempt to use the predefined combination flags if applicable.

[[ Spell Check Rules ]]

    Once the flags have been defined for a spell,
you will then want to ensure that objects or arguments
considered valid are checked in more depth before
determining if the spellcasting process should be
performed or not.  This is where the overloaded
functions defined earlier are linked to the spellcasting
system to determine how a spell should check
valid objects passed to it.  How to create these
functions will be explained later, but for now
right under the flags is the best place to define them.

Examples:

	set_spell_check_targets_rule(#’spell_check_targets_rule);
	set_spell_check_arguments_rule(#’spell_check_arguments_rule);
	set_spell_check_components_rule(#’spell_check_components_rule);

    These processes are defined as closures then passed to the spellcasting
system, which calls the defined functions before conducting the spellcasting
process itself.  Greater detail about how to formulate these functions will
be found after we finish the rest of configure().

[[ Spell Help ]]

    This is where a large portion of the individual spell help
file is contained, as a general rule of thumb, this setting
should typical contain no less than two complete sentences.

Examples:

set_spell_requirements_description(
    "One of the more common enchantments from the time "
    "of the orignal White Order was to shift the very essence of "
    "ones' spirit to the elemental qualities of snow.  Doing so results "
    "in various physical side effects for the student, most notablly "
    "the ability to pass  through ones enviornment at will, "
    "and also introduces a form of weakness to several magickal manipulations."
);

    Notice how the setting is one complete string, using spaces at
the end of each line and a double space at the start of a new sentence.
Some ideas to consider when creating a spell help setting:

    Why does the spell have that name?
    How was the spell discovered?
    Who discovered the spell?
    Why does the spell work the way it does?
    Are there any side effects of the spell?

[[ Spell Knowledge Requirements ]]

   This is the section for formulating a condition
descriptor to check if the caster has knowledge of a
spell or not.  You can use all available settings and
configurations of a normal condition descriptor here,
most usually however these are skill based.

Examples:

set_spell_knowledge_requirement(([
    Condition_Type_Code             : Condition_Type_Total,
    Condition_Value                 : 300,
    Condition_Info                  : ({
        ([
        //1:1 ratio
            Condition_Type_Code     : Condition_Type_Skill,
            Condition_Info          : Skill_Aretophrasty,
        ]),
        //1:1 ratio
        ([
            Condition_Type_Code     : Condition_Type_Skill,
            Condition_Info          : Skill_Arcane_Lore,
        ]),
        //1:1 ratio
        ([
            Condition_Type_Code     : Condition_Type_Skill,
            Condition_Info          : Skill_Metaphysics,
        ]),
        //1:0.25 ratio
        ([
            Condition_Type_Code     : Condition_Type_Skill,
            Condition_Info          : Skill_Evocation,
            Condition_Value         : 0.25,
        ]),
        //1:0.25 ratio
        ([
            Condition_Type_Code     : Condition_Type_Skill,
            Condition_Info          : Skill_Cryoturgy,
            Condition_Value         : 0.25,
        ]),
    }),
}));

[[ Spell Incantation Step ]]

   For all hermetic spellcasters, each spell must
be started with an incantation step.  Spells can
contain more than a single incantation, and
generally never more than a single incantation
in a row.  Due to the wide spread use of incantation
steps, it is standard to factor this step out entirely,
altering the default configurations defined by
Spell.c when needed.  By default, the speech
content of an incantation step is set to the
spell common name, meaning for additional
incantation steps you must override some
default values.

Examples:

//default step
add_spell_step(spell_incantation_step());

//secondary incantation
add_spell_step(spell_incantation_step(([
    Spell_Step_Order            : foo, //where foo == some integer
    Spell_Step_Speech_Content   : “bar”,
])));

    There is a great deal of customization regarding
incantation steps, from the language used, to the quote
styles the caster has during the incantation.  The available
values to use in this step are:

Spell_Step_Language
Spell_Step_Speech_Command
Spell_Step_Speech_Content
Spell_Step_Speech_Quote_Style

    Other settings available in all spell steps, like
settings for costs or activity are also available, these
are just the ones specific to speech based steps.

   From here on, topics surrounded by triple brackets
are classified for values and settings that specifically
apply to add_spell_step().

[[[ Spell Step General Concepts ]]]

   Each time a spell step is added, a mapping
containing key values and settings must be passed
as an argument to add_spell_step().  Unless there
is great reason not to, we define this mapping
by hand for each step.  As stated above, one
reason not to do such a thing was for the incantation
step, or if you have a handful of spells which will all
use a similar step, it can generally be worth factoring
out with its own inheritable for the various spells.

[[[ Spell Step Order ]]]

    The first value which should be defined in the
spell step mapping, this setting arranges the order
in which the spellcasting system executes spell
steps.  For maintenance and standardization reasons,
all your spell steps should be defined in ascending
order down.

Examples :

add_spell_step(([
    Spell_Step_Order     : 2,
]));

    Doing this now specifies that said step is the second
step in the spell, and any containing code or values will
not be executed or formulated until the spellcasting process
reaches the second step.   Spell step order must be defined
for each step.

[[[ Spell Step Descriptions ]]]

    This is where the name for the spell step is defined, and
is used by the system for things like skipping steps, or the
help files for spells which list step descriptions and skills.
Usually kept to a few words, this string should give a basic
overview of what the step is doing.

Examples:

add_spell_step(([
    Spell_Step_Order         : 2,
    Spell_Step_Description   : “manifesting the required energy”,
]));

    Now, if the caster has verbose spellcasting enabled, when they complete
above step the result of the step performance and the step description will be
displayed such as:

    Your performance in manifesting the required energy was perfect.

If the spell step was skippable, the caster could cast the spell via:

    cast spell without manifesting the required energy

    And the spellcasting system would automatically remove the
step from this instance of the spellcasting process conduction,
handling the adjustments for cost and difficulty automatically.

[[[ Spell Step Activity ]]]

  How much activity performing the individual spell step costs,
defined as a integer.

Examples:

add_spell_step(([
    Spell_Step_Order           : 2,
    Spell_Step_Description     : “manifesting the required energy”,
    Spell_Step_Type_Code       : Spell_Step_Type_Gesture,
    Spell_Step_Activity        : 20,
]));

[[[ Spell Step Required ]]]

    A value which can be True or False depending upon
if the step can be skipped or not.

Examples:

add_spell_step(([
    Spell_Step_Order           : 2,
    Spell_Step_Description     : “manifesting the required energy”,
    Spell_Step_Type_Code       : Spell_Step_Type_Gesture,
    Spell_Step_Activity        : 20,
    Spell_Step_Required        : False,
]));

[[[ Spell Step Difficulty ]]]

    How difficult a spell step is, each step will have skills
defined in a mapping with how much of the skill is used to
get an overall combined value, which is checked against
the set step difficulty.  The following values for spell step
difficulty are as followed:

(Per Step)
Difficulty      Min     Max
None            0       0
Very Easy       0       110
Easy            55      220
Moderate        110     330
Hard            165     440
Very Hard       220     550

Examples:

add_spell_step(([
    Spell_Step_Order           : 2,
    Spell_Step_Description     : “manifesting the required energy”,
    Spell_Step_Type_Code       : Spell_Step_Type_Gesture,
    Spell_Step_Activity        : 20,
    Spell_Step_Required        : False,
    Spell_Step_Difficulty      : Spell_Step_Difficulty_Easy,
]));

[[[ Spell Step Importance ]]]

   How important a step is to the overall spellcasting process.
Used to determine the overall performance of a spell by taking the
weighted average of each step against the value of step importance.

  Skipping steps which have importance set will offset the spell step
cost and overall difficulty values of the spell.  The current importance
values and their adjustments are as follows:

Skipped Step Difficulty Modifier
Importance      Min     Max
None (1)        0       0
Minor (2)       10      25
Lesser(3)       20      50
Major (4)       30      75
Greater (5)     40      100
Great (6)       50      125
(cost adjust only affects energy costs, not difficulty)

Examples:

add_spell_step(([
    Spell_Step_Order           : 2,
    Spell_Step_Description     : “manifesting the required energy”,
    Spell_Step_Type_Code       : Spell_Step_Type_Gesture,
    Spell_Step_Activity        : 20,
    Spell_Step_Required        : False,
    Spell_Step_Difficulty      : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance      : Spell_Step_Importance_Minor,
]));

[[[ Spell Step Skip Cost Adjust ]]]

    A float used to modify the cost of a step based on if the step
is skipped of not, this setting can only be used if the spell step
is not required.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    //1.5x the cost of the step if skipped
    Spell_Step_Skip_Cost_Adjust : 1.50,
]));

[[[ Spell Step Skills ]]]

  The field of a spell step containing a mapping of all
the skills used in the step along with their ratios at
which the skill is counted.  The amount of skills used
along with the ratios are which each skill is counted is
heavily dependent upon the difficulty and importance of
a step.  Spell step skills, difficulty and importance are
the three most vital settings to spell balance.  Most often
easier steps should contain 3-4 different skills, at least
one of which at a 1:1 ratio, for slightly mid-tier spells
at around the moderate difficulty, 3-5 skills should be
used, with two of which at a 1:1 ratio.  Lastly, for the
most difficult of spells, 4-5 skills should be used,
two with a 1:1 ratio and a third with an almost complete
ratio, around 1:0.75.

    As an additional note, any spell steps using the gesture
spell step code must contain Skill_Prestidigitation, at an
extremely reduced ratio, usually 1:0.10, to 1:0.25.  This
is because we have standardized the usage of the prestidigitation
skill to be related with the act of performing gestures in spells.
If the spell step requires drawing or tracing a rune, you can use
Skill_Drawing or Skill_Calligraphy in conjunction  with Skill_Rune_Lore
instead of, not in addition to, prestidigitation.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    Spell_Step_Skip_Cost_Adjust : 1.50,
    Spell_Step_Skills           : ([
        Skill_Thaumaturgy       : 1.00,
        Skill_Evocation         : 0.75,
        Skill_Prestidigitation  : 0.20,
    ]),
]));

[[[ Spell Step Fumble Threshold ]]]

    Specifies a minimum performance that must be meet to
complete a spell step.  Fumbled steps can also have control
over specialized messages or damage types the said step will
cause if fumbled. The current options for adding fumble
support to spell steps are as follows:

Spell_Step_Fumble_Message
Spell_Step_Fumble_Damage_Type

    Both of the settings above are not directly required in
the formulation of a spell, however they can add depth
and more customization of the spellcasting process.

[[[ Spell Step Costs ]]]

    This value holds arrays defined for energy costs
of a given step.  Each step can hold multiple types of
energy costs, usually the cost of the step has some
dependence upon the difficulty of the step, overall
goal of the spell, and even how many steps are in the
spell entirely.  A good rule of thumb is to determine how
much energy total a spell will require, then figure out how to
best break up that cost among the spells individual steps.  This
is also where we can set the option to allow the spellcasting
process to automatically convert energy for the caster if
needed, or directly require that the energy be already present
at the time of casting.  If one picks the latter of the two options
and the caster does not have the required energy to complete the
step costs, the spell will fail, where-as if the former options is chosen
the system will attempt to convert spiritual energy into the desired
energy, ending in failure if the caster does not have the needed energy
to convert as well.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    Spell_Step_Skip_Cost_Adjust : 1.50,
    Spell_Step_Skills           : ([
        Skill_Thaumaturgy       : 1.00,
        Skill_Evocation         : 0.75,
        Skill_Prestidigitation  : 0.20,
    ]),
    Spell_Step_Costs            : ({
        //this step costs 10 magickal energy, 15 if it is skipped.
        ({ Energy_Magickal, 10.0 }),
    }),
]));

[[[ Spell Step Limbs Required ]]]

    An int array which specifies which limbs the caster must have
to perform the step.  For gestural spells, the caster must use at least
one hand.  If the planned step has a message that requires two hands,
then obviously two hands must be required.  This value allows us to
easily reference all or specific limbs used in the step when it is time
to construct the spell messages.

    Spells steps that are thoughts, speech content, vocalizations,
or passive events have no use for this setting.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    Spell_Step_Skip_Cost_Adjust : 1.50,
    Spell_Step_Skills           : ([
        Skill_Thaumaturgy       : 1.00,
        Skill_Evocation         : 0.75,
        Skill_Prestidigitation  : 0.20,
    ]),
    Spell_Step_Costs            : ({
        ({ Energy_Magickal, 10.0 }),
    }),
    //performing this step requires the caster to have 2 functioning hands.
    Spell_Step_Limbs_Required   : ([
        Limb_Type_Hand          : 2,
    ]),
]));

[[[ Spell Step Message/Display ]]]

    For this field, we can specify a message or display to be performed
at the time of the spell step.  Spells that use the gesture type code should
always contain at least a Spell_Step_Message, while Display is generally a
optional setting that can add some depth and pad the length of a spell.

    Spell_Step_Display is a more used setting for spell steps which
have thoughts or vocalization type codes, as with it you can display
messages to the caster about their senses or emotions.

    To be able to construct proper spell step messages, we first have to
understand how the spellcasting system allows us to define specific
objects in the message.  This is done by the core system using a
replacement styled function to let us reference objects or limbs
inside Message_Content.

The list of options are as follows:

“%caster”
“%targets”
“%target”
“%target_or_self”
“%components”
“%component”
“%arguments”
“%argument”
“%limbs” //will reference all the limbs or single limb if only one is required.
“%limb_1” //will reference the first limb if more than one is required,
this can be repeated up the N amount of limbs required. Such as,
“%limb_2”, ect.

    It is usually best practice to nest another message within the first,
one part showing the gesture or actions the caster performs visually,
and a secondary message showing a brief effect of the telesmatic
process for those with astral perception.  This is not required, but
does add depth to the spell.  Spells can also nest other forms of
messages, such as for auditory or thermal based messages.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    Spell_Step_Skip_Cost_Adjust : 1.50,
    Spell_Step_Skills           : ([
        Skill_Thaumaturgy       : 1.00,
        Skill_Evocation         : 0.75,
        Skill_Prestidigitation  : 0.20,
    ]),
    Spell_Step_Costs            : ({
        ({ Energy_Magickal, 10.0 }),
    }),
    Spell_Step_Limbs_Required   : ([
        Limb_Type_Hand          : 2,
    ]),
    Spell_Step_Message          : ([
        Message_Content         : ({
            "%caster", ({ "wave", "%caster", "%limbs" }), "through",
            ({ 't', Description(Description_Type_Ambient_Medium_Colored_Name) }),
            "gently",
            Message(([
                Message_Content : ({
                    "as", 'a', self_color("auroric", 0, 0, False, "haze of energy"),
                    "falls upon the surrounding area",
                }),
                Message_Senses  : Message_Sense_Astral,
            ])),
        }),
        Message_Senses          : Message_Sense_Visual |
                                 Message_Sense_Kinesthetic_For_Participants,
    ]),
]));

[[[ Spell_Step_Do_Call ]]]

    Accepts a closure pointing to what function the spell step
should call at step completion.  Most usually for calling
spell_complete() on the last step of the spell.  Should be
defined last in the step as it signifies that the step itself is
almost finished.

Examples:

add_spell_step(([
    Spell_Step_Order            : 2,
    Spell_Step_Description      : “manifesting the required energy”,
    Spell_Step_Type_Code        : Spell_Step_Type_Gesture,
    Spell_Step_Activity         : 20,
    Spell_Step_Required         : False,
    Spell_Step_Difficulty       : Spell_Step_Difficulty_Easy,
    Spell_Step_Importance       : Spell_Step_Importance_Minor,
    Spell_Step_Skip_Cost_Adjust : 1.50,
    Spell_Step_Skills           : ([
        Skill_Thaumaturgy       : 1.00,
        Skill_Evocation         : 0.75,
        Skill_Prestidigitation  : 0.20,
    ]),
    Spell_Step_Costs            : ({
        ({ Energy_Magickal, 10.0 }),
    }),
    Spell_Step_Limbs_Required   : ([
        Limb_Type_Hand          : 2,
    ]),
    Spell_Step_Message          : ([
        Message_Content         : ({
            "%caster", ({ "wave", "%caster", "%limbs" }), "through",
            ({ 't', Description(Description_Type_Ambient_Medium_Colored_Name) }),
            "gently",
            Message(([
                Message_Content : ({
                    "as", 'a', self_color("auroric", 0, 0, False, "haze of energy"),
                    "falls upon the surrounding area",
                }),
                Message_Senses  : Message_Sense_Astral,
            ])),
        }),
        Message_Senses          : Message_Sense_Visual |
                                  Message_Sense_Kinesthetic_For_Participants,
        ]),
    Spell_Step_Do_Call          : #'spell_complete,
]));

    Congratulations, you should know have a basic understanding
of how spell steps should be formulated and the various settings
and options within them.  Now, we’ll talk about what comes
after configure().

[ Spell Check Targets Rules ]

    Remember those functions we overloaded near the top of
the file, then used as closures near the top of configure() ?
Well, directly under configure() is where we define and place
these functions.  Initially, all the targets of a spell are kept in
an object array, even if the target is only a single object.  For
spells which have a single target, first define the target object
as the first value in the targets object array.

   After this, we can now check the target object for various
statuses or results to ensure it’s valid for the spell to be cast
upon should the spell targeting flags determine the target to be
valid.  The types of checks performed will vary greatly spell
by spell.  Here is where you check for things like, is the target
undead, do they already contain a copy of the enchantment the
spell generates, or pretty much any other bit of information
contained on the object.  For a spell to be cast, this function
must return True.  If it’s determined that the target object
defined is not a valid target for whatever reason, use the
Error() function along with a string array explaining why
the target is not valid to the caster.

Examples:

mixed spell_check_targets_rule(object array targets,
    object who, status initial) {
    //for single target spells, define the single target object from the
    //target object array
    object target = targets[0];
    //checks if the target has the capability for emotions, returns True if so,
    //or a error if not.
    if(!target->sentience()->query_sentience_emotion())
        return Error(({
            ({ 't', target }), ({ "are", target }),
            "devoid of emotions so you are unable to augment",
            ({ 'r', target, "feelings" })
        }));
    return True;
}

[ Spell Generate Default Targets Rules ]

    Generates a target object array by default, values
returned must be an object array and fit the conditions
of the defined target flags.  Extremely useful for spells
that should target the caster by default, or target
all the junk items in a room by default.  When using
this function in conjunction with the
Spell_Targets_Flag_Handle_Automatically
the spell in question will attempt to locate targets
by default while preventing the caster from specifying
additional targets entirely.

Examples:

//will specify the caster by default
object array spell_generate_default_targets_rule(object who) {
    return ({ who });
}

    Any other formulation of targets that can be located
and derived from the caster object, or defined from
outside methods can be used here.

[ Spell Check Arguments Rule ]

    By default, the spellcasting system can handle
multiple spell arguments for a single spell, so it places
all the arguments used into a mixed value.  The individual
arguments are housed within as strings, and for spells which
only accept one argument, pulling the single argument from the
mixed value and then checking it against a defined list of
valid strings is acceptable.   Just as the targets rule, this
function must return either True or an Error().

Examples:

varargs mixed spell_check_arguments(mixed arguments,
    object who, status initial) {
    //for spells with optional arguments
    unless(sizeof(arguments))
        return True;
    //for turning the mixed arguments into a string
    string arg = implode(arguments, "_");
    if(arg == "allowed argument")
       return True;
    return Error(({
        arg, "is not a valid argument for this spell.",
    }));
}

[ Spell Check Components Rule ]

    Checks the component(s) specified during the spellcasting
attempt, checks the object if deemed valid by the components
flags.  Not all spells that use components have to destruct the
component either, however for spells using typical or common
place items with the goal of transforming it into some
new other magickal based item, the component should
be destructed in spell_complete() with a message regarding
the object transformation.  Just as the check targets and arguments
rules, this function must also return True or an Error().

Examples:

varargs mixed spell_check_components_rule(object array components,
    object who, status initial) {
    object component = components[0];
    //if the component is a gemstone, return true, else, return error
    unless(component->query_property(Prop_Gemstone))
        return Error(({
            component, "is not the type of thing that can be ",
            "used as component for this spell",
        }));
    return True;
}

[ Spell Complete ]

    This is what performs the main desired outcome of the spell,
and here you have access to the entirety of the spellcasting process
descriptor and thus all the objects, messages, and values utilized
in constructing the spellcasting process.  Effects from firing off
special attacks, to installing item or personal enchantments all
go here.  Firstly, you must define some objects and values to
pull the most desired information from the spellcasting descriptor.
Then you’re free to manipulate or use these objects at will,
including them in messages, applying modifiers, whatever the
spell does.

Examples:

void spell_complete(descriptor process) {
    //pulls the spellcasting process descriptor
    descriptor s_p = Process_Query_Info(process, "Spellcasting_Process");
    //caster object
    object who = Spellcasting_Process_Query(s_p, Spellcasting_Process_Actor);
    //overall spell performance float.
    float performance = Spellcasting_Process_Query(s_p,
        Spellcasting_Process_Performance);
    //the component object array
    object array components = Spellcasting_Process_Query(s_p,
        Spellcasting_Process_Components);
    //defining single component usage
    mixed component = components[0];
    //targets object array
    object array targets = Spellcasting_Process_Query(s_p,
        Spellcasting_Process_Targets);
    //single target from said array
    object target = targets[0];
    //spell arguments
    string array arg = Spellcasting_Process_Query(s_p,
        Spellcasting_Process_Arguments);
    //single arg
    string args = implode(arg, "_");
    //followed by whatever code or manipulations should be performed after the
    //definition of these values.
}

//simple attack spell_complete
void spell_complete(descriptor process) {
    spell_execute_typical_special_attack(process, ([
        Special_Attack_Type                     : ({ "magick" }),
        Special_Attack_Vector                   : Vector_Dart,
        Special_Attack_Power                    : ({
            Special_Attack_Power_Somewhat_Strong,
            Special_Attack_Power_Very_Strong,
        }),
        Special_Attack_Skill                    : ({
            Skill_Telesmatic_Weapon,
            Skill_Conjuration,
            Skill_Thaumaturgy,
        }),
        Special_Attack_Strike                   : ({ 10, 15 }),
        Special_Attack_From                     : ({ ({ 's', "%caster", "%limbs" }) }),
        Special_Attack_Size                     : Special_Attack_Size_Small,
    ]));
}

//simple enchantment installing on spell_complete
//note that this assumes you check for valid targets not already
//in possession of the enchantment

void spell_complete(descriptor process) {
    descriptor s_p = Process_Query_Info(process, "Spellcasting_Process");
    object array targets = Spellcasting_Process_Query(s_p,
        Spellcasting_Process_Targets);
    object target = targets[0];
    object new_enchantment = new(Project_Name_Misc("enchantment"));
    spell_install_personal_enchantment(process, new_enchantment);
}