MUDprogramy na SWMudzie

Zawartość dokumentu:


Składnia MUDprogramów
Dołączenie MOBprogramu do Moba
A co z OBJprogami i ROOMprogami
Typy Triggerów dla MOBprogów
OBJprogi i ROOMprogi
Typy Triggerów dla OBJprogów
Typy Triggerów dla ROOMprogów
Zmienne
Operacje na zmiennych i przykłady
Sekwencje Sterujące
Operatory
If_Check'i w Instrukcjach Warunkowych
Dodatkowe MOBkomendy
Przykłady



-------------------------Składnia MUDprogramów-------------------------------

Najprostszym sposobem opisania składni jest podanie przykładu, więc oto on.
Najpierw zdefiniujemy notację: wszystko zawarte w nawiasach klamrowych {} 
jest wymagane, wszystko w nawiasach kwadratowych [] jest opcjonalne, 
wszystko w cudzysłowach "" jest ciągiem znaków (case insesitive) który musi 
się w tym miejscu znajdować, NL oznacza wymagane w tym miejscu przejście 
do nowej linii. Oto diagram przedstawiający typowy MOBprogram:

 


     ">" {typ_triggera} " " {lista_argumentów} "~" NL
{komenda_programu_1} NL
{komenda_programu_2} NL
{komenda_programu_3} NL
. . .
{komenda_programu_N} NL
"~" NL

 

Wyjaśnienia:

TYP_TRIGGERA to nazwa jednego z dostępnych triggerów
KOMENDA_PROGRAMU może to być dowolna komenda muda (chat, kill itp.), 
albo komenda sterująca (o nich później)
LISTA_ARGUMENTÓW zależy od triggera, ale zawsze jest przekazywana do
systemu jako ciąg znaków.

To jest przykład JEDNEGO bloku MOBprogramu dla moba.


-------------------Dołączanie MOBprogramu do Moba---------------------------

Są dwa sposoby dołączenia programów do moba. Pierwszy sposób to lista 
mob_programów znajdująca się na końcu prototypu moba w kraince. Wszystkie 
moby biegające po mudzie, które są stworzone na bazie tego prototypu będą 
posiadać właśnie ten zestaw programów, niezależnie od tego ile ich będzie. 
Drugim sposobem dynamicznego zmieniania programów jest używanie OLC
Aby dołączyć program do moba w pliku krainki należy w sekcji #MOBILES 
w kraince, na końcu prototypu moba (np. w linii za linią opisującą pozycję/płeć 
moba), można dodawać dowolną ilość bloków MOBprogramów (używając 
składni przedstawionej wcześniej) kończąc je linią zaczynającą się od znaku 
'~' (tylda). Przykład znajduje się w: progexample.are.

-----------------------A co z OBJprogami i ROOMprogami------------------------

W przypadku OBJprog'ów i ROOMprog'ów sytuacja jest podobna. Oczywiście 
można dołączyć je na dwa sposoby. Pierwszy polega na dołączeniu listy programów 
na końcu prototypu danego przedmiotu/pokoju w dokładnie taki sam sposób jak 
w przypadku MOBprogów, drugi to użycie OLCa.

--------------------Typy triggerów dla MOBprogów----------------------------

Dodawanie triggerów jest bardzo proste dla koderów, ale podstawowa
lista przedstawiona poniżej (ich nazwy, składnia listy argumentów i
tłumaczenie na bardziej zrozumiały język <chiński?>) powinna wystarczyć do
stworzenia bardzo ciekawych MOBprogów (w razie pomysłu i nagłej potrzeby na
nowy trigger skontaktuj się z koderami SWMuda (note to coders)).

Składnia: act_prog [p] <ARGUMENT>

Argument to lista słów kluczowych oddzielonych spacjami. Jeśli
pierwszym słowem jest znak 'p', wówczas reszta słów traktowana jest jako
fraza. Trigger aktywuje się, kiedy słowo kluczowe (czy też cała fraza)
zawarte jest w komunikacie wywołanym przez funkcję act(). Zarówno fraza jak
i słowa kluczowe nie rozróżniają dużych i małych liter.

OPIS: To najogólniejszy trigger. Odnosi się do niemal każdego zdarzenia na
mudzie. Za każdym razem, gdy funkcja act() jest wywołana z
wiadomością dostarczaną TO_CHAR,TO_VICT,TO_ROOM (wywołania 
wewnątrz kodu muda) trigger może się uaktywnić. Na przykład:
MOBprogram: > act_prog p beka Ci w nos. ~
Ten trigger zostanie uaktywniony tylko wtedy, gdy mob otrzyma
wiadomość, w której cztery powyższe słowa są wymienione w dokładnie
takiej kolejności i z taką ilością spacji. Kropka jest bardzo ważna,
gdyż dla triggera słowem jest każdy ciąg znaków poza spacją. To
eliminuje błędną interpretację, gdy słowem kluczowym jest 'hi' a
sprawdzana jest wiadomość ze słowem np. 'machina'


Składnia: speech_prog [p] <ARGUMENT>

Argument taki sam jak dla act_prog.

OPIS: Ten trigger uaktywnia się, gdy słowo kluczowe, czy fraza, zawarte
jest w tekście, który został powiedziany przez gracza (komenda say)
w tym samym pokoju, co mob.

Składnia: tell_prog [p] <ARGUMENT>

Argument jak dla speech_prog

OPIS: Trigger ten działa podobnie do speech_prog, jednak w odróżnieniu od
niego reaguje na słowa/frazy, które gracz powie mobowi za pomocą
komendy tell.


Składnia: rand_prog <NUMER>

Argument jest liczbą od 1 do 100 włącznie.

OPIS: Ten trigger jest sprawdzany co PULSE_MOBILE (czyli co 
ok. 1 sec) i jeśli argument jest większy niż losowa liczba procent, 
wówczas trigger jest aktywowany. Trigger wykona się nawet, jeśli 
w pokoju nie ma żadnego gracza, ale muszą być gracze w tej 
kraince
. Ten program pozwala nadać mobom nieco prywatności: 
np. zamiatacz, który zatrzymuje się by zajarać szluga, pouskarżać 
się na swój marny los, czy pomarzyć o jakiejś sprzątaczce, czy 
też piesek, który warczy i szczeka - to czyni ich bardziej żywymi
a nie tylko łazikami jakimi są normalnie.


