eu_tomat

Сначала выскажусь о процессорах в инфузилке. Предположим, создание процессора – это магия и инопланетная технология, не допускающая крафта на деревянном верстаке. Но если я куплю робота за UU, то с помощью этой инопланетной технологии я смогу создавать новые комплектующие. Соглашусь: пусть будет запрет на крафт комплектующих на верстаке. Пусть всё делают компьютеры и роботы – тогда это полностью оправдает название проекта. Требуется сильно поднять цену на топовые комплектующие? Не проблема – их можно хоть из алмазных блоков или иридия делать, но при чём здесь таум? Необязательно запускать майн, чтобы играть в него. И если бы не компьютерные моды, майкрафт не удержал бы моего внимания так долго. И вопрос был не о вкусах игроков (кстати, грегтех технологичен), а о развитии проекта. Еще раз спрошу: 1) Почему айтишников на CC.RU вынуждают создавать компьютеры через магию? 2) Почему приоритетом стала не технологичность, а таинственность? 3) CC.RU переориентируются на другую аудиторию? Пока писал, увидел новое сообщение: Автоматизация трубами. Трубами, Карл! Роботы нервно закурили. Последний вопрос: в чем уникальность обновленного CC.RU?

Именно за это я никогда не любил Таумкрафт. И если всю эту магию не удастся в полной мере автоматизировать с помощью компьютеров, то зачем она вообще нужна на проекте computercraft.ru? Драка не за руды, а за информацию. По сути же это столкновение инженеров и магов. Сначала Кровавая Администрация говорит инженерам, что магия таума давно уже стала технологией. Инженеры, покурив гайды, соглашаются. Затем инженерам говорят, что их процессоры давно уже работают на магии, и негоже собирать их на верстаке, хотя инженеры давно уже всю сборку выполняют роботами. Естественно, инженеры сомневаются в необходимости привлекать магию. Тогда им говорят, что есть еще модик с кастомными рудами, и разглашение алгоритма их генерации сделает игру скучной. Что происходит? CC.RU сменил цель?

Являясь в данный момент самым богатым по UU, позволю себе внести предложение по их вайпу. Я поддерживаю избавление от лишней наличности, но против уравниловки после вайпа. Считаю, что в идеале вайп избыточных UU должен быть ежедневным, вычисляемым, например, так: -- несгораемый минимум, скорость и степень снижения uu_min, uu_los, uu_pow = 1500, 0.01, 1.4 -- вычисление UU на следующий день uu_next = uu_curr - floor(power(max(uu-uu_min,0)*uu_los;uu_pow))Это позволит безболезненно накопить свои 1k5 UU на чанклодер, но при голосовании с одного аккаутна ограничить максимальный счет на уровне 4k UU. Голосование с двух аккаунтов даст лишь 5k5, а с трех – всего около 7k. То есть, много не накопишь даже при активном голосовании. В результате игроки предпочтут не копить UU, а сразу пускать их в дело. А в ожидании нового сервера голосование не пойдет на спад, а наоборот, будет расти. Эффективность голоса игрока при этом заметно снижается, но это его вклад в быстрый старт. Новые игроки, не получив стартового баланса UU, тоже будут заинтересованы в голосовании за проект. Наибольший баланс будут иметь не те, кто давно и много голосовал или мало тратил (как я, например), а те, кто активно голосовал в последнее время. Что можно сделать сейчас? Думаю, что наиболее справедливым будет посчитать голоса за последние два-три месяца и сконвертировать их в UU после вайпа в соответствии с новым балансом UU.

UU следует резать хитрее, сохраняя накопленное за последний месяц-два – если не в этот вайп, то хотя бы в последующие. Конкуренция в топе голосов за месяц снизилась.

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

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

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

Оу, классно! Не ожидал от Lua возможности даже имитировать указатель на переменную. Но у меня сомнения относительно os.clock(). Всегда думал, что это время, затраченное процессором на выполнение кода, а оно совпадает с реальным временем лишь в случае, когда процессор 100% своего времени тратит на выполнение кода именно на этом компьютере. Что-то типа активной части uptime.

