Difference between revisions of "Manual:DIL Changes"

From DikuMUD Wiki
Jump to navigation Jump to search
m (Minor changes to test wiki sync.)
 
(14 intermediate revisions by one other user not shown)
Line 1: Line 1:
−
===== ''Temp list of changes. Will reorganize once I see what all we have.
+
===== ''Temp list of changes. Will reorganize once I see what all we have.'' =====
−
'' =====
 
  
 
== Priority ==
 
== Priority ==
Line 14: Line 13:
 
Let's look at a Midgaard town guard, a quick wstat guard func shows:     
 
Let's look at a Midgaard town guard, a quick wstat guard func shows:     
  
−
dilcopy rescue@function("guard/captain/mayor");  
+
#dilcopy rescue@function("guard/captain/mayor");
−
dilcopy arrest_check@midgaard("accus_room@midgaard");  
+
#dilcopy arrest_check@midgaard("accus_room@midgaard");      
−
dilbegin SFUN_PROTECT_LAWFUL time PULSE_SEC*60 bits SFB_RANTIME  
+
#dilbegin SFUN_PROTECT_LAWFUL time PULSE_SEC*60 bits SFB_RANTIME      
−
dilbegin guard2();  
+
#dilbegin guard2();      
  
 
In this example, the priority belongs to rescue. Therefore the expected behavior is that this guard will prioritize rescuing someone they see being attacked before rushing off to enforce peace or arrest someone. Secondarily, if rescuing is not an active option, the guard will arrest someone before trying to keep the peace.  
 
In this example, the priority belongs to rescue. Therefore the expected behavior is that this guard will prioritize rescuing someone they see being attacked before rushing off to enforce peace or arrest someone. Secondarily, if rescuing is not an active option, the guard will arrest someone before trying to keep the peace.  
 
If the guard is interrupted in the middle of the execution of guard2(); above, the guard2(); program will simply pause until the higher priority dils are completed.
 
If the guard is interrupted in the middle of the execution of guard2(); above, the guard2(); program will simply pause until the higher priority dils are completed.
−
In prior DIKU versions, there was no way to determine the dil insertion point on an object and therefore no way to predictably control execution order.  
+
In prior DIKU versions, there was no way to determine the dil insertion point on an object and therefore no way to predictably control execution order. So we introduce the following:
 +
 
 
{| class="wikitable"
 
{| class="wikitable"
 
|-
 
|-
Line 42: Line 42:
 
| FN_PRI_MISSION || 30 || Sent on an important mission
 
| FN_PRI_MISSION || 30 || Sent on an important mission
 
|-
 
|-
−
| FN_PRI_CHORES || 40 || Picking up gargabe or eating rabbits.  
+
| FN_PRI_CHORES || 40 || Picking up garbage or eating rabbits.  
  
 
|}
 
|}
Line 50: Line 50:
 
dilbegin unique programName();
 
dilbegin unique programName();
  
−
This unique flag or keyword works to ensure that a unit will never have more than one of that function available on the object at any given time. This is a great way to cut down on the length of new dils because instead of having to do an if(dilfind) every time, you can simply use the unique flag. For example, if you create an entangle spell, and want to have a DIL that can be copied onto char's affected by entanglement, then the unique flag makes sure that even if the spell was cast twice on the same char, there would be only one instance of the entangle DIL running on that char.
+
This unique flag or keyword works to ensure that a unit will never have more than one of that function available on the object at any given time. This is a great way to cut down on the length of new dils because instead of having to do an if(dilfind) every time, you can simply use the unique flag. For example, if you create an entangle spell, and want to have a DIL that can be copied onto char's affected by entanglement, then the unique flag makes sure that even if the spell was cast twice on the same char, there would be only one instance of the entangle DIL running on that char.  
 +
 
 +
== Built-in Player DIL Commands ==
 +
Three are three new commands implemented for players (in DIL).   
 +
* alias
 +
* trigger
 +
* variable 
 +
 
 +
Many of you will recognize these as components of mud clients like zmud/cmud/mudlet etc. 
 +
This change makes muds a little more accessible by presenting the mud in a web form while still allowing for some of the basic automations found in clients.
 +
 
 +
=== Alias ===
 +
{| class="wikitable"
 +
|-
 +
! alias !! arbitrary name !! commands !! result
 +
|-
 +
| alias || fido || goto fido;tell fido hello;pet fido || travel to fido. You tell Fido Hello. You pet Fido
 +
|-
 +
| alias || tf || tell fido $1 || You tell Fido Hi
 +
|-
 +
| alias || tf || tell fido $0 || You tell Fido a whole string of stuff.
 +
|}
 +
{| class="wikitable"
 +
|-
 +
! pointer !! use
 +
|-
 +
| $0 || Entire string
 +
|-
 +
| $1 || 1st Word
 +
|-
 +
| $2 || 2nd Word
 +
|}
 +
 
 +
