eu_tomat

Из OpenComputers файл можно переслать через PUT-запрос. В качестве примера рекомендую изучить pastebin.lua, позволяющий как скачивать, так и отсылать файлы.

И что мешает залить txt-файл тем же путём, каким заливаются html-файлы?

Решение зависит от того, каким образом был сделан сайт. В большинстве случаев загрузка текстового файла ничем не отличается от загрузки других файлов, например, HTML-кода страничек или скриптов. Если же сайт был сделан каким-то конструктором сайтов, то решение зависит от конкретного конструктора. Какой случай у тебя?

На какой сайт?

Программа не может ждать и не ждать одновременно. Но, например, может пытаться получить очередную запись из очереди событий с некоторой периодичностью, если указать нулевое время ожидания: event.pull("modem_message", 0). Даже если назначить обработчик событий через event.listen(...), для его функционирования потребуется периодически вызывать os.sleep(). То есть, в этом случае ожидание тоже не постоянное, его размер и периодичность также задаётся программистом.

Так что именно требуется? Ждать или не ждать?

При наличии драйверов устройство отобразится в выводе утилиты components. API устройства можно посмотреть в выводе components -l. Для 1.12 есть Plethora Peripherals с другим набором драйверов, а про OpenPeripheral для 1.12 я тоже не слышал.

Для обеспечения доступа компьютера к механизмам из других модов следует установить адаптер вплотную к механизму, а сам адаптер подключить к компьютеру, например, кабелем OpenComputes. Также имеет смысл проверить список устройств с помощью утилиты components до подключения устройства и после. Если в результате подключения новых устройств не появилось, то что-то пошло не так: либо адаптер оказался не в общей сети с компьютером, либо механизм не имеет драйвера для работы с OpenComputers. Драйверы многих механизмов поставляются модом OpenPeripheral.

Эти-то причины как раз и не мешают применять semver. Можешь смело переходить на 1.0.0. То была рекомендация а не требование. Semver не мешает начать хоть с версии 100500.0.0 или скакнуть на неё с 0.0.1. Желательно иметь разумное обоснование таких скачков, но это не требование semver. С GUI сложнее. Semver описывает систему версионирования применительно к API. В случае графических интерфейсов появляется широкое поле для субъективных интерпретаций. По идее, мажорная версия должна быть увеличена при глобальном изменении интерфейса. Минорная версия увеличивается при добавлении нового функционала без больших изменений интерфейса. А патч-версия увеличивается при баг-фиксах. Но всё это относительно. Если я переместил кнопку на 100 пикселей выше, это баг-фикс, или изменение интерфейса? С точки зрения пользователя это может быть баг-фиксом. А с точки зрения другого пользователя или какого-нибудь автокликера это может быть нарушением совместимости. А если я добавил так много мелкого функционала в очередную минорную версию, что графический интерфейс стал мало похож на прежний, то стоит ли считать это изменение глобальным и увеличивать мажорную версию? Тут чёткий рецепт вряд ли возможен, и в каждой команде разработчиков могут быть свои предпочтения в версионировании.

Здесь закралась ошибка. Объективно запрета нет. Субъективно же как раз взвешивание "за" и "против". Также, говоря о пользе, имеет смысл уточнять, для кого именно полезно, для достижения какой цели, в какой ситуации. Также изначальный вопрос был "что полезно, и что неполезно", а что имеет право на существование. FAQ спецификации semver содержит рекомендацию начинать разработку с версии 0.1.0, но она необязательна. Тут вопрос не в публичности репозитория, а в том, какую из версий разработчик посчитает достойной назвать релизом. Нулевая мажорная версия обеспечивает разработчику максимальную свободу, не связывая его обязательствами по поддержке существующего API или формата данных. Кстати, какой API предоставляет твоя OCLIDE и с какими версиями API эмуляторов совместима?

А какому пункту спецификации это противоречит? https://semver.org/lang/ru/ Нулевые версии допустимы: Есть пункт, запрещающий ведущие нули в числах: Эту формулировку можно понять так, будто бы запрещёны и нулевые числа, но приведённый пример опровергает это.

А в чём заключается заточка под OpenComputers кроме нестабильной интеграции с эмулятором? И в чём заключается интеграция?