Składnia: fight_prog <NUMER>

Argument jest liczbą od 1 do 100 włącznie, jak w rand_prog.

OPIS: Użyteczne by urozmaicić walkę z danym mobem. Trigger jest sprawdzany
co PULSE_VIOLENCE (ok 1/4 sec.), i tylko gdy mob walczy. Może być użyte np. do
rzucania Mocy na przeciwnika. Tylko pierwszy fight_prog dla danego
moba będzie wykonany.


Składnia: hitprcnt_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Aktywowany jest co 1/4 sec (PULS_VIOLENCE), gdy mob walczy
Sprawdzaczy ilość hp moba jest poniżej podanego jako argument procentu,
jeśli tak, wówczas aktywuje program. Wielokrotne hitprcnt_progs
powinny być wpisane w kolejności rosnącej - 40% zawsze, bowiem wykona
się przed 20%, a tylko pierwszy skuteczny program się wykonuje!


Składnia: greet_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Kiedy tylko ktoś wejdzie do pokoju z mobem, i ów mob go widzi,
trigger jest sprawdzany. Dobre dla sklepikarzy, którzy chcą witać 
klientów, czy dla pseudo-agresywnych mobów, które wolą sprawdzić
kogo atakować, a kogo nie.


Składnia: all_greet_prog <NUMBER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Działa jak greet_prog, ale aktywuje się nawet, jeśli mob nie widzi
przyjścia gracza. (np. sneak, invis, itp.). Najużyteczniejsze dla
niby-teleportów (jeśli moby mogą transferować) czy dla strażników,
których nie można przejść.


***UWAGA: żaden greet_prog nie aktywuje się, jeśli mob walczy.***



Składnia: entry_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Odwrotność greet_prog'a. Aktywuje się za każdym razem, gdy mob
wejdzie do pokoju. Użyteczne dla rozglądania się, witania z
graczami itp. Tylko pierwszy program jest wykonywany, więc moby nie
wyglądają na głupków powtarzając komendy z powielonych programów.


Składnia: give_prog <ARGUMENT>

Argument to albo pełna nazwa przedmiotu, albo słowo 'all'. Kompletna
nazwa to np.: "pierścień żółty zielony" dla "żółto-zielony pierścień". Nazwa
ta to linia w sekcji #OBJECTS zaraz za VNUM'em.

OPIS: Ten trigger jest aktywowany gdy tylko gracz daje cos mobowi.
Znakomicie nadaje się do questów. Można wstawić kilka give_prog'ow
np. dla "miecz", drugi dla "pierścień" a trzeci dla "all", co będzie
dawało specjalną reakcję na miecze i pierścienie a standardową dla
pozostałych przedmiotów,


Składnia: bribe_prog <NUMER>

Argument to dowolna dodatnia liczba całkowita.

OPIS: Ten trigger aktywuje się, gdy mob otrzyma pieniądze. Jeśli ilość
monet danych mobowi przekracza liczbę podaną jako argument, program
wykonuje się. Zauważ, że znów można wstawić kilka programów (w
kolejności tym razem malejącej). Pierwszy np. na 1000 kredytek, drugi
na 1. Pieniądze dane mobowi nie dopisują się do jego kredytek,
ale tworzona jest kupka monet, którą może np. odrzucić (Uwaga:
zrzucenie i podniesienie zamienia to z powrotem na pieniądze).


Składnia: death_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Kiedy mob umiera, jeśli losowy procent jest mniejszy niż argument,
mob wykonuje komendy z programu, zamiast standardowego death_cry.
Dzieje się to zanim utworzone zostanie ciało, więc można uznać ten
trigger za ostatnie tchnienie moba. Może on np. niszczyć przedmioty
które ma na sobie, albo tworzyć inne, rzucać Moc na zabójcę, a
nawet przenieść się do innego pomieszczenia by tam umrzeć. Pozycja
moba jest ustawiana na STANDING więc może wykonywać wszystkie
komendy, nie zważając na to, że praktycznie nie żyje. Niemniej,
nawet jeśli przywróci sobie pełnię sił i tak umrze. W ten sposób nie
da się zrobić nieśmiertelnych mobów. Niemniej, przed śmiercią mob
może przenieść się do innego pokoju, załadować świeżą wersję siebie
samego, dać mu wszystkie przedmioty, przenieść go tam gdzie sam
zginął i zmusić nowego moba do zaatakowania zabójcy. (W ten sposób
można zamienić np. kotka w smoka po śmierci).


Składnia: hour_prog <NUMER>

Argument jest godziną - liczbą od 0 do 23

OPIS: Trigger ten aktywuje się, gdy na mudzie jest godzina wskazana jako
argument. Oczywiście słowo godzina nie dotyczy czasu rzeczywistego,
ale czasu mudowego, gdzie jedna godzina trwa dokładnie 1 tick.
Program wykonuje się co 5 pulsów (czyli ok. 2 do 3 sec) przez
cały czas gdy na mudzie jest dana godzina. Dlatego nie ma sensu
robić programu, w którym mob ogłasza, że właśnie minęła godzina
20-ta za pomocą tego triggera, gdyż biedak będzie to nadawał przez
całą godzinę. Można jednak kazać piekarzowi przez całą godzinę 6tą
rano piec chleb.


Składnia: time_prog <NUMER>

Argument jak w hour_prog

OPIS: Trigger ten jest podobny w działaniu do hour_prog, z tą różnicą, że
aktywuje się w momencie gdy dana jako argument godzina właśnie się
rozpoczęła i aktywuje się tylko ten jeden raz. Właśnie tego triggera
należy użyć jeśli chcemy by mob ogłosił wybicie godziny 20-tej.
Równie dobrze można sprawić by mob o godzinie 23 poszedł spać, zaś o
8 rano wstał.


Składnia: script_prog <ARGUMRNT>

Argument to liczba z przedziału 1 - MAX_SCRIPT (w tej chwili MAX_SCRIPT
wynosi 32). Jest to unikalny numer skryptu, dzięki któremu można go
potem uruchomić komendą: "mprunscript <nr_skryptu>".

