ПАМЯТКА СТРОИТЕЛЯМ  (версия 0.5)

 Доработанные и новые разделы в этой версии:
  3.11   4.6   5.2 - 5.3   5.6 - 5.9   5.12 - 5.18

                                            "ХАЛЯВЫ БЫТЬ НЕ ДОЛЖНО"
                                                                Moris

   Эта памятка представляет собой пока что разрозненный набор советов тем, 
кто создает новые игровые пространства (зоны) для нашего мира Арда MUD или же
проверяет зоны, написанные другими авторами. Возможно, в будущем памятка 
вырастет в настоящее руководство, но сейчас она не претендует на это.
   Здесь не затрагиваются вопросы выбора и согласования темы зоны. Если вы
хотите разработать новую зону не просто для своего удовольствия, а с расчетом
на ее будущее подключение в Арде, прежде всего напишите Head Builder'у 
проекта (на данный момент это Аланна, alanna@mail.ru). Тут собраны некоторые
рекомендации тем, кто уже начал строить.
   Для работы над зонами вам потребуется редактор зон AWE 1.2 (Arda World
Editor), его можно скачать по адресу http://www.arda.pp.ru/build/awe1_2.exe
Изучите справку к этой программе, и вы получите ответы на большинство вопросов,
которые возникают у начинающих строителей.

--------------------------------------------------------------------------------

1. Тексты
---------

1.1) Не забывайте, пожалуйста, что все выводимые на экран строки надо 
ограничивать 80 символами. Имеется в виду видимая длина, то есть в нее 
не входят символы перевода цвета ("&Cкарась&w" - 6 видимых символов, а не 10). 
И пусть AWE ругается, что строка с цветами длиннее 80: важно, какова длина 
видимой строки. Это же относится к текстам, выводимым на экран в программах 
(оператором mpecho и другими). К примеру, если у моба "Бывалый солдат" 
в программе стоит "say Привет!", вы должны предусмотреть, чтобы 
"Бывалый солдат говорит 'Привет!'" было не длиннее 80 символов.

1.2) Цвета можно использовать не везде (см. справку к AWE). В частности, крайне
нежелательны цвета в названиях комнат и мобов, английском коротком названии
предмета. Но, в любом случае, вы не должны забывать поставить после цветного
слова или строки текста (после каждой цветной строки!) перевод на обычный цвет
шрифта &w: "&RНа помощь!&w".
   В том случае, когда вам просто необходимо использовать цветной фон, также
не забывайте закрыть его обычным: ^x

1.3) Следите за переносом строк во всех текстах описаний, при этом старайтесь:
1. Не отрывать предлоги.
2. Разрывать по завершении предложения или знаку препинания, по возможности.
3. Делать примерно одинаковое число символов в строках, желательно от 70 до 80.
4. Оставлять по пробелу в конце строки, чтобы было позже удобнее менять
   разбивку на строки.
5. Все вышеперечисленное не догма, но надо стараться это учитывать.
6. Обязательно делать перевод строки в конце описания, но удалять лишние пустые
   строки.

1.4) Старайтесь писать грамотно, трижды проверять сделанное. Избегайте повторов
одних и тех же слов в соседних предложениях (особенно часто повторяют личные
местоимения "он", "его", "ему"). Всегда оценивайте, насколько однозначно и
легко воспринимается написанное, нет ли каких-то противоречий или глупых фраз.


2. Мобы
-------

2.1) Постарайтесь, чтобы количество мобов и вещей соответствовало количеству 
комнат. В хорошей зоне на 100 комнат приходится не менее 20 разновидностей 
мобов и не менее 40 предметов. Однако не стоит гнаться за количеством ради 
славы: все, что вы делаете, не должно выглядеть лишним или блеклым.
Можно сделать отличную оригинальную зону из 40 комнат, насыщенную квестами
и программами, с наделенными собственным поведением мобами, а можно из 400 
пустых комнат с повторяющимися тривиальными описаниями. Во втором случае 
ваша зона будет неинтересной и ненужной.