=== Variable ===
 +
 
 +
Variables are basically stringlists and can be defined as such:
 +
variable friends papi|john|aja|bruce|cityguard|the janitor
 +
To recall a variable for use in a trigger, you will notate it as (@variablename) or in this example (@friends). This is recalled in the example below.
 +
 
 +
=== Trigger ===
 +
If you want to do whatever the beastly Fido tells you to do: 
 +
 
 +
$trigger obey /^the Beastly Fido tells you '(.+?)'/ $1 
 +
 
 +
Or maybe you'd like to   
 +
 
 +
$trigger smarmy /^(@friends)\sleaves (.+?)\.$/ say I love $1. Especially when $1 leaves $2.
 +
 
 +
You may notice this is written with Regular Expressions. If you're not familiar or want to learn more: [https://regexr.com/ RegEx Reference]

Latest revision as of 03:33, 19 July 2020

Temp list of changes. Will reorganize once I see what all we have.

Priority

How does a program determine it should run and pause others? When performing a wstat <unit> func command on an object, the dil functions will display in order of priority; top to bottom with most important dils at the top. If a dil program is executing the priority command, it will block all programs below it. Many of the stock game functions call on the priority or FN_PRI to function properly. A few examples of dils that should/do take priority:

  • Death ~ dilbegin recall fnpri(FN_PRI_DEATH) death_seq();
  • Rescue
  • Under Arrest ~ (dilbegin fnpri(FN_PRI_RESCUE-1)arrest_check(office:string);

We'll refer to this concept as 'fnpri'.

Let's look at a Midgaard town guard, a quick wstat guard func shows:

  1. dilcopy rescue@function("guard/captain/mayor");
  2. dilcopy arrest_check@midgaard("accus_room@midgaard");
  3. dilbegin SFUN_PROTECT_LAWFUL time PULSE_SEC*60 bits SFB_RANTIME
  4. dilbegin guard2();

In this example, the priority belongs to rescue. Therefore the expected behavior is that this guard will prioritize rescuing someone they see being attacked before rushing off to enforce peace or arrest someone. Secondarily, if rescuing is not an active option, the guard will arrest someone before trying to keep the peace. If the guard is interrupted in the middle of the execution of guard2(); above, the guard2(); program will simply pause until the higher priority dils are completed. In prior DIKU versions, there was no way to determine the dil insertion point on an object and therefore no way to predictably control execution order. So we introduce the following:

vme.h#define Integer Comment
FN_PRI_RES 0 Don't use
FN_PRI_SYS 1 functions dealing with death
FN_PRI_DEATH 2 functions dealing with death
FN_PRI_BODY 5 gaining hits, etc
FN_PRI_COMBAT 10 in-combat moves
FN_PRI_RESCUE 20 Rescue someone rather than passing by
FN_PRI_BLOCK 25 Blocking things like commands
FN_PRI_MISSION 30 Sent on an important mission
FN_PRI_CHORES 40 Picking up garbage or eating rabbits.

The 'Unique' DIL Flag

In DIKU III, we introduce the unique flag in a dil program. dilbegin unique programName();

This unique flag or keyword works to ensure that a unit will never have more than one of that function available on the object at any given time. This is a great way to cut down on the length of new dils because instead of having to do an if(dilfind) every time, you can simply use the unique flag. For example, if you create an entangle spell, and want to have a DIL that can be copied onto char's affected by entanglement, then the unique flag makes sure that even if the spell was cast twice on the same char, there would be only one instance of the entangle DIL running on that char.

Built-in Player DIL Commands

Three are three new commands implemented for players (in DIL).

  • alias
  • trigger
  • variable

Many of you will recognize these as components of mud clients like zmud/cmud/mudlet etc. This change makes muds a little more accessible by presenting the mud in a web form while still allowing for some of the basic automations found in clients.

Alias

alias arbitrary name commands result
alias fido goto fido;tell fido hello;pet fido travel to fido. You tell Fido Hello. You pet Fido
alias tf tell fido $1 You tell Fido Hi
alias tf tell fido $0 You tell Fido a whole string of stuff.
pointer use
$0 Entire string
$1 1st Word
$2 2nd Word

Variable

Variables are basically stringlists and can be defined as such: variable friends papi|john|aja|bruce|cityguard|the janitor To recall a variable for use in a trigger, you will notate it as (@variablename) or in this example (@friends). This is recalled in the example below.

Trigger

If you want to do whatever the beastly Fido tells you to do:

$trigger obey /^the Beastly Fido tells you '(.+?)'/ $1

Or maybe you'd like to

$trigger smarmy /^(@friends)\sleaves (.+?)\.$/ say I love $1. Especially when $1 leaves $2.

You may notice this is written with Regular Expressions. If you're not familiar or want to learn more: RegEx Reference

Retrieved from "http://wiki.dikumud.net/index.php?title=Manual:DIL_Changes&oldid=629"