eu_tomat

Мод-то какой?

Во! Это уже та конкретика, которую читатель ожидает увидеть в описании, и которая может его заинтересовать. Также имеет смыл рассказать и о других утилитах, встроенных в эту OS. Если их смысл общеизвестен, достаточно простого их перечисления. Полезным будет упомянуть в описании, что система основана на CraftOS, чтобы у ознакомившихся с кодом не возникало непреодолимого желания строчить посты о плагиате. Не менее полезной будет информация об отличиях этой системы от стандартной OpenOS. Потребуется ли модифицировать под эту систему программы, написанные для OpenOS? А если потребуется, то как именно. И вообще, когда создаёшь описание к своим программам, помни о том, что читатель ленив. Это тебе не лень писать систему, а мне не лень вникать, что это такое, и зачем оно нужно. Но большинство читателей бегло читает только первый пост. Иногда читает лишь первый абзац или даже первое предложение. @arutimasu Если тебе интересно, я могу разобрать начало твоего поста, как его видит типичный читатель, возникает ли у него мотивация читать дальше, установить твою систему или задать вопрос. И могу рассказать, как бы я оформлял описание, чтобы читателю было интересно. Конечно же, в рамках того немного, что я смог понять из обсуждения. Заголовок комментировать не буду: скорее всего, ты вынес в него самую важную информацию.

В реальности чистый Lua используется редко. Чаще всего как дополнительный, не основной язык. Полноценные же программы я встречал только в ComputerCraft и OpenComputers. Но это специфическая среда, можно сказать, учебная. Тогда какая должна быть мотивация использовать этот клон? В чём его преимущества в сравнении с чистым Lua?

Хорошо, теоретически мы можем взять то или это. А практически, как я понимаю, пока никто не брал. Тогда отложим графику в сторону и зайдём с другой стороны. Можешь продемонстрировать преимущества своей системы на примере какой-либо уже написанной программы?

Вот про это и хочется узнать подробнее и на примерах. Допустим, у нас есть несколько реализаций игры "жизнь" для: OpenComputers, Computercraft, NodeMCU и x86. Но теперь мы хотим иметь только одну реализацию. Можем ли мы для этого использовать твою систему? И если да, то как должна выглядеть такая программа?

А можно как-то подробнее описать опыт тестирования? Для меня даже сам термин "фентезийная консоль" звучит слишком абстрактно. Каково практическое применение этих консолей? И как применять конкретно эту? Как её запустить на протестированных платформах? Что нам это даст?

Геосканер имеет две доступных игроку функции: scan возвращает зашумлённую таблицу плотностей блоков в заданной области. analyze возвращает разнообразную информацию о блоках, непосредственно контактирующих с геосканером или роботом.

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

Поля таблицы и их значения можно посмотреть с помощью такого кода: for k,v in pairs(t) do print(k,v) end

Я проверил на версии MineTweaker3-1.7.10-3.0.10B.jar, команда успешно выгрузила рецепты в файл. Попробуй у себя проверить на минимальной сборке. Возможно, конфликтуют какие-то из модов.

Система-то запустится. Но удобно ли её использовать? Как минимум, не все значки приложений поместятся на экран.

Установить MineOS на устройство, имеющее экран уровня 3: компьютер, сервер. Планшет в их число не входит.

Хорошо. Подождём раскрытия потенциала.

Тут нужна пояснительная бригада. Если форк не отличается от ванильной MineOS, то в чём его смысл? И в чём заключается актуальность другой ветки, если она обновлена в репозитории в то же время, что и основная — 2 года назад?

Ты теперь будешь в каждой теме это писать? Зачем этот спам?

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

Если посмотреть на даты, то исправить текст просил современник Пушкина. Но исправить смогли лишь его почитатели спустя пару веков. Хорошая работа, Пушкин жив!

Ну, это известная штука, если речь шла именно о ней. Просто товарищ @Taoshi использовал слово "заменить", а в этом механизме нет никакой замены, конденсаторы охлаждаются лазуритом, не покидая слотов реактора.

@Taoshi Ты не ответил на вопрос. Поясни, что ты имел в виду: Что за отдельный механизм? Как он работает? Почему у него получается работать с конденсаторами и что ему мешает работать с охлаждающими капсулами?

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