2.2) Разброс уровней мобов в зоне не должен превышать 10, в крайнем случае 15. 
Если в вашей зоне кролики 5 уровня будут бегать возле орков 40 уровня, игроки 
будут испытывать серьезное неудобство. Если вам по сюжету совершенно необходимо
поставить какого-то беззащитного моба существенно ниже уровня зоны, не забудьте
поставить ему флаг noquest.

2.3) Короткое английское название моба желательно делать из 1 слова. Тогда
описание моба, выдаваемое в комнату (длиной не более 80 символов, включая
подставленное вместо %s английское имя), может быть более содержательным.
Основной язык у нас русский. В списке ключевых слов могут быть и другие
английские слова - ничего страшного, если игрок о них не догадается.
   Русские ключевые слова также не обязаны все входить в описание, выдаваемое
в комнату. Однако в списке ключевых должны быть все слова из названия моба,
наиболее заметные слова из описания, выдаваемого в комнату. Полезно добавить
к ключевым словам и наиболее характерные слова из описания, выдаваемого при
взгляде на моба.
   Не включайте в список ключевых слов моба предлоги.

2.4) Для мобов желательно наиболее характерное и редкое слово (особенно слово
с цифрами, см. далее) ставить первым в списке ключевых слов. Это повышает шансы
на то, что в программах при обращении к мобу посредством переменной $n он
не будет спутан с каким-то другим мобом.
   ВСЕ мобы, которые упоминаются в программах по имени, должны называться в них 
ключевым словом с цифрами (желательно добавлять к английскому слову VNUM данного
моба). Например, строка программы: "mpforce rabbit25005 jump"
Для моба с VNUM 25005 "rabbit25005 tiny крохотный крольчонок" ключевое слово
rabbit25005 является совершенно уникальным идентификатором.
   Если моб упоминается в программах ТОЛЬКО по VNUM (например, mpmload 25005),
не нужно включать цифры в список ключевых слов.

2.5) Описание моба, которое видно в комнате, не стоит завязывать:
- на других мобов ("Собака%s вылизывает своих щенков." - щенков могут убить,
призвать в другое место либо очаровать и увести);
- на конкретную комнату ("Мальчик%s бросает камешки в ручей." - его могут
призвать либо увести куда-нибудь на высохшую равнину, "Лошадь%s пасетсЯ тут." -
она может находиться в здании);
- на предметы, которые могут забрать и унести, выбить у моба из рук, украсть
из инвентаря и т.п.
   Вы можете привязать описание моба к комнате, если вы знаете, что моб не может
оказаться в другом месте (флаги sentinel, notsummonable, иммунитет к очаровать).
   Еще не забывайте, что в описании должно присутствовать действие. Например,
неверно "ПрекраснаЯ эльфийка%s с бездонными синими глазами.", верно так:
"ПрекраснаЯ эльфийка%s с бездонными синими глазами расчесывает волосы."
(примечание: описание моба, видимое в комнате, в бою не показывается).
   Все это относится и к описаниям мобов, отображаемым, когда на них смотришь.
Но не следует здесь писать, чем занят моб (на него могут посмотреть в тот
момент, когда он в бою, будет смешно видеть, к примеру: "Мальчик крепко спит
и улыбаетсЯ во сне.", когда он наносит вам удар за ударом). 
   ВСЕ мобы должны иметь описания, отображаемые, когда игрок смотрит на них.

2.6) Следите за тем, какие части тела заданы для моба, чтобы, к примеру, 
у лошади после ее смерти не появлялась лапа.
   Следите за тем, какой тип атаки задан у моба (чтобы не получалось так:
"Ударом кулака олененок царапает вас."). И вообще, старайтесь быть внимательнее.

2.7) Когда вы размещаете несколько экземпляров одного моба (то есть все они 
имеют один и тот же VNUM) в комнатах, кликните на каждый ресет моба мышкой и 
поставьте для каждого(!) экземпляра максимальное число мобов этого типа в мире.
Например, если у вас два моба с VNUM = 26005 в одной комнате и третий в другой,
вы должны для всех установить "Количество в мире = 3".

