eu_tomat

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

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

@aMax, Гайд предлагает описание некоторого инструмента или среды. Или инструкции по созданию инструмента. А эта статья больше похожа на историю решения. Даже непонятно до конца, как это решение использовать. Зачем нужна программа Clickteam Fushion 2.5? Какую роль выполняет расширение Lacewing Webserver? Что делает сама написанная программа? Как пишутся программы в указанной среде? Почему исходник в бинарном виде? Каким образом его можно прочесть вне указанной среды? Какие преимущества этой среды способны компенсировать уродливость исходника программы? Каковы эти манипуляции? Кто и когда успел его выбрать? Как управлять выбором? Кем воспроизводится видео? Этой программой или клиентом? Если клиентом, то почему это действие оказалось в перечне действий программы?

В чём ты обнаружил усложнение? Я дал максимально простое решение в соответствии с условиями задачи. Но на всякий случай уточнил, требуется ли обработка дополнительных условий. А предложенное тобой решение вообще не для этой задачи: Во-первых, допуск на варп не означает готовности дать дополнительные права в привате. Во-первых, заказчик говорил о чёрном списке, а не белом. В третьих, даже если бы речь шла о белом списке, это не значит, что хозяин варпа разрешает этим игрокам телепортировать кого-то прицепом. Да. Польза от неё чисто демонстрационная. Будь у меня подобная цель, на своём варпе я бы использовал два телепорта, чтобы игроки не задерживались в точке варпа, а максимально быстро телепортировались либо в душегубку, либо в магазин. Тогда шанс того, что кого-то телепортирует прицепом, будет очень мал. И даже эти маловероятные коллизии можно будет обработать на целевых телепортах. Но это как раз-таки будет усложнением.

Все эти костыли не универсальны. Придётся писать костыль, подходящий под конкретные условия эксплуатации системы. Самый простой из костылей: устанавливать все компьютеры и контроллеры тыльной стороной на север. И роботы, если схема не предусматривает их поворотов.

Подтверждаю. Считаю это багом, потому что значения сторон, возвращаемых событием redstone_changed, не совпадают со сторонами в getInput и setOutput. Сломано, начиная с 1.7.3.

Сейчас 3D-принтер позволяет закрыть декорацией любые уродливые или однообразные блоки. Но если хочется придать произвольную форму самому контроллеру, то я предлагаю развить эту идею: управлять формой программно, вплоть до создания произвольной 3D-анимации. Такая анимация хорошо бы смотрелась и на роботах тоже. Можно пойти и другим путём: менять форму не контроллера, а специальных блоков. Уже сейчас 3D-модели могут управляться красным сигналом, выбирая одну из двух заранее заданных форм. Но интересно было бы произвольно менять форму моделей с помощью аналога голографического проектора. Отличие от голограммы будет в "твёрдости" формы.

Что именно требуется объяснить?

Тут никому не надо бежать. Все уже прибежали. Предположим, сначала на варп пришёл обычный игрок. Он стоит, смотрит по сторонам. И тут приходит игрок из чёрного списка, срабатывает датчик, и телепорт уносит обоих игроков в измельчитель. За такое админы могут наказать владельца варпа. Если подобная ситуация не создаёт проблем, то можно использовать простое решение: Прошиваем EEPROM этим кодом: -- программа, телепортации игроков из чёрного списка -- телепорт из IC2 управляется красным сигналом -- перед использованием исправить список игроков, -- окрестность варпа и сторону с телепортом local black_list = { "black", "schwarz", "niger" } local x1,x2,y1,y2 = -2.5, 1.5, -1.5,2.5 local rs_side = 3 local redstone = component.proxy(component.list("redstone")()) -- преобразование таблицы для удобства использования for k = #black_list,1,-1 do black_list[black_list[k]] = true black_list[k] = nil end -- ожидание перемещений игроков на варп -- и телепортация игроков из чёрного списка local _, signal, x,y, player while true do signal,_,x,_,y,player = computer.pullSignal() if signal == "motion" and black_list[player] and x1<=x and x<=x2 and y1<=y and y<=y2 then redstone.setOutput(rs_side,15) redstone.setOutput(rs_side,0) end end Встаём лицом на север, ставим самый простой корпус компьютера, справа от него конвертер энергии, к нему подключаем MFSU, а перед корпусом ставим телепорт: Сверху на компьютер ставим датчик движения (Motion Sensor из OpenComputers). В компьютер вставляем прошитую EEPROM, и самые дешёвые: красную карту, процессор и планку памяти Стоя на телепорте примерно по его центру, создаём варп. Где-то ставим целевой телепорт, его запитывать энергией необязательно. Связываем телепорт на варпе с целевым телепортом. Никаких дополнительных удобств моя программа не предусматривает. Для изменения чёрного списка тупо исправляем код и заново прошиваем EEPROM. Можно иначе расположить телепорт относительно корпуса компьютера. В этом случае в коде потребуется изменить сторону подачи сигнала редстоуна. А при изменении положения телепорта относительно датчика движения и сторон света следует изменить границы окрестности варпа.

