Перейти к содержимому

Aex

Пользователи
  • Публикации

    36
  • Зарегистрирован

  • Посещение

  • Победитель дней

    6

Aex стал победителем дня 10 августа 2019

Aex имел наиболее популярный контент!

Репутация

86 Обычный

1 подписчик

Aex

  • Звание
    Участник

Информация

  • Пол
    Мужчина

Посетители профиля

Блок посетителей профиля отключен и не будет отображаться другим пользователям

  1. Не знаю, где лучше расположить эту тему. Ситуация: Есть дом на сервере 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: Это наблюдается на как минимум двух компьютерах с двумя разными программами...
  2. Сложнее ещё потому что не всегда можно использовать альтернативные крафты. Например, всякая там мебель BibleCraft. И не у всех альтернативных крафтов такое удобное совпадение имени. Ну и надо создавать какие-то алиасы, потому что пользователь не видит у себя на экране minecraft:planks, он видит у себя Oak Wood Planks. Это конечно решаемо, но усложняет жизнь. В общем, в дальнейшем надо в любом случае думать и дорабатывать этот момент.
  3. Давненько не было автокрафтеров тут. Может, кому-то пригодится моя версия. Предназначена в первую очередь для крафта всяких часто необходимых мелочей со сложными крафтами (например, компоненты OpenComputers) из примитивных исходных ресурсов (например, процессор из слитков золота и железа, тростника и редстоуна), которые у пользователя отнимают кучу времени на поиск всех транзисторов и крафт недостающих. Рассчитана на использовании робота и двух сундуков, один из которых - основное хранилище (может быть покрупнее), а другой предназначен для резервирования компонентов при крафте. Ссылка: https://pastebin.com/1gqtWLub Необходимая конфигурация робота: Проверялась работа на компонентах (корпус, память, процессор, жёсткий диск) второго уровня. Screen, Keyboard Crafting Upgrade Inventory Upgrade и Inventory Controller Видеокарта и экран первого уровня Для дальнейших потенциальных расширений: Беспроводная карта Upgrade Container Конфигурация установки: Перед роботом - контейнер ресурсов (любой из возможных инвентарей достаточного размера) Под роботом - контейнер-буфер (можно обычный сундук) Рядом желательно поставить зарядник Возможности: Рекурсивный крафт сложных рецептов. Ресурсов расходуется, по результатам практических испытаний, ровно столько, сколько необходимо. Каталог рецептов для крафта, разбитый на страницы по 10 предметов для более удобного пролистывания на маленьком экране робота. Портативность - требуется только робот, два сундука и исходные ресурсы. Желателен также источник энергии Сообщения о том, каких конкретно исходных ресурсов не хватает для крафта (исходные ресурсы - те, для которых не найдено рецепта) Процесс крафта подробно отображается на экране, чтоб за ним было не так скучно и одиноко следить (см. недостатки) Об окончании крафта робот сообщит приветливым писком. Равно как и о неудаче. Недостатки и известные недочёты: Скорость..... Крафт занимает значительное время. Например, изготовление процессора 3го уровня из примитивных ресурсов (тростник, красный камень, алмазы, дерево для резаков, слитки золота, железа) занимает около 5 минут. Стоит отметить что количество изготавливаемых предметов не сильно влияет на время (2 процессора, скорее всего, будут делаться те же примерно 5 минут). Не умеет работать с альтернативными ресурсами. Возможно, когда-нибудь исправлю. Не умеет работать с инструментами (имеются ввиду многоразовые, как молот ИК2). Возможно, так же когда-нибудь исправлю. Не умеет работать с количествами предметов более стака, а также не гарантируется корректная работа с предметами, не складывающимися в стак. Постараюсь исправить в ближайшее время. Нет поиска по именам компонентов (то есть, либо задаёте название компонента целиком, либо задаёте крафт через каталог). Когда-нибудь поправлю Проверок на наличие контейнеров не делается, так как программа писалась "для себя" и находится в разработке. В дальнейшем будут введены. Также не везде гарантируется наличие защиты от "Количество предметов: Привет". Особенности: Шаблоны содержатся в одном файле, что облегчает переносимость, но приносит определённые неудобства всвязи с размерами файла (12 строк на предмет). Буду думать, как лучше сделать (разбить на разные файлы?). Файл имеющихся шаблонов могу выложить при необходимости (на разных сборках эти шаблоны могут отличаться) Дальнейшее развитие (no promises!): Исправление имеющихся недочётов Поддержка работы по сети (заказ компонентов, сообщение о готовности - дистанционно). Работа с более сложными инвентарями - сборщики, и т.д. Работа с машинами-обработчиками ресурсов - когда-нибудь в отдалённом будущем, скорее всего. Управление: Интерфейс текстовый. Посмотреть команды главного меню можно, нажав "Enter" (оставив поле ввода пустым).
  4. Интереснее не запреты, а скорее доступность ресурсов и их расход на определённых этапах развития. Чтоб человек становился перед выбором - или ты работаешь на еду, делаешь упор на аграрное развитие, или ты добываешь ресурсы, или ты их обрабатываешь, или снабжаешь энергией, или всё сразу, но на грани выживания. А не когда ты всё своими руками. Ну как в реальности никому в голову не придёт (при нормально работающей экономике) на одном заводе делать и генераторы, и котлеты. Слишком разное оборудование, слишком разные технологические процессы, логистика опять же. А не как в майне, где всё очень дискретно. Поставил дробилку- вот вам и обработка ресурсов. Вопрос в скорости этой обработки. Ну и в майне просто приходится развиваться "во все стороны", так как этапы в принципе одни и те же. Мораль: усложнять этапы производства. Усложнять систему питания (одно дело - когда весь день проводишь на диване, другое - в шахте, размахивая киркой). Разделять методы производства (чтоб не получалось в одну и ту же машину кидать и железную руду, и зерно). Ну и задействовать людей на разных этапах развития. Например, в майне всю жизнь было "пока не сделаешь алмазную кирку, урана тебе не видать". Да и ресурсы начальные мало что стоят. В итоге, новичок, приходя на сервер, существующий уже какое-то время, не может никому ничего предложить. Куда приятнее, когда на разных этапах развития у игроков повышается и понижается спрос на определённые ресурсы. И генерация руд жилами тут очень полезна. Наткнулся новичок на жилу с несколькими тоннами угля. Накопал. Девать его пока некуда (ну факелы-печки). А тут "старичок", который может его бронзой для кирки обеспечить за этот уголь, который ему для электростанции нужен, или там на углеволокно. И да. Логистики в майне нет. Просто нет. Потому что можно носить с собой целый состав ресурсов, и хранить в сундуке всё вперемешку. А вот если бы приходилось строить многоблочные хранилища отдельных ресурсов (примерно как с жидкостями в РК), то тут опять же был бы повод торговать.
  5. Aex

    Робо-фермер

    В гайдах описал систему. Программы, которые используются у меня, выкладывать не стал (кроме управляющего компьютера), так как всё это зависит от конфигурации и всё равно по уму нужно всё переделывать. Если кому-нибудь надо, то могу выложить или раскрыть подробности.
  6. Дисклеймер: всё ниженаписанное можно реализовать миллионом других методов, которые, вероятно, будут более оптимальны. Программный код приведён не полностью, так как система заточена под конкретное использование, конкретные габариты и пр. Программы также не являются оптимальными и содержат огромное количество костылей отчасти из-за лени, отчасти из-за проблем совместимости с другими системами дома и нежелания всё переделывать (перевод: опять же из-за лени) Автор не отвечает за психические и физические (потеря сознания, кровотечение из глаз, конвульсии, панические атаки, депрессию, разочарование в человечестве), а также игровые увечья и случаи летального исхода, вызванные данным гайдом. Итак, зелёная энергия угля и пара. Зелёная она потому что: Нижеописанное представляет собой способ получать ок. 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
  7. Aex

    Робо-фермер

    А ещё интереснее, когда он и бойлер этим самым углём топит. При необходимости, в зависимости от наполненности энергохранилища. А ещё когда этим всем можно управлять по сети. Не знаю, стоит об этом гайд писать, или это никому не интересно?
  8. Это подготовка к "Робик стал есть слишком много ресурсов, вайпнем-ка мы его"?
  9. Я подозреваю, Entity detector будет точно также реагировать (потом проверю). Ну хоть motion sensor на роботов не реагирует, и то плюс. Так что двери делать всё же лучше на них (а то у меня была мысль Entity detector использовать).
  10. Ну таблица - можно списать на время суток... Strateg, спасибо, всё очень понятно. Интересно, а какая у него максимальная дальность...
  11. А какой тут код показывать? Тут хоть просто в консоли d = component.os_entdetector; = d.scanPlayers(); последнюю строку повторяем 4 раза. Первые три выводит нормальную таблицу "имя-координаты-расстояние". После этого тупо возвращает пустую таблицу. Помогает только физический снос детектора. Doob, потом попробую дальность задавать Спасибо.
  12. Ностальгия... У себя сейчас сделал подобный лифт с управлением keypad из OpenSecurity. Ну и всякие мелкие отличия (возможность управления по сети, сохранение адресов в файлы, чтоб при рестарте компьютера не перестраивать всё заново). Если кому-нибудь интересно, могу выложить.
  13. Попробовал я тут с Entity Detector поиграть.... Почему-то вывести таблицу в удобочитаемый вид так и не получилось. Через lua-консоль выводится нормально, если использовать =d.scanPlayers(), а вот записать таблицу в переменную, чтоб потом её можно было прочитать, у меня так и не вышло. Ну и плюс к тому, после трёх сканирований он больше не находит ничего. То есть возвращает пустую таблицу. Описаний, кроме АПИ, найти не удалось. Кто-нибудь знаком с этим детектором?
  14. ну ОК, принцип "а ты кто такой чтоб что-то просить" я понял. Учту.
  15. Ходят слухи об удалении OC-интерфейса к SG-вратам. Было бы ну очень печально, если б вратами нельзя было управлять по компьютеру....
×
×
  • Создать...