Doob

Если внимательно посмотреть, то заметна еще одна деталь - содержимое экрана рендерится на поверхности, отстоящей от блока экрана. Я так понял, что она настраивается здесь.

Получается, что экраны голографические, в отличии от других модов, где экраны рендерятся другими способами и совпадают с границами блока.

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

Для полетов на свинолете, надо в точке назначения иметь озеро с водой 5x5 блоков, тогда можно безопасно летать.

Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе?

К тому же, при лаге, реактор не будет сваливать тики в кучу. Он их может пропускать, но в такой ситуации, сервер уже лежит и не шевелится.

Искусственное изменение тпс другими модами и плагинами легко отследить - изменение тиков реактора на >10%

Ну с сигналами логика строгая.

Редстоун карта работает всегда, но управлять ей может только включенный комп.

Сетевая карта не генерирует сигналы, пока не открыт порт. Если комп выключен, то порты закрыты.

Если комп выключен и установлено wake-up сообщение, то никаких сигналов не посылается, кроме внутреннего на корпус. Это при получении wake-up

Вообще-то сетевая карта генерирует сигналы. И любой компонент будет генерировать, но управлять им не получится.

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

Для таких случаев и существует Power Distributor и Relay, через них сигналы не проходят.

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

Вообще, это логично. В старых версиях тоже должно работать.

Если компонент находится в другом корпусе, у него только отключается видимость, а функционал остается. Т. е. компонент в одну сторону имеет доступ, а к нему доступа нет.

https://github.com/MightyPirates/OpenComputers/blob/master-MC1.12/src/main/scala/li/cil/oc/server/network/Component.scala

Меня больше смущает oc_wlan, однажды она перестала работать, хотя ничего не изменилось. Возможно, что-то с форжем.

Не понял, в чем проблема, плавятся только блоки индастриала и ванильные.

Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется.

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

Задачу можно решить только статистическим подходом. Можно взять генетические алгоритмы или reinforcement learning, за несколько дней получить модель, которая сможет подглядывать на 100 шагов вперед. Но я не знаю, как представить граф в памяти, особенно с учетом возможностей роботов. 2 мегабайта памяти это вообще ни о чем. В любом случае надо задействовать внешние ресурсы.

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

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

Реалистичный ассемблер очень помог бы в понимании основ. Есть забавные ламповые языки, вроде Forth или Basic. Да и вообще, очень мало таких сложных языков, в которых не разберется простая домохозяйка за пару вечеров.

Ближайший сосед (NNS). Оптимальный по времени и памяти, но непредсказуемый по длине пути.

Антиассемблер какой-то, это даже безумней жаваскрипта. Взяли нормальный язык, покалечили и обозвали ассемблерным.

Даже в ShenzhenIO у ПЛИСов более реалистичный язык, чем это.

17 минут назад, BrightYC сказал:

В каком смысле автообновление? 

Как хочешь добавить поддержку oreDict? 

Работа на ванильных контейнерах - это как? Будешь делать огромные поля из сундуков? 

В смысле, не когда пользователь захочет, а когда обновится в репозитории.

C oreDict все просто, надо только добавить дополнительную структуру данных для фильтрации. Ужас будет, когда моды перейдут в ванильное пространство имен.

Поля из сундуков, да. Но и возможность подключить Refined Storage или Applied Energistics систему. Я просто отделил управление ресурсами от обменного терминала.

От робота я отказался, теперь только транспозеры.

Храню теперь все в csv, чтобы можно было строить красивые графики в plotly. Жесткие диски должны стоять в RAID, купать их незачем.

Вся прога - полный рип, зависимость от тяжеловесной библиотеки, которая больше не работает и обновлять ее никто не будет. Зависимость от мода, который тоже на ладан дышит.

Сейчас в пятый раз перерабатываю концепцию с нуля. Никаких зависимостей, моментальный старт прямо с EEPROM,  автообновление, работа на ванильных контейнерах, без лишних модов.

Это рип. Посмотрел в конфиг, вообще рип.

Пимка - рип.

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

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

Здравствуйте, я - молдавский вирус. В виду бедности моего создателя и общей отсталости развития высоких технологий нашей страны, я не в силах причинить какой-либо вред вашему компьютеру. Пожалуйста, сотрите сами несколько самых нужных вам файлов, а затем разошлите меня по почте своим друзьям.
Благодарю за понимание и сотрудничество.