2.8) Если вы запланировали в своей зоне пять практически одинаковых разбойников,
причем отличия состоят только в экипировке и минимальной разнице уровней, лучше 
использовать для них один и тот же VNUM. Отличия в экипировке вы получите за 
счет ресетов (можно надеть или дать в инвентарь каждому экземпляру моба свой 
набор предметов). Небольшой разброс уровней для мобов с одним VNUM есть всегда. 
(ВАЖНО!) Когда вы расставляете одинаковых мобов по комнатам, а игроки убивают
их, все одинаковые мобы в итоге могут оказаться в одной комнате (особенности 
работы ресетов). Можно ставить мобов с одинаковым VNUM в следующих случаях:
1. Если они бродят (без флага sentinel) в одном районе;
2. Если они стоят (с флагом sentinel) в одной комнате;
3. Если мобы с флагом sentinel стоят в разных комнатах, но поодиночке - в этом 
случае установите им также флаг oneperroom.

2.9) Мобам, участвующим в квестах или имеющим программы, кроме иммунитета
к очарованию, желателен иммунитет ко сну. Полезен также флаг notsummonable.
Но не надо этим излишне увлекаться. Старайтесь продумать, требуют ли конкретные
программы привязки к месту, не будет ли халявой очаровать моба и заставить
его отдать что-то, что дается за квест, или же отозвать моба, затем пройти
в охранявшееся им место без боя. Если вы уверены, что не страшно моба
очаровывать, усыплять, призывать, если программа не будет работать неверно
после призыва моба, тогда не ставьте этих ограничений.

2.10) Не забывайте о том, что почти всегда мобу нужно видеть игрока, другого 
моба, предмет, чтобы реагировать должным образом. Если это необходимо, ставьте 
мобу аффекты infrared (часто забывают для темных комнат и открытых пространств),
detect_hidden, detect_invis или truesight. Если вы не хотите давать мобу
возможность видеть все (что часто нереалистично), позаботьтесь о том, чтобы 
он логично (как-то иначе) реагировал в тех случаях, когда он не видит чего-то
или кого-то.

2.11) Помните, что для использования некоторых предметов, специфических умений
и заклинаний для моба должны выполняться определенные условия. Например, моб
не сможет использовать умение "придушить", если не будет злым, не сможет
успешно развеивать магию с противника в бою без аффекта detect_magic, с доброго
моба свалится любой предмет с флагом "нельзЯ_хорош" и т.д.

2.12) Нежелательно ставить мобу урон или здоровье 1dX, лучше, например, 5dY,
где среднее значение то же. То есть не надо делать слишком большого разброса 
параметров (от минимума к максимуму). Еще лучше XdY + Z, где Z хотя бы порядка
половины от среднего итогового значения (для здоровья). Для урона Z стоит брать
поменьше.

2.13) Не делайте мобов с очень слабой защитой или вообще без оной, кроме низких
уровней (2-6). Как правило, либо уклонение, либо парирование по смыслу надо
ставить. Могут быть исключения, но тогда мобов надо усиливать в нападении,
давать магическую атаку либо боевую программу или защищать сопротивляемостью.
Когда вы выбираете для моба сопротивляемость к чему-либо, иммунитет (не слишком
часто!), уязвимость, не забывайте о логике. Так, ставить дереву сопротивляемость
к огню нереалистично.

2.14) Если вам необходимо удалить моба в процессе выполнения программы на этом
самом мобе, сделайте это следующим образом:
 mpgoto 10
 speak westron
 say SLAYME
Здесь вторая строчка нужна только для животных (которые говорят лишь на языке 
mammal). Моб отправится в служебную комнату 10 и даст команду на собственное
удаление другому служебному мобу. Учтите, что другие способы ликвидации моба 
во время исполнения программы на нем опасны!


3. Предметы
-----------

