eu_tomat

И вот результат. Все проекты автора переехали на свалку. Его хостинг, к слову, довольно быстро сдох.

Перенёс на свалку. Вряд ли автор темы восстановит свой хостинг. Он у него через пару месяцев сдох.

Точно, именно мне. Повторение — мать учения. Я редко озадачиваюсь внутренностями майна, и потому успел забыть. Ещё раз спасибо.

Проблема таки в синтаксисе. Или использование несоответствующей коду версии Python. Оказалось, это типовая проблема. Просто погуглите фразу "manage.py from exc". Синтаксис кода должен соответствовать версии Python.

А как вытащить этот код из файлов майна? Чем лучше их декомпилировать и деобфусцировать?

Python является кроссплатформенным языком. Непереносимость между Windows и Linux может возникать в случаях, если написанная программа использует какие-то специфические функции библиотек, доступные не для всех платформ. Непереносимой может оказаться и запись пути к файлу в системах Windows и Linux. Но, судя по скриншоту, причиной является ошибка в коде manage.py. upd: А ещё непереносимым может оказаться код между версиями Python. Например, код, верный для Python 2.7, может вызвать синтаксическую ошибку в Python 3.4.

Отлично! Теперь через широковещательные пакеты можно чужими солярками крутить.

У меня лечение не совпадает с этой формулой. Провожу эксперимент: Строю из стекла стакан высотой 2 блока, спавню в него 3 овцы, радаром проверяю здоровье овец. У всех по 8 жизней. Кидаю в стакан взрывное зелье моментального урона II. Радар показывает 2 овцы с двумя жизнями. Кидаю в стакан взрывное зелье лечения. Стараюсь целиться в центр овец, он у них общий в одном блоке. Радар показывает 4 и 6 единиц здоровья. Расхождение в две единицы. Аналогичный результат, если кидать зелья роботом сверху. Две овцы со здоровьем 1 единица исцеляются до 3 и 5 единиц. Здесь тоже разница в две единицы. В чём фокус?

Анекдот напомнил:

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

Верный подход. По идее, оптимально кидать зелье либо когда здоровье каждого из мобов будет достаточно низким, чтобы полностью использовать эффект зелья, либо когда здоровье одного из мобов опустится до минимума. Правда, в твоей программе зелья используются не столь оптимально, а когда здоровье хотя бы одного моба сможет полностью использовать эффект от применённого зелья. У меня возник вопрос про взрывные зелья. От чего зависит восстановление здоровья каждого моба, попавшего в зону действия зелья? По моим тестам здоровье может пополниться на 2-4 единицы. При этом все мобы находятся в одном блоке. Непонятны причины такого разброса.

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

Судя по коду, животные над аккумуляторами в среднем расходуются быстрее, чем указано в конфиге. Конфиг определяет вероятность нанесения урона отдельно взятому животному. А средний общий расход здоровья животных зависит от количества животных одного вида над аккумулятором. Грубо посчитать его можно, умножив средний расход здоровья одного животного на их количество. При малом количестве животных ошибка будет незначительной. Выводы: Размещать "запасных" животных над аккумулятором нерационально, т.к. это приведёт к увеличению среднего расхода животных, без повышения выработки энергии. Подавать свежих животных в генератор требуется в два (точнее, в 1,999) раза чаще, чем я предполагал ранее. Конечно, это при условии, что мы стремимся оптимально расходовать животных. Но для реальной оценки здоровья животных лучше всё-таки использовать радар. Неверно моё предположение о том, что при непрерывной подаче свежих животных со скоростью, соответствующей их среднему расходу, со временем животные должны накапливаться в генераторе, а среднее время простоя генератора постепенно сокращаться. В существующей механике лишние животные будут довольно быстро убиты, а среднее время простоя генератора останется практически неизменным на всём протяжении его работы.

О том и речь.

Это жёрдочки из IC2. О чём же ещё мы говорим?

OpenPeripheral предоставляет драйвер для доступа к жёрдочкам.

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

