eu_tomat

Эта ошибка ничего не говорит о том, подключился ли мост. Покажи вывод команды components br.

Сейчас проверил. Адаптер нужен. Что именно не получается? Что выдаёт команда components br?

Не помню точно. По-моему, через блок адаптера подключается.

В интернете вообще есть информация про это: Гайд по OpenPeripheral#1 Terminal Glasses.

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

Не обязательно анализировать все слоты. Опроса единственного слота достаточно для вычисления количества прошедших реакторных тиков, что даёт знание не только текущего износа всех конденсаторов, но и того, на каком тике тот или иной конденсатор не сможет поглотить предназначенное для него тепло. Можно и вообще не опрашивать слоты, ориентируясь исключительно на время работы реактора между включением-выключением. Согласен: есть шанс не успеть для этой схемы и с таким TPS. Чисто теоретически для безопасной работы достаточно было бы и 1 TPS. Но мы же говорим о среднем значении, а в какой именно момент слоты времени достанутся управляющему реактором компьютеру на перегруженном сервере, угадать невозможно. Но при аккуратной работе шанс взрыва даже этой схемы и даже с таким TPS очень мал. Аккуратная работа: Загрузили реактор топливом и конденсаторами Вычислили время ближайшей замены конденсаторов, уменьшив его на половину реакторного тика. Подали сигнал красной платой, находящейся в управляющем компьютере. Выждали нужное количество реакторных тиков в os.sleep и убрали красный сигнал. Заменили уже непригодные конденсаторы. Их даже проверять не надо, они вычислены ещё до пуска реактора. Вычислили время ближайшей замены следующей партии конденсаторов и т.д. по кругу. Так как время работы реактора уменьшено на половину реакторного тика, конденсаторы могут чуть не догореть до своего предела. Эту недоработку тоже можно исправить, но это вопрос отдельной тема с большим количеством текста и практических исследований. Если кратко: надо поддерживать синхронизацию компьютера с реакторными тиками, минимально нагружая сервер. Это трудно сделать, учитывая, что синхронизация регулярно теряется, а точно восстанавливать её на сервере с низким TPS бывает проблематично. А в это время надо не только синхронизацию поддерживать, но и параллельно выполнять замену компонентов реактора, что нелинейно усложняет алгоритм.

@ECS О какой библиотеке идёт речь? Стандартная библиотека в составе OpenOS не может корректно работать с таким кодом.

Да, это первое, что стоило попробовать. Но, насколько я помню, filesystem позволяет одновременно держать открытыми максимум 16 файлов. Поэтому рано или поздно потребуется ограничить количество файлов и хранить несколько виртуальных файлов внутри одного, используя аналог файловой системы. В этом случае проще будет использовать единственный файл. А уже тогда можно будет с лёгкостью отказаться от компонента filesystem, получив дополнительное ускорение. И B-tree будет выглядеть более уместно. Просто советчики немного забежали вперёд, а по сути их предложения вполне обоснованы.

Держа диск в руке, нажимаем правую кнопку мыши. В появившемся интерфейсе нужно выбрать режим "unmanaged". Теперь этот диск будет определяться не как filesystem, а как drive с соответствующим набором свойств и методов. Компонент drive позволяет посекторно читать с диска и писать на него примерно в 6-7 раз быстрее, нежели при работе с компонентом filesystem. А что мешает всё хранить в одном файле? К слову, использование режима unmanaged очень похоже на работу с единственным файлом. Также поверх unmanaged-диcка можно написать свою файловую систему, позволяющую держать нужное количество файлов постоянно открытыми.

В качестве БД можно использовать один постоянно открытый файл или же ограниченное количество открытых файлов. Это позволит исключить затраты на открытие-закрытие файлов.

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

Невозможно добыть, опасно заполнить и бессмысленно хранить. К слову, автор уже использует AE как часть общей системы. И главная её проблема не в том, чтобы заполнить, а в том, чтобы как-то разумно использовать, о чём сразу и сообщил автор: Так что, главная трудность ещё впереди.