Захардкодить — конечно, да. Другого-то выбора всё равно нет. При столь жёстких лимитах времени компьютер только и должен делать, что непрерывно останавливать очередной реактор, выбрасывать из него все без разбора капсулы, загружать новые, запускать реактор и переходить к следующему, и так далее по кругу. Даже в этом случае мы не вписываемся в ТЗ и вынуждены выбрасывать капсулы с 9% остатком прочности, а не 25% как хочет заказчик. И это, конечно, при условии, что управляющий комп не лагает. Учитывая, что за включение реакторов отвечает компьютер, то реакторы и будут запущены с задержкой относительно друг друга. Нет смысла включать их как-то иначе. Это получится само собой. Ну, а время работы каждого реактора после замены стержней надо считать в любом случае. Точнее говоря, каждый реактор имеет дедлайн до взрыва — 105 секунд от момента последнего включения. Заменяя стержни в очередном реакторе, проверяем, укладываемся ли в дедлайн следующего с некоторым запасом времени, который зависит от лагов. Если не успеваем заменить все капсулы, то запоминаем для этого реактора количество оставшихся для замены капсул и, не включая его, переходим к следующему. В следующем цикле замены капсул продолжим заменять то, что не успели в предыдущем. И если снова не опоздаем, то сможем включить этот реактор и установить новый дедлайн. Тут особых сложностей нет кроме того, что реакторы будут иногда простаивать. И тем чаще, чем сильнее лагает управляющий компьютер.

А что за отдельный механизм? Как он работает? Почему у него получается работать с конденсаторами и что ему мешает работать с охлаждающими капсулами? Там вроде речь о другом шла: требовалось кинуть отработанную капсулу в МЭ-интерфейс, а из него уже трубы заберут куда-то. Ты хочешь сказать, что на том сервере используется древняя версия OpenComputers, которая не умеет читать содержимое всего инвентаря за один такт? Тогда да, задача из ТЗ дважды нерешаемая. А зачем включать-выключать реактор при замене каждого стержня? Разве ТЗ имело такое требование? Один раз выключили, заменили все разом и снова включили.

В том-то и дело, что лагов сервера без замеров мы не знаем. Поэтому не знаем, сможет ли их покрыть сокращение реакторов в 2 раза. Проблема в том, что при сильных лагах, пока происходит замена охлаждающих ячеек в одних реакторах, остальные могут взорваться, не дождавшись своевременной замены. Что за ограничения территории и функциональных блоков? Для 50 реакторов территория с функциональными блоками нашлись, а для компьютеров — нет? О чём тут вообще речь? На каком сервере такие ограничения?

Проблема в том, что потоки на одном компьютере не выполняются параллельно. Хочешь относительной асинхронности — ставь больше компьютеров. Кстати, а что мешает установить по компьютеру в каждом чанке? А на чём основаны подсчёты? Теоретически можно больше 50 реакторов обслужить с запасом, но для конкретного сервера в конкретный период времени нужны замеры. Ещё одно важное замечание: на лагающих серверах приоритетной задачей компьютера является не замена компонентов, а отключение реактора. А когда реакторов много, то начинать отключение реакторов приходится сильно заранее, что приводит к их простою.

На одну замену требуется 2 такта. И по такту на включение и выключение. Если сервер не лагает, а реактор один, то можно синхронизироваться на начало его такта, который длится одну секунду (20 майнкрафтовких тактов) и спокойно заменить до 9 элементов даже без останова реактора и без потери в энергогенерации. Не помню, можно ли успеть заменить 10. На лагающем сервере, где игроками активно используются роботы и компьютеры, проблема будет заключаться в вечно запаздывающем возврате управления компьютеру. И какова будет суммарная длительность операции замены стержней, заранее сказать невозможно. В самом плохом случае может возникнуть ситуация, когда замены потребуют все охлаждающие ячейки во всех реакторах, и тогда компьютер попросту не успеет заменить их все. И прежде чем браться за эту задачу, стоит оценить, насколько она осуществима хотя бы в теории. А в теории на нелагающем сервере для безопасной замены всех охлаждающих ячеек во всех 50 реакторах потребуется 95 секунд. При этом типичное время жизни охлаждающих ячеек в этой схеме составляет всего 105 секунд. Получаем запас времени 10 секунд. То есть теоретически такая схема работы в целом жизнеспособна. Но это минимально необходимое время с учётом того, что компьютер не проверяет состояние ячеек, а действует исключительно на основе своих прогнозов. А если проверять износ ячеек, то потребуются ещё 2.5 секунды, и от запаса времени останется всего 7.5. Пока будет выполнен весь цикл замены ячеек, и мы закончим обработку последнего реактора, оставшийся ресурс охлаждающих ячеек в первом составит 7%. А по условию задачи замена требуется при остатке ресурса 25%. Выходит, это условие невыполнимо даже в теории. Тогда износ ячеек можно не проверять, а сразу заменять все подряд; так мы сэкономим немного времени. Тогда износ ячеек составит 9% — это немного лучше, но всё равно не сходится с условиями задачи. На лагающих серверах время замены стержней может увеличиться в несколько раз, всё зависит от текущей игровой ситуации. Запаса времени у нас, скорее всего, не будет вовсе, и некоторые из реакторов потребуется держать постоянно остановленными, без энергогенерации. Вот такая получилась грустная арифметика. А кроме прочего у нас ещё и трубы норовят засунуть топливо в свободную ячейку, что осложняет задачу ещё сильнее: Это значит, что трубам доверять столь тонкую задачу нельзя. Компьютер легко справится с ней, но, конечно же, при наличии времени, которого ему и так мало.