3.1) Короткое английское название предмета желательно делать из 1 слова. Тогда
описание предмета, выдаваемое в комнату (длиной не более 80 символов, включая
подставленное вместо %s английское имя), может быть более содержательным.
Основной язык у нас русский. В списке ключевых слов могут быть и другие
английские слова - познание покажет их игрокам.
   Русские ключевые слова также не обязаны все входить в описание, выдаваемое
в комнату. Однако в списке ключевых должны быть все слова из названия предмета
и наиболее заметные слова из описания, выдаваемого в комнату. Не перебарщивайте,
тем не менее, с количеством ключевых слов: вряд ли стоит когда-либо использовать
более 4 русских и 3 английских ключевых слов (минимальное число - 2 русских и
1 английское).
   Никогда не включайте в список ключевых слов предлоги, даже если они входят
в название предмета. Например, "платье в клеточку". Если вы включите "в" 
в список ключевых слов, игрок сможет подобрать предмет командой "взять в",
что глупо и создаст ненужную путаницу.

3.2) Для предметов желательно наиболее характерное и редкое слово (особенно 
слово с цифрами, см. далее) ставить первым в списке ключевых слов. Это повышает 
шансы на то, что в программах при обращении к предмету посредством переменной 
$o он не будет спутан с каким-то другим предметом.
   ВСЕ предметы, которые упоминаются в программах по имени, должны называться 
в них ключевым словом с цифрами (желательно добавлять к английскому слову VNUM 
данного предмета). Например, строка программы: "get club26014"
Для предмета с VNUM 26014 "club26014 wooden деревЯннаЯ дубинка" ключевое слово
club26014 является совершенно уникальным идентификатором. Если в программах
данный предмет упоминается ТОЛЬКО по VNUM, тогда вводить цифры в список ключевых
слов не нужно (например, mpoload 26014).

3.3) Если вы используете цвета в длинном описании предмета (строке, которая 
выдается в комнату), помните, что для него обычным является желтый цвет.
Например, правильно так: "&RЯрко-краснаЯ&Y роза%s лежит тут.&w", а не
"&RЯрко-краснаЯ&w роза%s лежит тут." Не страшно, что при этом AWE ожидает
точки в конце.

3.4) Описание предмета, которое видно в комнате, не стоит связывать с конкретной
комнатой или местностью, другими предметами. Например, "Книга%s лежит на столе."
и "На полу блеснула золотаЯ монета%s." будут звучать глупо где-нибудь на дне
морском, куда могли отнести эти вещи.
   Вместо слов "лежит на полу", "на земле" и подобных (их можно сохранять лишь
неберущихся предметов) пишите "лежит тут", "валЯетсЯ здесь" или "у ваших ног" 
(очень распространенная ошибка). Иначе, к примеру, игроки бросят морковь на пол 
в таверне, и фраза "Морковь(carrot) торчит из земли." будет вызывать недоумение.

3.5) Не забывайте, что в описании должно присутствовать действие. Например,
неверно "РжаваЯ кольчуга%s.", верно так: "РжаваЯ кольчуга%s требует ремонта.";
неверно "Книга%s с изображением черепа.", верно "Книга%s с изображением черепа 
лежит тут."

3.6) В качестве короткого английского названия предмета (English) старайтесь 
выбирать существительное, являющееся переводом главного слова в русском названии
предмета. %s желательно ставить после русского слова, соответствующего 
английскому, тогда получится так: "Гоблинское копье(lance) жутко неудобное." 
(кстати, действие тут есть, но сказуемое выражено прилагательным. Это вполне 
нормально). Тем не менее, если уж ваш предмет называется "копье гоблина", 
следует писать "Копье гоблина%s жутко неудобное.", а не "Копье%s гоблина..." 
Английское "lance" будет относиться ко всему словосочетанию - ничего страшного, 
даже хорошо, потому как %s отделяет полное название предмета, и игроку будет 
проще.