OPIS: Jest specyficzny trigger służący do tworzenia programu nie
wykonywanego w całości za jednym zamachem, lecz linijka po linijce,
po jednej co ok. 5 okienek (ok. 1,5 sec). Skrypt można uruchomić i innego
programu używając mprunscript.

Podejście do listy komend jako skryptu powoduje, że NIE WOLNO używać
w programie instrukcji warunkowych (if checki). Można natomiast w przypadku
typów act, speech czy tell używać zmiennych. (Chodzi tu o stałe
i zmienne globalne, nie można używać zmiennych lokalnych, ani
argumentów programu ($vlx i $vax)). Trigger ten znakomicie
nadaje się do tworzenia moba, który opowiada pewną historię, przy
czym każde zdanie wypowiada osobno, w pewnym odstępie czasu. Można
też zrobić moba, który o konkretnej godzinie zaczyna recital i
zaczyna śpiewać. Dzięki zastosowaniu skryptu gracz nie zostanie
zasypany od razu całym ekranem tekstu.



-------------------------OBJprogi i ROOMprogi-------------------------------

OBJprogi to odpowiednik MOBprogów dla przedmiotów. Triggery dla
OBJprogów są sprawdzane gdy na danym przedmiocie dokonywana jest pewna
czynność, ewentualnie coś dzieje się wokół tego przedmiotu. Zasada działania
oraz sposób pisania ich jest dokładnie taki sam jak w przypadku MOBprogów.
Technicznie rozwiązano to za pomocą tzw. supermoba, który na czas działania
programu podszywa się pod przedmiot. Innymi słowy - opis supermoba staje się
opisem tego przedmiotu
, a interpretowanie programu należy już do supermoba.

ROOMprogi to odpowiednik MOBprogów dla pokojów. Triggery dla
ROOMprogów są sprawdzane gdy w danym pomieszczeniu dokonywana jest pewna
czynność. Działanie jest podobne jak przy OBJprogach, z tym, że supermob tym
razem podszywa się pod pokój - czyt. przyjmuje jego nazwę.

Dzięki zastosowaniu techniki unifikacji działania wszystkich
mud-programów w OBJprogach i ROOMprogach można wywoływać dokładnie takie
same komendy jak w przypadku MOBprogów. Prowadzić to może do zabawnych
sytuacji, gdy przedmiot uśmiecha się, zaś pokój odchodzi na północ. W
istocie rzeczy czynności te dokonuje supermob, jednak będąc nazwanym tak jak
przedmiot/pokój sprawia na graczu wrażenie, że robi to przedmiot/pokój.

Ważnym jest pamiętać o tym, że tak naprawdę to nie przedmiot/pokój
wykonuje dany program. Dlatego jeśli chcemy aby efektem wykonania programu
była zmiana stanu przedmiotu, musimy zadbać o to by znajdował się on w
odpowiednich rękach (czyt. supermoba). Nie powinno się też wywoływać skilli
ofensywnych i w ogóle rozpoczynania jakiejkolwiek walki. Może to doprowadzić
do niepożądanych skutków (choć kod taką możliwość uwzględnia i stara się
przed tym zabezpieczyć
).


--------------------Typy Triggerów dla OBJprogów----------------------------

OBJprogi dysponują innym zestawem triggerów i tylko te zostaną
zaakceptowane przez muda. Zasada ich działania i sposób użycia jest jednak
taki sam jak dla MOBprogów.


Składnia: act_prog [p] <ARGUMENT>

Argument jest taki sam jak w act_prog'u dla MOBprogów.

OPIS: Zasada działania act_proga dla przedmiotów jest taka sama jak dla
mobów (p. wyżej). Jedyna różnica polega na tym, że trigger reaguje
tylko na teksty, które widzi CAŁY pokój. Dodatkowo trigger ma szanse
się uaktywnić tylko wówczas, gdy dany przedmiot leży w pokoju, nie
jest zaś w inwentarzu czy ekwipunku gracza/moba.


Składnia: greet_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger jest sprawdzany, gdy do pomieszczenia, w którym leży dany
przedmiot wchodzi gracz. Aktywuje się jeśli losowy procent jest
mniejszy niż podany argument. Trigger ten można wykorzystać tworząc
leżące na ziemi przedmioty, które natychmiast po wejściu gracza do
lokacji "przyklejają" się do niego zmuszając gracza do podniesienia
go (a są np. typu no-drop).


Składnia: speech_prog [p] <ARGUMENT>

Argument tak jak w speech_prog'u dla MOBprogów.

OPIS: Ten trigger uaktywnia się gdy słowo kluczowe, czy fraza, zawarte
jest w tekście który został powiedziany przez gracza (komenda say)
w tym samym pokoju, w którym leży dany przedmiot. Sposób działania
jak w speech_prog'u dla MOBprogów.


Składnia: random_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger uaktywnia się losowo, gdy wygenerowana liczba procent jest
mniejsza od podanej jako argument. Program nie zostanie jednak
wykonany w momencie, gdy przedmiot znajduje się w pokoju, zaś w
lokacji tej nie ma ŻADNEGO gracza. Można dzięki temu stworzyć
przedmioty, które dla gracza mają mieć charakter niezwykły i np. co
jakiś czas zaczynają świecić, czy wydawać jakieś dźwięki. Unikać
należy sytuacji, gdy w efekcie wywołania programu przedmiot znika.


Składnia: wear_prog <NUMER>

Argument jest procentem szans na wykonanie programu, czyli przyjmuje wartości od 0 do 100

OPIS: Trigger uaktywnia się gdy gracz ubiera przedmiot i wygenerowana liczba procent jest
mniejsza od podanej jako argument.


Składnia: remove_prog <NUMER>

Argument jest procentem szans na wykonanie programu, czyli przyjmuje wartości od 0 do 100

OPIS: Trigger sprawdzany jest w momencie, gdy gracz zdejmuje z siebie dany
przedmiot (remove). Uaktywnia się losowo, gdy wygenerowana liczba
procent jest mniejsza od podanej jako argument. Można w ten sposób
stworzyć przedmioty, które bezpośrednio po zdjęciu znikają, bądź
spadają na ziemię, a także takie, które od razu zakładają się
ponownie.


Składnia: sac_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100

