eu_tomat

Ну, если безумство в данном случае является не психиатрической категорией, а показателем мотивации, то пусть так и будет. А плотность у нас достигается так: есть кубик из сундуков IronChest размером 5x5x5 с адаптером внутри, угловые сундуки отсутствуют. Кабель от адаптера выходит наружу, съедая ещё два сундука. Из обвязки там только кабель, соединяющий все блоки + сервер с монитором и конвертер с энергохранителем. Но можно пойти на принцип, и обвязку тоже впихнуть внутрь, оформив всю систему в виде параллелепипеда. Пусть будет кишка, по центру которой проходит кабель, с адаптерами в центре узлов, облепленными сундуками. Тогда в кубике будут потеряны не только 8 угловых сундуков, но и ещё 5 на адаптер и кабели. Останется 112 сундуков на каждый узел. С лицевой стороны один кусок кабеля заменяем сервером, один сундук – монитором, второй – конвертером энергии, а третий – энергохранителем. Три сундука потеряны. Но с хвостовой стороны можно два блока кабеля, идущего в никуда, заменить на сундуки. В итоге потерян лишь один сундук из всей схемы. В твоей схеме было 56 транспозеров. Сейчас я не буду проверять, не знаю, сколько там реально доступных устройств на сервере после вычета необходимых, но пусть будет 56. К каждому адаптеру прилегают 4 сундука. Не буду сейчас выкраивать крохи (хотя этим тоже можно будет потом упороться), и буду считать, что в каждом адаптере всегда лежит MFU, связанный с сундуком. Получается 5 устройств на адаптер. 11 узлов в кишке как раз и дают 55 устройств + 1 сундук в конце прилепился прямо к адаптеру. Удачное совпадение. Теперь считаем. Объём конструкции = 5x5x5x11 блоков. Полезный объём 112x11-1 сундуков. Ну, хорошо, даже зарезервируем ещё два сундука: один для входящих, а другой для исходящих ресурсов. Получится 1229 сундуков на 1375 блоков занятого объёма. Эффективность использования пространства: 1229/1375=0.893. MFU занимают в сундуках 1229-56=1173 слота. Ещё 1229 слотов остаются в резерве для сохранения возможности обмена. Сундуки наверняка будут алмазными, т.к. основную стоимость крафта создают MFU. Итого выходит (108x1229-1229-1229+56)/(5x5x5x11) = 94.785 слотов на каждый занятый блок, а потери составляют не более 13% в сравнении с голым алмазным сундуком. Для ванильных сундуков вычисления будут чуть отличаться. Один узел даёт 4 одновременно подключенных двойных (на 54 слота) сундука. Получается 14 узлов по 70 сундуков в каждом. Узел будет чуть шире: 5x5x6. Формула выводится аналогично. У меня получилось ((54-2)x(14x70-4)+14x4)/(5x5x6x14) = 24.194 слота на каждый занятый блок с потерями чуть более 10% от голого ванильного сундука. По занятому объёму это даже более выгодно, чем на сундуках IronChest. Правда, не так выгодно по затратам на MFU. А какова плотность твоей сети хранения на транспозерах?

Если речь зашла о максимальных значениях, то описанная сеть на MFU имеет ёмкость в 5.5 раз больше. С ванильными сундучками, правда, результат скромнее, ёмкость отличается примерно в 3.3 раза. Кроме того, сеть на MFU имеет меньшие габариты за счёт более плотного размещения сундуков, и это, думаю, основное достоинство схемы. Недостатками схемы являются дорогой крафт MFU, низкая скорости работы (до 3х раз в худшем случае) и более сложная логика как при постройке, так и в процессе эксплуатации.

Как-то стрёмно это скачивать. Каково происхождение файла? Лучше бы выложить ссылку на источник, которому можно доверять.

Эти посты были перенесены из темы про мод OpenComputers, идея зародилась в этом посте: Кому не не лень писать много кода, рассказываю: Робот способен не только устанавливать блоки, но и сразу линковать MFU на них. И если робот размещает линкованные MFU в определённом порядке в своём инвентаре и в определённом порядке переносит их в определённые же сундуки, то порядок MFU в слотах сундуков всегда определён. И если алгоритм работы с массивом сундуков всегда возвращает MFU в те же самые слоты, где они были ранее, то порядок не нарушается никогда. И если игроки с шаловливыми руками лишены доступа к этим сервисным сундукам, то и порядку MFU в сундуках ничто не угрожает. Дистанция 3 для MFU – это много или мало? Попытаюсь придумать, например, систему хранения на одном адаптере, облепленном сундуками. Максимальное количество сундуков = 5^3-8+6-4. Это куб 5x5x5 с отрезанными блоками в каждой из 8 вершин и добавленными в центре каждой из 6 граней. Ещё 4 блока потрачено на адаптер и кабель до него. Выходит 119 сундуков. Но для компактности я бы пожертвовал всеми сундуками, выступающими за грани. Получится 114 сундуков. Такая схема легко масштабируется, и два адаптера обеспечат систему хранения из 228 сундуков. Часть слотов в сундуках, непосредственно контактирующих с адаптером, будет занята MFU. Если сильно захотеть, то от части MFU можно избавиться, так как прямой доступ к некоторым из сундуков не обязателен, и к ним можно обращаться через соседние сундуки. Для этого потребуется аккуратно реализовать энергонезависимое хранение информации о содержимом сундуков с учётом того, что последняя операция переноса может и не завершиться успехом. Впрочем, кеширование полезно в любом случае. Вот, как-то так и обходятся ограничения. Но этот путь, возможно, не для всех.