3.7) Все или почти все предметы (не менее 80%) должны иметь описания,
отображаемые, когда игрок осматривает вещь. Вот там уже действие необязательно,
к тому же, можно не повторять название предмета. Например, осматривая предмет 
"шапка", можем прочесть "РванаЯ и измазаннаЯ в какой-то гадости." или "Она
Явно вам будет маловата."

3.8) Первое дополнительное описание предмета должно иметь список ключевых слов,
ПОЛНОСТЬЮ совпадающий с полем Name предмета. Например, "lantern oil26003 стараЯ
маслЯнаЯ лампа" - вместе с цифрами(!)  Иначе на аукционе, например, описание
предмета не будет видно.

3.9) Не стоит в дополнительных описаниях предметов (которые показываются при
осмотре вещи) давать какие-то указания на то, откуда эта вещь, кому она 
принадлежала. Тот, кто случайно нашел этот предмет в таверне или на свалке,
как правило, не имеет информации об этом, а знает лишь то, что сообщают
ему его органы чувств. Аналогично, старайтесь не указывать принадлежность
конкретной персоне в названии предмета ("топор Беорна").

3.10) Внимательно прочтите все, что написано в справке к AWE по поводу качества
предметов и условий их получения. Не кладите вещи отличного качества там, где
их может взять кто угодно без всяких усилий. Вместо этого разработайте квест
на такой предмет и предусмотрите все, чтобы игрок мог получить награду только
после полного прохождения квеста.
   Не старайтесь понизить качество предмета и загнать его в требуемые рамки,
добавляя кучу ухудшающих качество аффектов. Будьте готовы к тому, что
бессмертные могут изменить часть созданных вами предметов при подготовке
зоны к подключению, если этого потребует баланс.

3.11) Если какой-нибудь предмет загружается в ходе квеста просто как реакция
на произнесенные игроком слова (например, лукошко для ягод, которое моб
выдает игроку, согласившемуся сходить за ягодами), обязательно установите
стоимость такого предмета равной нулю. То же самое относится ко всем другим
способам появления предмета в мире, допускающим получение без труда и 
за короткое время множества таких предметов.


4. Комнаты
----------

4.1) Не следует часто повторять одинаковые названия комнат, одинаковые или во
многом повторяющиеся описания. Подробно расписывать выходы и окна в описании
комнаты не надо, так как выходы можно увидеть по команде scan; [закрытые двери]
и <окна> автоматически выделяются в списке выходов.

4.2) Не забывайте указывать описания выходов (то, что показывает команда scan).
Нежелательно оставлять там название или описание комнаты, в которую ведет выход,
вместо этого упомяните, что видно в том направлении или что слышно оттуда.

4.3) Избегайте указывать направление под землей ("Туннель идет с севера на юг.")
и в местности, лишенной явных ориентиров, где легко заплутать.

4.4) Не забывайте расставить флаги nomob на тех выходах, которые соединяют
отдельные обособленные куски зоны. Это нужно для того, чтобы ограничить 
область, где будут бродить отдельные мобы. Как правило, это выглядит логично.
Например, в огороженном поселении дети не должны выходить за ограду, где на них
могли бы напасть дикие звери; служанка может гулять с половой тряпкой в доме
из комнаты в комнату, но оставаться в помещении, не выходить на улицу, даже
когда входная дверь открыта.

4.5) Правильно выберите тип комнаты и ее флаги. К примеру, если вы хотите
поместить закопанную вещь, тип комнаты должен позволять тут копать. Если это
комната, попасть в которую можно только после выполнения квеста или прохождения
какого-нибудь лабиринта, следует поставить флаг noastral, чтобы запретить
попадать сюда посредством магии перемещений в пространстве.

4.6) Флаг NOSUMMON нет необходимости ставить на комнатах с одним из флагов SAFE,
PRIVATE, SOLITARY, NORECALL. Из таких комнат призвать никого нельзя.


5. Программы
------------

