********************************************************************************
"SkillMUD" technology preview release 1
This file last updated: 7/1/2004 4:05AM
SkullMUD is developed by Jeremy Hill <jeremyhill@cox.net> (Tamraine)
Area files and some help files by other SkullMUD developers

This codebase has been developed on and off since approximately 1/23/04.
********************************************************************************
Evaluating SkullMUD:

Here's a hands-on tutorial on how to see how various systems work in-game.
Log in to the game using 'Admin' (password: admin) and follow the
instructions below.

********************************************************************************
Skill system:
- Type 'skills' to get a listing of skills in the game.
- 'Skedit 0' to edit the 'Skull' skill.
- Feel free to change parameters as desired.

Adding a new skill:
- Type 'skedit add <name of skill>.  NOTE: At the moment, skedit does not
  handle skill names with spaces.  It will in a later version.
- Find the skill in 'skills' and edit it.
------------------------------------------
Here's a pretend skill named 'stickyfire' (think napalm):

skedit add stickyfire
<30000hp 50c 50e 50f 50l 274mv> skedit add stickyfire
argument: stickyfire
Skill added.  Use skedit <number> to edit it.
...set some parameters...
Skillbuilder> 
 1. [nam] Name of skill [locked]: stickyfire
 2. [mag] Type of magic: elemental
 3. [lvl] Level of magic required: 4
 4. [tar] Valid skill targets: 2
 5. [fla] Skill flags: 0
 6. [cos] Base cast costs[6]: 0 500 0 0 0 0 
 7. [ukc] Upkeep costs per upkeep round[6]: 0 1000 0 0 0 0 
 8. [lag] Readiness lag (RT seconds): 2
 9. [las] Base last seconds: 10
10. [upk] Upkeep time: 1
--------------------------------------------------------------------------------
---Messages---
11. [mself] Wear-off message (self): The sticky fire burning your flesh finally dissipates.
12. [mroom] Wear-off message (room): The fire immolating $n finally extinguishes itself.
13. [mupk] Upkeep message (self): 
14. [mpuls] Pulse message (self): The fire stuck to your flesh continues to burn you!
--------------------------------------------------------------------------------
---Skill Prerequisites---
<list of other named skills added here, e.g. 'haste'>
--------------------------------------------------------------------------------
15. [code] Custom code for: Cast? Yes Pulse? Yes Upkeep? No Expire? No
Hit a number plus its corresponding arguments to change a field.
Example: 
> 2 chi
Hit ? to view this skill again, or enter Q or X to quit.
Skillbuilder> 

Some info here:
1) The name of the skill.
    --stickyfire, locked.

2) Type of magic.  Look at magic_table[] in const.c for a list.
    --for stickyfire: elemental

3) What's the learned level of magic required to cast?  <Not implemented>

4) What are the valid targets? self, enemy only, etc.  <not implemented>
    --Take a look in merc.h (TARGET_IGNORE block) to see what targets
      will eventually do.
    
5) Various skill flags.  <not implemented>

6) The cost to just cast the spell.  Example:
Skillbuilder> 6 10 20 30 40 50 60
menu.c 76: Exec_menu called
Foo: 6 Argument: 10 20 30 40 50 60
Skill base costs changed to: 10 chi 20 elemental 30 fae 40 ley 50 combat 60 adventuring 

7) The cost to upkeep the spell, if applicable.
    --In this case, stickyfire is an enemy-only skill.  It is a magical fire
      that will continue to burn only if you continually feed it elemental magic
      to keep it burning.  If you run out of magic after, say, 3 upkeep rounds
      (a round length, in seconds, is defined by setting option 10), the spell
      will expire.

8) The 'lag' associated with casting the skill.  (WAIT_STATE).

9) The base last hours is how many hours the spell will last.
    --That is, if you are the unfortunate target of a stickyfire spell,
      you will be burned every pulse for 10 hours (seconds), provided that
      the caster is able to make their upkeep each round.

10) How often (in seconds) the caster has to pay upkeep.

11) Wear-off message.  When the spell expires, what does the victim see?

12) Wear-off message.  When the spell expires, what does the room see?

13) Upkeep message for the victim, not the caster.  I don't like this, actually;
    I'll be adding in another upkeep field for the caster as well.  Note:
    when the victim is the caster, this will work fine.  But in the case of
    stickyfire here, the caster isn't really informed that he is paying mana
    to keep the spell active.

14) The message the victim receives every game pulse (every second).  Not
    recommended to be used for lengthy spells--quite spammy!

15) Code, only for new skills.  That is, what custom code (if any) will be
    required for this skill?
    -- This requires the most amount of forward-thinking.  If you flag
       a skill to only have custom cast code, the game will not write
       function placeholders for custom expire, pulse, and upkeep.
       You cannot edit the function code online; the game only created
       the placeholders for you.  That is, all you have to do is
       edit the functions in skill_code.c.
       
       If you later decide you DO want custom code for one of those events,
       you'll have to do some hand-editing.
       1) Edit the table in skill_c.include to link up the appropriate 
          functions to the skill.
       2) Declare the new skill functions in skill_code.h.
       3) Write the new skill functions in skill_code.c.
              
