eu_tomat

Давай проверим это вместе. Для начала посмотрим содержимое, которым предлагается прошить EEPROM: И там первой же строкой видим: local handle, code, result, reason = component.proxy(component.list("internet")()).request('https://raw.githubusercontent.com/titan123023/OCBios/master/bios.lua'), '' А все последующие строки кода используют результаты этой строки. Получается, что код в EEPROM предназначен для скачивания и запуска кода, находящегося по адресу https://raw.githubusercontent.com/titan123023/OCBios/master/bios.lua. А так как скачать код без интернет-платы невозможно, из этого следует, что OCBios работает только при наличии интернет-платы.

Масштабный труд! Круто всё расписано.

Редактор годный, только он не для OpenOS.

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

@BenniShifer919 Не вполне понимаю проблему. Картинки бесполезны из-за их размера. Чтобы увидеть различия между ними, приходится скролллить их вверх-вниз, удерживая детали в памяти. К таким усилиям я не готов, поэтому прекратил попытки ориентации по ним. Предлагаю вырезать из картинок всё несущественное, оставив только значимую часть. А подписи к картинкам имеет смысл как-то группировать, чтобы понимать принадлежность подписи к верхней или нижней картинке. Описание проблемы непонятное: Что значит "генерируется заново"? Как это проявляется? Что значит "в принципе некорректно работает"? Код я не стал читать полностью, но вижу странность в первых строчках. Предполагаю наличие аналогичной проблемы и в остальных участках. if direction == "down" then for y=2,sizeY,1 do for x=1,sizeX,1 do map[y][x] = map[y-1][x] end end for x=1,sizeX,1 do map[1][x] = nil end Если развернуть этот цикл, то получим следующее: Строка с номером 2 заполняется значениями из предыдущей строки, то есть из строки с номером 1. Строка с номером 3 заполняется значениями из строки с номером 2, а по сути всё из той же строки с номером 1. ... Строка с номером sizeY заполняется значениями из строки с номером sizeY-1, а в конечном итоге из строки с номером 1. Строка с номером 1 очищается. Результат работы этого кода можно сформулировать так: первая строка копируется в остальные строки, а сама она очищается. Это не похоже на сдвиг.

Точно. Там же проблема с автоматизацией замены этих рамок в пасеках. Рамки не удастся поместить в пасеку не то что роботами или транспозерами, но даже ванильными воронками. По крайней мере, на 1.7.10 так было.

@BenniShifer919 Про графику не скажу, я не так много работал с ней. Я понимаю, как решить конкретную задачу, но какой-то общий подход в работе с графикой сформулировать вряд ли смогу. А общие советы могу дать такие: Начинать изучение мода я рекомендую в творческом режиме. Первым делом я рекомендую найти в каталоге с игрой файл config/OpenComputers.cfg, найти в нём и установить параметр bufferChanges=false. Отключение буферизации изменений на носителях OpenComputers позволит тут же синхронизировать их с файлами в каталоге сохранения и наоборот. Благодаря этому можно будет редактировать файлы программ любым привычным тебе редактором, не прибегая к редактору на игровых компьютерах. В творческом режиме есть команда, позволяющая заспавнить компьютер. Направляем взгляд персонажа на твёрдый блок и пишем /oc_sc. В результате появится компьютер в сборе. ШПКМ на системном блоке включает его. Но можно по ПКМ на системном блоке зайти в его интерфейс и нажать кнопку включения. На мониторе мы увидим сообщения загрузки OpenOS с дискеты. NEI позволяет получить готовых: робота, дрона, микроконтроллер в богатой комплектации. С роботом проще всего: он называется Creatix, достаём его через NEI, устанавливаем в мир, кликаем по нему ПКМ и попадаем в интерфейс. Там нажимаем кнопку включения и видим загрузку системы. Устанавливать операционную систему не обязательно, но новичкам полезно это сделать. Набираем команду # install, и следуем подсказкам установщика. После перезагрузки OpenOS загрузится уже с жёсткого диска компьютера или робота. Командой # lua запускаем интерпретатор Lua. В нём можно провести различные эксперименты с синтаксисом языка или исследовать API компонентов. Когда основные конструкции в будущей программе более-менее ясны, или же требуется протестировать многострочные скрипты, имеет смысл создать файл программы. Но т.к. редактировать эту программу мы условились во внешнем редакторе, то в игре мы лишь создаём нужный файл программы. Например, с именем uniqname.lua. Зная имя файла, находим его в каталоге сохранения игры любыми привычными нам средствами. Он найдётся при условии, если ранее мы отключили буферизацию изменений. Этот файл я рекомендую переместить в более удобное для редактирования место, а в каталоге диска OpenComputers создать символическую ссылку на него. Так мы решим сразу две проблемы. Во-первых, файл с программой будет находиться в более привычном для программиста месте. А во-вторых, позволит без лишних размышлений удалять сохранения игры, потерявшие актуальность. При этом файл программы сохранится на своём месте, а вместе с сейвом удалится лишь ссылка не него. Редактируем наш файл любым удобным для нас редактором. Проверяем в игре его содержимое командой # cat uniqname.lua или запускаем его как программу: # uniqname. Думаю, этого достаточно для начала. Но можно продвинуться дальше. Можно посмотреть, что за компоненты находятся в компьютере, который заспавнился командой /oc_sc, изучить их назначение. Можно поместить в компьютер какие-нибудь другие компоненты: разнообразные сетевые платы, красную плату. Можно поставить рядом адаптер, а к нему — разные блоки. Посмотреть, как меняется вывод команды # components и # components -l. API компонентов удобнее изучать в интерпретаторе lua. Там работает автодополнение: можно просто набрать слово component и нажимать клавишу TAB. Если для какого-то компонента отсутствует документация, интерпретатор lua становится незаменимым средством. Возможности роботов и их компоненты тоже можно изучить в интерпретаторе lua. Хотя, можно начать и с чтения документации. Например, на официальном сайте: https://ocdoc.cil.li/ Изучать сборку робота я рекомендую с разборки стандартного Creatix, которого можно взять из NEI. Ставим в мир креатвинвый системый блок, заполнять его не обязательно, он удобен как источник бесконечной энергии. К нему ставим сборщик, а к тому разборщик. Кидаем в него робота, и все его детали постепенно оказываются в сборщике. Скорее всего, будет переполнение сборщика, и часть компонентов выпадет наружу. Это не страшно, подбираем их и смотрим внутрь сборщика. Из сборщика можем достать какие-то компоненты, можем какие-то добавить. Некоторые компоненты можно установить лишь в определённые позиции, а без некоторых робот не соберётся. При нажатии на кнопку старта сборки получим пересобранного робота уже с другим именем. На мой взгляд, новичку удобнее начинать именно с такого способа сборки. Точнее, с пересборки стандартного робота. Тема работы с дронами, микроконтроллерами и серверами, я думаю, уже выходит за рамки базовых знаний, поэтому рассматривать её я здесь не буду. Тем более, большинство схем автоматизации строятся на обычных компьютерах и роботах.

