Doob

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

Вообще-то я так и писал, сначала был нормальный человеческий код, а когда начал запихивать его в EEPROM, то делал любую дичь, лишь бы влезло. Вот лучший минификатор, который я видел: https://github.com/stravant/lua-minify, еще лучше сжать может только человек, который писал код и знает на чем можно сэкономить.

Еще надобно сделать управление опытом игрока, а то в этой версии скучно, вообще ни чем его не потрогать. Может быть сразу дать полный доступ к NBT игрока через JSON, чтобы лишний раз не бегать? Можанги вон к версии 1.13 наконец-то доперли, дали возможность смотреть и редактировать почти все, прямо из игры.

Предлагаю добавить в world_interface функцию получения всего инвентаря игрока и сделать insertItem как в OC для MC1.12.2. Очень нужные функции, т. к. в старых версиях майна все надо делать по одному стаку и одному слоту, а это сильно замедляет работу с инвентарем. Пройти по 36 слотам это 1.8 секунды. И было бы совсем здорово, чтобы при уничтожении стака, выдавалось количество (либо сделать уничтожение не по слотам, а по предметам, чтобы работало как команда clear с возможностью указать количество предметов)

Свой, конечно, не хочется, чтобы оно опять превратилось в тыкву. Да и тащить целую гуи-либу ради одного списка и пары кнопок это оверхед.

Такая возможность есть уже давно, можно проверить, видно ли сейчас солнце (в дождь и ночью выдает false) и видно ли небо над головой. Я в копалку добавил подзарядку, как только узнал, о возможности проверки наличия солнечной панели. https://github.com/DOOBW/geominer/blob/master/miner.lua#L104

Нет, серверная часть простая как палка, только гуи клиента подкрутить под текущие возможности. Главное это настроить вайтлист, составить список предметов из модов, т. к. информация о NBT в базе не сохраняется, если делать сохранение, то это ковырять индивидуально каждый мод, ибо в NBT моды скрывают бездну дюпов. Еще надо пощупать дебагу с комблоком именно на серверном ядре с форжем, я помню, что там все отлично работало только на одном типе ядра, а форж всегда фортели выкидывает. Можно вифи, можно через stem, хоть азбукой морзе, там надо еще подумать, как игрокам удобней. С очками на IT было прикольно, но я уже забыл API, как там ловить прокрутку и клики, как интерфейс под экран подстраивается. С ними удобно тем, что сложную авторизацию можно выкинуть и их не надо постоянно заряжать как планшет.

Данная версия безвозвратно устарела, да и слишком тормознутая была из-за массивной GUI либы. Все учтено, ничего не багает, не дюпает, вайтлист есть. Я полностью переработал концепцию, теперь она только на дебаге и работает, с аешками и сундуками я наигрался вдоволь. Игроки подключаются удаленно и вообще никакого влияния на ядро оказать не могут. Есть только одна проблема, я все делал на МС1.12.2, там есть некоторые различия в возможностях, по сравнению с другими версиями. Вообще, без проблем могу перенести на 1.7.10, единственный затык в том, что до 1.13 нет абсолютно никакой возможности получить информацию об инвентаре игрока на чистом MC+OC. Я подготовил PR, добавляющий возможность дебаге смотреть в инвентарь, но там в OC разработка продвигается медленно и все нестабильно. Поэтому, лучше воспользоваться той штукой, которую делал NEO. Пока что я изощрился забирать ресы у игрока, присылая ему бессмертную летающую вагонетку. Гораздо проще добавить функционал для работы самим компам, чтобы они от имени игрока покупали/продавали ресы из сундуков, но вряд-ли такое будет востребовано.

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

oppm install tar

Первое, что бросается в глаза, это запуск скрипта, если нужен третий питон, то обязательно надо писать python3 script.py Второе, это ошибка синтаксиса, мои телепатические способности подсказывают, что там должен быть какой-то импорт, но написан он неправильно. Файл в студию или можешь потыкать в умной IDE, вроде PyCharm, тогда все станет понятно.

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

Все хорошо, только звук довольно противный, предлагаю заюзать это. https://www.dropbox.com/s/4s7nhyuk8bjfp21/bzrrrrrr.ogg

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

