Anon

Копаясь среди компонентов и функций, я остановился на eeprom: Функция makeReadonly зачем-то требует хэш данных, записанных на eeprom. Причем параметр обязательный, и обязательно должен соответствовать хэшу данных на eeprom. Самое смешное, что этот хэш можно получить другой функцией eeprom - getChecksum. Судя по исходникам, ни для чего, кроме проверки в функции makeReadonly этот хэш не используется, но вот если он будет неправильный, то вернётся ошибка. Зачем это вообще было сделано?

Хочу заметить пару интересных деталей поведения vram-буферов, найденных эмпирическим путём, о которых в документации не сказано: Активные цвета видеокарты (setBackground и setForeground) привязаны к vram-буферу. То есть переключив активный буфер, вы так же переключаете и активные цвета, установленные в этом буфере. Очень удобно, на мой взгляд Палитра цветов (setPaletteColor, getPaletteColor) привязана к vram-буферу, но ведёт себя немного иначе. Ведь палитра цветов, как известно, сохраняется даже при перезагрузке компьютера (Причём, что интересно, привязана к монитору, а не к видеокарте. То есть поменяв местами видеокарты двух компьютеров, не меняя местами мониторы, палитра каждого компа останется своей). И каждый vram-буфер тоже имеет отдельную палитру. Но вот при перезагрузке, сохраняется только палитра экранного буфера (под индексом 0). В любом случае приятно, что буферы имеют личные background, foreground, и palette. На данный момент, это всё, что я нашёл. Надеюсь кому-нибудь эта информация пригодится

@ProgramCrafter Значит я неправильно понял сообщение об ошибке. Так или иначе, получить полный стектрейс в этом случае не получится.

Надеюсь, проект ещё жив, но на свежую OpenOS ставиться отказывается

Нет, нельзя. В стеке вызовов видно, что ошибка происходит в /lib/process.lua. А происходит она, скорее всего, из-за неверного значения переданного в одну из функций библиотек OpenOS аргумента. Судя по всему, стек вызовов настолько большой, что debug.traceback заменила его часть на "(...tail calls...)". Это недоработка разработчиков самого lua, так как во время отладки важно видеть первые вызовы, а не последние.

Вопрос неоднозначный. Как такового файлового потока stderr, по аналогии с реальными машинами, в opencomputers нет. То что вы видите - фактически сообщение об ошибке красного цвета. Если вы хотите самостоятельно обработать ошибку, произошедшую в рантаеме, есть два способа: Самый простой вариант - pcall local result, value = pcall (function () --[[ ... ]] end) Если функция, переданная в pcall первым аргументом, выполнена успешно, первое возвращаемое значение будет true, а все последующие - значения, которые вернула исполняемая функция. В обратном случае, первым значением pcall вернёт false, а вторым - сообщение об ошибке, которое вам нужно. Однако, при использовании pcall, вы получите только сообщение об ошибке, но не стек вызовов, который показывает OpenOS. Другой, более навороченный вариант - xpcall local function errorHandler (errorMessage) print ("Runtime error: " .. errorMessage) print (debug.traceback ()) end local result, value = xpcall (function () --[[ ... ]] end, errorHandler) Если функция, переданная в xpcall выполнена успешно, то возвращаемые значения будут такие же, как и с pcall. А если во время выполнения функции произойдёт ошибка, то вторым значением xpcall вернёт то, что вернула функция-обработчик. То есть xpcall вызывает обработчик, вместо того чтобы просто вернуть ошибку. Но в чём же профит, спросите вы? Тут есть один занятный момент: обработчик ошибок вызывается именно в том месте, в котором произошла ошибка. А это значит, что debug.traceback, вызванный в обработчике, вернёт стек вызовов актуальный для контекста ошибки. Хитрым образом эту фичу использовал @ECS в процессе разработки MineCode IDE для реализации брейкпоинтов: В том месте кода, где пользователь поставит брейкпоинт, намеренно произойдёт ошибка, которую потом поймает обработчик и покажет отладочную информацию. Таким образом, выполнение программы безопасно прерывается в нужном месте. Кстати, пожалуй, удобнее всего обрабатывать ошибки так: local result, value = xpcall (function () --[[ ... ]] end, debug.traceback) if not result then print (value) end Поскольку debug.traceback конкатенирует свой аргумент со стеком вызовов.

Рутмастер, попробуй рассуждать логически. Допустим не будет. Почему?

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

Можно. Но я не знаю как реализована функция pull_e. Если она использует базовое апи computer, тогда в качестве аргумента computer.pullSignal передайте 0 computer.pullSignal (0) Если же вы используете библиотеку event из OpenOS, то в event.pull аналогично первым аргументом передайте 0 event.pull (0, eventType) Однако стоит заметить, что если каждый кадр вы рисуете целиком (очищаете экран, ставите надписи итд), то при таком подходе интерфейс будет, скорее всего, мигать. Хотя это уже другая тема, здесь поможет двойная буферизация.

Скорее `сломан брайль`

Иногда удобно использовать встроенное средство редактирования файлов OpenOS. Однако мне никогда не нравился дефолтный чёрный цвет фона. Поэтому я немного модифицировал edit.lua так, чтобы цвета легко настраивались. Установка проще, чем заварить чай. Достаточно скопировать и запустить следующую команду (OpenOS должна быть установлена). wget -f https://raw.githubusercontent.com/Smok1e/oc-openos-colored-edit/main/edit.lua /bin/edit.lua Настроить цвета можно в стандартном файле конфигурации - /etc/edit.cfg В конце файла добавьте (или измените) следующее: colors = { background = [желаемый цвет фона], foreground = [желаемый цвет текста] } Например: Спасибо за внимание. Кстати если кто-нибудь знает, каким образом можно изменить цвета стандартной оболочки OpenOS, буду признателен, если расскажете.

Типичный сотрудник ubisoft:

1) Магические числа - быдлокод. Что за 48 и 57? string.byte ('0'), string.byte ('9'). 2) Результат будет всегда 8-значный или N-значный 3) math.floor?????? Ну и наконец, math.random возвращает целое число, если в него передать целое значение. math.random (10000000). О производительности твоего примера я даже боюсь говорить. Вызов string.char в цикле, конкатенация строк, которые в луа иммутабельны просто убьют процессор, если функция будет использоваться часто.

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

Пробовал по аналогии установить окну .onClose, но ничего не происходит.

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

Предлагаю добавить функцию зарядки предмета, если рядом стоит зарядник из ic2 или других модов. Серьёзная проблема в том, что алмазная кирка ломается буквально за 1 проход робота, куда удобнее использовать алмазный бур и заряжать его.