If you're happy with the skill, hit 'X' to exit out of skillbuilder and
validate it to write the changes to disk.  If you decide you'd like to
abandon your changes, you can either copyover to flush it from memory
or ignore it. :)
********************************************************************************
Program system:
Nothing much of note to report here yet as developmental resources were
directed elsewhere.  There's mostly only 3 things to try out that'll give
you a fair dose of how tightly programs integrate with the event system:

--Goto 3001 and say 'test'.  This is a very simple program that illustrates
  the usage of the new %percent% ifchecks.  Eventually the program code
  will be entirely rewritten to use percents (and #pounds# for variables,
  but more on that later...)  At the moment percents cannot be nested, such
  as "if %mob.isfighting %actor.name%%".  This will be available at a later date.
  
  Type 'mpdump 3011' to see the actual program code.

  Here's an impartial list of acceptable percents at the moment(mobprogs only):
    .name
        if %mob.name% == hassan
        if %mob.name% == %actor.name%
        if %actor.name% == tamraine
    .short_desc
    .long_desc
    .vnum
        if %mob.vnum% == 3011
    .pos
        if %mob.pos% == standing
    .hp
        if %actor.hp% > 1000
    .sex
    .str
    .int
    .cha
    .con
    .dex
    .reflex
    .will
    .perception
    .gold
    .silver
    .age
    .chi
    .elemental
    .ley
    .fae
        if %mob.fae% > %actor.fae%
    .isusing
        if %actor.isusing weapon%
    .has
        if %actor.has food%
    .isfighting
        if %actor.isfighting%
        if %actor.isfighting 3011%
        if %actor.isfighting hassan%
     
    (these are for mobprogs only, obj and rooms to follow suit later)
  
--Goto 10033 and go north.  Say yes.  This is a more conventional program
  using 'wait' code to delay execution between says. 'mpstat ishiguardian'
  to see a list of programs on this particular mob.

-- Goto 10024.  Make sure you have a fishing pole.  Type 'fish' to fish.   
   Likewise, Goto 2100.  Can fish thereas well.  Have an ice fishing rod handy.
   
--Goto 1991.  If you get struck by arrows, well, that's because the field you
  are standing in surrounds an enemy Stronghold.  The archers in said
  Stronghold aren't fond of your presence here.  But you can get some revenge.
  You can either explore the field for a bit to find a catapult stone or
  simply load some stones (load obj 1922).  Now place the stone into the catapult.
  If you get lucky, you'll score a direct hit on the Stronghold.  Do a
  'at 1943 look' to see the damage you dealt.  Even if the shot is off-target,
  you'll kill some archers--after launching a few stones, do a 'at 1944 look'.
  You'll also notice the stone(s) you have fired are present there.
  
  This program also illustrates the usage of 'cooldown' to keep a person
  from dumping a bunch of stones into the catapult at once.
  
-- Goto 1944.  Try to 'fire ballista'.  If there's a Tryn soldier manning
   it, you'll have to kill him first.  If not, you can fire it.  Have a
   poor unsuspecting newbie stand in room 1996 for a pleasant surprise. :)
   
   This program also illustrates the usage of the 'input' trigger.
   Stat the ballista ('stat ballista') to see the trigger phrase and
   'opdump 1944' to see the oprog code.

********************************************************************************
Secret doors:

--Goto 3160.  As an immortal, you can see the north exit in red.  Looking
  north also gives you the keyword of the door.  Try 'bumping' into the
  door by going north, or try 'open north' or 'unlock north'.  The keyword
  for the door must be known to perform either of those operations.

********************************************************************************
Taglines:

--Set your intelligence to 5. (set char admin int 5)  Goto 2030 and read
  the room description, ignoring the fact that you can see the secret exit.
  Now set your intelligence to 12.  A new line has suddenly appeared in the
  room description!  Examine the tapestry.  Interesting..  Now set your
  intelligence to 15 and look at it again.  Well, another interesting new
  tidbit!  You've learned about some keyhole.  This is just an example
  of how taglines work, not a fully-working area.  Goto 2317 to see
  another example; this room's description changes depending on the time
  of day.  'Help tagline' for more info.
  
********************************************************************************
Events:

--There are many types of events in the game.  In fact, you've probably
  unknowingly been exposed to several already.
  
  --For an affhandle event, type 'report whatever'.  <--don't do, crashes :)
  --For a menu event, use 'skedit'.
  --Type 'events'--the save_event is quietly ticking away in the background.
  --Create a poll (type 'poll') and post it--it'll be handled in a poll event.
  --The programs above uses the prog_event and prog_cooldown_events
    extensively.
  --Add this line of code somewhere : 
    print_event(ch, 10, "Hey, look, %s!  This is a 10-second delayed print event!\n\r", ch->name);
    
  Events are easy and useful!

********************************************************************************
Menus:
--Menus only exists in three areas of the game at the moment:
    1) the 'poll' command uses a menu;
    2) the 'skedit' command uses a menu;
    3) 'list' uses a menu.  (goto 3160 and type 'list').

********************************************************************************

As you can readily see, nothing is polished or even finished.  This 
technology release is provided for developers looking for new ideas. 
                                --Tamraine