OPIS: Trigger sprawdzany jest w momencie poświęcania przedmiotu (komenda
sacrifice). Uaktywnia się losowo, gdy wygenerowana liczba procent
jest mniejsza od podanej jako argument. Wywołanie programu nie ma
jednak wpływu na to co stanie się z przedmiotem, gdyż bezpośrednio
po wywołaniu programu zniknie. Można w ten sposób stworzyć
przedmiot bardziej "boski" od pozostałych i specjalnie wynagradzać
za poświęcenie go.

***sac_prog nie jest uzywany ***


Składnia: get_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100

OPIS: Trigger sprawdzany jest w momencie gdy gracz podniesie dany
przedmiot z ziemi, ew. wyciągnie go z pojemnika czy ciała moba.
Uaktywnia się losowo, gdy wygenerowana liczba procent jest mniejsza
od podanej jako argument. Ten program pozwala na stworzenie
przedmiotów, które podnieść może np. tylko gracz powyżej czy poniżej
pewnego levelu, albo przedstawiciel konkretnej rasy czy profesji.
Można też sprawić, by zaraz po podniesieniu gracz zmuszony jest
założyć ten przedmiot.


Składnia: drop_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100

OPIS: Trigger sprawdzany jest w momencie gdy gracz odrzuci dany przedmiot
na ziemię. Uaktywnia się losowo, gdy wygenerowana liczba procent
jest mniejsza od podanej jako argument. W ten sposób można sprawić,
że odrzucone lustro stłucze się, albo bumerang wróci z powrotem do
gracza.


Składnia: damage_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger uaktywnia się gdy przedmiot ulega zniszczeniu i 
wygenerowana liczba procent jest mniejsza od podanej jako argument.



Składnia: repair_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger uaktywnia się gdy przedmiot jest naprawiany i 
wygenerowana liczba procent jest mniejsza od podanej jako argument.


Składnia: examine_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger sprawdzany jest za każdym razem gdy gracz spojrzy 
na dany przedmiot (look), ew. zajrzy do środka (examine, look in). 
Uaktywnia się losowo, gdy wygenerowana liczba procent jest mniejsza 
od podanej jako argument. Ciekawym zastosowaniem tego triggera 
jest stworzenie skrzyni z zawartością, która trafia do inwentarza czy nawet
ekwipunku gracza jak tylko zajrzy do środka skrzyni.


Składnia: zap_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger sprawdzany jest gdy gracz zostanie oparzony przez dany
przedmiot i odrzuca go, przez wzgląd na morale (przedmioty
anti-good, ant-neutral, anti-evil). Uaktywnia się losowo, gdy
wygenerowana liczba procent jest mniejsza od podanej jako argument.
Przykładem wykorzystania mogą być przedmioty, które po opadnięciu
znikają. Jednak pod żadnym pozorem nie można napisać programu, który
zmusi gracza do ponownego podniesienia i założenia tego przedmiotu.
Takie coś doprowadzi do powstania nieskończonej pętli!!!


Składnia: use_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Bardzo ogólny trigger. Sprawdzany jest w bardzo wielu momentach, zaś
jego podstawowym zastosowaniem jest zmiana standardowej informacji
wysyłanej do gracza po użyciu danego przedmiotu na inną. I tak np.
use_prog sprawdzany jest gdy: gracz pije z tego przedmiotu (drink),
zjada go (eat), zakłada na siebie (wear), połyka (quaff), albo
wyzwala jego magiczne moce (zap, brandish). Uaktywnia się losowo,
gdy wygenerowana liczba procent jest mniejsza od podanej jako
argument. Jeśli program zostanie uaktywniony, wówczas dla komendy
eat gracz nie otrzyma informacji "Zjadasz chleb". Zamiast tego
wykonuje się program, w którym można zastąpić to np. przez "Łapczywie
zjadasz chleb dławiąc się przy tym prawie."



Składnia: push_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .

OPIS: Trigger uaktywnia się gdy gracz wciśnie przycisk i 
wygenerowana liczba procent jest mniejsza od podanej jako argument.


Składnia: pull_prog <NUMER>

Argument jest procentem czyli przyjmuje wartości od 0 do 100 .7

OPIS: Trigger uaktywnia się gdy gracz pociągnie dzwignię i 
wygenerowana liczba procent jest mniejsza od podanej jako argument.


--------------------Typy Triggerów dla ROOMprogów--------------------------

ROOMprogi dysponują innym zestawem triggerów i tylko te zostaną
zaakceptowane przez muda. Zasada ich działania i sposób użycia jest jednak
taki sam jak dla MOBprogów i OBJprogów.


Składnia: act_prog [p] <ARGUMENT>

Argument jest taki sam jak w act_prog'u dla MOBprogów.

OPIS: Zasada działania act_proga dla pokojów jest dokładnie taka sama jak
w przypadku OBJprogów.


Składnia: leave_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger sprawdzany jest gdy gracz/mob wychodzi z danego pokoju.
Uaktywnia się w momencie gdy losowa liczba procent jest mniejsza od
podanej jako argument. Program ten nie daje jednak możliwości
zmuszenia gracza do pozostania w pokoju. Bez względu na to co się
stanie z graczem (transfer do innej lokacji) po wykonaniu programu
trafi on do pokoju, do którego się udawał. Trigger ten można jednak
wykorzystać np. do zamykania drzwi, przez które ten gracz przeszedł
(przez co np. podążający za nim inni gracze czy moby odbiją się od
nich i nie przejdą).


Składnia: enter_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger sprawdzany jest gdy gracz/mob wchodzi do danego pokoju.
Uaktywnia się w momencie gdy losowa liczba procent jest mniejsza od
podanej jako argument. Można w ten sposób np. zmusić gracza do
powrotu tam skąd przyszedł, albo do zaatakowania znajdującego się w
lokacji moba, czy też przenieść go do innego pokoju jeśli tylko
gracz spełnia pewne określone warunki.



Składnia: sleep_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger sprawdzany jest w momencie gdy gracz kładzie się w danym
pokoju spać (komenda sleep). Uaktywnia się w momencie gdy losowa
liczba procent jest mniejsza od podanej jako argument. Jest to
sposób na zrobienie lokacji, w której nie można spać, bądź też
wywołanie 'pseudo-snu' czy przerzucenie do innej lokacji.


