Fingercomp

Мммм! И ещё кто-то пилит то же самое даже.

Числовые операции (например, операторы <, >, +, *, ...) бросают ошибку, если скормишь им nil.

На версиях вроде MC 1.12 энергия была конечной даже до введения этого конденсатора. Ибо Forge добавил свою энергосистему, а возможности узнать, какие моды предоставляют её, не дал. И генератор в первую очередь из-за этого нужен был. Если отвечать на вопрос, то теперь не детектится отсутствие модов, поэтому если не нужно потребление энергии, то отключать требуется в конфиге.

Эм. Никак?

Он вышел раньше, чем я предполагал — ниже список нового. Сила овец и оцелотов в их пушистости. Теперь пушистость можно приложить к делу и питать компы — с помощью ковровых конденсаторов. От обычных конденсаторов они толком не отличаются, но могут генерировать энергию, если по ним ходят минимум 2 пушистых животных: овцы или оцелоты, которые генерируют больше энергии. Все новые процессоры, которые будут скрафчены, будут с Lua 5.3 по умолчанию. Сменить можно так же — шифт-пкм. К беспроводной карточке, которую мы все знали, теперь добавили урезанную версию T1, тоже беспроводную. Она может открывать только 1 порт и стрелять сигналом на 16 блоков, а не 400. Креативная компонентная шина (штука, пихабельная в серверы), которая добавляет 1024 компонента. Логичное дополнение. Роботов можно подключать к компьютерам как компоненты. И менять имя роботов: то, что раньше делалось в наковальне, теперь можно через setName и getName. Робот должен быть выключен, чтобы функции работали. Починены всякие проблемки с рендерингом всяких символов. Блоки-инвентари иногда не сохраняли содержимое при сохранении мира. Дроны с чанклодырями не всегда грузили чанки. Пофикшена интеграция с AE2. computer.addUser неправильно отдавал ошибку как-то. Хитбоксы у кабелей теперь обтягивают их форму. Раньше кабели-пересечения были с хитбоксом на весь блок. Апгрейд крафта не всегда крафтил, когда должен был. Апгрейд крафта крафтил один предмет и ломал рецепт — для всех, в том числе игроков. Весело. Датчик движения как-то коряво работал. Пофикшена работа роботов с предметами-инвентарями вроде жидкостных ячеек IC2. Устранена возможная утечка памяти в сетевом коде. В MC 1.10+: пофикшена getMetadata у дебаг-карты. В MC 1.10+: добавлена getBlockstate для дебаг-карты. В MC 1.12: нельзя было заменить EEPROM дрону. В MC 1.7.10: добавлены getAllStacks и inventoryName для транспозеров с инвентарных апгрейдов. Обновлён французский перевод. В OpenOS: Обновлён install.lua, чтобы работал более предсказуемо. uuid.lua возвращает правильные UUID 4 версии, как в RFC написано. Фиксы всякие поддержки vt100. Утечка памяти при загрузке процессов (есть и такая, даже в Луа). Более конкретные комбинации клавиш: Ctrl+Alt+Delete не будет считаться за Ctrl+Delete, например. Вайтлиста измерений для чанклоадера... ну, их пока нет. Скачать.

В теме нигде не нашёл упоминания, что если даже AE будет поставлен, то его адски занёрфят, отрежут всё нафиг, оставят пару блоков — убьют в нём смысл, по сути, так как очень к тормозам и заборам из труб стимулирует.

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

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

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

Я б советовал сразу отсюда юзать: https://github.com/ben-mkiv/OCGlasses — там сложнее, но есть вика внятная. World Located — рисуются в мире 3д-объектами. Вокруг них можно ходить, например, как вокруг блока обычного. Overlay Located — рисуются на HUD игрока, как хотбар или шкала здоровья. Можно визуализировать, но для этого нужно писать свою прогу. Или найти готовую, кто-то делал уже, я думаю. Очки рисуют то, что ты на компе через компонент моста укажешь. Если на компе будет кол-во энергии от робота, полученного, например, по сети, можешь и это рисовать. Сам пример я дать не могу, ибо тестить негде. Вот ссылки: Рисование моделек OBJ. Ещё мы юзали эти очки в сервере UT#2, можешь посмотреть на файлики.

Сам на Arch Linux сижу. Всё отлично идёт.

Оказывается, они есть только в кубаче 1.10 и выше. Разобрался с этим утром и отрепортил.

