hohserg

Т.е. построить функцию, которая принимает строку а возвращает строку, которая получается отображением каждого символа в строку текущий символ..рандомный символ? Типа, "abc" -> "a(b%cH"

А потом все остальные компоненты редстоуна. А потом весь остальной контент майна А потом forge, чтобы можно было эмулировать работу с модами А потом... Упс, кажется, это уже не эмулятор А вообще, это хорошая идея сделать визуальный индикатор редстоуна, но лучше его сделать не двоичным(вкл/выкл), а полноценно показывающем силу сигнала(например, надписью с числом)

Обнова! Теперь есть инсталятор и апдейтер, процесс установки существенно упростился. Для сравнения До После Оптимизирован сетевой диск: появился файл конфигурации /frequentlyReadedFiles.txt, задающий список часто читаемых файлов. Контент этих файлов отправляется устройствам на ранней стадии инициализации без запросов со стороны устройств. Когда устройству в дальнейшем нужно будет прочитать этот файл, то вся необходимая информация уже имеется локально и не требуются вызовы сетевой карты. Время инициализации снижено с 5.5сек до 3.5сек. А время второй и последующих инициализаций снижено до 2.9сек благодаря сохранению кэша файлов во временной файловой системе. Добавлена программа lua repl - можно в интерактивном режиме выполнять код на устройствах Добавлена серверная команда about - краткое описание, ссылки, версия и благодарности

А верстак этот как обычный блок-инвентарь? Или у него инвентарь существует только пока игрок открывает гуи?

Беспроводной зарядник имеет точку в которую он передает энергию, представленную в виде тройки dx,dy,dz, относительных смещений от центра зарядника. Эта точка может находиться вокруг зарядника в пределах сферы радиуса R(настраивается в конфиге). Ее можно задать и получить программно. Также беспроводной зарядник имеет радиус r разброса энергии вокруг ChargingPoint. Этот радиус также задается программно. Передачу энергии можно включать/отключать wireless_charger.setChargingPoint(dx,dy,dz) dx,dy,dz = wireless_charger.getChargingPoint() R = wireless_charger.getChargingRadius() wireless_charger.setDisperseRadius(r) r = wireless_charger.getDisperseRadius() wireless_charger.setActive(true) a = wireless_charger.isActive() Зарядник работает следующим образом: если он активен, то потребляет каждый тик N энергии(настраивается в конфиге), после чего ищет в сферической области радиуса r в точке dx,dy,dz любые устройства, способные принимать энергию. Для каждого устройства определяется объем пересечения его хитбокса с сферой зарядки. Этот объем делится на объем сферы, получая коэфициент попадания. В результате каждое устройство получает энергию в размере N*min(1, hitV/chargeV). Стоит отметить, что сумма энергии, переданной всем устройствам не должна превышать N(чтобы не было дюпа). С этой механикой можно как-нить поиграться, типо, юзать не сферические радиусы, а кубические области

Верное замечание. Я уже думал над тем, чтобы сделать библиотеку io, аналогично буферизирующую обращение к диску. Также можно сделать отправку больших кусков лога по запросу, как только юзер открывает терминал конкретного устройства

HoverHelm — сетевые диски для тех, у кого нет жёсткого: дронов, микроконтроллеров. Вставляем диск в сервер — через модемы клиенты получают к нему доступ. И пару вкусных фич вдобавок. Фичи и преимущества по сравнению с голым EEPROM Сетевой жесткий диск: можно забыть про ограничение в 4кБ можно делать программы модульными легко обновить программу, не нужно перешивать каждого дрона за всю игру может понадобиться скрафтить только один жесткий диск Удаленный терминал: не нужны клава и моник, больше слотов в роботах централизованное управление всех ваших дронов Обратная совместимость: старые eeprom-программы работают без изменений Какие-то другие очевидные плюсы, про которые я забыл Прогресс разработки Система запускается и работает Виртуальный диск с доступом к папке на жестком диске сервера Удаленный терминал для запуска программ на устройствах Конфигурация Логирование Связь через сетевую и связанную карту Инсталлятор Виртуальный гпу Связь через интернет-карту (Stem) Сохранение имен устройств Удаленные терминалы Минимальные системные требования Конечное устройство Сервер Инструкция по установке Установка сервера: Установите OpenOS Выполнить команду pastebin run xh61Yx8a Отредактируйте открывшийся конфиг Добавьте желаемые к использования сетевые и связанные карты по образцу Можно настроить пути расположения пользовательских папок и папки клиентского ядра Установка клиента: Запустите HoverHelm server hoverhelm/main.lua Выполните команду prepare_eeprom <имя устройства> <адрес серверного модема> <порт> <адрес клиентского модема> Если на сервере одна сетевая карта, вместо адреса её можно вписать тип (modem или tunnel). Адрес клиентского модема можно убрать вообще, если на клиенте только одна сетевая карта. Инструкция по использованию Запустите сервер HoverHelm командой hoverhelm/main.lua Запустите устройства, просто включив их при первом запуске каждого устройства будет создана его пользовательская папка в /home/hoverhelm/devices/<deviceName>/ можно смонтировать по этому пути отдельный диск средствами OpenOS в терминале сервера и в файле лога устройства повится строка <deviceName> started, сигнализирующая о готовности устройства файлы, общие для всех устройств лежат в /home/hoverhelm/device_core/ (coreRootFolder в конфиге) файлы, специфичные для конкретного устройства лежат в /home/hoverhelm/devices/<deviceName>/ (userRootFolder в конфиге) В терминале сервера выполните deviceName>device-program-name args, чтобы выполнить на устройстве deviceName программу device-program-name с аргументом args программа с именем test будет искаться по пути /test.lua и /programs/test.lua, относительно виртуальной фс устройства Из коробки пока доступна только программы reboot и lua В терминале сервера выполните hide, чтобы свернуть HoverHelm server не прерывая его работу можно будет открыть его той же командой для продолжения работы с терминалом Ссылки Гитхаб: https://github.com/hohserg1/HoverHelm