Składnia: rest_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger ten sprawdzany jest w momencie gdy gracz odpoczywa w danym
pokoju (komenda rest). Uaktywnia się w momencie gdy losowa liczba
procent jest mniejsza od podanej jako argument. Można w ten sposób
sprawić, że gracz odpoczywa bardziej niż chce i w efekcie zasypia.


Składnia: rfight_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger ten sprawdzany jest w momencie gdy w danym pokoju toczy się
walka. Uaktywnia się w momencie gdy losowa liczba procent jest
mniejsza od podanej jako argument. Jest to sposób na stworzenie
pewnych lokacji, w których walka jest zakazana, bądź dozwolona tylko
od pewnego levelu. Może to być również miejsce święte, które
powoduje przywołanie strażnika który włącza się do walki itp.


Składnia: rdeath_prog <NUMER>

Argument to procent szans na wywołanie programu.

OPIS: Trigger ten sprawdzany jest w momencie gdy gracz/mob umrze w danym
pokoju. Uaktywnia się gdy losowa liczba procent jest mniejsza od
podanej jako argument liczby. Jest to prosty sposób na to, by ciało
zabitego moba zniknęło zanim gracz je splądruje.


Składnia: speech_prog [p] <ARGUMENT>

Argument tak jak w speech_prog'u dla MOBprogów.

OPIS: Ten trigger uaktywnia się gdy słowo kluczowe, czy fraza, zawarte
jest w tekście który został powiedziany przez gracza (komenda say)
w tym właśnie pokoju. Sposób działania jak w speech_prog'u dla
MOBprogów.


Składnia: random_prog <NUMER>

Argument oznacza liczbę procent (od 0 do 100).

OPIS: Trigger uaktywnia się losowo, gdy wygenerowana liczba procent jest
mniejsza od podanej jako argument. Program nie zostanie jednak
wykonany w momencie, gdy w pokoju nie ma ŻADNEGO gracza. Można dzięki
temu stworzyć lokacje, w których od czasu do czasu szumi las, czy
świergolą ptaszki, albo np. otwierają lub zamykają się drzwi.


Składnia: hour_prog <NUMER>

Argument jest godziną - liczbą od 0 do 23

OPIS: Trigger ten aktywuje się, gdy na mudzie jest godzina wskazana jako
argument
. Oczywiście słowo godzina nie dotyczy czasu rzeczywistego,
ale czasu mudowego, gdzie jedna godzina trwa dokładnie 1 tick.
Program wykonuje się co 5 pulsów (czyli ok. 2 do 3 sec) przez
cały czas gdy na mudzie jest dana godzina. Można w ten sposób zrobić
lokacje, w których po północy straszą duchy itp.


Składnia: time_prog <NUMER>

Argument jak w hour_prog

OPIS: Trigger ten jest podobny w działaniu do hour_prog, z tą różnicą, że
aktywuje się w momencie gdy dana jako argument godzina właśnie się
rozpoczęła i aktywuje się tylko ten jeden raz. Można ten trigger
wykorzystać np. do otwierania tajemnych drzwi tylko o określonej
porze (supermob ładuje klucz, odklucza drzwi, otwiera i purge'uje
klucz).


------------------------------Zmienne--------------------------------------

Aby jednak programy mogły działać poprawnie i można było odwoływać
się do postaci i przedmiotów, których dotyczy program, należy wprowadzić
zmienne. W MUDprogach zmiennymi są litery poprzedzone znakiem dolara, tak
jak w przypadku socjali. Gdy interpreter wykonuje polecenie, zmienne te są
zamieniane na wartości opisane poniżej.

Ponieważ na naszym mudzie mamy prawdziwe zmienne a nie udawane jak na
innych, ;) dlatego dla wygody proponuję stare "zmienne" nazywać po prostu
stałymi, gdyż w rzeczywistości tym właśnie są, jako że mają przypisaną
wartość na stałe i w progu nie możemy jej zmieniać.

Zmienne możemy podzielić na 4 grupy: stałe (stare zmienne), lokalne,
globalne, argumenty programu moba. Poniżej po kolei opisane są
wszystkie rodzaje.

------------
Stałe:

$i nazwa moba, który posiada program
$I nazwa (w mianowniku) owego moba
$n imię postaci, która spowodowała wykonanie programu
$# imię postaci, która spowodowała wykonanie programu
(#-numer 1-6, 1-mia, 2-dop, 3-cel, 4-bie, 5-nar, 6-mie)
$N jeśli postać jest graczem to imię i title owej postaci jeśli mobem to jego nazwę w mianowniku
$t nazwa drugiej postaci (dla act_proga) np. A uśmiecha się do B
$T imię i title (ew. nazwa w mianowniku jeśli to mob) owej postaci
$r imię losowej wybranej postaci w pokoju (nigdy == $i)
$R imię i title (ew. nazwa w mianowniku jeśli to mob) losowo wybranej postaci


$j to, on, ona - zależnie od płci $i
$e to, on, ona - zależnie od płci $n
$E to, on, ona - zależnie od płci $t
$J to, on, ona - zależnie od płci $r

$k temu, jemu, jej - zależnie od płci $i
$m temu, jemu, jej - zależnie od płci $n
$M
temu, jemu, jej - zależnie od płci $t
$K
temu, jemu, jej - zależnie od płci $r

$l tego, jego, jej - zależnie od płci $i
$s tego, jego, jej - zależnie od płci $n
$S tego, jego, jej - zależnie od płci $t
$L tego, jego, jej - zależnie od płci $r

$o nazwa pierwszego przedmiotu (np. ktoś upuszcza A)
$O opis (short_descr) owego przedmiotu
$p nazwa drugiego przedmiotu (np. ktoś wkłada A do B)
$P opis (short_descr) owego przedmiotu

$a przyjmuje następujące wartości zależnie od płci $i: m-'y', k-'a', n-'e',
na przykład jeśli mob jest rodzaju męskiego to za $a w tekście proga
zostanie podstawiona litera 'y'
$A przyjmuje następujące wartości zależnie od płci $n: m-'y', k-'a', n-'e'.

W if_checkach (o nich zaraz) akceptowane są podstawowe
stałe, a mianowicie $i, $n, $t, $r, $o i $p. Jeśli stała odnosi się do
obiektu który nie istnieje, wówczas wartość na jaką zostanie zamieniona jest
po prostu pusta. (np. odwołanie się do $o gdy triggerem jest: A całuje B).
Wyjątkiem są ifchecki: "var", "isset" i "isnumber" które operują na
zmiennych, nie na stałych.

Jedyny problem ze stałymi jest w przypadku odwołania do drugiego
przedmiotu czy drugiej postaci, gdyż wartości te są przekazywane przez
funkcję act w tym samym miejscu. (stąd widać, że stałe te mają
zastosowanie praktycznie tylko wewnątrz act_prog'ów). To znaczy, że jeśli
odwołujesz się do stałej $t w sytuacji 'ktoś wkłada A do B', rezultatem
będzie najprawdopodobniej malutki pad muda, albo jakiś zupełnie niewiadomy
efekt, szczególnie jeśli owo $t jest używane w jakimś if_check'u
(np. if isnpc($t) w powyższej sytuacji). Dlatego powinno się odwoływać do
stałych $t, $T, $p i $P ze szczególną ostrożnością.

Sprawa ze stałymi komplikuje się nieco w przypadku OBJprog'ów i
ROOMprog'ów, gdyż w tym momencie nie ma moba-posiadacza programu. Sprawa
jednak została rozwiązana w dość prosty sposób. Otóż jako $i i $I występuje
wspomniany wcześniej supermob, który przyjmuje nazwę przedmiotu/pokoju.
Znaczenie $n, $N, $r, $R pozostaje bez zmian. Dla OBJprogów, pod $o i $O
kryje się wówczas przedmiot-posiadacz programu. Drugi przedmiot i druga
postać w przypadku ROOMprogów i OBJprogów nie istnieje.

------------
Zmienne:

Na SWMudzie dostępnych jest po 10 zmiennych z każdego rodzaju: lokalnych,
globalnych
, a także argumentów programu. Zmienne te mają następujące
nazwy:
lokalne: $vlx - gdzie x jest cyfrą od 0 do 9 (np. $vl0)
globalne: $vgx - x cyfra od 0 do 9
arg proga: $vax - x cyfra od 0 do 9

Uwaga: należy pamiętać by nazwy zmiennych pisać małymi literami,
$VG0 NIE zostanie potraktowana jako zmienna.

Zmiennych można używać praktycznie w każdym miejscu programu. W miejscu
gdzie w tekście programu występuje nazwa zmiennej zostanie podstawiona
jej wartość. Zmiennym lokalnym i globalnym można przypisywać wartości
liczbowe i łańcuchy znaków. Nie ma rozróżnienia między zmiennymi liczbowymi
a stringami (łańcuchami znaków) dlatego na builderze spoczywa odpowiedzialność
by sprawdzić czy dana zmienna zawiera to czego się spodziewa. Aby sprawdzić
czy dana zmienna jest liczbą należy użyć ifchecka isnumber($var) (dokładny opis
ifcheckow niżej). Sprawdzanie co zawiera zmienna jest o tyle ważne, że na
zmiennych zawierających liczby można wykonywać proste operacje matematyczne
(+, -, *, /) natomiast na stringach takich operacji wykonać się nie da
(przykład: jeśli $vg0 == 5 a $vl0 == 10 to po wykonaniu '$vl1 = $vg0 + $vl0'
$vl1 będzie miała wartość 15, jeśli jednak $vg0 == 'jakiś dziwny tekst' to
po wykonaniu '$vl1 = $vg0 + $vl0' zmienna $vl1 będzie zawierać taki string:
'jakiś dziwny tekst + 10' a przecież nie o to chodziło. ;)

Poniżej znajduje się krótki opis każdego typu zmiennych.

------------
Zmienne lokalne:
nazwa: $vlx - gdzie x jest cyfrą od 0 do 9 (np. $vl0)
Zmienne te przy starcie mob programu są kasowane i żeby ich użyć należy im
przypisać jakąś wartość. Zmienne lokalne zachowują swoje wartości do końca
trwania programu, po jego zakończeniu są kasowane. Zmienne lokalne są unikalne
dla każdego mob programu (jeden prog moba nie widzi zmiennych lokalnych innego
programu).

------------
Zmienne globalne:
nazwa: $vgx - gdzie x jest cyfrą od 0 do 9 (np. $vg0)
Zmienne globalne zachowują swoją wartość przez całe życie moba i są takie same
dla każdego programu moba. Dzięki temu można stworzyć interakcję między różnymi
programami tego samego moba i uzależnić działanie jednego programu od wyniku
działania innego. Jednak należy uważać przy pisaniu programów, aby jeden
prog nie kasował przez nieuwagę wartości zapisanych w zmiennych globalnych
przez inny program. Zmiennej globalnej również należy nadać jakąś wartość
zanim zacznie się jej używać.

------------
Argumenty programu:
nazwa: $vax - gdzie x jest cyfrą od 0 do 9 (np. $va0)
Argumenty programu są to zmienne które zawierają dane związane z uruchomieniem
danego programu (np. godzinę uruchomienia programu, słowa które wypowiedział
gracz żeby uruchomić program itp.) i są zależne od typu mob programu. Wartości
tych argumentów są ustalane przy starcie programu i pozostają niezmienione do
końca programu. Nie można im przypisywać nowych wartości.

Wartości argumentów w zależności od typu proga:

a) speech, tell i act progi:
$va0 - zawiera cały tekst który wywołał działanie proga (np. jeśli mamy
speech_prog z triggerem 'p nie mam' a gracz powie: 'nie mam tego' to
$va0 będzie zawierać: 'nie mam tego').
$va1 - zawiera pierwsze słowo z tekstu aktywującego proga
(np. w naszym przykładzie wyżej $va1 będzie miało wartość: 'nie')
$va2 do $va9 - kolejne słowa tekstu aktywującego proga. Jeśli tekst składał się
z mniejszej ilości słów niż 9 to reszta zmiennych będzie pusta (np. $va4
do $va9 z naszego przykładu będą puste). Jeśli tekst miał więcej niż 9 słów
to reszta nie jest nigdzie zapisywana (zostaje zignorowana).
Jeśli przy wywołaniu programu tekst umieścimy w apostrofach np.: say nie 'wiem co to' jest, to cały tekst w apostrofach będzie potraktowany jako jeden wyraz. Argumenty programu będą wtedy zawierać następujące wartości: $va0 = nie 'wiem co to' jest, $va1 = nie, $va2 = wiem co to, $va3 = jest.

b) time i hour progi:
- $va0 zawiera godzinę wywołania progu, inne argumenty są puste

