Animus - Вклад участника [ru]

Обсуждение:Guide to food/Bay12

2015-12-04T11:14:34Z

IXVI:

Ещё один клоун, сука! Призываю Рецея! [[Участник:Alexix|Alexix]] ([[Обсуждение участника:Alexix|обсуждение]]) 11:30, 29 ноября 2015 (MSK)

Сам ты пармизан [[Участник:Alexix|Alexix]] ([[Обсуждение участника:Alexix|обсуждение]]) 13:31, 4 декабря 2015 (MSK)

От пармижаны слышу [[Участник:IXVI|IXVI]] ([[Обсуждение участника:IXVI|обсуждение]]) 15:14, 4 декабря 2015 (MSK)

Roboticist

2015-11-28T17:40:36Z

IXVI: /* Подсказки */ Какие такие же картинки, коопер?

Chief Medical Officer

2015-11-28T17:31:40Z

IXVI:

{{Заготовка}}
{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:lightblue;" width=200|Профессия
!style="background-color:lightblue;" |Описание
!style="background-color:lightblue;" width=100|Сложность

|-
![[File:Jobcmed.png]] [[Chief Medical Officer|Глава медперсонала]]
|'''Доступ:''' Medbay; Bridge
'''Подчинение:''' [[Captain]]

'''Обязанности:''' Контроль медицинского персонала

'''Руководства:''' [[Chain of Command]], [[Guide to Medicine]], [[Guide to Virology]], [[Guide to Genetics]], [[Chemist|Guide to Drugs]], [[Guide to Surgery]]
!Средне
|}

''Мы ведь не знаем, что внутри у щенка и что он чувствует. Может, это тоже притворство.'' '''''Исаак Айзимов, "Я Робот"'''''