Имеешь ввиду, что теряется логистика энергообеспечения, которая является источником интересного игрового контента? Согласен. Тогда нужно придумать аналогичную логистику для беспроводного энергообеспечения. Сочетать компактность и интересный контент

Беспроводная зарядка позволит строить компактные билды, без кучи проводов Можно усложнить фичу блока-зарядника. Например ,чтобы можно было программно в неком бОльшем радиусе перемещать точку радиуса раздачи энергии. Тогда появится задача оптимального распределения энергии между устройствами вокруг, наведение на пролетающих дронов(зарядка без торможения, очень занятые дроны) Хорошая идея)

Типо, блок беспроводной зарядки ищет в радиусе устройства с апгрейдом-приемником и заряжает их. Чтобы было не очень читерно можно сделать высокие энергопотери и/или дорогой крафт

Попробовал поискать в веб-архиве. Не вышло. Хотя особо не старался, попробовал два сервиса. Было бы здорово организовать на форуме какой-то заповедник для сохранения перезаливов годных наработок

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

Прочитать изображение, получить представление в виде матрицы пикселей в соответствии с форматом и вывести в виде кучи прямоугольников(https://github.com/StarChasers/OCGlasses/wiki/Widget_Box2D)

Предложение: сделать беспроводную зарядку, состоящую из апгрейда-приемника и блока-раздатчика энергии

Действительно

Кстати, микроконтроллерам не требуется проводка, поэтому можно сделать хранилище большей плотности - фулл заполненный n*m*k куб в шахматном порядке. По сравнению с проводными транспозерами будет лишь задержка в один тик на отправку сообщения с инструкциями всем воронкам

А как проверить, что предмет передался за 1 тик? А что, если в задаче конвейер? Типо, нужно постоянно из сундука А передавать стаки предметов в сундук Б и между ними несколько промежуточных сундуков? Тогда имеет смысл активировать все транспозеры синхронно(с точностью до тика). Тогда не учитывая разогрев(передача нескольких первых предметов) и охлаждение(передача последних нескольких предметов) скорость перемещения предметов как раз будет 1 стак/тик независимо от количества промежуточных сундуков. В задаче с конвейером виртуальные компоненты очень помогут. Соглашусь с @eu_tomat: виртуальные компоненты дают прирост производительности на ограниченном классе задач

А отправка по сети сколько времени занимает? ~~~ Кажется, отличная идея: паковать все операции для всех компонентов в один пакет и отправлять broadcast-ом. Таким образом можно уменьшить задержку вызова всех компонентов до задержки вызова broadcast

А робот в выключенном состоянии может выдавать сигнал редстоуна? Если нет, то можно обезопасить схему, добавиви инвертор между роботом и реактором и также инвертировать работу с редстоуном в программе. Если робот по какой-то причине выключится, то выключится и реактор

Судя по всему нужно скачать и прошить через flash. Рекомендую попробовать вот этот современный bios:

Жидкость в универсальной жидкостной капсуле хранится в нбт, а не в метадате. Если в сборке установлен OpenPeripherals, то посмотри это Можно получить отпечаток конкретной капсулы с жиждостью и юзать этот отпечаток в качестве аргумента me_interface#requestCrafting

Кстати, до сих пор я не видел чисел. Проводились ли кем-то статистические исследования TLWY? Известна ли зависимость вероятности возникновения TLWY от тпс при использовании какого-то эталонного кода(типо, бесконечный цикл с ожиданием 0 сек внутри)?

А если сделать кучу вложенных pcall? Это позволит размазать вероятность TLWY по ним всем и тем самым уменьшить вероятность TLWY на pcall верхнего уровня?

TPS можно измерить просто сравнив задержку os.sleep(n) с изменением реального времени, взятого где-нить из инета А если TLWY вывалится снаружи pcall?

А какие есть способы решения этой проблемы?