c) bribe prog:
- $va0 zawiera ilość kredytów jaką dostał mob, reszta pusta

d) rand progi:
- $va0 zawiera ilość procent przy jakich włącza się prog

e) reszta programów:
W większości triggerem jest procent szans na wywołanie programu i to zawiera
$va0, a reszta jest pusta. Ponieważ nie jest to zbytnio interesujące bo i tak od
początku wiemy jaka jest wartość triggera to używanie argumentów w reszcie progów
nie jest zbyt sensowne.


----------------------Operacje na zmiennych i przykłady---------------------

Na zmiennych można wykonywać następujące operacje:

a) Przypisanie:
Nadanie zmiennej jakiejś wartości. Zanim będzie można użyć danej zmiennej w innych
operacjach najpierw trzeba nadać jej jakąś wartość.
$vl0 = 3
$vl0 = Taki sobie tekst.
$vg0 = $vl1
błędne użycie:
$va0 = 5 - argumentów programu nie można zmieniać


b) Operacje arytmetyczne:
Na zmiennych można wykonywać proste operacje arytmetyczne, należy pamiętać że
obie zmienne muszą zawierać wartości liczbowe (można to sprawdzić ifcheckiem
isnumber($var)) oraz że NIE można wykonywać złożonych działań (tylko jedno działanie
w linii)
$vl0 = 5 * 2
$vl0 = $vl1 + 30
$vl0 = $vg0 / $va0
$vg8 = $va3 - $vl6
błędne użycie:
$vl0 = 5 * 2 + 8 - nie można wykonywać złożonych działań


c) Zwiększanie i zmniejszanie wartości zmiennej o 1:
Należy pamiętać że jeśli zmienna będzie stringiem to otrzymamy głupoty.
$vl0++ zwiększa zmienna o 1
$vg0-- zmniejsza zmienna o 1

d) Przypisanie zmiennej wartości checka:
Zmiennej globalnej lub lokalnej można przypisać wartość kilku specjalnych
checków używanych w progach. Ich spis znajduje się poniżej. Należy pamiętać
że przypisanie ifchecka do zmiennej musi być jedyną operacją w linii i nie
można już tam np. wykonywać działań matematycznych.
$vg0 = name($n)
$vl0 = credits($r)
$vl0 = race($i)
błędne użycie:
$vl0 = var($vg1) - ifchecka var() nie można stosować w taki sposób
$vg0 = credits($n) + 100 - nie można jednocześnie przypisywać wartości
checka i wykonywać działań

Lista checków, których wartości można przypisać zmiennym:
name 
inroom; wasinroom
sex; position; level; credits; race; clan
str; wis; int; dex; con; cha; frc; lck
rand(b); rand(a,b) - losuje liczbę z zakresu 0-b lub a-b



---------------------------Sekwencje Sterujące------------------------------

W kodzie MUDprogramu można umieszczać sekwencje sterujące. Jedyną
obecnie dopuszczalną sekwencją jest instrukcja warunkowa. Oto składnia
instrukcji warunkowej dla MUDprogramu (oznaczenia p. Składnia MUDprog'ów).


"if" " " {if_check_1} "(" {argument} ")" [ {operator} {wartosc} ] NL
[ "or" " " {if_check_2} "(" {argument} ")" [ {operator} {wartosc} ] NL ]
. . .
[ "or" " " {if_check_N} "(" {argument} ")" [ {operator} {wartosc} ] NL ]

[ {komenda_programu_1} NL ]
[ {komenda_programu_2} NL ]
. . .
[ "break" NL ]
. . .
[ {komenda_programu_N} NL ]

[ "else" NL ]

[ {komenda_programu_1} NL ]
[ {komenda_programu_2} NL ]
. . .
[ "break" NL ]
. . .
[ {komenda_programu_N} NL ]

"endif" NL

Ogólnie rzecz biorąc wygląda to tak: linia z 'if', za nią może (ale
nie musi) wystąpić kilka linii z 'or', za tym dowolna ilość linii z legalnymi
komendami muda, które mogą zawierać linię z komendą 'break', opcjonalnie za
tym linia z 'else', za którą znów jest dowolna ilość linii z legalnymi
komendami muda, które mogą zwierać linię z komendą 'break', zakończone
wszystko linią z 'endif'.

Jedyne części składni, której dotychczas nie znałeś (zakładając, że
przestudiowałeś wcześniejszą część ze składnią MUDprogów) to linie
zawierające słowo IF.

--Wyjaśnienia

IF_CHECK to łańcuch znaków, który opisuje kontekst, w którym będzie
dokonywane porównanie.
ARGUMENT to wskazanie na miejsce, z którego pochodzi lewa strona porównania
OPERATOR to rodzaj porównania lewej strony z prawą
WARTOSC to prawa strona porównania

Komenda BREAK przerywa działanie całego MOBprogramu niezależnie od poziomu
zagnieżdżenia w instrukcjach warunkowych.

Jeśli to cię przeraża, przerwij na moment czytanie tego dokumentu i rzuć
okiem na przykłady. Mam nadzieję, że one wyjaśnią pewne wątpliwości które ci
się nasunęły po przestudiowaniu tego paragrafu. Jeśli nie... trudno, musisz
wysilić szare komórki w nieco większym stopniu niż dotychczas.


--------------------------------Operatory-----------------------------------

Większość podstawowych operatorów numerycznych jest dopuszczalna i
daje takie same efekty jak operatory w języku C. Operatory łańcuchowe
nieco bardziej zagmatwane. Głównie dlatego, bo wyglądają podobnie jak
operatory numeryczne i nie mają nic wspólnego z porównywaniem łańcuchów w
języku C. Wynik porównania jest wartością logiczną TRUE (prawda) lub FALSE
(fałsz).

Operatory numeryczne:

A == B A równe B
A != B A różne od B
A > B A większe od B
A < B A mniejsze od B
A >= B A większe lub równe B
A <= B A mniejsze lub równe B
A & B wynik operacji na bitach 'and' (A and B)
A | B wynik operacji na bitach 'or' (A or B)

Operatory łańcuchowe:

A == B A jest takie samo jak B
A != B A nie jest takie samo jak B
A / B B zawiera się w A. Np. if name($n) / pies zwróci wartość
TRUE dla "piesek" "pies" "superpies" itp. Używanie == w
tym przypadku oznacza, że szukasz pełnej nazwy moba np.
"piesek pies" (pole name dla mobów).
A !/ B B nie zawiera się w A.

Należy pamiętać o tym, że operatory łańcuchowe uwzględniają wielkość liter
(czyli są case SENSITIVE).


--------------------If_Check'i w Instrukcjach Warunkowych-------------------

Poniżej znajduje się lista if_check'ów i ich argumentów. Właściwie
ich nazwy jednoznacznie wskazują na to do czego służą, ale w niektórych
przypadkach zasługują na małe wyjaśnienie. Każdy z operatorów '==' może być
zastąpiony przez dowolny z wymienionych powyżej. Argument ($*) oznacza
odwołanie do stałej, która ma jakiś sens w tym if_check'u (np. dla
if_check'a, w którym sprawdza się postać jedynymi poprawnymi stałymi będą
$i, $n, $t i $r). Wartość typu <string> jest to ciąg znaków. Nie potrzeba
ich umieszczać w żadnych cudzysłowach czy apostrofach. Nic z tych rzeczy.
(np.

 name($n) == ork duży brązowy
)