5.1) Программы оживляют зону, делают ее интересной и оригинальной. В идеале 
автор зоны должен не только разработать программы, но и тщательно протестировать
их на локальной демо-версии Арды. Если вы испытываете серьезные сложности с 
написанием и отладкой программ, изложите хотя бы подробные их сценарии, чтобы 
ваши идеи реализовали те, кто будет проверять зону и готовить ее к подключению.
С возникшими вопросами обращайтесь к Head builder'у или тому, кто курирует
вашу работу. Описать все аспекты разработки программ в зонах и встречающиеся при
этом "подводные камни" в рамках этого руководства не представляется возможным.

5.2) Возьмите за правило всегда использовать в программах названия операторов,
обычные команды MUD и заклинания только полностью и только в английском
варианте. Не поленитесь посмотреть, как будет "улыб" по-английски и полностью.
Во-первых, демо-версия MUD, как правило, не во всем русифицирована, и какие-то
из русских команд могут не пройти. Во-вторых, английские названия, как правило,
менее подвержены изменениям с развитием MUD. Полные слова лучше воспринимаются
при анализе программ, и еще будет куда меньше путаницы с похожими заклинаниями.

5.3) Старайтесь писать программы с выравниванием по блокам, например:
  if ispc($n)
    if level($n)<20
    or hps($n)<200
      challenge $n
      say Сейчас Я тебе покажу, мелюзга!
    else
      say Сижу тихо, никого не трогаю!
    endif
  endif
В таком виде программы куда лучше воспринимаются.
   Размер программы не должен превышать 4 килобайт. В подавляющем большинстве
случаев этого достаточно. Старайтесь, по возможности, избегать повторов одних
и тех же групп операторов в разных ветвях программы (за счет рационального
использования проверок if и операторов else, or, and, break). Результатом будет
упрощение программы.

5.4) Не забывайте учитывать род в текстах программ: сказал$a, велико$z(го:й:го).
Старайтесь предусмотреть все возможные ситуации и варианты развития событий
в программах. Продумывайте это несколько раз. Что будет, если в комнате темно?
Что будет, если моб ослеплен? А если у него выкрали нужную вещь? Есть ли сейчас
в этой комнате моб, к которому нужно обратиться?
   Широко используйте проверку ispc($n) в программах - вообще ставьте ее везде,
где это не противоречит смыслу. Часто требуется проверить, не находится ли моб
в бою. Например, вряд ли он улыбнется вам в ответ на ваше "Привет", если в это
время вы его лупите дубиной (if isfight($i) ... else ... endif). Перед тем, как
что-то сделать в программе, поставьте соответствующую проверку.
   Помните о логике. Например, моб стоит у запертых ворот и ждет, когда игрок
даст ему потерянный ключ. Мобу нужно войти внутрь. Естественно, он должен
реагировать на открытые ворота и проходить туда, даже если ему не принесли
ключа.

5.5) Необходимо избегать множественных обращений мобов вслух в greet_prog, 
которые возникают при входе группы в комнату. С этой целью не надо использовать
в таких программах стандартные социалы, emote, say, mpecho, заменяя их mpechoat
(без соответствующих mpechoaround) и tell. Тем не менее, если моб делает что-то
явное, например, орет в голос или прыгает и размахивает топором, было бы вполне
естественно, если б это увидели все.

5.6) При старте программы на предмете или комнате управление передается особому
мобу VNUM 3 по имени "supermob супермоб". Он имеет примерно 50 уровень и
выполняет все операции в программе так же, как если бы программа стояла на
этом мобе. Он обладает рядом особенностей: видит все, даже закопанные вещи,
видит всех, а его действия, наоборот, игрокам не видны (флаг secretive). 
В программах на комнатах и предметах $i - супермоб. 
   Соответственно, загружать предмет в комнату в программе на комнате или другом
предмете нужно так:
  mpoload 10000
  drop sword10000
Если предмет нельзя взять, то в этом примере нужна только первая строка.
Здесь загружается предмет VNUM 10000 с ключевым словом sword10000.