Зависит от того, какими подходами ты уже пользовался. Что именно в моде OpenComputers ты считаешь наиболее сложным?

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

В event.listen мы передаём нашу функцию, которая должна обрабатывать нужное нам событие, а также строку, задающую фильтр по названию события. Когда наша программа выполнила все задачи, требовавшие немедленного выполнения, она обычно вызывает os.sleep. Всю остальную работу выполняет операционная система. Внутри os.sleep вызывается computer.pullSignal, где происходит ожидание события. Название этого события сравнивается со всеми имеющимися фильтрами и при совпадении с каким-либо из них вызывается соответствующий ему обработчик событий. То есть, наша функция, которую мы ранее задали в event.listen. В эту функцию передаются данные, полученные в результате выполнения computer.pullSignal. Вот и вся магия.

Продолжение сильно зависит от твоей собственной инициативы. Простейший вариант программы я написал. Более совершенный вариант тоже возможен, но он требует досконального изучения механик этого реактора. Сам я с этим модом играть не планирую, поэтому самостоятельно исследовать его механики я не буду. А ты более подробную информацию тоже не предоставляешь. Товарищ @Taoshi сначала говорил, что в 1.7.10 можно что-то сделать с помощью мода Mekanism, но потом почему-то стал говорить уже про 1.12.2. Уточнять эту информация я не буду. Если желаешь, сам вытягивай из него, что он имел в виду. Возможно, что-то где-то как-то работает. @Zelenuydrakon Если хочешь продолжения, предлагаю рассмотреть два варианта. Возможно, ты всё-таки найдёшь в каком-то моде работоспособный интерфейс, связывающий нужный тебе реактор с компьютером. Или можешь сам изучить механику реактора, разложив её по тактам. Если предоставишь подробное описание механики реактора, возможно, за написание новой программы кто-то и возьмётся. А под лежачий камень вода не потечёт.

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

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

Это хорошая новость. А есть что-нибудь кроме лозунгов и рекламы? Что именно в этой сборке делает настоящую экономику возможной?

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

Что это значит? В чём он другой, а в чём тот же самый? Я сейчас запустил NuclearCraft-1.9f--1.7.10.jar, но Fission Controller из NuclearCraft у меня точно также не подключился к Reactor Logig Adapter из Mecanism. А как ты определил, что она более ранняя? Судя по данным curseforge, 1.9g является более свежей версией в сравнении с 1.9f.

А как его подцепить к реактору из NuclearCraft? В видеоролике показан не тот реактор, что нам требуется. А к реактору из заказа мне этот адаптер подцепить не удалось.