Всё это частности. Многое зависит от игрока и конфига. Всё орущее легко прячется в хлев. Админ может накрутить конфиг так, что генераторы станут более рентабельными. И в конечном итоге всё равно встанет вопрос об оптимальном алгоритме замены или же лечения животных даже если генератор будет использоваться в единственном экземпляре. К этому вопросу я и предлагаю вернуться. Ты предлагаешь выкинуть радар. Основания для этого вроде бы есть. Зная интервалы и шанс попыток генератора отнять жизнь у овцы, а также количество её жизней, можно посчитать средний интервал, на протяжении которого генератор будет расходовать одну овцу. В соответствии с найденным интервалом можно подавать очередную овцу в генератор. Но это в среднем. Если мы так поступим, то время от времени генерация энергии будет приостанавливаться из-за нехватки овец. Ты предлагаешь добавить "запасную" овцу. Но при такой схеме рано или поздно и она тоже погибнет. Я даже больше скажу: рано или поздно "запасная" овца смогла бы появиться сама, и даже не одна. Но всё равно генерация энергии будет периодически прекращаться. Ты, как знаток теорвера, как предлагаешь решать эту проблему?

@Doob За развёрнутый и иллюстрированный ответ, конечно же, лайк. Но использованные в тексте выражения склоняют читателя к мысли, будто бы ты споришь со мной. А по факту твой вывод совпадает с моим: описанное событие маловероятно. При этом ты игнорируешь другое правило: при достаточно длинной серии испытаний событие с ненулевой вероятностью рано или поздно наступит. Может, поздно. А может, и рано. Может, вообще в первом же испытании. Теория вероятностей этому не мешает. А я хочу иметь стабильный источник энергии. Пусть даже на таком странном принципе действия. Главная проблема этой схемы не в использовании зелий, а в том, что одного генератора не хватит для поддержания энергии даже обслуживающего его робота. Чтобы выйти хотя бы в небольшой плюс, потребуется около десятка генераторов. И животными надо будет "кормить" каждый из этих генераторов. Ты, конечно, можешь предложить просто равномерно кидать новых оцелотов и овец в каждый из генераторов. Но это решение приведёт к тому, что в краткосрочной перспективе часть генераторов будет простаивать, а в долгосрочной перспективе произойдёт избыточное накопление животных в некоторых из генераторов. Для борьбы с этой проблемой можно было бы объединить генераторы в один большой, но в результате движения разных видов животных в ограниченном пространстве происходит накопление оцелотов с одной стороны генератора, а овец с другой. Это заметно визуально. И ещё потребуется проверить, всегда ли над одним аккумулятором находится не менее двух животных хотя бы одного вида. Может, там и с плотностью животных не всё так просто.

Проблема этих вычислений в другом. Они верны на большом масштабе. Например, это позволяет сопоставить средний цикл размножения овец со средней частотой смертности овец на одном генераторе. При большом количестве генераторов, зная необходимое их количество, можно легко вычислить достаточное количество родительских пар. Такая математика успешно работает. Но вероятность коварная штука, и маловероятные события время от времени случаются. И будь на одном генераторе хоть сотня овец, может так оказаться, что одна из них погибнет за минимально возможные 8 минут, а остальные полностью сохранят здоровье. Да, это маловероятно, но всё же вероятно. И даже если мы построим огромную фабрику энергии, где работают законы больших чисел, и мы совершенно точно вычислим момент, в который должна погибнуть очередная среднестатистическая овца, то нет гарантии, что она погибнет ровно в этот момент. И даже если она действительно погибла, то потребуется определить, на каком из генераторов произошла её гибель, чтобы произвести замену. В общем, радар нужен для оценки реальной ситуации. Но сейчас меня заинтересовало другое. Достаточно ли двух оцелотов (и пусть даже двух овец) для покрытия расхода энергии обслуживающего эту схему робота? @hohserg Ты проводил замеры? На приложенном скриншоте и компьютер и робот собраны в креативных корпусах.

@bob558 Эта ошибка возникает, если в слоте для инструмента отсутствует предмет с изменяющейся прочностью. Такая ошибка проявится, например, с кирками из ихора.

Овец можно плодить роботами.

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

Но если деревья требуется периодически высаживать, то кто их срубает?

Пф... Я просто не сразу понял. Мне показалось, что надо повторять через каждые три метра. А это три минуты, похоже. А нужны деревья сами по себе, или получаемые с них ресурсы: древесина, листва, яблоки?