eu_tomat

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

как запустить прогу на других компах через интернет-плату? тоесть сканируем все пк с интернет-платой, отсылаем файл и запускаем

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

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

Или это опять глюк форума?

Вот код автора на pastebin.

@Pravdarius Лишние символы видны и при вставке кодом:

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

Сюда приходят только за подобным, это и печалит=(

Если тебя это порадует, то так почти всегда и во всём. Даже старожилы не живут всё время одним лишь Майкнафтом, да Lua.

@Hikooshi На будущее: вопросы по программированию лучше задавать в этом разделе > Программирование > Вопросы.

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

может ли МФУ подключить транспозер (и если я подключу то сколько переферий будет заюзано 1 или 2)?

Подключить может, добавится один транспозер. Сам MFU периферией не является.

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

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

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

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

Важно:  MFU способен питать любое оборудование OC, а не только служить интерфейсом. Решён вопрос питания компьютеров, запечатанных в массиве сундуков. Вопрос питания большой сети компонентов одним MFU без включения этих компонентов в местную сеть решается линком MFU на распределитель энергии.

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

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

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

Это старая шутка. Намекает на бессмысленность действий, которые якобы содействуют некоторому процессу, но по факту ни на что не влияют. Об её происхождении я лишь догадываюсь. Помнится, в "Маленьком принце" Сента Экзюпери был король, повелевавший и Солнцем и звёздами. Например, он намеревался потребовать захода Солнца в семь часов сорок минут вечера. Не раньше и не позже, так как требовать нужно в благоприятный момент.

1 час назад, BrightYC сказал:

забыл указать, что для корректной работы /gamerule dodaylightcycle false нужен

Предлагаю просто выполнить component.debug.runCommand(" /gamerule doDaylightCycle false")где-то в начале программы.

Напоминает "закат Солнца вручную".

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

Я никак не могу решить множественное пересечение на двойном сундуке.

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

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

P.S.: Добавил промежуточный слой из пяти блоков: два блока сундука, блок транспозера и два блока кабеля.

На больших площадях и объёмах это самое эффективное заполнение, но на малых будут мешать косые углы.

40 минут назад, Appo сказал:

/P.S/ почему сих пор не кто не допер сделал воркшоп для манкрафта? для быстрого обмена чертежами и редактором для их создания и топом чертежей для разных модов? А то приходится сатану вызывать что бы объяснить построение системы в 3д

Я, кстати, почти все схемы для Майнкрафта рисую в LibreOffice Calc, закрашивая клеточки разными цветами. С плоскими схемами вообще легко. Объёмные рисую слоями, уже привык. Некоторые схемы рисуются автоматически через вычисления и условное форматирование. Именно так я получил форму секций сундуков, находящихся в радиусе действия MFU. На изображениях срезов прослеживается тот самый куб с обрезанными уголками, и с торчащими отростками в центре граней:

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

Я одного понять не могу, как транспозеры "осознают" своё место?
Просто натыкать же не получится, как указывать какой есть какой?

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

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

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

Тестовый полигон выглядит так...

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

39 минут назад, Doob сказал:

С OpenPeripheral я могу АЕшку подключить к сундуку (в новых версиях напрямую к игроку) и не страдать фигней.

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

Кстати, ты так и не ответил на вопрос:

12 часа назад, eu_tomat сказал:

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

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

1 час назад, Doob сказал:

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

Под кем не будет работать сундук? Сундук работает, установленный как под, так и над адаптером. Сквозь адаптер, ясное дело, предмет не передать, и сундуки, стоящие строго между адаптерами являются "застойными" в соответствующих направлениях. Проблему придётся решать более сложной логикой движения предметов внутри системы, и об этом недостатке я упоминал выше.

1 час назад, Doob сказал:

И вообще, система на адаптерах работать не будет, потому что для получения функционала контроллера инвентаря, в адаптер надобно вставить сам контроллер инвентаря.

Да, важное уточнение. Без OpenPeripheral работать не будет. Следует отнести этот факт к недостаткам системы. Но с OpеnPeripheral работает.

1 час назад, Doob сказал:

Вообще не понял, как оно должно работать кубами x5.

Ставим куб 5x5x5 из алмазных сундуков IronChest, сундуки по всем 8 углам куба удаляем, т.к. MFU до них не дотягивается. В центр обрезанного куба ставим адаптер, в прилегающие сундуки кладём MFU, слинкованные с остальными сундуками, к адаптеру цепляем кабель. К кабелю цепляем комп, монитор и прочую обвязку. Для эстетики можем всё это заглубить внутрь массива сундуков.

Ванильные сундуки ставятся двойными, получается конструкция 5x5x6.

22 минуты назад, Appo сказал:

@eu_tomat 
если не ошибаюсь, но MFU можно привязывать к другому адаптеру. Тем самым делая цепочку из удаленно связанных адаптеров.
Если соединять таким способом, какова тогда плотность?

Ого! Градус безумия растёт. Промежуточные адаптеры можно даже не запитывать энергией. Теперь можно динамически подключать не только отдельные сундуки, но и целые сегменты. При неаккуратном использовании этой возможности процессор крашится, не в силах переварить прорву новых компонентов.

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

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

ааа, понял. А то есть похожее? а на скринах, это не их система?

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

1 час назад, Alex сказал:

я в жизни не видел 1229 сундуков

Сами по себе эти циферки смысла не несут. Они важны лишь для сравнения двух систем в предельном случае и в равных условиях.

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

3 часа назад, Doob сказал:

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

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

А плотность у нас достигается так: есть кубик из сундуков 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.

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

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

К одному транспозеру можно поставить 5 сундуков. К серверу подключить 56 транспозеров. Итого, можно организовать сеть хранения на 5*53*56 = 14840 предметов. И это ванильные сундуки/бочки, никаких ограничений я не вижу.

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

Эти посты были перенесены из темы про мод OpenComputers, идея зародилась в этом посте:

В 20.05.2019 в 13:00, eu_tomat сказал:

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

В 20.05.2019 в 13:40, Alex сказал:

Отличное решение. Но все равно это костылик. Это надо как-то перебирать в сундуках мфу-шки нужные, чтобы вызвать методы и обратится к тем блокам, на которые они прилинкованы. МФУ-шки могут перемешиваться в сундуке и прочие неописуемые беды могут происходить. Да и как их искать там? Как понять, к чему они прилинкованы? nbt-хеши как-то брать и запоминать? или как? Это сильно хлопотно и много кода писать.

Кому не не лень писать много кода, рассказываю:

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

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

Часть слотов в сундуках, непосредственно контактирующих с адаптером, будет занята MFU. Если сильно захотеть, то от части MFU можно избавиться, так как прямой доступ к некоторым из сундуков не обязателен, и к ним можно обращаться через соседние сундуки. Для этого потребуется аккуратно реализовать энергонезависимое хранение информации о содержимом сундуков с учётом того, что последняя операция переноса может и не завершиться успехом. Впрочем, кеширование полезно в любом случае.

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

В 20.05.2019 в 09:52, Alex сказал:

А было бы в адаптере 6 слотиков, уже другая песня была бы совсем, или вообще, был бы в моде отдельный блок датчиков на 9 слотиков - было бы еще удобнее. Не нужно было бы на базе городить паутину из проводов и адаптеров к каждой МФСУ-шке или реактору. Взять даже те же кодовые двери и кнопочные блоки из openSecurity. Конструкция стен не всегда позволяет эстетично подцепить к ним провода. А радио-контроллеры бы решили эту проблему.

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

P.S.: От этого поста отпочковалось обсуждение системы хранения на MFU.

6 часов назад, Alex сказал:

жаль только, что разработчик адаптеру сделал только один интернал слотик, а не 6 или 9, например. Можно было бы положить в адаптер несколько прилинкованных мфе-шек и работать с устройствами удаленно, и в конфиге сделать мфе-шке дальность блоков 8-16

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

Кстати, для любителей удалённого доступа был интересный аддончик OpenCCSensors, но с ним на OpenComputers были какие-то проблемы, точнее не скажу, я уже несколько лет его не трогал.

9 часов назад, Appo сказал:

В игре Stormworks в патче 0.7.2 добавлена возможность написания Lua скриптов...
Предлагаю ознакомится с обзором на обновление...
Думаю не стоит говорить какие гигантские возможности в этой игре..

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

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

а в идеале нужно проверять maxStackSize, а то мало ли, что там за рес летает и дропается.

Вдруг это какие-то магические лепешки и какашки, или какая-то маджик семечка или плод или помидорка, которая стакается по 8 или 16, или вообще не стакается. Робот тогда призадумается и повиснет, скорее всего, и будет работать неправильно, так как число 64 никогда не сможет образоваться в слотике.

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

В 16.05.2019 в 00:46, Andrej сказал:

Можете написать програму что бы робот нажимал пкм перед собой и когда инструмент разрядиться выбрасывал вниз на пару секунд на подзарядку и брал обратно работать, а так же когда предметов в инвентаре будет 64 выбрасывал их?

Задача выполнена.

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

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

3 часа назад, BrightYC сказал:

count_items = count_items + item.size

А для чего задействован счётчик, считающий сумму арифметической прогрессии? Он заставит предметы выгружаться, когда их количество превысит 10.

Предлагаю вообще избавиться от счётчика, а проверку упростить до:

  if robot.count() >= 64 then
    robot.drop()
  end

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

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

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