Guide to Contribution: различия между версиями

Материал из Chaotic Onyx
Перейти к навигацииПерейти к поиску
м (5)
 
(не показано 7 промежуточных версий 6 участников)
Строка 1: Строка 1:
 
{{Заготовка}}
 
{{Заготовка}}
  
Что может быть интереснее того, чтобы играть в компьютерную игру? Правильно! Дрочить потные яйца! Хотите быть чемпионом? Сосите хуй.
+
Что может быть интереснее того, чтобы играть в компьютерную игру? Правильно! Менять мир игры и наблюдать, как глупые ньюфаги превозмогают. Хотите знать, как делают игры? Отлично, в этой статье мы и разберем все, что касается разработки билда Space Station 13, помимо самого написания кода.
  
= Зачем все это? Давайте просто писать в ротик Эпикусу блять сука на нахуй черти ебанные я пошёл хавать блядь охуенный хавчик! =
+
= Зачем все это? Давайте просто писать код! =
  
[[Файл:doyouwannabeaprogrammer.jpeg|200px|thumb|right|tl;dr суть статьи вкратце.]]
+
Не спеши пока ничего делать, для начала давай немного разберемся с теорией - все довольно просто, но это решит множество твоих проблем в будущем.  
  
Не спеши пока ничего делать, для начала давай немного разберемся с теорией - все довольно просто, но это не решит множество твоих проблем в будущем. Ты вырастешь, тебе нужно будет жилье, тебе нужна будет работа, тебе нужна будет девушка, тебе нужны будут деньги. Вот это будут действительно проблемы для тебя в будущем, а не какие-то там попытки спиздить бумбокс, склеить его костылями и пытаться продавать его за 600 рублей. Надо ли тебе это? Решай сам.
+
Наверное, ты уже видел один из [https://github.com/Rampoch/Chaotic-Onyx реальных билдов Space Station 13]? При достаточной внимательности, ты даже мог там разглядеть кнопку "Download ZIP". Давай пойдем по наивному пути и попробуем его скачать.
  
Наверное, ты уже видел один из [https://www.youtube.com/watch?v=oHg5SJYRHA0 реальных билдов Space Station 13]? При достаточной внимательности, ты даже мог там разглядеть кнопку "Go Fuck Yourself". Давай пойдем по наивному пути и попробуем его скачать.
+
Скачав и разархивировав архив, ты получил папку с полной копией того билда, который, скорее всего, прямо сейчас работает на сервере. Что мы видим в типичной папочке с билдом? Рассмотрим на примере сборки Baystation12:
  
Скачав и разархивировав архив, ты получил винлокер, скрытый в архиве. Что мы видим в типичной папочке с билдом? Надпись "Эпикус желает твои сочные соски, скинь их или мы будем заставлять играть тебя на нашем проекте Chaotic Popyx".
+
* '''название_билда.dme''' (Dream Maker Environment) - самый главный файл исходных кодов игры. Он хранит в себе список всех файлов с кодом, которые будут скомпилированы в дистрибутив игры. Все просто: добавили новый файл - добавили его путь в .dme; не хотите чтобы какой-то файл компилировался в сборку - удалите его отсюда. Это файл можно открыть бьондовским Dream Maker'ом, в котором можно добавлять/исключать файлы из сборки с помощью дерева файлов в его интерфейсе слева.
 +
* '''название_билда.dmb''' (Dream Maker Build) - скомпилированная версия сборки. Dream Maker собирает все исходные файлы с кодом, которые указаны в .dme файле вместе, компилирует их и отдает этот .dmb файл, который можно загрузить в Dream Daemon, чтобы запустить сервер.
 +
* '''code, icons, interface, fonts, maps, sound''' - обычные папки, в которых, внезапно, лежат исходные коды, иконки, файлы интерфейса, шрифты, карты и звуки соответственно. Здесь все легко.
 +
* '''config''' - важная папка с конфигами сервера. Перед первым запуском локальной сборки, убедись что скопировал файлы из подпапки examples в корень папки config и все правильно настроил.
 +
* '''html''' - различные html-формы, которые используются для описания расположения элементов интерфейса во всяких консолях, панельках, а также вспомогательные элементы.
 +
* '''tools''' - скрипты и программы, в основном, на нормальных языках программирования, которые могут понадобиться при разработке и запуске сервера. Например, здесь может быть программа, которая переводит музыку в формате midi в ноты для пианино.
 +
* '''sql''' - конфигурационные файлы для запуска Базы Данных под сервер.
  
* '''Эпикус.dme''' (Gay Master Gandonio) - самый главный педераст сервера. Он хранит в себе куча вонючего кала, которые изредка вылезают из своей норки во время очередного написания кода. Все просто: добавили нос Шепарду - получился развал Анимуса. Это позволит вам следить за историей русского сегмента SS13.
+
Хорошо, мы разобрались с тем, что тут лежит. Допустим, ты нашел какой-то файлик с кодом и решил в нем что-то поменять, скажем, урон у дубинки СБ - одно число. Скомпилировал билд, запустил у себя локальную версию - все хорошо. Далее ты хочешь сделать так, чтобы эти изменения попали на сервер - как ты их будешь передавать?
* '''Ramp0ch.dumb''' (Ex-Gayest Gay In The Fucking Gayish World) - сжатый комок баребуха. Ramp0ch собирает все члены игроков Cahotic Oynx, которые указаны в его сладкой попке вместе, массирует их и отдает эти обработанные пенисы Эпикусу, который трансформируется в гавно.
 
* '''cock, icunts, facefuck, fonks, mops, asspound''' - обычные попки, в которых, внезапно, лежат скелеты хуйцов, покрытые украинскими флагами. Чтобы разузнать предысторию этого события, необходимо провести расследование в нашем шоу Голос Дети.
 
* '''cockfig''' - важная папка с конфигами сервера. Перед первым запуском локальной сборки, убедись что насрал в туалет и сдернул за собой человеческие отходы. Иначе дерьмо вонять будет, и жить в этом помещении будет невозможно.
 
* '''huetml''' - те немногие, что выебали американцев в жопу.
 
* '''sos''' - скрипты и программы, в основном, на ненормальных языках программирования, которые не понадобятся при разработке и запуске сервера. Например, здесь может быть программа, которая переводит бабки кэш мани money real дерьмо йоу это реальны  разъёб
 
* '''sooqalar''' - конфигурационные файлы для запуска Базы Данных под сервер.
 
  
Значит, Японцы, перед второй мировой войной, а именно - адмирал Ямамото, задумали расхуячить американский флот на Гавайских островах, то что потом вошло в историю как катастрофа на Перл Харбор.
+
Можно, конечно, взять этот файлик, отправить владельцу сборки на GitHub'e, чтобы он полностью заменил файл. Также, например, можно попросить его заменить все самому в конкретной строчке, но чем больше будет количество изменений и людей, которые их вносят - тем сложнее будет со всем эти справляться. Тут приходит на помощь Git.
  
Слушай и запоминай. Командующий налетом на Перл Харбор был адмирал Нагума. Средний офицер, на самом деле, но исполнительный. Исполнительный, безусловно. Професионал. Но без фантазии. У японцев на самом деле людей с фантазией было немного.  
+
Тут важно отличать две вещи - Git и GitHub. Первое - это обычная маленькая программа для сохранения истории изменений кода, а второе - это интернет-портал, который позволяет хранить у себя твои исходные коды.
  
Дерьмо, блядь, на палочке. Ничего не знаешь, ничего не можешь, что ты вообще, блядь, в армии делаешь, а?
+
Что делает Git? По сути, он сравнивает исходную версию всех файлов до изменений с тем, что получилось в итоге и создает список изменений - diff (от слова difference). Далее он помогает зафиксировать эти изменения и сохранить со своим описанием в специальном архиве изменений, в подпапке .git. Зафиксировав изменения, их можно будет откатывать, восстанавливать, сливать и делать с ними прочие непотребства, не беспокоясь о том, что твоя работа куда-то пропадет - вся история изменений останется в архиве и ее всегда можно будет восстановить. Более того, любой другой человек может прийти и посмотреть всю историю работы со сборкой. И это еще не все, git позволяет синхронизировать твой локальный архив изменений с другими архивами, которые расположены у других разработчиков на компьютерах, или, например, на GitHub'e.
  
Какие самолеты были на этих авианосцах? Самолеты какие были? Какой самый известный самолет на тихоокеанском театре военных действий? Сколько истребителей, сука? Сколько, блядь, истребителей, скотина блядь?!
+
То есть, с помощью Git, ты можешь зафиксировать свое изменений кода и создать, так называемый, commit - один набор изменений файлов. Этот коммит сохранится в историю в твоем локальном архиве, как последнее изменение сборки, после чего можно будет синхронизировать свой архив с архивом игрового сервера на GitHub. Как только архив изменений на GitHub обновится - изменения применятся к сборке сервера и, после компиляции и обновления сервера педалями, дубинка станет наносить новый урон.
  
Седьмого декабря, 1941 года. японский флот в составе шести авианосцев, "Акаги", "Кага", "Хирю", "Сорю", "Секаку" и "Дзуйкаку", а так же двух линейных кораблей "Хиэй Кирисима" появились на траверсе острова Оаху, Гавайских островов.  
+
Да, это чуть-чуть сложнее, чем просто скинуть файл с изменениями, но чем больше файлов было изменено и чем больше разработчиков одновременно работает над кодом сборки - тем важнее становится использование Git.
  
Первое ударное воздушное соединение насчитывало 50 истребителей "Зеро", 40 торпедоносцев и 81 пикирующий бомбардировщик. В итоге этого налета четыре линейных корабля американского флота было потоплено.  
+
Таким образом, репозиторий (так называют те самые архивы с историей изменений) - это набор коммитов (наборы изменений), которые совершались последовательно друг за другом. В любой момент можно получить в своей папке состояние всех файлов после применения какого-то коммита: просто переключаемся на соответствующий коммит из истории. Последовательность коммитов одного за другим образует ветку. Веток в одном репозитории может быть много. То есть начиная с какого-то коммита, мы можем создать новую ветку и добавлять туда новые коммиты, независимо от старой последовательности. Закончив работу над какой-то задачей, можно объединить эту ветку с исходной, в результате чего, все изменения окажутся в одной ветке.
  
Какие корабли? Какие корабли?! Аризона, Вест-Вирджиния, Оклахома и Мэриленд. Это знать надо! Если ты учился в шестом училище, это классика, блядь! Сколько истребителей, сука? Сколько, блядь, истребителей, скотина блядь?!
+
Удобство веток в том, что два человека могут заниматься разными вещами в сборке, не мешая свои изменения. Даже если они затронут одни и те же файлы, проблемы возникнут только при мерже этих двух веток в одну - надо будет внимательно разруливать их изменения, выбирая какие оставить в финальной версии.
  
Сейчас наша армия ориентируется именно на этих офицеров. По крайней мере это те немногие, что выебли американцев в жопу. И это знать надо! Дерьмо собачье. А, блядь, нахуй! Ну-ка иди сюда, сука, блядь! Дерьмо собачье, блядь! А, блядь!
+
Кстати, когда ты создаешь новый репозиторий, например, локально, на компьютере - ты автоматически создаешь новую ветку, локальную. Когда ты будешь заливать свои изменения из этой локальной ветки назад на сервер - ты будешь, как бы, объединять свою локальную ветку с исходной веткой на сервере.
  
Так, я сейчас чай принесу, мы с тобой продолжим, продолжим-продолжим... Ты, хоть и полный идиот, но... Я думаю, что эта информация будет тебе полезна. По крайней мере ближайший час.
+
= Берем в руки Git и готовимся к поступлению в Академию Магов =
  
= Берем в руки хуй и готовимся к поступлению в Академию Порядочных Парней =
+
== Установка и настройка ==
  
==  Отсос и манипуляция членом ==
+
Git - обычная программа, которую можно поставить, точно так же, как какой-нибудь Byond, подключить к скачанному репозиторию и работать с ним. Проблема в том, что это программа хоть и мощная, но консольная, из-за чего ей неудобно пользоваться под Windows. К счастью, есть огромное количество программ-оберток, которые дают обычный интерфейс с кнопочками, управляя консольной программой за тебя. Вообще говоря, все эти программы просто дают интерфейс и пишут некие команды в консоль, причем эти команды всегда будут одни и те же, независимо от самой программы.
  
Для начала практики минета необходимо определится с позой в которой оба партнера будут чувствовать себя наиболее комфортно.  
+
Для совсем новичков, остановимся на примере SourceTree - это самый простой способ сделать свой первый коммит. Скачивать репозиторий zip-архивом не нужно, все скачается автоматически.
  
Существует множество поз для орального секса, от самых простых и до самых изощренных, так что поле для экспериментов тут довольно широко.  
+
Итак, заходим на официальный сайт [SourceTree https://www.sourcetreeapp.com/], качаем версию под свою ОС и устанавливаем. Сам Git входит в сборку SourceTree и будет установлен автоматически - отдельно его ставить не нужно. После установки, нужно будет зарегистрироваться у разработчика, на сайте Attlasian. Этот аккаунт может тебе еще пригодиться, если ты будешь работать с репозиторием, расположенным на BitBucket, а не на GitHib'е.
  
Основной принцип при выборе позы в которой вы будете делать минет партнеру это ее удобство как для вас, так и для партнера с точки зрения не только комфорта но и чувственного наслаждения от сексуальной близости.
+
Запустив SourceTree, щелкаем Файл/Клонировать. Указываем сайт репозитория (например, https://github.com/Rampoch/Chaotic-Onyx), путь, где мы будем хранить репозиторий локально и название для отображения в интерфейсе программы. Жмем кнопку клонировать. В выбранной папочке создастся новый репозиторий - точная копия репозитория, который хранится на сервере GitHub. Теперь мы можем тут что-то поменять и залить изменения на оригинальный репозиторий сервера.
  
Хорошенько оближите головку члена, чтобы она стала немного влажной, так она будет лучше скользить у вас в губах. Начните с легкого и неглубокого минета, достаточным для начала будет брать в ротик лишь головку пениса.
+
== Интерфейс SourceTree ==
 
 
Однако не стоит заигрываться с ней потому что от перевозбуждения ваш партнер может преждевременно ощутить оргазм так и не познав всего спектра наслаждения от минета. Да и получить в ротик теплой струйкой спермы в самом начале игры тоже будет не очень интересно.
 
 
 
Чередуйте игривые ласки и поцелуи с легким сосанием члена дабы партнер немного остывал от стимуляции пениса. Немного пососав член переключитесь на мошонку или поцелуи живота партнера, поцелуи в губы после члена также будет довольно волнителен для вас и вашего партнера.
 
 
 
Если вы владеете практикой глубокого минета, то пробуйте глубоко глотать его доводя партнера до вершин наслаждения.
 
 
 
== Ебались и не только кстати) ^_^ ==
 
  
 
[[Файл:SourceTree.png|thumb|right|Интерфейс SourceTree]]
 
[[Файл:SourceTree.png|thumb|right|Интерфейс SourceTree]]
Строка 63: Строка 55:
 
Что у нас есть в интерфейсе SourceTree?
 
Что у нас есть в интерфейсе SourceTree?
  
* '''Закладки.''' Каждая закладка - отдельная история. То есть все, что мы видим на этой закладке - касается кончика пениса.
+
* '''Вкладки.''' Каждая вкладка - отдельный локальный репозиторий. То есть все, что мы видим на этой вкладке - касается конкретного репозитория, который мы создали.
* '''Нижние закладки''' Это разные закладки рангом пониже. Полные лохи - их лишь используют как тряпку ебаную
+
* '''Нижние вкладки.''' Это разные панели с полезной информацией о состоянии репозитория.
** '''Невероятный отсос''' - стимуляция пеениса языком с последующим заглотом
+
** '''Состояние файлов''' - все изменения, которые были внесены в файлы, которые содержаться в репозитории, но еще не зафиксированы. Если залезть сейчас внутрь папки репозитория и поменять любой файл, то изменения появятся в этой закладке.
** '''>Эпикус'' - Чувак час страдал, выдумывал, что бы такого написать. Я за минуту откатил 2 кликами и забанил. Э - эффективность.
+
** '''Журнал/История''' - история изменений, все коммиты по всем отслеживаемым веткам. На скриншоте видно очень много веток - потому что это Baystation12, там каждый разработчик создает свою ветку, а потом они мержатся в основную. Каждая строчка - это отдельный коммит, со своим автором, номером, датой и описанием. Выбрав конкретный коммит, снизу можно посмотреть список измененных файлов и конкретные изменения каждого файла. Также там есть полное описание коммита, которое могло не поместится в строчке выше и дополнительная информация.
* '''Леваки.''' - пидорасы все
+
* '''Левая панель.''' Содержит список всех веток в репозитории, внешних веток, меток и спрятанных изменений. Ветки - это просто наборы коммитов, разные ветки истории изменений, по сути. То есть начиная с некоторого состояния репозитория, например, 12 марта, два разработчика начали параллельно вносить какие-то изменения. Удобно, если каждый будет создавать новые коммиты в своей отдельной ветке, тогда их изменения не будут перемешиваться, а когда они закончат - можно будет удобно слить их в одну основную ветку.
** '''Заебать''' - В жопу ебать таким образом что аж заебался
+
* '''Верхняя панель.''' Главные кнопки для работы с репозиторием.
** '''Марксизм''' - философское, экономическое и политическое учение, основанное Анальным Карлом и Фридрихом Энгейсом. Существуют различные интерпретации учения Маркса, связанные с различными политическими партиями и движениями в общественной мысли и политической практике. Политический марксизм является одним из вариантов социализма наряду с левым анархизмом
+
** '''Закоммитить''' - создать новый коммит. Эта кнопка соберет все изменения, которые были внесены, спросит описание изменений и создаст новый коммит, который сразу окажется в локальном репозитории. Пока коммит хранится только локально у тебя, можно его изменять и даже удалять, но как только ты его отправишь в основной репозиторий на сервере GitHub, удалить его уже будет нельзя. Так что не стоит сразу пушить все свои коммиты на сервер, 10 раз подумай, не сохранил ли ты случайно какой-нибудь мусор, или, хуже, личную информацию, которую не хотел бы раскрывать.
** '''Получить''' - по ебалу
+
** '''Отправить''' - отправить все коммиты, которые были сохранены локально в удаленный репозиторий, например, в репозиторий сервера на GitHub. В диалоге можно будет выбрать какую конкретно ветку отправить в какую ветку в каком удаленном репозитории, если у тебя там много вариантов.
** '''Извлечь''' - пули с пятой точки
+
** '''Получить''' - скачать все коммиты с удаленного сервера к себе в локальный репозиторий. Коммиты переезжают из конкретной удаленной ветки в конкретную локальную ветку. Да, автоматически ничего обновляться не будет, так что перед началом работы над новым коммитом, лучше скачай все изменения из репозитория сервера этой кнопкой.
** '''Ветка''' - деревянное
+
** '''Извлечь''' - получает только информацию о том, есть ли на сервере новые коммиты. То есть ты увидишь новые коммиты в удаленных ветках, но локальные ветки останутся без изменений.
** '''Слияние''' - рампоча и эпикуса приведёт к созданию монстра ебаного
+
** '''Ветка''' - создать новую ветку, начиная с текущего коммита.
** '''Спрятать хуй''' - Основное свойство и главный геймплей прекрасной игры Space Station 13 Космическая станция 13 КС13 СС13. Позволяет высовывать или заправить хуй в штаны себе обратно, чтобы не вызвать подозрений.
+
** '''Слияние''' - сливаем две ветки в одну. Все коммиты из обеих веток будут выстроены в истории по времени, а в конце будет добавлен новый мерж-коммит, в котором можно будет разрешить все конфликты, если они будут. Конфликт - это когда в разных ветках трогали одни и те же строчки одних и тех же файлов. Чтобы решить такой конфликт - надо выбрать какие варианты должны войти в итоговый результат.
** '''анал''' - порвался ещё в самом начале
+
** '''Спрятать''' - прячем все текущие изменения под каким-то названием, с возможностью их потом вытащить. Иногда бывает удобнее, чем плодить ветки.
 +
** '''Терминал''' - откроет консольное окно, куда можно будет вбивать сырые команды Git. Иногда бывает полезно, если ты хочешь сделать какую-то сложную штуку, которую либо не завезли в интерфейс, либо ты не знаешь где ее искать.
  
== Твой первый секс ==
+
== Твой первый коммит ==
  
 
[[Файл:SourceTree_Commit.png|thumb|right|Интерфейс создания нового коммита в SourceTree]]
 
[[Файл:SourceTree_Commit.png|thumb|right|Интерфейс создания нового коммита в SourceTree]]
Строка 87: Строка 80:
 
Как только мы определились с теми изменениями, которые нужно включить в коммит, пишем в окне снизу описание коммита и нажимаем закоммитить. Коммит сразу окажется в истории локальной ветки коммитов, чтобы отправить его в удаленный репозиторий сервера, нужно нажать сверху кнопку "Отправить" и выбрать конкретную ветку, в которую нужно запихать наши новые коммиты.
 
Как только мы определились с теми изменениями, которые нужно включить в коммит, пишем в окне снизу описание коммита и нажимаем закоммитить. Коммит сразу окажется в истории локальной ветки коммитов, чтобы отправить его в удаленный репозиторий сервера, нужно нажать сверху кнопку "Отправить" и выбрать конкретную ветку, в которую нужно запихать наши новые коммиты.
  
Поздравляю, вы лишились своей анальной девственности. Продолжайте в том же духе, и вы сможете стать как наш лидер, любящий очень большие носы ммммммммммммм бляяяяя
+
=== Создаем Pull Request на GitHub ===
 
 
=== Создаем Pull Anal на GitHub ===
 
 
 
Отправить свою сперму напрямую в чью-то маму в ShitHub'e тебе, скорее всего, не дадут. Для внесения своих изменений в чужие мамы, на ShitHub придумали способ тянуть за анал, необходимо купить такую возможность всего за 1000 рублей в месяц.
 
 
 
Чтобы клонировать репозиторий к себе на аккаунт, нужно нажать кнопку Fork в интерфейсе страницы репозитория на ShitHub'e. Как я буду вилкой-то чистить? Чё, совсем мудак, что ли? Покажи мне, как я буду чистить-то, ёпта!
 
 
 
Ну и наконец, чтобы потянуть за анус, идем в основной репозиторий сервера, нажимаем на кнопку дранус. Выбираем основную вену в руке, колим содержимое шприца, указываем соответствующую ветку в твоем внешнем репозитории на аккаунте, ловим кайфарик.
 
  
= Фокусы любого анального волшебника =
+
Отправить свои коммиты напрямую в репозиторий сервера на GitHub'e тебе, скорее всего, не дадут. Для внесения своих изменений в чужие репозитории, на GitHub придумали Pull Request'ы, запросы на забор кода из твоего репозитория. Чтобы создать такой запрос, тебе нужно (1) клонировать исходный репозиторий, создав новую копию под своим аккаунтом на GitHub; (2) внести коммиты с локального репозитория у тебя на компьютере, в этот новый репозиторий на GitHub, под твоим аккаунтом; (3) сделать запрос на забор кода из твоего репозитория GitHub в репозиторий сервера.
  
== Высовываем хрустальный шар из своего гудка ==
+
Чтобы клонировать репозиторий к себе на аккаунт, нужно нажать кнопку Fork в интерфейсе страницы репозитория на GitHub'e. У тебя в профиле появится новый репозиторий, полная копия основного, в который ты сможешь заливать свои изменения. Обрати внимание, что в него не будут автоматически добавляться изменения из основного репозитория - нужно будет обновлять руками. Чтобы добавить коммиты, которые уже есть в локальной истории у тебя на компьютере, в этот репозиторий, нужно в SourceTree добавить новый внешний репозиторий и пушить в одну из его веток. Лучше для каждого нового набора изменений создавать на внешнем репозитории новую ветку, чтобы не мешать тематически разные изменения и создавать для них отдельные Pull Request'ы.
  
Очень сука часто нахуй волшебники пидорские ебутся в свои волосатые епта жопы блять, который охуеть будет нихуево макс иди нахуй понятным любому нахуй, кто сука на него посмотрит. Простой ебаный способ блядь делать нахуй правильные PR'ы епта:
+
Ну и наконец, чтобы сделать сам Pull Request, идем в основной репозиторий сервера, нажимаем соответствующую кнопку. Выбираем основную ветку репозитория сервера (в нее будем заливать изменения), а для ветки из которой нужно забрать коммиты, указываем соответствующую ветку в твоем внешнем репозитории на аккаунте.
  
# Перед блядь тем нахуй как сука ты пидор начал нахуй что-либо сука делать, обнови нахуй основную ветку анального локального терминального репозитория, забрав сука все нахуй новые блядь коммиты блядь из ебаного основного сука репозитория нахуй сервера блять на GitHub'е епта. Сразу блядь отправь нахуй все эти новые коммиты блять в свой внешний репозиторий ебаный на ShitHub епта (ты же сука еще помнишь нахуй, что он сука не обновляется автоматически нихуя?).
+
= Фокусы любого приличного волшебника =
# Создай новую ветку, в верхушке ЗАЛУПЫ. Лучше назови ее Gaysex, чтобы было понятно, чем ты собираешься в ней заниматься. Все свои коммиты можешь в мусорку выкинуть лоооооол
 
# Если ты кончил без презерватива, тебе пиздец нахуй! Если забивать на этот пункт, то придётся платить алименты до конца своих дней.
 
# Если у тебя очень много коммитов или у них не достаточно понятное описание - мягко сядь на туалет и начни срать жёстко. Сразу после похода в туалет вся твоя размазня на стенках туалета останутся проиндексированными, но говно будет сброшено. Сдергиваешь туалет и стираешь за собой ёршиком так чисти чисти нахуй
 
# Отправляй свои изменения прямо в пизду и нахуй через кишечник рот желудок легкие Афганистан
 
# ты сука
 
# Если все хорошо, то твой член просто примут и все, но так бывает очень редко. Скорее всего, у принимающего в жоп будут какие-то вопросы по поводу того, почему твой хуй внезапно оказался в говне, тогда после того, как ты его помоешь, желательно '''мягко'''устроить пробитие, сказать что-нибудь от души, а потом перезалить мочевой пузырь, чтобы обновить cumмиты на ShitHub'e и обоссаться на месте. Цыгане что-ли? Ненавижу блядь цыган.
 
  
= БЫДЛО ЁБАННОЕ блЯ ПИСАЛО ЭТУ СТАТЬЮ=
+
== Создаем чистые Pull Request'ы ==
  
ребята вы жрали?
+
Очень часто у новичков возникают проблемы с тем, чтобы сделать чистый Pull Request, который будет максимально понятным любому, кто на него посмотрит. Простой способ делать правильные PR'ы:
  
= статья воняет =
+
# Перед тем как ты начал что-либо делать, обнови основную ветку локального репозитория, забрав все новые коммиты из основного репозитория сервера на GitHub'е. Сразу отправь все эти новые коммиты в свой внешний репозиторий на GitHub (ты же еще помнишь, что он не обновляется автоматически?).
 +
# Создай новую ветку, в верхушке основной ветки локального репозитория. Лучше назови ее как-нибудь так, чтобы было понятно, чем ты собираешься в ней заниматься. Все свои коммиты на эту тему пиши прямо в эту ветку.
 +
# Если ты закончил и внес все изменения, какие хотел, обязательно скомпилируй билд и проверь на локальном сервере, что все работает так, как должно! Если забивать на этот пункт, то твои ПРы любой адекватный админ будет принимать очень и очень долго.
 +
# Если у тебя очень много коммитов или у них не достаточно понятное описание - мягко откати все свои коммиты до последнего не-твоего коммита (ПКМ по первому коммиту сверху, который сделал не ты; "сбросить состояние текущей ветку к выбранному коммиту"; режим выбираем мягкий, чтобы сохранить все изменения, сбросив лишь фиксации). Сразу после отката все твои изменения останутся проиндексированными в списке изменений, но коммиты будут сброшены. Создаешь новый красивый коммит с хорошим описанием.
 +
# Отправляй свои изменения в свой внешний репозиторий, в ветку с таким же названием. Уже в этой ветке откатить ничего не получится, потому что она хранится на GitHub. Но на самом деле, это временная ветка, которая нужна лишь для того, чтобы прикрепить ее к Pull Request'у. Так как все твои изменения всегда будут у тебя на компьютере локально, ты всегда можешь удалить эту ветку и создать заново, чтобы сделать историю коммитов чистой. В этой ветке, желательно, всегда иметь хорошие коммиты, с нормальным описанием, которые логически разбиты на этапы внесения изменений.
 +
# Создаем сам Pull Request, привязывая к нему нашу ветку с идеальными описаниями коммитов. В описании обязательно стоит описать все изменения, которые были проделаны в ветке, даже если все подробно описано в самих коммитах - отсюда потом удобно будет скопировать изменения, например, в внутриигровой changelog.
 +
# Если все хорошо, то твой PR просто примут и все, но так бывает очень редко. Скорее всего, у принимающего будут какие-то вопросы и пожелания по изменениям, тогда после того, как ты внесешь изменения, желательно '''мягко''' отменить последний коммит локально, пересоздать его с дополнительными изменениями, а потом перезалить внешнюю ветку, чтобы обновить коммиты на GitHub'e. PR должен автоматически подобрать новую ветку (ну или там можно руками выбрать новую ветку), так что его пересоздавать не нужно!
  
= ДЕРЖИ РОВНО ФРАЕР =
+
= Сервер - это легко =
 +
Для запуска сервера вам потребуется сделать следующее:<br><br>
 +
1. Любым способом получить необходимую версию сборки.<br>
 +
* Например из [https://github.com/ChaoticOnyx/OnyxBay репозитория OnyxBay]  <br><br>
 +
2. Из папки config/example скопировать всё в папку config.<br><br>
 +
3. Добавить себя в администратора сервера.
 +
* Для этого нужно в файл admins.txt добавить строку:
 +
  [ваш сикей] - Host
 +
* Важно соблюдать регистр роли; регистр сикея не важен. Это выдаст вам роль Host - она дает полные права администратора(+EVERYTHING). Все возможные можно посмотреть в admin_ranks.txt
 +
4. Затем необходимо скомпилировать и запустить сервер.
 +
* Для этого необходимо открыть .dme файл в корневой папке сборки. У вас должен открыться Dream Maker.
 +
* Во вкладке Build нажать Compile and Host. Можно просто Host, если скомпилировали все ранее.
 +
* После минуты-полторы вы в нижнем окне увидите строку "файл.dmb - 0 errors, 0 warnings (время компиляции)", а также у вас откроется Dream Daemon. Если же появились ошибки или предупреждения, но вы ничего не изменяли в исходном коде - что-то пошло не так.
 +
* В Dream Daemon можете выбрать порт сервера, если порт (стандартный 80) будет занят каким-либо приложением или другим сервером, при запуске Dream Maker выдаст ошибку "Dream Daemon FAILED to open port [порт]!" Порт должен быть менее 65535.
 +
* Нажмите зеленую кнопку GO
 +
5. После того как вы запустили сервер, вероятно вы захотите на него зайти.
 +
* Нажмите желтую кнопку Join (над кнопкой STOP. Если успешно запустился сервер, GO заменится на STOP). Входит под аккаунтом, который авторизован у вас сейчас в Byond.
 +
* Либо в браузере введите в адресную строку "byond://localhost:[порт сервера]".
 +
{{GuideMenu}}

Текущая версия от 18:52, 26 сентября 2021

В разработке…


Jobeng.png
Данная статья помечена как неоконченная. Это означает, что статья находится на доработке, поэтому может быть неверна или неактуальна.

Вы можете помочь проекту Onyxyeye@256x256.png Onyx и сообществу Animus-logo.png SS13 в целом — зайдите на наш Bus Mainframes.gif Портал сообщества.


Что может быть интереснее того, чтобы играть в компьютерную игру? Правильно! Менять мир игры и наблюдать, как глупые ньюфаги превозмогают. Хотите знать, как делают игры? Отлично, в этой статье мы и разберем все, что касается разработки билда Space Station 13, помимо самого написания кода.

Зачем все это? Давайте просто писать код!

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

Наверное, ты уже видел один из реальных билдов Space Station 13? При достаточной внимательности, ты даже мог там разглядеть кнопку "Download ZIP". Давай пойдем по наивному пути и попробуем его скачать.

Скачав и разархивировав архив, ты получил папку с полной копией того билда, который, скорее всего, прямо сейчас работает на сервере. Что мы видим в типичной папочке с билдом? Рассмотрим на примере сборки Baystation12:

  • название_билда.dme (Dream Maker Environment) - самый главный файл исходных кодов игры. Он хранит в себе список всех файлов с кодом, которые будут скомпилированы в дистрибутив игры. Все просто: добавили новый файл - добавили его путь в .dme; не хотите чтобы какой-то файл компилировался в сборку - удалите его отсюда. Это файл можно открыть бьондовским Dream Maker'ом, в котором можно добавлять/исключать файлы из сборки с помощью дерева файлов в его интерфейсе слева.
  • название_билда.dmb (Dream Maker Build) - скомпилированная версия сборки. Dream Maker собирает все исходные файлы с кодом, которые указаны в .dme файле вместе, компилирует их и отдает этот .dmb файл, который можно загрузить в Dream Daemon, чтобы запустить сервер.
  • code, icons, interface, fonts, maps, sound - обычные папки, в которых, внезапно, лежат исходные коды, иконки, файлы интерфейса, шрифты, карты и звуки соответственно. Здесь все легко.
  • config - важная папка с конфигами сервера. Перед первым запуском локальной сборки, убедись что скопировал файлы из подпапки examples в корень папки config и все правильно настроил.
  • html - различные html-формы, которые используются для описания расположения элементов интерфейса во всяких консолях, панельках, а также вспомогательные элементы.
  • tools - скрипты и программы, в основном, на нормальных языках программирования, которые могут понадобиться при разработке и запуске сервера. Например, здесь может быть программа, которая переводит музыку в формате midi в ноты для пианино.
  • sql - конфигурационные файлы для запуска Базы Данных под сервер.

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

Можно, конечно, взять этот файлик, отправить владельцу сборки на GitHub'e, чтобы он полностью заменил файл. Также, например, можно попросить его заменить все самому в конкретной строчке, но чем больше будет количество изменений и людей, которые их вносят - тем сложнее будет со всем эти справляться. Тут приходит на помощь Git.

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

Что делает Git? По сути, он сравнивает исходную версию всех файлов до изменений с тем, что получилось в итоге и создает список изменений - diff (от слова difference). Далее он помогает зафиксировать эти изменения и сохранить со своим описанием в специальном архиве изменений, в подпапке .git. Зафиксировав изменения, их можно будет откатывать, восстанавливать, сливать и делать с ними прочие непотребства, не беспокоясь о том, что твоя работа куда-то пропадет - вся история изменений останется в архиве и ее всегда можно будет восстановить. Более того, любой другой человек может прийти и посмотреть всю историю работы со сборкой. И это еще не все, git позволяет синхронизировать твой локальный архив изменений с другими архивами, которые расположены у других разработчиков на компьютерах, или, например, на GitHub'e.

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

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

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

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

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

Берем в руки Git и готовимся к поступлению в Академию Магов

Установка и настройка

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

Для совсем новичков, остановимся на примере SourceTree - это самый простой способ сделать свой первый коммит. Скачивать репозиторий zip-архивом не нужно, все скачается автоматически.

Итак, заходим на официальный сайт [SourceTree https://www.sourcetreeapp.com/], качаем версию под свою ОС и устанавливаем. Сам Git входит в сборку SourceTree и будет установлен автоматически - отдельно его ставить не нужно. После установки, нужно будет зарегистрироваться у разработчика, на сайте Attlasian. Этот аккаунт может тебе еще пригодиться, если ты будешь работать с репозиторием, расположенным на BitBucket, а не на GitHib'е.

Запустив SourceTree, щелкаем Файл/Клонировать. Указываем сайт репозитория (например, https://github.com/Rampoch/Chaotic-Onyx), путь, где мы будем хранить репозиторий локально и название для отображения в интерфейсе программы. Жмем кнопку клонировать. В выбранной папочке создастся новый репозиторий - точная копия репозитория, который хранится на сервере GitHub. Теперь мы можем тут что-то поменять и залить изменения на оригинальный репозиторий сервера.

Интерфейс SourceTree

Интерфейс SourceTree

Что у нас есть в интерфейсе SourceTree?

  • Вкладки. Каждая вкладка - отдельный локальный репозиторий. То есть все, что мы видим на этой вкладке - касается конкретного репозитория, который мы создали.
  • Нижние вкладки. Это разные панели с полезной информацией о состоянии репозитория.
    • Состояние файлов - все изменения, которые были внесены в файлы, которые содержаться в репозитории, но еще не зафиксированы. Если залезть сейчас внутрь папки репозитория и поменять любой файл, то изменения появятся в этой закладке.
    • Журнал/История - история изменений, все коммиты по всем отслеживаемым веткам. На скриншоте видно очень много веток - потому что это Baystation12, там каждый разработчик создает свою ветку, а потом они мержатся в основную. Каждая строчка - это отдельный коммит, со своим автором, номером, датой и описанием. Выбрав конкретный коммит, снизу можно посмотреть список измененных файлов и конкретные изменения каждого файла. Также там есть полное описание коммита, которое могло не поместится в строчке выше и дополнительная информация.
  • Левая панель. Содержит список всех веток в репозитории, внешних веток, меток и спрятанных изменений. Ветки - это просто наборы коммитов, разные ветки истории изменений, по сути. То есть начиная с некоторого состояния репозитория, например, 12 марта, два разработчика начали параллельно вносить какие-то изменения. Удобно, если каждый будет создавать новые коммиты в своей отдельной ветке, тогда их изменения не будут перемешиваться, а когда они закончат - можно будет удобно слить их в одну основную ветку.
  • Верхняя панель. Главные кнопки для работы с репозиторием.
    • Закоммитить - создать новый коммит. Эта кнопка соберет все изменения, которые были внесены, спросит описание изменений и создаст новый коммит, который сразу окажется в локальном репозитории. Пока коммит хранится только локально у тебя, можно его изменять и даже удалять, но как только ты его отправишь в основной репозиторий на сервере GitHub, удалить его уже будет нельзя. Так что не стоит сразу пушить все свои коммиты на сервер, 10 раз подумай, не сохранил ли ты случайно какой-нибудь мусор, или, хуже, личную информацию, которую не хотел бы раскрывать.
    • Отправить - отправить все коммиты, которые были сохранены локально в удаленный репозиторий, например, в репозиторий сервера на GitHub. В диалоге можно будет выбрать какую конкретно ветку отправить в какую ветку в каком удаленном репозитории, если у тебя там много вариантов.
    • Получить - скачать все коммиты с удаленного сервера к себе в локальный репозиторий. Коммиты переезжают из конкретной удаленной ветки в конкретную локальную ветку. Да, автоматически ничего обновляться не будет, так что перед началом работы над новым коммитом, лучше скачай все изменения из репозитория сервера этой кнопкой.
    • Извлечь - получает только информацию о том, есть ли на сервере новые коммиты. То есть ты увидишь новые коммиты в удаленных ветках, но локальные ветки останутся без изменений.
    • Ветка - создать новую ветку, начиная с текущего коммита.
    • Слияние - сливаем две ветки в одну. Все коммиты из обеих веток будут выстроены в истории по времени, а в конце будет добавлен новый мерж-коммит, в котором можно будет разрешить все конфликты, если они будут. Конфликт - это когда в разных ветках трогали одни и те же строчки одних и тех же файлов. Чтобы решить такой конфликт - надо выбрать какие варианты должны войти в итоговый результат.
    • Спрятать - прячем все текущие изменения под каким-то названием, с возможностью их потом вытащить. Иногда бывает удобнее, чем плодить ветки.
    • Терминал - откроет консольное окно, куда можно будет вбивать сырые команды Git. Иногда бывает полезно, если ты хочешь сделать какую-то сложную штуку, которую либо не завезли в интерфейс, либо ты не знаешь где ее искать.

Твой первый коммит

Интерфейс создания нового коммита в SourceTree

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

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

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

Создаем Pull Request на GitHub

Отправить свои коммиты напрямую в репозиторий сервера на GitHub'e тебе, скорее всего, не дадут. Для внесения своих изменений в чужие репозитории, на GitHub придумали Pull Request'ы, запросы на забор кода из твоего репозитория. Чтобы создать такой запрос, тебе нужно (1) клонировать исходный репозиторий, создав новую копию под своим аккаунтом на GitHub; (2) внести коммиты с локального репозитория у тебя на компьютере, в этот новый репозиторий на GitHub, под твоим аккаунтом; (3) сделать запрос на забор кода из твоего репозитория GitHub в репозиторий сервера.

Чтобы клонировать репозиторий к себе на аккаунт, нужно нажать кнопку Fork в интерфейсе страницы репозитория на GitHub'e. У тебя в профиле появится новый репозиторий, полная копия основного, в который ты сможешь заливать свои изменения. Обрати внимание, что в него не будут автоматически добавляться изменения из основного репозитория - нужно будет обновлять руками. Чтобы добавить коммиты, которые уже есть в локальной истории у тебя на компьютере, в этот репозиторий, нужно в SourceTree добавить новый внешний репозиторий и пушить в одну из его веток. Лучше для каждого нового набора изменений создавать на внешнем репозитории новую ветку, чтобы не мешать тематически разные изменения и создавать для них отдельные Pull Request'ы.

Ну и наконец, чтобы сделать сам Pull Request, идем в основной репозиторий сервера, нажимаем соответствующую кнопку. Выбираем основную ветку репозитория сервера (в нее будем заливать изменения), а для ветки из которой нужно забрать коммиты, указываем соответствующую ветку в твоем внешнем репозитории на аккаунте.

Фокусы любого приличного волшебника

Создаем чистые Pull Request'ы

Очень часто у новичков возникают проблемы с тем, чтобы сделать чистый Pull Request, который будет максимально понятным любому, кто на него посмотрит. Простой способ делать правильные PR'ы:

  1. Перед тем как ты начал что-либо делать, обнови основную ветку локального репозитория, забрав все новые коммиты из основного репозитория сервера на GitHub'е. Сразу отправь все эти новые коммиты в свой внешний репозиторий на GitHub (ты же еще помнишь, что он не обновляется автоматически?).
  2. Создай новую ветку, в верхушке основной ветки локального репозитория. Лучше назови ее как-нибудь так, чтобы было понятно, чем ты собираешься в ней заниматься. Все свои коммиты на эту тему пиши прямо в эту ветку.
  3. Если ты закончил и внес все изменения, какие хотел, обязательно скомпилируй билд и проверь на локальном сервере, что все работает так, как должно! Если забивать на этот пункт, то твои ПРы любой адекватный админ будет принимать очень и очень долго.
  4. Если у тебя очень много коммитов или у них не достаточно понятное описание - мягко откати все свои коммиты до последнего не-твоего коммита (ПКМ по первому коммиту сверху, который сделал не ты; "сбросить состояние текущей ветку к выбранному коммиту"; режим выбираем мягкий, чтобы сохранить все изменения, сбросив лишь фиксации). Сразу после отката все твои изменения останутся проиндексированными в списке изменений, но коммиты будут сброшены. Создаешь новый красивый коммит с хорошим описанием.
  5. Отправляй свои изменения в свой внешний репозиторий, в ветку с таким же названием. Уже в этой ветке откатить ничего не получится, потому что она хранится на GitHub. Но на самом деле, это временная ветка, которая нужна лишь для того, чтобы прикрепить ее к Pull Request'у. Так как все твои изменения всегда будут у тебя на компьютере локально, ты всегда можешь удалить эту ветку и создать заново, чтобы сделать историю коммитов чистой. В этой ветке, желательно, всегда иметь хорошие коммиты, с нормальным описанием, которые логически разбиты на этапы внесения изменений.
  6. Создаем сам Pull Request, привязывая к нему нашу ветку с идеальными описаниями коммитов. В описании обязательно стоит описать все изменения, которые были проделаны в ветке, даже если все подробно описано в самих коммитах - отсюда потом удобно будет скопировать изменения, например, в внутриигровой changelog.
  7. Если все хорошо, то твой PR просто примут и все, но так бывает очень редко. Скорее всего, у принимающего будут какие-то вопросы и пожелания по изменениям, тогда после того, как ты внесешь изменения, желательно мягко отменить последний коммит локально, пересоздать его с дополнительными изменениями, а потом перезалить внешнюю ветку, чтобы обновить коммиты на GitHub'e. PR должен автоматически подобрать новую ветку (ну или там можно руками выбрать новую ветку), так что его пересоздавать не нужно!

Сервер - это легко

Для запуска сервера вам потребуется сделать следующее:

1. Любым способом получить необходимую версию сборки.

2. Из папки config/example скопировать всё в папку config.

3. Добавить себя в администратора сервера.

  • Для этого нужно в файл admins.txt добавить строку:
 [ваш сикей] - Host
  • Важно соблюдать регистр роли; регистр сикея не важен. Это выдаст вам роль Host - она дает полные права администратора(+EVERYTHING). Все возможные можно посмотреть в admin_ranks.txt

4. Затем необходимо скомпилировать и запустить сервер.

  • Для этого необходимо открыть .dme файл в корневой папке сборки. У вас должен открыться Dream Maker.
  • Во вкладке Build нажать Compile and Host. Можно просто Host, если скомпилировали все ранее.
  • После минуты-полторы вы в нижнем окне увидите строку "файл.dmb - 0 errors, 0 warnings (время компиляции)", а также у вас откроется Dream Daemon. Если же появились ошибки или предупреждения, но вы ничего не изменяли в исходном коде - что-то пошло не так.
  • В Dream Daemon можете выбрать порт сервера, если порт (стандартный 80) будет занят каким-либо приложением или другим сервером, при запуске Dream Maker выдаст ошибку "Dream Daemon FAILED to open port [порт]!" Порт должен быть менее 65535.
  • Нажмите зеленую кнопку GO

5. После того как вы запустили сервер, вероятно вы захотите на него зайти.

  • Нажмите желтую кнопку Join (над кнопкой STOP. Если успешно запустился сервер, GO заменится на STOP). Входит под аккаунтом, который авторизован у вас сейчас в Byond.
  • Либо в браузере введите в адресную строку "byond://localhost:[порт сервера]".

НачинающимИнтересноеПрофессииРуководства

Ролевая игра

Руководство по отыгрышу ролиРуководство по отыгрышу роли для продвинутыхРуководство по заполнению окна Relations и созданию связейПсихология убийстваПсихологические заболеванияЗнания персонажа

Режимы игры

Агент СиндикатаОперативник СиндикатаСнаряжение СиндикатаРеволюцияКультВампирВолшебникГенокрадКосмический Ниндзя

Инженерное дело

Руководство инженераРуководство атмосферного техникаИскусство взломаКонструированиеТехнологии связиПродвинутое конструирование

Медицинские руководства

Медицина ХирургияВирусология ХимияМедицинский справочникРадиация

Научно-исследовательские проекты

ИсследованияРабота с газамиКсенобиологияКсеноархеологияРобототехникаКсеноботаникаИнтегрированные схемы

Служба безопасности

Руководство службы безопасностиСвод космических законовОружие

Прочее

Как грамотно писатьПравильная работа с документамиОфициальные бланки документов НТКак готовить еду ОниксаРуководство по напиткам

Руководства для желающих помочь

Учимся программировать в BYONDРисуем спрайты