Проблема из-за того, что изначально программа была в виде пары циклов. Где-то я добавил ветвления, где-то навесил флагов, а где-то пропустил. Давно собирался разбить алгоритм по уму, чтобы не путаться в флагах, но до майна руки не доходят.

Раньше была проверка направления в функции go, т. к. она основная. Но я этот костыль выкинул и ни чем не заменил в новой версии.

С этими побегами понятно, я не мог отловить баг на своих стендах из-за того, что он возникает с вероятностью 1/8.

Был еще какой-то баг, вроде-бы ошибка при чистке инвентаря или во время сортировки.

Ну да, с облаком проще. Я отладку через гит делал. Если сделать сначала проверку версии, то будет универсальный лончер, для чего угодно.

https://github.com/DOOBW/geominer/blob/master/firmware.lua

Вспомнил тут недавно про нематоду OpenWorm, которую реализовали в виде робота.

Такой себе червячок, 1000 нервных клеток. Потянет даже atmega328p, правда, пришлось бы задействовать внешнюю память.

Были бы у меня какие-нибудь мелкие движители, я б по хардкору, на низком уровне, реализовал такого червячка.

В кукбуке есть подробная инфа о некоторых штуках Lua.

https://fingercomp.gitbooks.io/oc-cookbook/content/lua/table-copy.html

Вот-вот, для его возможностей процессор на всю мощь не используется. Хотя, в начале нулевых, японцы умудрялись запихнуть самообучение на 400 MHz, с таким себе распознаванием образов. Так что не удивительно, если он помимо моргания экраном, еще сливает гигабайты телеметрии.

Для данной задачи, вполне хватит ультразвукового датчика, угол у него 15-30 градусов, так что можно им не вращать, а скорости хватает для работы в реалтайме. Хотя, кота через него можно и не разглядеть.

Камеры для определения расстояния не очень надежны, поэтому в теслах они дополняются ультразвуковыми локаторами.

Для сохранения и планирования маршрута, ардуины точно не хватит, про NodeMCU тоже не уверен. Перекопал кучу статей и видео, не нашел ничего автономного.

Полетные контроллеры для дронов делают на базе STM32, идеально подходит по скорости обработки данных и ширине GPIO. И все это без лишних придатков, на чистом C. (хотя, вполне потянет загрузчик с Lua или uPython)

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

Лучше взять нормальный микроконтроллер, а это годится разве только для мигания светодиодом.

Можно прикрутить одну камеру, но скорость работы вообще никакая.

Видел конструкции, где делались два снимка, вычислялась карта глубины и робот прокладывал маршрут. Довольно костыльно, но работает.

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

Можно взять какой-нибудь нормальный проц на ARM, вроде STM32. Такая мощь не снилась оберткам для всяких луа, жаваскриптов и прочих пистонов. К тому-же цена в разы меньше.

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

Сервомоторы имеют обратную связь, иначе они бы не работали, но к этой связи надо подключиться.

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

Вот пример нормальной начинки для робота https://www.youtube.com/watch?v=8LSrYU5G61M

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

Во всяких автономных беспилотниках используют лидары, но у них лютое потребление энергии.

Не понял, откуда 27 МОХ.

На максимальной температуре счетверенный МОХ дает 699.96 eu/t, это при полном переотражении нейтронов, т. е. эффективность 35.

При отражении только с трех сторон и конденсатором с четвертой, получаем 599.95 eu/t и эффективность 30.

Я же натыкал конденсаторов и, чтобы поднять эффективность, полностью закрыл один МОХ, отбирая тепло с корпуса. Но если уменьшить количество элементов, придется ставить закрытые сдвоенные МОХ, что опять дает эффективность 30.

Эффективные схемы на МОХ нужнее, т. к. уран на начальных этапах игры быстро перерабатывается, а плутоний нужен всегда. И у урана нет буста по энерговыделению с повышением температуры, что крайне важно для всяких UU фабрикаторов.

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

Но я ведь делал, повторить могу в любое время, при хорошем пинге.

Я тут накидал сбалансированную по всем параметрам схему, дающую 8099 еутиков, погоняю и покажу, может есть еще что дооптимизировать.