Глазам не верю: айтишники в рабстве у магов! Если бы компы были независимы от магии, я бы расценил соседство двух модов как возможность сравнить пути развития. Но теперь изучение магии становится почти обязательным. Надеюсь, на новом сервере развитие магов тоже как-то тормозится через необходимость индустриальной прокачки. Маги добрые, скиньте, пожалуйста, ссылки на хорошие гайды по свежему Таумкрафту.

Какой FPS ожидается на Raspberry Pi B+?

Нельзя просто так взять и прекратить изобретение велосипедов. Есть MineCraft, есть MineTest, и даже Копатель в конце концов. Но и это не предел. Есть TM, есть OB. Почему существование этих модов должно быть аргументом против создания альтернативы?

Интерфейс должен быть другим, спору нет. Тыкать в монитор ради одного пузырька – это утомит даже самого автора программы. Игроки любят «материализацию» – вот, что я имел в виду, оправдывая эту идею. Игроки любят всевозможные пузырьки, которые можно хранить в сундуках и достать в нужный момент. Еще игроки любят, чтобы пузырьков было много, 100500 стаков – в самый раз. А когда эти пузырьки однажды не поместятся в сундук, игроки захотят хранить свое добро на флешках из AE. Понятно, что весь майнкрафт является абстракцией, а сеть AE «дематериализует» даже эту абстракцию, но большинству игроков «материальные» вещи нравятся больше циферок. К примеру, меня полностью устраивают циферки, но поэтому я и в майн почти не играю. А если играю, то мысленно по пути на работу или же изредка запускаю игру для проверки идеи. Но с таким подходом я остаюсь в меньшинстве. Игроки любят предметы. Что касается удобства SQL, то оно относительно: Игрокам нравится разнообразие направлений для развития. Поэтому заменять фермы опыта копалками – значит обеднять игру. Моды, подобные Equivalent Exchange, интересны лишь на первый взгляд. К примеру, меня не интересует магия, и на WitchCraft я даже не заглянул. А людям нравится. И с точки зрения автоматизации интересна каждая из этих задач. Игрок, который скачал программу для фермы или шахтера, наслаждается не тем, что он стоит в AFK, а тем, что эта скачанная и непонятная хрень из буковок способна оживить его робота и заставить делать утомительную для игрока работу. Затем игрок пробует модифицировать эту программу или написать свою, наслаждаясь уже тем, что это именно его программа приносит результат. Потом игрок радуется тому, что его программа лучшая и самая эффективная из всех известных ему. По крайней мере, эволюция игроков на computercraft.ru мне видится именно такой. Идея все-таки неплоха. prostoshu не мечется с вопросами «а чтобы такое написать» и «какие есть идеи». Он придумал и написал. Написал криво, неудобно, да еще и с претензией – вот, что плохо. Не особо нужно на IT – наверное. Но где-то пригодится, если доработать. Лично мне интересно увидеть адекватное развитие этой идеи.

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

А разве банк опыта на IT закрылся? И если я верно помню, в банке опыта количество опыта учитывалось более адекватно.

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

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

Полагаю, это утверждение не отрицает применения роботов для перемещения реакторных компонент, топлива и отходов? Иначе, как ты выразился, "придется весь завод копировать полностью" вместе с последовательностью воронок/транспозеров – редкостная тягомотина. Кроме того, изобилие воронок – лагодром, и один «подносящий снаряды» робот на большой АЭС – будет лучшим решением. 1) Масштабируемая АЭС с произвольным количеством реакторов – это будет бомба. 2) Комп в качестве пульта управления и робот для подсобных задач. И транспозеры, как советовал Doob. 3) С транспозерами должно хватить и одного робота для обслуживания кучи реакторов. Крафтить эффективнее целыми стаками, если для этого достаточно исходных составляющих. Не понял вопроса. Хранить схемы можно в файлах.

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

@Zer0Galaxy, разве я сравнивал? Ты выдал полное решение задачи, а я лишь пару демонстраций тех моментов, которые меня самого зацепили.