5.7) Если вы хотите выполнить какое-нибудь агрессивное действие против
персонажа в программе на комнате или предмете, не забывайте, что при этом
может начаться бой между этим персонажем и супермобом (получится чепуха,
что-то вроде "Ударом кулака вы царапаете черное кольцо.").
Вот как надо делать, чтобы этого не случилось:
  mpasupress $n 2
  cast curse $n
  mppeace self

5.8) Если в программе игроку $n наносятся повреждения, выдайте все сообщения
о том, что происходит, "mpechoat $n" и "mpechoaround $n" ДО нанесения игроку
урона. Иначе, если он умрет (или сбежит за счет трусости), сообщения не будут
выданы. Например:
  mpechoat $n $I1 двинул вам в зубы!
  mpechoaround $n $I1 двинул $N3 в зубы!
  mpdamage $n 15
Если необходимо повреждать игрока заклинаниями или mpdamage несколько раз,
воспользуйтесь после первого повреждения проверкой "if insameroom($n)".

5.9) В программе на мобе $n - тот, с кем моб сражается. Тем не менее, если
вы в программе хотите использовать, к примеру, заклинание "огненный шар",
пишите "cast fireball", а не "cast fireball $n". Раз моб уже сражается, 
атакующее заклинание автоматически будет применено против его противника,
и первый вариант всегда сработает. А вот второй не сработает, если моб не
видит $n (например, ослеплен).

5.10) Как программно разместить в комнате спрятанную вещь.
Если вещь без флажка "взять", то все просто:
 mpat 26001 mpoload 26071
Иначе придется поступить так:
 mpoload 26071
 mpmset self flags secretive
 mpat 26001 drop stone26071
 mpmset self flags secretive
 mpat 26001 mposet stone26071 flags hidden
Камень VNUM 26071 имеет в списке ключевых слов "stone26071". В файле зоны флага 
hidden у предмета быть не должно. Загрузив предмет командой mpoload, далее 
c помощью mpmset временно делаем действия моба незаметными (не забудьте тут же 
снять флаг!) и бросаем камень в нужной комнате. Наконец, командой mposet ставим 
флаг hidden. Учтите, что незаметность требуется лишь тогда, когда программа 
размещена на мобе. В программах на комнатах и предметах все делает специальный
служебный моб - supermob, а все его действия и так незаметны.
Не забывайте делать в программе проверку на наличие этого предмета в комнате.

5.11) Как программно разместить в комнате закопанную вещь.
 mpoload 26071
 mpmset self flags secretive
 mpat 26034 drop stone26071
 mpat 26034 bury stone26071
 mpmset self flags secretive
Помните, что в комнате, где вы хотите закопать предмет, должно быть разрешено
копать! То есть комната должна быть соответствующего типа, например, field
или forest, причем без флага nodig.
Не забывайте делать в программе проверку на наличие этого предмета в комнате.

5.12) Правильный порядок операторов при перемещении игрока командой mptransfer:
 mpechoat $n Вас швырнуло в проход на севере.
 mpechoaround $n $N4 швырнуло в проход на севере.
 mptransfer $n 10001 show
 mpat 10001 mpechoaround $n $N1, кувыркаЯсь в воздухе, влетел$a с юга.
Если в этом примере третью строку поставить на другое место, будет ошибка.

5.13) Триггер look_prog на данный момент не поддерживается, триггер exa_prog
работает только на предметах.

5.14) Программа time_prog на комнате стартует в соответствующий час один раз
только для тех комнат, в которых есть хотя бы один персонаж (игрок или моб).
   Программа time_prog на мобе стартует в указанный час всегда.
   При старте MUD (например, при ежедневной перезагрузке) время устанавливается
в 1 час ночи. Это можно использовать в программах на мобах(!) для приведения
зон в начальное состояние, если по какой-то причине ресетами нужного эффекта
добиться нельзя. Например, если моб не обнаружил в комнате неберущийся предмет
в "time_prog 1", он может загрузить его.

