hohserg

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

Беспроводной зарядник имеет точку в которую он передает энергию, представленную в виде тройки 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, аналогично буферизирующую обращение к диску. Также можно сделать отправку больших кусков лога по запросу, как только юзер открывает терминал конкретного устройства

2 минуты назад, Alex сказал:

И нет цепей, переключателей, распределитей, накопителей и проводов

Имеешь ввиду, что теряется логистика энергообеспечения, которая является источником интересного игрового контента?

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

50 минут назад, Alex сказал:

В чем игровой интерес или новый геймплей?

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

50 минут назад, Alex сказал:

Может лучше какой-то апгрейд программируемый лучше добавить?

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

7 минут назад, Alex сказал:

зарядку в радиусе и батареек всяких из ОС, а возможно и планшета в инвентаре

Хорошая идея)

23 часа назад, NEO сказал:

Поясни подробнее.

Типо, блок беспроводной зарядки ищет в радиусе устройства с апгрейдом-приемником и заряжает их.

Чтобы было не очень читерно можно сделать высокие энергопотери и/или дорогой крафт

Попробовал поискать в веб-архиве. Не вышло. Хотя особо не старался, попробовал два сервиса.

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

17 часов назад, eu_tomat сказал:

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

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

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

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

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

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

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

По сравнению с проводными транспозерами будет лишь задержка в один тик на отправку сообщения с инструкциями всем воронкам

А как проверить, что предмет передался за 1 тик?

2 часа назад, whiskas сказал:

А передача вещей неспашет ибо транспозеры сработают все в 1 тик в рандомной очереде и потом гадай куда вещ ушла)

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

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

 Соглашусь с @eu_tomat: виртуальные компоненты дают прирост производительности на ограниченном классе задач

А отправка по сети сколько времени занимает?

~~~

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

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

Судя по всему нужно скачать и прошить через flash.

Рекомендую попробовать вот этот современный bios: 

Жидкость в универсальной жидкостной капсуле хранится в нбт, а не в метадате.

Если в сборке установлен OpenPeripherals, то посмотри это 

Можно получить отпечаток конкретной капсулы с жиждостью и юзать этот отпечаток в качестве аргумента me_interface#requestCrafting

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

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

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

15 минут назад, ProgramCrafter сказал:

Но вообще с проблемой TLWY может справиться что-то вроде pcall.

А если TLWY вывалится снаружи pcall?

15 часов назад, eu_tomat сказал:

отслеживать лаги сервера и не отключаться по TLWY.

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

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

4 часа назад, ProgramCrafter сказал:

изготавливать урановые стержни, обслуживать реактор, не допускать его взрыва,

Тут недалеко темка была, показывающая, что одна эта задача целого конкурса стоит

В 23.07.2020 в 15:22, eu_tomat сказал:

Я плохо понял о чём здесь идёт речь. Чем плоха реализация os.sleep, если не вешать на него тяжёлые обработчики событий?

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

Если он работает как обычный тайл, то все упирается в 

В 23.07.2020 в 15:22, eu_tomat сказал:

обращение к периферии вместо одного тика иногда требует двух тиков, а в моменты сильного снижения TPS задержка доходила и до 5 тиков

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