Тогда почему эта тема находится в разделе "Программы"? Чем не устраивают разделы "Идеи" или "Беседка"? И это даже не концепт, а, скорее, набросок концепта. Лично я не понял, как это работает. Зачем нужен контроллер? Как связана сеть контролеров и транспозеров? Как расшифровать эту схему? Это вид сверху, сбоку или в разрезе? Как всё это выглядит в объёме? Что значит, каждый блок? Если архитектура всех блоков одинакова, то каким образом их можно разделить на типы? А если не одинакова, то чем отличается структура блоков одного типа от структуры другого?

Понимаю, что реакторных схем с выходом энергии не менее 19 k eu/t не так много. Тем не менее, важно конкретизировать требуемую схему. Реализация универсального алгоритма оптимальный замены потребует гораздо больших усилий от программиста, и не факт, что она окажется устойчивой на перегруженных серверах. Для конкретных же схем составить оптимальный план замены конденсаторов заметно проще.

> return reguser:sub(4) 0a4d55a8d778e5022fab701977c5d840bbc486d0,d8f4590320e1343a915b6394170650a8f35d6926,8888

Не будем ему в этом препятствовать. Каков формат этих данных? Как их интерпретировать? Какой участок строки отвечает за что? Какой критерий позволяет определить, что versions = 1.1?

Сеанс телепатии прошёл неудачно. Я счёл вводные данные ошибочными. Но предположим, ошибки нет. Получается, что поля данных внутри исходной строки перекрывают друг друга. Это ошибка, или так и задумано? local reguser = "1.10a4d55a8d778e5022fab701977c5d840bbc486d0,d8f4590320e1343a915b6394170650a8f35d6926,8888" local reguser = "1.10a4d55a8d778e5022fab701977c5d840bbc486d0,d8f4590320e1343a915b6394170650a8f35d6926,8888"

> reguser = "1.1,10a4d55a8d778e5022fab701977c5d840bbc486d0,d8f4590320e1343a915b6394170650a8f35d6926,8888" > t={} > for s in reguser:gmatch("([^,]+)") do t[#t+1]=s end > versions, login, pass, seed = table.unpack(t) > > print( versions ) 1.1 > print( login ) 10a4d55a8d778e5022fab701977c5d840bbc486d0 > print( pass ) d8f4590320e1343a915b6394170650a8f35d6926 > print( seed ) 8888

OpenOS является не единственной операционной системой для OpenComputers. А механизм доступа к запущенным процессам полностью определяется именно операционной системой.

А разве ошибка 403 не является ответом сервера? Или OC может каким-то образом сам её подсовывать вместо ответа сервера?

Это в какой-то определённой серверной сборке ответ игнорируется, или OpenComputers так себя ведёт с настройками по умолчанию?

О какой операционной системе идёт речь?

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

Если движок сайта выдаёт ошибку 403, то обычно это никак не обойти. Если доступ блокируется по IP, то может помочь доступ через прокси. Если ошибка выпадает не постоянно, тогда, пользуясь временной возможностью, можно залить файлы на промежуточный сервер. Но какой в этом смысл, если требуется актуальная версия логов?

Звучит так, будто бы это форум нытиков. Подозреваю, для кого-то так и есть. Местная ячейка партии нытиков хотя и ослаблена, но до сих пор жива. Но кому интересен изначальный замысел форума, те задают вопросы как по OpenComputers, так и по ComputerCraft и пишут программы. Нет другой активности, кроме той, что создаём мы сами. Кстати, надо отдать должное критикуемому в этой теме моду. Хотя большинство из нас и оказалось на форуме благодаря урокам @1Ridav по Lua в ComputerCraft, тем не менее подавляющее большинство программ написано форумчанами именно для OpenComputers.