== Краткое описание ==
Карта научной станции "Эклипс", новое воплощение перерожденной классической станции "Исход".

Файл:Map Eclipse.jpg

2019-09-24T06:09:38Z

Krendelec: Krendelec загрузил новую версию Файл:Map Eclipse.jpg

2019-05-29T10:07:55Z

Krendelec:

{|
|-
!style="width:200px"|[[File:Onyxyeye@256x256.png]]
|
'''<span style="font-size: 20px"><font style="color: orange;">Chaotic</font> <font style="color: #282b2c;">Onyx</font></span>'''

'''Текущий глава:''' VitaliiCN ''(Discord-ID: VitaliiCN#6005)''

'''Направление сервера:''' ролевая игра в рамках классической Space Station 13.

'''Зайти на сервер:''' byond://ss13.ru:2507

'''Текущий билд:''' <span style="a {color: red;}">[https://github.com/ChaoticOnyx/OnyxBay OnyxBay]</span>

'''Discord:''' [https://discord.gg/RxK5v8k присоединиться]
|}
{{toc_right}}

'''Space Station 13 - игра про Чрезвычайное Происшествие на космической станции и сотрудников, которые пытаются устранить ее последствия или хотя бы их пережить.''' Что будет если вычеркнуть пару слов из этой фразы? Убрать из игры Чрезвычайное Происшествие - игра превратится в симулятор офисного работника 2556. Уберем слова про сотрудников - останутся раунды по 15 минут, вечные дырки в станции, разгерметизации, взрывы, 3 режима и убийства для фана.

Всю историю сервера Space Station 13 делились на те, на которых знают только про Чрезвычайное Происшествие и на те, на которых не хотят знать ни про что, кроме сотрудников. На ролевом сервере Черной Тирании всегда были игроки, которые понимали, что истинная SS13 где-то ближе к Чрезвычайным Происшествиям, нежели чем к чаепитиям, а на свободной Белой Мечте находились такие, что хотели чуть-чуть меньше Хаоса и больше отыгрыша. Может быть пора перестать бросаться из крайности в крайность и воткнуть свой вектор с направлением сервера '''ровно по середине'''?

'''Направление Chaotic Onyx - ролевая игра про Чрезвычайное Происшествие на космической станции'''. Здесь вы не увидите трейторов, которые играют только ради зеленого текста, и офицеров СБ, которые начнут в вас стрелять за километр только потому что их предыдущие 10 раундов подряд молча избивали огнетушителем до смерти. Точно также мы стараемся избегать "чайных" ситуаций, когда весь геймплей сводится в маленькое окошко чата снизу-справа вашего монитора.

Chaotic Onyx - это не про ярлыки ролеплееры-грифонеры, а про ту '''Space Station 13, какой она должна была всегда быть'''.

== Важная информация ==

* '''Правила сервера:''' [[Onyx Rules]]
* '''Предыстория:''' [[Chaotic Onyx Backstory]]
* '''Более подробное руководство по отыгрышу роли:''' [[Guide to Rolebeing]]
* '''Space Law:''' [[Space Law/Onyx]]
* '''Standard Operating Procedure:''' [[Standard Operating Procedure]]
* '''Цепь Коммандования:''' [[Chain of Command]]
* '''Заметки Администратора Оникса:''' [[Onyx Administrator's Notes]]
* '''Гайд по грамотности''' [[Guide to Grammar]]

=== Подсказки ===

Разберем различные вопросы, которые остаются неочевидными для многих игроков:

* '''Флавор должен описывать статичную внешность персонажа''', которая не изменяется на протяжении всего раунда. В нем нет места для эмоций, характера, впечатления, которое он кому-то оставляет и так далее. Также не стоит описывать области тела, скрытые под одеждой.
* '''Не стоит вместо флавора давать ссылку на портрет персонажа в интернете''': другим игрокам гораздо удобнее мельком прочитать пару строчек, чем раскачегаривать браузер и отвлекаться от игры, чтобы узнать какого цвета глаза у вашего персонажа.
* '''Цепь командования''' работает не только при отсутствующем капитане, а всегда. Любой глава может приказывать любым сотрудникам станции в области своей компетентности. Так, ХоС может приказать всем сотрудникам станции не вступать в контакт со странным человеком в синем балахоне, а ХоП уволить ученого, который пропивает все свое время в баре, пользуясь тем, что у него нет Директора по Исследованиям.

=== You was blocked by EAMS ===

На сервере действует специальная система, которая по косвенным признакам определяет любителей набегать и портить игру другим. В случае ошибочных срабатываний - обращайтесь в AdminHelp или в [https://discord.gg/EcQWksh наш дискорд].

Main Page

2019-05-18T18:32:59Z

Krendelec:

<div style="text-align:center">
<div style="font-size: 210%">Добро пожаловать на официальную вики сервера '''Chaotic Onyx! [[Файл:Turboslime.gif|link=https://ss13.ru]]'''</div> </div>


<div style="text-align:center">
<div style="font-size: 110%">В данный момент у нас [[Special:Statistics|{{NUMBEROFARTICLES}}]] статей, [[Special:Statistics|{{NUMBEROFACTIVEUSERS}}]] активных участников и [[Special:Statistics|{{NUMBEROFFILES}}]] загруженных файлов.</div>
</div> <br>


{{Шаблон:Newwikiinfo}}
<br>


{| border="1" width=100% class=wikitable
|colspan=2|
<div style="font-size: 115%; line-height: 150%; margin-top:25px; text-align: justify;">
Добро пожаловать на русскую Вики-энциклопедию по игре [[Space Station 13]]! Здесь собраны справочные материалы, руководства и другая полезная информация. Игра разработана на платформе [http://www.byond.com/ BYOND], содержит множество различных режимов игры, полную интерактивность и разрушаемость. Игра не имеет никаких "границ", Вы можете быть тем, кем хотите и делать то, что захотите (в разумных пределах, хоть и ограниченных Вашей фантазией).
<br>
<br>
Игра сложна на первый взгляд, но лишь потому, что, в отличие от остальных игр жанра "песочница", несет намного больший потенциал. Разрушать или строить? Убивать или спасать? Держаться с командой или быть одиночкой? Выбор лишь за Вами. А мы постараемся помочь вам разобраться, что к чему и сделать так, чтобы вы получили от игры максимум ощущений.

Если Вы новичок, то мы рекомендуем Вам прочитать статью [[Getting Started|обо всем необходимом для начала игры]], а так же ознакомиться с [[Onyx_Rules|правилами нашего сервера]]. Помните, что сервер является ролевым, а значит требования к игре могу показаться вам непривычными. '''Дабы избежать разногласий с администрацией, обязательно ознакомьтесь с этими двумя статьями!'''

Более опытные игроки могут ознакомиться с информацией о многочисленных сборках станции, как и тех которые используются у нас, так и старых или использующихся только на зарубежных серверах. Мы постарались собрать и перевести как можно больше информации об огромном мире [[Space Station 13]].
</div>
|}

Файл:Turboslime.gif

2019-05-18T18:32:38Z

Krendelec:

Заглавная страница

2019-05-11T11:31:58Z

Krendelec: /* Карта Викистанции */

2019-05-11T11:03:36Z

Krendelec:

Roboticist/D2K5

2019-05-11T11:03:23Z

Krendelec:

{{Архивировано}}
{| 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:Jobrob.png]]<br>[[Roboticist|Роботехник]]
|Доступ: Robotics; Technical Storage; Maintenance

Подчинение: [[Chief Engineer]]

Описание: Просирает все свои инструменты и пытается делать жопоробота.

Guides: [[Guide to Robotic|Руководство по Роботехнике]]
!Средне
|}

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

Из вещей тут есть скальпели и циркулярная пила, зарядное устройство, мультитул, датчики (''proximity sensor''), огнетушитель и запасная монтировка. Ящик у исследовательского компьютера содержит запчасти для роботов и киборгов, включая провода, батареи с зарядом 15000 и много листов металла.

== Создание Киборгов ==

Процедура создания обыкновенного киборга по пунктам.

1. Пополнить запас металла в фабрикаторах путём кликания по фабрикатору активной рукой, в которой есть металл.
2. Создать каркас киборга, голову, руки и ноги; порядок не важен.
3. Добавить две флешки в голову (не забудьте прицелиться в голову на кукле).
Совет: Для этого подойдут даже разрядившиеся флешки.
4. Добавить проводку и заряженную батарею в корпус.
5. Прикрепить голову, корпус и конечности к каркасу (''robot suit''), просто взять в руки нужную часть и кликнуть по каркасу.
6. Вытащить мозг из того, кого вы собрались "боргифицировать".
1. Схватите (интент - ''grab'') пациента и кликните на операционном столе.
2. В одну руку возьмите скальпель, а в другую - циркулярную пилу.
3. Выберете голову на прицел-кукле.
4. Применять инструменты в таком порядке: скальпель -> пила -> скальпель -> пила.
7. Добавьте мозг в уже готового киборга, держите мозг в активной руке и кликните на него.
8. И щепотку базилика
Поздравляю! Если батарея заряжена, владелец мозга сможет контролировать тело.

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

== Использование Компьютера для Чайников ==

Компьютер роботехника с исследовательскими данными используется не так как в других лабораториях. Как только в базе появилась новая технология, роботехник может загрузить её чертежи в фабрикаторы. А вот, непосредственно и сам процесс:

1. Откройте консоль компьютера, кликнув на него.
2. Вставьте в него ID-карту, кликнув на пустое поле у "''Card''" держа карту в активной руке (или просто кликните по компьютеру).
3. Нажмите "''login''", и вытащите свою карту обратно.
4. Нажмите на "''run automate''" чтобы запустить программу.
5. Консоль теперь отобразит различные команды. Вы будете начинать с "''research''"
6. Появится список возможных исследований. Введите ''research [нужная опция]" чтобы начать.
7. Компьютер начнёт исследование. Нижние уровни исследований проходят быстрее.
8. Когда вы исследовали достаточно, после нажатия "research" появится сообщение, которое предложит вам перейти на следующий уровень командой "advance". Введите эту команду чтобы разблокировать исследования следующего уровня.
Совет: Не обязательно сразу переходить на следующий уровень; перед этим можно изучить все оставшиеся исследования текущего уровня.

== Древо <s>Прокачки</s> Исследований ==

'''Первый Уровень'''

Исследования этого уровня занимают 1:40 за каждое, и в основном для них нужен ''pharosium''.

* Улучшение фабрикаторов(Improved Manufacturing Units): на создание частей уходит меньше материалов.
* Чертежи ботов(Basic Drone Schematics): охранный бот, медбот, пожарный бот, бот-который-чинит-пол и бот-уборщик.
* Сенсорные протезы(Sensory Prostheses): ''VISOR goggles''(очки), которые позволяют слепым видеть, ''auditory headset'' - глухим слышать.
* Улучшенные Модули Киборгов(Improved Cyborg Modules): киборг-шахтёр, киборг-атмостех и раздатчик модулей для киборгов.
* Модификации Киборгов(Basic Cyborg Upgrades): Propulsion ''Propulsion upgrade'' (реактивный ранец), одноразовые наборы для подзарядки и починки, улучшение скорости, оптические мезонные сканеры.

'''Второй Уровень'''

Исследования этого уровня продлеваются 3:20 минут; может пригодиться ''claretine''.
* Большое Улучшение Фабрикаторов(Superior Manufacturing Units): они потребляют ещё меньше материалов.
* Улучшенные алгоритмы исследований(Improved Research Algorithms): уменьшает время исследований на 20% (до 2:40 на этом уровне)
* Улучшенная Перезапись и Перезарядка(Improved Rewriting & Recharging): Устройство для перезаписи модулей (''Module Rewriter'') действует почти мгновенно. Повышенна скорость подзарядки киборгов.
* Новые модули для киборгов(Superior Cyborg Modules): Охранный, строитель и химик.
* Улучшенная Модернизация Киборгов (Improved Cyborg Upgrades): силовой щит, тепловой щит, тепловизор.

'''Третий Уровень'''

Исследования на этом уровне занимают 5 минут (4 с улучшением алгоритмов), кроме улучшения имплантов, которое исследуется за 2:30 (2:00 с алгоритмами). Нужно будет запастись всяческой рудой, она вам потребуется.

* Эффективные Фабрикаторы(Efficient Manufacturing Units): ещё одно уменьшение затрат материалов
* Быстрые Фабрикаторы(Rapid Manufacturing Units): фабрикаторы создают части быстрее.
* Улучшенные Импланты(Rapid Manufacturing Units): ''Machine translator'' (позволяет использовать канал роботов :s) и импланты ''blood-monitor'' (позволяют проверять состояние здоровья).
* Ещё одни модификации для киборгов(Superior Cyborg Upgrades): экономия энергии, самопочинка, телепорт и дополнительные слоты.

'''Четвёртый Уровень'''

???

* Продвинутые Алгоритмы исследований(Advanced Research Algorithms): помогает вам исследовать оставшееся единственное улучшение быстрее-...???
* Продвинутые Фабрикаторы: думаю, тут без комментариев, ведь все любят экономить материалы?

'''Продукция'''

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

Все эти штучки вам дёшево не обойдутся. Для этого потребуется много ресурсов, некоторые из них даже нельзя достать на самой станции. Вам повезло, что больше всего для исследований нужны ''mauxite'', ''molitz'' и ''pharosium'', а они доступны на станции в форме листов металла, стекла и проводов, соответственно.

Экзотические руды понадобятся при более продвинутых исследованиях. И добыть их можно только на шахтёрском астероиде. Есть два основных способа достать руду для вас: просто попросить шахтёров, или создать своих киборгов-шахтёров <s>с блэкджеком и шлюхами</s>, чтобы они добывали минералы для вас. Если всё пройдёт гладко (а что может пойти не так?), то у вас в мастерской скоро окажутся ящики с рудами.

Одного лишь шахтёрского модуля может и не хватить для киборга, он всё-ещё может наткнуться на неприятности. Улучшение боргов на первом уровне исследований (Basic Cyborg Upgrades) значительно облегчит ему жизнь. Установить модификации на рабочего киборга можно просто взяв вашу ID-карту и использовав на нём чтобы открыть интерфейс, а потом открыть панель ломом, а потом просто засунуть модификацию в киборга. Ох уж эта современная наука... Только не забудь закрыть всё это, когда закончишь.

== Содержание Киборгов и Модификации ==

'''Модуль'''

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

Чтобы поменять модуль киборгу, роботехник должен использовать на нём ID-карту и открыть панель ломом, а потом вытащить оттуда карту модуля.

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

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

'''Батареи'''

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

TIP: Замена батареи происходит также как и замена карты модуля.

'''Модификации'''

Модификации устанавливаются и снимаются путём открытия крышки киборга, а потом клика на него с модификацией в руке. У киборга может быть установлено только две модификации одновременно, и большинство из них потребляют дополнительную энергию. Есть большой спектр модификаций, которые можно комбинировать с большим спектром модулей. Например, киборгам-шахтёрам отлично подойдут реактивные ранцы, а охранным киборгам - повышение скорости или термальные сканеры. Для создания модификации её нужно для начала изучить, а потом нажать на "''Download Available Schematics''" в самом низу меню фабрикатора.

'''Мозги'''
Если у вашего киборга атрофировались мозги, или мозги которые вы взяли из того трупа в мусорке оказались неподходящими, вы всегда можете вытащить мозги из киборга. Просто используйте на киборге ID-карту, а потом монтировку. Это вскроет его, позволяя вам вручную вытащить и заменить мозг.

== Боты ==
Кроме создания запутанных комбинаций плоти и металла, роботехник может делать и не такие сложные механизмы для всяческих задач. Их можно создавать в фабрикаторах после изучения "''Basic Drone Schematics''", но их можно создать и вручную, что может сохранить вам материалы и время.

'''Медбот'''
Медбот автоматически колит трикордизин всем раненым людям поблизости, или если его модифицировать, то что у него будет в пробирке. Их можно взломать емагом, после чего они будут вкалывать людям не очень-то и лечащие химикаты. Чтобы построить вручную, соединяйте всё в таком порядке:

1.Возьмите левую или правую руку робота
2.Добавьте пустую аптечку любого цвета
Совет: Если вы можете подписать аптечку/роботическую руку чтобы выбрать боту имя.
3.''Health analyzer'', который есть в каждой аптечке.
4.''Proximity sensor''; один изначально есть в мастерской роботехника.

'''Чистящий Бот'''

Чистит полы не оставляя за собой скользкой воды. Если взломать его емагом, то о предыдущем преимуществе можно забыть, все будут поскальзываться. Чтобы создать такого, соединяйте в следующем порядке:

1.Синее ведро. Можете взять его у уборщика или садовника.
2.''Proximity sensor''
3.Левая или правая рука робота.

'''Бот-пожарник'''

The firebot murders fires. When emagged, it knocks people into nearby walls with surprising efficiency. To build one manually, combine the following in order:

1.Пустой тулбокс (красный)
2.Левая или правая рука робота
3.Огнетушитель
4.''Proximity sensor''

'''Бот-который-чинит-пол'''

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

1.Пустой тулбокс(синий)
2.Плитка (''floor tile'')
3.''Proximity sensor''
4.Левая или правая рука робота.

'''Охранный Бот'''

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

1.Используйте отвёртку на ''Remote Signalling Device''
2.Соедините его с шлемом охраны.
3.Возьмите то, что у вас вышло и используйте на нём сварку.
4.Combine it with a proximity sensor
5.Then a left or right robot arm
6.And a stun baton to finish

Один такой в начале смены появляется в бриге, легендарный Бипски!

'''Жопобот'''

Новейшее изобретение космических британских учёных - автоматизированная задница с торчащей рукой. Он будет ходить и слушать что говорят люди, а потом повторять со своими коррективами, в основном состоящих из замены некоторых слов на "butt". Чтобы построить такого, соедини вот это в соответствующем порядке (не перепутай):

1.Жопа
2.Рука робота

'''Репликант'''

Репликанты это киборги, которые выглядят как люди. Функционально, они идентичны киборгам. Чтобы сделать репликанта, добавь как минимум 30 единиц синтетической плоти к '''законченному''', но ещё '''пустому''' каркасу киборга. Мозг добавлять как обычно.

Совет: Химия - это ваш почти единственный способ добыть синтетической плоти, будьте вежливы.

== Советы ==

1.Если твои инструменты украли или просто потерялись, можно сделать ещё в фабрикаторе.

2.Кончились флешки, не знаешь то делать? Можно взломать фабрикатор.

== Искусство Предавать ==

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

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

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

3.Если вы будете тащить труп по коридору, никто и не удивится, если вы скажете что это был доброволец. Однако, пользуйтесь этим осторожно.

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

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

6.Строить ботов, а потом взламывать их емагом - отличный способ устроить треш, угар и содомию на станции.

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

[[Category:D2K5]]

DM Guide 12

2019-05-11T11:02:46Z

Krendelec:

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

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

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

Chapter 12

Savefiles

Life was like one of those many-storied houses of dreams where the dreamer, with a slow or sudden rush of understanding like a wash of cool water, knows himself to have been merely asleep and dreaming, to have merely invented the pointless task; the dreamer awakes relieved in his own bed and rises yawning, and has odd adventures, which go on until (with a slow sudden rush of understanding) he awakes in this palace antechamber; and so on and on.
--John Crowley, Little Big
Сейв-файлы используется для записи информации на диск. Делается это, в основном, по двум причинам. Во-первых, это хранение информации о мире, которая сохраняется, а потом может быть загружена вновь. Примером может служить сохранение книг в библиотеке.
Другая причина - хранение информации игроков и о игроках. Сейв-файлы используется для сохранения персонажей игроков, и даже передачи их с сервера на сервер.

1. The savefile Object

The savefile data object provides control over a savefile on the disk. It is another built-in object type in DM. All data that is read from or written to the file goes through the savefile object.

To create a savefile object, the new instruction is used.

new /savefile(Name)
Name is the optional file name.
If a file with the specified name already exists, it will be used by the savefile. Otherwise, a new one is created. If no name is specified, a unique temporary file will be created.

When the savefile object is deleted the specified file will remain. It can be accessed at a later time by creating another savefile object with the same name. Notice the difference between creating the object and creating the file. Several savefile objects may be created to access the same physical file. That file is only created once and lasts until it is explicitly removed.

The only case in which this is not true is when no name was given and a temporary file was used. In that case, the file is deleted along with the savefile object. Such temporary savefiles may be useful when loading information from another world, as will be described in section 12.6.

2. Saving Players

The first case we shall consider is how to save a player when they log out and restore them when they log back in. By doing that, you are free to delete their mob when they aren't around; it is just taking up memory and probably getting into mischief--best to put the avatar into suspended animation until the player returns. Another practical reason is that you can freely reboot (or horror of horrors) crash the world without losing player information. (And if you make a backup of the savefile, you are "free" to crash your hard-drive too. What fun!)

The mob Write proc is used to store information about a player and the Read proc is used to restore it. These both take a savefile as an argument.

object.Write (F)
object.Read (F)
F is the savefile.
By default, the Write procedure stores the value of each object variable. You will see later how to add additional information or how to control which variables are saved.

For now, let's just use the default Read and Write procs to save a player. It can be done like this:

mob/Logout()
var/savefile/F = new(ckey)
Write(F)
del(src)

mob/Login()
var/savefile/F = new(ckey)
Read(F)
return ..()
In this case, each player is saved in a separate file with the same name as their key. To make sure it is a valid file name, we used ckey, the canonical form of the key, which is stripped of punctuation. This is still guaranteed to be unique, so there is no fear of conflict.

You might be wondering what happens when a new player logs in. Since they don't have a savefile, a new one will be created. The Read proc, of course, will find this file to be empty and will therefore return without making any changes.

When an existing player logs in, on the other hand, each variable will be restored to the value it had when last saved. Some of those variables may just be numbers or text. Some, like the contents list, may be more complicated. Those are handled too. (Gasp. Or at least inhale with slight exaggeration. Otherwise, you won't fully appreciate the sentence you just read.)

2.1 tmp Variables

A few things are not saved. For example, the mob's location is not restored. That is because the location is a reference to an external object (like a turf). If that value were written to the savefile, it would be treated just like an item in the contents list--the whole object would be written to the savefile. That is certainly not what you want in the case of the mob's location.

Variables like loc are called temporary or transient variables, because their value is computed at run-time (when the mob is added to the contents list of a turf). In some cases, temporary variables would just be wasting space in the savefile, but in others (like loc), it would be incorrect to save and restore them as though they were objects "belonging" to the player.

The Write proc already knows about the built-in temporary variables. If you define any of your own, however, you need to mark them as such. You do that with the tmp variable type modifier. The syntax is just like global and const.

The following example defines some temporary variables that reference external objects. We don't happen to want those objects (in this case other mobs) to be saved along with the player. Since there is no way for the compiler to know that, we have to tell it by using the tmp flag.

mob
var/tmp
mob/leader
followers[]

2.2 Overriding Write and Read

In some cases, you might want to restore temporary variables when the player is loaded. Take the case of the player's location. You may not want it saved as an object but rather as a coordinate that can be restored when the player returns.

In other words, you want to save it by reference rather than by value. The trick is, you have to find some sort of reference that will still be valid in the future--possibly even after you have recompiled and rebooted the world. That is why the compiler leaves this sort of thing up to you: only you can decide how best to do it.

In this case, we will simply save the player's map coordinates. The following example gets the job done, but you will see an even better way to do it later.

mob
var
saved_x
saved_y
saved_z

Write(savefile/F)
saved_x = x
saved_y = y
saved_z = z
..() //store variables
Read(savefile/F)
..() //restore variables
Move(locate(saved_x,saved_y,saved_z))
All we did was copy the player's coordinates into non-temporary variables before calling the default Write proc. Then, when loading the player, we simply moved back to the same spot.

You are probably thinking it would be more efficient if you could just write the coordinates to the file yourself rather than making dummy variables for the purpose. You are right. Working directly with savefiles is next.

3. The Structure of a Save File

The interior of a savefile is structured like a tree. Each node in the tree has a data buffer and may also contain additional sub-nodes. (A buffer is simply a sequence of stored values.) Since the file-system is such a familiar analogy, we shall call the nodes directories and the top node in the savefile shall be called the root directory. (Yes, savefiles are upside-down trees just like the DM object tree.)

Do not be confused between savefile directories and file-system directories. The savefile itself is just a single file. The savefile object simply presents the contents of that file in the form of a hierarchical directory structure. To distinguish between the two, one calls these data directories as opposed to file directories.

The purpose of all this is to allow you to organize information in a logical format. For example, you could have a master savefile with a directory for each player. Or different aspects of the world could be stored in different directories. The freedom to organize things in such a manner is not merely esthetic; it determines what data can be saved and retrieved as a unit. If everything were simply written in one continuous stream of data, the entire file would have to be read from the beginning in order to find, say, the information about a particular player.

3.1 cd variable

The savefile variable cd contains the path of the current data directory within the savefile. These paths are like DM object type paths except they are stored in a text string. The root is a slash "/", which also serves as the delimiter between directory names like this: "/dir1/dir2".

By assigning cd, the current directory can be changed. An absolute path may be specified (beginning with the root "/") or a path relative to the current directory may be used. The special path name ".." may be used to represent the parent of the current directory. No matter how you assign it, the new value of cd will always be the resulting absolute path.

It is possible to change to a directory that does not exist. If data is written to it, the new directory will be automatically created in the savefile. Valid directory names are the same as node names in DM code; letters, digits, and the underscore may be used to any length. They are case sensitive, so "KingDan" is different from "kingdan".

3.2 dir variable

The dir savefile variable is a list of directory names inside the current directory. An entire directory can be deleted by removing it from this list. It is also commonly used to test for the existence of a directory.

In the following example, a check is made when players log in to see if they already exist in a master savefile.

var/savefile/SaveFile = new("players.sav")

mob/Login()
SaveFile.cd = "/" //make sure we are at the root
if(ckey in SaveFile.dir)
SaveFile.cd = ckey
Read(SaveFile)
usr << "Welcome back, [name]!"
else
usr << "Welcome, [name]!"
..()
Note that we are using ckey as the unique data directory name for each player.

4. Data Buffers

Information in a savefile is stored in buffers. These are sequential records of one or more values. The term sequential or serial implies that values which are written in a particular order must be read back in that same order. This is different from random access data which may be retrieved in any order (like items in a DM list object). In a savefile, the directories are randomly accessed and the data within buffers is sequentially accessed. The two methods each serve their own purpose.

4.1 File Input/Output

The << operator places a value in a buffer and the >> operator reads a value from a buffer. If no directory is specified, the buffer in the current directory is used.

savefile << value
savefile << variable
Or
savefile [}"directory" << value
savefile [}"directory" >> variable
When a directory is not specified, the current position in the buffer is accessed. This position always starts at the beginning when the directory is entered (by setting cd). Subsequent values are appended to the buffer as they are written.

When a directory is specified, the value written replaces any previous contents of the given directory. This is equivalent to entering the directory, writing to it, returning to the previous directory, and restoring the position in the buffer. An absolute or relative path may be used to specify the location of the directory.

We can now return to the problem of saving the player's coordinates. Before, this had to be done using dummy variables. Now it can be done directly.

mob/Write(savefile/F)
//store coordinates
F << x
F << y
F << z
//store variables
..()
mob/Read(savefile/F)
var {saved_x; saved_y; saved_z}
//load coordinates
F >> saved_x
F >> saved_y
F >> saved_z
//restore variables
..()
//restore coordinates
Move(locate(saved_x,saved_y,saved_z))
Ok, so we still had to define some dummy variables, but at least they are hidden in the Read proc rather than cluttering up the object definition. That saves memory and, as it happens, it also saves space in the savefile, because we chose to write the coordinates sequentially into the same buffer rather than into three separately named buffers.

4.2 Stored Variables

The way variables are normally stored is to make a separate directory for each one with the same name as the variable. If you wanted complete control over the savefile format, you could do that yourself with something like the following code:

mob/Write(savefile/F)
F["name"] << name
F["gender"] << gender
F["icon"] << icon
mob/Read(savefile/F)
F["name"] >> name
F["gender"] >> gender
F["icon"] >> icon
The advantage of having each variable in its own directory is flexibility. In the future, you could add or remove variables and old savefiles would still work. That saves you the headache of trying to maintain backwards compatibility in a single sequential buffer as items come and go.

On the other hand, values which will always be grouped together can be more efficiently saved in a single buffer. That is how we handled the three map coordinates in the previous example. There is less overhead, the fewer times you have to change directories.

Figure 12.23: Sample Savefile Format

Output Code Contents of players.sav
mob/Write(savefile/F)
F["name"] << "Dan"
F["gender"] << "male"
F["icon"] << 'peasant.dmi'
/dan
name "Dan"
gender "male"
icon 'peasant.dmi'
mob/Write(savefile/F)
F << "Dan"
F << "male"
F << 'peasant.dmi'
/dan
"Dan",
"male",
'peasant.dmi'

4.3 Data Directories

The notation introduced above for reading and writing to a specified directory works in general--not just on the left-hand side of the input/output operators << and >>. The syntax is a savefile followed by a directory path in square brackets. This accesses the first value in the specified buffer and may be used in any expression, including assignments. It therefore behaves like a sort of permanent variable, which is a convenient device.

4.4 Saving Objects

You may be wondering why we didn't use the << operator to write players to a savefile. Instead we have been calling the Write proc. With minor modifications, we could have used <<. In fact, << internally calls Write when saving an object, so it would almost be the same.

The difference between directly calling Write verses using << to save an object is in how the object will be recreated. When >> is used, a new object is returned. Obviously when you call the object's Read proc directly, the object must already exist.

The << operator works by first recording the type of the object being saved. It then moves into a fresh temporary directory and calls the object's Write proc. When this returns, the entire contents of the temporary directory (sub-directories and all) are packed up and written as a single value after the object type information which was already saved. This allows you to treat an object like any other value when it is written to a serial buffer. (Programmers refer to this process as serialization of the object.)

The >> operator simply reverses the sequence of operations. It reads the stored type, creates a new object, and calls its Read proc.

The terminology used to distinguish between the two different cases is a property save verses an instance save. When you call Write directly, you are doing a property save, because you are only saving the properties of the object. When you instead use <<, you are doing an instance save, because you are saving a full instance of the object (along with its properties). You must use the same method for restoring an object that you used to save it.

4.4.1 Saving a Player Instance

Up until now, we assumed that the mob created for a player logging in was the same type as the mob which was last saved. If your world allows players to inhabit other types of mobs, however, this assumption could be wrong. In that case, you would want to create a new mob from the savefile rather than using the default world.mob. In other words, you would want to save the mob instance rather than just saving its properties.

client/New()
var/savefile/F = new(ckey)
F >> usr
return ..()
client/Del()
var/savefile/F = new(ckey)
F << usr
del(usr)
In this case, we handled saving in client.New rather than mob.Login. There are two reasons. One is that we want to create the mob from the savefile before the default client.New creates one for us. The second reason is that presumably this world allows the player to switch from one mob to another. If that is the case, we can't use Login as an indicator that the player is signing into the game; it might just be a movement from one mob to another.

In all the examples up to this point, we have been using server-side savefiles. That just means they are stored on the server's filesystem. It is also possible to store savefiles on the player's computer. These are called client-side savefiles.

5. The Key Save File

The player's key may have a savefile attached to it. This file can be obtained by calling client.Import(). It returns a savefile reference or null if there is none.

To copy a savefile back to the key, client.Export() is used. Note that if changes are made to an imported file, these are not saved to the key unless that file is exported. That is because behind the scenes, Import and Export upload and download the savefile from the client to the server. The imported file on the server side is merely a temporary copy of the key's savefile.

client.Import (Object)
Object is the optional object to read.
Returns copy of key savefile.
client.Export (File)
File is the savefile to export.
If no file is specified in the call to Export(), the key's savefile is deleted. If a value other than a savefile is given, this is written into a temporary savefile and exported to the key. Similarly, an object may be passed to Import() and it will be automatically read from the file.

5.1 Client-Side Saving

One reason to use client-side saving is if the player will be connecting to a group of worlds which all share the same savefile format. That way, changes made to the player's mob in one world would be automatically transferred to any of the other worlds the player accesses.

The following example outlines how player information can be saved in the key file.

mob
Login()
var/savefile/F = client.Import()
if(F) Read(F) //restore properties
..()
proc/SavePlayer()
var/savefile/F = new()
Write(F) //save properties
client.Export(F)
Like the previous server-side example, the player is loaded in Login(). However, it is not a good idea to save the player in Logout() as we did before, because in this case the client is needed in order to export the file. By the time Logout() is called, the player may have already disconnected.

It is therefore necessary to save the player before logging out. The SavePlayer() proc in this example was defined for that purpose, but it needs to be called from somewhere else in the code. You could do that every time a change is made or whenever the player requests it. Another method is to require the player to exit properly from the world in order to be saved rather than simply disconnecting without warning.

6. Transmission Between Worlds

Client-side savefiles are one method for transferring player information between worlds. This is best used when the player is free to randomly connect to any one of the worlds. It is also suited for situations in which the contents of the player savefile are not sensitive--that is, the player can't cheat by modifying or backing up the file.

There are times when a client-side savefile is not appropriate. In that case, savefiles can be transferred directly between worlds without using the player's key as an intermediary. That gives you assured control over the contents of the file.

6.1 Export, Import, and Topic

The procedures for transferring files between worlds are similar to the ones for manipulating the player's key file. The procedure world.Export() can be used to send a file. This causes a message to be sent to the remote world, which handles it in the world.Topic() procedure. If the remote world expects and is willing to receive a savefile, it calls world.Import() to download it. These three procedures were already introduced in section 8.2.4.

There are a few differences between the world Import and Export procs and the corresponding client procs. In the case of exporting from one world to another, the remote world's network address and import topic must be specified in addition to the file being sent.

On the remote end, world.Import() is used to receive the file, just as with a key file. However, this results in the savefile being downloaded into the world's resource cache. A reference to this cache file is returned instead of automatically creating a savefile object as client.Import() does. That allows for the transferral of other types of files. The cache reference can be easily opened as a temporary savefile by simply specifying it in place of the name of the file to open.

6.2 A Sample Player Transferal System

The following code demonstrates how player savefiles can be transferred directly from one world to another. The destination world is imagined here to be running at the address dm.edu on port 2001. This address could be any other hard-coded value, or even a variable set at run-time.

mob/proc/GotoMars()
var/savefile/F = new()
F << src
if(!world.Export("dm.edu:2001#player",F))
usr << "Mars is not correctly aligned at the moment."
return
usr << link("dm.edu:2001")

world/Topic(T)
if(T == "player")
//download and open savefile
var/savefile/F = new(Import())

//load mob
var/mob/M
F >> M

return 1
The GotoMars() proc sends a player to the remote world. It simply writes the player to a file and then sends it. In this example we happen to be using a full object save on the mob rather than a mere property save, but it could be done another way. Note how the return value of Export() is checked to ensure that the remote world is alive and well before sending the player along.

The code for world.Topic() actually belongs in the code for the remote world, but here we assume that both worlds have the same player import facilities. The "player" topic causes a savefile to be imported and read. The mob which is created as a result is ready and waiting when the player connects to the new world. One could instead store the savefile and load it when the player arrives.

6.3 Security

You may not want just anyone sending savefiles to your worlds. There are a couple strategies to limit access. One is to keep the import topic a secret. Another would be to put a password in the savefile itself.

Access can also be limited to specific network addresses. The address of the sending world is passed as an argument to world.Topic. This could be compared to a list of permitted addresses and permission granted accordingly.

To get such a system working, it might be useful to use something like the following code to test the sending and receiving of messages. It simply allows you to specify the address and topic you wish to send and displays the result.

mob/verb/export(Addr as text)
usr << "Export([Addr]) == \..."
usr << world.Export(Addr)

world/Topic(T,Addr)
world.log << "Topic([T]) from address [Addr]."
return 1

6.4 Sharing Object Types

Care must be taken when transferring objects from one world to another that the same type of object is defined in both places. If an object type that was saved in a file does not exist when it is loaded, it cannot be created and null will be returned instead.

The most fool-proof strategy is to compile every world with the same code base in which all the transferable object types are defined. Techniques for splitting the code in large projects into multiple files is a topic that will be discussed in chapter 19 and is a useful method of re-using code for this purpose.

7. Advanced Savefile Mechanics

Most of the time, the default reading and writing behavior works and you don't have to think too hard about how it works. I am going to tell you how it works anyway. If you don't want to know, please shut your eyes while reading this section.

Those of you who still have your eyes open get to learn about a few powerful elements of the language. You will probably never use them, but powerful knowledge should rarely be used anyway. (Knowing how to build an H-bomb is a good example.) It just helps put everything else in perspective.

I will start by showing you how you could soft-code the default save routines. Then I will explain how it works. Then I will explain how it really works. Then the rest of you can open your eyes again.

mob/Write(savefile/F)
var/V
for(V in vars)
if(issaved(vars[V]))
if(initial(vars[V]) == vars[V])
F.dir.Remove(V) //just in case
else F[V] << vars[V] //write variable
mob/Read(savefile/F)
var/V
for(V in vars)
if(issaved(vars[V]))
if(V in F.dir)
F[V] >> vars[V] //read variable
This same code would, of course, be defined for object types other than mob as well. It depends only on the existence of a special variable named vars, which happens to be defined for all object types. It is a list of the variables belonging to an object.

You can access and loop through vars like any other list. The only special behavior is that when you index it with the name of a variable, you get, not the name, but the value of the variable. So whenever you see vars[V] in the above code, it is accessing the value of the mob's variable whose name is stored in V. Note that this value can even be modified. It is just as if you were accessing the variable directly.

The next thing you must be wondering about in the above code is issaved(). That is where we check to see if the variable being considered is temporary. If the variable is marked global, const, or tmp, it is not saved to the file because the issaved instruction returns 0.

Finally, before saving the variable, we check if it has changed. We do that by using the initial() instruction to get the original compile-time value of the variable. Only if the variable has changed is it saved. That saves space, but it also makes the savefile more adaptable. In the future, you may wish to change the default value of a variable. When you recompile your world, existing savefiles will automatically use the new value if the variable still had its initial value when saved.

7.1 Duplicate References

If you think for a while (maybe a long while) about the above saving scheme, you will come to the conclusion that it is subtly flawed. Fortunately, the savefile is smarter than you think.

Each variable is written to its own directory using the << operator, be it a number, text string, object, or list of objects. That means, of course, that objects are written in full. If we are saving a player who has a bunch of items in the contents list, an instance of each of these is written to the file.

But what happens if two variables refer to the same object? If these were each written as a separate instance, the savefile would contain two independent instances of the same object. When loading this information, a new object would be created for each reference to the original one. That could lead to all sorts of subtle problems. Ick.

Fortunately, the savefile can detect this case and handle it correctly. During any single savefile operation, such as writing an object, a special de-duplication mode is entered. In this mode, the first occurrence of an object is written in full but subsequent occurrences are written as a reference to the first one. This will even handle recursive references that would otherwise cause an infinite loop.

De-duplication mode lasts for the duration of the first operation that initiated it. For example, if you write a mob to the savefile, de-duplication mode will extend through the writing of each mob variable, which might in turn include writing entire objects belonging to the mob. All duplicate references within the single top-most operation will be detected.

The only rule you must abide by is to make sure things are always read back in the same order they were written. That ensures that the first occurrence of an object (which is saved in full) will be restored before any references to it are encountered.

Commanding officer

2019-05-11T11:01:53Z

Krendelec:

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

|-
![[File:Generic_Torch_CO.png]]<br>[[Commanding officer|Командующий офицер]]
|'''Доступ:''' Полный.
'''Подчинение:''' Sol Central Government.

'''Обязанности:''' Командовать "Факелом". Быть авторитетом для пассажиров и экипажа. Отдавать приказы другим командующим. Контролировать работоспособность отделов.

'''Guides:''' [[Sol Central Government Law]]
!Очень сложно

|-
|}

'''Командующий Офицер''', также иногда именуемый как "'''KO'''", или, как многие привыкли – просто Капитан, несёт ответственность за сам "Факел" и всё, что находится на нём. Именно он будет регулярно следить за тем, чтобы экипаж, отсеки и их главы работали продуктивно и без непредвиденных сбоев. Он настолько авторитетен, что имеет доступ даже в самый темный закоулок этого корабля. Его мужеству и отваге нет предела. Единственная неотрицательная роль в игре, которой ПОЛНОСТЬЮ подчиняется [[AI|Искусственный Интеллект]].

Эта роль настолько важна и мощна, что рекомендуется лишь самым опытным игрокам.

==Командование==
[[file:CO_commanding.png|thumb|right|Под "командованием" нередко имеется в виду простое просиживание штанов на мостике.]]
Руководить и направлять в нужную сторону – основная работа Командующего Офицера, которую он исполняет на мостике. Он имеет полную власть над главами, способен повышать и понижать код тревоги, контактировать с экспедициями и запускать преждевременный гиперпрыжок. Как вы уже поняли, он является главой над прочими главами, и на его плечах висит руководство над ними, контроль их работы над отсеками и сотрудниками. Либо, если в раунде присутствует Заместитель Командующего, то он просто может скинуть все свои обязанности на него. КО почти не предстаёт лично перед глазами экипажа, и все проблемы он решает при помощи коммуникации с прочими людьми, сидя в своём мягеньком кресле.

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

===Тревога и [[Standard Operating Procedure|СОП]]===
Командующий Офицер вправе изменять ''уровень тревоги'' с помощью предоставленной ему Командной Консоли (Находится на мостике, прямо перед Вашим креслом). Каждый уровень устанавливает новые требования к персоналу, расширяет власть Охранного отсека и повествует о повышении угрозы для корабля в целом.

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

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

==Снаряжение==
Являясь абсолютной властью на этом корабле, Офицер имеет целую кучу специального оборудования, созданного для него одного: начиная с бронированной одежды и оружия, заканчивая персональным ручным телепортером, карточки с полным доступом и диском ядерной аутентификации (с прилегающим к нему устройству, позволяющее обнаружить диск в случае утраты). Эти предметы имеют очень высокую цену, и очевидно, что их захочет заполучить даже самый непутевый пассажир. Следовательно, ходить направо и налево тряся своим энергетическим пистолетом будет весьма опасно, как и для самого КО, так и для того, кто захочет этот пистолет отобрать.

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

==Абсолютная власть==
За КО почти всегда стоит последнее слово за всем прошедшим на станции. Если он говорит кому-то делать что-то, то этот кто-то обязан пойти и выполнить приказ, иначе хуже будет только ему. Единственное, что будет препятствовать его правлению – [[Sol Central Government Law|Закон СолГова]], из которого даже он не является исключением и может быть в любой момент быть арестован силами правосудия.

Ситуаций, где приказ Главнокомандующего может быть оспорен очень мало. КО должен понимать, что делает, и делать это, согласно закону, в котором на первом месте стоит сохранение жизни экипажа и предотвращение получения урона кораблём. Как пример: приказ, отданный Главному Инженеру пойти с КО в бар и напиться в стельку может быть не только проигнорирован, но и спровоцировать экипаж выступить против Главнокомандующего, так как в приказе нет логики. Да, у него есть безграничная власть, но это повод быть тираном или идиотом.

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

В случае возможности захвата "Факела" враждебными силами, КО может получить доступ в отсек с последним защитным механизмом – устройству самоуничтожения, которое встроено в убежище. Оно уничтожит сам корабль и всех существ на борту, однако активировать его нелегко. Требуется диск ядерной аутентификации и код, сообщенный экспедиционной командой. Само существование этого устройства является секретной информацией, обычно доступной только для КО и остальной части глав.

==Советы==

* По правилам ролевого отыгрыша, КО имеет больше всего свободы. Он должен знать основу работы каждого отсека корабля и кто им руководит. Да, вы обязаны представлять себе работу каждого отсека, но эти знания являются поверхностными, и вы не сможете подменить хирурга, если он уснул на медицинской кушетке, делать бомбы вместо ученых и так далее. И запомните: Командующий Офицер не должен доверять кому попало.
* Как правило, вы не являетесь офицером. Вы не должны лезть в малозначимые криминальные дела до тех пор, пока вас об этом не попросят.
** Даже не вздумайте бегать по кораблю таская с собой оружие. Либо потом не нойте, что у вас его отобрали.
* Не думайте, что если вы заняли самую значимую позицию в игре, то вы можете делать то, что вздумается. Рамки дозволенного должны присутствовать даже у самого авторитетного человека на борту.
* Используйте по максимуму своего заместителя. Он обеспечит вам поддержку, и руководить "Факелом" станет куда проще.

{{TorchJobMenu}}
[[Category:Torch]]
[[Category:Jobs]]

Guide to Ship

2019-05-11T11:01:18Z

Krendelec:

{{Архивировано}}

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

== Космическая Физика ==

В отличии от большинства штук, что тебе доводилось использовать - у корабля есть "инерция". Проще говоря, после изменения скорости, корабль некоторое время все еще будет двигаться в заданном направлении.
Хорошая новость - так ты сможешь сэкономить топливо.
Плохая новость - инерция может запросто закинуть тебя в пояс астероидов.
Запомни простое правило: '''без ускорения не изменишь направление'''.

== Штурвал (helm) ==
''Как мне управлять этой штукой?''

Используй '''штурвальную (helm)''' консоль, интерфейс которой состоит из следующих элементов.

=== Статус ===

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

Прими как аксиому следующее: '''движение по диагонали - наглая ложь'''.
Поэтому когда ты движешься, скажем, на 45 градусов, на самом деле ты сначала смещаешься влево, а затем вверх, но не налево-вверх. Это важно помнить, когда будешь пытаться проскочить близ астероидов или вроде того.

=== Интерфейс движения ===

Существует три способа управлять кораблем:
* Используй кнопки на консоли. Нажимая их в любом из направлений, ты будешь задавать кораблю ускорение в соответствующую сторону. Центральная кнопка нужна для торможения.
* Используй прямое управления. Нажимая эту кнопку, ты получаешь доступ к карте вокруг корабля и можешь контролировать корабль подобно персонажу. Кнопка "away" нужна для выхода из этого режима.
* Используй автопилот. Просто установи место назначения и включи его. Помни, что автопилот не заботится об эффективном энергопотреблении и стремится развить максимальную скорость, что может привести к неприятным последствиям.

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

=== Интерфейс навигации ===

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

== Сенсоры ==

''Куда мы движемся?''

Одна из классных вещей в "Сенсорной консоли" это "Sensor Suite", позволяющий считывать показания аппаратуры. Сенсорная панель довольно проста - погляди на карту в режиме "прямого управления" кораблем и настрой мощность сенсоров. Высокая активность этой аппаратуры быстро нагревает ее, так что не задерживайся в режиме мощного сканирования.

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

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

== Двигатель ==

''Но КАК мы движемся?''

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

Корабли могут использовать любые типы '''двигателей''', но наиболее популярным является газовый тип, который выбрасывает газ в противоположную сторону от направления движения. Для таких двигателей особенно важны два фактора - '''давление''' газа и '''масса''' газа в используемой газовой смеси.
Изменяя последний параметр, можно менять тип топлива: от тяжелого CO2 до легкого Гидрогена.
Исходя из этого, обычно наиболее простой путь для получения увеличенного давления - нагрев газа любым доступным путем. Сами двигатели также требуют энергию для работы. Каждый запуск использует приблизительно 20 КВ энергии.

Все эти параметры отображаются в '''Engine Console''', которая поделена на две вкладки.
В первой можно установить ограничение скорости для двигателей и включать/выключать их как вместе, так и раздельно.
Вторая позволит вам оценить статус двигателей, приблизительный расход топлива или причину неполадки в движках.

== Случайные события ==

''Боже, мы все умрем!''

Помимо всяческих секторов полных сокровищ, на общей карте можно обнаружить и странные штуки, которые блокируют зону досягаемости ваших сканеров.
Эти зоны называются '''Эвентами''' и пока вы находитесь в них, они диктуют вам свои правила.
Существует три основных типа случайных событий:
* '''Астероидное поле''' - суть ровно в том, о чем говорит название. Кругом астероиды и они летят прямо в вас. Их количество определяется скоростью корабля: недвижимый корабль обычно имеет дело лишь с 25% от обычного количества, 60% - при скорости ниже 0.3, 100% вплоть до 3 и с трех - 200%.
* '''Облако пыли''' - небольшие камни, которые стремятся растереть все на своем пути. Ваша скорость не имеет значения.
* '''Электрический шторм''' - пока вы в зоне этого эвента с электроникой корабля может творится что угодно. Особенно неприятно то, что здесь корабельные щиты никак не помогут.

== Блуждания ==

''Дрейфуя сквозь ад...''

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

Это может быть несколько пугающим путешествием, поскольку космос чертовски, чертовски огромен.
Покуда вы продолжаете свое путешествие, вы перемещаетесь между случайными z-уровнями на тех же координатах, откуда и начали свое путешествие.
Хорошая новость - если корабль остался неподвижным, то вы его найдете.
Плохая новость - если корабль улетел, то вы живой труп.

[[Category:SEV Torch]]
[[Category:Guides]]

New California Republic

2019-05-11T11:00:32Z

Krendelec:

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

|-
![[Файл:NKR_trooper.png]]<br>Новая Калифорнийская Республика
|'''Доступ:''' Куда доберётесь, База НКР
'''Подчинение:''' В зависимости от должности
!Средне

|-
|}

===Добро пожаловать в Пустоши!===

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

===Чем занимаются===
В зависимости от выбранной должности у вас могут быть разные занятия:
*'''Trooper (Солдат)''' - вы простой солдат, основная боевая единица НКР. Вы подчиняетесь Сержанту НКР.
*'''Veteran Ranger (Рейнджер-ветеран)''' - вы элитный боец НКР, вы лучший из лучших(''если это не так, не берите его''). Отличаетесь от других солдат гораздо более хорошей экипировкой и боевой подготовкой. Как правило действуете один, но бывают и исключения. Вы подчиняетесь Главному Штабу НКР, однако считаетесь с просьбами Генерала.
*'''Sergeant NCR (Сержант НКР)''' - сержанты это командиры отрядов простых солдат.Как правило вооружены лучшее, чем простые солдаты. Подчиняетесь Генералу.
*'''General (Генерал)'''- вы самый главный, именно вы решаете на какие задания отправить свои отряды и политику поведения в целом. Вам подчиняются все выше перечисленные, кроме Рейнджера, однако скорее всего он выполнит вашу просьбу(''если вы будете достаточно вежливы'').

===Чем не занимаются===
*Солдаты НКР не ходят по одному(исключение - Рейнджер), хотя в крайних случаях это возможно.
*НКР нейтрально относятся ко всем кроме Анклава, Братства Стали, Легиона и Рейдеров - однако устраивать ''молчаливые'' войны при первом виде врага не стоит.
*Вы не убийцы, а миротворцы, не трясите оружием зря.

===Важно!===
*Не забывайте, что НКР это военизированная фракция, со строгой иерархией и подчинением старшим по рангу.

===Общие рекомендации===
*Постарайтесь добраться до базы и объединиться с другими членами НКР.
*Вы можете делать аванпосты, чтобы контролировать важные объекты.
*На вашей базе есть много полезных вещей, хорошенько её обследуйте(очень, очень хорошенько, вдруг там есть какой то секрет?).
*Не ходите по одиночке,если вы конечно не Рейнджер.
*Не стоит пренебрегать сбором хлама, ведь вы можете обменять его у жителей на полезные вещи.
{{Шаблон:Fallout}}