Мой метод называется "Сделай сам". Я продемонстрировал, как произвести вычисления, используя небольшой объем памяти, и как ускорить запись вычислений в файл. Склеить всё это воедино не составит большого труда. Ну, и добавить обработку точки и чтение из файла, как сделал Zer0Galaxy. Все составляющие у тебя есть. Что делать с наградой, ума не приложу. Меня игровые ресурсы не интересуют. Удивлюсь, если заинтересуется Zer0Galaxy.

Всё-таки не удержался и сделал буферизацию. local dstName = "result" local dstL = 10^7 local bufL = 2^12 local dst = io.open(dstName,"w") local dstBuf dstBuf = string.rep("0",bufL) for i=1,math.floor(dstL/bufL) do dst:write(dstBuf) end dst:write( string.rep("0",dstL%bufL) ) dstBuf = {} for dstI=dstL,1,-1 do local dig = dstI%10 dstBuf[#dstBuf+1] = dig if dstI%bufL==1 then dst:seek("set",dstI-1) dst:write(table.concat(dstBuf):reverse()) dstBuf = {} end end dst:close()Результаты тестирования разных способов записи в файл на 10M знаков:29.10 сек - способ Zer0Galaxy() с инверсией промежуточного файла 23.15 сек - уменьшено количество вызовов seek в два раза. 38.13 сек - обратная запись без промежуточного файла 20.19 сек - обратная запись со строковым буфером 32..64 байта 10.15 сек - обратная запись с табличным буфером 4KB Выводы: 1) Уменьшение количества файловых операций даёт хороший результат; 2) Конкатенация строк – неэффективная операция, строковой буфер более 32-64 приводит к потере эффективности. Т.к. Lua не имеет средств для изменения отдельных символов строки, то более эффективными по скорости оказались таблицы; 3) Подтвердились опасения, что запись файла в обратном направлении без буфера может оказаться неэффективной. И это при том, что количество файловых операций уменьшилось. Ускорение записи почти в три раза очень радует.

Дописывать файл, сдвигая уже записанное, вряд ли возможно без потери эффективности. Я имел в виду другое решение: заполнить файл нулями или пробелами, а затем выводить результат поверх нулей. local dstName = "result" local dstL = 9 -- создание файла и заполнение его пробелами local dst=io.open(dstName,"w") dst:write( string.rep(" ",dstL) ) -- заполнение данными с конца файла dst:seek("end",-1) for i=dstL,1,-1 do dst:write(i) if i>1 then dst:seek("cur",-2) end end dst:close() Убеждаемся в том, что файл имеет верный размер и содержимое $ lua test.lua; cat result; echo""; stat -c%s result 123456789 9 На двоичных данных, да в низкоуровневых языках прирост однозначно был бы. Вопрос в том, насколько эффективно Lua может выполнить преобразование в число. Но мне думается, что в нашем случае гораздо большего прироста производительности можно достичь, минимизируя файловые операции, и в этом поможет практически любой буфер, но желательно кратный 512 (или больше, в зависимости от размера кластера файловой системы), и выровненный на начало файла.

@Zer0Galaxy, нужно ли выполнять двойное преобразование файлов? Читать источник в обратную сторону нам всё равно уже пришлось, а теперь еще добавились прямое чтение и запись. То же самое и с записью приемника. Два раза идет прямая запись и один раз обратное чтение. Но можно обойтись одной прямой и одной обратной записью. Впрочем, я не знаю, насколько эффективно Lua справляется с буферизацией обратной записи. К тому же отказ от преобразования даст небольшой побочный эффект в виде возможных ведущих нулей или пробелов; не знаю, насколько это критично для целей автора темы.

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

Для готового кода этот кусок был бы явно лишним. Но код демонстрационный и по возможности универсальный. Поэтому, например, я часть лишнего кода убрал в комментарии, а не удалил совсем. В финальном коде строки источника и приемника должны быть замены файлами, а может, и строковые буферы там будут в каком-то виде. Как топикстартер хранит своё число сейчас и как будет хранить потом, он не прояснил до сих пор. tostring же выдает только один порядок цифр – от старших к младшим. Спасибо, что напомнил – я таки не один. Психанул, увидев сообщение NEO и вспомнив предыдущих скептиков. Так и надо. Но если считать этот код готовым, этот блок переменных следует вообще выбросить.