eu_tomat

Ну наконец-то кто-то пришёл по-настоящему поныть! Наша местная ячейка партии нытиков была надолго обескровлена ожесточёнными дебатами о преимуществах одних модов над другими. Последние недели даже у самых активных её членов силы оставались лишь на расстановку грустных реакций под каждым постом. Но OpenComputers продолжает обеспечивать приток свежей крови даже в партию нытиков. Так победим.

Многое смешалось в этой статье. Но я попробую разобрать. Какой мод лучше для программирования? Оба мода хороши. ComputerCraft проще в освоении, но OpenComputers обеспечивает большее разнообразие задач для программирования. Обязательно ли новичку отвлекаться на крафт компьютеров и роботов? Нет, не обязательно. В творческом режиме компьютер создаётся одной консольной командой, а готовый робот с внушительным обвесом доступен в NEI. Почти все программы, взаимодействующие с миром, изначально пишутся и тестируются в творческом режиме, и лишь после этого переносятся сначала в режим одиночного выживания, а затем и на сервера. Являются ли проблемой усложнённые крафты компьютеров на тех или иных серверах? Нет, это проблема самих серверов. Она не имеет отношения ни к самим модам, ни к программированию. На конкретном сервере крафт черепашки может оказаться даже сложнее крафта робота. OpenComputers убивает поток свежей крови на форум? Тут надо подумать. Как наличие второго мода мешает новичкам изучать первый? Да, старожилы форума в большинстве своём предпочитают OpenComputers. Но они не препятствуют другим участникам писать программы и статьи о программировании в ComputerCraft. Итог: Читатели негативно воспринимают нытьё. Нужна конструктивная критика и предложения. Что требуется сделать для обретения комфорта? Чем может помочь администрация форума? Чем могут помочь старожилы? Чем может помочь сам автор этой статьи? Что в результате этих действий ожидает увидеть автор?

Для начала можно хотя бы ознакомиться с кодом скрипта. Он как раз и работает через mount/umount.

О чём этот пост? Что такое рекомпилятор? Что он делает? Что гораздо быстрее? Что за блоки большого размера? О каких модах идёт речь? И какое отношение ко всему этому имеет графика?

Русскоязычное описание API: https://minecraft.fandom.com/ru/wiki/OpenComputers/Computer_API https://minecraft.fandom.com/ru/wiki/OpenComputers/Robot_API https://minecraft.fandom.com/ru/wiki/OpenComputers/Дрон Если эта документация недостаточно свежа, есть описание на английском: https://ocdoc.cil.li/component:computer https://ocdoc.cil.li/component:robot https://ocdoc.cil.li/component:drone

1) Похоже, что-то сломано в моде. Даже если он выдаёт размер инвентаря робоита 81, то всё равно не позволит использовать больше 64 ячеек. 2) Этот код не содержит условия для останова цикла. Остановиться он может только по ошибке. С каким сообщением останавливается программа? Скорее всего, что-то вроде attempt to index a nil valueпри обработке пустого слота.

Цикл перебирает ячейки инвентаря робота. Но инвентарь робота не может вместить больше 64 ячеек независимо от количества установленных улучшений инвентаря.

Текстура может зависеть от использованного пакета текстур. Найти можно в зависимости от языка: Linked Card Связанная плата Пара связанных плат создаётся одним крафтом. Также две платы можно связать друг с другом на верстаке.

Вставить связанную карту в робота и запустить программу ещё раз.

А залил-то куда, чем и откуда?

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

Про меняющиеся данные вроде бы не было уточнения. Поэтому вариант с копированием тоже уместен. Опции команды install многим неизвестны. Зато команда cp и её опции широко известны даже за пределами модов Майнкрафта. Поэтому такое решение может для кого-то оказаться более предпочтительным.

Действительно, есть возможность заблокировать запись на диск. Тогда алгоритм выглядит так: устанавливаем OpenOS на дискету командой install, добавляем на неё любые файлы, защищаем от записи и получаем возможность устанавливать модифицированную систему всё той же командой install.

Да, команда install по сути выполняет копирование файлов, упрощая процесс установки со стандартной дискеты OpenOS. Использование команды cp чуть сложнее, но в конечном итоге на возможности загрузки копии операционной системы это никак не сказывается. При установке OpenOS с пользовательских носителей команда install теряет своё главное преимущество – простоту использования. Поэтому с тем же успехом можно копировать файлы командой cp.

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

Чтобы обычная дискета превратилась в установочную, достаточно установить на неё файлы OpenOS с оригинальной дискеты.

Мод OpenComputers не позволяет управлять атрибутом ReadOnly дискет. Ни установить, ни сбросить его невозможно. Атрибут ReadOnly установлен лишь для специальных дискет, содержимое которых жёстко задано модами и не предназначено для изменений. Для этой цели существуют обычные дискеты. Они позволяют разместить на них произвольный набор файлов.

Почему нет? Существует прямо противоположная идея: надо изобрести максимальное количество велосипедов.

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

Вероятность этого не высока, т.к. на бесконечном поле использование отражателей снижает среднюю производительность. Но на краях, как всегда, возникают нюансы. Поэтому проверить будет полезно. Найденные тобой 8 вариантов схем можно свести к 3 базовым, учитывая симметрию. Найденный мной вариант не сдвигает узлы изначальной сетки. В двух других, найденных электронными мозгами, изначальный порядок узлов сильно нарушен, для человеческих мозгов такие решения неочевидны. Похоже, дальнейшие улучшения возможны только перебором. А что касается оптимизации, то первым делом я предлагаю выбросить рекурсию.

Я хотел не файловую систему, а сообщить о том, что хранение одного файла на ленте не имеет особого смысла. Смысл может иметь файловая система для ленты, но при наличии применений. А что именно я хотел увидеть?

@whiskas Меня смутила фраза А конкретно слово "всех". Потому что все варианты с конденсаторами и счетверённым ураном описываются 54-битным числом. И даже выполнение относительно простого цикла for(i=1; i<(1ul << 54); i++) x ^= i; со всеми оптимизациями компилятором займёт много дней, не говоря уже о рекурсивных способах перебора. Похоже, что провальные варианты ты откидывал не в начале рекурсии, а до начала рекурсии. Вопрос в том, какие именно варианты ты отбросил. Я именно об этом спрашивал: Меня интересуют ограничения вроде этого: Как ты вышел на такое количество? Есть вручную расставленный вариант с производительностью 4360 eu/t. Максимальное количество энергии, которое сможет обеспечить счетверённая сборка урана в схемах такого типа, составляет 120 eu/t. Соответственно, урановые сборки должны занимать не менее 37 ячеек реактора. А значит, схема может иметь максимум 17 конденсаторов. Это теоретическое ограничение сверху. Ограничение снизу считается проще. Как минимум каждая пятая ячейка реактора должна содержать конденсатор. Поэтому схема должна содержать не менее 11 конденсаторов. Но эта теория для бесконечной плоскости. На практике диапазон окажется немного уже. По моим прикидкам оптимальная схема не должна иметь больше 14 конденсаторов (в среднем 14.5), но это слишком грубый расчёт. Как ты вышел на максимум в 16 конденсаторов?

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

Именно так. Что значит "надо"? В каких задачах это востребовано?

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