Потоки — очень полезные штуки, позволяющие исполнять несколько кусков кода. Раньше для их использования приходилось скачивать отдельную библиотеку, работающую через костыли. Начиная с OpenOS 1.6.4, они есть в стандартной поставке ОС — в модуле thread. Давайте посмотрим, из чего она состоит — и в чём её преимущество перед любыми другим библиотеками. Начнём с версий. OpenOS 1.6.4 — версия, включённая в OpenComputers 1.7.0. Если не хотите возиться с обновлением системы вручную, требуется иметь версию выше или равную 1.7.0. Сразу обращаю внимание на самую важную вещь: потоки не могут исполняться одновременно. В один момент времени только один поток может работать. В чём тогда красота тредов? Они автономны, то есть: Начинают исполнение сразу же после создания. Передают исполнение в другие потоки в местах, указанных использователем, — при том или ином вызове computer.pullSignal (os.sleep, event.pull и т. д.). Автоматически продолжают своё исполнение без необходимости самостоятельно их стартовать. Потоки можно убить и приостановить. Они неблокирующие: Вызов computer.pullSignal не блокирует исполнение других потоков. Они отцепляемые: Процесс, в котором был создан поток, называется родительским. При завершении родительского процесса все потоки останавливаются. Поток может отсоединиться от родительского процесса и работать полностью автономно — например, как слушатели событий. Поток может сменить родителя на другого. Поток сам является процессом и потому может создавать дочерние потоки. Работающий поток не даёт завершиться своему родителю. Они независимы при обработке событий: Потоки не наследуют и не передают дочерним свой набор слушателей событий. Все слушатели событий и таймеры принадлежат только конкретному потоку. Как следствие, поток не может изменять их набор в другом. Слушатели и таймеры автоматически удаляются при завершении потока, даже если завершение вызвано ошибкой. Приостановленные потоки игнорирует события. Если несколько потоков вызвали event.pull на одно и то же событие, они оба его получат. Этот набор фич в таком объёме присутствует только в этой библиотеке, и ни одна другая и не даёт столько простоты в работе с ними. Пожалуй, приступим к использованию. Потоки создаются функцией thread.create: первым аргументом передаётся функция, дальше идут аргументы к ней. local thread = require("thread") local t = thread.create(function(a, b) print("В потоке получены аргументы:", a, b) end, 21, 42) Функция возвращает объект потока. Его же может получить сам поток вызовом thread.current() — однако если вызвана не в потоке, то возвращает nil. На всякий случай, основной процесс не является потоком. Объект потока позволяет чудить различные вещи с потоком. t:suspend() приостанавливает поток. Как уже сказано, такой поток не будет получать события и обрабатывать тики таймера. Забавно, что если приостановить поток, когда он ждёт события, то неизвестно, что он получит после его возобновления. t:resume() возобновляет работу ранее приостановленного потока. Так как созданные потоки сразу начинают работу, то обычно этот метод вызывать не придётся. t:kill() убивает поток, то есть завершает его, удаляя всех слушателей и таймеры. Возобновить работу потока после того, как он убит, нельзя. t:status() возвращает строку со статусом потока: "running" — поток работает или блокирован другим. Такой поток не даёт завершиться своему родителю. "suspended" — поток приостановлен. Его дочерние потоки также будут приостановлены. Когда родительский процесс завершается, такой поток автоматически убивается. "dead" — поток мёртв. t:attach() позволяет сменить родителя у потока. Без аргумента поток будет присоединён к текущему процессу. Переданное как аргумент число позволяет указать, к кому присоединить: 0 — текущий процесс, 1 — родитель текущего и т. д. t:detach() отцепляет поток от родителя. Такой поток будет работать до его остановки или перезагрузки компьютера. t:join() останавливает процесс, в котором была вызвана это функция, до завершения потока t. local thread = require("thread") local t = thread.create(function() os.sleep(10) end) t:join() -- остановится на 10 секунд Можно передать первым аргументом этой функции число, которое будет служит таймаутом (в секундах). Тогда, если не успеет завершиться поток за это время, join завершится досрочно. t:join ждёт только одного потока. Для групп потоков есть функции thread.waitForAny и thread.waitForAll — обратите внимание, что это функции библиотеки, а не методы объекта потока. Обе функции первым аргументом требуют таблицу с потоками, а вторым опционально можно задать таймаут. thread.waitForAll ждёт, пока завершатся все потоки из списка. local thread = require("thread") local t1 = thread.create(function() os.sleep(10) end) local t2 = thread.create(function() os.sleep(15) end) thread.waitForAll({t1, t2}) print("Это сообщение будет написано через 15 секунд") thread.waitForAny ждёт, пока завершится хотя бы один поток из списка. local thread = require("thread") local t1 = thread.create(function() os.sleep(10) end) local t2 = thread.create(function() os.sleep(15) end) thread.waitForAny({t1, t2}) print("Это сообщение будет написано через 10 секунд") Что будет, если поток бросает ошибку? При ошибке в потоке она не будет проброшена в родительский процесс. Как и со слушателями, она будет записана в файл /tmp/event.log, но родитель не сможет узнать причину ошибки — и, вообще, успешно ли завершился поток. local thread = require("thread") local t = thread.create(function() os.sleep(3) error("test") end) print(t:status()) --> running t:join() print(t:status()) --> dead Кроме того, событие жёстокого прерывания (Ctrl+Alt+C) не передаётся всем процессам — только одному; причём неизвестно, какому именно: родителю или одному из его потоков. Если вы используете потоки, первым делом сделайте один, который будет ждать события interrupted и подчищать ресурсы. local thread = require("thread") local cleanupThread = thread.create(function() event.pull("interrupted") print("Принял ^C, чищу всякие ресурсы") end) local mainThread = thread.create(function() while true do local input = io.read() if input == "exit" then break end end end) thread.waitForAny({cleanupThread, mainThread}) os.exit(0) Обратите внимание, что в конце программы стоит os.exit. Я уже упоминал не раз, что родительский процесс, достигнув конца программы, не завершится до тех пор, пока работает хотя бы один из его дочерних потоков. Вызов os.exit() позволяет выйти из программы, закрыв все дочерние потоки. Что, безусловно, достаточно удобно. Есть ещё один момент. Допустим, данная программа запускается в роботе: local robot = require("robot") local thread = require("thread") local moveThread = thread.create(function() while true do robot.forward() end end) local inputThread = thread.create(function() while true do local input = io.read() if input == "exit" then break end end end) thread.waitForAny({inputThread, moveThread}) os.exit(0) Если вы запустите эту программу, то должны заметить, что вы ничего не сможете написать в роботе, хотя работает io.read. Дело в том, что функция robot.forward вызывает метод компонента, который блокирует исполнение компьютера. Пока робот двигается, на компьютере не может выполняться ни одна команда. Чтобы хоть что-то можно было вставить в строку, то поставьте после robot.forward какой-нибудь os.sleep(0) — он позволит соседнему потоку принять и обработать события. Тем не менее, строка ввода всё равно будет работать с тормозами. В подобном случае задумайтесь над тем, чтобы использовать вместо строки ввода иное средство коммуникации: редстоун, сеть, интернет-сокет. Несмотря на всё, библиотека действительно облегчает работу с потоками в OpenOS. Кроме того, очень удобно поместить все слушатели событий в один поток, чтобы они все автоматически были удалены после убийства потока. local event = require("event") thread = require("thread") local mainThread = thread.create(function() event.listen("key_down", function(evt, addr, key, code, user) print("A key has been pressed!") end) while true do print("do something") os.sleep(0.5) end end) -- событие interrupted не ловится обработчиками local intThread = thread.create(function() event.pull("interrupted") end) thread.waitForAny({mainThread, intThread}) os.exit(0) Не нужно функции сохранять в переменные и помнить, что нужно ставить event.ignore в конце программы; не требуется ребутать компьютер, если программа завершилась с ошибкой, а до отключения слушателей дело не дошло. В общем, красота.