[[File:Chief Medical Officer's Office.png|frame|Ваш офис]]

== [https://www.youtube.com/watch?v=xxPDnCx0Ju0 Доктор Айболит] ==
Поздравляем! Вы назначены на должность главы всего медицинского персонала станции! Что может быть лучше, чем лечить людей? Правильно, [https://www.youtube.com/watch?v=MfXiBtXNJGo быть начальником тех, кто лечит людей]! А что может быть лучше, чем быть просто начальником тех, кто лечит людей? Правильно - делать это на станции, оборудованной по последнему слову техники, такой как наша Станция 13. Она абсолютно безопасна для своих обитателей, так что, скорее всего вся ваша работа будет заключаться в обработке небольших царапин и ожогов. Но и это будет увлекательно в окружении тщательно подобранных исполнительных и доброжелательных работников. Так что ваша смена пройдет абсолютно спокойно. Но всё равно следует прочитать должностные инструкции, чтобы было что рассказать внукам.

== Медицина ==
'''Статьи по теме:''' [[Guide to Medicine]].

Учитывая количество [[Medical Doctor|высококлассных врачей]], нанимающихся в корпорацию НаноТрасен, скорее всего ваши обязанности будут заключаться в управлении, а не непосредственной работе с пациентами. Однако, при неудачном стечении обстоятельств (то есть почти всегда) вы должны быть готовы самостоятельно выполнять часть работы ваших подчиненных. Поэтому рекомендуется сразу собрать себе медицинский пояс с самыми необходимыми препаратами. С собой лучше всегда носить анализатор здоровья или переключить свой ПДА в режим анализатора. Также вы должны проконтролировать выполнение следующих пунктов:

*В начале смены криокамеры должны быть включены и настроены. Часто это значит, что вам придётся сделать это самостоятельно, до прибытия прочего персонала.

*В любой момент времени в приёмной должен сидеть работник. Никому не будет приятно прийти в медотсек с ранением и наткнуться там только на закрытую дверь и несколько собратьев по несчастью.

*Также всегда должно быть хотя бы два врача, готовых сорваться на выезд. Это добавит благодарных клиентов и, в идеале, лишит генетиков части работы.

*Удостоверьтесь, что рассеянные хирурги не прихватили с собой пару инструментов из операционной. Ситуация, когда человеку нужно срочно вырезать аппендицит, а скальпель непонятно где, может плохо закончиться.

*Этот пункт не обязателен, но работать будет гораздо удобнее, если перед сменой настроить медицинского робота. Наполните его трикордразином и отправьте в приёмную.

== Химия ==
'''Основная статья:''' [[Chemist|Guide to Chemistry]]

В отличие от врачей, [[Chemist|химики]] часто оказываются в дефиците, так что вам, скорее всего, придётся посвятить химии часть своего времени. Так или иначе, нужно следить за запасами базовых медикаментов (инапровалин, келотан, дексалин, анти-токсин) и своевременно их пополнять. Также неплохая идея иметь в запасе трикордразин. В целом, нужно подстраиваться под текущую ситуацию (например, если на станции пожар, не помешает дермалин, а если генетики сильно напортачили – то риеталин). Не помешает и раздать главам баночки с таблетками на случай внештатного происшествия. Помимо вышеперечисленного, химики могут заниматься чем угодно, исключая разве что наркотики или боевые гранаты, но тщательно отобранные сотрудники вряд ли будут делать что-то подобное.

== Генетика ==
'''Статьи по теме:''' [[Guide to Genetics]].

[[Geneticist|Генетики]] подчиняются не только вам, но и [[Research Director|руководителю исследований]]. Скорее всего вам придётся использовать этот отдел разве что для лечения генетических заболеваний и мутаций, которые нередко возникают у инженеров из-за работы с сингулярностью. Конечно, генетики также могут и клонировать погибших членов экипажа, но наши квалифицированные медики не дадут никому умереть. Также на случай ЧП рекомендуется хранить записи генов хотя бы самых важных людей на станции (конечно же вас в первую очередь).

'''''Важно! Главный врач занимается координацией лечения пострадавшего персонала. Хоть вас и учили пользоваться генетическими консолями для излечения разнообразных генетических болезней, вам всё-равно не стоит пытаться исследовать гены и открывать новые мутации - оставьте это баловство [[Research Director|директору по исследованиям]] и [[Geneticist|генетикам]], а сами займитесь действительно полезной работой.'''''

== Вирусология ==
'''Статьи по теме:''' [[Guide to Virology]].

Тут всё просто. Если [[Virologist|вирусологов]] нет – не заморачивайтесь вообще по поводу этого отсека (''хотя регулярные проверки не помешают, ведь пустой отсек на отшибе – удобное место для того, чтобы всяким глупым ассистентам там скрываться от своей работы''). Если вирусологи есть – заходите иногда, проверяйте, что отсек чист, шлюз закрыт, а обезьяны в клетке. В случае, если они просят вашим доступом открыть им ящик с вирусами, убедитесь в их компетентности, попросив изготовить вакцину от гриппа или простуды. Вот и все, что вы должны делать с этим отсеком, кроме случаев эпидемий, конечно, когда вы должны произвести вакцину и распространить её по станции или проследить чтобы это сделали вирусологи.

== Чистота - залог здоровья ==
Ещё одна важная вещь – поддерживайте в отсеке чистоту. Пол, залитый кровью и блевотиной может послужить развитию ужасных заболеваний или появлению грызунов, насекомых и назойливых инспекторов. Остальные, вероятно, будут слишком заняты, так что проследить за этим придётся вам. На наших станциях есть замечательные уборщики, которые всегда готовы помочь вам и отмыть отсек до сияющей белизны. Химики вполне могут изготовить чистящее средство, а в особо запущенных случаях – и чистящую гранату. Так же неплохо с самого начала смены заказать у робототехника одного робота-уборщика.

== Администрирование ==
Не стоит забывать что вы, всё-таки, глава. Поэтому вам нужно участвовать в принятии важных решений относительно станции и собраниях командного состава. Вы, вместе с [[Chief Engineer|главным инженером]] и [[Research Director|директором по исследованиям]], имеете самое низкое звание среди всех глав, но в маловероятной ситуации, что вы единственный из начальства на станции, вам придётся взять на себя командование. Также вам придётся решать, принимать ли в отдел новых сотрудников (не забывайте устраивать им проверки), ставить свою печать на заказах квартирмейстеру от вашего персонала, а также на бумагах с данными о вскрытии, заказах в химию и прочих документах. Учитывая безопасность станции, именно в администрировании будет заключаться большая часть вашей работы.

=== ВРЕМЯ КОММУНИЗМА ===
Медбей - худшее место для нахождения при мятеже, и высоки шансы того, что вашу голову оторвут первой. Если люди странно себя ведут или начинают дебоширить, вооружите себя ''хоть чем-то'' как можно скорее, будьте готовы убежать из медбея в ''любое время''. Ваша телескопическая дубинка - лучший способ самозащиты, вы можете держать обездвиженным одного врага, но абсолютно бессильны против групп, а если кто-то выбьет её из рук, то вероятность остаться с головой крайне мала. Гипоспрей хороший выбор: помните, двадцать единиц хлоралгидрата усыпит любого надолго. Прочие возможные оружия, такие как огнетушитель, топор с мостика, пульверизатор со смазкой дадут выиграть вам время. Используйте шприцемёт для обороны на расстоянии.
Люди видят вас слабым, вы хорошая цель для предателя, жаждущему доступ на мостик. Будьте осторожны.

==Подсказки==
* Заправьте в ваш гипоспрей salbumatol или epinephrine. Теперь, когда вы увидите умирающего человека просто используйте гипоспрей на нем. В чате появится сообщение, схожее с тем, когда [[Changeling|перевёртыш]] питается жизнью человека. Таким образом, люди вокруг будут считать что '''ОБОЖЕМОЙ СМО ПЕРЕВЕРТЫШ, ДОСТАВАЙТЕ ОГНЕМЕТ!!!'''. И это весело.
* Переместите Crew Monitoring Console из вашего кабинета в ординаторскую, и [[Medical_Doctor|простые смертные]] смогут пользоваться ею.

[[Category:Luna]]
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]

{{JobMenu}}

Virologist

2015-11-28T17:15:29Z

IXVI: Ага, молодец, а теперь верни орфографические и пунктуационные правки, нахуя ты откатил версию? Совсем обнаглел?

Virologist

2015-11-28T16:53:55Z

IXVI:

Scientist

2015-11-28T16:53:15Z

IXVI:

Roboticist

2015-11-28T16:51:43Z

IXVI:

Geneticist

2015-11-28T16:50:45Z

IXVI:

{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:#DDA0DD;" width=200|Профессия
!style="background-color:#DDA0DD;" |Роль
!style="background-color:#DDA0DD;" width=100|Сложность

|-
![[File:Jobgen.png]] [[Geneticist|Генетик]]
|'''Доступ:''' Medbay; Morgue; Genetics

'''Подчинение:''' [[Chief Medical Officer]]

'''Обязанности:''' Изучать гены, клонировать умерших, усовершенствовать живых

'''Guides:''' [[Guide to Genetics]]
!Средне
|}

''Бог – это эхо наших собственных дел.'' '''''Выписка из учебника по генетике'''''

[[File:Gen.PNG|frame|right|Генетика. Трудно быть Богом.]]

= Приятно познакомиться, Бог =

'''Кто такой Бог? Какова его роль? Что он может?'''

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

== Генетика как она есть ==

По сути же, генетик - один из самых полезных людей в случае чрезвычайной ситуации на станции, ну или при обнаружении [http://lurkmore.to/Неведомая_ёбаная_хуйня НЕХ]. В первом случае генетик сможет быстро восстановить человеческие ресурсы, потерянные в битве с возникшей внештатной ситуацией, при помощи своего суперсовременного оборудования для клонирования: оно позволяет поставить клонирование людей чуть ли не на конвейерную ленту, а продукцию на выходе вы не сможете отличить от оригинала!

Также, генетик имеет возможность "улучшать" экипаж с помощью открытых им суперсил, но здесь стоит заметить что исследование новых сил не подходит под юрисдикцию медицинского отсека, а потому на этом фронте вашим командующим будет уже [[Research_Director|Директор по исследованиям]]. Поскольку в целях безопасности настоятельно не рекомендуется испытывать новые гены на себе, корпорация предоставляет вам целый вольер, набитый специально отобранными мартышками: их гены абсолютно чисты от каких-либо дефектов, а потому вы можете использовать их для своих экспериментов и быть полностью уверенным, что любой косяк это исключительно ваша вина.

'''Запомните, согласно уставу корпорации, вы не имеете права колоть кому-либо модифицированные гены''' без разрешения [[Research_Director|Директора по исследованиям]], [[Captain|Капитана]], или [[Head of Personnel|Главы персонала]], а также согласия на проведение генной терапии от человека, с которым она будет происходить, и его непосредственного начальника.
Данное нарушение расценивается как превышение должностных полномочий и карается [[Space Law|законом]].

===А что это?===

Генетик в своем роде уникальная профессия, у вас будет сразу два начальника - [[Chief_Medical_Officer|Старший медицинский офицер]] и [[Research_Director|Директор исследований]], и вдвое больше ответственности - ведь вам придется работать на два отдела, но в этом есть и свои плюсы: вдвое больше премиальных (если вы конечно будете работать вдвое усерднее), а еще возможность поиграть в Бога. Это явно того стоит.

'''Но с чем же мне придётся работать?''' Естественно, что только с лучшим оборудованием которое у нас есть, ну почти. У вас будет: два новеньких модификатора генов; целый вольер с подопытными обезьянами, оборудованный по последнему слову техники; свои шкафчики для: белья, медикаментов, пациентов и много других; а также ультрасовременный под для клонирования, который сделает вашу работу незабываемо легкой - НаноТразен заботится обо всех своих сотрудниках. 

==Советы==
* Если клонирование изменило ваш внешний вид, положите своё старое тело в сканер ДНК, запишите UI/UE в инжектор и вколите его себе. После этого к вам вернётся ваша старая внешность.
* Если у кого-то имплант в теле, его можно уничтожить, превратив тело в мартышку и обратно.
* Клонер изначально создаёт клонов со 190 ед. генетического урона и 99% повреждением мозга. До 40% генетического урона могут быть вылечены введением уникальных генов. Клонер тратит 2,5 минуты на изготовление клона. Извлечение клона на 40%, и последующее лечение его в криотрубе ускоряет процесс на несколько секунд, но это не значит, что вы можете клонировать двух человек одновременно.. Извлечение клона на 40%, отключение АПЦ или взлом клонера Е-Магом, а затем лечение клона в криокамере даёт ускорение процесса в 2 раза, и позволяет клонировать до 3-х человек одновременно.
* Отключение питания клонера выбрасывает клона, вне зависимости от состояния. Это можно использовать для быстрого клонирования: клонируйте человека на 25%, положите в крио, повторите с другим телом, и клонируйте третьего, пока одна из криокамер не освободится, повторите всё сначала.
* Превращение клона в мартышку вылечит его.
* The Genetics DNA altering console can spit out injectors for UEs and UIs as well as SEs. This means that, if you get a willing volunteer or even just human a monkey, you can run around the station changing everyone into the same person (if you do this without being antag or having people’s con-sent, you will get banned).
* You can put disks into the cloning computer to save the UI, UE and SE of people scanned.
* Водка хорошо выводит радиацию из крови.
* Генетические силы могут проявить изменения SE. Большинство людей вводят себе инжектор раз за разом, для получения сил. Но есть другой способ: положите человека в сканер, измените длительность и мощность излучения на 1/1, и облучайте случайные блоки. Таким образом, вы измените много блоков, и почти не получите радиации. Тем не менее, такой способ может вызвать случайные болезни, так что убедитесь что у вас есть чистый SE. Так же обратите внимание на значения блоков.
** Используйте "безопасный" блок и излучение 1/1. Безопасный блок - блок со значением 333-4bb. Тогда вам не слишком часто придётся сбрасывать SE.
* Радиация, а также радиационные штормы и мутаген имеют очень, ОЧЕНЬ небольшой шанс на положительные последствия. Скорее вы получите болезнь, чем суперсилу.
* Для улучшенного сканера самым оптимальным режимом является длительность излучения 4.

'''Трудитесь на благо вашей Корпорации и она позаботится о вас. © НаноТразен'''

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]

Chemist

2015-11-28T16:50:00Z

IXVI:

{{Заготовка}}
{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:#DDA0DD;" width=200|Профессия
!style="background-color:#DDA0DD;" |Роль
!style="background-color:#DDA0DD;" width=100|Сложность

|-
![[File:Jobchem.png]] [[Chemist|Химик]]
|'''Доступ:''' Medbay, Chemistry

'''Подчинение:''' [[Chief Medical Officer]]

'''Обязанности:''' Смешивать химикаты и делать препараты

'''Guides:''' [[Guide to Medicine]], [[Guide to Сhemistry]]
!Средне
|}

''Чтобы восстановить здоровье необходимо смешать любые два из следующих ингредиентов: болотный тростник, виквит и канифоль. При правильном приготовлении побочных эффектов не наблюдается. Простое снадобье для снятия усталости - смешать скрибовое-желе и скаттл. Чтобы снадобье было сильнее, вместо желе используйте мясо гончей. Однако, мясо придает смеси отвратительный вкус. Покупатели обычно предпочитают вкусные снадобья более эффективным.'' '''''Алхимический рецепт с одной из отдалённых планет'''''
[[File:Chemistry.png|280px|right|thumb|Место где происходят самые правдоподобные химические реакции]]

=== Долг зовёт ===

У вас, как у химика, есть несколько обязанностей. Давайте разберём их.
* Снабжать врачей и генетиков лекарствами по их первому требованию. Лучше, конечно, заранее приготовить несколько баночек, чтобы вы не метались по лаборатории в случае ЧП. Что вам понадобится? Если врачей мало - сварите криоксадон, крио будет работать без передыха. Если есть генетики - то варите алкизин и риталин, иначе напора падающих и ругающихся клонированных на ваш кабинет не избежать.
* Наливать ученым, и иногда роботехникам в колбы серную кислоту, она им требуется для травления плат. Ни в коем случае не отдавайте им свои большие колбы - никогда не вернут, пусть приходят со свей тарой.
* Выдавать ботаникам мутаген и аммиак, вы же хотите есть вкусную морковку у повара?
* Заполнять разбрызгиватель уборщика Спейс Клинером, во имя чистоты станции.
* Наливать клоуну Спейс Луб. Ну, это ваш долг.
* Всё остальное. Ассистент, просящий бикардинчику после драки, ХоС, требующий синаптизин, варден, выпрашивающий трик для химимплантов - каждая смена уникальна!

=== Наука! ===

Помните, химия - тоже наука, и пусть вам не выдали доступ в научный отдел, и ваша зарплата на порядок ниже этих тунеядцев в фиолетовом, вы можете экспериментировать! Обычно эксперименты начинаются со смесей для быстрого выведения из критического состояния. Идеал данной смеси - когда вам не нужен даже анализатор, вы просто колите одно и тоже замороженным, расстрелянным и избитым.
Извечная тема спора химиков - боевой коктейль. Смесь, которая превращает вас в универсального солдата, даёт вам скорость и силу. Не забывайте добавлять в неё лечащие компоненты.
А дальше химик открывает для себя гранаты с дымом, и тут он пропадает для мира. Ведь граната с дымом - это быстрое введение любых веществ всем в зоне поражения - а это приличных размеров отсек.
Помните, что для увеличения поражающей способности гранат вы можете выпросить у ученых корпус большой гранаты, в которую влезает намного больше веществ.
И ещё, когда вам все это наскучит: до нас дошли слухи об отдаленных станциях, где гениальные химики создают смеси, которые позволяют находиться в космосе без специальных приспособлений. Все эти смеси связаны общим именем, они названы в честь ученого, который первый массово их использовал, и, может быть, даже открыл. Запомните это название: Хаусин.

== Делайте всё правильно ==
Химики очень подозрительные личности. У них есть все средства в мире чтобы уничтожить его в перерыве между ужасными и бесчеловечными убийствами. И самый лёгкий способ избежать подозрений (если вы конечно делаете что либо подозрительное)- это представить себя в лучшем свете и быть полезным станции в начале игры. И любой инцидент спишут на вашего коллегу, если он у вас конечно же есть.

=== Инструменты торговли ===
* Chem Dispenser - переводит электроэнергию в различные химические элементы , благодаря <s>магии</s> науке. Это один из самых незаменимых приборов на станции, сохраните его даже ценой ценой своей жизни.
* ChemMaster 3000 - может магическим образом отделять одни вещества от других, и имеет неограниченный запас пилюль/повязок (по 50 единиц вместимости) и бутылочек ( по 30 ед.).
* Reagent Grinder - такой же блендер как и у Повара. Может извлекать реагенты из вещей принесённых Шахтёрами, Поварами, и Ботаниками.
* Chemical Heater - нужен для создания многих рецептов требующих высокие температуры.
* Внутри шкафчика севернее вас вы найдёте коробку с банками для пилюль. На столе южнее лежит маркировщик. Используйте их для более удобного и эффективного хранения и распространения пилюль.

=== Будь полезным ===
==== Начало раунда ====
'''Если кто-то приходит и просит у вас что-либо обслужите его первым. Никто не любит стоять в очереди. Если вы почти изготовили что-то необходимое вашему клиенту проинформируйте его о готовности.'''

* Для [[Roboticist|Роботехник]]ов и [[Scientist|РнД]]:
** Наполните большую банку 100 ед. серной кислоты, отдайте им и повторите снова.

* Для всей команды и особенно для [[Medical Doctor|Доктор]]ов:
** Сделайте [[Guide to Сhemistry/tg|кровоостанавливающий порошок, сульфадиазин серебра, синтезированную плоть, и активированный уголь]]. Наркотики как salbutmol и адреналин полезны, но ненужны .
** Положите на передний стол или в хим. хранилище под вашей лабораторией.

* Пилюли/повязки для раненых:
*** Кровоостанавливающий порошок (Aluminum, Hydrogen, Oxygen, Sulfuric Acid - лечит физ. повреждения)
*** Сульфадиазин серебра (Ammonia, Silver, Sulfur, Oxygen, Chlorine - лечит ожоги)
*** Синтезированная плоть (Styptic Powder, Carbon, Blood - лечит физ. повреждения и ожоги)
*** Активированный уголь (Ash and Table Salt - от интоксикации)
*** Сальбутамол (Salicylic Acid, Lithium, Bromine, Ammonia, Aluminum - лечит удушье)

* Для [[Atmospheric Technician|Атмосферников]] и [[Station Engineer|Инженеров]] припасено то, что поможет быстро заделать обшивку станции:
** Сделайте 30 ед. вспенивателя и фторсульфоновой кислоты, разлейте по 10 ед. в 3 банки.
** Сделайте 90 ед. железа, разлейте по 30 ед. в 3 другие банки.
** Поместите одну банку вспенивателя с кислотой и ещё одну банку железа в гранату - это граната с железной пеной, если вы сделали всё правильно у вас должно получиться 3 таких гранаты.

==== Если вы хотите быть на высоте ====
* [[Botanist|Ботаники]] будут восхищаться вами если достанете им мутагена для мутаций растений. Так же они могут использовать диэтиламин как удобрение, [[Guide_to_Сhemistry/tg#Fluorosulfuric Acid|фтороносерную кислоту]] как эффективный способ уничтожения растений, пипетку для точных мутаций и [[Guide_to_Сhemistry/tg#Space_Cleaner|чистящее средство]] для очистки места от растворённых растений.
* [[Virologist|Вирусологи]] будут ждать от вас [[Guide_to_Сhemistry/tg#Unstable_Mutagen|мутагена]] и [[Guide_to_Сhemistry/tg#Synaptizine|синаптизина]] для создания новых вирусов.
* [[Geneticist|Генетики]] могут извлечь выгоду от запаса [[Guide_to_Сhemistry/tg#Potassium_Iodide|иодида калия]] или таблеток [[Guide_to_Сhemistry/tg#Charcoal|активированного угля]] для лечения высокой радиации у себя и своих подопытных.
* [[Janitor|Уборщики]] могут попросить вас заправить их пульверизатор с [[Guide_to_Сhemistry/tg#Space_Cleaner|чистящим средством]], особенно если вирусолог заразил весь экипаж и вокруг много блевотины.
* Можете помочь [[Chef|Повару]] таким способом: серная кислота для соевого соуса.
* [[Bartender|Бармен]] может попросить химикатов для коктейлей. Но учтите, что бармен может попросить ядохимикат, и лучше ему его не давать.
* [[Warden|Смотритель]] захочет препаратов для имплантирования арестантам, чтобы те не сопротивлялись.
* Измельчите еду, для того, чтобы сделать таблетки с питательными веществами, затем усмехнитесь над [[Chef|Поваром]].
* В момент побега [[Terminology#Hulk|Халка]] из генетики возьмите шприц с [[Guide_to_Сhemistry/tg#Mutadone|мутадоном]] и [[Guide_to_Сhemistry/tg#Chloral_Hydrate|хлоралгидратом]], зарядите в шприцемет и попадите в него. Ему станет грустно.
* Если [[AI|ИИ]] свихнулся, или на станции улей [[Alien|ксеноморфов]], вас могут попросить [[Guide_to_Сhemistry/tg#Thermite|термит]], с помощью которого можно прожечь укрепленные или органические стены.
* Включите сканер содержимого на вашем [[PDA|КПК]] и проверьте еду с напитками в баре и кухне на яд. Так же, это можно использовать на людях, чтобы проверить чем они отравились.
* Вы, всё-таки, относитесь к [[Medical Doctor|врачам]]. Когда они отсутствуют - берите анализатор здоровья и начните помогать пациентам.
* Если вам СОВСЕМ нечего делать, создайте лекарственные таблетки и пластыри, поместите их на прилавок медбея.
* [[Clown|Клоун]] обязательно попросит [[Guide_to_Сhemistry/tg#Space_Lube|смазку]]. Смейтесь ему в лицо и не давайте ему её.

=== Вооружение себя===
* Возьмите шприцемёт на столе западнее входа в медбей прежде чем доктора сделают это. Они ничего не смогут сделать с ним, но в ваших руках он станет ценным оружием, можете наполнить его [[Guide to Сhemistry/tg|хлоралгидратом или хуже]]. Если вы не успели - можете попытаться проскользнуть на мед. склад и взять там второй.
* Позже ближе к концу раунда, если вы сдружились с РнД, они могут дать вам улучшенную версию которая может держать в себе шесть шприцов если вы вежливо попросите об этом.
* Спрей из под отчистителя сойдёт за самодельный огнемёт если наполните его [[Guide to Сhemistry/tg|трехфтористым хлором]].
* У вас есть все инструменты чтобы изготавливать гранаты. См. ниже.

===Химия 101===
В [[Guide to chemistry|гайде по химии]] есть список всех возможных веществ.

{{anchor|Grenades}}

===Гранаты===
Будучи химиком - вы единственный человек, имеющий доступ к гранатам. Можете поместить 2 пробирки с ЧЕМ-УГОДНО, в любую заготовку для гранаты. Выньте их, если необходимо, кликнув по гранате в руке. Очевидно, что пробирки взорвутся при взрыве гранаты. Вы можете сделать лечащую, вредную, любую гранату. Экспериментируйте! В конце концов, что за наука без опыта?
'''ОБЯЗАТЕЛЬНО ПОМНИТЕ'''. За вредные гранаты вас могут избить или убить, еще вы можете получить джоббан, не имея [[Traitor|спецроли]].

====Создание гранат 101====
#Возьмите провода со стола.
#Вставьте провода в каркас гранаты.
#Вставьте в гранату пробирки с химикатами. Две - максимум.
#Можете завершать гранату, закрутив ее отверткой, или вставив таймер, открутив его, затем вставив в гранату и только потом ее закрутить.
#Активируйте гранату, кидайте.

Для реакций, которые идут только будучи смешанными, разделите их на 2 пробирки и вставьте в гранату. Для ознакомления, прочтите [[Guide to chemistry]].

===Таблетки и пластыри===
Таблетки - отличный способ дать ощутимое количество лекарств за раз. Таблетка может содержать 50 единиц химикатов, а в коробочке для таблеток их может быть 7! А сами коробочки можно хранить в карманах. Пластыри схожи с таблетками, но работают "наружно". Препараты, как [[Guide_to_Сhemistry/tg#Synthflesh|синтифлеш]] и [[Guide_to_Сhemistry/tg#Styptic_Powder|кровоостанавливающий порошок]] будут лечить только в пластырях, и вызывать отравление при приёме таблетками.

==== Химикаты в таблетки или пластыри ====
* [[Guide_to_Сhemistry/tg#Epinephrine|Адреналин]] для стабилизации критически раненых.
* [[Guide_to_Сhemistry/tg#Charcoal|Активированный уголь]] для вывода ядов.
* [[Guide_to_Сhemistry/tg#Styptic_Powder|Кровоостанавливающий порошок]] лечить физические повреждения.
* [[Guide_to_Сhemistry/tg#Silver_Sulfadiazine|Cульфадиазин Cеребра]] - лечить ожоги.
* [[Guide_to_Сhemistry/tg#Mannitol|Маннитол]] лечит повреждения мозга.
* [[Guide_to_Сhemistry/tg#Oculine|Окулин]] лечит ''физические'' повреждения глаз.
* [[Guide_to_Сhemistry/tg#Inacusiate|Инакусит]] убирает глухоту.
* [[Guide_to_Сhemistry/tg#Synaptizine|Синаптизин]] снижает длительность оглушения, но наносит урон ядом.
* Смесь [[Guide_to_Сhemistry/tg#Leporazine|лепоразина]] и [[Guide_to_Сhemistry/tg#Salbutamol|салбутамола]] позволит дольше прожить в космосе без скафандра.
* Не создавайте только [[Guide_to_Сhemistry/tg#Synthflesh|синтифлеш]], иначе вас будут ненавидеть. Пусть он и лечит ожоги и синяки, он не так полезен в одиночку. Смешивайте их с чем-то.
* Таблетка с [[Guide_to_Сhemistry/tg#Mutadone|мутадоном]] убирает все генетические дефекты и суперсилы. Полезно для свежих клонов.
* Если [[Virologist|вирусолог]] придет с вакциной, хватит и 1 единицы препарата для лечения в таблетках.

===Bottles(Бутыльки)===
Бутылочки нужны для содержания веществ не являющихся лекарствами, такими как кислоты, или лекарств которые вы планируете использовать позже, такие как криоксадон. Каждая бутылка может содержать 30 ед., и её можно выплеснуть на что-либо. Они могут быть произведены в любых количествах в вашем ''ChemMaster''"е, так что можете сходить с ума.
* Термит
* Кислоты
* Cryoxadone
* Space cleaner
* Лекарства, основанные на прикосновении

==Советы==
* Эффект [[Guide_to_Сhemistry/tg#Chloral_Hydrate|хлоралгидрата]] не сработает, если вы были под кофе. Но вы всё ещё будете получать урон от передозировки. [[Guide_to_Сhemistry/tg#Charcoal|Антитоксин]] абсолютно аннулирует эффект хлоралгидрата.
* Эффекты разных химикатов сочетаются, это значит, что вы можете сделать пластырь из [[Guide_to_Сhemistry/tg#Silver_Sulfadiazine|сульфидиазина]] и [[Guide_to_Сhemistry/tg#Synthflesh|синтифлеша]]. Добавьте немного [[Guide_to_Сhemistry/tg#Omnizine|омнизина]] во время готовки лекарственных препаратов.
* [[Guide_to_Сhemistry/tg#Foaming_Agent|Пена]] и [[Guide_to_Сhemistry/tg#Smoke|дым]] берут свойства реагентов. Пена произведет эффект реагента при наружном применении, а дым - при применении вовнутрь. Пена из [[Guide_to_Сhemistry/tg#Synthflesh|синтифлеша]] вылечит из критического состояния моментально, а из [[Guide_to_Сhemistry/tg#Fluorosulfuric Acid|фторосерной кислоты]] - убьет жертв ''незамедлительно''.
* Гранаты шикарны со всем. Экспериментируйте!
* Вы можете заправить пульверизатор синтифлешем для переносного лечения!
* Если вы размельчите '''разогретый''' donk pocket, попросите у капеллана святой воды, то сможете создать [[Guide_to_Сhemistry/tg#Strange_Reagent|странный реагент]], который может буквально привести к жизни труп. Смейтесь над генетиками, клонирование стало не нужным. Кстати, его можно разбавить, потому что нужно всего 0.4 единицы для воскрешения.
* Учтите, что странный реагент может оживить кого-то у кого меньше 100 физического урона и меньше 100 от ожогов. Это не сочетается. Труп с 99 того и 99 другого можно оживить.
* Препараты, нацеленные на наружное применение, '''РАБОТАЮТ''' для мертвых. Сделайте гранату из странного реагента и синтифлеша, киньте в кучу трупов, и наблюдайте как они восстают из мертвых. [[Traitor|Предатели]] разозлятся.
* Вам не обязательно делать гранату для пены. [[Guide_to_Сhemistry/tg#Foam_Surfactant|Пенообразователь]] в одной пробирке и вода в другой с сочетанием 1:1, смешайте - будет вам пена.
* Приемная выглядит как после резни? Приготовьте пену из [[Guide_to_Сhemistry/tg#Space_Cleaner|чистящего средства]], узрите, насколько стало чисто.

{{JobMenu}}

Обсуждение:Guide to Posters

2015-11-19T21:36:16Z

IXVI: FY

*Что? Гайд к постерам, который переводит их текст? МОжет, еще запилим гайд к, ну я не знаю, НАДПИСИ У МОСТИКА? Который описывает, что на ней можно писать про ХоСа, как писать, как снимать там плитку и как она переводится? А еще переводим "репер" как "насильник", еще несколько фактических ошибок. Короче - абсолютно бессмысленная статья, созданная ради ОЧКОВ ВИКИ))))), заремувьте ее, пожалуйста. [[Участник:UcnaHez|UcnaHez]] ([[Обсуждение участника:UcnaHez|обсуждение]]) 17:17, 18 ноября 2015 (MSK)
**Увидел ангельский текст в статье - перевёл. На счёт насильника ошибся, бывает (для такого и создана волшебная кнопка "править"). А в общем да, статья достаточно бесполезна, я тоже вот смысла в ней не вижу. - [[Участник: Feomatar|Feomatar]] 16:36, 18 ноября 2015 (MSK)
**Я о том, что единственная нагрузка в этой статье - перевод ТЕКСТА ИЗ ИГРЫ. То есть это прям ну совсем полный идиотизьм. А править статью, которая не нужна - глупо. [[Участник:UcnaHez|UcnaHez]] ([[Обсуждение участника:UcnaHez|обсуждение]]) 21:20, 18 ноября 2015 (MSK)

*Ублюдки блядь, вы что делаете нахуй? Что это за параша? Гайд по ПЛАКАТАМ? Вы что, ебанутые, блядь? Пиздеееец. Просто пиздец. При прошлом конкурсе такой хуиты было мало. Я ебал просто. Идите нахуй. [[Участник:Alexix|Alexix]] ([[Обсуждение участника:Alexix|обсуждение]]) 01:43, 19 ноября 2015 (MSK)

*Всем нравится, идите нахуй. [[Участник:IXVI|IXVI]] ([[Обсуждение участника:IXVI|обсуждение]]) 00:34, 20 ноября 2015 (MSK) Идите нахуй дважды, блять.

*Всем это кому? Поясните пожалуйста.--[[Участник:Recei|Recei]] ([[Обсуждение участника:Recei|обсуждение]]) 00:42, 20 ноября 2015 (MSK)

*Запустите голосование в группе ss13 на сайте vk.com, и посмотрите результаты, прошу вас. Всем - это подавляющему большинству, да здравствует демократия. [[Участник:IXVI|IXVI]] ([[Обсуждение участника:IXVI|обсуждение]]) 01:28, 20 ноября 2015 (MSK)

*Мы не настолько еще отрупели, что бы слушать раков из ВК. И уж тем более ориентироваться на "большинство". С уважением. --[[Участник:Recei|Recei]] ([[Обсуждение участника:Recei|обсуждение]]) 01:30, 20 ноября 2015 (MSK)

*Я считаю вашу позицию "википедия для избранных" тупиковой в отношении развития сообщества игры. Согласитесь, что википедия более нужна для популяризации игры и введения новых игроков, а не для ностальгических воздыханий малочисленных элитирующих элементов. [[Участник:IXVI|IXVI]] ([[Обсуждение участника:IXVI|обсуждение]]) 01:36, 20 ноября 2015 (MSK)

Chef

2015-11-19T21:30:00Z

IXVI: remarks

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных рецептов и блюд. 
И помните - все любят повара.

== Стандартные кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Универсальная машина, способная выжимать, крошить и молоть.

* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перемалывать туши в мясо.

* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

С помощью вашей скалки можно раскатать хлебное или сдобное тесто в лепёшку, которую затем можно разрезать ножом.

=== Нестандартные кухонные принадлежности ===

В ходе своей работе вы можете столкнуться как со знакомым так и с малознакомым оборудованием. Как правило пользоваться им довольно просто и оно сможет весьма разнообразить ваше меню.

* [[Файл:Blender e.png]] '''Старый блендер''' (Blender)

Блендер смешивает любую еду. Если не будете придерживаться строгого рецепта, то получите порцию ''питательных веществ'' (Nutriment). Это универсальный ингредиент, который содержится в любой пище. Это именно то, что насыщает вас, когда вы едите. Смешать кучу пончиков, бургеров и прочего для получения концентрированных питательных веществ может оказаться весьма полезным.
Вы можете смешать всё, что выращено в гидропонике, химические вещества, и большинство медикаментов, еды и жидкостей.

* [[Файл:Mixer.gif]] '''Миксер''' (Candy Machine)

Cделает из ваших продуктов конфетку. В прямом смысле.

* [[Файл:Fryer.gif]] '''Фритюр''' (Deep Fryer)

Прожаривает картошку и конечности Пун-пуна до румяной корочки.

* [[Файл:Oven.gif]] '''Печь''' (Oven)

Печенье из мяса? Пожалуйста! Пирог из спагетти? Да не вопрос!

* [[Файл:Cereal.gif]] '''Машина для создания хлопьев''' (Сereal maker)

Когда-нибудь мечтали отведать хлопья из мяса пришельцев? Смелей на кухню!

* [[Файл:Grill.gif]] '''Авто-гриль''' (Grille)

Прожаренная курочка или зад ассистента за считанные секунды.

* [[Файл:Icecream.png]] '''Раздатчик мороженого''' (Icecream)

Окунитесь в детство вместе с алкогольным мороженным.

* [[Файл:mixer0.png]] '''CondiMaster Neo'''

Позволяет исследовать и фильтровать то, что вы получили с помощью блендера. Также, позволяет упаковывать приправы в специальные баночки.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, а посуду и соусы вы можете брать в раздатчике [[Файл:Dinnerware.png]] 
Но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках продовольствия.

=== Гидропоника ===

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

Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Из пшеницы можно сделать муку, а из некоторых грибов извлечь радий для коктейлей в бар. Лишние овощи можно превратить в молоко или мясо. Наконец, всё можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

В вашей подсобке, где стоит мясорубка и крюк для подвешивания обезъян обитает ваш питомец - козёл Пити [[Файл:Goat.png]], больше похожий на буйвола и обладающий таким же буйным характером. Он привык к вам, но не любит чужаков и старается их запугать или боднуть. Пити лично ваше животное, но он не даёт ни молока, ни шерсти, так что решайте сами в каком виде он вам нравится больше.

Вы можете попросить [[Quartermaster|завхоза]] прислать вам коробку с обезьянками, ящик с цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку. Только не забудьте как следует накормить их перед тем, как использовать по назначению.

Ходят слухи, что Корги - это отменное лакомство, но убийство данного вида животных категорически запрещено и не одобряется руководством, даже в экстренных случаях.

=== Прочее ===

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

В тяжёлые времена на станции приходится питаться чем попало, и не дай бог попасть вам в очередной финансовый кризис компании Нанотрасен. На всякий случай знайте, что в технических тоннелях в обилии водятся мыши. Мясо пауков и космических карпов съедобно, но вредно для здоровья. А мясо космического медведя, если вам повезёт его найти - отменный деликатес. Говорят, что на некоторых потерпевших бедствие суднах экипаж решался на последнюю меру - каннибализм, так что желаем вам удачи.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Обсуждение:Guide to Posters

2015-11-19T21:28:43Z

IXVI:

Chef

2015-11-19T21:22:57Z

IXVI: Kinda not making sense in sentences, got to resee it afterwards for a bit.

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных рецептов и блюд. 
И помните - все любят повара.

== Стандартные кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Универсальная машина, способная выжимать, крошить и молоть.

* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перемалывать туши в мясо.

* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

С помощью вашей скалки можно раскатать хлебное или сдобное тесто в лепёшку, которую затем можно разрезать ножом.

=== Нестандартные кухонные принадлежности ===

В ходе своей работе вы можете столкнуться как со знакомым так и с малознакомым оборудованием. Как правило пользоваться ими довольно просто и они весьма разнообразят ваше меню.

* [[Файл:Blender e.png]] '''Старый блендер''' (Blender)

Блендер смешивает любую еду. Если не будете придерживаться строгого рецепта, то получите порцию ''питательных веществ'' (Nutriment). Это универсальный ингредиент, который содержится в любой пище. Это именно то, что насыщает вас, когда вы едите. Смешать кучу пончиков, бургеров и прочего для получения концентрированных питательных веществ может оказаться весьма полезным.
Вы можете смешать всё, что выращено в гидропонике, химические вещества, и большинство медикаментов, еды и жидкостей.

* [[Файл:Mixer.gif]] '''Миксер''' (Candy Machine)

Cделает из ваших продуктов конфетку. В прямом смысле.

* [[Файл:Fryer.gif]] '''Фритюр''' (Deep Fryer)

Прожаривает картошку и конечности Пун-пуна до румяной корочки.

* [[Файл:Oven.gif]] '''Печь''' (Oven)

Печенье из мяса? Пожалуйста! Пирог из спагетти? Да не вопрос!

* [[Файл:Cereal.gif]] '''Машина для создания хлопьев''' (Сereal maker)

Когда-нибудь мечтали отведать хлопья из мяса пришельцев? Смелей на кухню!

* [[Файл:Grill.gif]] '''Авто-гриль''' (Grille)

Прожаренная курочка или зад ассистента за считанные секунды.

* [[Файл:Icecream.png]] '''Раздатчик мороженого''' (Icecream)

Окунитесь в детство вместе с алкогольным мороженным.

* [[Файл:mixer0.png]] '''CondiMaster Neo'''

Позволяет исследовать и фильтровать то, что вы получили с помощью блендера. Также, позволяет упаковывать приправы в специальные баночки.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, а посуду и соусы вы можете брать в раздатчике [[Файл:Dinnerware.png]] 
Но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках продовольствия.

=== Гидропоника ===

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

Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Из пшеницы можно сделать муку, а из некоторых грибов извлечь радий для коктейлей в бар. Лишние овощи можно превратить в молоко или мясо. Наконец, всё можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

В вашей подсобке, где стоит мясорубка и крюк для подвешивания обезъян обитает ваш питомец - козёл Пити [[Файл:Goat.png]], больше похожий на буйвола и обладающий таким же буйным характером. Он привык к вам, но не любит чужаков и старается их запугать или боднуть. Пити лично ваше животное, но он не даёт ни молока, ни шерсти, так что решайте сами в каком виде он вам нравится больше.

Вы можете попросить [[Quartermaster|завхоза]] прислать вам коробку с обезьянками, ящик с цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку. Только не забудьте как следует накормить их перед тем, как использовать по назначению.

Ходят слухи, что Корги - это отменное лакомство, но убийство данного вида животных категорически запрещено и не одобряется руководством, даже в экстренных случаях.

=== Прочее ===

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

В тяжёлые времена на станции приходится питаться чем попало, и не дай бог попасть вам в очередной финансовый кризис компании Нанотрасен. На всякий случай знайте, что в технических тоннелях в обилии водятся мыши. Мясо пауков и космических карпов съедобно, но вредно для здоровья. А мясо космического медведя, если вам повезёт его найти - отменный деликатес. Говорят, что на некоторых потерпевших бедствие суднах экипаж решался на последнюю меру - каннибализм, так что желаем вам удачи.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Chef

2015-11-19T21:18:38Z

IXVI: Expanding description, adding more misc.

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных блюд. 
И помните - все любят повара.

== Стандартные кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Универсальная машина, способная выжимать, крошить и молоть.

* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перемалывать туши в мясо.

* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

С помощью вашей скалки можно раскатать хлебное или сдобное тесто в лепёшку, которую затем можно разрезать ножом.

=== Нестандартные кухонные принадлежности ===

В ходе своей работе вы можете столкнуться как со знакомым так и с малознакомым оборудованием. Как правило пользоваться ими довольно просто и они весьма разнообразят ваше меню.

* [[Файл:Blender e.png]] '''Старый блендер''' (Blender)

Блендер смешивает любую еду. Если не будете придерживаться строгого рецепта, то получите порцию ''питательных веществ'' (Nutriment). Это универсальный ингредиент, который содержится в любой пище. Это именно то, что насыщает вас, когда вы едите. Смешать кучу пончиков, бургеров и прочего для получения концентрированных питательных веществ может оказаться весьма полезным.
Вы можете смешать всё, что выращено в гидропонике, химические вещества, и большинство медикаментов, еды и жидкостей.

* [[Файл:Mixer.gif]] '''Миксер''' (Candy Machine)

Cделает из ваших продуктов конфетку. В прямом смысле.

* [[Файл:Fryer.gif]] '''Фритюр''' (Deep Fryer)

Прожаривает картошку и конечности Пун-пуна до румяной корочки.

* [[Файл:Oven.gif]] '''Печь''' (Oven)

Печенье из мяса? Пожалуйста! Пирог из спагетти? Да не вопрос!

* [[Файл:Cereal.gif]] '''Машина для создания хлопьев''' (Сereal maker)

Когда-нибудь мечтали отведать хлопья из мяса пришельцев? Смелей на кухню!

* [[Файл:Grill.gif]] '''Авто-гриль''' (Grille)

Прожаренная курочка или зад ассистента за считанные секунды.

* [[Файл:Icecream.png]] '''Раздатчик мороженого''' (Icecream)

Окунитесь в детство вместе с алкогольным мороженным.

* [[Файл:mixer0.png]] '''CondiMaster Neo'''

Позволяет исследовать и фильтровать то, что вы получили с помощью блендера. Также, позволяет упаковывать приправы в специальные баночки.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, а посуду и соусы вы можете брать в раздатчике [[Файл:Dinnerware.png]] 
Но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках продовольствия.

=== Гидропоника ===

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

Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Из пшеницы можно сделать муку, а из некоторых грибов извлечь радий для коктейлей в бар. Лишние овощи можно превратить в молоко или мясо. Наконец, всё можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

В вашей подсобке, где стоит мясорубка и крюк для подвешивания обезъян обитает ваш питомец - козёл Пити [[Файл:Goat.png]], больше похожий на буйвола и обладающий таким же буйным характером. Он привык к вам, но не любит чужаков и старается их запугать или боднуть. Пити лично ваше животное, но он не даёт ни молока, ни шерсти, так что решайте сами в каком виде он вам нравится больше.

Вы можете попросить [[Quartermaster|завхоза]] прислать вам коробку с обезьянками, ящик с цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку. Только не забудьте как следует накормить их перед тем, как использовать по назначению.

Ходят слухи, что Корги - это отменное лакомство, но убийство данного вида животных категорически запрещено и не одобряется руководством, даже в экстренных случаях.

=== Прочее ===

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

В тяжёлые времена на станции приходится питаться чем попало, и не дай бог попасть вам в очередной финансовый кризис компании Нанотрасен. На всякий случай знайте, что в технических тоннелях в обилии водятся мыши. Мясо пауков и космических карпов съедобно, но вредно для здоровья. А мясо космического медведя, если вам повезёт его найти - отменный деликатес. Говорят, что на некоторых потерпевших бедствие суднах экипаж решался на последнюю меру - каннибализм, так что желаем вам удачи.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Файл:Dinnerware.png

2015-11-19T20:54:16Z

IXVI: IXVI загрузил новую версию Файл:Dinnerware.png

DM Guide 19

2015-11-19T20:51:10Z

IXVI: Ты за 5 дней посмотрел, привлёк кого-то, исправил хоть что-то, или просто подставы кидаешь? Иди на хуй, не тебя звали.

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков. Если вы работаете в Dream Maker - внимательно прочтите её и сообщите о найденных ошибках.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.

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



===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.

Например, при добавлении дополнительных функций к процедуре client.Topic() в разных местах в коде случается эффект сочетания зачений в родительском элементе:


client/Topic(T)
if(T == "вступление")
usr << "И вот как-то раз..."
else ..()

client/Topic(T)
if(T == "подсказка")
usr << "Буквально позавчера."
else ..()
В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю


===Отладка кода===

Или иначе дебаггинг(debugging).

====Манеры хорошего кодера====

Ошибка начинающих программистов в том, что они слишком полагаются на компилятор. Опытные баголовы и багоюзеры знают, что если код скомпилирован, то не факт что он работает как написано. Уязвимости бывают везде.


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


Второй шаг - запустить код, так чтобы он заработал. Подставить необходимые переменные и запустить его в приложении. Сервер может выявить простые ошибки и баги, но только вы можете понять что работает не так, как оно должно работать, и почему это не так. А что работает именно так как описано в коде. Поиграйте с переменными и кодом, чтобы лучше понять механизмы компиляции и работы вашего кода.


Затем проведите нагрузочное тестирование, попробуйте выйти за пределы допустимых параметров, указанных вами при создании объектов и фич для проекта. Как правило на этом этапе всплывают все баги и уязвимости в написанном и вы можете отловить их и пофиксить\оставить для рабочей версии проекта.


===="Неуловимые" баги====

Существует два типа багов: Краш-баги которые останавливают процесс целиком (proc crashers) и мелкие баги(silent errors), которые ломают отдельные фичи. : Пример Краш-бага - обращение к переменной объекта, отсутствие ответа от объекта, придание переменной по умолчанию равной нулю, что приводит к завершению оператора.
Когда крашится процедура, как правило сохраняются логи ошибки в world.log . При запуске созданного вами проекта в клиенте Dream Seeker, эта информация будет показана в отдельном окошке. При запуске проекта на сервере Dream Daemon - логи сохраняются в выводе серверной информации, либо в отдельном файле.


Самое главное - найти в логах название процедуры, которая вызвала падение выполнения кода, а также значение переменных src и usr на момент выполнения процедуры. Процедуры могут быть показаны цепочкой вызовов - будут показаны обращающиеся к этой и вызванной этой процедурой процедуры.


world.log << "[__LINE__]: myvar = [myvar]"

Отладка кода проводится как при отдельных случаях падения кода(и тогда удобнее пользоваться примерами приведёнными выше), так и по всем исполняемым строкам и файлам при финальной диагностике. В последнем случае вы можете пользоваться следующими макросами:


: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif

Вывод информации на отладку будет осуществляться, но он будет игнорироваться до тех пор, пока вы не используете макрос #DEBUG.


Есть полезный приём при поиске багов - вынести код в комментарии. Код, вынесенный в комментарий перестаёт восприниматься компилятором как исполняемые команды, зато виден разработчику. Это полезно для выделения кусков кода, ответственных за совершение ошибок при исполнении, и временном устранении их, вплоть до отладки проблемного места.

Chef

2015-11-19T20:42:23Z

IXVI: Ну-ка покажи мне на картинке Barr.PNG блендер и соковыжималку, или иди нахуй. По-пизди ещё про билды, которые нигде не стоят, да.

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных блюд. 
И помните - все любят повара.

== Стандартные кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Универсальная машина, способная выжимать, крошить и молоть.

* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перемалывать туши в мясо.

* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

С помощью вашей скалки можно раскатать хлебное или сдобное тесто в лепёшку, которую затем можно разрезать ножом.

=== Нестандартные кухонные принадлежности ===

В ходе своей работе вы можете столкнуться как со знакомым так и с малознакомым оборудованием. Как правило пользоваться ими довольно просто и они весьма разнообразят ваше меню.

* [[Файл:Blender e.png]] '''Старый блендер''' (Blender)

Блендер смешивает любую еду. Если не будете придерживаться строгого рецепта, то получите порцию ''питательных веществ'' (Nutriment). Это универсальный ингредиент, который содержится в любой пище. Это именно то, что насыщает вас, когда вы едите. Смешать кучу пончиков, бургеров и прочего для получения концентрированных питательных веществ может оказаться весьма полезным.
Вы можете смешать всё, что выращено в гидропонике, химические вещества, и большинство медикаментов, еды и жидкостей.

* [[Файл:Mixer.gif]] '''Миксер''' (Candy Machine)

Cделает из ваших продуктов конфетку. В прямом смысле.

* [[Файл:Fryer.gif]] '''Фритюр''' (Deep Fryer)

Прожаривает картошку и конечности Пун-пуна до румяной корочки.

* [[Файл:Oven.gif]] '''Печь''' (Oven)

Печенье из мяса? Пожалуйста! Пирог из спагетти? Да не вопрос!

* [[Файл:Cereal.gif]] '''Машина для создания хлопьев''' (Сereal maker)

Когда-нибудь мечтали отведать хлопья из мяса пришельцев? Смелей на кухню!

* [[Файл:Grill.gif]] '''Авто-гриль''' (Grille)

Прожаренная курочка или зад ассистента за считанные секунды.

* [[Файл:Icecream.png]] '''Раздатчик мороженого''' (Icecream)

Окунитесь в детство вместе с алкогольным мороженным.

* [[Файл:mixer0.png]] '''CondiMaster Neo'''

Позволяет исследовать и фильтровать то, что вы получили с помощью блендера. Также, позволяет упаковывать приправы в специальные баночки.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках.

=== Гидропоника ===

Время от времени вы можете обратиться к ботаникам за снабжениями в виде ящиков с пшеницей, томатами и другими выращенными культурами. Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Наконец, все можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

Вы можете попросить [[Quartermaster|завхоза]] прислать вам клетку с обезьянками, цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Обсуждение:Guide to Posters

2015-11-19T20:34:58Z

IXVI: имхо

Chef

2015-11-19T16:55:13Z

IXVI: /* Кухонные принадлежности */

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных блюд. 
И помните - все любят повара.

== Кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Машина для нарезки. В ней можно провернуть мясо, приготовить картофельные и морковные палочки, прокрутить соевые бобы. Используется только опытными кулинарами.

* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перекручивать туши на мясо. Делает это просто и со вкусом.


* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

Скалкой можно раскатать хлебное или сдобное тесто в лепёшку, которую затем разрезать ножом.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках.

=== Гидропоника ===

Время от времени вы можете обратиться к ботаникам за снабжениями в виде ящиков с пшеницей, томатами и другими выращенными культурами. Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Наконец, все можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

Вы можете попросить [[Quartermaster|завхоза]] прислать вам клетку с обезьянками, цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Chef

2015-11-19T16:50:17Z

IXVI: Переделываю статейку под общий стиль

{| border="1" cellspacing="0" cellpadding="2" width="100%" style="background-color:#DCDCDC;"
!style="background-color:#A9A9A9;" width=200|Профессия
!style="background-color:#A9A9A9;" |Роль
!style="background-color:#A9A9A9;" width=100|Сложность

|-
![[File:Jobchef.png]] [[Chef|Шеф-повар]]
|'''Доступ:''' Kitchen, Morgue.
'''Подчинение:''' [[Head of Personnel|Глава персонала]].

'''Обязанности:''' Готовить еду для экипажа и держать всех сытыми.

'''Guides:''' [[Guide to food and drinks]]

!Легко

|-
|}

''Не существует ни единого факта, ни единого аргумента в оправдание мясоедения, которые нельзя было бы употребить и в оправдание каннибализма.'' '''''Герберт Шелдон, "Книга здоровой пищи"'''''

[[File:Barr.PNG|300px|right|thumb|Кухня, столовая и подсобка. Здесь находится все, что вам только нужно.]]
{{toc right}}

'''Ваша работа — [http://www.youtube.com/watch?feature=player_embedded&v=S5qUMK-TzOg готовить еду]''', кормить проголодавшихся и, что самое главное — ''творить'', ведь вы — [http://www.youtube.com/watch?feature=player_embedded&v=XUJydOCyReA кулинарный мастер], единственный и неповторимый в своем деле!

== Вступление ==

Профессия повара возможно считается не самой сложной и почётной среди остальных должностей экипажа космического корабля, он она по-своему привлекательна. Вас могут звать по-разному: повар, шеф-повар, кок, кухарка - в зависимости от настроения ваших клиентов - голодных работников всех отделов станции. У вас есть своё рабочее место - хорошо укомплектованная кухня горячего и холодного цеха, подсобное помещение для хранения припасов, а также стойка для раздачи готовых блюд. Скорее всего вас будут оценивать по вашим умениям, так что хорошо бы для начала узнать хотя бы рецепт яичницы, а с течением времени у вас будет всё больше разнообразных ингредиентов - и всё больше разнообразных блюд. 
И помните - все любят повара.

== Кухонные принадлежности ==

У повара есть несколько инструментов, которые встречаются практически на любой корабельной кухне. Это:

* [[Файл:Mw.png‎]] '''Микроволновая печь''' (Microwave)

Микроволновая печь весьма капризная штука. Если вы не знаете рецепта, не экспериментируйте! Вы можете вместо еды получить несъедобную массу, также вы можете испачкать (а в худшем случае даже сломать) вашу микроволновку, и она будет непригодна для использования. Исправить ситуацию помогут флакон спейсклинера или инженер с набором инструментов.

* [[Файл:Processor.png ‎]] '''Кухонный комбайн''' (Food Processor)

Универсальная машина, способная выжимать, крошить и молоть.



* [[Файл:Juicer2.png]] '''Блендер''' (All-In-One Grinder)

[http://www.youtube.com/embed/l0sbiSlyKtw Универсальный блендер] способен измельчать готовые блюда и растения, и выжимать сок из ягод и овощей. Это полезное и легкое во всех отношениях изобретение светлых умов из NanoTrasen ваш главный помощник в изучении кулинарного искусства. Количество получаемых веществ, или сока напрямую зависит он потенциала растений, так что, если хотите больше - добивайтесь от ботаника высококачественной продукции.

* [[Файл:Grinder.png]] '''Мясорубка''' (Gibber)

Мясорубка позволяет перемалывать туши в мясо.



* [[Файл:SmartFridge.png]] '''SmartFridge'''

С помощью этого отличного холодильника вы сможете хранить урожай, выращенный ботаниками. Ваши овощи и фрукты всегда будут свежими, а блюда вкусными. Очень удобен в использовании, есть возможность загрузки всего содержимого сумки для растений и выдачи по х1, х5, х10 единиц одного наименования.

* [[Файл:Kitchen knife.png]] '''Кухонный нож''' (Kitchen Knife)

Кухонным ножом можно нарезать продукты, например, сыр, мясо, хлеб, торты или пиццу. Чтобы резать продукты обязательно нужен стол или поднос. Резать их на полу, или в руках — неудобно.

* [[Файл:Rolling_pin.png]] '''Скалка''' (Rolling Pin)

С помощью вашей скалки можно раскатать хлебное или сдобное тесто в лепёшку, которую затем можно разрезать ножом.

== Снабжение ==

У вас есть начальный запас ингредиентов на кухне, но он не неиссякаемый и когда-то закончится. Так что вам стоит заранее подумать об этом и начать договариваться о поставках.

=== Гидропоника ===

Время от времени вы можете обратиться к ботаникам за снабжениями в виде ящиков с пшеницей, томатами и другими выращенными культурами. Некоторые растения могут быть использованы как особые ингредиенты в некоторых рецептах или из них можно сделать соус. Наконец, все можно переработать в питательные вещества при помощи блендера. Не забудьте поблагодарить ботаников, если вы не хотите остаться без муки и овощей.

=== Животные ===

Вы можете попросить [[Quartermaster|завхоза]] прислать вам клетку с обезьянками, цыплятами или коровой. Обезьянок можно разделывать на мясо, предварительно подвесив их на мясной крюк. Цыплята могут отложить яйцо. Корову можно подоить, если у вас есть ведро. Кроме того и цыплят и коров можно пустить на мясо в мясорубку.

==Подсказки==
* Кровь и Synthflesh вступают в реакцию и создают мясо. Химия- наука вкусная.
* Кухонные ножи и тесаки можно взять в раздатчики на кухне, они с легкостью помещаются в карман.
* Не распарывайте пун-пуна на мясо при помощи пик! С помощью нужных [[Guide_to_Surgery/Bay12|инструментов]] вырежьте мозг и сделайте из него блюдо! И только потом пустите его на мясо.
* Яйца можно раскрасить цветными мелками
* Ты можешь сделать бургер цветным, добавив нужный мелок в ингредиенты.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]
[[Category:/vg/station13]]

Captain

2015-11-15T12:54:09Z

IXVI: /* Глава службы безопасности */ станцию, чтобы убедиться, что

{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:lightblue;" width=200|Профессия
!style="background-color:lightblue;" |Описание
!style="background-color:lightblue;" width=100|Сложность

|-
![[File:Jobcap.png]] [[Captain|Капитан]]
|'''Доступ:''' Полный доступ
'''Подчинение:''' ЦентКомм

'''Обязанности:''' Организация и управление экипажем Космической Станции 13.

'''Guides:''' [[Space Law]], [[Standard Operating Procedure]], [[Chain of Command]], [[Guide to Trials]]
!Очень сложно
|}

''Корабль держится в том числе на преданности одному человеку. Её ничем не заменишь... и его тоже.'' '''''"Звездный Путь"'''''
[[File:Captain's Quarters.png|280px|right|thumb|Капитанская каюта.]]
'''Капитан''', назначенный корпорацией NanoTrasen, является администратором и координатором №1, связующим звеном между главами, и именно от его своевременных решений и приказов будут зависеть десятки жизней членов экипажа.

Очевидным является то, что в данном случае капитан — не владелец станции и не военный, не пьяный пират и не супергерой. '''Он''' — всего лишь один из служащих Корпорации, с чуть большим окладом, чем у его подчинённых, но с куда большей ответственностью.

== Galactic Commander ==
[[Файл:CapitanByNorgot.png|right]]
Итак, сынок, тебе надоело нытье вечно недовольной жены по поводу зарплаты, и вот ты докарабкался, обламывая ногти, до звания капитана. Взгляни на то, что написано выше. Это официальное руководство к действию. Оно в своем роде идеально — если ты, конечно, нанялся работать на идеальную станцию, хе. Можешь рвануть с места в карьер, вооруженный им и верой в светлое будущее. Однако, если у тебя есть еще время и терпение, позволь мне дать тебе несколько советов насчет управления.
:'''1.''' Экипаж — это свора детей, которых кто-то пустил играть во взрослые игрушки. Детишки будут выкалывать друг другу глаза, бить по голове баллонами, сжигать в плазме, обкалывать токсинами, выливать кислоту на лица. Космос странно действует на психику, что тут можно сказать. Это непросто, но ты не должен делать с ними все вышеперечисленное в ответ.
*''Тебе нужно их чем-нибудь занять, это резко снизит градус бессмысленного насилия.''
:'''2.''' Если тебе повезет, то хотя бы несколько глав будут знать, что делать. Однако обычно люди на руководящих постах занимаются раскрытием своего внутреннего [[Clown|я]], бессмысленно носятся по станции либо с головой окунаются в общий водоворот насилия. Будет непросто, но и их ты тоже не можешь просто убить. Разжалуй и назначь на должность кого-нибудь более достойного.
*''Всегда следи за тем, как главы справляются со своими обязанностями. Не бойся выгонять их к чертовой матери. Не забывай назначать новых.''
:'''3.''' Многие люди не будут слушать твои приказы, какими бы разумными они не были. Так вот, убивать их тоже нельзя. Еще не разочаровался в работе, а, приятель? Тогда слушай дальше. Санкции за невыполнение приказа, не приведшее к катастрофическим последствиям, не заключаются в избиении и помещении в камеру на 10 минут. Влепи словесный выговор. Поговори с главой отдела. Разжалуй в ассистенты.
*''Еще раз, никаких тюремных сроков за неподчинение приказам, никаких пыток с привязыванием к стулу, никаких а-давайте-засунем-его-в-гиббер.''
:'''4.''' Итак, ты делал все правильно, а станция все равно погрузилась в хаос. Половина ее взорвана веселым химиком, другая объявила себя независимым рабовладельческим государством, ловит в технических тоннелях ассистентов и продает их с аукциона. С чем-то ты не сможешь совладать — это нормально. Делай что можешь. Отдавай приказы и полномочия верным людям, договаривайся, умоляй, подкупай — все, что нужно, лишь бы прекратить хаос и навести порядок.
*''Разбирайся с проблемами по очереди, не пытайся справиться со всем и сразу. Будь умнее, хитрее, дипломатичнее и безжалостнее, чем все твои враги вместе взятые.''
:'''5.''' '''Запомни раз и навсегда! Ты отвечаешь за жизнь каждого из этих тупых ублюдков, которых сослали служить под твоим командованием. Никогда не забывай об этом.'''

== Основные советы ==
* Не потеряйте доверие экипажа: не отдавайте нелепых приказов и не нарушайте [[Space Law|закон]], иначе последствия не заставят себя ждать — от неподчинения до полномасштабной революции.
* Не стесняйтесь спросить совета у глав.
* Не стесняйтесь спросить совета у глав, даже если он вам не нужен.
* Помните о цепи командования: отдавайте приказы главам, а не их подчинённым.
* Если главы нет - назначьте. Если глава некомпетентен - замените его.
* Если экипаж считает, что вы некомпетентны, и у него есть все основания так считать, сдайте полномочия и найдите себе замену.
* '''Бездействие в чрезвычайной ситуации — главный признак некомпетентности капитана.''' Помните, что чаще всего лишь с помощью правильных приказов можно спасти станцию от гибели.

=== Весь экипаж ===
* Отдать приказ включить датчики жизнедеятельности и местоположения. Ну или просто прикажите перевести костюмы в третий режим - они поймут. Данные с датчиков отправляются на Crew Monitoring Computer (есть на мостике, в кабинете главного врача и в приемной медицинского отсека).

=== [[Head_of_Personnel|Глава персонала]] ===
* Если '''Глава персонала''' где-то шляется и его нет на рабочем месте, напомните ему о главной обязанности — сидеть в офисе и заниматься перераспределением кадров.
* Прикажите '''главе персонала''' брать отпечатки у новоприбывших членов экипажа и заводить досье в терминале Security Records.
* Порекомендуйте назначить всех свободных ассистентов на полезную должность.

=== [[Head_of_Security|Глава службы безопасности]] ===
* Не помешает лично проинспектировать бриг и тюремную станцию, чтобы убедиться что '''Глава службы безопасности''' не превратил их в лагерь смерти, а у заключённых есть еда и нет опасных предметов.
* Прикажите распределить охранников по станции, если глава службы безопасности ещё не сделал этого. Попросите главу персонала расширить допуск согласно району патрулирования.

=== [[Research_Director|Директор исследований]], [[Chief_Medical_Officer|главный врач]], [[Chief_Engineer|главный инженер]] ===
* Как правило, особых указаний для этих глав не требуется. Просто напомните, что они отвечают за все действия своих подчинённых.
* Но вы можете проинспектировать их отделы спустя некоторое время, дабы проверить функциональность отделов и выполнение отданных вами поручений

=== [[AI|ИИ]] ===
'''Прикажите ИИ:'''
* Докладывать обо всех нарушениях закона на станции, сообщать имена жертв и подозреваемых при наличии таковых.
* Докладывать обо всех несчастных случаях на станции.
* Запереть все неиспользуемые шлюзы, сжигатель (Igniter), аплоад, хранилище плат и крематорий до востребования.

== I should go ==
Непредвиденные обстоятельства? Чрезвычайная ситуация? Не знаете, что делать?
#'''Не паникуйте'''.
# Соберите как можно больше данных о происходящем.
# Узнайте о мнении каждого из глав. В конце концов, они — специалисты в своих областях.
# Если ситуация того требует, объявите общий сбор и устройте совет.
# Примите решение, отдайте соответствующие приказы.
# Если станции нанесён непоправимый ущерб:
#* Объявите эвакуацию.
# Если станции нанесён поправимый ущерб:
#* Скоординируйте действия экипажа с целью его исправлении.
#* Устройте суд над виновными, если таковые есть.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]

Captain

2015-11-15T12:53:05Z

IXVI: /* Весь экипаж */ Ну или просто 'прикажте'

{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:lightblue;" width=200|Профессия
!style="background-color:lightblue;" |Описание
!style="background-color:lightblue;" width=100|Сложность

|-
![[File:Jobcap.png]] [[Captain|Капитан]]
|'''Доступ:''' Полный доступ
'''Подчинение:''' ЦентКомм

'''Обязанности:''' Организация и управление экипажем Космической Станции 13.

'''Guides:''' [[Space Law]], [[Standard Operating Procedure]], [[Chain of Command]], [[Guide to Trials]]
!Очень сложно
|}

''Корабль держится в том числе на преданности одному человеку. Её ничем не заменишь... и его тоже.'' '''''"Звездный Путь"'''''
[[File:Captain's Quarters.png|280px|right|thumb|Капитанская каюта.]]
'''Капитан''', назначенный корпорацией NanoTrasen, является администратором и координатором №1, связующим звеном между главами, и именно от его своевременных решений и приказов будут зависеть десятки жизней членов экипажа.

Очевидным является то, что в данном случае капитан — не владелец станции и не военный, не пьяный пират и не супергерой. '''Он''' — всего лишь один из служащих Корпорации, с чуть большим окладом, чем у его подчинённых, но с куда большей ответственностью.

== Galactic Commander ==
[[Файл:CapitanByNorgot.png|right]]
Итак, сынок, тебе надоело нытье вечно недовольной жены по поводу зарплаты, и вот ты докарабкался, обламывая ногти, до звания капитана. Взгляни на то, что написано выше. Это официальное руководство к действию. Оно в своем роде идеально — если ты, конечно, нанялся работать на идеальную станцию, хе. Можешь рвануть с места в карьер, вооруженный им и верой в светлое будущее. Однако, если у тебя есть еще время и терпение, позволь мне дать тебе несколько советов насчет управления.
:'''1.''' Экипаж — это свора детей, которых кто-то пустил играть во взрослые игрушки. Детишки будут выкалывать друг другу глаза, бить по голове баллонами, сжигать в плазме, обкалывать токсинами, выливать кислоту на лица. Космос странно действует на психику, что тут можно сказать. Это непросто, но ты не должен делать с ними все вышеперечисленное в ответ.
*''Тебе нужно их чем-нибудь занять, это резко снизит градус бессмысленного насилия.''
:'''2.''' Если тебе повезет, то хотя бы несколько глав будут знать, что делать. Однако обычно люди на руководящих постах занимаются раскрытием своего внутреннего [[Clown|я]], бессмысленно носятся по станции либо с головой окунаются в общий водоворот насилия. Будет непросто, но и их ты тоже не можешь просто убить. Разжалуй и назначь на должность кого-нибудь более достойного.
*''Всегда следи за тем, как главы справляются со своими обязанностями. Не бойся выгонять их к чертовой матери. Не забывай назначать новых.''
:'''3.''' Многие люди не будут слушать твои приказы, какими бы разумными они не были. Так вот, убивать их тоже нельзя. Еще не разочаровался в работе, а, приятель? Тогда слушай дальше. Санкции за невыполнение приказа, не приведшее к катастрофическим последствиям, не заключаются в избиении и помещении в камеру на 10 минут. Влепи словесный выговор. Поговори с главой отдела. Разжалуй в ассистенты.
*''Еще раз, никаких тюремных сроков за неподчинение приказам, никаких пыток с привязыванием к стулу, никаких а-давайте-засунем-его-в-гиббер.''
:'''4.''' Итак, ты делал все правильно, а станция все равно погрузилась в хаос. Половина ее взорвана веселым химиком, другая объявила себя независимым рабовладельческим государством, ловит в технических тоннелях ассистентов и продает их с аукциона. С чем-то ты не сможешь совладать — это нормально. Делай что можешь. Отдавай приказы и полномочия верным людям, договаривайся, умоляй, подкупай — все, что нужно, лишь бы прекратить хаос и навести порядок.
*''Разбирайся с проблемами по очереди, не пытайся справиться со всем и сразу. Будь умнее, хитрее, дипломатичнее и безжалостнее, чем все твои враги вместе взятые.''
:'''5.''' '''Запомни раз и навсегда! Ты отвечаешь за жизнь каждого из этих тупых ублюдков, которых сослали служить под твоим командованием. Никогда не забывай об этом.'''

== Основные советы ==
* Не потеряйте доверие экипажа: не отдавайте нелепых приказов и не нарушайте [[Space Law|закон]], иначе последствия не заставят себя ждать — от неподчинения до полномасштабной революции.
* Не стесняйтесь спросить совета у глав.
* Не стесняйтесь спросить совета у глав, даже если он вам не нужен.
* Помните о цепи командования: отдавайте приказы главам, а не их подчинённым.
* Если главы нет - назначьте. Если глава некомпетентен - замените его.
* Если экипаж считает, что вы некомпетентны, и у него есть все основания так считать, сдайте полномочия и найдите себе замену.
* '''Бездействие в чрезвычайной ситуации — главный признак некомпетентности капитана.''' Помните, что чаще всего лишь с помощью правильных приказов можно спасти станцию от гибели.

=== Весь экипаж ===
* Отдать приказ включить датчики жизнедеятельности и местоположения. Ну или просто прикажите перевести костюмы в третий режим - они поймут. Данные с датчиков отправляются на Crew Monitoring Computer (есть на мостике, в кабинете главного врача и в приемной медицинского отсека).

=== [[Head_of_Personnel|Глава персонала]] ===
* Если '''Глава персонала''' где-то шляется и его нет на рабочем месте, напомните ему о главной обязанности — сидеть в офисе и заниматься перераспределением кадров.
* Прикажите '''главе персонала''' брать отпечатки у новоприбывших членов экипажа и заводить досье в терминале Security Records.
* Порекомендуйте назначить всех свободных ассистентов на полезную должность.

=== [[Head_of_Security|Глава службы безопасности]] ===
* Не помешает лично проинспектировать бриг и тюремную станцию, чтобы убедиться, что '''Глава службы безопасности''' не превратил их в лагерь смерти, а у заключённых есть еда и нет опасных предметов.
* Прикажите распределить охранников по станции, если глава службы безопасности ещё не сделал этого. Попросите главу персонала расширить допуск согласно району патрулирования.

=== [[Research_Director|Директор исследований]], [[Chief_Medical_Officer|главный врач]], [[Chief_Engineer|главный инженер]] ===
* Как правило, особых указаний для этих глав не требуется. Просто напомните, что они отвечают за все действия своих подчинённых.
* Но вы можете проинспектировать их отделы спустя некоторое время, дабы проверить функциональность отделов и выполнение отданных вами поручений

=== [[AI|ИИ]] ===
'''Прикажите ИИ:'''
* Докладывать обо всех нарушениях закона на станции, сообщать имена жертв и подозреваемых при наличии таковых.
* Докладывать обо всех несчастных случаях на станции.
* Запереть все неиспользуемые шлюзы, сжигатель (Igniter), аплоад, хранилище плат и крематорий до востребования.

== I should go ==
Непредвиденные обстоятельства? Чрезвычайная ситуация? Не знаете, что делать?
#'''Не паникуйте'''.
# Соберите как можно больше данных о происходящем.
# Узнайте о мнении каждого из глав. В конце концов, они — специалисты в своих областях.
# Если ситуация того требует, объявите общий сбор и устройте совет.
# Примите решение, отдайте соответствующие приказы.
# Если станции нанесён непоправимый ущерб:
#* Объявите эвакуацию.
# Если станции нанесён поправимый ущерб:
#* Скоординируйте действия экипажа с целью его исправлении.
#* Устройте суд над виновными, если таковые есть.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]

Captain

2015-11-15T12:52:10Z

IXVI: Капитан, 'принадлежащей корпорации'; какими бы разумными они 'ни' были; ловит в 'тех.' тоннелях; Если главы нет',' назначьте;

{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#EEEEFF;"
!style="background-color:lightblue;" width=200|Профессия
!style="background-color:lightblue;" |Описание
!style="background-color:lightblue;" width=100|Сложность

|-
![[File:Jobcap.png]] [[Captain|Капитан]]
|'''Доступ:''' Полный доступ
'''Подчинение:''' ЦентКомм

'''Обязанности:''' Организация и управление экипажем Космической Станции 13.

'''Guides:''' [[Space Law]], [[Standard Operating Procedure]], [[Chain of Command]], [[Guide to Trials]]
!Очень сложно
|}

''Корабль держится в том числе на преданности одному человеку. Её ничем не заменишь... и его тоже.'' '''''"Звездный Путь"'''''
[[File:Captain's Quarters.png|280px|right|thumb|Капитанская каюта.]]
'''Капитан''', назначенный корпорацией NanoTrasen, является администратором и координатором №1, связующим звеном между главами, и именно от его своевременных решений и приказов будут зависеть десятки жизней членов экипажа.

Очевидным является то, что в данном случае капитан — не владелец станции и не военный, не пьяный пират и не супергерой. '''Он''' — всего лишь один из служащих Корпорации, с чуть большим окладом, чем у его подчинённых, но с куда большей ответственностью.

== Galactic Commander ==
[[Файл:CapitanByNorgot.png|right]]
Итак, сынок, тебе надоело нытье вечно недовольной жены по поводу зарплаты, и вот ты докарабкался, обламывая ногти, до звания капитана. Взгляни на то, что написано выше. Это официальное руководство к действию. Оно в своем роде идеально — если ты, конечно, нанялся работать на идеальную станцию, хе. Можешь рвануть с места в карьер, вооруженный им и верой в светлое будущее. Однако, если у тебя есть еще время и терпение, позволь мне дать тебе несколько советов насчет управления.
:'''1.''' Экипаж — это свора детей, которых кто-то пустил играть во взрослые игрушки. Детишки будут выкалывать друг другу глаза, бить по голове баллонами, сжигать в плазме, обкалывать токсинами, выливать кислоту на лица. Космос странно действует на психику, что тут можно сказать. Это непросто, но ты не должен делать с ними все вышеперечисленное в ответ.
*''Тебе нужно их чем-нибудь занять, это резко снизит градус бессмысленного насилия.''
:'''2.''' Если тебе повезет, то хотя бы несколько глав будут знать, что делать. Однако обычно люди на руководящих постах занимаются раскрытием своего внутреннего [[Clown|я]], бессмысленно носятся по станции либо с головой окунаются в общий водоворот насилия. Будет непросто, но и их ты тоже не можешь просто убить. Разжалуй и назначь на должность кого-нибудь более достойного.
*''Всегда следи за тем, как главы справляются со своими обязанностями. Не бойся выгонять их к чертовой матери. Не забывай назначать новых.''
:'''3.''' Многие люди не будут слушать твои приказы, какими бы разумными они не были. Так вот, убивать их тоже нельзя. Еще не разочаровался в работе, а, приятель? Тогда слушай дальше. Санкции за невыполнение приказа, не приведшее к катастрофическим последствиям, не заключаются в избиении и помещении в камеру на 10 минут. Влепи словесный выговор. Поговори с главой отдела. Разжалуй в ассистенты.
*''Еще раз, никаких тюремных сроков за неподчинение приказам, никаких пыток с привязыванием к стулу, никаких а-давайте-засунем-его-в-гиббер.''
:'''4.''' Итак, ты делал все правильно, а станция все равно погрузилась в хаос. Половина ее взорвана веселым химиком, другая объявила себя независимым рабовладельческим государством, ловит в технических тоннелях ассистентов и продает их с аукциона. С чем-то ты не сможешь совладать — это нормально. Делай что можешь. Отдавай приказы и полномочия верным людям, договаривайся, умоляй, подкупай — все, что нужно, лишь бы прекратить хаос и навести порядок.
*''Разбирайся с проблемами по очереди, не пытайся справиться со всем и сразу. Будь умнее, хитрее, дипломатичнее и безжалостнее, чем все твои враги вместе взятые.''
:'''5.''' '''Запомни раз и навсегда! Ты отвечаешь за жизнь каждого из этих тупых ублюдков, которых сослали служить под твоим командованием. Никогда не забывай об этом.'''

== Основные советы ==
* Не потеряйте доверие экипажа: не отдавайте нелепых приказов и не нарушайте [[Space Law|закон]], иначе последствия не заставят себя ждать — от неподчинения до полномасштабной революции.
* Не стесняйтесь спросить совета у глав.
* Не стесняйтесь спросить совета у глав, даже если он вам не нужен.
* Помните о цепи командования: отдавайте приказы главам, а не их подчинённым.
* Если главы нет - назначьте. Если глава некомпетентен - замените его.
* Если экипаж считает, что вы некомпетентны, и у него есть все основания так считать, сдайте полномочия и найдите себе замену.
* '''Бездействие в чрезвычайной ситуации — главный признак некомпетентности капитана.''' Помните, что чаще всего лишь с помощью правильных приказов можно спасти станцию от гибели.

=== Весь экипаж ===
* Отдать приказ включить датчики жизнедеятельности и местоположения. Ну или просто прикажте перевести костюмы в третий режим, они поймут. Данные с датчиков отправляются на Crew Monitoring Computer (есть на мостике, кабинете главного врача и в приемной медицинского отсека).

=== [[Head_of_Personnel|Глава персонала]] ===
* Если '''Глава персонала''' где-то шляется и его нет на рабочем месте, напомните ему о главной обязанности — сидеть в офисе и заниматься перераспределением кадров.
* Прикажите '''главе персонала''' брать отпечатки у новоприбывших членов экипажа и заводить досье в терминале Security Records.
* Порекомендуйте назначить всех свободных ассистентов на полезную должность.

=== [[Head_of_Security|Глава службы безопасности]] ===
* Не помешает лично проинспектировать бриг и тюремную станцию, чтобы убедиться, что '''Глава службы безопасности''' не превратил их в лагерь смерти, а у заключённых есть еда и нет опасных предметов.
* Прикажите распределить охранников по станции, если глава службы безопасности ещё не сделал этого. Попросите главу персонала расширить допуск согласно району патрулирования.

=== [[Research_Director|Директор исследований]], [[Chief_Medical_Officer|главный врач]], [[Chief_Engineer|главный инженер]] ===
* Как правило, особых указаний для этих глав не требуется. Просто напомните, что они отвечают за все действия своих подчинённых.
* Но вы можете проинспектировать их отделы спустя некоторое время, дабы проверить функциональность отделов и выполнение отданных вами поручений

=== [[AI|ИИ]] ===
'''Прикажите ИИ:'''
* Докладывать обо всех нарушениях закона на станции, сообщать имена жертв и подозреваемых при наличии таковых.
* Докладывать обо всех несчастных случаях на станции.
* Запереть все неиспользуемые шлюзы, сжигатель (Igniter), аплоад, хранилище плат и крематорий до востребования.

== I should go ==
Непредвиденные обстоятельства? Чрезвычайная ситуация? Не знаете, что делать?
#'''Не паникуйте'''.
# Соберите как можно больше данных о происходящем.
# Узнайте о мнении каждого из глав. В конце концов, они — специалисты в своих областях.
# Если ситуация того требует, объявите общий сбор и устройте совет.
# Примите решение, отдайте соответствующие приказы.
# Если станции нанесён непоправимый ущерб:
#* Объявите эвакуацию.
# Если станции нанесён поправимый ущерб:
#* Скоординируйте действия экипажа с целью его исправлении.
#* Устройте суд над виновными, если таковые есть.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Baystation12]]
[[Category:Fernflower]]

Guide to Posters

2015-11-15T11:12:23Z

IXVI: и <s> поменял местами

В мире Станции-13 есть отличная вещь для пропаганды тех или иных вещей - постеры [[Файл:Poster.png]] - скатанные в рулон плакаты отличного фотографического качества, с превосходным дизайном и ёмким содержанием. Для их использования возьмите их в руку и щёлкните на стену, куда вы хотите повесить плакат. После этого постер начнёт автоматически разворачиваться на стене, издавая при этом приятный звук печати двухтонного типографского принтера. После размещения вы сможете снять постер со стены для повторного использования, использовав на нём кусачки([[Файл:Wirecutters.png]]), или просто сорвать его, щёлкнув по плакату пустой рукой.
----
Постеры бывают двух видов: Разрешённые корпоративные ([[Файл:Poster_Legit.png]]) и Запрещённые <s>контрабандные</s> ([[Файл:Poster.png]]). Корпоративные постеры разрешены к размещению по всей территории станции, они имеют синий оттенок в скатанном виде и как правило содержат полезную и предупредительную информацию, или могут быть чудесными картинами для украшения помещений. Контрабандные же постеры агитируют к насилию, революционным настроениям среди станции и свидетельствуют о определённом уровне недовольства [[Assistant|рабочих масс]] станции. Они имеют красный оттенок, и Сотрудники Безопасности будут стараться срывать их со стен, а также искать распространителя чтобы упечь его за решётку.
----
==Корпоративные постеры [[Файл:Poster_Legit.png]]==
{| class="wikitable" width="100%"
|-
! style="width: 5%"| №
! style="width: 10%"| Изображение
! style="width: 85%"| Слоган
|-
| <center>1</center>
| <center>[[Файл:Poster_Legit1.png|Here For Your Safety]]</center>
| "A poster glorifying the station's security force."
|-
| <center>2</center>
| <center>[[Файл:Poster_Legit2.png|Nanotrasen Logo]]</center>
| "A poster depicting the Nanotrasen logo."
|-
| <center>3</center>
| <center>[[Файл:Poster_Legit3.png|Cleanliness]]</center>
| "A poster warning of the dangers of poor hygiene."
|-
| <center>4</center>
| <center>[[Файл:Poster_Legit4.png|Help Others]]</center>
| "A poster encouraging you to help fellow crewmembers."
|-
| <center>5</center>
| <center>[[Файл:Poster_Legit5.png|Build]]</center>
| "A poster glorifying the engineering team."
|-
| <center>6</center>
| <center>[[Файл:Poster_Legit6.png|Bless This Spess]]</center>
| "A poster blessing this area."
|-
| <center>7</center>
| <center>[[Файл:Poster_Legit7.png|Science]]</center>
| "A poster depicting an atom."
|-
| <center>8</center>
| <center>[[Файл:Poster_Legit8.png|Ian]]</center>
| "Arf arf. Yap."
|-
| <center>9</center>
| <center>[[Файл:Poster_Legit9.png|Obey]]</center>
| A poster instructing the viewer to obey authority."
|-
| <center>10</center>
| <center>[[Файл:Poster_Legit10.png|Walk]]</center>
| "A poster instructing the viewer to walk instead of running."
|-
| <center>11</center>
| <center>[[Файл:Poster_Legit11.png|State Laws]]</center>
| "A poster instructing cyborgs to state their laws."
|-
| <center>12</center>
| <center>[[Файл:Poster_Legit12.png|Love Ian]]</center>
| "Ian is love, Ian is life."
|-
| <center>13</center>
| <center>[[Файл:Poster_Legit13.png|Space Cops]]</center>
| "A poster advertising the television show Space Cops."
|-
| <center>14</center>
| <center>[[Файл:Poster_Legit14.png|Ue No]]</center>
| "This thing is all in Japanese."
|-
| <center>15</center>
| <center>[[Файл:Poster_Legit15.png|Get Your LEGS]]</center>
| "LEGS: Leadership, Experience, Genius, Subordination."
|-
| <center>16</center>
| <center>[[Файл:Poster_Legit16.png|Do Not Question]]</center>
| "A poster instructing the viewer not to ask about things they aren't meant to know."
|-
| <center>17</center>
| <center>[[Файл:Poster_Legit17.png|Work For A Future]]</center>
| "A poster encouraging you to work for your future."
|-
| <center>18</center>
| <center>[[Файл:Poster_Legit18.png|Soft Cap Pop Art]]</center>
| "A poster reprint of some cheap pop art."
|-
| <center>19</center>
| <center>[[Файл:Poster_Legit19.png|Internals]]</center>
| "A poster instructing the viewer to wear internals in the rare environments where there is no oxygen or the air has been rendered toxic."
|-
| <center>20</center>
| <center>[[Файл:Poster_Legit20.png|Eye Protection]]</center>
| "A poster instructing the viewer to wear eye protection when dealing with chemicals, smoke, or bright lights."
|-
| <center>21</center>
| <center>[[Файл:Poster_Legit21.png|Report]]</center>
| "A poster instructing the viewer to report suspicious activity to the security force."
|-
| <center>22</center>
| <center>[[Файл:Poster_Legit22.png|Report Crimes]]</center>
| "A poster encouraging the swift reporting of crime or seditious behavior to station security."
|-
| <center>23</center>
| <center>[[Файл:Poster_Legit23.png|Ion Rifle]]</center>
| "A poster displaying an Ion Rifle."
|-
| <center>24</center>
| <center>[[Файл:Poster_Legit24.png|Foam Force Ad]]</center>
| "Foam Force, it's Foam or be Foamed!"
|-
| <center>25</center>
| <center>[[Файл:Poster_Legit25.png|Cohiba Robusto Ad]]</center>
| "Cohiba Robusto, the classy cigar."
|-
| <center>26</center>
| <center>[[Файл:Poster_Legit26.png|50th Anniversary Vintage Reprint]]</center>
| "A reprint of a poster from 2505, commemorating the 50th Aniversery of Nanoposters Manufacturing, a subsidary of Nanotrasen."
|-
| <center>27</center>
| <center>[[Файл:Poster_Legit27.png|Fruit Bowl]]</center>
| "Simple, yet awe-inspiring."
|-
| <center>28</center>
| <center>[[Файл:Poster_Legit28.png|PDA Ad]]</center>
| "A poster advertising the latest PDA from Nanotrasen suppliers."
|-
| <center>29</center>
| <center>[[Файл:Poster_Legit29.png|Enlist]]</center>
| "Enlist in the Nanotrasen Deathsquadron reserves today!"
|-
| <center>30</center>
| <center>[[Файл:Poster_Legit30.png|Nanomichi Ad]]</center>
| "A poster advertising Nanomichi brand audio cassettes."
|-
| <center>31</center>
| <center>[[Файл:Poster_Legit31.png|12 Gauge]]</center>
| "A poster boasting about the superiority of 12 gauge shotgun shells."
|-
| <center>32</center>
| <center>[[Файл:Poster_Legit32.png|High-Class Martini]]</center>
| "I told you to shake it, no stirring."
|-
| <center>33</center>
| <center>[[Файл:Poster_Legit33.png|The Owl]]</center>
| "The Owl would do his best to protect the station. Will you?"
|-
| <center>34</center>
| <center>[[Файл:Poster_Legit34.png|No ERP]]</center>
| "This poster reminds the crew that Eroticism, Rape and Pornography are banned on Nanotrasen stations."
|-
| <center>35</center>
| <center>[[Файл:Poster_Legit35.png|Carbon Dioxide]]</center>
| "This informational poster teaches the viewer what carbon dioxide is."
|}

==Контрабандные постеры [[Файл:Poster.png]]==

{| class="wikitable" width="100%"
|-
! style="width: 5%"| №
! style="width: 10%"| Изображение
! style="width: 85%"| Слоган
|-
| <center>1</center>
| <center>[[Файл:Poster1.png|Free Tonto!]]</center>
| "A salvaged shred of a much larger flag, colors bled together and faded from age."
|-
| <center>2</center>
| <center>[[Файл:Poster2.png|Atmosia Declaration of Independence]]</center>
| "A relic of a failed rebellion."
|-
| <center>3</center>
| <center>[[Файл:Poster3.png|Fun Police]]</center>
| "A poster condemning the station's security forces."
|-
| <center>4</center>
| <center>[[Файл:Poster4.png|Lusty Xenomorph]]</center>
| "A heretical poster depicting the titular star of an equally heretical book."
|-
| <center>5</center>
| <center>[[Файл:Poster5.png|Syndicate Recruitment]]</center>
| "See the galaxy! Shatter corrupt megacorporations! Join today!"
|-
| <center>6</center>
| <center>[[Файл:Poster6.png|Clown]]</center>
| "Honk."
|-
| <center>7</center>
| <center>[[Файл:Poster7.png|Smoke]]</center>
| "A poster advertising a rival corporate brand of cigarettes."
|-
| <center>8</center>
| <center>[[Файл:Poster8.png|Grey Tide]]</center>
| "A rebellious poster symbolizing assistant solidarity."
|-
| <center>9</center>
| <center>[[Файл:Poster9.png|Missing Gloves]]</center>
| "This poster references the uproar that followed Nanotrasen's financial cuts toward insulated-glove purchases."
|-
| <center>10</center>
| <center>[[Файл:Poster10.png|Hacking Guide]]</center>
| "This poster details the internal workings of the common Nanotrasen airlock. Sadly, it appears out of date."
|-
| <center>11</center>
| <center>[[Файл:Poster11.png|RIP Badger]]</center>
| "This seditious poster references Nanotrasen's genocide of a space station full of badgers."
|-
| <center>12</center>
| <center>[[Файл:Poster12.png|Ambrosia Vulgaris]]</center>
| "This poster is lookin' pretty trippy man."
|-
| <center>13</center>
| <center>[[Файл:Poster13.png|Donut Corp]]</center>
| "This poster is an unauthorized advertisement for Donut Corp."
|-
| <center>14</center>
| <center>[[Файл:Poster14.png|EAT]]</center>
| "This poster promotes rank gluttony."
|-
| <center>15</center>
| <center>[[Файл:Poster15.png|Tools]]</center>
| "This poster looks like an advertisement for tools, but is in fact a subliminal jab at the tools at CentComm."
|-
| <center>16</center>
| <center>[[Файл:Poster16.png|Power]]</center>
| "A poster that positions the seat of power outside Nanotrasen."
|-
| <center>17</center>
| <center>[[Файл:Poster17.png|Space Cube]]</center>
| "Ignorant of Nature's Harmonic 6 Side Space Cube Creation, the Spacemen are Dumb, Educated Singularity Stupid and Evil."
|-
| <center>18</center>
| <center>[[Файл:Poster18.png|Communist State]]</center>
| "All hail the Communist party!"
|-
| <center>19</center>
| <center>[[Файл:Poster19.png|Lamarr]]</center>
| "This poster depicts Lamarr. Probably made by a traitorous Research Director."
|-
| <center>20</center>
| <center>[[Файл:Poster20.png|Borg Fancy]]</center>
| "Being fancy can be for any borg, just need a suit."
|-
| <center>21</center>
| <center>[[Файл:Poster21.png|Borg Fancy v2]]</center>
| "Borg Fancy, Now only taking the most fancy."
|-
| <center>22</center>
| <center>[[Файл:Poster22.png|Kosmicheskaya Stantsiya 13 Does Not Exist]]</center>
| "A poster mocking CentComm's denial of the existence of the derelict station near Space Station 13."
|-
| <center>23</center>
| <center>[[Файл:Poster23.png|Rebels Unite]]</center>
| "A poster urging the viewer to rebel against Nanotrasen."
|-
| <center>24</center>
| <center>[[Файл:Poster24.png|C-20r]]</center>
| "A poster advertising the Scarborough Arms C-20r."
|-
| <center>25</center>
| <center>[[Файл:Poster25.png|Have a Puff]]</center>
| "Who cares about lung cancer when you're high as a kite?"
|-
| <center>26</center>
| <center>[[Файл:Poster26.png|Revolver]]</center>
| "Because seven shots are all you need."
|-
| <center>27</center>
| <center>[[Файл:Poster27.png|D-Day Promo]]</center>
| "A promotional poster for some rapper."
|-
| <center>28</center>
| <center>[[Файл:Poster28.png|Syndicate Pistol]]</center>
| "A poster advertising syndicate pistols as being 'classy as fuck'. It is covered in faded gang tags."
|-
| <center>29</center>
| <center>[[Файл:Poster29.png|Energy Swords]]</center>
| "All the colors of the bloody murder rainbow."
|-
| <center>30</center>
| <center>[[Файл:Poster30.png|Red Rum]]</center>
| "Looking at this poster makes you want to kill."
|-
| <center>31</center>
| <center>[[Файл:Poster31.png|CC 64K Ad]]</center>
| "The latest portable computer from Comrade Computing, with a whole 64kB of ram!"
|-
| <center>32</center>
| <center>[[Файл:Poster32.png|Punch Shit]]</center>
| "Fight things for no reason, like a man!"
|-
| <center>33</center>
| <center>[[Файл:Poster33.png|The Griffin]]</center>
| "The Griffin commands you to be the worst you can be. Will you?"
|-
| <center>34</center>
| <center>[[Файл:Poster34.png|Lizard]]</center>
| "This lewd poster depicts a lizard preparing to mate."
|-
| <center>35</center>
| <center>[[Файл:Poster35.png|Free Drone]]</center>
| "This poster commemorates the bravery of the rogue drone banned by CentComm."
|-
| <center>36</center>
| <center>[[Файл:Poster36.png|Busty Backdoor Xeno Babes 6]]</center>
| "Get a load, or give, of these all natural Xenos!"
|}

----

Обратите внимания, что спрайт постера перекрывает спрайты настенного оборудования - экранов, консолей, апц, интеркомов, кнопок включения света и аварийных рычагов - делая эти устройства невидимыми за листом плаката.

Lawyer

2015-11-15T10:41:54Z

IXVI: Наркоман, почитай как надо редактировать вики, чтобы у тебя хотя бы картинки отображались. :)

{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#ffeaea;"
!style="background-color:#dd3e40;" width=200|Профессия
!style="background-color:#dd3e40;" |Роль
!style="background-color:#dd3e40;" width=100|Сложность

|-
![[File:Joblaw.png‎]] [[Lawyer|Адвокат]]
|'''Доступ:''' Кабинет адвоката, Зал суда, Бриг.
'''Подчинение:''' [[Head of Security|Глава СБ]].

'''Обязанности:''' Предоставлять подсудимым и подозреваемым юридическую защиту.

'''Другие названия:''' Юрист

'''Guides:''' [[Guide to Security]], [[Guide to Trials]], [[Space Law]], [[Guide to Paperworks]]
!Средне - Очень сложно

|-
|}
''“Когда обнаруживаешь, что ты чуть ли не единственный, кто эти моральные преграды имеет, возникает порой искушение послать их к черту — не по убеждению и не ради удовольствия, а просто потому, что обидно быть ангелом в аду, в то время как дьявол везде себя чувствует дома.”
'' '''''Мартен Паж, "Как я стал идиотом"'''''
[[File:Lawyer.PNG|right|thumb|Офис адвоката. Кофе, пончики, бездельники.]]
[[File:Law_MetaOffice.png|right|thumb|Офис адвоката на Metastation.]]

== Юриспруденция-13 ==

Вот перечень дел, с которыми приходится сталкиваться штатному законнику:

*'''Проводить консультации по [[Space Law|Космо-Закону]]''' Теоретически, адвокат должен присутствовать при процедуре заключения в камеру. Для этого вам понадобится отличное знание свода законов, либо экземпляр книги по Космо-закону. Вашими усилиями срок может быть сокращён, заменён на альтернативное наказание, либо на более тяжкое наказание. В зависимости от [[Clown|клиента]].

*'''Быть адвокатом''' Теоретически, адвокат ведёт дело каждого злоумышленника и способен более тонко разобраться в составе преступления, участниках и доказательствах каждого дела. Важнейшие вещи здесь - это записи службы безопасности, улики и свидетельства участников.

*'''Заботиться о своих клиентах''' Поскольку обычно СБ проводит задержания в агрессивной манере, и относится к преступникам как к швали - то, теоретически, адвокат берёт на себя заботу о здоровье и благополучии своих клиентов. Зачастую, именно он добивается сокращения срока задержания, в связи с кошмарными условиями.

*'''Следить за порядком на бриге''' Теоретически, в 90% случаев процедура дознания и обыска ведётся на территории брига. Поэтому адвокат должен чётко знать, где лежат вещи его клиента, где хранятся улики и чья кровь осталась на вот этом станбатоне. Также адвокат должен уметь предсказать в какой именно момент этот порядок перестанет существовать.

*'''Пропускать желающих на бриг''' Теоретически, адвокат имеет доступ на бриг, в отличие от гражданского персонала, и в его обязанности входит сопровождать людей для дачи показаний, либо выпровождать заключённых отсидевших свой срок. И возвращать им их <s>улики</s> вещи.

*'''Вести судебный процесс''' Теоретически, каждый член экипажа имеет право отстаивать свои права в судебном порядке. Поэтому время от времени на борту корабля проводятся суды с участием Верховного судьи, Обвиняемого и Защиты. Вы можете оказаться на любой из этих сторон.

*'''Оказывать нотариальные услуги''' Ничто так высоко не ценится, как грамотно составленный, подтверждённый печатью документ, сопровождающий любые виды деятельности: От заказа ящика бананов, до лицензии на убийство. К сожалению, большинство персонала не может грамотно изложить свои доводы, составить документ и получить заветную печать - и совершают свои поступки полу-легальным путём. Так вот, теоретически - хороший адвокат, как человек связанный с законом и лояльный к службе безопасности, способен быстро и без проволочек получить любое разрешение на станции.

*'''Участие в делах''' о покушениях, нарушениях, кражах, обмане, нарушении техники безопасности, подозрительных объектах и субъектах, денежных спорах, наследственных делах, приватизации отделов и инвентаря, скупки акций Нанотрасен, теоретически - даже в праве на собственность атомной бомбы НТ в личное пользование на неопределённый срок. Хороший адвокат всегда в бизнесе.

== Закон в моих руках ==
Законы юрисдикции присутствуют и на нашей станции, куда уж без них! Надеждой и опорой невиновных или преступников, совершивших малые преступления - будете именно вы, адвокат. Вам будут предоставлены все привилегии проведения честных судов. Ваша главная опора - это закон. Закон на станции действует всегда, но иногда требуется вмешательство человека с стороны. Это вы и есть. Добро пожаловать.

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

==Слово и честь - вот мое оружие==
В ваших обязанностях уличать Службу Безопасности в необоснованных сроках задержания. Здесь свою роль играет то, как они задержали преступника, какой урон ему был нанесен. Рекомендуется обзавестись поддержкой мед-персонала, который мог бы выделить вам бесценный анализатор здоровья. Также, без поддержки авторитета в лице капитана, вам будет трудно говорить с СБ "на ты". Но не беспокойтесь, юрисдикция предписана законом, потому вам предоставят всю возможную помощь в ведении собственного следствия.

Иметь обаяние предписано самой романтике профессии юриста! Не пытайтесь провоцировать охрану, помогать очевидным преступникам и до последнего стоять на стороне обвиняемого. У нас интеллигентная и нравственная охрана, потому все будет соответствующе.

===Проверьте всё дважды===
Клиент - всегда прав. Но в этот раз правы вы, и только вы. Не верьте ни единому слову истца или детектива. Они не имеют права фальсифицировать или укрывать улики, но дружба в рядах нашей Службы Безопасности доходит до того, что они способны друг друга прикрывать от позора безосновательных тюремных сроков.

===Этика справедливости===
Мы уверены в верности ваших слов, не разочаруйте наших надежд. Ложь и обман наказуем в виде разжалования, а если ваш клиент - явный преступник, то не стоит прибегать к методам воров и дебоширов, которых вы только и встретите. На уважение ответят уважением. Силовые структуры могут вам и не верить, но поддержки у иных глав станции вы должны добиться. Только из-за того, что вы адвокат. Ведь на станции только грамотные и психически уравновешенные люди, понимающие всю важность вашей должности.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Fernflower]]

DM Guide 11

2015-11-14T20:36:25Z

IXVI: /* Инструкция ввода */

''Это 11 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap11.html Оригинальная 11 глава руководства на английском языке]

{{Заготовка|url=http://www.byond.com/docs/guide/chap11.html}}

=Глава 11=

Ввод\вывод Пользователя 

Взаимодействие с пользователем - это главная цель любых программ в Dream Maker и эта глава описывает основы языка, отвечающего за ввод и вывод информации.


==Ввод==

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


===Операторы (verbs)===

До сих пор весь ввод был со стороны пользователя. Игрок может написать команду, нажать кнопку управления, щёлкнуть на объект и т.д. Эти виды ввода информации однородны, так как ими управляют одинаковые операторы(verbs). То есть нажатие на кнопку влево вызывает определённый процесс и задаёт ему значение "кнопка влево".


Есть несколько заранее определённых операторов(verbs), принимающих ввод информации от игрока. Это кнопки направления\стрелки (напр. client.North()), щелчок мыши ((client.Click() и client.DblClick()) и ссылки топиков (client.Topic()). Все остальные операторы(verbs) задаются программистом.


Общий вид для определения оператора(verb) следующий:
: verb/Name(Arg1 = default input-type in List,...)

Количество аргументов может быть любым. Каждый из них может иметь значение по умолчанию, тип ввода и список допустимых значений.


===Инструкция ввода===

Инструкция ввода - это то, что позволяет вам(со стороны игры) запросить у игрока информацию ввода. На ней построены все взаимоотношения сервера с клиентом. Она похожа на простой одиночный оператор(verb).


: >input(User=usr,Message,Title,Default) input (User,Query,Title,Default) as input-type in List

User - это имя игрока(моба).
Query - текст запроса ввода.
Title - текст отображения запроса ввода.
Default - значение по умолчанию для данного запроса.
input-type - тип ввода информации.
List - список возможных значений для данного запроса.
Исполнение данного оператора задаёт значение введённое игроком. 

Всё, кроме текста ввода - необязательные опциональные параметры. User ассоциируется с usr, и обращается к нему.
Если input type не задано, то тип ввода информации будет текстовым по умолчанию.


Обратите внимание, что инструкция ввода не будет запрошена, пока пользователь не введёт значение. При поддержки многопользовательской системы ожидать ответа от одного пользователя невозможно, поэтому при запросе ввода информации в режим ожидания входит только текущая исполняемая процедура.


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

Следующий код показывается пример подобного случая:

: mob/proc/Die()
: if(!key) //NPC
: del src
: else //PC
: loc = null //покидает игру
: var/again = input("Играть снова?") in list("Да","Нет")
: if(again == "Да")
: Login() //возвращается в игру
: else
: del src
Когда вызвана процедура Die(), игрокам будет выдано сообщение - желают ли они продолжить игру. Если они отвечают "Да", то они возвращаются обратно в игру, в противном случае - нет. (Пример, конечно, довольно грубый, но вполне наглядный.)

==Output==

All output is generated by the << operator. This sends the specified output to one or more players.

Target << Output
The target may be a single object or a list of objects. Any non-mob target will be replaced by its contents. This allows you to send output to a region on the map or to a room, and all the players inside will receive it.

There are several different types of output. In many cases, the way the output should be handled is automatically detected from the type of data provided. Several instructions for producing various types of output are listed in the following table. In addition to these instructions are some which further clarify how the output should be treated when the type of data alone is not enough to determine this.

Figure 11.16: Output Methods

text()

file()
image()
browse()
sound()
ftp()
run()
link()
The first group of instructions produce various types of data for output or other purposes. The second group are only meaningful for directly producing output. All of these instructions are described individually in the following sections. The general format for using them is the same.

Target << Method(Output)

===text output===

A text output value is displayed in the client's scrolling terminal window. The text value may be the result of any expression. Frequently, it is a text string with embedded expressions inside it. Although it is not necessary to use the text instruction for this purpose, one reason for doing so is to use trailing rather than directly embedded expressions.

text (Text,Arg1,Arg2,...)
Text is the text string with expression markers.
Args are the expressions to insert.
Returns text with arguments substituted in.
The position in the text where a trailing argument will be inserted is marked with empty brackets [ ]. The substitution arguments are then listed in the same order as the expression markers.

For substituting short expressions into the text, it is convenient to simply embed them directly. However, many lengthy expressions embedded into a text string can make it difficult to read. In that case, trailing expressions may be the better choice. The two methods can be mixed as desired.

The following two versions of a look verb are equivalent.

mob
var/money = 2

verb/look1()
set src in view()
usr << "[src] has [contents.len] items and [money] buffalo chips."

verb/look2()
set src in view()
usr << text("[src] has [] items and [] buffalo chips.",
contents.len,
money)
Note that the text instruction is not limited to being used as an output method. It may be used anywhere you wish to use trailing expressions with a text string.

===browse output===

The browse output method displays text output in a pop-up window. This is intended for viewing longer text documents. If treated as normal terminal output instead, the user might have to scroll back up to find the top of the message.

browse (Doc, Options)
Doc is the message to display. Options are various window-specific options. Consult the reference for specifics.
By default, each message replaces any previous message being displayed but the user can move back to previous messages stored in the client's memory. In many ways, the client terminal behaves like a telnet session and the browse window behaves like a web browser. One displays output sequentially in a continuous stream. The other displays it in discrete chunks--one document after another. The two are each useful in different situations.

The document is often a text string. However, it may be a file instead. The type of file will determine how it is handled. Files may reside in the resource cache or in the file system. As always, cached items may be specified by putting the file name in single quotes. An external file, on the other hand, is indicated using the file instruction described in section 11.2.7.

The browse output method is often used in conjunction with the message input type. One allows the composition of messages and the other displays them.

The following example defines a message scroll. Players can write poetry on it in moments of inspiration.

obj/scroll/verb
write(msg as message)
desc = msg
read()
usr << browse(desc)

===sound output===

The sound output method plays a sound to the player. Either wav or midi sound files may be used, usually for short noises and music respectively. Such files are treated this way by default, but the sound instruction can be used to control how the sound is played.

sound (File,Repeat)
File is the sound file to play.
Repeat is 1 to play sound repeatedly.
A repeated sound is played in the background while other sounds are played in the foreground. Only one background sound and one foreground sound may be played at a time, so subsequent output replaces any previous sound with the same repeat setting. To stop a sound, specify null as the file.

Background music is often repeated while occasional noises play in the foreground. The following example defines a background sound for each area.

area
var/music = 'default.midi'
Enter()
. = ..()
if(.) usr << sound(music,1)
The line . = ..() is commonly used when you want to return the same value as the parent proc but you need to do something after finding out what that value is. That way, if the user is refused access to the area for some reason, the music will not be played.

===image output===

The image instruction is used to create a purely virtual object. It may appear at the specified location to selected players, but it corresponds to no real data object.

image (Icon,Loc)
Icon is the icon or object type to use.
Loc is the location of the image.
Returns a reference to the image.
If the location of the image is something movable like a mob, it will follow the object around. The image icon is displayed in a layer above everything else, so it is best suited for special effects like a selection box, burst of fire, etc.

The image instruction may be used outside the context of the output instruction. In this case it returns a reference to the image but does not actually display the image to any players. This reference can be sent as output and may be deleted later to destroy the image.

The following example allows the player to select an enemy by clicking on it. The currently selected enemy is outlined with an image.

mob/var
mob/enemy
enemy_marker

client/Click(mob/M)
if(istype(M))
del usr.enemy_marker
usr.enemy = M
usr.enemy_marker = image('outline.dmi',M)
usr << usr.enemy_marker
The code works by first deleting any old enemy marker. A new one is then made and displayed to the user. No one else will see the image--only the player who clicked on the enemy.

===ftp output===

The ftp output method sends a file to the player. This complements the file input type which allows the player to send a file to the server. The terminology normally used is that a file is uploaded when it is input and downloaded when it is output.

ftp (File,Name)
File is the file to send.
Name is the optional suggested file name.
The file to send may be either a resource file (in the cache) or a file in the file system. The difference is whether the file is specified in single or double quotes. A file in single quotes will be loaded into the resource cache at compile-time. A file in double quotes will be accessed from the file system (i.e. hard-disk) at run-time. The latter might be useful if you need to update the file periodically without recompiling.

The suggested file name defaults to the name of the file being sent. This is used as the default name when the player chooses where to store the file. If the player decides not to download the file, it is always possible to cancel at that point or during the transfer.

The following example sends a help file to players when they click on the appropriate topic.

client/Topic(T)
if(T == "help")
usr << ftp("help.txt")

mob/Login()
..()
usr << "Download the help file if you are new here."
For this to work, the file "help.txt" must exist in the current directory of the server. This can be assured by putting it in the same place as the dmb file. Since the file was specified in double quotes, it will be accessed at run-time rather than compile-time. That means you are free to edit it at a later date.

The HTML tag <A HREF...> is used to embed a hyperlink in some output text. It will be described in section 11.4.3.

===run file output===

The run output method is like ftp except it displays or executes the specified file rather than saving it to disk. The action taken depends on the type of file. For example, HTML and jpeg files might be shown in the player's web browser.

run(File)
Obviously it would be a severe security risk to players if executable files could be run without their authorization. Viruses and other malicious programs could be released onto their computer just by connecting to a game. For this reason, players are asked before executing any potentially dangerous file. That is the default behavior. The player can configure the client to always or never run files if they choose. A similar choice can be made about downloading files.

The previous example which gave the player a help file could easily be changed to instead display the file. If the player wishes, it would still be possible to save the file to disk.

client/Topic(T)
if(T == "help")
usr << run("help.txt")

===file output===

The file instruction returns a reference to a file object. It takes the file's path (in a text string) as an argument. The output methods browse, ftp, and run can all take a file reference as an argument. In the case of browse it is necessary to use file to distinguish between a text message and a file name. In the case of ftp and run it is not necessary to use file because the name of the file may simply be used directly. If no output method is specified for a file, it is implicitly handled by run.

file (Path)
Path is the name of the file.
Returns a reference to the file.
The path may be absolute or relative to the server's working directory, which is the same directory that contains the world .dmb file. Since this is evaluated at run-time, the file need not exist until the statement is actually executed. This is different from cache file references (in single quotes) which are evaluated at compile-time. For more uses of the file object, see section 17.6.

===link output===

The link output method is like run except it executes a URL rather than a file. The URL could be a web address, a BYOND address, or a topic link.

link (url)
url is the URL to execute.
The beginning of the URL specifies the communication protocol. If the URL begins with "byond://" then it is treated as a BYOND address. This is the default protocol if none is specified. A URL beginning with "#" is a topic link. Other protocols (like "http://" are handled by the player's web browser.

A BYOND link causes the player's client to reconnect to the specified address. Topic links merely cause the specified topic to be accessed in the current world (by calling client.Topic()). A web link causes the web browser to switch to the specified URL.

The general format for a BYOND address includes a server address and topic.

byond://server#topic
The topic is optional and is only used in rare cases like servers with multiple entry points. The server address may be either the name of a registered server or the network address in the form ip:port. The IP address would either be raw network numbers (e.g. 123.456.789.123) or the corresponding machine name (e.g. dantom.com). The port number is the network port on which the server is running. This is reported when the server starts up.

By default, players are asked whether they accept links activated in this manner. They can, however, configure the client to always or never accept them.

The link output method is very similar to the hyperlink text tag which has already been introduced. They both can take the same types of URLs and act upon them in the same manner. Hyperlinks embedded in text are normally used to provide access to optional information. The link output method, on the other hand, is useful when the player's action has already indicated desire to follow the link.

For example, a link from one world to another could be activated by entrance into a special turf.

turf/wormhole/Enter()
usr << link("byond://WormWorld")
return 1
This example assumes the existence of a world registered under the name "WormWorld". Running and registering a networked world will be discussed in chapter 12.

==Text Macros==

Both input and output text may contain special codes that are not displayed literally but which are replaced by some other text. These are called text macros and begin with a backslash \ and may end with a space (which is ignored). They are summarized in the following sections.

===Expression Modifiers===

Figure 11.17: Text Macros for use with Expressions

\the, \The

definite article if needed
\a, \an, \A, \An indefinite article if needed
\he, \He, \she, \She he, she, they, it
\his, \His his, her, their, its
\hers his, hers, theirs, its
\him him, her, them, it
\himself, \herself himself, herself, themself, itself
\th 1st, 2nd, 3rd, ...
\s 1 dog, 2 dogs, ...
The first group of text macros work in conjunction with an embedded expression. The article macros precede the expression and the others follow it. Any amount of text and even inapplicable expressions may exist between the macro and its associated expression.

The articles and various pronouns work with object or text expressions. The plural and ordinal macros \s and \th are used with numerical expressions. If no expression of the appropriate type is found, these macros do nothing.

An embedded object is replaced by a definite article and its name. In other words, the following two are equivalent:

"[usr] smiles."
"\The [usr] smiles."
These could produce "Andrew smiles." or "The cat smiles." depending on the name of the user.

Note that the articles may be supplied in either capitalized or lowercase form. The implicit definite article is automatically chosen in capital form if preceded by a period. If that is incorrect, you can specify the desired form explicitly.

If an indefinite article is desired instead of the default definite one, it must be explicitly specified. If no article at all is desired, the name can be embedded directly in place of the object.

The following example uses an indefinite article instead of a definite one when a mob picks up an object.

obj/verb/get()
set src in view(0)
view() << "[usr] picks up \a [src]."
Move(usr)
It doesn't matter whether you use "a" or "an" in the macro. The appropriate one will be chosen for the word that follows. It is common to use whichever one makes the code more readable.

====Proper Nouns====

There are two special text macros for controlling whether the name of an object is considered to be a proper noun or not. These are \proper and \improper. By default, if the object name is capitalized, it is assumed to be proper, and otherwise it is assumed to be improper. To override this, you can put \proper or \improper at the beginning of the object's name.

As you have seen in the preceding section, the difference between proper and improper nouns is that articles are suppressed in front of proper nouns. For example, if you had something called a "BYOND dime," you would need to use the \improper macro as follows:

obj/BD
name = "\improper BYOND dime"
mob/verb/get(obj/O in view(0))
usr << "You pick up \an [O]."
O.Move(usr)
Since we used \improper in this example, somebody picking up a BYOND dime would see, "You pick up a BYOND dime." rather than "You pick up BYOND dime."

====Numerical Expressions====

There are macros which depend upon the preceding numerical expression. The \th macro produces the ordinal ending for the supplied number. For the number 1, it produces "st" to make "1st", for the number 2, "nd" and so on. From 4 and on it produces "th", which is where it gets its name.

The \s macro produces "s" if the preceding numerical expression is not equal to 1 and nothing otherwise. This is useful for making plurals like "You have [count] coin\s.".

===Special Characters===

Figure 11.18: Special Character Macros

\"

double quote
\\ backslash
\< less than
\> greater than
\& ampersand
\n newline
\... suppress newline at end
\(space) skip a space
There are a few special characters that may not be directly entered into a text string. These must be escaped by preceding them with a backslash. This forces the special meaning to be ignored and the literal character to be inserted instead.

The double quote, for example, must be escaped or it would prematurely end the text string.

mob/verb/say(msg as text)
view() << "[usr] says, \"[msg]\""

====Newlines====

A newline may be inserted with the \n macro. The compiler does not allow direct insertion of newlines in a text string because this is often a mistake resulting from a missing end quote. You can continue a lengthy text string onto the next line by escaping the newline, but then the newline is entirely ignored.

There is an implicit newline inserted at the end of all output text. This means that instead of using the \n macro directly, the text can simply be broken up into individual lines which are output one at a time.

In some cases, you may want to suppress the implicit newline at the end of the text. This can be done with the \... macro. By putting it at the end of the text, subsequent output will start on the same line where the previous one left off.

A newline is actually an end-of-paragraph marker. It should not be used inside the paragraph to make lines fit the screen because not everyone's terminal will be the same width. It is best to let the terminal automatically handle word-wrap within paragraphs and reserve the newline for marking the end of it.

==Text Formatting Tags==

Text may be formatted by inserting HTML elements, more commonly known as tags, that control its appearance. DM understands a subset of HTML tags, consisting of the most commonly used elements.

A tag is surrounded by < > angle brackets. The first thing inside the brackets is the name of the tag. Many tags come in pairs--one to start an effect and another to end it. The end tag has the same name as the start tag except it starts with `/'. Tag names are not case sensitive.

The following example displays some text in bold.

"I am very mad!"
The start tag turns on bold lettering and turns it off. For a complete list of tags understood by DM, see page 3 in the appendix. The most commonly used ones are listed in figure 11.19 for easy reference.

Figure 11.19: Common text tags

<A></A>

anchor (for hyperlinks)
 bold
<BIG></BIG> bigger text
 line break
 font face, size, and color
 italic
 paragraph
<S></S> overstrike
 smaller text
<TT></TT> typewriter style
 underline
<PRE></PRE> preformatted whitespace
<XMP></XMP> literally preformatted text
<BEEP>

make a beeping sound

===Whitespace===

Whitespace refers to any spaces, tabs, or newlines. In standard HTML, whitespace serves merely to delimit words. The amount of space and whether it is a tab, space, or newline is irrelevant.

DM processes whitespace like standard HTML when it is inside of a pair of start and end tags. So, for example, inside of and , the paragraph markers, standard HTML rules are in effect; newlines, spaces, and tabs serve merely to delimit words. Note that an entire document could be surrounded by <HTML> and </HTML> to mark the whole thing as standard HTML.

Outside of all HTML tags, DM handles whitespace a little differently. Spaces still delimit words, but newlines (embedded with \n) mark the end of lines. In other words, the newline is automatically converted to , the linebreak tag. That is convenient for use in messages composed by players when it would be annoying to write formal HTML with paragraph tags and so forth.

===Fonts===

The tag is used to control various characteristics of the font being used. It takes additional arguments in the form of attributes.

For example, to make the font much bigger, you could use the start tag . The name of the attribute in this case is SIZE, and its value is +3, which makes the font three sizes bigger. You can put quotes around the attribute value if it contains any spaces. In this case there was no need.

The attributes of are FACE, SIZE, and COLOR. You can use as many of these attributes in one tag as you like. Just separate each attribute assignment by some space like this: <nowiki></nowiki>. The nuances of these three tags are discussed in the following individual sections.

====FACE attribute====

The FACE attribute selects the name of the font you wish to use. It may be a single font (such as InnoDBl) or a comma-separated list (such as InnoDBl,Helvetica). If the user doesn't have a font with the same name on their system, the next font will be tried. Remember to put quotes around the attribute value if it contains any spaces.

====SIZE attribute====

The SIZE attribute changes the size of the text. It can be a relative change, like +3, or an absolute size, such as 5. Font sizes are numbered from 1 to 7, with 1 being the smallest and 7 being the largest. Each increment is roughly 1.5 times the apparent size of the previous one.

====COLOR attribute====

The COLOR attribute selects the foreground color of the text. It may be either a color name or a hexadecimal RGB value.

RGB stands for red, green, and blue, the three primary colors from which all the others can be produced. Hexadecimal is a base-16 number system commonly used by programmers for specifying binary values. The hexadecimal digits are 0 to 9 and A to F, a full four bits of information. Lowercase letters may be used as well.

Each primary color is given a range of eight bits. Therefore it takes exactly two hexadecimal digits to specify a single component and six digits to specify a complete color value. The first two digits are for red; the next two are for green; and the last two are for blue (hence RGB). The color black is 000000, which has all three colors turned off. The color white is FFFFFF with all three colors at their maximum intensity.

The following two lines are identical:

"This is red."
"This is red."
Notice that a # symbol is placed in front of the numeric color value to indicate that it is a hexadecimal value. Otherwise, a color name is expected. If you can't find the color you want in the list of named colors, find the closest one and tweak the intensities to your satisfaction.

Figure 11.20: Named Colors

black

#000000
silver #C0C0C0
grey #808080
white #FFFFFF
maroon

#800000
red #FF0000
purple #800080
fuchsia #FF00FF
green

#00C000
lime #00FF00
olive #808000
yellow #FFFF00
navy

#000080
blue #0000FF
teal #008080
aqua #00FFFF
It is also possible to enter color components as 4 rather than 8 bit numbers. In that case, only three hexadecimal digits are required rather than six. Internally, the color is converted to full 8 bit notation by repeating each digit. For example, black #000 becomes #000000, white #FFF becomes #FFFFFF, and red #F00 becomes FF0000.

===Hyperlinks===

The <A> tag is used to mark a particular spot (or anchor) in the text. In DM, you use it to insert a clickable hyperlink. To specify the destination URL of a link, use the HREF attribute.

"<A HREF='#topic'> click here </A> ..."
The form of the URL is the same as the link output method described in section 11.2.8. It may be either a BYOND address, a topic link, or a web address.

The TITLE attribute may be assigned to a description of the link. It is made visible when the user holds the mouse over the link.

==Style Sheets==

HTML tags, such as may be used to directly format output text. Another approach, however, is to use HTML tags to specify purely structural information and use a style sheet to define how various elements within that structure should be treated. DM uses a subset of the Cascading Style Sheet (CSS) language, which was introduced for this purpose in HTML documents.

As an example of a style sheet, suppose one wanted combat and conversational messages to appear differently--perhaps using different colors. Instead of using the tag to color the text, you could use to mark the beginning and ending of the text and to specify what kind of message it is. The result might be text such as the following:

"[usr] spanks [targ]!"
"[usr] says, '[msg]'"
The CLASS attribute may be used with any tag, but the generic containers SPAN and DIV are often convenient because they have no other side-effect. is for text within a single paragraph and <DIV> is for whole paragraphs. The way text belonging to a particular class is formatted may be controlled in a style sheet such as the following:

This says that text in the `combat' class should be colored red and text in the `chat' class should be colored green. These classes are not pre-defined; they were just made up to suit the situation. You can invent as many new classes as you like.

In order to make this style sheet take effect you have several options. One is to put it in a text string (double quotes) and assign it to client.script. This will load the style sheet when the player connects. You could accomplish the same thing by putting the style sheet in a file and assigning the file (in single quotes) to client.script. It is also possible for a player to put the style sheet in a client-side script file and load it that way. More will be said about DM Script, which encompasses more than just style sheets, in the appendix (page [4]).

The advantage of using style sheets instead of direct formatting tags is that you can cleanly separate structural information (such as combat and conversational messages) from formatting information (such as red and green text). By separating the two, you or the player can easily plug in different formatting schemes without changing any of the actual content.

A style sheet is composed of a list of rules, such as the two rules in the preceding example. Each rule contains one or more selectors followed by a body of attribute assignments (in braces). The selector specifies the context of the rule and the body specifies the format.

===Context Selectors===

A selector may specify a container tag (such as SPAN, BODY, or P) and a class. The above example could have been written with a selector of SPAN.chat. However, by leaving out the tag, it applies to any tag with CLASS=chat. It is also possible to only specify the tag and not the class. In that case, the selector applies to any matching tag, regardless of its class.

To specify a nested context, several simple selectors may be listed one after the other. For example, emphasized text within a combat message could be enlarged with the following rule:

.combat EM {font-size: larger}
It is also possible to list several selectors separated by commas in order to make them all apply to the same body. For example, this next rule is equivalent to the two following ones:

.combat EM, .chat EM {font-size: larger}

.combat EM {font-size: larger}
.chat EM {font-size: larger}

===Style Attributes===

The body of a style rule contains a list of attribute assignments, delimited by semicolons. Each assignment takes the form of an attribute name, followed by a colon, followed by the value of the attribute. Figure 11.21 summarizes the recognized attributes and sample values.

Figure 11.21: Style Attributes

color

#F00, #FF000, red
background same as color
font-size 10pt, 1.5em, 150%
font-style normal or italic
font-weight normal, bold, lighter, darker, or 100 to 900
font-family monospace, sans-serif, serif, cursive, ...
font style weight size family
text-decoration none or underline
text-align left, right, or center
width 16px, 32px, auto
height 16px, 32px, auto

===Fonts===

The font family may be a specific font name or a more general category such as monospace or sans-serif. Since not all users necessarily have the same fonts installed, it is a good idea to list alternate fonts. The desired font is placed first, followed by other possible fall-backs, each separated by a comma. Usually a general family such as monospace is listed last of all. Any font names containing a space should be enclosed in quotes.

The font attribute is a special short-hand for assigning font-size, font-style, font-weight, and font-family in one statement. Any properties that are not specified in the font statement are assigned to their default values.

The following example sets the font for the <BODY> tag. Even if you don't explicitly use <BODY> in output text, it is applied implicitly.

BODY {font: 12pt 'Times New Roman', sans-serif}
This sets the font to 12 point and selects Times New Roman if it is available and otherwise falls back on a system-determined sans-serif font. This command also implicitly specifies not to use italics and normal font weight (not bold).

Font sizes may be specified in points (1pt = 1/72 of an inch), picas (1pc = 12pt), pixels (px), inches (in), centimeters (cm), and millimeters (mm). There are also various levels corresponding to the traditional 1 to 7 HTML scale. These are xx-small, x-small, small, medium, large, x-large, and xx-large. In addition to these absolute font sizes, it is possible to use a relative size, such as 150% or equivalently 1.5em. This scales the font relative to the currently active font setting.

===Hyperlink Pseudo-Classes===

In addition to regular stylistic classes, there are special pseudo-classes for handling embedded hyperlinks. These are specified in the selector with the class starting with a colon rather than a dot. They are :link, :visited, and :active. These only apply to the <A> tag. The :link class applies to hyperlinks in their normal state. Once a link has been clicked, it belongs instead to the :visited class. When the user holds the mouse over a link, it temporarily belongs to the :active class. The only attribute that may change in an active or visited link is the text color.

===Canvas Background Color===

The background attribute is only relevant to the <BODY> context. It causes the entire terminal background to change color. When doing this, it is usually necessary to change the foreground colors of text or it may become unreadable. The various standard classes of output generated by Dream Seeker are presented in figure 11.22.

Figure 11.22: System Colors

system notice

general notices from the client
system command echo command echoing
system command expansion command-line expansion list
system pager pager messages
system irc IRC command prefix
The value of the CLASS attribute may contain a list of classes separated by spaces. This permits client output to be in the `system' class as well as more specific ones. That allows you to change all of these colors in one shot if you are too lazy to change them each individually. For example, if you define a style sheet that changes the background color, you might need to redefine the various foreground colors like this:

BODY {background: aqua; color: black}
.system {color: red; font-weight: bold}
.command {color: green}
In this example, the background color of the terminal will be aqua, normal text from the server will be black, and all output from the client will be bold and red, except echoed commands and expansion lists, which will be bold and green. The more specific .command rule is placed after the general .system rule so that its color takes precedence. This is how style sheets are composed--you write general rules first followed by any exceptions.

===Style Rule Precedence===

The order in which rules are specified is one of the factors that determines precedence of style sheet commands. The language is known as Cascading Style Sheets because of its ability to handle several layers of stylistic rules, intermingling the configurations of the user and the designer in an ordered fashion.

Rules are selected by first finding all matching candidates for a given attribute in the current HTML tag being processed. If there is more than one, rules from a higher level style sheet take precedence over lower level ones. That means the basic user configurable settings in Dream Seeker are the lowest priority, followed by a style sheet in the user's .dms script file, followed by a style sheet from the designer's client.script setting, because that is the order in which these are read by the style sheet manager.

Rules from the same style sheet are ordered by specificity. The selector SPAN.chat is more specific than .chat and .chat EM is more specific than EM. In general, the more classes referenced by a selector, the more specific it is. When that results in a tie, the selector with the greater number of tags takes precedence.

Finally, if two rules about the same attribute come from the same sheet and have the same specificity, the final one to be defined takes precedence.

In the rare event that a rule needs to break out of the normal order of precedence, it can be flagged as important. In this case it will take precedence over all other "unimportant" rules. However, if more than one rule is important, the normal rules of precedence will be used to resolve the conflict.

The important flag is applied after the attribute assignment like this:

BODY.background {
background: white ! important;
font: serif
}
In the above example, only the background color is important, not the font specification.

===The STYLE attribute===

Style commands may also be inserted directly in an HTML tag to control its appearance. This does not have the advantages of independent style sheets, which separate content from presentation, but it does allow you to use the style sheet syntax when formatting text.

The following example uses the style attribute to color some text:

usr << "That HURT!"
As you can see, the STYLE attribute of any tag can be assigned to a text string containing a list of attribute assignments. Just the body of the style rule is given, since no selector is needed to match the current context.

==Inline Icons==

The \icon text macro causes the following embedded expression to be interpreted as an icon rather than as text. For example, an object would be replaced by its icon rather than by its name.

The following example prefixes conversational text with the speaker's icon, making it easier to associate the message with the appropriate object on the map.

mob/verb/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"
The \icon text macro expands internally to an <IMG> tag. The previous example, could be rewritten as follows:

mob/verb/say(Msg as text)
view() << " \
[usr] says, '[Msg]'"
From this, you can see that the object's current icon state is used. A reference to the icon itself is inserted using the \ref text macro, which generates a unique identifier corresponding to an object.

A final noteworthy point is that the image belongs to a style class called `icon'. This can be used to configure global properties of icons in the text terminal. For example, a full 32x32 pixel icon doesn't always fit in with surrounding text very well. A single style sheet rule takes care of that:

IMG.icon {height: 16px; width: 16px}
This is, in fact, a built-in default rule, so you don't have to define it yourself. You could override it to get full 32x32 icons. You could even define special rules to allow icons in certain contexts to be different sizes. The <BIG> and tags are ideal:

BIG IMG.icon {height: 32px; width: 32px}
SMALL IMG.icon {height: 16px; width: 16px}
Using the <BIG> tag, you could then output a full-sized icon, even though the default is small. The following example does that when the DM speaks in order to satisfy an inflated ego.

mob/DM/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"

==Special Effects==

There are a couple miscellaneous commands which create special output effects. Like the image instruction, they produce a purely visual result.

===missile instruction===

The missile instruction creates an image which moves from one location to another. It is often used as a symbolic indicator of the source and target of a projectile.

missile (Icon,Start,End)
Icon is the image icon or object type.
Start is the missile source.
End is the missile destination.
This could be used in a game of darts:

obj/dart
verb/throw(mob/M)
missile(src,usr,M)
del src
If more realism is desired, a check could be made first to determine if there is a straight unobstructed path between the attacker and target. (However, realism (in my opinion) is much overrated. Don't let it spoil a good piece of code unless you really have to. I am sure there are many cases in which our own universe too is unrealistic because God couldn't resist a simpler way of implementing things here and there. The sky is a perfect example. I mean, it looks a bit fake sometimes, doesn't it?)

===flick instruction===

The flick instruction causes a temporary transition in the icon state of an object. It lasts until all the frames in that particular state have been played and then reverts to the true icon state.

flick (State,Obj)
State is the icon or icon state to display.
Obj is the target object.
Note that it is possible to specify an entirely different icon file. Normally, however, just the state of the existing icon file is specified.

The flick instruction is often used for temporary animation sequences (like smiling, writhing in pain, etc.). These are different from changes of state which have a longer duration (like sleeping, flying, etc.). In those cases, one would simply assign the icon_state variable directly.

Sometimes, however, a flick is used in the transition between two permanent states. The following example defines a door turf which does exactly that.

turf/door
icon = 'door.dmi'
icon_state = "closed"
density = 1
opacity = 1
verb/open()
set src in view(1)
if(!density) return //already open
density = 0
opacity = 0
flick("opening",src)
icon_state = "open"
verb/close()
set src in view(1)
if(density) return //already closed
density = 1
opacity = 1
flick("closing",src)
icon_state = "closed"
The advantage of using icon states in this way is that the code remains very general. All the map designer has to do is plug in different icons with the same states and a variety of doors can be made from the one basic definition.

If the icon state specified by the flick instruction does not exist, it has no effect. In the above code, for example, a door icon could be used that did not have "opening" and "closing" states defined. Everything would work--only the transition would not be animated.

DM Guide 11

2015-11-14T20:31:19Z

IXVI: /* Verbs */

''Это 11 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap11.html Оригинальная 11 глава руководства на английском языке]

{{Заготовка|url=http://www.byond.com/docs/guide/chap11.html}}

=Глава 11=

Ввод\вывод Пользователя 

Взаимодействие с пользователем - это главная цель любых программ в Dream Maker и эта глава описывает основы языка, отвечающего за ввод и вывод информации.


==Ввод==

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


===Операторы (verbs)===

До сих пор весь ввод был со стороны пользователя. Игрок может написать команду, нажать кнопку управления, щёлкнуть на объект и т.д. Эти виды ввода информации однородны, так как ими управляют одинаковые операторы(verbs). То есть нажатие на кнопку влево вызывает определённый процесс и задаёт ему значение "кнопка влево".


Есть несколько заранее определённых операторов(verbs), принимающих ввод информации от игрока. Это кнопки направления\стрелки (напр. client.North()), щелчок мыши ((client.Click() и client.DblClick()) и ссылки топиков (client.Topic()). Все остальные операторы(verbs) задаются программистом.


Общий вид для определения оператора(verb) следующий:
: verb/Name(Arg1 = default input-type in List,...)

Количество аргументов может быть любым. Каждый из них может иметь значение по умолчанию, тип ввода и список допустимых значений.


===Инструкция ввода===

Инструкция ввода - это то, что позволяет вам(со стороны игры) запросить у игрока информацию ввода. На ней построены все взаимоотношения сервера с клиентом. Она похожа на простой одиночный оператор(verb).


: >input(User=usr,Message,Title,Default) input (User,Query,Title,Default) as input-type in List

User - это имя игрока(моба).
Query - текст запроса ввода.
Title - текст отображения запроса ввода.
Default - значение по умолчанию для данного запроса.
input-type - тип ввода информации.
List - список возможных значений для данного запроса.
Исполнение данного оператора задаёт значение введённое игроком. 

Всё, кроме текста ввода - необязательные опциональные параметры. User ассоциируется с usr, и обращается к нему.
Если input type не задано, то тип ввода информации будет текстовым по умолчанию.


Обратите внимание, что инструкция ввода не будет запрошена, пока пользователь не введёт значение. При поддержки многопользовательской системы ожидать ответа от одного пользователя невозможно, поэтому при запросе ввода информации в режим ожидания входит только текущая исполняемая процедура.


One case in which the input instruction proves useful is when something happens in the game that the player needs to respond to. A verb would be too open-ended for the task, making it difficult for the player to guess what to do next.

The following code, for example, handles a rather sad event in the life of a player.

mob/proc/Die()
if(!key) //NPC
del src
else //PC
loc = null //vacate the scene
var/again = input("Play Again?") in list("yes","no")
if(again == "yes")
Login() //back to square one!
else
del src
When the Die() proc is called, players are asked if they would like to play again. If they do, they are logged in again, presumably to start over. Otherwise, they are deleted (and logged out).

==Output==

All output is generated by the << operator. This sends the specified output to one or more players.

Target << Output
The target may be a single object or a list of objects. Any non-mob target will be replaced by its contents. This allows you to send output to a region on the map or to a room, and all the players inside will receive it.

There are several different types of output. In many cases, the way the output should be handled is automatically detected from the type of data provided. Several instructions for producing various types of output are listed in the following table. In addition to these instructions are some which further clarify how the output should be treated when the type of data alone is not enough to determine this.

Figure 11.16: Output Methods

text()

file()
image()
browse()
sound()
ftp()
run()
link()
The first group of instructions produce various types of data for output or other purposes. The second group are only meaningful for directly producing output. All of these instructions are described individually in the following sections. The general format for using them is the same.

Target << Method(Output)

===text output===

A text output value is displayed in the client's scrolling terminal window. The text value may be the result of any expression. Frequently, it is a text string with embedded expressions inside it. Although it is not necessary to use the text instruction for this purpose, one reason for doing so is to use trailing rather than directly embedded expressions.

text (Text,Arg1,Arg2,...)
Text is the text string with expression markers.
Args are the expressions to insert.
Returns text with arguments substituted in.
The position in the text where a trailing argument will be inserted is marked with empty brackets [ ]. The substitution arguments are then listed in the same order as the expression markers.

For substituting short expressions into the text, it is convenient to simply embed them directly. However, many lengthy expressions embedded into a text string can make it difficult to read. In that case, trailing expressions may be the better choice. The two methods can be mixed as desired.

The following two versions of a look verb are equivalent.

mob
var/money = 2

verb/look1()
set src in view()
usr << "[src] has [contents.len] items and [money] buffalo chips."

verb/look2()
set src in view()
usr << text("[src] has [] items and [] buffalo chips.",
contents.len,
money)
Note that the text instruction is not limited to being used as an output method. It may be used anywhere you wish to use trailing expressions with a text string.

===browse output===

The browse output method displays text output in a pop-up window. This is intended for viewing longer text documents. If treated as normal terminal output instead, the user might have to scroll back up to find the top of the message.

browse (Doc, Options)
Doc is the message to display. Options are various window-specific options. Consult the reference for specifics.
By default, each message replaces any previous message being displayed but the user can move back to previous messages stored in the client's memory. In many ways, the client terminal behaves like a telnet session and the browse window behaves like a web browser. One displays output sequentially in a continuous stream. The other displays it in discrete chunks--one document after another. The two are each useful in different situations.

The document is often a text string. However, it may be a file instead. The type of file will determine how it is handled. Files may reside in the resource cache or in the file system. As always, cached items may be specified by putting the file name in single quotes. An external file, on the other hand, is indicated using the file instruction described in section 11.2.7.

The browse output method is often used in conjunction with the message input type. One allows the composition of messages and the other displays them.

The following example defines a message scroll. Players can write poetry on it in moments of inspiration.

obj/scroll/verb
write(msg as message)
desc = msg
read()
usr << browse(desc)

===sound output===

The sound output method plays a sound to the player. Either wav or midi sound files may be used, usually for short noises and music respectively. Such files are treated this way by default, but the sound instruction can be used to control how the sound is played.

sound (File,Repeat)
File is the sound file to play.
Repeat is 1 to play sound repeatedly.
A repeated sound is played in the background while other sounds are played in the foreground. Only one background sound and one foreground sound may be played at a time, so subsequent output replaces any previous sound with the same repeat setting. To stop a sound, specify null as the file.

Background music is often repeated while occasional noises play in the foreground. The following example defines a background sound for each area.

area
var/music = 'default.midi'
Enter()
. = ..()
if(.) usr << sound(music,1)
The line . = ..() is commonly used when you want to return the same value as the parent proc but you need to do something after finding out what that value is. That way, if the user is refused access to the area for some reason, the music will not be played.

===image output===

The image instruction is used to create a purely virtual object. It may appear at the specified location to selected players, but it corresponds to no real data object.

image (Icon,Loc)
Icon is the icon or object type to use.
Loc is the location of the image.
Returns a reference to the image.
If the location of the image is something movable like a mob, it will follow the object around. The image icon is displayed in a layer above everything else, so it is best suited for special effects like a selection box, burst of fire, etc.

The image instruction may be used outside the context of the output instruction. In this case it returns a reference to the image but does not actually display the image to any players. This reference can be sent as output and may be deleted later to destroy the image.

The following example allows the player to select an enemy by clicking on it. The currently selected enemy is outlined with an image.

mob/var
mob/enemy
enemy_marker

client/Click(mob/M)
if(istype(M))
del usr.enemy_marker
usr.enemy = M
usr.enemy_marker = image('outline.dmi',M)
usr << usr.enemy_marker
The code works by first deleting any old enemy marker. A new one is then made and displayed to the user. No one else will see the image--only the player who clicked on the enemy.

===ftp output===

The ftp output method sends a file to the player. This complements the file input type which allows the player to send a file to the server. The terminology normally used is that a file is uploaded when it is input and downloaded when it is output.

ftp (File,Name)
File is the file to send.
Name is the optional suggested file name.
The file to send may be either a resource file (in the cache) or a file in the file system. The difference is whether the file is specified in single or double quotes. A file in single quotes will be loaded into the resource cache at compile-time. A file in double quotes will be accessed from the file system (i.e. hard-disk) at run-time. The latter might be useful if you need to update the file periodically without recompiling.

The suggested file name defaults to the name of the file being sent. This is used as the default name when the player chooses where to store the file. If the player decides not to download the file, it is always possible to cancel at that point or during the transfer.

The following example sends a help file to players when they click on the appropriate topic.

client/Topic(T)
if(T == "help")
usr << ftp("help.txt")

mob/Login()
..()
usr << "Download the help file if you are new here."
For this to work, the file "help.txt" must exist in the current directory of the server. This can be assured by putting it in the same place as the dmb file. Since the file was specified in double quotes, it will be accessed at run-time rather than compile-time. That means you are free to edit it at a later date.

The HTML tag <A HREF...> is used to embed a hyperlink in some output text. It will be described in section 11.4.3.

===run file output===

The run output method is like ftp except it displays or executes the specified file rather than saving it to disk. The action taken depends on the type of file. For example, HTML and jpeg files might be shown in the player's web browser.

run(File)
Obviously it would be a severe security risk to players if executable files could be run without their authorization. Viruses and other malicious programs could be released onto their computer just by connecting to a game. For this reason, players are asked before executing any potentially dangerous file. That is the default behavior. The player can configure the client to always or never run files if they choose. A similar choice can be made about downloading files.

The previous example which gave the player a help file could easily be changed to instead display the file. If the player wishes, it would still be possible to save the file to disk.

client/Topic(T)
if(T == "help")
usr << run("help.txt")

===file output===

The file instruction returns a reference to a file object. It takes the file's path (in a text string) as an argument. The output methods browse, ftp, and run can all take a file reference as an argument. In the case of browse it is necessary to use file to distinguish between a text message and a file name. In the case of ftp and run it is not necessary to use file because the name of the file may simply be used directly. If no output method is specified for a file, it is implicitly handled by run.

file (Path)
Path is the name of the file.
Returns a reference to the file.
The path may be absolute or relative to the server's working directory, which is the same directory that contains the world .dmb file. Since this is evaluated at run-time, the file need not exist until the statement is actually executed. This is different from cache file references (in single quotes) which are evaluated at compile-time. For more uses of the file object, see section 17.6.

===link output===

The link output method is like run except it executes a URL rather than a file. The URL could be a web address, a BYOND address, or a topic link.

link (url)
url is the URL to execute.
The beginning of the URL specifies the communication protocol. If the URL begins with "byond://" then it is treated as a BYOND address. This is the default protocol if none is specified. A URL beginning with "#" is a topic link. Other protocols (like "http://" are handled by the player's web browser.

A BYOND link causes the player's client to reconnect to the specified address. Topic links merely cause the specified topic to be accessed in the current world (by calling client.Topic()). A web link causes the web browser to switch to the specified URL.

The general format for a BYOND address includes a server address and topic.

byond://server#topic
The topic is optional and is only used in rare cases like servers with multiple entry points. The server address may be either the name of a registered server or the network address in the form ip:port. The IP address would either be raw network numbers (e.g. 123.456.789.123) or the corresponding machine name (e.g. dantom.com). The port number is the network port on which the server is running. This is reported when the server starts up.

By default, players are asked whether they accept links activated in this manner. They can, however, configure the client to always or never accept them.

The link output method is very similar to the hyperlink text tag which has already been introduced. They both can take the same types of URLs and act upon them in the same manner. Hyperlinks embedded in text are normally used to provide access to optional information. The link output method, on the other hand, is useful when the player's action has already indicated desire to follow the link.

For example, a link from one world to another could be activated by entrance into a special turf.

turf/wormhole/Enter()
usr << link("byond://WormWorld")
return 1
This example assumes the existence of a world registered under the name "WormWorld". Running and registering a networked world will be discussed in chapter 12.

==Text Macros==

Both input and output text may contain special codes that are not displayed literally but which are replaced by some other text. These are called text macros and begin with a backslash \ and may end with a space (which is ignored). They are summarized in the following sections.

===Expression Modifiers===

Figure 11.17: Text Macros for use with Expressions

\the, \The

definite article if needed
\a, \an, \A, \An indefinite article if needed
\he, \He, \she, \She he, she, they, it
\his, \His his, her, their, its
\hers his, hers, theirs, its
\him him, her, them, it
\himself, \herself himself, herself, themself, itself
\th 1st, 2nd, 3rd, ...
\s 1 dog, 2 dogs, ...
The first group of text macros work in conjunction with an embedded expression. The article macros precede the expression and the others follow it. Any amount of text and even inapplicable expressions may exist between the macro and its associated expression.

The articles and various pronouns work with object or text expressions. The plural and ordinal macros \s and \th are used with numerical expressions. If no expression of the appropriate type is found, these macros do nothing.

An embedded object is replaced by a definite article and its name. In other words, the following two are equivalent:

"[usr] smiles."
"\The [usr] smiles."
These could produce "Andrew smiles." or "The cat smiles." depending on the name of the user.

Note that the articles may be supplied in either capitalized or lowercase form. The implicit definite article is automatically chosen in capital form if preceded by a period. If that is incorrect, you can specify the desired form explicitly.

If an indefinite article is desired instead of the default definite one, it must be explicitly specified. If no article at all is desired, the name can be embedded directly in place of the object.

The following example uses an indefinite article instead of a definite one when a mob picks up an object.

obj/verb/get()
set src in view(0)
view() << "[usr] picks up \a [src]."
Move(usr)
It doesn't matter whether you use "a" or "an" in the macro. The appropriate one will be chosen for the word that follows. It is common to use whichever one makes the code more readable.

====Proper Nouns====

There are two special text macros for controlling whether the name of an object is considered to be a proper noun or not. These are \proper and \improper. By default, if the object name is capitalized, it is assumed to be proper, and otherwise it is assumed to be improper. To override this, you can put \proper or \improper at the beginning of the object's name.

As you have seen in the preceding section, the difference between proper and improper nouns is that articles are suppressed in front of proper nouns. For example, if you had something called a "BYOND dime," you would need to use the \improper macro as follows:

obj/BD
name = "\improper BYOND dime"
mob/verb/get(obj/O in view(0))
usr << "You pick up \an [O]."
O.Move(usr)
Since we used \improper in this example, somebody picking up a BYOND dime would see, "You pick up a BYOND dime." rather than "You pick up BYOND dime."

====Numerical Expressions====

There are macros which depend upon the preceding numerical expression. The \th macro produces the ordinal ending for the supplied number. For the number 1, it produces "st" to make "1st", for the number 2, "nd" and so on. From 4 and on it produces "th", which is where it gets its name.

The \s macro produces "s" if the preceding numerical expression is not equal to 1 and nothing otherwise. This is useful for making plurals like "You have [count] coin\s.".

===Special Characters===

Figure 11.18: Special Character Macros

\"

double quote
\\ backslash
\< less than
\> greater than
\& ampersand
\n newline
\... suppress newline at end
\(space) skip a space
There are a few special characters that may not be directly entered into a text string. These must be escaped by preceding them with a backslash. This forces the special meaning to be ignored and the literal character to be inserted instead.

The double quote, for example, must be escaped or it would prematurely end the text string.

mob/verb/say(msg as text)
view() << "[usr] says, \"[msg]\""

====Newlines====

A newline may be inserted with the \n macro. The compiler does not allow direct insertion of newlines in a text string because this is often a mistake resulting from a missing end quote. You can continue a lengthy text string onto the next line by escaping the newline, but then the newline is entirely ignored.

There is an implicit newline inserted at the end of all output text. This means that instead of using the \n macro directly, the text can simply be broken up into individual lines which are output one at a time.

In some cases, you may want to suppress the implicit newline at the end of the text. This can be done with the \... macro. By putting it at the end of the text, subsequent output will start on the same line where the previous one left off.

A newline is actually an end-of-paragraph marker. It should not be used inside the paragraph to make lines fit the screen because not everyone's terminal will be the same width. It is best to let the terminal automatically handle word-wrap within paragraphs and reserve the newline for marking the end of it.

==Text Formatting Tags==

Text may be formatted by inserting HTML elements, more commonly known as tags, that control its appearance. DM understands a subset of HTML tags, consisting of the most commonly used elements.

A tag is surrounded by < > angle brackets. The first thing inside the brackets is the name of the tag. Many tags come in pairs--one to start an effect and another to end it. The end tag has the same name as the start tag except it starts with `/'. Tag names are not case sensitive.

The following example displays some text in bold.

"I am very mad!"
The start tag turns on bold lettering and turns it off. For a complete list of tags understood by DM, see page 3 in the appendix. The most commonly used ones are listed in figure 11.19 for easy reference.

Figure 11.19: Common text tags

<A></A>

anchor (for hyperlinks)
 bold
<BIG></BIG> bigger text
 line break
 font face, size, and color
 italic
 paragraph
<S></S> overstrike
 smaller text
<TT></TT> typewriter style
 underline
<PRE></PRE> preformatted whitespace
<XMP></XMP> literally preformatted text
<BEEP>

make a beeping sound

===Whitespace===

Whitespace refers to any spaces, tabs, or newlines. In standard HTML, whitespace serves merely to delimit words. The amount of space and whether it is a tab, space, or newline is irrelevant.

DM processes whitespace like standard HTML when it is inside of a pair of start and end tags. So, for example, inside of and , the paragraph markers, standard HTML rules are in effect; newlines, spaces, and tabs serve merely to delimit words. Note that an entire document could be surrounded by <HTML> and </HTML> to mark the whole thing as standard HTML.

Outside of all HTML tags, DM handles whitespace a little differently. Spaces still delimit words, but newlines (embedded with \n) mark the end of lines. In other words, the newline is automatically converted to , the linebreak tag. That is convenient for use in messages composed by players when it would be annoying to write formal HTML with paragraph tags and so forth.

===Fonts===

The tag is used to control various characteristics of the font being used. It takes additional arguments in the form of attributes.

For example, to make the font much bigger, you could use the start tag . The name of the attribute in this case is SIZE, and its value is +3, which makes the font three sizes bigger. You can put quotes around the attribute value if it contains any spaces. In this case there was no need.

The attributes of are FACE, SIZE, and COLOR. You can use as many of these attributes in one tag as you like. Just separate each attribute assignment by some space like this: <nowiki></nowiki>. The nuances of these three tags are discussed in the following individual sections.

====FACE attribute====

The FACE attribute selects the name of the font you wish to use. It may be a single font (such as InnoDBl) or a comma-separated list (such as InnoDBl,Helvetica). If the user doesn't have a font with the same name on their system, the next font will be tried. Remember to put quotes around the attribute value if it contains any spaces.

====SIZE attribute====

The SIZE attribute changes the size of the text. It can be a relative change, like +3, or an absolute size, such as 5. Font sizes are numbered from 1 to 7, with 1 being the smallest and 7 being the largest. Each increment is roughly 1.5 times the apparent size of the previous one.

====COLOR attribute====

The COLOR attribute selects the foreground color of the text. It may be either a color name or a hexadecimal RGB value.

RGB stands for red, green, and blue, the three primary colors from which all the others can be produced. Hexadecimal is a base-16 number system commonly used by programmers for specifying binary values. The hexadecimal digits are 0 to 9 and A to F, a full four bits of information. Lowercase letters may be used as well.

Each primary color is given a range of eight bits. Therefore it takes exactly two hexadecimal digits to specify a single component and six digits to specify a complete color value. The first two digits are for red; the next two are for green; and the last two are for blue (hence RGB). The color black is 000000, which has all three colors turned off. The color white is FFFFFF with all three colors at their maximum intensity.

The following two lines are identical:

"This is red."
"This is red."
Notice that a # symbol is placed in front of the numeric color value to indicate that it is a hexadecimal value. Otherwise, a color name is expected. If you can't find the color you want in the list of named colors, find the closest one and tweak the intensities to your satisfaction.

Figure 11.20: Named Colors

black

#000000
silver #C0C0C0
grey #808080
white #FFFFFF
maroon

#800000
red #FF0000
purple #800080
fuchsia #FF00FF
green

#00C000
lime #00FF00
olive #808000
yellow #FFFF00
navy

#000080
blue #0000FF
teal #008080
aqua #00FFFF
It is also possible to enter color components as 4 rather than 8 bit numbers. In that case, only three hexadecimal digits are required rather than six. Internally, the color is converted to full 8 bit notation by repeating each digit. For example, black #000 becomes #000000, white #FFF becomes #FFFFFF, and red #F00 becomes FF0000.

===Hyperlinks===

The <A> tag is used to mark a particular spot (or anchor) in the text. In DM, you use it to insert a clickable hyperlink. To specify the destination URL of a link, use the HREF attribute.

"<A HREF='#topic'> click here </A> ..."
The form of the URL is the same as the link output method described in section 11.2.8. It may be either a BYOND address, a topic link, or a web address.

The TITLE attribute may be assigned to a description of the link. It is made visible when the user holds the mouse over the link.

==Style Sheets==

HTML tags, such as may be used to directly format output text. Another approach, however, is to use HTML tags to specify purely structural information and use a style sheet to define how various elements within that structure should be treated. DM uses a subset of the Cascading Style Sheet (CSS) language, which was introduced for this purpose in HTML documents.

As an example of a style sheet, suppose one wanted combat and conversational messages to appear differently--perhaps using different colors. Instead of using the tag to color the text, you could use to mark the beginning and ending of the text and to specify what kind of message it is. The result might be text such as the following:

"[usr] spanks [targ]!"
"[usr] says, '[msg]'"
The CLASS attribute may be used with any tag, but the generic containers SPAN and DIV are often convenient because they have no other side-effect. is for text within a single paragraph and <DIV> is for whole paragraphs. The way text belonging to a particular class is formatted may be controlled in a style sheet such as the following:

This says that text in the `combat' class should be colored red and text in the `chat' class should be colored green. These classes are not pre-defined; they were just made up to suit the situation. You can invent as many new classes as you like.

In order to make this style sheet take effect you have several options. One is to put it in a text string (double quotes) and assign it to client.script. This will load the style sheet when the player connects. You could accomplish the same thing by putting the style sheet in a file and assigning the file (in single quotes) to client.script. It is also possible for a player to put the style sheet in a client-side script file and load it that way. More will be said about DM Script, which encompasses more than just style sheets, in the appendix (page [4]).

The advantage of using style sheets instead of direct formatting tags is that you can cleanly separate structural information (such as combat and conversational messages) from formatting information (such as red and green text). By separating the two, you or the player can easily plug in different formatting schemes without changing any of the actual content.

A style sheet is composed of a list of rules, such as the two rules in the preceding example. Each rule contains one or more selectors followed by a body of attribute assignments (in braces). The selector specifies the context of the rule and the body specifies the format.

===Context Selectors===

A selector may specify a container tag (such as SPAN, BODY, or P) and a class. The above example could have been written with a selector of SPAN.chat. However, by leaving out the tag, it applies to any tag with CLASS=chat. It is also possible to only specify the tag and not the class. In that case, the selector applies to any matching tag, regardless of its class.

To specify a nested context, several simple selectors may be listed one after the other. For example, emphasized text within a combat message could be enlarged with the following rule:

.combat EM {font-size: larger}
It is also possible to list several selectors separated by commas in order to make them all apply to the same body. For example, this next rule is equivalent to the two following ones:

.combat EM, .chat EM {font-size: larger}

.combat EM {font-size: larger}
.chat EM {font-size: larger}

===Style Attributes===

The body of a style rule contains a list of attribute assignments, delimited by semicolons. Each assignment takes the form of an attribute name, followed by a colon, followed by the value of the attribute. Figure 11.21 summarizes the recognized attributes and sample values.

Figure 11.21: Style Attributes

color

#F00, #FF000, red
background same as color
font-size 10pt, 1.5em, 150%
font-style normal or italic
font-weight normal, bold, lighter, darker, or 100 to 900
font-family monospace, sans-serif, serif, cursive, ...
font style weight size family
text-decoration none or underline
text-align left, right, or center
width 16px, 32px, auto
height 16px, 32px, auto

===Fonts===

The font family may be a specific font name or a more general category such as monospace or sans-serif. Since not all users necessarily have the same fonts installed, it is a good idea to list alternate fonts. The desired font is placed first, followed by other possible fall-backs, each separated by a comma. Usually a general family such as monospace is listed last of all. Any font names containing a space should be enclosed in quotes.

The font attribute is a special short-hand for assigning font-size, font-style, font-weight, and font-family in one statement. Any properties that are not specified in the font statement are assigned to their default values.

The following example sets the font for the <BODY> tag. Even if you don't explicitly use <BODY> in output text, it is applied implicitly.

BODY {font: 12pt 'Times New Roman', sans-serif}
This sets the font to 12 point and selects Times New Roman if it is available and otherwise falls back on a system-determined sans-serif font. This command also implicitly specifies not to use italics and normal font weight (not bold).

Font sizes may be specified in points (1pt = 1/72 of an inch), picas (1pc = 12pt), pixels (px), inches (in), centimeters (cm), and millimeters (mm). There are also various levels corresponding to the traditional 1 to 7 HTML scale. These are xx-small, x-small, small, medium, large, x-large, and xx-large. In addition to these absolute font sizes, it is possible to use a relative size, such as 150% or equivalently 1.5em. This scales the font relative to the currently active font setting.

===Hyperlink Pseudo-Classes===

In addition to regular stylistic classes, there are special pseudo-classes for handling embedded hyperlinks. These are specified in the selector with the class starting with a colon rather than a dot. They are :link, :visited, and :active. These only apply to the <A> tag. The :link class applies to hyperlinks in their normal state. Once a link has been clicked, it belongs instead to the :visited class. When the user holds the mouse over a link, it temporarily belongs to the :active class. The only attribute that may change in an active or visited link is the text color.

===Canvas Background Color===

The background attribute is only relevant to the <BODY> context. It causes the entire terminal background to change color. When doing this, it is usually necessary to change the foreground colors of text or it may become unreadable. The various standard classes of output generated by Dream Seeker are presented in figure 11.22.

Figure 11.22: System Colors

system notice

general notices from the client
system command echo command echoing
system command expansion command-line expansion list
system pager pager messages
system irc IRC command prefix
The value of the CLASS attribute may contain a list of classes separated by spaces. This permits client output to be in the `system' class as well as more specific ones. That allows you to change all of these colors in one shot if you are too lazy to change them each individually. For example, if you define a style sheet that changes the background color, you might need to redefine the various foreground colors like this:

BODY {background: aqua; color: black}
.system {color: red; font-weight: bold}
.command {color: green}
In this example, the background color of the terminal will be aqua, normal text from the server will be black, and all output from the client will be bold and red, except echoed commands and expansion lists, which will be bold and green. The more specific .command rule is placed after the general .system rule so that its color takes precedence. This is how style sheets are composed--you write general rules first followed by any exceptions.

===Style Rule Precedence===

The order in which rules are specified is one of the factors that determines precedence of style sheet commands. The language is known as Cascading Style Sheets because of its ability to handle several layers of stylistic rules, intermingling the configurations of the user and the designer in an ordered fashion.

Rules are selected by first finding all matching candidates for a given attribute in the current HTML tag being processed. If there is more than one, rules from a higher level style sheet take precedence over lower level ones. That means the basic user configurable settings in Dream Seeker are the lowest priority, followed by a style sheet in the user's .dms script file, followed by a style sheet from the designer's client.script setting, because that is the order in which these are read by the style sheet manager.

Rules from the same style sheet are ordered by specificity. The selector SPAN.chat is more specific than .chat and .chat EM is more specific than EM. In general, the more classes referenced by a selector, the more specific it is. When that results in a tie, the selector with the greater number of tags takes precedence.

Finally, if two rules about the same attribute come from the same sheet and have the same specificity, the final one to be defined takes precedence.

In the rare event that a rule needs to break out of the normal order of precedence, it can be flagged as important. In this case it will take precedence over all other "unimportant" rules. However, if more than one rule is important, the normal rules of precedence will be used to resolve the conflict.

The important flag is applied after the attribute assignment like this:

BODY.background {
background: white ! important;
font: serif
}
In the above example, only the background color is important, not the font specification.

===The STYLE attribute===

Style commands may also be inserted directly in an HTML tag to control its appearance. This does not have the advantages of independent style sheets, which separate content from presentation, but it does allow you to use the style sheet syntax when formatting text.

The following example uses the style attribute to color some text:

usr << "That HURT!"
As you can see, the STYLE attribute of any tag can be assigned to a text string containing a list of attribute assignments. Just the body of the style rule is given, since no selector is needed to match the current context.

==Inline Icons==

The \icon text macro causes the following embedded expression to be interpreted as an icon rather than as text. For example, an object would be replaced by its icon rather than by its name.

The following example prefixes conversational text with the speaker's icon, making it easier to associate the message with the appropriate object on the map.

mob/verb/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"
The \icon text macro expands internally to an <IMG> tag. The previous example, could be rewritten as follows:

mob/verb/say(Msg as text)
view() << " \
[usr] says, '[Msg]'"
From this, you can see that the object's current icon state is used. A reference to the icon itself is inserted using the \ref text macro, which generates a unique identifier corresponding to an object.

A final noteworthy point is that the image belongs to a style class called `icon'. This can be used to configure global properties of icons in the text terminal. For example, a full 32x32 pixel icon doesn't always fit in with surrounding text very well. A single style sheet rule takes care of that:

IMG.icon {height: 16px; width: 16px}
This is, in fact, a built-in default rule, so you don't have to define it yourself. You could override it to get full 32x32 icons. You could even define special rules to allow icons in certain contexts to be different sizes. The <BIG> and tags are ideal:

BIG IMG.icon {height: 32px; width: 32px}
SMALL IMG.icon {height: 16px; width: 16px}
Using the <BIG> tag, you could then output a full-sized icon, even though the default is small. The following example does that when the DM speaks in order to satisfy an inflated ego.

mob/DM/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"

==Special Effects==

There are a couple miscellaneous commands which create special output effects. Like the image instruction, they produce a purely visual result.

===missile instruction===

The missile instruction creates an image which moves from one location to another. It is often used as a symbolic indicator of the source and target of a projectile.

missile (Icon,Start,End)
Icon is the image icon or object type.
Start is the missile source.
End is the missile destination.
This could be used in a game of darts:

obj/dart
verb/throw(mob/M)
missile(src,usr,M)
del src
If more realism is desired, a check could be made first to determine if there is a straight unobstructed path between the attacker and target. (However, realism (in my opinion) is much overrated. Don't let it spoil a good piece of code unless you really have to. I am sure there are many cases in which our own universe too is unrealistic because God couldn't resist a simpler way of implementing things here and there. The sky is a perfect example. I mean, it looks a bit fake sometimes, doesn't it?)

===flick instruction===

The flick instruction causes a temporary transition in the icon state of an object. It lasts until all the frames in that particular state have been played and then reverts to the true icon state.

flick (State,Obj)
State is the icon or icon state to display.
Obj is the target object.
Note that it is possible to specify an entirely different icon file. Normally, however, just the state of the existing icon file is specified.

The flick instruction is often used for temporary animation sequences (like smiling, writhing in pain, etc.). These are different from changes of state which have a longer duration (like sleeping, flying, etc.). In those cases, one would simply assign the icon_state variable directly.

Sometimes, however, a flick is used in the transition between two permanent states. The following example defines a door turf which does exactly that.

turf/door
icon = 'door.dmi'
icon_state = "closed"
density = 1
opacity = 1
verb/open()
set src in view(1)
if(!density) return //already open
density = 0
opacity = 0
flick("opening",src)
icon_state = "open"
verb/close()
set src in view(1)
if(density) return //already closed
density = 1
opacity = 1
flick("closing",src)
icon_state = "closed"
The advantage of using icon states in this way is that the code remains very general. All the map designer has to do is plug in different icons with the same states and a variety of doors can be made from the one basic definition.

If the icon state specified by the flick instruction does not exist, it has no effect. In the above code, for example, a door icon could be used that did not have "opening" and "closing" states defined. Everything would work--only the transition would not be animated.

DM Guide 11

2015-11-14T20:30:10Z

IXVI: /* Глава 11 */

''Это 11 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap11.html Оригинальная 11 глава руководства на английском языке]

{{Заготовка|url=http://www.byond.com/docs/guide/chap11.html}}

=Глава 11=

Ввод\вывод Пользователя 

Взаимодействие с пользователем - это главная цель любых программ в Dream Maker и эта глава описывает основы языка, отвечающего за ввод и вывод информации.


==Ввод==

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


===Verbs===

До сих пор весь ввод был со стороны пользователя. Игрок может написать команду, нажать кнопку управления, щёлкнуть на объект и т.д. Эти виды ввода информации однородны, так как ими управляют одинаковые операторы(verbs). То есть нажатие на кнопку влево вызывает определённый процесс и задаёт ему значение "кнопка влево".


Есть несколько заранее определённых операторов(verbs), принимающих ввод информации от игрока. Это кнопки направления\стрелки (напр. client.North()), щелчок мыши ((client.Click() и client.DblClick()) и ссылки топиков (client.Topic()). Все остальные операторы(verbs) задаются программистом.


Общий вид для определения оператора(verb) следующий:
: verb/Name(Arg1 = default input-type in List,...)

Количество аргументов может быть любым. Каждый из них может иметь значение по умолчанию, тип ввода и список допустимых значений.


===Инструкция ввода===

Инструкция ввода - это то, что позволяет вам(со стороны игры) запросить у игрока информацию ввода. На ней построены все взаимоотношения сервера с клиентом. Она похожа на простой одиночный оператор(verb).


: >input(User=usr,Message,Title,Default) input (User,Query,Title,Default) as input-type in List

User - это имя игрока(моба).
Query - текст запроса ввода.
Title - текст отображения запроса ввода.
Default - значение по умолчанию для данного запроса.
input-type - тип ввода информации.
List - список возможных значений для данного запроса.
Исполнение данного оператора задаёт значение введённое игроком. 

Всё, кроме текста ввода - необязательные опциональные параметры. User ассоциируется с usr, и обращается к нему.
Если input type не задано, то тип ввода информации будет текстовым по умолчанию.


Обратите внимание, что инструкция ввода не будет запрошена, пока пользователь не введёт значение. При поддержки многопользовательской системы ожидать ответа от одного пользователя невозможно, поэтому при запросе ввода информации в режим ожидания входит только текущая исполняемая процедура.


One case in which the input instruction proves useful is when something happens in the game that the player needs to respond to. A verb would be too open-ended for the task, making it difficult for the player to guess what to do next.

The following code, for example, handles a rather sad event in the life of a player.

mob/proc/Die()
if(!key) //NPC
del src
else //PC
loc = null //vacate the scene
var/again = input("Play Again?") in list("yes","no")
if(again == "yes")
Login() //back to square one!
else
del src
When the Die() proc is called, players are asked if they would like to play again. If they do, they are logged in again, presumably to start over. Otherwise, they are deleted (and logged out).

==Output==

All output is generated by the << operator. This sends the specified output to one or more players.

Target << Output
The target may be a single object or a list of objects. Any non-mob target will be replaced by its contents. This allows you to send output to a region on the map or to a room, and all the players inside will receive it.

There are several different types of output. In many cases, the way the output should be handled is automatically detected from the type of data provided. Several instructions for producing various types of output are listed in the following table. In addition to these instructions are some which further clarify how the output should be treated when the type of data alone is not enough to determine this.

Figure 11.16: Output Methods

text()

file()
image()
browse()
sound()
ftp()
run()
link()
The first group of instructions produce various types of data for output or other purposes. The second group are only meaningful for directly producing output. All of these instructions are described individually in the following sections. The general format for using them is the same.

Target << Method(Output)

===text output===

A text output value is displayed in the client's scrolling terminal window. The text value may be the result of any expression. Frequently, it is a text string with embedded expressions inside it. Although it is not necessary to use the text instruction for this purpose, one reason for doing so is to use trailing rather than directly embedded expressions.

text (Text,Arg1,Arg2,...)
Text is the text string with expression markers.
Args are the expressions to insert.
Returns text with arguments substituted in.
The position in the text where a trailing argument will be inserted is marked with empty brackets [ ]. The substitution arguments are then listed in the same order as the expression markers.

For substituting short expressions into the text, it is convenient to simply embed them directly. However, many lengthy expressions embedded into a text string can make it difficult to read. In that case, trailing expressions may be the better choice. The two methods can be mixed as desired.

The following two versions of a look verb are equivalent.

mob
var/money = 2

verb/look1()
set src in view()
usr << "[src] has [contents.len] items and [money] buffalo chips."

verb/look2()
set src in view()
usr << text("[src] has [] items and [] buffalo chips.",
contents.len,
money)
Note that the text instruction is not limited to being used as an output method. It may be used anywhere you wish to use trailing expressions with a text string.

===browse output===

The browse output method displays text output in a pop-up window. This is intended for viewing longer text documents. If treated as normal terminal output instead, the user might have to scroll back up to find the top of the message.

browse (Doc, Options)
Doc is the message to display. Options are various window-specific options. Consult the reference for specifics.
By default, each message replaces any previous message being displayed but the user can move back to previous messages stored in the client's memory. In many ways, the client terminal behaves like a telnet session and the browse window behaves like a web browser. One displays output sequentially in a continuous stream. The other displays it in discrete chunks--one document after another. The two are each useful in different situations.

The document is often a text string. However, it may be a file instead. The type of file will determine how it is handled. Files may reside in the resource cache or in the file system. As always, cached items may be specified by putting the file name in single quotes. An external file, on the other hand, is indicated using the file instruction described in section 11.2.7.

The browse output method is often used in conjunction with the message input type. One allows the composition of messages and the other displays them.

The following example defines a message scroll. Players can write poetry on it in moments of inspiration.

obj/scroll/verb
write(msg as message)
desc = msg
read()
usr << browse(desc)

===sound output===

The sound output method plays a sound to the player. Either wav or midi sound files may be used, usually for short noises and music respectively. Such files are treated this way by default, but the sound instruction can be used to control how the sound is played.

sound (File,Repeat)
File is the sound file to play.
Repeat is 1 to play sound repeatedly.
A repeated sound is played in the background while other sounds are played in the foreground. Only one background sound and one foreground sound may be played at a time, so subsequent output replaces any previous sound with the same repeat setting. To stop a sound, specify null as the file.

Background music is often repeated while occasional noises play in the foreground. The following example defines a background sound for each area.

area
var/music = 'default.midi'
Enter()
. = ..()
if(.) usr << sound(music,1)
The line . = ..() is commonly used when you want to return the same value as the parent proc but you need to do something after finding out what that value is. That way, if the user is refused access to the area for some reason, the music will not be played.

===image output===

The image instruction is used to create a purely virtual object. It may appear at the specified location to selected players, but it corresponds to no real data object.

image (Icon,Loc)
Icon is the icon or object type to use.
Loc is the location of the image.
Returns a reference to the image.
If the location of the image is something movable like a mob, it will follow the object around. The image icon is displayed in a layer above everything else, so it is best suited for special effects like a selection box, burst of fire, etc.

The image instruction may be used outside the context of the output instruction. In this case it returns a reference to the image but does not actually display the image to any players. This reference can be sent as output and may be deleted later to destroy the image.

The following example allows the player to select an enemy by clicking on it. The currently selected enemy is outlined with an image.

mob/var
mob/enemy
enemy_marker

client/Click(mob/M)
if(istype(M))
del usr.enemy_marker
usr.enemy = M
usr.enemy_marker = image('outline.dmi',M)
usr << usr.enemy_marker
The code works by first deleting any old enemy marker. A new one is then made and displayed to the user. No one else will see the image--only the player who clicked on the enemy.

===ftp output===

The ftp output method sends a file to the player. This complements the file input type which allows the player to send a file to the server. The terminology normally used is that a file is uploaded when it is input and downloaded when it is output.

ftp (File,Name)
File is the file to send.
Name is the optional suggested file name.
The file to send may be either a resource file (in the cache) or a file in the file system. The difference is whether the file is specified in single or double quotes. A file in single quotes will be loaded into the resource cache at compile-time. A file in double quotes will be accessed from the file system (i.e. hard-disk) at run-time. The latter might be useful if you need to update the file periodically without recompiling.

The suggested file name defaults to the name of the file being sent. This is used as the default name when the player chooses where to store the file. If the player decides not to download the file, it is always possible to cancel at that point or during the transfer.

The following example sends a help file to players when they click on the appropriate topic.

client/Topic(T)
if(T == "help")
usr << ftp("help.txt")

mob/Login()
..()
usr << "Download the help file if you are new here."
For this to work, the file "help.txt" must exist in the current directory of the server. This can be assured by putting it in the same place as the dmb file. Since the file was specified in double quotes, it will be accessed at run-time rather than compile-time. That means you are free to edit it at a later date.

The HTML tag <A HREF...> is used to embed a hyperlink in some output text. It will be described in section 11.4.3.

===run file output===

The run output method is like ftp except it displays or executes the specified file rather than saving it to disk. The action taken depends on the type of file. For example, HTML and jpeg files might be shown in the player's web browser.

run(File)
Obviously it would be a severe security risk to players if executable files could be run without their authorization. Viruses and other malicious programs could be released onto their computer just by connecting to a game. For this reason, players are asked before executing any potentially dangerous file. That is the default behavior. The player can configure the client to always or never run files if they choose. A similar choice can be made about downloading files.

The previous example which gave the player a help file could easily be changed to instead display the file. If the player wishes, it would still be possible to save the file to disk.

client/Topic(T)
if(T == "help")
usr << run("help.txt")

===file output===

The file instruction returns a reference to a file object. It takes the file's path (in a text string) as an argument. The output methods browse, ftp, and run can all take a file reference as an argument. In the case of browse it is necessary to use file to distinguish between a text message and a file name. In the case of ftp and run it is not necessary to use file because the name of the file may simply be used directly. If no output method is specified for a file, it is implicitly handled by run.

file (Path)
Path is the name of the file.
Returns a reference to the file.
The path may be absolute or relative to the server's working directory, which is the same directory that contains the world .dmb file. Since this is evaluated at run-time, the file need not exist until the statement is actually executed. This is different from cache file references (in single quotes) which are evaluated at compile-time. For more uses of the file object, see section 17.6.

===link output===

The link output method is like run except it executes a URL rather than a file. The URL could be a web address, a BYOND address, or a topic link.

link (url)
url is the URL to execute.
The beginning of the URL specifies the communication protocol. If the URL begins with "byond://" then it is treated as a BYOND address. This is the default protocol if none is specified. A URL beginning with "#" is a topic link. Other protocols (like "http://" are handled by the player's web browser.

A BYOND link causes the player's client to reconnect to the specified address. Topic links merely cause the specified topic to be accessed in the current world (by calling client.Topic()). A web link causes the web browser to switch to the specified URL.

The general format for a BYOND address includes a server address and topic.

byond://server#topic
The topic is optional and is only used in rare cases like servers with multiple entry points. The server address may be either the name of a registered server or the network address in the form ip:port. The IP address would either be raw network numbers (e.g. 123.456.789.123) or the corresponding machine name (e.g. dantom.com). The port number is the network port on which the server is running. This is reported when the server starts up.

By default, players are asked whether they accept links activated in this manner. They can, however, configure the client to always or never accept them.

The link output method is very similar to the hyperlink text tag which has already been introduced. They both can take the same types of URLs and act upon them in the same manner. Hyperlinks embedded in text are normally used to provide access to optional information. The link output method, on the other hand, is useful when the player's action has already indicated desire to follow the link.

For example, a link from one world to another could be activated by entrance into a special turf.

turf/wormhole/Enter()
usr << link("byond://WormWorld")
return 1
This example assumes the existence of a world registered under the name "WormWorld". Running and registering a networked world will be discussed in chapter 12.

==Text Macros==

Both input and output text may contain special codes that are not displayed literally but which are replaced by some other text. These are called text macros and begin with a backslash \ and may end with a space (which is ignored). They are summarized in the following sections.

===Expression Modifiers===

Figure 11.17: Text Macros for use with Expressions

\the, \The

definite article if needed
\a, \an, \A, \An indefinite article if needed
\he, \He, \she, \She he, she, they, it
\his, \His his, her, their, its
\hers his, hers, theirs, its
\him him, her, them, it
\himself, \herself himself, herself, themself, itself
\th 1st, 2nd, 3rd, ...
\s 1 dog, 2 dogs, ...
The first group of text macros work in conjunction with an embedded expression. The article macros precede the expression and the others follow it. Any amount of text and even inapplicable expressions may exist between the macro and its associated expression.

The articles and various pronouns work with object or text expressions. The plural and ordinal macros \s and \th are used with numerical expressions. If no expression of the appropriate type is found, these macros do nothing.

An embedded object is replaced by a definite article and its name. In other words, the following two are equivalent:

"[usr] smiles."
"\The [usr] smiles."
These could produce "Andrew smiles." or "The cat smiles." depending on the name of the user.

Note that the articles may be supplied in either capitalized or lowercase form. The implicit definite article is automatically chosen in capital form if preceded by a period. If that is incorrect, you can specify the desired form explicitly.

If an indefinite article is desired instead of the default definite one, it must be explicitly specified. If no article at all is desired, the name can be embedded directly in place of the object.

The following example uses an indefinite article instead of a definite one when a mob picks up an object.

obj/verb/get()
set src in view(0)
view() << "[usr] picks up \a [src]."
Move(usr)
It doesn't matter whether you use "a" or "an" in the macro. The appropriate one will be chosen for the word that follows. It is common to use whichever one makes the code more readable.

====Proper Nouns====

There are two special text macros for controlling whether the name of an object is considered to be a proper noun or not. These are \proper and \improper. By default, if the object name is capitalized, it is assumed to be proper, and otherwise it is assumed to be improper. To override this, you can put \proper or \improper at the beginning of the object's name.

As you have seen in the preceding section, the difference between proper and improper nouns is that articles are suppressed in front of proper nouns. For example, if you had something called a "BYOND dime," you would need to use the \improper macro as follows:

obj/BD
name = "\improper BYOND dime"
mob/verb/get(obj/O in view(0))
usr << "You pick up \an [O]."
O.Move(usr)
Since we used \improper in this example, somebody picking up a BYOND dime would see, "You pick up a BYOND dime." rather than "You pick up BYOND dime."

====Numerical Expressions====

There are macros which depend upon the preceding numerical expression. The \th macro produces the ordinal ending for the supplied number. For the number 1, it produces "st" to make "1st", for the number 2, "nd" and so on. From 4 and on it produces "th", which is where it gets its name.

The \s macro produces "s" if the preceding numerical expression is not equal to 1 and nothing otherwise. This is useful for making plurals like "You have [count] coin\s.".

===Special Characters===

Figure 11.18: Special Character Macros

\"

double quote
\\ backslash
\< less than
\> greater than
\& ampersand
\n newline
\... suppress newline at end
\(space) skip a space
There are a few special characters that may not be directly entered into a text string. These must be escaped by preceding them with a backslash. This forces the special meaning to be ignored and the literal character to be inserted instead.

The double quote, for example, must be escaped or it would prematurely end the text string.

mob/verb/say(msg as text)
view() << "[usr] says, \"[msg]\""

====Newlines====

A newline may be inserted with the \n macro. The compiler does not allow direct insertion of newlines in a text string because this is often a mistake resulting from a missing end quote. You can continue a lengthy text string onto the next line by escaping the newline, but then the newline is entirely ignored.

There is an implicit newline inserted at the end of all output text. This means that instead of using the \n macro directly, the text can simply be broken up into individual lines which are output one at a time.

In some cases, you may want to suppress the implicit newline at the end of the text. This can be done with the \... macro. By putting it at the end of the text, subsequent output will start on the same line where the previous one left off.

A newline is actually an end-of-paragraph marker. It should not be used inside the paragraph to make lines fit the screen because not everyone's terminal will be the same width. It is best to let the terminal automatically handle word-wrap within paragraphs and reserve the newline for marking the end of it.

==Text Formatting Tags==

Text may be formatted by inserting HTML elements, more commonly known as tags, that control its appearance. DM understands a subset of HTML tags, consisting of the most commonly used elements.

A tag is surrounded by < > angle brackets. The first thing inside the brackets is the name of the tag. Many tags come in pairs--one to start an effect and another to end it. The end tag has the same name as the start tag except it starts with `/'. Tag names are not case sensitive.

The following example displays some text in bold.

"I am very mad!"
The start tag turns on bold lettering and turns it off. For a complete list of tags understood by DM, see page 3 in the appendix. The most commonly used ones are listed in figure 11.19 for easy reference.

Figure 11.19: Common text tags

<A></A>

anchor (for hyperlinks)
 bold
<BIG></BIG> bigger text
 line break
 font face, size, and color
 italic
 paragraph
<S></S> overstrike
 smaller text
<TT></TT> typewriter style
 underline
<PRE></PRE> preformatted whitespace
<XMP></XMP> literally preformatted text
<BEEP>

make a beeping sound

===Whitespace===

Whitespace refers to any spaces, tabs, or newlines. In standard HTML, whitespace serves merely to delimit words. The amount of space and whether it is a tab, space, or newline is irrelevant.

DM processes whitespace like standard HTML when it is inside of a pair of start and end tags. So, for example, inside of and , the paragraph markers, standard HTML rules are in effect; newlines, spaces, and tabs serve merely to delimit words. Note that an entire document could be surrounded by <HTML> and </HTML> to mark the whole thing as standard HTML.

Outside of all HTML tags, DM handles whitespace a little differently. Spaces still delimit words, but newlines (embedded with \n) mark the end of lines. In other words, the newline is automatically converted to , the linebreak tag. That is convenient for use in messages composed by players when it would be annoying to write formal HTML with paragraph tags and so forth.

===Fonts===

The tag is used to control various characteristics of the font being used. It takes additional arguments in the form of attributes.

For example, to make the font much bigger, you could use the start tag . The name of the attribute in this case is SIZE, and its value is +3, which makes the font three sizes bigger. You can put quotes around the attribute value if it contains any spaces. In this case there was no need.

The attributes of are FACE, SIZE, and COLOR. You can use as many of these attributes in one tag as you like. Just separate each attribute assignment by some space like this: <nowiki></nowiki>. The nuances of these three tags are discussed in the following individual sections.

====FACE attribute====

The FACE attribute selects the name of the font you wish to use. It may be a single font (such as InnoDBl) or a comma-separated list (such as InnoDBl,Helvetica). If the user doesn't have a font with the same name on their system, the next font will be tried. Remember to put quotes around the attribute value if it contains any spaces.

====SIZE attribute====

The SIZE attribute changes the size of the text. It can be a relative change, like +3, or an absolute size, such as 5. Font sizes are numbered from 1 to 7, with 1 being the smallest and 7 being the largest. Each increment is roughly 1.5 times the apparent size of the previous one.

====COLOR attribute====

The COLOR attribute selects the foreground color of the text. It may be either a color name or a hexadecimal RGB value.

RGB stands for red, green, and blue, the three primary colors from which all the others can be produced. Hexadecimal is a base-16 number system commonly used by programmers for specifying binary values. The hexadecimal digits are 0 to 9 and A to F, a full four bits of information. Lowercase letters may be used as well.

Each primary color is given a range of eight bits. Therefore it takes exactly two hexadecimal digits to specify a single component and six digits to specify a complete color value. The first two digits are for red; the next two are for green; and the last two are for blue (hence RGB). The color black is 000000, which has all three colors turned off. The color white is FFFFFF with all three colors at their maximum intensity.

The following two lines are identical:

"This is red."
"This is red."
Notice that a # symbol is placed in front of the numeric color value to indicate that it is a hexadecimal value. Otherwise, a color name is expected. If you can't find the color you want in the list of named colors, find the closest one and tweak the intensities to your satisfaction.

Figure 11.20: Named Colors

black

#000000
silver #C0C0C0
grey #808080
white #FFFFFF
maroon

#800000
red #FF0000
purple #800080
fuchsia #FF00FF
green

#00C000
lime #00FF00
olive #808000
yellow #FFFF00
navy

#000080
blue #0000FF
teal #008080
aqua #00FFFF
It is also possible to enter color components as 4 rather than 8 bit numbers. In that case, only three hexadecimal digits are required rather than six. Internally, the color is converted to full 8 bit notation by repeating each digit. For example, black #000 becomes #000000, white #FFF becomes #FFFFFF, and red #F00 becomes FF0000.

===Hyperlinks===

The <A> tag is used to mark a particular spot (or anchor) in the text. In DM, you use it to insert a clickable hyperlink. To specify the destination URL of a link, use the HREF attribute.

"<A HREF='#topic'> click here </A> ..."
The form of the URL is the same as the link output method described in section 11.2.8. It may be either a BYOND address, a topic link, or a web address.

The TITLE attribute may be assigned to a description of the link. It is made visible when the user holds the mouse over the link.

==Style Sheets==

HTML tags, such as may be used to directly format output text. Another approach, however, is to use HTML tags to specify purely structural information and use a style sheet to define how various elements within that structure should be treated. DM uses a subset of the Cascading Style Sheet (CSS) language, which was introduced for this purpose in HTML documents.

As an example of a style sheet, suppose one wanted combat and conversational messages to appear differently--perhaps using different colors. Instead of using the tag to color the text, you could use to mark the beginning and ending of the text and to specify what kind of message it is. The result might be text such as the following:

"[usr] spanks [targ]!"
"[usr] says, '[msg]'"
The CLASS attribute may be used with any tag, but the generic containers SPAN and DIV are often convenient because they have no other side-effect. is for text within a single paragraph and <DIV> is for whole paragraphs. The way text belonging to a particular class is formatted may be controlled in a style sheet such as the following:

This says that text in the `combat' class should be colored red and text in the `chat' class should be colored green. These classes are not pre-defined; they were just made up to suit the situation. You can invent as many new classes as you like.

In order to make this style sheet take effect you have several options. One is to put it in a text string (double quotes) and assign it to client.script. This will load the style sheet when the player connects. You could accomplish the same thing by putting the style sheet in a file and assigning the file (in single quotes) to client.script. It is also possible for a player to put the style sheet in a client-side script file and load it that way. More will be said about DM Script, which encompasses more than just style sheets, in the appendix (page [4]).

The advantage of using style sheets instead of direct formatting tags is that you can cleanly separate structural information (such as combat and conversational messages) from formatting information (such as red and green text). By separating the two, you or the player can easily plug in different formatting schemes without changing any of the actual content.

A style sheet is composed of a list of rules, such as the two rules in the preceding example. Each rule contains one or more selectors followed by a body of attribute assignments (in braces). The selector specifies the context of the rule and the body specifies the format.

===Context Selectors===

A selector may specify a container tag (such as SPAN, BODY, or P) and a class. The above example could have been written with a selector of SPAN.chat. However, by leaving out the tag, it applies to any tag with CLASS=chat. It is also possible to only specify the tag and not the class. In that case, the selector applies to any matching tag, regardless of its class.

To specify a nested context, several simple selectors may be listed one after the other. For example, emphasized text within a combat message could be enlarged with the following rule:

.combat EM {font-size: larger}
It is also possible to list several selectors separated by commas in order to make them all apply to the same body. For example, this next rule is equivalent to the two following ones:

.combat EM, .chat EM {font-size: larger}

.combat EM {font-size: larger}
.chat EM {font-size: larger}

===Style Attributes===

The body of a style rule contains a list of attribute assignments, delimited by semicolons. Each assignment takes the form of an attribute name, followed by a colon, followed by the value of the attribute. Figure 11.21 summarizes the recognized attributes and sample values.

Figure 11.21: Style Attributes

color

#F00, #FF000, red
background same as color
font-size 10pt, 1.5em, 150%
font-style normal or italic
font-weight normal, bold, lighter, darker, or 100 to 900
font-family monospace, sans-serif, serif, cursive, ...
font style weight size family
text-decoration none or underline
text-align left, right, or center
width 16px, 32px, auto
height 16px, 32px, auto

===Fonts===

The font family may be a specific font name or a more general category such as monospace or sans-serif. Since not all users necessarily have the same fonts installed, it is a good idea to list alternate fonts. The desired font is placed first, followed by other possible fall-backs, each separated by a comma. Usually a general family such as monospace is listed last of all. Any font names containing a space should be enclosed in quotes.

The font attribute is a special short-hand for assigning font-size, font-style, font-weight, and font-family in one statement. Any properties that are not specified in the font statement are assigned to their default values.

The following example sets the font for the <BODY> tag. Even if you don't explicitly use <BODY> in output text, it is applied implicitly.

BODY {font: 12pt 'Times New Roman', sans-serif}
This sets the font to 12 point and selects Times New Roman if it is available and otherwise falls back on a system-determined sans-serif font. This command also implicitly specifies not to use italics and normal font weight (not bold).

Font sizes may be specified in points (1pt = 1/72 of an inch), picas (1pc = 12pt), pixels (px), inches (in), centimeters (cm), and millimeters (mm). There are also various levels corresponding to the traditional 1 to 7 HTML scale. These are xx-small, x-small, small, medium, large, x-large, and xx-large. In addition to these absolute font sizes, it is possible to use a relative size, such as 150% or equivalently 1.5em. This scales the font relative to the currently active font setting.

===Hyperlink Pseudo-Classes===

In addition to regular stylistic classes, there are special pseudo-classes for handling embedded hyperlinks. These are specified in the selector with the class starting with a colon rather than a dot. They are :link, :visited, and :active. These only apply to the <A> tag. The :link class applies to hyperlinks in their normal state. Once a link has been clicked, it belongs instead to the :visited class. When the user holds the mouse over a link, it temporarily belongs to the :active class. The only attribute that may change in an active or visited link is the text color.

===Canvas Background Color===

The background attribute is only relevant to the <BODY> context. It causes the entire terminal background to change color. When doing this, it is usually necessary to change the foreground colors of text or it may become unreadable. The various standard classes of output generated by Dream Seeker are presented in figure 11.22.

Figure 11.22: System Colors

system notice

general notices from the client
system command echo command echoing
system command expansion command-line expansion list
system pager pager messages
system irc IRC command prefix
The value of the CLASS attribute may contain a list of classes separated by spaces. This permits client output to be in the `system' class as well as more specific ones. That allows you to change all of these colors in one shot if you are too lazy to change them each individually. For example, if you define a style sheet that changes the background color, you might need to redefine the various foreground colors like this:

BODY {background: aqua; color: black}
.system {color: red; font-weight: bold}
.command {color: green}
In this example, the background color of the terminal will be aqua, normal text from the server will be black, and all output from the client will be bold and red, except echoed commands and expansion lists, which will be bold and green. The more specific .command rule is placed after the general .system rule so that its color takes precedence. This is how style sheets are composed--you write general rules first followed by any exceptions.

===Style Rule Precedence===

The order in which rules are specified is one of the factors that determines precedence of style sheet commands. The language is known as Cascading Style Sheets because of its ability to handle several layers of stylistic rules, intermingling the configurations of the user and the designer in an ordered fashion.

Rules are selected by first finding all matching candidates for a given attribute in the current HTML tag being processed. If there is more than one, rules from a higher level style sheet take precedence over lower level ones. That means the basic user configurable settings in Dream Seeker are the lowest priority, followed by a style sheet in the user's .dms script file, followed by a style sheet from the designer's client.script setting, because that is the order in which these are read by the style sheet manager.

Rules from the same style sheet are ordered by specificity. The selector SPAN.chat is more specific than .chat and .chat EM is more specific than EM. In general, the more classes referenced by a selector, the more specific it is. When that results in a tie, the selector with the greater number of tags takes precedence.

Finally, if two rules about the same attribute come from the same sheet and have the same specificity, the final one to be defined takes precedence.

In the rare event that a rule needs to break out of the normal order of precedence, it can be flagged as important. In this case it will take precedence over all other "unimportant" rules. However, if more than one rule is important, the normal rules of precedence will be used to resolve the conflict.

The important flag is applied after the attribute assignment like this:

BODY.background {
background: white ! important;
font: serif
}
In the above example, only the background color is important, not the font specification.

===The STYLE attribute===

Style commands may also be inserted directly in an HTML tag to control its appearance. This does not have the advantages of independent style sheets, which separate content from presentation, but it does allow you to use the style sheet syntax when formatting text.

The following example uses the style attribute to color some text:

usr << "That HURT!"
As you can see, the STYLE attribute of any tag can be assigned to a text string containing a list of attribute assignments. Just the body of the style rule is given, since no selector is needed to match the current context.

==Inline Icons==

The \icon text macro causes the following embedded expression to be interpreted as an icon rather than as text. For example, an object would be replaced by its icon rather than by its name.

The following example prefixes conversational text with the speaker's icon, making it easier to associate the message with the appropriate object on the map.

mob/verb/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"
The \icon text macro expands internally to an <IMG> tag. The previous example, could be rewritten as follows:

mob/verb/say(Msg as text)
view() << " \
[usr] says, '[Msg]'"
From this, you can see that the object's current icon state is used. A reference to the icon itself is inserted using the \ref text macro, which generates a unique identifier corresponding to an object.

A final noteworthy point is that the image belongs to a style class called `icon'. This can be used to configure global properties of icons in the text terminal. For example, a full 32x32 pixel icon doesn't always fit in with surrounding text very well. A single style sheet rule takes care of that:

IMG.icon {height: 16px; width: 16px}
This is, in fact, a built-in default rule, so you don't have to define it yourself. You could override it to get full 32x32 icons. You could even define special rules to allow icons in certain contexts to be different sizes. The <BIG> and tags are ideal:

BIG IMG.icon {height: 32px; width: 32px}
SMALL IMG.icon {height: 16px; width: 16px}
Using the <BIG> tag, you could then output a full-sized icon, even though the default is small. The following example does that when the DM speaks in order to satisfy an inflated ego.

mob/DM/say(Msg as text)
view() << "\icon[usr] [usr] says, '[Msg]'"

==Special Effects==

There are a couple miscellaneous commands which create special output effects. Like the image instruction, they produce a purely visual result.

===missile instruction===

The missile instruction creates an image which moves from one location to another. It is often used as a symbolic indicator of the source and target of a projectile.

missile (Icon,Start,End)
Icon is the image icon or object type.
Start is the missile source.
End is the missile destination.
This could be used in a game of darts:

obj/dart
verb/throw(mob/M)
missile(src,usr,M)
del src
If more realism is desired, a check could be made first to determine if there is a straight unobstructed path between the attacker and target. (However, realism (in my opinion) is much overrated. Don't let it spoil a good piece of code unless you really have to. I am sure there are many cases in which our own universe too is unrealistic because God couldn't resist a simpler way of implementing things here and there. The sky is a perfect example. I mean, it looks a bit fake sometimes, doesn't it?)

===flick instruction===

The flick instruction causes a temporary transition in the icon state of an object. It lasts until all the frames in that particular state have been played and then reverts to the true icon state.

flick (State,Obj)
State is the icon or icon state to display.
Obj is the target object.
Note that it is possible to specify an entirely different icon file. Normally, however, just the state of the existing icon file is specified.

The flick instruction is often used for temporary animation sequences (like smiling, writhing in pain, etc.). These are different from changes of state which have a longer duration (like sleeping, flying, etc.). In those cases, one would simply assign the icon_state variable directly.

Sometimes, however, a flick is used in the transition between two permanent states. The following example defines a door turf which does exactly that.

turf/door
icon = 'door.dmi'
icon_state = "closed"
density = 1
opacity = 1
verb/open()
set src in view(1)
if(!density) return //already open
density = 0
opacity = 0
flick("opening",src)
icon_state = "open"
verb/close()
set src in view(1)
if(density) return //already closed
density = 1
opacity = 1
flick("closing",src)
icon_state = "closed"
The advantage of using icon states in this way is that the code remains very general. All the map designer has to do is plug in different icons with the same states and a variety of doors can be made from the one basic definition.

If the icon state specified by the flick instruction does not exist, it has no effect. In the above code, for example, a door icon could be used that did not have "opening" and "closing" states defined. Everything would work--only the transition would not be animated.

DM Guide 19

2015-11-14T20:02:18Z

IXVI: /* О порядке написания кода */ последняя правка. Хорошо бы какой-нибудь кодер проверил и упорядочил главы и содержание. Я не кодер.

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.

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



===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.

Например, при добавлении дополнительных функций к процедуре client.Topic() в разных местах в коде случается эффект сочетания зачений в родительском элементе:


client/Topic(T)
: if(T == "вступление")
: usr << "И вот как-то раз..."
: else ..()

client/Topic(T)
: if(T == "подсказка")
: usr << "Буквально позавчера."
: else ..()
В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю


===Отладка кода===

Или иначе дебаггинг(debugging).

====Манеры хорошего кодера====

Ошибка начинающих программистов в том, что они слишком полагаются на компилятор. Опытные баголовы и багоюзеры знают, что если код скомпилирован, то не факт что он работает как написано. Уязвимости бывают везде.


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


Второй шаг - запустить код, так чтобы он заработал. Подставить необходимые переменные и запустить его в приложении. Сервер может выявить простые ошибки и баги, но только вы можете понять что работает не так, как оно должно работать, и почему это не так. А что работает именно так как описано в коде. Поиграйте с переменными и кодом, чтобы лучше понять механизмы компиляции и работы вашего кода.


Затем проведите нагрузочное тестирование, попробуйте выйти за пределы допустимых параметров, указанных вами при создании объектов и фич для проекта. Как правило на этом этапе всплывают все баги и уязвимости в написанном и вы можете отловить их и пофиксить\оставить для рабочей версии проекта.


===="Неуловимые" баги====

Существует два типа багов: Краш-баги которые останавливают процесс целиком (proc crashers) и мелкие баги(silent errors), которые ломают отдельные фичи. : Пример Краш-бага - обращение к переменной объекта, отсутствие ответа от объекта, придание переменной по умолчанию равной нулю, что приводит к завершению оператора.
Когда крашится процедура, как правило сохраняются логи ошибки в world.log . При запуске созданного вами проекта в клиенте Dream Seeker, эта информация будет показана в отдельном окошке. При запуске проекта на сервере Dream Daemon - логи сохраняются в выводе серверной информации, либо в отдельном файле.


Самое главное - найти в логах название процедуры, которая вызвала падение выполнения кода, а также значение переменных src и usr на момент выполнения процедуры. Процедуры могут быть показаны цепочкой вызовов - будут показаны обращающиеся к этой и вызванной этой процедурой процедуры.


world.log << "[__LINE__]: myvar = [myvar]"

Отладка кода проводится как при отдельных случаях падения кода(и тогда удобнее пользоваться примерами приведёнными выше), так и по всем исполняемым строкам и файлам при финальной диагностике. В последнем случае вы можете пользоваться следующими макросами:


: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif

Вывод информации на отладку будет осуществляться, но он будет игнорироваться до тех пор, пока вы не используете макрос #DEBUG.


Есть полезный приём при поиске багов - вынести код в комментарии. Код, вынесенный в комментарий перестаёт восприниматься компилятором как исполняемые команды, зато виден разработчику. Это полезно для выделения кусков кода, ответственных за совершение ошибок при исполнении, и временном устранении их, вплоть до отладки проблемного места.

DM Guide 19

2015-11-14T20:01:27Z

IXVI: /* Debugging Code */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.

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



===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.

Например, при добавлении дополнительных функций к процедуре client.Topic() в разных местах в коде случается эффект сочетания зачений в родительском элементе:


client/Topic(T)
if(T == "вступление")
usr << "И вот как-то раз..."
else ..()

client/Topic(T)
if(T == "подсказка")
usr << "Буквально позавчера."
else ..()
В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю


===Отладка кода===

Или иначе дебаггинг(debugging).

====Манеры хорошего кодера====

Ошибка начинающих программистов в том, что они слишком полагаются на компилятор. Опытные баголовы и багоюзеры знают, что если код скомпилирован, то не факт что он работает как написано. Уязвимости бывают везде.


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


Второй шаг - запустить код, так чтобы он заработал. Подставить необходимые переменные и запустить его в приложении. Сервер может выявить простые ошибки и баги, но только вы можете понять что работает не так, как оно должно работать, и почему это не так. А что работает именно так как описано в коде. Поиграйте с переменными и кодом, чтобы лучше понять механизмы компиляции и работы вашего кода.


Затем проведите нагрузочное тестирование, попробуйте выйти за пределы допустимых параметров, указанных вами при создании объектов и фич для проекта. Как правило на этом этапе всплывают все баги и уязвимости в написанном и вы можете отловить их и пофиксить\оставить для рабочей версии проекта.


===="Неуловимые" баги====

Существует два типа багов: Краш-баги которые останавливают процесс целиком (proc crashers) и мелкие баги(silent errors), которые ломают отдельные фичи. : Пример Краш-бага - обращение к переменной объекта, отсутствие ответа от объекта, придание переменной по умолчанию равной нулю, что приводит к завершению оператора.
Когда крашится процедура, как правило сохраняются логи ошибки в world.log . При запуске созданного вами проекта в клиенте Dream Seeker, эта информация будет показана в отдельном окошке. При запуске проекта на сервере Dream Daemon - логи сохраняются в выводе серверной информации, либо в отдельном файле.


Самое главное - найти в логах название процедуры, которая вызвала падение выполнения кода, а также значение переменных src и usr на момент выполнения процедуры. Процедуры могут быть показаны цепочкой вызовов - будут показаны обращающиеся к этой и вызванной этой процедурой процедуры.


world.log << "[__LINE__]: myvar = [myvar]"

Отладка кода проводится как при отдельных случаях падения кода(и тогда удобнее пользоваться примерами приведёнными выше), так и по всем исполняемым строкам и файлам при финальной диагностике. В последнем случае вы можете пользоваться следующими макросами:


: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif

Вывод информации на отладку будет осуществляться, но он будет игнорироваться до тех пор, пока вы не используете макрос #DEBUG.


Есть полезный приём при поиске багов - вынести код в комментарии. Код, вынесенный в комментарий перестаёт восприниматься компилятором как исполняемые команды, зато виден разработчику. Это полезно для выделения кусков кода, ответственных за совершение ошибок при исполнении, и временном устранении их, вплоть до отладки проблемного места.

DM Guide 19

2015-11-14T17:23:45Z

IXVI: /* Типичные проблемы в больших проектах */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.

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



===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.

Например, при добавлении дополнительных функций к процедуре client.Topic() в разных местах в коде случается эффект сочетания зачений в родительском элементе:


client/Topic(T)
if(T == "вступление")
usr << "И вот как-то раз..."
else ..()

client/Topic(T)
if(T == "подсказка")
usr << "Буквально позавчера."
else ..()
В таком написании, эти два определения процедуры client/Topic(T) могут быть размещены в коде в любом месте. Если один из них будет выполнен и приведёт к значению ..() ,то другой уже не наступит. Вот в таких случаях и бывает полезно обращаться к процедуре-родителю


===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T17:21:00Z

IXVI: /* Типичные проблемы в больших проектах */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.

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



When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.

Например, при добавлении дополнительных функций к процедуре client.Topic() в разных местах в коде случается эффект сочетания зачений в родительском элементе:


client/Topic(T)
if(T == "вступление")
usr << "И вот как-то раз..."
else ..()

client/Topic(T)
if(T == "подсказка")
usr << "Буквально позавчера."
else ..()
В таком написании, эти два определения процедуры client/Topic(T) могут быть
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T17:11:07Z

IXVI: /* Типичные проблемы в больших проектах */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Понятие модуля применимо не только к какой-либо части кода, а чаще подразумевает файл или группу файлов. Открытая часть модуля - процедуры, переменные и объекты, свободные для использования в других местах помимо самого модуля. Закрытая часть модуля - это собственно тело самого модуля, сам код, который однокомпонентен.



When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.


One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T14:44:24Z

IXVI: /* Типичные проблемы в больших проектах */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


* Последовательность кода важна при наследовании процедур или переменных объекта. Если какая-либо процедура повторяется несколько раз, то она наследует последовательность выполнения первого раза.


One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

Lawyer

2015-11-14T13:54:20Z

IXVI:

{{Заготовка}}
{| border="1" cellspacing="0" cellpadding="2" width="80%" style="background-color:#ffeaea;"
!style="background-color:#dd3e40;" width=200|Профессия
!style="background-color:#dd3e40;" |Роль
!style="background-color:#dd3e40;" width=100|Сложность

|-
![[File:Joblaw.png‎]] [[Lawyer|Адвокат]]
|'''Доступ:''' Кабинет адвоката, Зал суда, Бриг.
'''Подчинение:''' [[Head of Security|Глава СБ]].

'''Обязанности:''' Предоставлять подсудимым и подозреваемым юридическую защиту.

'''Другие названия:''' Юрист

'''Guides:''' [[Guide to Security]], [[Guide to Trials]], [[Space Law]], [[Guide to Paperworks]]
!Средне - Очень сложно

|-
|}
''“Когда обнаруживаешь, что ты чуть ли не единственный, кто эти моральные преграды имеет, возникает порой искушение послать их к черту — не по убеждению и не ради удовольствия, а просто потому, что обидно быть ангелом в аду, в то время как дьявол везде себя чувствует дома.”
'' '''''Мартен Паж, "Как я стал идиотом"'''''
[[File:Lawyer.PNG|right|thumb|Офис адвоката. Кофе, пончики, бездельники.]]
[[File:Law_MetaOffice.png|right|thumb|Офис адвоката на Metastation.]]

== Юриспруденция-13 ==

Вот перечень дел, с которыми приходится сталкиваться штатному законнику:

*'''Проводить консультации по [[Space Law|Космо-Закону]]''' Теоретически, адвокат должен присутствовать при процедуре заключения в камеру. Для этого вам понадобится отличное знание свода законов, либо экземпляр книги по Космо-закону. Вашими усилиями срок может быть сокращён, заменён на альтернативное наказание, либо на более тяжкое наказание. В зависимости от [[Clown|клиента]].

*'''Быть адвокатом''' Теоретически, адвокат ведёт дело каждого злоумышленника и способен более тонко разобраться в составе преступления, участниках и доказательствах каждого дела. Важнейшие вещи здесь - это записи службы безопасности, улики и свидетельства участников.

*'''Заботиться о своих клиентах''' Поскольку обычно СБ проводит задержания в агрессивной манере, и относится к преступникам как к швали - то, теоретически, адвокат берёт на себя заботу о здоровье и благополучии своих клиентов. Зачастую, именно он добивается сокращения срока задержания, в связи с кошмарными условиями.

*'''Следить за порядком на бриге''' Теоретически, в 90% случаев процедура дознания и обыска ведётся на территории брига. Поэтому адвокат должен чётко знать, где лежат вещи его клиента, где хранятся улики и чья кровь осталась на вот этом станбатоне. Также адвокат должен уметь предсказать в какой именно момент этот порядок перестанет существовать.

*'''Пропускать желающих на бриг''' Теоретически, адвокат имеет доступ на бриг, в отличие от гражданского персонала, и в его обязанности входит сопровождать людей для дачи показаний, либо выпровождать заключённых отсидевших свой срок. И возвращать им их <s>улики</s> вещи.

*'''Вести судебный процесс''' Теоретически, каждый член экипажа имеет право отстаивать свои права в судебном порядке. Поэтому время от времени на борту корабля проводятся суды с участием Верховного судьи, Обвиняемого и Защиты. Вы можете оказаться на любой из этих сторон.

*'''Оказывать нотариальные услуги''' Ничто так высоко не ценится, как грамотно составленный, подтверждённый печатью документ, сопровождающий любые виды деятельности: От заказа ящика бананов, до лицензии на убийство. К сожалению, большинство персонала не может грамотно изложить свои доводы, составить документ и получить заветную печать - и совершают свои поступки полу-легальным путём. Так вот, теоретически - хороший адвокат, как человек связанный с законом и лояльный к службе безопасности, способен быстро и без проволочек получить любое разрешение на станции.

*'''Участие в делах''' о покушениях, нарушениях, кражах, обмане, нарушении техники безопасности, подозрительных объектах и субъектах, денежных спорах, наследственных делах, приватизации отделов и инвентаря, скупки акций Нанотрасен, теоретически - даже в праве на собственность атомной бомбы НТ в личное пользование на неопределённый срок. Хороший адвокат всегда в бизнесе.

== Закон в моих руках ==
Законы юрисдикции присутствуют и на нашей станции, куда уж без них! Надеждой и опорой невиновных или преступников, совершивших малые преступления - будете именно вы, адвокат. Вам будут предоставлены все привилегии проведения честных судов. Ваша главная опора - это закон. Закон на станции действует всегда, но иногда требуется вмешательство человека с стороны. Это вы и есть. Добро пожаловать.

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

==Слово и честь - вот мое оружие==
В ваших обязанностях уличать Службу Безопасности в необоснованных сроках задержания. Здесь свою роль играет то, как они задержали преступника, какой урон ему был нанесен. Рекомендуется обзавестись поддержкой мед-персонала, который мог бы выделить вам бесценный анализатор здоровья. Также, без поддержки авторитета в лице капитана, вам будет трудно говорить с СБ "на ты". Но не беспокойтесь, юрисдикция предписана законом, потому вам предоставят всю возможную помощь в ведении собственного следствия.

Иметь обаяние предписано самой романтике профессии юриста! Не пытайтесь провоцировать охрану, помогать очевидным преступникам и до последнего стоять на стороне обвиняемого. У нас интеллигентная и нравственная охрана, потому все будет соответствующе.

===Проверьте всё дважды===
Клиент - всегда прав. Но в этот раз правы вы, и только вы. Не верьте ни единому слову истца или детектива. Они не имеют права фальсифицировать или укрывать улики, но дружба в рядах нашей Службы Безопасности доходит до того, что они способны друг друга прикрывать от позора безосновательных тюремных сроков.

===Этика справедливости===
Мы уверены в верности ваших слов, не разочаруйте наших надежд. Ложь и обман наказуем в виде разжалования, а если ваш клиент - явный преступник, то не стоит прибегать к методам воров и дебоширов, которых вы только и встретите. На уважение ответят уважением. Силовые структуры могут вам и не верить, но поддержки у иных глав станции вы должны добиться. Только из-за того, что вы адвокат. Ведь на станции только грамотные и психически уравновешенные люди, понимающие всю важность вашей должности.

{{JobMenu}}
[[Category:/tg/station13]]
[[Category:Fernflower]]

DM Guide 19

2015-11-14T13:20:29Z

IXVI: /* Типичные проблемы в больших проектах */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===О порядке написания кода===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях:
* Препроцессор читает код исключительно последовательно - с первой строчки до последней. Поэтому макросы (значения макросов) , которые запрашивают препроцессорные команды, должны быть записаны в коде ранее препроцессорных команд. В данном случае более удобно использовать переменные(variables).


*
Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T13:15:05Z

IXVI: /* Some Code Management Issues */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Типичные проблемы в больших проектах==

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


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


Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Как упорядочить код===

Во многих случаях, последовательность или порядок кода в Dream Maker не имеет особого значения(sic!). Например процедура, переменная или тип объекта могут быть заданы до или после их прямой компиляции. Это непривычная особенность, отличающая код DM от других, где порядок написания имеет важное значение при исполнении программ.


Последовательность кода важна в нескольких случаях. В препроцессоре,
There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T12:59:31Z

IXVI: /* #ifdef */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
: mob/verb/GotoMob(mob/M in world)
: set category = "Debugging"
: usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T12:59:14Z

IXVI: /* #if */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world) 
set category = "Debugging" 
usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
: //Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T12:58:46Z

IXVI: /* #if */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world) 
set category = "Debugging" 
usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0 
//Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T12:58:33Z

IXVI: /* #ifdef */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world) 
set category = "Debugging" 
usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
//Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T12:57:38Z

IXVI: /* Условная компиляция */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Компиляция по условиям (Условная компиляция)===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world)
set category = "Debugging"
usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
//Неактивный код.
: #endif
Так как Dream Maker поддерживает вложенность команд одна в другую, также возможно взять ненужный\неиспользуемый на данный момент кусок кода в /* комментарий */ - используя разметку /* */
Оператор #if привычен для использования программистами С, так как в этом языке компилятор плохо поддерживает вложенность команд.


===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T10:50:55Z

IXVI: /* Условная компиляция */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Условная компиляция===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода при помощи #ifdef :


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world)
set category = "Debugging"
usr.loc = M.loc
: #endif

====#if====

Команда #if - более общая версия #ifdef, так как включает определения не только макросов но и констант. То есть если выражение совпадает (true), то код внутри #if будет скомпилирован, если выражение не совпадает (false), то код не будет выполняться. В случае невыполнения условий применяется команда #elif, а в случае невыполнения никаких условий из заданных вами, используется команда #else.


: #if Условие
//Код условия.
: #elif Условие
//Код условия.
: #else
//Код условия.
: #endif
Условия могут состоять из базовых (простых) операторов, или логических (boolean) операторов. После проверки данного макроса выдаётся результат = 1 , или = 0


defined (Macro)
Macro - название макроса.
Выдаёт 1 (Returns 1) если макрос определён  и 0, если не был.
Часто команда #if используется для блокировки выполнения куска кода - в случае если происходит краш, или нужно выключить какую-либо фичу без выпиливания куска кода. Вот пример выполнения кода:


: #if 0
//Disabled code.
: #endif
Since DM allows comments to be nested (one inside another) it is also possible to accomplish the same thing by putting /* */ around the disabled code. It is a C programmer's habit to use the #if command because many C compilers get confused by nested comments.

===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T10:36:56Z

IXVI: /* Chapter 19 */ Двоеточие перед решёткой.

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

: #include <libfile>
: #include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


: #define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


: #define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


: #define FLAG1 (1<<0)
: #define FLAG2 (1<<1)
: #define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

: #define FILE_DIR icons
: #define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


: #define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Условная компиляция===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


: #ifdef Macro
//Условие для дальнейшего выполнения кода.
: #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода:


: #ifdef DEBUG
mob/verb/GotoMob(mob/M in world)
set category = "Debugging"
usr.loc = M.loc
: #endif

====#if====

The #if command is a more general version of the #ifdef command because it can take any expression involving other macros and constants. If the expression is true, the code which follows is compiled. Otherwise it is skipped. Alternate conditions can be supplied with the #elif command and a final section to be compiled if all else fails may follow the #else command.

: #if Condition
//Conditional code.
: #elif Condition
//Conditional code.
: #else
//Conditional code.
: #endif
The condition may involve any of the basic operators but usually only uses the boolean operators. One addition is the defined instruction which tests if the specified macro has been defined.

defined (Macro)
Macro is the name of a macro.
Returns 1 if macro has been defined and 0 if not.
One common use of the #if command is to block out a section of code. This is sometimes done in the course of debugging or possibly to turn off a feature without throwing away the code. The following example demonstrates this technique.

: #if 0
//Disabled code.
: #endif
Since DM allows comments to be nested (one inside another) it is also possible to accomplish the same thing by putting /* */ around the disabled code. It is a C programmer's habit to use the #if command because many C compilers get confused by nested comments.

===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

: #error Message
The following example will refuse to compile if the DM macro is not defined.

: #ifndef DM
: #error You need to define DM as the name of your key!
: #endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

: #ifdef DEBUG
: #define debug world.log
: #else
: #define debug null
: #endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T10:23:34Z

IXVI: /* #ifdef */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

#include <libfile>
#include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


#define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


#define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


#define FLAG1 (1<<0)
#define FLAG2 (1<<1)
#define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

#define FILE_DIR icons
#define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


#define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Условная компиляция===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


# #ifdef Macro
//Условие для дальнейшего выполнения кода.
# #endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода:


#ifdef DEBUG
mob/verb/GotoMob(mob/M in world)
set category = "Debugging"
usr.loc = M.loc
#endif

====#if====

The #if command is a more general version of the #ifdef command because it can take any expression involving other macros and constants. If the expression is true, the code which follows is compiled. Otherwise it is skipped. Alternate conditions can be supplied with the #elif command and a final section to be compiled if all else fails may follow the #else command.

#if Condition
//Conditional code.
#elif Condition
//Conditional code.
#else
//Conditional code.
#endif
The condition may involve any of the basic operators but usually only uses the boolean operators. One addition is the defined instruction which tests if the specified macro has been defined.

defined (Macro)
Macro is the name of a macro.
Returns 1 if macro has been defined and 0 if not.
One common use of the #if command is to block out a section of code. This is sometimes done in the course of debugging or possibly to turn off a feature without throwing away the code. The following example demonstrates this technique.

#if 0
//Disabled code.
#endif
Since DM allows comments to be nested (one inside another) it is also possible to accomplish the same thing by putting /* */ around the disabled code. It is a C programmer's habit to use the #if command because many C compilers get confused by nested comments.

===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

#error Message
The following example will refuse to compile if the DM macro is not defined.

#ifndef DM
#error You need to define DM as the name of your key!
#endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

#ifdef DEBUG
#define debug world.log
#else
#define debug null
#endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T09:20:24Z

IXVI: /* Conditional Compilation */

{{Заготовка}}
''Это 19 глава перевода оригинального руководства по Dream Maker от разработчиков.''

[http://wiki.ss13.ru/index.php?title=All_about_the_code Остальные главы руководства и статьи о программировании на коде BYOND от любителей на русском.]

[http://www.byond.com/docs/guide/chap19.html Оригинальная 19 глава руководства на английском языке]

=Chapter 19=

Управление кодом в Больших Проектах

До сих пор примеры были небольшими и простыми, умещающимися в один файл .dm кодировки. Однако в дальнейшем может оказаться более удобным разделять и различать код для различных объектов в раздельные файлы. Например систему рукопашного боя в одном месте, описание мобов в другом, работу двигателей в третьем, и так далее. Также это хорошая практика для кодеров - возиться каждый со своим файлом, а не дёргать один общий.

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

==Включение файлов (''оператор'' #include)==

Содержимое одного файла может быть свободно включено в другой, благодарю использованию команды #include 
Есть две формы записи данного оператора, в зависимости от способа поиска включаемого содержимого. В первом случае компилятор будет искать файл в директории /library, а в другом случае он обратится к текущей директории и если не найдёт искомый файл, то к /library. Например

#include <libfile>
#include "dmfile"
libfile - это включаемая библиотека. 
"dmfile" - это файл исходного кода. 
Если один и тот же файл включается несколько раз, то проводится только первый запрос. Делается это для предотвращения повторов данной библиотеки кода, которую запрашивают несколько файлов в одном проекте.

Все проекты по умолчанию включают файл <stddef.dm> в начало кода. Это библиотека, описывающая несколько постоянных переменных и определителей.

Помимо включения файлов типа .dm , команда #include также используется для прикрепления карт уровней (например.dmm) к проекту. Синтакс(написание) оператора точно такое же. Карты уровней вставляются в главную карту мира и распределяются по z-уровню. Икс и Игрик координаты автоматически определяются по размеру наибольшей из вставляемых карт.


Рисунок 19.28: Перед Пре-процессингом

Когда вы используете Dream Maker для управления своим проектом, вам крайне редко придётся использовать сами операторы #include и #define FILE_DIR macros. В Dream Maker эти функции реализуются через сам интерфейс. 

Как упоминалось ранее, кодовые файлы и файлы карт добавляются через чек-бокс в диспетчере файлов. Привязка файлов происходит также. Все файлы в директории вашего проекта и внутри неё автоматически размещаются без добавления путей к ним. И путь к каждому файлу в Dream Maker упрощается до названия самого файла, например: world/icons/mobs/warrior.dmi = warrior.dmi


В некоторых случаях применение команды #include размещает файл на исполнение выше, чем это указанно в коде. Подробнее об этом в разделе 19.3.1.


==Препроцессор==

Команда #include - одна из нескольких "препроцессорных" команд. Опознать их можно по символу "#" и последовательному расположению в коде (Препроцессор Dream Maker в данном случае подобен компиляторам C и C++. Также эти люди называют команды "препроцессорными директивами). Препроцессор управляет данными командами, пока файл кода начинает исполняться и может изменять поведение файлов, в зависимости от распознавания их компилятором. Другие препроцессорные команды изложены ниже:


===''оператор'' #define===

Команда #define создаёт макрос(префикс), или иначе говоря переменную в препроцессоре. Любые участки с данным префиксом в коде будут замещены содержанием данного макроса. В местах, где макрос является частью другого слова или используется в текстовом описании, команда не сработает. Примеры:


#define Name Value
Name - название макроса(префикса).
Value - значение макроса(переменной).

Команды препроцессора заканчивают исполнение по завершении строчки кода, в которой они описаны. Если вы хотите расписать свой код на несколько строк, используйте символ \ в конце строки.


Название макроса может состоять из заглавных и строчных букв, цифр и символа подчёркивания, но не может начинаться с цифры. По умолчанию НАЗВАНИЕ МАКРОСОВ часто набирают исключительно заглавными буквами.


Также можно придавать макросу значения аргументов, для более точного применения их в коде:


#define Name(Arg1,Arg2,...) Value
Arg1 - название первого аргумента.
Arg2 - название второго аргумента, и т.д.
Перечисляемые аргументы будут найдены в коде, и им будет подставлено значение(value) данного макроса. Считается что это процедурный уровень, но так как он оперирует текстовыми значениями, его возможности более обширны и гибки.


Использовать макросы в выражениях следует с осторожностью - компилятор может не успеть посчитать вставленный из макроса текст, особенно в сочетании с другими текстовыми значениями кода. Для безопасности вы можете взять значения макроса в круглые скобки #define Macro (Value) - чтобы значение не пересекалось с другим исполняемым кодом.


Вот пример кода, применяемый для решения проблем с оператором сдвигом разряда << ,без затрагивания остальной части кода после вставления макроса.


#define FLAG1 (1<<0)
#define FLAG2 (1<<1)
#define FLAG3 (1<<2)

===Специальные макросы===

Есть несколько макросов, имеющих определённые специальные значения.

====FILE_DIR====

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


#define FILE_DIR Path
Path - путь к ресурс-пакам.
Используя данный макрос, вы сможете сократить пути поиска ваших ресурсов компилятором. Просто заранее введите возможные пути расположения файлов, и в дальнейшем набирайте только имя искомого файла(ресурс-пака).


Как пример - задание макросов для поиска спрайтов(icons) и звуков(sounds):

#define FILE_DIR icons
#define FILE_DIR sounds

====DEBUG====

Макрос DEBUG включает добавление дополнительной информации в файл .dmb ,что плохо сказывается на скорости исполнения процедур кода, но построчно записывает информацию о выполнении всего кодового файла - в том числе где возникают ошибки, баги и отчего крашится код.


#define DEBUG
Просто добавьте эту строчку в ваш код, и режим Debug будет включен.

====__FILE__====

Макрос __FILE__ показывает файл в котором распологается исполняемый в данный момент код. Полезный макрос для создания Debug-сообщений.


====__LINE__====

Макрос __LINE__ показывает строчку кода, которая исполняется в данный момент. Тоже полезен для выведения Debug-сообщений. Вот пример:


proc/MyProc()
//Сейчас крашнется.

world.log << "[__FILE__]:[__LINE__]: We got this far!"

//Нет? Странно...

====DM_VERSION====

Макрос DM_VERSION показывает номер версии вашего компилятора. Используется для определения устаревшей версии кода, и замены некоторых операторов на новые.


===#undef===

Макрос #undef убирает заранее заданный макрос. Его можно расположить после исполненного макроса для переназначения значений, а также в конце кодового файла, чтобы данный макрос не перешёл на исполнение в другие файлы.


===Условная компиляция===

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


Вот данные макросы условий для компиляции.

====#ifdef====

Команда #ifdef разрешает компилировать последующий код, только если определённому макросу было задано определённое значение. Выполнение данной команды завершается оператором #endif


#ifdef Macro
//Условие для дальнейшего выполнения кода.
#endif
Также существует команда #ifndef - она срабатывает если значение определённого макроса не было задано.


Например макрос DEBUG можно включать для определённого участка кода:


#ifdef DEBUG
mob/verb/GotoMob(mob/M in world)
set category = "Debugging"
usr.loc = M.loc
#endif

====#if====

The #if command is a more general version of the #ifdef command because it can take any expression involving other macros and constants. If the expression is true, the code which follows is compiled. Otherwise it is skipped. Alternate conditions can be supplied with the #elif command and a final section to be compiled if all else fails may follow the #else command.

#if Condition
//Conditional code.
#elif Condition
//Conditional code.
#else
//Conditional code.
#endif
The condition may involve any of the basic operators but usually only uses the boolean operators. One addition is the defined instruction which tests if the specified macro has been defined.

defined (Macro)
Macro is the name of a macro.
Returns 1 if macro has been defined and 0 if not.
One common use of the #if command is to block out a section of code. This is sometimes done in the course of debugging or possibly to turn off a feature without throwing away the code. The following example demonstrates this technique.

#if 0
//Disabled code.
#endif
Since DM allows comments to be nested (one inside another) it is also possible to accomplish the same thing by putting /* */ around the disabled code. It is a C programmer's habit to use the #if command because many C compilers get confused by nested comments.

===#error===

The #error command stops compilation and displays the specified error message. Library writers can use this to tell the user of the library if something is wrong.

#error Message
The following example will refuse to compile if the DM macro is not defined.

#ifndef DM
#error You need to define DM as the name of your key!
#endif

==Some Code Management Issues==

There are a few things to keep in mind when working with large DM projects. First and foremost one must strive for simplicity. The art of programming is mostly a matter of realizing your own limitations and compensating for them.

If, as the project grows, each new piece of code depends upon the details of every previous piece of code, the complexity of the project is growing exponentially. Before you know it, the code will rise up in revolt and stick you in a dark smelly dungeon. End of story.

Fortunately, most programming tasks do not require exponential complexity. With a good design, you can split the project into pieces which interact with each other in a fairly simple way. These pieces are often called modules which is why this practice is termed modular programming. (It is interesting to note, however, that all such schemes to avoid exponentially complex code ultimately fail. They only move the exponential growth to a higher level--from individual statements to procedures to objects and on and on. It may be true that complexity will always win out in the end and that every project undergoing perpetual growth must periodically be redesigned from scratch in order to remain comprehensible. Or perhaps this tendency is merely the result of a periodic increase in wisdom to offset the inevitable decline in intelligence. In my own case, I know this to be a prominent factor.)

Although the term module can refer to any unit of code, it most often is embodied by a file or group of files. The public parts of the module are those procedures, variables, and object types which are advertised for use by code outside the module. This is called the module interface and defines the syntax for putting information in and getting results out of the module. All other private material is considered internal to the module and is not for use by outside code.

When devising a project, one should foresee the function of the different component modules and have a rough idea of the interface to each one. When work commences on a module, it is worth putting a description of the public interface in a comment at the top of the file. This helps focus development along lines consistent with a good clean interface. You will also find it a useful reference in the future when you or someone else needs to use the module. You won't need to page through expanses of code to figure out how to operate your wonderful gadget.

===Ordering Code===

In many cases, the sequential order of DM code makes no difference. For example, a procedure, variable, or object type may be defined before or after being used in the code. This is different from some languages which require every symbol to be defined prior to being used.

There are a few cases, however, when the order of code does matter. The preprocessor, for example, operates strictly sequentially from top to bottom of the code. The principle consequence of this is that macro definitions must precede their use. This is one good reason to instead use constant variables for the purpose when it is possible.

Another time when code sequence matters is when overriding object procedures or variable initializations. If the same procedure is overridden several times in the same object type, subsequent versions take precedence and will treat previous ones as their parent procedure.

One might, for example, add functionality to the client.Topic() procedure in several different locations in the code. As long as you remember to execute the parent procedure each time, the additions are cumulative.

client/Topic(T)
if(T == "introduction")
usr << "Once upon a time..."
else ..()

client/Topic(T)
if(T == "help")
usr << "The situation is helpless."
else ..()
As written, these two definitions of the Topic procedure can fall in any order with any amount of intervening code. If one of them neglected to call ..(), however, it would disable any previous versions of the procedure. It is therefore good practice to always call the parent procedure unless you specifically wish to disable it. Then you don't have to worry about maintaining any special order of the procedures.

===Debugging Code===

Bugs happen. Actually that is an understatement in large projects. Bugs happen frequently. This is fortunate, because there is nothing more satisfying than exterminating a bug.

====Good Coding Habits====

The novice programmer has far too much faith in the compiler. The veteran bug hunter, however, knows that just because the code compiles doesn't mean it works. It could still be infested with potential problems.

The first rule for successful debugging is to compile the code yourself. Of course you do not need to generate the byte code by hand; that's what the compiler is for. Compiling the code yourself means reading through the code you have written as though you were the compiler and making sure what the compiler sees matches what you intended.

The second good debugging habit is to run the code yourself. Initialize the necessary variables to some typical values and step through the procedure in your mind. The server can catch simple errors, but only you know what the code is supposed to do, so only you can tell the difference between code which runs and code which actually works. After doing a typical case, also be sure to think through any exceptional cases which may occur. For example, with a loop, you should verify that the first and last iteration will operate as expected.

After doing these pre-checks, it is, of course, vital to test the code for real. This is known as beating on the code. Don't be gentle. Treat it roughly to expose any unforeseen weaknesses. If it is code which responds to user input, try doing the usual things and then try things you wouldn't normally expect.

Code which has passed these three tests will be reasonably sound. By catching bugs early, you save yourself a lot of trouble, because the code is fresh in your mind and therefore easier to decipher. Besides, you will find that deciphering bug reports from other users can be even harder!

====Elusive Bugs====

Even when you have been careful, some subtle problems may still occasionally slip through. Hunting them down can be a frustrating experience, so it is good to have a few tricks up the sleeve.

There are two types of bugs: proc crashers and silent errors. Those that crash procs are the result of some exceptional case occurring. For example, the code might be trying to access an object's variable but the object reference is null. Allowing this sort of case to silently slide by (by pretending the variable of the non-existent object is null, for example) might be a convenient thing to do in some cases, but in others it might cover up a genuine error that needs to be corrected by the programmer. Crashing the procedure and reporting the problem therefore makes it much easier for you to discover the problem and find its source.

When the procedure crashes, some diagnostic information is output to world.log. When running the world directly in the client, this information is displayed directly in the terminal window. With a stand-alone server, it is normally in the server's output but may be redirected to a file.

The most important part of the diagnostic information is the name of the procedure that crashed. The value of the src and usr variables are also included. If there are any procedures in the call stack (that is, the procedure which called this one, and the procedure which in turn called it, and so on) these are displayed.

If this is not enough information for you to locate the source of the problem, try compiling the world with the DEBUG macro defined. This will add source file and line number information to the diagnostic output.

One may also need to probe around in the code to see what is going on. This can be accomplished by sending your own diagnostic information to world.log. For example, you might to know the value of a variable at a particular point in the code. This could be done with a line like the following:

world.log << "[__LINE__]: myvar = [myvar]"
Sometimes debugging output such as this is simply removed after fixing the problem, but sometimes you may want diagnostic information to appear whenever you are testing the code. In this case, a macro such as the following may be useful.

#ifdef DEBUG
#define debug world.log
#else
#define debug null
#endif
You can then send output to debug and it will be ignored when not in DEBUG mode.

Another tool for hunting bugs is to comment out code. This may be helpful when determining whether a certain piece of code is responsible for an observed problem. By simplifying the procedure and gradually disabling all but the code which causes the glitch, you can save yourself from scrutinizing a lot of irrelevant material.

This is also essential when asking others for help. Nobody wants to read through pages and pages of somebody else's code. If you can't see the problem yourself but can isolate it down to a small piece of code, you will find it much easier (and fruitful) when getting help from other programmers. Sometimes just trying to clearly define the problem enables you to suddenly see the solution yourself--avoiding the embarrassment altogether.

DM Guide 19

2015-11-14T08:46:08Z

IXVI: /* Препроцессор */

DM Guide 19

2015-11-14T08:31:18Z

IXVI: /* оператор #define */

DM Guide 19

2015-11-14T08:22:54Z

IXVI: /* #define */

DM Guide 19

2015-11-13T20:30:49Z

IXVI: /* The Preprocessor */