Как планируется обрабатывать коллизии? Кроме чужого игрока в зоне действия телепорта может одновременно оказаться и наш союзник. Что делать с ним? Телепортировать обоих? Телепорт из IC2 не обладает избирательным действием.

Описание нуждается в доработке Что именно мониторит программа? Из описания это не ясно. Что значит "основной" ПК? Нужно это как-то указать в описании. И вообще, предлагаю между пунктами "добрый вечер" и "инструкцией" добавить описание общей идеи. Есть какой-то компьютер, называемый основным, он делает то-то и то-то. Ещё есть какой-то компьютер, и его задача делать это и и это. Вот типичный скриншот (он-то почему-то отсутствует в описании). Видео лучше убрать в спойлер. И вообще, для хорошего восприятия описания лучше, если первой картинкой будет идти скриншот программы, а не видео её прототипа. Коды пастебина предлагаю оформить в виде ссылок таким образом: pastebin run nqNgzVFN А так как это коды установщиков, и они недостаточно информативны, предлагаю указать и список устанавливаемых файлов, так же со ссылками на источник. Например: /lib/tools/boot.lua /etc/profile и т.д. Тут на форуме многие ничего не скачивают и не запускают, но код читают. Может, советы какие полезные дадут. А без ссылок мало кто посмотрит. Тем более, описание не добавляет интереса к программе. Шрифты предлагаю как-то привести к единому виду. Где-то используется мелкий шрифт непонятно зачем, где-то указан белый фон. Желательно эту пестроту убрать ради удобства чтения. И этот момент непонятен: С каких пор такая комплектация называется слабенькой?

Да, не получится заставить чужого дрона выполнять произвольные команды, если его ПО не содержит дыр. Тут я вижу два сценария. Самый вероятный: после перепрошивки следует незаметно подбросить дрона его владельцу, чтобы тот установил его своими руками. Сделать это будет сложно, но при удачном раскладе возможно. В маловероятном сценарии дрон жертвы может оказаться строительным, заточенным на то, чтобы что-то брать из сундука и устанавливать в мир. В этом случае, подменив путевую точку, можно попытаться заставить дрона взять робота из сундука грифера и установить его в мир от имени жертвы. Меня тут внезапно осенило. Я обычно скептически отношусь к использованию путевых точек на сервере. Внутри привата от них мало пользы, т.к. апгрейд навигации сам по себе имеет зону, достаточную для покрытия привата. А за пределами привата где-то в майнерс-мирах путевая точка окажется маячком не только для самого игрока, но и для гриферов. Будучи мирным шахтёром, я заинтересован в максимальной скрытности своих систем. Но сейчас я посмотрел на это с другой стороны: если использовать путевые точки в качестве приманки, то гриферы рискуют сами оказаться в роли жертвы. В общем, если кому-то нравится использовать путевые точки на сервере, то я поддерживаю. Это добавит динамики игровому процессу.

Путевые точки переименовываются даже в привате, даже за не очень толстыми стенами. А про охранное стекло я давно хотел узнать. Оно совсем не ломается? На EvilWorld, помнится, кто-то ломал чужие постройки из охранного стекла. Но остаётся другая проблема. Даже если предположить, что "настоящая" путевая точка хорошо защищена, злоумышленнику всё равно ничто не мешает установить несколько своих с такими же именами. И чем их будет больше, тем вероятнее, что первой в списке окажется чужая. Как отличить свою путевую точку от чужой?

Хочу предупредить о главном недостатке путевых точек. Имена путевых точек может подделать любой желающий. Насколько я помню, даже в чужом привате и даже за не очень толстыми стенами. На этом даже основан популярный метод угона дронов. Для угона дрона злоумышленник устанавливает свою путевую точку за пределами привата жертвы и назначает ей имя с таким же названием, как и у точки жертвы, а имя точки жертвы он меняет на какое-нибудь иное. После этого дрон начинает опираться на новые координаты. Путевые точки имеют свой UUID, но в текущих версиях OpenComputers нет возможности узнать UUID точки через findWayPoints. Такая возможность позволила бы нивелировать последствия несанкционированных переименований точек. Главным способом защиты от подделки является сверка координат путевых точек с координатами внутреннего апгрейда навигации или, например, с радиосигналами GPS. Поэтому на публичном сервере путевые точки оказываются лишь вспомогательным, локальным средством навигации. За пределами же карты апгрейда или зоны покрытия GPS достоверность полученных координат сомнительна. На приватном сервере путевыми точками можно покрыть любую часть карты, причём, в автоматическом режиме. В этом случае координатам путевых точек можно полностью доверять.

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