Забавно, что иридий стоит дешевле распылителя пены. Даже 60 UU дёшево — но раз это для людей, которым небезразлично будущее сервера (а мне, судя по этому, безразлично абсолютно), то пусть хотя бы 50-60 UU стоит.

Заданный в ОП вопрос действительно интересен, поэтому я отвечу на него. term.read, io.read, io.stdin:read — вот вся эта дружная команда не исполняется параллельно — понятно почему, я думаю. А если нужно? Значит, или ввод, или выполнение действий таки надо заставить работать параллельно. Если два сделать, то получим демон, который захватит ввод, что достаточно глупо. Потому и варианта 2. Вариант 1. Вынести ввод в параллель. Обозначенные выше команды не исполняются параллельно, как я уже сказал. Мы можем переписать их так, чтобы они ловили ивенты листенерами, а не пуллом — получим собственную GUI-библиотеку. Можно облегчить себе задачу, и использовать стороннюю GUI-библиотеку. Этот вариант предпочтительнее, если ещё нужно рисовать кого-то, помимо ввода. А можно попробовать вынести ввод в тред. Треды — это такие штуки, которые были добавлены в одном из не столько давних обновлений OpenOS, и позволяют исполняться нескольким блокам кода параллельно — но не одновременно! Только что-то одно в данный момент времени, а переключение между тредами будет по os.sleep или event.pull. Если у тебя в фермере после каждого вызова долгого метода (любое движение у робота таковым является) будет стоять хотя бы os.sleep(0), то можешь поставить такое: local term = require("term") local thread = require("thread") thread.create(function() while true do local input = term.read() -- всё, дальше можем обрабатывать ввод end end) Есть у меня сомнения, что os.exit() из треда сработает, но можно попробовать. Сами треды чистить не нужно — они сами остановятся при завершении процесса. Вариант 2. Параллельным делать обработку действий. Этот вариант оптимальнее, говорю сразу. Чтобы совсем ничего не менять, то можно просто обернуть саму обработку в отдельный тред, как в коде выше мы ввод принимали. Я бы так и сделал. А можно зарегистрировать слушателей событий с помощью event.listen. Первым аргументом имя ивента, вторым — функция-обработчик. Нельзя забывать поставить event.ignore в конце программы, иначе слушатель будет работать, как демон, вне процесса. Аргументы те же. Треды в этом плане лучше гораздо. В них можно даже регистрировать слушателей, и они автоматически подчистятся с выходом из программы, в том числе и при ошибке.