Ограничение на количество MFU в одном адаптере легко преодолимо: транспозер + сундуки с кучей MFU ограничивают количество периферийных устройств лишь размером инвентарей, находящихся в непосредственной близости от транспозера. А если задержки не критичны, то и вообще ограничений нет. Плюс такого подхода ещё и в том, что он снимает ограничение и на количество периферии, задаваемое процессором или серверными шинами. P.S.: От этого поста отпочковалось обсуждение системы хранения на MFU.

Разработчик и не планировал какой-то по-настоящему удалённой работы. Целью было получить доступ к устройствам, спрятанным внутри многоблочных структур, когда вынести их наружу невозможно. К примеру, дальности хватает ровно на то, чтобы подключиться к центральному блоку реактора внутри ЖЯР, поставив адаптер вплотную к его обшивке. Кстати, для любителей удалённого доступа был интересный аддончик OpenCCSensors, но с ним на OpenComputers были какие-то проблемы, точнее не скажу, я уже несколько лет его не трогал.

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

В идеале ТЗ должно содержать описание работы механизма и его назначение. Но автор не раскрыл всех деталей работы своей машины. Поэтому фантазировать можно долго, а улучшения программы могут оказаться невостребованными. В таких случаях есть смысл оставаться в рамах ТЗ: Задача выполнена. Но если начать фантазировать, то меня, например, больше смущает выполнение robot.use() без заметной паузы, хотя вряд ли урожай успевает созреть между всеми кликами. Такие программы обычно тупо нагружают сервер, при этом не конвертируя нагрузку в какую-либо игровую пользу. Но что там выращивается, и какой инструмент используется, ТЗ умалчивает. Может, и правда, урожай созревает после каждого клика? Тут надо бы сначала допросить автора. @Andrej Расскажи нам, что это за машина. Что она выращивает? Каким инструментом собирает урожай? А то у нас тут фантазия разыгралась, переживаем за твой механизм. Вдруг он перестал работать. А может, админы уже собираются вайпать весь сервер из-за этой программы.

А для чего задействован счётчик, считающий сумму арифметической прогрессии? Он заставит предметы выгружаться, когда их количество превысит 10. Предлагаю вообще избавиться от счётчика, а проверку упростить до: if robot.count() >= 64 then robot.drop() end

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

Эксперимент: Реальный ассортимент больше в несколько раз.

@Asior Дроп из коробок может не поместиться в инвентаре робота.

Перемещение из сундука в руку выполняется в два этапа: перемещение коробок во внутренний инвентарь робота, а из него в руку: robot.suck() inventory_controller.equip()

А зачем поворачивать направо для открытия коробок? Открывать коробки можно, не отворачиваясь от сундука. А если сундук для готовой продукции расположен сверху или снизу, то можно вообще обойтись без поворотов. Открыть стак коробок можно, поместив их в руку робота и выполнив скрипт for i=1,64 do robot.use(nil,true) end. Также нужно позаботиться о том, чтобы в инвентаре робота было достаточно слотов для приёма результата распаковки.

Да, я правил прямо в jar, и там у меня получался рабочим либо рецепт крафта, либо рецепт ремонта. Работает. Кстати, не обязательно копировать все файлы, достаточно файлов shaped_recipes.ini и shapeless_recipes.ini.

Мне не удалось воспроизвести этот трюк. Можешь выложить пропатченный мод?

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

Напомнило анекдот: – Всё, начальник! – Сделал? – Сломал.

Хм... неожиданно. Проверил. В industrialcraft-2-2.2.819-experimental.jar ещё был крафт. В industrialcraft-2-2.2.821-experimental.jar крафт уже сломан. Возможно, это и не замысел никакой, а ошибка разработчика.

@yura0138 В какой операционке так происходит? Откуда и куда копируется? Как копируется? Желательно описать последовательность действий по шагам. У меня под win7 копируется из chrome в блокнот без ошибок.

Да, можно дать всем апгрейдам инвентаря уровень 1. Можно же и стоимостью крафта давить на игрока, не обязательно уровнем.

@whiskas Это относилось к заполнению "крестиками" бесконечной плоскости. А на границах заполнения всегда возникают нюансы. Я действовал довольно грубо, без подбора. Как видишь, в основе твоей схемы лежит та же самая идея: в центре шаблонное заполнение, а по краям есть тонкий подбор. Изначально удачный шаблон даёт заполнение близкое к оптимальному без значительного напряжения мозга.

Прекрасно. Я-то на скорую руку лепил, метод описал выше. А тут уже пришлось сдвигать некоторые элементы. Тут 4340 eu/t против 4280 eu/t моих.

Это в какой версии мода его вырезали? А другая схема, это какая? Без конденсаторов уже будет и задача другая.

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