Aex
-
Публикации
36 -
Зарегистрирован
-
Посещение
-
Победитель дней
6
Сообщения, опубликованные пользователем Aex
-
-
Сложнее ещё потому что не всегда можно использовать альтернативные крафты. Например, всякая там мебель BibleCraft. И не у всех альтернативных крафтов такое удобное совпадение имени. Ну и надо создавать какие-то алиасы, потому что пользователь не видит у себя на экране minecraft:planks, он видит у себя Oak Wood Planks. Это конечно решаемо, но усложняет жизнь.
В общем, в дальнейшем надо в любом случае думать и дорабатывать этот момент.
-
Давненько не было автокрафтеров тут. Может, кому-то пригодится моя версия.
Предназначена в первую очередь для крафта всяких часто необходимых мелочей со сложными крафтами (например, компоненты OpenComputers) из примитивных исходных ресурсов (например, процессор из слитков золота и железа, тростника и редстоуна), которые у пользователя отнимают кучу времени на поиск всех транзисторов и крафт недостающих.
Рассчитана на использовании робота и двух сундуков, один из которых - основное хранилище (может быть покрупнее), а другой предназначен для резервирования компонентов при крафте.
Ссылка:
Необходимая конфигурация робота:
- Проверялась работа на компонентах (корпус, память, процессор, жёсткий диск) второго уровня.
- Screen, Keyboard
- Crafting Upgrade
- Inventory Upgrade и Inventory Controller
- Видеокарта и экран первого уровня
Для дальнейших потенциальных расширений:
- Беспроводная карта
- Upgrade Container
Конфигурация установки:
- Перед роботом - контейнер ресурсов (любой из возможных инвентарей достаточного размера)
- Под роботом - контейнер-буфер (можно обычный сундук)
- Рядом желательно поставить зарядник
Возможности:
- Рекурсивный крафт сложных рецептов. Ресурсов расходуется, по результатам практических испытаний, ровно столько, сколько необходимо.
- Каталог рецептов для крафта, разбитый на страницы по 10 предметов для более удобного пролистывания на маленьком экране робота.
- Портативность - требуется только робот, два сундука и исходные ресурсы. Желателен также источник энергии
- Сообщения о том, каких конкретно исходных ресурсов не хватает для крафта (исходные ресурсы - те, для которых не найдено рецепта)
- Процесс крафта подробно отображается на экране, чтоб за ним было не так скучно и одиноко следить (см. недостатки)
- Об окончании крафта робот сообщит приветливым писком. Равно как и о неудаче.
Недостатки и известные недочёты:
- Скорость..... Крафт занимает значительное время. Например, изготовление процессора 3го уровня из примитивных ресурсов (тростник, красный камень, алмазы, дерево для резаков, слитки золота, железа) занимает около 5 минут. Стоит отметить что количество изготавливаемых предметов не сильно влияет на время (2 процессора, скорее всего, будут делаться те же примерно 5 минут).
- Не умеет работать с альтернативными ресурсами. Возможно, когда-нибудь исправлю.
- Не умеет работать с инструментами (имеются ввиду многоразовые, как молот ИК2). Возможно, так же когда-нибудь исправлю.
- Не умеет работать с количествами предметов более стака, а также не гарантируется корректная работа с предметами, не складывающимися в стак. Постараюсь исправить в ближайшее время.
- Нет поиска по именам компонентов (то есть, либо задаёте название компонента целиком, либо задаёте крафт через каталог). Когда-нибудь поправлю
- Проверок на наличие контейнеров не делается, так как программа писалась "для себя" и находится в разработке. В дальнейшем будут введены. Также не везде гарантируется наличие защиты от "Количество предметов: Привет".
Особенности:
- Шаблоны содержатся в одном файле, что облегчает переносимость, но приносит определённые неудобства всвязи с размерами файла (12 строк на предмет). Буду думать, как лучше сделать (разбить на разные файлы?). Файл имеющихся шаблонов могу выложить при необходимости (на разных сборках эти шаблоны могут отличаться)
Дальнейшее развитие (no promises!):
- Исправление имеющихся недочётов
- Поддержка работы по сети (заказ компонентов, сообщение о готовности - дистанционно).
- Работа с более сложными инвентарями - сборщики, и т.д.
- Работа с машинами-обработчиками ресурсов - когда-нибудь в отдалённом будущем, скорее всего.
Управление:
Интерфейс текстовый. Посмотреть команды главного меню можно, нажав "Enter" (оставив поле ввода пустым).
-
7
-
1
-
Интереснее не запреты, а скорее доступность ресурсов и их расход на определённых этапах развития.
Чтоб человек становился перед выбором - или ты работаешь на еду, делаешь упор на аграрное развитие, или ты добываешь ресурсы, или ты их обрабатываешь, или снабжаешь энергией, или всё сразу, но на грани выживания. А не когда ты всё своими руками.
Ну как в реальности никому в голову не придёт (при нормально работающей экономике) на одном заводе делать и генераторы, и котлеты. Слишком разное оборудование, слишком разные технологические процессы, логистика опять же.
А не как в майне, где всё очень дискретно. Поставил дробилку- вот вам и обработка ресурсов. Вопрос в скорости этой обработки.
Ну и в майне просто приходится развиваться "во все стороны", так как этапы в принципе одни и те же.
Мораль: усложнять этапы производства. Усложнять систему питания (одно дело - когда весь день проводишь на диване, другое - в шахте, размахивая киркой). Разделять методы производства (чтоб не получалось в одну и ту же машину кидать и железную руду, и зерно).
Ну и задействовать людей на разных этапах развития.
Например, в майне всю жизнь было "пока не сделаешь алмазную кирку, урана тебе не видать". Да и ресурсы начальные мало что стоят. В итоге, новичок, приходя на сервер, существующий уже какое-то время, не может никому ничего предложить. Куда приятнее, когда на разных этапах развития у игроков повышается и понижается спрос на определённые ресурсы.
И генерация руд жилами тут очень полезна. Наткнулся новичок на жилу с несколькими тоннами угля. Накопал. Девать его пока некуда (ну факелы-печки). А тут "старичок", который может его бронзой для кирки обеспечить за этот уголь, который ему для электростанции нужен, или там на углеволокно.
И да. Логистики в майне нет. Просто нет. Потому что можно носить с собой целый состав ресурсов, и хранить в сундуке всё вперемешку. А вот если бы приходилось строить многоблочные хранилища отдельных ресурсов (примерно как с жидкостями в РК), то тут опять же был бы повод торговать.
-
1
-
-
В гайдах описал систему. Программы, которые используются у меня, выкладывать не стал (кроме управляющего компьютера), так как всё это зависит от конфигурации и всё равно по уму нужно всё переделывать. Если кому-нибудь надо, то могу выложить или раскрыть подробности.
-
Дисклеймер: всё ниженаписанное можно реализовать миллионом других методов, которые, вероятно, будут более оптимальны. Программный код приведён не полностью, так как система заточена под конкретное использование, конкретные габариты и пр. Программы также не являются оптимальными и содержат огромное количество костылей отчасти из-за лени, отчасти из-за проблем совместимости с другими системами дома и нежелания всё переделывать (перевод: опять же из-за лени)
Автор не отвечает за психические и физические (потеря сознания, кровотечение из глаз, конвульсии, панические атаки, депрессию, разочарование в человечестве), а также игровые увечья и случаи летального исхода, вызванные данным гайдом.
Итак, зелёная энергия угля и пара. Зелёная она потому что:
Нижеописанное представляет собой способ получать ок. 200 eU/t с довольно средними начальными инвестициями и практически нулевыми затратами в процессе.
Система включает в себя:
- Ферму угля
- РК-Бойлер с турбиной
- Управляющий компьютер
Что требуется:
- Ферма угля с роботом (требования опишу ниже)
- Бойлер - в зависимости от настроения
- 160 слитков стали на турбину + 99 на ротор (расходник, но с очень большим сроком службы)
- много свободного места (под бойлер+турбину минимум 6 блоков в высоту)
Важно: подобная схема не предназначена для оперативного включения-выключения. Перед тем, как турбина начнёт генерировать энергию, бойлер должен нагреться и произвести некоторое количество пара, что занимает некоторое время (несколько десятков минут реального времени). В это время бойлер будет расходовать уголь "впустую", причём гораздо быстрее, чем во время постоянной работы. Если уголь заканчивается, бойлер в течение какого-то времени (сравнимого с временем, требуемым на нагрев) будет остывать, по-прежнему вырабатывая пар (а следовательно, турбина будет вырабатывать энергию). Если энергию отдавать некуда, уголь будет потребляться впустую (в отличие от тех же генераторов). Следовательно, необходимо хранилище энергии и схема управления (о чём ниже).
Достоинства:
- Бесплатная и бесконечная энергия (не считая износа ротора, которого хватает на очень длительный срок)
- Вырабатывает гораздо больше энергии, чем другие ранние источники
- Субьективное мнение: вырабатывать энергию с помощью более сложного, требующего определённой автоматизации и обвязки, относительно (по меркам майнкрафта, закрывая глаза на ферму угля) реалистичного энергоблока куда интереснее, чем используя десятки ИК2-генераторов
- Выглядит серьёзнее
Недостатки (некоторые делают использование данной схемы интереснее, а следовательно, могут быть отнесены к достоинствам):
- Сложнее в постройке, настройке, требует автоматизации.
- Занимает много места
- Не способен быстро включаться-выключаться
- Требует много материалов (могут быть проблемы со сталью).
Итак. В RailCraft есть такая замечательная вещь, как турбина. Она умеет производить IC2-электричество из пара. Количество энергии зависит от количества поступаемого пара, до 200 eU/t при поступлении 320 единиц пара. Разумнее всего производить пар при помощи бойлера из того же Railcraft. В итоге, получаем полноценный энергоблок котёл-турбина.
Бойлер
Бойлеры бывают нескольких разновидностей. Во-первых, различается материал котла.
Котлы бывают низкого давления (железные, быстрее разогреваются, выдают меньше пара) и высокого давления (разогреваются медленнее, больше потребляют угля и выдают больше пара). Я предпочитаю строить железный котёл 3x4x3, так как со сталью в начале игры обычно проблемы. Такая конфигурация выдаёт чуть меньше пара, чем требуется для 100% эффективности турбины, но для меня это некритично. Если со сталью проблем нет, можно построить котёл высокого давления 3х3х3 (но будет переизбыток пара).
Кроме материала и габаритов котла бойлеры различаются также и по топливу. Бывают бойлеры, работающие на жидком (лава, горючие жидкости) и на твёрдом (уголь, древесина) топливе. Несмотря на то, что бойлер - структура многоблочная, совмещать различные блоки котла и топки в одной структуре нельзя (то есть, нельзя построить бойлер наполовину железный, наполовину стальной, и т.д.).
В данном случае я буду рассматривать железный котёл 3х4х3 (что не критично), работающий на твёрдом топливе (а вот это уже критично).
Собираем его так (снизу вверх): нижним слоем кладём блоки Solid Fueled Boiler Firebox в габаритах будущего бойлера (в нашем случае 3х3). Над ними 3х4х3 Low Pressure Boiler Tank. Когда всё готово, блоки котла должны соединиться. Теперь к бойлеру можно получить доступ в интерфейс.
https://ftbwiki.org/Steam_Boiler_(Railcraft)
Турбина
Прямо на бойлере (сверху) строим турбину из RailCraft
Строим её из 12 блоков Steam Turbine Housing в формате 2х2х3. Когда конструкция готова, внешний вид поменяется вот на такой (без адаптера и прочей обвязки, разумеется):
Соответственно, на этом собственно строительство бойлера закончено. Чтобы работать в "ручном" режиме, нужно только подсоединить его к сети, заполнить водой, заправить углём и каждые 5 минут бегать добавлять угля и воды. Но разумеется, это не интересно. Соответственно, его надо как-то автоматизировать.Важно: Если в разогретом бойлере закончилась вода, надо перед доливкой дать ему остыть. Или долить сразу и насладиться фейерверком.
Вода
Как говорили машинисты паровозов, у Вас может закончится уголь, может закончиться пар, но ни в коем случае не должна заканчиваться вода!
Самое простое - сделать резервуар воды и поставить помпу из IC2 вплотную к бойлеру, подключив к турбине и поместив в неё Fluid Ejector Upgrade. Можно заправлять и роботом, но в таком случае есть одна проблема, которую я упомяну потом. Да и смысла нет, помпа много энергии не потребляет, а потребности бойлера в воде обеспечит без проблем.
Ключом можно поменять сторону, с которой помпа будет брать воду. При клике на сторону ключом с зажатым шифтом задаётся сторона, противоположная той, на которую кликнули.
Так как турбина вырабатывает 200 eU/t, помпу к турбине подключаем через трансформаторы (MV и LV). Подключать её к хранилищу смысла нет, так как бойлер потребляет воду только когда он вырабатывает пар. А когда он вырабатывает пар, турбина выдаёт электричество (не сразу, но бойлер вмещает достаточно воды чтоб компенсировать данный лаг).
Информация о турбине: https://ftbwiki.org/Steam_Turbine_(Railcraft)
Уголь
И вот тут начинается самое интересное.
Я уже говорил, что нам требуется ферма угля. Таковые уже рассматривались на данном форуме, и не раз, поэтому углубляться в детали не буду.
В моём случае ферма угля занимает два этажа под машинным отделением (где и находится энергоблок), размером в чанк, на 72 дерева (по 36 на каждом этаже). Робот, который занимается сбором угля, также обслуживает и котёл. Для этого, в принципе, можно выделить и отдельного робота, при условии, что у него есть доступ к собираемому углю.
На картинке выше - робот поднимается с фермы через отверстие в полу (рядом с сундуком, отмечено жёлто-чёрными блоками), добирает из сундука угля до 4 стаков и отправляется к воронке. Выгружает уголь в воронку (подходит именно сбоку, а не сверху) и идёт назад отдыхать. Программу писать не буду, потому что данные действия - элементарны, и зависят от конкретной пространственной конфигурации.
Наличие воронки здесь важно по той же причине, по которой не рекомендуется использовать робота для заливки воды. Дело в том, что бойлер умеет принимать уголь автоматически из любого контейнера, стоящего вплотную к блокам топки. А так как робот для бойлера - всего лишь контейнер, то бойлер будет тянуть всё, что находится в инвентаре робота и что горит. Что не очень хорошо, если у робота в инвентаре находятся, например, саженцы. Конечно, можно выгружать саженцы, но это будет только усложнять жизнь.
Вместо воронки, соответственно, можно поставить любой сундук. Я использую воронку потому что ввиду малого инвентаря она позволяет дозировать подаваемый уголь точнее и проще.
Возникает вопрос: почему не поставить бойлер сразу рядом с сундуком, в который выгружается уголь, и этим самым избавить робота от ненужной работы? Ответ далее.
Управление
Как я уже сказал, турбина вырабатывает до 200 eU/t. При этом съедается уголь в огромных количествах, а также изнашивается ротор. И если вопрос угля решается габаритами фермы (хотя в некоторых случаях это важно, так как много места может и не быть. Моя ферма из 72 дубов, находящаяся в подвальном помещении в биоме River, выдаёт чуть меньше угля, чем требуется для безостановочной работы бойлера), то менять роторы (ротора хватает на несколько реальных дней безостановочной работы, но всё же) - удовольствие не столь дешёвое. А потреблять 200 eU/t в режиме 24/7 нужно не всем, особенно на ранней стадии игры. А как я уже упомянул, включение-выключение бойлера занимает много времени, а также значительно снижает эффективность. Следовательно:
1) Требуется буфер энергии. Как минимум, MFE (4MeU). Желательно, MFSU (40MeU). За этим буфером необходимо следить, чтоб определять, сколько в нём энергии.
2) Требуется компьютер, который будет следить за содержимым буфера, и давать команду роботу.
Для упрощения себе жизни, у меня используется следующая схема:
Компьютер следит за содержимым MFSU. Если количество энергии падает ниже определённого значения (в моём случае - 20%), то подаёт редстоун-сигнал на провод, подходящий к тому месту, которое посещает робот каждый раз, когда выгружает уголь (примерно каждые 5 минут). Когда энергия превышает некоторое значение (у меня - 80%), сигнал снимается. Если робот видит, что сигнал подаётся, он докладывает уголь в бойлер. Если нет, то уголь, соответственно, в бойлер не поступает. Соответственно, уголь в бойлере кончается, энергия ещё какое-то время вырабатывается (достаточно для того, чтоб заполнить хранилище), после чего бойлер остывает. В зависимости от потребления и ёмкости хранилища, параметры должны быть иными (для MFE я использовал порог включения и порог выключения 50% - инерция бойлера обеспечивала необходимый гистерезис).
Данная схема, разумеется, неоптимальна и обладает очевидными недостатками (основной - отсутствие оперативности, робот не может среагировать достаточно быстро на повышенное потребление энергии. Однако ввиду того, что бойлер так или иначе не способен быстро включиться при необходимости, этот недостаток менее значим). При желании её можно усовершенствовать, передавая роботу сообщение о необходимости топить-не топить по беспроводной связи (наиболее оптимальным мне видится вариант, когда робот через определённые промежутки времени опрашивает управляющий компьютер, так меньше вероятность того, что сообщение затеряется).
Ниже приведена программа, которая используется у меня для управления бойлером. Она даёт команды роботу, управляющему бойлером, а также позволяет запрашивать по сети данные, касающиеся машинного отделения (количество энергии, температуру и состояние бойлера, генерируемую мощность, состояние ротора и др.), а также менять (опять же, по сети) режим работы бойлера. Также она выводит на монитор основную информацию.
Программа рассчитана под запуск с EEPROM (без ОС), для компьютера, имеющего сетевую, графическую карту, редстоун-интерфейс (в виде карты или внешнего компонента), подключённого адаптерами к MFSU, бойлеру, турбине, железному сундуку с углём. Так как программа была написана для личного использования, поиск оборудования и обработка ошибок его отсутствия не проводится (feel free to change it if you need it). Также не проводится поиск монитора, поэтому чтоб программа начала выводить на экран что-либо, желательно после установки монитора запустить на данном компьютере один раз OpenOS. Сетевое взаимодействие настроено под мою систему. По этой и другим причинам я не советую брать и использовать эту программу, а советую писать что-либо своё или подстраивать данную программу под себя.
https://pastebin.com/Mrrd13SY-
14
-
-
А ещё интереснее, когда он и бойлер этим самым углём топит. При необходимости, в зависимости от наполненности энергохранилища. А ещё когда этим всем можно управлять по сети.
Не знаю, стоит об этом гайд писать, или это никому не интересно?
-
1
-
-
Это подготовка к "Робик стал есть слишком много ресурсов, вайпнем-ка мы его"?
-
1
-
-
Я подозреваю, Entity detector будет точно также реагировать (потом проверю).
Ну хоть motion sensor на роботов не реагирует, и то плюс.
Так что двери делать всё же лучше на них (а то у меня была мысль Entity detector использовать).
-
Ну таблица - можно списать на время суток...
Strateg, спасибо, всё очень понятно.
Интересно, а какая у него максимальная дальность...
-
Я знаком. У меня всё работало. Код не покажу, ты же не показываешь.
А какой тут код показывать? Тут хоть просто в консоли
d = component.os_entdetector;
= d.scanPlayers();
последнюю строку повторяем 4 раза.
Первые три выводит нормальную таблицу "имя-координаты-расстояние". После этого тупо возвращает пустую таблицу.
Помогает только физический снос детектора.
Doob, потом попробую дальность задавать Спасибо.
-
Ностальгия...
У себя сейчас сделал подобный лифт с управлением keypad из OpenSecurity. Ну и всякие мелкие отличия (возможность управления по сети, сохранение адресов в файлы, чтоб при рестарте компьютера не перестраивать всё заново). Если кому-нибудь интересно, могу выложить.
-
1
-
-
Попробовал я тут с Entity Detector поиграть....
Почему-то вывести таблицу в удобочитаемый вид так и не получилось. Через lua-консоль выводится нормально, если использовать =d.scanPlayers(), а вот записать таблицу в переменную, чтоб потом её можно было прочитать, у меня так и не вышло.
Ну и плюс к тому, после трёх сканирований он больше не находит ничего. То есть возвращает пустую таблицу.
Описаний, кроме АПИ, найти не удалось.
Кто-нибудь знаком с этим детектором?
-
ну ОК, принцип "а ты кто такой чтоб что-то просить" я понял. Учту.
-
Ходят слухи об удалении OC-интерфейса к SG-вратам.
Было бы ну очень печально, если б вратами нельзя было управлять по компьютеру....
-
Мораль: ездить должны только роботы, разметкой и дорожными работами заниматься только роботы...короче, человек - лишний элемент везде, куда не посмотри.
А вообще, по идее он всё же не только за разметкой следит, но и за границами дороги, оценивает, куда можно ехать, а куда нельзя. Ну и при пропавших знаках у водителя-человека преимущества перед программой не будет, разве что водитель знает дорогу, ну тут уж программе проще сверяться с картой и GPS (хотя тут встаёт вопрос о поддержке и своевременном обновлении карт, что тоже не всегда и не везде просто).
Тут опять же открывается простор для самообучения. Все возможные ситуации на дороге предусмотреть, пожалуй, невозможно, а вот собирать информацию в автоматическом режиме и обмениваться ею между машинами - метод, на мой взгляд, довольно эффективный. Человек по сути так и учится, в автошколе сразу всё не скажут.
С другой стороны, тут вопрос в балансе между функциональностью и безопасностью. А то если переборщить, машина начнёт тормозить при виде любого пешехода, что тоже нехорошо. Да и проблема в ресурсах бортового компьютера - с собой таскать суперкомпьютер - не выход, а пересылать кучу данных с сенсоров по беспроводным сетям для централизованной обработки - частот не напасёшься.
Ну и интересно было бы знать, как она будет в снегу ориентироваться, где и разметки, и дороги толком не видно. Особенно применительно к нашим таллиннским реалиям где обожают сугробы в полтора человеческих роста оставлять на обочине.
-
А чего именно тест Тьюринга? Субьективная и не совсем однозначная штука.
А так, человек по сути тоже реагирует на внешние раздражители в рамках имеющейся базовой программы + самообучение (опыт).
Ну а такое - не столь, пожалуй, эффектно, как шагающие роботы, но тоже довольно интересно и в широком смысле относится к теме.
-
1
-
-
А есть ещё те, кому нравятся и компы, и ГТ...
Не, распиливать себя пока не хочется.
Ну а реализм в Майнкрафте - это вообще отдельная песнь
. -
По поводу онлайна на таких сервера: онлайн там высок, потому что всё развитие заключено на пару-дневном развитие и дальнейших пвп-замесах для 10-15 летних.
На ГТ наоборот, там играют люди недолюбливающие пвп, любители напрячь мозг для постройки чего восхитительного и супер-индустриального.
Если вообще сравнивать популярность комп модов и ГТ, то компы далековато на дне будут.
Так я ж уже это говорил, и не один раз. Сравнивать по популярности футбол и шахматы - дело неблагодарное. Не, можно, конечно, заняться упрощением шахмат, ну а смысл?
-
1
-
-
Задача создания муравейника сводится к саморепликации, как основу устройства муравейника.
Я считаю, что создание программы для робота\черепашки по саморепликации, это апогей программирования для МС, и наверное, самая востребованная разработка для компьютерного мода. Разрабатывая каждую новую программу, мы приближаем наступление момента, когда первая самореплицирующаяся машинка появится.
Например, объеденив строительную программу и копательную, можно уже создать робота, который построит улей из ресурсов, которые сам добудет.
Но по моему мнению, основная проблема состоит не в принципиальной невозможности создать робота который создает робота (робот не может тыкнуть на кнопку "собрать"), а в обработчике ошибок.
На каждом этапе работы этой "королевы" будет возникать куча прерываний, начиная с падающего песка и заканчивая багами модов. И сделать программу, которая сможет сама находить решение крайне сложно.
Так что, для меня сейчас цель плавно дописывать свою программу строительства. Затем, я смогу использовать ее, что бы робот смог сгенерировать и построить дом сам. Далее, я использую программу "Домик Байта", которую напишет кто то другой, что бы ориентироваться в построеном доме. Ну и так далее.
А в конце сбудется мечта - они съедят майн мир.
Апогей, тогда уж - если они сами себя исправлять начнут. То есть, отслеживать, что вызвало ошибку, и принимать меры к тому, чтоб подобное не произошло впредь. Хотя это уже где-то за гранью.
-
Вот даже не поспорю насчёт экстраутилитис и прочего
.Только комплект "чистые компьютеры + ИК2" без грега мне до боли напоминает вот это:

-
2
-
-
AlexCC
Ну зачем мне приписывать то, чего я не говорил?
Ирония с иронией, все это поняли (ты ж мой всерьёз не воспринял, надеюсь), я нигде не говорил, что воспринимаю список "идей" буквальноНасчёт "ненавижу компьютерные моды" - скажем так, не было бы тут компьютерных модов - меня бы тут тоже не было. Просто не люблю что-либо возводить в абсолют. Компьютерные моды - прекрасно, но эмулировать компьютер только ради компьютера - это как мод игры в майнкрафт в майнкрафте. И где я написал "Экстра, ТЕ, Эндер" или тем более ещё какие-то моды? Мне просто не нравится, когда у машины свинчивают руль и говорят "Ехать можно - зачем тебе руль? Это ж автомобиль, а не автоповорачиватель. Сдаётся мне, ты просто ненавидишь колёса".
Дюшес - ты не прав. РИТЭГи не автоматизировал. И стоящие в основном для украшения интерьера термалки. Эхх, недостоин я звания "компьютерщик". Пойти ,скинуть что ли ноутбук из окна и начать строить копию грегтека вживую из кубиков и проводков...
-
Забываете главное:
1. Установить обязательный посменный рабочий день (8 часов одна смена). Распределить между игроками смены в случайном порядке. В случае неявки
на работыв майн один раз - снос всех землянок с конфискацией ресурсов. В случае рецидива - вечный бан(с расстрелом и одновременным сожжением).2. В случае смерти - 1 час карцера с занесением 1 штрафного очка в досье. При накоплении 8 штрафных очков - игрок обязан незамедлительно
отработатьотыграть ещё смену.3. В случае сворачивания экрана - считать как нарушение пункта 1 (для этого необходимо модифицировать клиент, но что делать).
4. Запретить вообще все крафты. Сделать игровой валютой алмазы. Всё остальное при разбиении превращается в гравий. Гравий нельзя выбрасывать (за это 8 часов карцера с необходимостью сидеть в майне как по пункту 2), а только отдавать в банк за утилизационную плату. И кстати да, кирки разрешить двух видов: каменная (дешёвая) и золотая (дорогая, исключительно для алмазов).
5. Всё необходимое (включая еду, строительные материалы) покупать в банке за алмазы. Строить дома - тоже нельзя (наказание - 16 часов карцера со сносом постройки и конфискацией имущества). Можно арендовать робота в банке (за алмазы). Это подвигнет игроков учить программирование, а также заставит их пользоваться банком.
6. Все игроки обязаны минимум 4 часа в день писать программы для сервера. Оплата труда - 1 алмаз в за 4 рабочих часа. За очень хорошие программы можно выдавать премию в 5 алмазов. Учитывая смерть от голода и монстров, игроков даже заставлять не придётся. За что-то экстраординарное - аренда черепахи для майна на час. Ровно через час черепаха взрывается как атомная бомба, чтоб исключить использование дольше срока.
Представляете, какой будет онлайн, как будут пользоваться банком, как сразу все начнут программировать? Сразу сервер станет полностю компьютерным - все сидят, кодят, иногда отрываясь чтоб поискать в майне алмазы. Идеал компьютерного сервера, не правда ли? И лагать не будет!
Осталось решить вопрос предустановки майна на компьютеры пользователей и невозможности удаления, а также вопрос автоматической эвтаназии пользователя при бане.-
5
-
-
Так черепахи же не грузят чанки. Тогда нужно, чтоб или они с собой таскали при добыче чанклоадерную вагонетку (интересно, откуда им эндерглаза брать), или расставляли везде чанклоадеры (и повалили сервер).
Роботы - понятно, чанклоадер есть встроенный, но их сборку непонятно как автоматизировать.
-
Проблема в том, что как только ты подошёл к двери, она сама открывается без дальнейших действий с твоей стороны.
В этом есть плюсы, но есть и очевидные минусы. Подошёл к двери посмотреть, кто там...