В OpenComputers невозможно же. Просто памяти не хватит. И процессора.

Хочешь попросить, чтобы на стороне сервера робот (или что-то ещё) отрендерил картинку с помощью клиентского кода и затем ещё куда-то её отправил? ...Это не только невозможно; честно говоря, это вообще бред.

Пусть будет 20000. Без разницы толком, лишь бы число было не слишком большим и не слишком мелким.

Библиотека проста, только её читать... ещё то удовольствие это, с таким-то стилем кода. Но это субъективно. Что она делает? Попробую расписать, основываясь на том, что я прочёл. Пусть будут 3 корутины. Запустим #2 из #1. Обычно третью корутину из второй запускаем с помощью coroutine.resume — но после выскакивания из #3, управление будет в #2. С помощью библиотеки же можно вызвать coroutine.resume другой корутины, при этом стопнув текущую. То есть при вызове из #2 управление будет передано в #1, откуда затем сразу же пойдёт оно в #3, а потом, когда #3 стопнется, вернётся в #1. ...Зачем только? P. S. Пример совершенно непонятен.

А разве какие-то фиксы там не брались для витчери?

Прочитайте описание пунктов ниже перед голосованием. Так получилось, что в чате возникли отдельные всплески нытья и несогласия с курсом сервера. Поэтому было предложено провести голосовалку, которая закрепит основные вопросы по направлению сервера. Подчёркнутые опции означают те, которые выбраны были при разработке сервера. На практике это означает, что при их выборе Алексу придётся меньше возиться, так как с ними уже заготовлен сервер, то есть он откроется быстрее. Это означает, что для них уже имеются фиксы. Голосование длится пару дней. Не успели — просьба потом не ныть. Мод на голод? Их установлено несколько штук. Один всякие культуры добавляет, другой заставляет питаться чаще и разнообразнее. Настройки достаточно щадящие и новичка сразу с ног не валят. Если вы выбираете... Да — нужно будет задумываться о рационе, брать еды с собою и здорово кушать. Нет — тогда можете до скончания веков жрать яблоки, а ваш персонаж от этого даже с ума не сойдёт. Ведьмовский мод Witchery? Всякие колдунства, заклятия, фамильяры и прочие ведьмины прелести жизни. Потому что это весело. Не все постигли дзен и способны тереть нос свой о монитор OpenComputers, а так можно всяких сов и кошек повызывать. Если вы выбираете... Да — мод этот остаётся, можно будет жечь ведьм. Нет — мода не будет. Таум и аддоны? Есть Таум и несколько штук аддонов к нему. Добавляют вместе они несколько палочек, которыми можно махать и воплощать волшебства разной степени сложности, и другие средства для творения магии. Если вы выбираете... Да — будет таум и комплект приложений к нему. Нет — магия вам противна, и это будет принято к сведению. Тинкер? Tinker's Construct, который добавляет более продвинутые и модульные инструментики. Почему-то некоторым не нравился. Если вы выбираете... Да — можете наслаждаться удобными инструментами. Нет — придётся обходиться обычными кирками, крафтить и чаровать их наудачу.

Он с нескольких акков ВК голосовал. А тут-то ему мульты не нужны.

Я тут один заметил, что Алекс валюту эту хочет сделать как раз потому, что не нужно к UU привязывать? Вы о чём вообще тут ведёте беседу? UPD. Вот сообщение, где об этом говорится. То-то @newbie с десяти аккаунтов голосует, ага. Очень ограниченное количество.

Ну это уже за гранью "нихрена себе".

Сенсор координаты и углы направления взгляда возвращает. А дальше немного математики.