5.15) Программа rand_prog 100 на комнате срабатывает с тиком по одному разу
на каждого игрока в комнате. Не разрешается злоупотреблять такими программами,
особенно на мобах (которые будут стартовать намного чаще) и на предметах
(которых можно собрать кучу) - в итоге будет тьма стартов программ, что может
сильно тормозить MUD. Вообще rand_prog рекомендуется использовать только
на комнатах, желательно - с параметрами не более 5-10. Можно при необходимости
использовать rand_prog с еще меньшими параметрами на мобах, число которых
в мире заведомо ограничено.
   В программе rand_prog на комнате можно использовать переменную $n - она 
попеременно принимает значение имени каждого игрока в комнате. Для каждого 
игрока программа выполняется один раз. Таким образом, следует писать не
"mpecho Подул ветерок.", а "mpechoat $n Подул ветерок.", иначе может выйти
так, что каждый игрок увидит сообщение несколько раз.
   Во всяком случае, если вам нужна программа "rand_prog 100", в ней смело
ставьте "mpechoat $n" вместо "mpecho" - вот так будет работать правильно.

5.16) Программа rand_prog 100 на предмете стартует с тиком один раз для каждого
предмета в комнате (если в данной зоне есть игроки) и инвентаре игрока или моба.
Однако, если предметы ПОЛНОСТЬЮ одинаковы и находятся в одном и том же месте,
они временно объединяются в один предмет (технически), и для таких предметов
программа стартует один раз. $o - данный предмет, $i - супермоб (он выполняет
все действия в программах на предметах и комнатах).

5.17) Если вам в программе требуется переменная $r, учтите следующее. Значение
$r присваивается при старте программы, это случайно выбранный игрок из всех,
кого ВИДИТ моб в текущей комнате (включая бессмертных). Поэтому, если моб
по ходу программы перемещается в другую комнату, $r не будет никак связано
с игроками в месте назначения.

5.18) Если переменная $r не определена (так будет, когда при старте программы
в той комнате, где находится моб $i, он не видит ни одного игрока) попытка
использовать ее приведет к следующему:
 - если $r используется в операторах, к примеру, "mpechoaround $r ...", 
   то MUD выдаст ошибку в лог, а исполнение программы продолжится;
 - если $r используется в проверке, например, "if isflying($r)", программа
   немедленно прекратится (исключение - проверка "isdefined");
 - если $r используется в обычных командах, например, "cast bless $r",
   будет то же самое, что и при указании отсутствующей цели (в данном
   случае - ничего не произойдет, а программа продолжится).
Чтобы избежать этого, перед использованием $r вставьте новую проверку 
 if isdefined($r)
  ...
 endif
и обращайтесь к $r только внутри данной ветки программы.
   Проверка "isdefined" отсутствует в демо-версии 1.2 Arda MUD.
   Обратите внимание: проверка "if mortcount(0) > 0" не дает гарантии,
что $r определена, поэтому используйте только проверку "isdefined".
   С помощью этой проверки можно также выяснить, присвоены ли значения
другим переменным. Как правило, для каждого триггера заранее известно,
определены ли $n и $o, а $i определена всегда. Переменные $t и $p могут
обрабатываться только в act_prog и также, вообще говоря, могут быть
не определены.

5.19) Тщательно проверьте все программы на демо-версии движка Арда MUD, которую
можно скачать тут: http://www.arda.pp.ru/build/release.exe

--------------------------------------------------------------------------------

Желаем вам удачи! Доставьте себе удовольствие, создавая кусочек нашего игрового
мира. Доставьте удовольствие всем игрокам, кто будет исследовать вашу зону 
в Арде. Если вы считаете, что новые зоны у нас появляются редко, вы можете нам
помочь. Постройте свои зоны, наберитесь опыта и приходите к нам, чтобы помочь
квалифицированно проверять и доводить игровые зоны. Мы будем вам рады!

Составители: 
Аланна,  alanna@mail.ru
Эстэль,  rosella9090@mail.ru