Странное поведение переменной.
в Общие
Опубликовано: · Изменено пользователем Aex
Не знаю, где лучше расположить эту тему.
Ситуация:
Есть дом на сервере EvilCraft. В нём работает в режиме non-stop примерно 5 компьютеров (включая один сервер и одного робота).
В доме есть дверь. На которой запущена программа входного замка.
Программа (урезанная до скелета, чисто для демонстрации. В приведённой версии эффект наблюдается вполне) приведена тут:
https://pastebin.com/yzf4eRZq
Проблема:
Когда я выхожу с сервера, телепортируюсь в другой мир, или же просто покидаю чанк, то (не всегда!) проявляется следующий эффект:
Одна из переменных (в приведённом тексте TimeOut. Я пробовал её переименовать) перестаёт принимать значения.
То есть, для примера, когда я возвращаюсь в чанк и нажимаю на кнопку открытия дверей, вызывается функция VisitRequest, которая вызывает в свою очередь после проверки вызывает функцию OpenDoor, которая успешно отрабатывает, и вызывает в свою очередь функцию WaitMenu.
function WaitMenu(delay) sMode = -1; TimeOut = delay; timestamp = computer.uptime(); gpu.fill(1,7, resX, resY, " "); gpu.set(8, 9, "PLEASE WAIT"); endКоторая выполняет всё успешно (судя по надписи на экране). Но переменная TimeOut не принимает значение delay, и остаётся в нуле (её значение по-умолчанию), судя по выводу на экран и дальнейшему поведению программы.
Обнуление переменной исключается, так как единственное место где она обнуляется не исполняется (меню не отрисовывается).
Может кто-то с таким сталкивался? Из-за чего такое возможно?
Update: Это наблюдается на как минимум двух компьютерах с двумя разными программами...