А зачем крутящаяся солярка в майне? Там ведь с точностью до тика известно положение солнца.

Можно по паре жЫвотных на игрока выдавать, но первое время все-таки придется дохнуть от голода, пока они не расплодятся.

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

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

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

Если бы да кабы, да во рту выросли грибы... Я исхожу из того, что есть, один генератор ничего не решает, кто там чего может накрутить это дело десятое. А стак генераторов будет выдавать 192 энергии в секунду, при текущем конфиге. По гистограмме видно, если бомбить по одной овце до медианы, то будем получать 0.65< лишних овец, в ином случае, простой генератора будет 30-40% Мой подход основывается на том, что я не буду обслуживать поля генераторов, поэтому могу раз в 3 дня проверять состояние и добавлять недостающую овцу.

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

Все можно посчитать, для особо неверующих, можно даже сделать симуляцию. У вероятности есть такая замечательная штука, как распределение. И при разных условиях, плотность распределения может быть разная. Если теория вероятностей и комбинаторика обошли вас стороной, то я попробую объяснить на пальцах. Для упрощения, возьмем вероятность получить урон за 100% и поместим две овцы в одну ячейку. Каждую минуту одна овца будет в среднем получать 0.5 урона. Время жизни овцы работы ячейки от 8 до 16 минут. Для еще большего упрощения, можно взять среднее здоровье овец (они получают в среднем одинаковый урон) Подбрасываем монетку и назначаем этому мысленному конструкту урон в 1 единицу здоровья. Если одна овца кончилась, то записываем сколько минут проработал генератор и начинаем заново. Можно запустить симуляцию и увидеть... Ба! Кто это у нас? Похоже на Гамма-распределение или хи-кватратичное, но стоит помнить, что шум у нас равномерный. Код на питоне для наглядности. Можно покрутить жизнь овцы x1 независимо от x2 и увидеть, что конструкт действительно работает. Сколько раз бы мы не запускали симуляцию, наивысшая плотность вероятности будет около 24х минут. Я сначала оценивал минимальное время работы генератора по третьей левой сигме, но она очевидно не статичная и не линейная. Сейчас мы получаем минимальное время работы генератора 8 минут, но стоит приглядеться к площади на графике, которую занимает эта вероятность. Что мы тут видим? По отношению к остальной площади это просто песчинка. Можно пойти дальше и установить вероятность получения урона как в конфиге - 0.001 Вот тогда начнутся чудеса, пик отползает от 0, минимальное время работы тоже. Вот результаты работы симуляции (первый столбец это количество жизней конструкта, второй - минимальное время работы генератора в минутах) Но это третья сигма, она нелинейна, хоть и позволяет оценить время работы генератора. Я пошел немного дальше и вывел формулу получения пика. T = x*1762-2337 Где x - это среднее количество жизней в ячейке, а результат T - время до максимально вероятного окончания генерации. Теперь вернемся к нашим баранам. Сильное заявление, проверять я его конечно не буду. Сначала мы подкидывали монетку и получали 0.5, в конфиге у нас 0.001, значит подкинем монетку с тысячью сторон и внимание, вопрос... какова вероятность, что монетка выпадет на одну грань из тысячи, восемь раз подряд? Овцы и оцелоты это всего-лишь вид топлива, какой толк переводить на них зелья, если можно подкинуть еще? К тому же при подкидывании топлива, не только увеличивается среднее время работы, но и снижается вероятность отключения ячейки.

А конструкторы генерации на 1.7.10 есть? Или вымерли все? Я помню, еще на 1.2.5 руками указывал все параметры, захотел - генерирую острова в лавовом океане, захотел - луну с кратерами.

Математика позволяет оперировать вероятностями. Я тут посчитал и обнаружил, что животных, без дозаправки, можно оставлять примерно на 30 часов и ничего страшного не случится. Пик смертности приходится на ~12000 минут работы. А в первые 1000 минут, вероятность получить труп крайне мала. Но это сферовакуумные вычисления, может я ошибся с классификацией распределения, но при больших шансах урона все правильно выходит. В майне проверить это проблематично, да и шумят овечьи генераторы довольно неприятно.

Узнать матожидание 70% урона и настроить таймер, чтобы дроппер по таймеру бросал зелье. Тогда и робот не нужен.