С температурой мы более-менее разобрались. При желании точность определения температуры можно повысить, как предлагал товарищ @BenniShifer919: Но возникает вопрос, нужно ли это. Во-первых, программа резко потяжелеет. Сейчас она наибольшую часть времени просто спит в ожидании события изменения красного сигнала, ничего не проверяя и не вычисляя. А во-вторых, для правильных вычислений потребуется ещё сильнее вникнуть в механику реактора. Например, я заметил, что реактор включается далеко не в тот же такт, когда на него подан сигнал включения. Между этими событиями проходит случайное количество тактов. На самом деле оно, скорее всего, не совсем случайно, просто я пока не увидел закономерность. Скорее всего, такая же ситуация будет и с отключением реактора: он остановится не мгновенно, и температура успеет подрасти за несколько тактов до фактического выключения реактора. @Zelenuydrakon Теперь вопрос по остатку топлива. Какой именно остаток требуется отображать на экране? Требуется отобразить количество неизрасходованных капсул? Или нужно знать время догорания текущей капсулы? В первом случае решение выглядит простым. А во втором, скорее всего, снова потребуется вникать в механику реактора и опираться лишь на время. Причём, ориентироваться по красным сигналам мы уже не сможем даже приблизительно.

Я реализовал самое простое из решений. Исходным требованиям оно соответствует лишь частично. Для корректной работы требуется правка файла конфигурации ./config/NuclearCraft/FissionConfig.cfg. При значении параметра "The heat at which the comparator will emit a full redstone signal" = 950000 реактор будет включаться при остывании до 88.67% или ниже и включаться при нагреве до 95.00% или выше. Кроме управления реактором программа выводит на монитор 2x1 границы текущего интервала температур, а также стрелочку, сообщающую о направлении движения температуры реактора. Моя тестовая установка выглядит так: Блок песчаника нужен лишь для установки на него компаратора. Его можно заменить другими блоками. Красный контроллер обязательно должен находиться напротив выхода компаратора. Внутри компьютера обязательно должна присутствовать красная плата. Блок компьютера должен находиться в блоке, смежном с блоком контроллера реактора. Но можно дотянуть управляющий сигнал от компьютера какими-нибудь проводами. В любом случае требуется указать номер стороны в переменной rsSwitchSideпрограммы. Код программы: Особенность программы: Программа автоматически находит красную плату и красный контроллер, а также определяет рабочую сторону контроллера. С одной стороны, это позволило избавиться от необходимости вручную конфигурировать программу под конкретную установку. А с другой — программа может воспринять любые красные сигналы, поступающие на красный контроллер, как рабочие. Поэтому при сборке установки важно не подключать к компьютеру лишних контроллеров, а также не подключать к имеющемуся контроллеру никаких других устройств кроме компаратора, подключённого к реактору.

Хорошо. Значит, мне не показалось. А твой скриншот сделан на какой версии NuclearCraft? Я точно помню, что где-то видел похожую картинку с отрицательным нагревом, но не помню, где именно. Возможно, в каком-то видеогайде. Я даже ранее точно так же предложил подглядеть значения нагрева и охлаждения из интерфейса реактора и ориентироваться в вычислениях по ним. Но тестируя версию NuclearCraft-1.9g--1.7.10.jar, я почему-то всегда вижу лишь положительное значение нагрева не только в фазе нагрева реактора, но и в фазе охлаждения. Только цвет надписи меняется с белого на жёлто-оранжевый. А ещё значение генерации энергии при выключении реактора у меня не сбрасывается в ноль. Может, для отображения значения охлаждения нужны какие-то специальные условия? Или оно отображается не во всех версиях мода?

Загляни, если просто. Я с первого раза не нашёл, а на второй у меня не хватило мотивации. Значение интенсивности нагрева я нашёл сразу. А в каком месте посмотреть интенсивность охлаждения?

И, похоже, в изначальном варианте никто не готов его решать. Посчитать температуру, ориентируясь лишь на время, вполне возможно, но для этого потребуется вникать в механику мода. А её даже автор заказа не настолько хорошо знает. Поэтому твой вариант с дополнительным модом весьма полезен. Я же пока склоняюсь к более простому варианту. Предлагаю отказаться от точного отображения температуры и подкрутить конфиг мода, чтобы через красный сигнал определять, в каком диапазоне сейчас находится температура реактора. Размер диапазонов составит примерно 6-7% от максимальной температуры. А ссылочка на само решение имеется, или есть только демонстрация решения?

Идея хорошая, но успешность её применения снова упирается в хорошее знание механики, а у нас тут, похоже, нет желающих копать настолько глубоко. Сам я успел кое-что накопать. Снять показания непосредственно с самого реактора, скорее всего, невозможно. Но их можно получить через компаратор. Сигнал достигает максимального значения примерно при 25% нагрева реактора и это значение можно настроить в конфиге. @Zelenuydrakon А ты играешь на публичном сервере? Или вообще в одиночной игре? Доступ к конфигу имеется? Если конфиг доступен, а точные показания температуры не требуются, то программа получится наипростейшая.

Тогда ещё один вопрос. Скорость разогрева этого реактора не зависит от его температуры, или же возможен саморазгон?

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