Specjalne ifchecki do używania tylko ze zmiennymi:

Uwaga dotycząca if_check'ów: mobinroom, ovnumhere, otypehere, ovnumroom,
otyperoom, ovnumcarry, otypecarry, ovnumwear, otypewear, ovnuminv i
otypeinv. Wywołanie któregokolwiek z tych if_check'ów BEZ operatora i liczby
powoduje standardowe wywołanie if_check(num) == 1. Dodatkowo: nie wolno w
nich używać porównania if_check(num) == 0, gdyż nie będzie to działać.
Należy użyć porównania if_check(num) < 1.



--------------------------Dodatkowe MOBkomendy------------------------------

MOBkomendy w większości są to zmienione wizskille, tak by moby mogły
mieć większą siłę i w specjalnych okolicznościach dokonywać z graczem
niesamowite rzeczy, które tak naprawdę przysługują tylko nieśmiertelnym.

!!!!! UWAGA !!!!!
MpKill, MpDamage i MpGoto mogą używać TYLKO MOBY!

Oto MOBkomendy, które zostały zakodowane na SWMudzie celem nadania mocy
MUDprogramom:


-------------------------------PRZYKŁADY-------------------------------

Bardziej skomplikowany przykład można pobrać tutaj: progexample.are.
Oto przykład wykorzystania instrukcji warunkowej w programie:

>act_prog p puszcza pawia na twoje ubranie!~
if isnpc($n)
bekaj
rzygaj $n
else
if level($n) <= 5
or isgood($n)
tell $n Czy możesz łaskawie nie rzygać na mnie?
else
if level($n)>15
banzai
say Wiesz co $n... nienawidzę jak się na mnie rzyga!
mpkill $n
break
endif
klaps $n
shout MAMA!!!! $N rzyga na mnie... buuuu!
endif
endif
~

Ok.. czas przetłumaczyć.. trigger uaktywni się tylko wtedy gdy mob otrzyma
wiadomość "... puszcza pawia na twoje ubranie! ..." Jeśli ten paskudny
osobnik (p. przypomnij sobie kogo dotyczyły stałe $n i $N.. no ten kto
rzyga) jest mobem (NPC), wówczas mob beka sobie i rzyga też. Jeśli zaś jest
on graczem, to dobrzy i niskolevelowcy otrzymują ostrzeżenie,
wysokolevelowcy są atakowani, zaś średniolevelowcy dostają klapsa.

Zauważ jednak, że dwa moby mogłyby w łatwy sposób popaść w nieskończoną
walkę na rzyganie, która mogłaby nieco zwolnić muda.
Dlatego powinno unikać się odpowiadania rzyganiem na rzyganie, czy
miauczeniem na miauczenie.

A oto przykład pokazujący zastosowanie techniki script_prog'ów:

>act_prog p będzie teraz chodził~
if isimmort($n)
mprunscript 1
else
tell $n No dobra, zaprowadzę Cię do krainy miodem płynącej.
mptransfer $n 3001
mpgoto 3001
mprunscript 2
endif
~
>script_prog 1~
tell $n Oh, czymże sobie na ten zaszczyt zasłużyłem?
uśmiech
całuj $n
~
>script_prog 2~
south
south
west
north
tell $n jesteśmy na miejscu :)
tell $n baw się dobrze, ja znikam.
mpgoto 3014
~
|

I jeszcze tłumaczenie. Załóżmy, że jest to lista programów Jasia. Jeśli
gracz podejdzie do niego i wykona komendę 'follow Jaś', wówczas mob ujrzy
wiadomość, że ktoś zaczyna za nim chodzić. Jeśli jest on nieśmiertelny
wówczas uruchamia skrypt 1, jeśli nie, przenosi siebie i gracza do pewnej
lokacji i uruchamia skrypt 2. Komendy każdego ze skryptów nie będą
wykonane natychmiast, ale każda osobno w pewnym odstępie czasu. Oczywiście
jeden mob nie może naraz przetwarzać dwóch skryptów.
Co ciekawe, trigger ten nie uaktywni się jeśli gracz będzie płci żeńskiej,
gdyż mob uzyskuje wówczas tekst "... będzie teraz chodziła ..."
^
Zatem aby na płeć żeńską program też działał należy wykonać jego duplikat :P

++++++++++++++++++++++++++++++++++++++++++++++++++++++

MUDprogs.txt created July 18., 1998 (Asterrix)
Changes and adds 10 march 2005 by Ratm( nie tylko ;p ).