Использование EEPROM всё упрощает. Кладём два стака EEPROM в инвентарь игрока, а далее клавиатурный скрипт помещает их в сетку крафта и запускает крафт. На выходе получаем те же самые EEPROM + подарки. Чтобы подарками не переполнился инвентарь, выкидываем их тем же скриптом. Скрипт гоняем в цикле до чувства полного удовлетворения. Далее подарки нужно чем-то подбирать. Сгодится всё: роботы, воронки и прочее. За 10 минут накрафтилось около 100 стаков подарков. Это почти полный алмазный сундук. Отличный чит для фанатов OpenComputers. Но это в сингле. На серверах, возможно, нужные другие задержки или даже проверки.

Каноничное написание: Церковь Доброй Автоматизации. Доброта самой церкви является предметом теологических споров, и отдельные её адепты всё же могут причинять зло своим жертвам. К примеру, не считаются грехом: угон чужого робота, подбор паролей, кража шифров и подавление конкурирующих сетей. Сама же автоматизация несёт добро каждому вдумчиво и осознанно исполняющему ритуал автоматизации. По теме: 1) В обеих прошивках есть такой участок: do local start=false while not start do local eventName = computer.pullSignal() start = eventName=="modem_message" end end Его можно упростить до одной строки: repeat until computer.pullSignal()=="modem_message". 2) Роботы в качестве транспозеров слишком медлительны. Транспозер работает в 10 раз быстрее. Также роботы, перемещающие предметы, используют для этого две операции, а транспозеру достаточно одной. Поэтому ускорение будет 20-кратным. Если четырьмя транспозерами будет управлять один компьютер, ускорение будет 5-кратным. Перемещать предметы в верстак также быстрее транспозерамм. Имеющийся запас производительности позволит перекомпоновать схему, используя один транспозер как для пополнения сырья в сборочных роботах, так и для перемещения промежуточного продукта в верстак. Так схема станет максимально компактной. Для достижения максимальной производительности я рекомендую использовать микроконтроллеры со встроенным транспозером. Один транспозер будет подавать за тик стак сырья, робот за тик выполнит крафт, другой транспозер за тик переместит продукт в верстак. Тут основным вопросом будет, сможет ли игрок так часто кликать на крафт. Скорее всего, нет. Поэтому можно оставить в схеме одного робота. Скорее всего, даже хватит одного транспозера. 3) При внешней подаче и выгрузке содержимого слотов робота крафт легко синхронизируется с помощью событий inventory_changed. Как только заполнился слот сырья и опустел слот продукции, выполняем очередной крафт, в противном случае фильтруем события и ждём. 4) Класть кирпич на клавишу Shift не надо, нормальные автокликеры способны сами имитировать любые нажатия. 5) Если нет верстака с полноценными слотами, можно воспользоваться и обычным. В этом случае финальный крафт выполняется автокликерами. Требуется лишь пополнять инвентарь игрока материалами, да забирать продукцию.

На этот вопрос нет простого ответа. Для достижения поставленной цели придётся анализировать конкретную игровую сборку. Почти у все модов можно найти какие-то уязвимости. Бывает, что мод глючен сам по себе. А бывает, лишь при определённом взаимодействии с другими модами. В новых версиях модов одни уязвимости могут быть исправлены, но добавлены новые. На каких-то серверах эти проблемы могут быть исправлены изменением кода или настроек. Все сервера различны, поэтому готового рецепта нет и не будет. Что касается OpenComputers, то в сочетании с другими модами он тоже имел некоторые дюпы. А, возможно, и сейчас имеет. Но вряд ли это окажется сильно похожим на команду give. Скорее, это будет дюп какого-то определённого типа предметов. Зачастую же виновниками дюпа оказываются другие моды, а OpenComputers используется для автоматизации процесса. Самым простым способом поиска уязвимостей конкретной сборки является продолжительная и разнообразная игра. Попробуй использовать всевозможные механики из всевозможных модов на сервере во всевозможных сочетаниях, и ты обязательно найдёшь какой-нибудь дюп, который не заметили админы.

Что именно работает, что не работает, и что должно работать?

А вопрос касается только законных способов? Или требуется получить что-то без разрешения администратора?

А в каком смысле "выдавать"? Выдавать предметы со склада можно разными путями: перемещать транспозером, выплёвывать роботом, или раздатчиком. Или имеется в виду аналог команды give?

А по какой формуле растягивается поводок?

Кстати, о заряде. В программу имеет смысл добавить ограничение силы сигнала беспроводных плат для уменьшения энергопотребления. Особенно много может потреблять плата второго уровня.

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

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