Здесь идёт речь о системе OpenOS, или в целом об OpenComputers? Имеется в виду консоль, ожидающая ввода команды? Какой в это время TPS на сервере?

Для начала надо сделать текущим корневой каталог. # cd / Если затем выполнить pastebin get, то программа установится в корневой каталог. Можно не устанавливать программу заново, а перенести её, воспользовавшись командой move. Решение с установкой в корневой каталог имеет недостаток: после перезагрузки компьютера перед запуском программы снова потребуется сменить текущий каталог на корневой. Проблему можно решить радикально, дописав в коде shell.resolve при вызове fs.exists.

Суть в том, что при установке создаётся каталог /home, и программа, скорее всего, установилась именно в него, а не в корневой. Файлы создаются в каталоге /home, а их наличие проверяется в /. Да, очень похоже. filesystem является слишком низкоуровневой библиотекой. Библиотека io, уровнем повыше, использует вспомогательную библиотеку shell: function io.open(path, mode) local resolved_path = require("shell").resolve(path) local stream, result = require("filesystem").open(resolved_path, mode) Благодаря этому io.open может открыть файл в текущем каталоге без указания полного пути. Но filesystem.open без указания пути откроет файл в корневом каталоге. Смешение кода, работающего то через io, то через filesystem обычно и приводит к описанной ошибке.

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

В норме, кстати, компы не вырубаются. Обычно останавливается код, завёрнутый в pcall. Но pcall не спасает в случае сильных лагов. Вряд ли это так было задумано, но такое поведение не противоречит логике предохранения сервера от запредельной нагрузки. Когда игровой сервер дышит на ладан, то отрубившиеся компы выглядят не самой большой проблемой. И даже если сервер не лагает, всё равно надо как-то останавливать случайно или злонамеренно зацикленные скрипты. Куда возвращать управление? В зависшую программу while true do end?

TLWY не следует воспринимать как какую-то недоработку OpenComputers, эта механика намеренно добавлена разработчиками мода для защиты игрового сервера от зависших или злонамеренно зацикленных скриптов. Что касается злонамеренности, то эта защита легко обходится в несколько строк кода. В рабочих же программах, которым недостаточно окна, предоставляемого TLWY, эта проблема решается не столь красиво, а само решение требует адаптации под задачу и условия сервера. Но во всех известных мне случаях задача решаемая. Если не смотря на принятые меры, программа всё же завершается по TLWY, это может означать лишь то, что нагрузка на игровой сервер превысила все разумные пределы. В этих условиях лучшее, что можно сделать, это прекратить любые действия в программе, тем самым снизив нагрузку на сервер, и, переждав проблемы и не завершившись с ошибкой, возобновить работу. Поэтому меня больше интересует не борьба с TLWY, а вопрос, как сделать механизм TLWY более гибким, чтобы, например, не выключались компы во время загрузки OpenOS, а скрипты с интенсивными вычислениями наоборот бы, блокировались.

Конечно же, можно.

Да, теперь-то, когда проблема была локализована, стало понятно, что надо не swing() выполнять, а повторить forward().

А на твёрдых блоках повреждение свинки зависит от скорости приземления?

Ага. Вот они, серверные нюансы, не проявляющие себя в одиночной игре. Программа уже получила управление после необходимой задержки, но движение робота до сих по не завершено из-за лагов сервера. Robot.scala: if (agent.isAnimatingMove) { // This shouldn't really happen due to delays being enforced, but just to // be on the safe side... result(Unit, "already moving") То, чего не должно происходить на практике благодаря принудительным задержкам, но проверка на всякий случай добавлена. Как оказалось, не зря.

А свинка повреждается при любом приземлении, или только при быстром?

А ещё интересно было бы посмотреть, что именно там возвращают robot.forward() и robot.swing(). В случае неудачи обычно возвращается ещё и её причина.

Почему сложно-то? Я же не предлагаю работать именно с этими фиксированными числами, а иллюстрирую пример с железной киркой. От эксперимента к эксперименту эти числа будут отличаться в силу случайности износа при использовании. По факту же мы с тобой оба предлагаем одинаковое решение, но я даже на два не делю. Какое число я получил от robot.durability(), столько же раз использую инструмент до следующей проверки.