eu_tomat

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

Майн хорош, с этим трудно спорить. Но почему бы не попробовать что-то ещё? Из всего списка Factorio мне ближе всех. Кроме Майна с компами, конечно.

О, ассемблер. Неплохо. Это поинтереснее, чем проводками в комбинаторы тыкать. AAI тоже интересно выглядит, но программируется всё теми же комбинаторами. Я играл в Fcatorio. В начале было интересно, но на поздних стадиях игры хочется чего-то другого. Чего-то похожего на screeps. В идеале, чтобы все стационарные объекты обслуживались мобильными юнитами, а те управлялись бы пользовательским скриптом. И чтобы можно было с ранних стадий игры обойтись одними лишь мобильными юнитами первого уровня без лент и манипуляторов, а на поздних – без автоматических дронов, как транспортных, так и строительных. И чтобы юниты были модульными, чтобы в каждый из них можно было добавить свой набор улучшений: скорость, энергия, броня, дальность зрения, грузоподъёмность, бонусы для дальности стрельбы, урона, скорострельности. И чтобы исследования добавляли крафт юнитов более высоких уровней с бОльшим количеством слотов улучшений, либо крафт апгрейда, поднимающего уровень юнита до следующего. Такие смутные мысли крутились у меня во время игры в Factorio.

Предположим, стратегия и её цель – одно и то же: Новые панели делаются, чтобы сделать еще больше панелей. Посты на форуме пишутся, чтобы написать ещё больше постов на форуме. Новые моды выпрашиваются, чтобы выпросить ещё больше новых модов. Кажется, в этом нет никакого подвоха.

Как называется мод на программируемый комбинатор?

Отлично! Так мы хотя бы точно узнаем, сколько нужно утилизаторов для снижения TPS сервера, и каков должен быть их разрешённый лимит на игрока. А про цель стратегии ты так и не ответил. Это всем понятно: производство иридия для новых панелей для производства иридия для новых панелей. Это суть стратегии. А цель стратегии всё-таки в чём?

Стратегия подразумевает достижение цели. В чём цель конкретно этой стратегии? И почему эта стратегия мешает пользоваться ускорителями или использовать поле утилизаторов?

Согласно данным разведки обычный утилизатор не так-то прост: Стак сырья за тик тебя устроит?

Не заметил это сообщение сразу, отвечу сейчас:Проверить, какие числа принимаются, а какие нет, можно, вставив для контроля print() сразу же за read(): local vremua = io.read("*n") print(vremua) Такой отладочный код поможет увидеть, что число всегда возвращается верное. И почему-то не заметил это: Действительно, после чтения числа через read("*n") следующий за ним вызов read() возвращает пустую строку. Вот пример, в нём же показано, как обойти такое поведение read(): $ lua5.3 > print( '-' .. io.read() .. '-' .. io.read() .. '-' .. io.read() .. '-' ) 111 222 333 -111-222-333- > print( '-' .. io.read("*number") .. '-' .. io.read() .. '-' .. io.read() .. '-' ) 111 222 -111--222- > print( '-' .. io.read("*number",1) .. '-' .. io.read() .. '-' .. io.read() .. '-' ) 111 222 333 -111-222-333-Почему так происходит, я сам не понимаю. С удовольствием послушаю более опытных знатоков Lua.

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

Эта задача решается даже с противными скобочками: local expr="2+2*2" print( load("return "..expr)() ) И еще раз говорю, io.read тут не при чём, дело в синтаксисе языка. Можно и так: local value = load("return " .. io.read() )() print( value )

Указанный код похож на работоспособный, и потому ничего не поясняет. Ну, будем мы сравнивать krya=='*', и как это нам помешает?

А разве в стандартном IC2exp ускорители не позволяют выполнить любую операцию за один тик?

Если я верно понял вопрос, то никак. И дело не в io.read(), а в синтаксие Lua. Переменная указывается по её имени, а строковая константа всегда записывается в двойные и одинарные кавычки, а также в двойные квадратные скобки. То есть, Lua всегда интерпретирует name как имя, а 'name' как строковую константу. В случае твоего кода необходимо сравнивать значение переменной со строковой константой, и потому без кавычек не обойтись. Но можно пойти на хитрость, предварительно записав константу в переменную. Например: local y, n = "y", "n" local a = io.read() if a==y then ... elseif a==n then ... else ... end Так мы избавимся от кавычек на нужном участке кода, используя их в другом месте. Но зачем?

А как на скрине можно увидеть, что значение 100 не принято? Мне скрин показывает, что выполнение пошло по третьей ветви условий, то есть, первые два условия оказались ложными. А такое поведение может быть объяснено кодом zn == y, который выполняет сравнение переменной zn с переменной y. Учитывая, что предыдущий код не иницализирует переменную y, то она, скорее всего, не существует, и условие всегда будет ложным. Если код переписать код таким образом: zn == "y", то он выполнит сравнение переменной zn с символом "y", в случае успеха направив выполнение программы по первой ветви. Аналогичным образом следует поправить и вторую ветвь условия.

А с чем тут можно спорить? С тем, что чувствительные к лагу процессы не должны отдавать распределиние приоритетов операционной системе? У каждой задачи своя специфика, и каждый из подходов может оказаться оптимальным в соответствующих условиях. Низкоприоритетные процессы с низкой нагрузкой прекрасно уживаются друг с другом и работают в фоне. Удобнее всего это сделать через механизмы, предоставляемые операционной системой. Процессы, требующие быстрой реакции, должны работать на выделенных компьютерах, желательно вообще без операционнной системы для снижения влияния её процессов. Есть и контрпримеры. Основным процессом может быть запущена zip-архивация, в результате работы которой двери будут открываться фоновым процессом с лагом в несколько секунд. А динамические схемы ядерных реакторов вообще требуют контролируемой задержки. Нужна уверенность в том, что при вызове computer.pullSignall() задержка будет иметь погрешность в пределах одного тика. Работа такой программы в фоне может привести к взрыву реактора. Если компьютер выделенный, то и задача перестает быть для него фоновой. Такая программа сама распределяет приоритеты подзадач. К примеру, при управлении несколькими ядерными реакторами программа имеет возможность не только прогнозировать критические моменты каждого реактора, но и отсрочить их, безопасно распределяя управление периферией во времени. А когда критические моменты далеко, в это время можно дать команды на крафт и распределение свежих порций топлива, получить указания с центрального пульта или освежить инфу для него. То есть, контролировать множество устройств с одного компьютера является хорошей идеей. Но в ряде случаев плохой идей будет отдать распределение приоритетов между процессами операционной системе. с тем же успехом центральный пульт может хранить прошивки и конфиги всех выделенных под конкретные задачи компьютеров, рассылать команды на их обновление, вести логи, отображать информацию о состоянии любой из систем и заниматься прочими низкоприоритетными задачами. Тут для RC самое место. Итог всё тот же: решение может считаться плохим или хорошим лишь применительно к конкретной задаче. Ну, а применительно к нашему форуму задачей вообще может оказаться получение опыта работы с RC. Тут выбор очевиден, против этого не возразить. И уж точно, не смотря на существование альтернатив, твой код заслуживает внимания. Это не оспаривается. Хорошая работа.

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

Для облегчения поиска оставлю ссылку на тему с программой: Программа для подгрузки и популяризации варпов (магазинов)

1. Нет абстрактного "Lua для майна", но есть поддержка Lua в моде ComputerCraft и в моде OpenComputers. Сильных отличий от стандартного Lua нет. Основная разница в API доступа к библиотекам и компонентам. Поэтому нужно знать обычный Lua и особенности модов. 2. Раздел с гайдами имеется. Также есть гайды по модам. Там же лежит легендарная серия уроков от @1Ridav по Lua в ComputerCraft. На главной странице есть "Полезные ссылки" с описаниями как языка Lua, так и модов ComputerCraft и OpenComputers. 3. Я изучал Lua и мод ComputerCraft по тем самым урокам @1Ridav. Тем, кто уже имеет навык использования других языков программирования, эти уроки могут показаться нудными и затянутыми. Но таким людям и не нужны подобные уроки, а достаточно какой-нибудь статьи в духе "Lua за 60 минут", да справочника по API библиотек модов. Главный совет начинающему программисту: всегда использовать полученные знания в своих программах. Не страшно, если программа будет примитивной. Главное, наработать навык использования тех или иных конструкций, приёмов программирования. Книги, статьи, гайды, обсуждения на форумах обогащают практику программирования, но не заменяют ее. Короче: программистом можно стать только через написание программ.

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

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

Как в том анекдоте: либо штаны наденьте, либо крестик снимите. Дело в том, что в Lua нет именованных констант. Но если значение переменной не меняется в течение срока её жизни, такую переменную условно можно назвать константой. Условно. Но так как обсуждаемые переменные не являются локальными, и срок их жизни может превышать время выполнения программы, и нет никаких гарантий, что их не изменит другая программа, то константами такие переменные не могут называться даже условно. В общем, выбирай: либо это совсем не константы, либо локальные переменные, которые можно условно назвать константами. А это вообще шедевр. Особенно после предыдущего заявления: Так кто накатал программку: @Laine_prikol или @Doob? И если это вторичное творчество, то почему нет ссылки на оригинал, и описания отличий от него? И кто теперь будет сопровождать этот код? Пушкин? @Doob?

Точно. Обожаю рыть норы, чтобы в норах строить коробки. Зато рабочее пространство функционально, а порча территории минимальна. Отлично! Можно сильно сэкономить на хранении общей карты, применив дельта-кодирование.

6 блоков не особо укроют от любопытных глаз. При достаточном запасе времени и энергии многократное сканирование рано или поздно распознает любую плотность со сколь угодно большой точностью. Другое дело, что этот процесс вероятностный, и точное количество необходимых сканирований заранее спрогнозировать невозможно. Зато оболочка в 32 блока принципиально непреодолима для геосканера. Печаль лишь в том, что от доступного привата в 500k блоков на EvilWorld при такой жирной скорлупе останется менее 4k блоков полезной ёкмости.

Киты работают, а хелп не хочет: /help У Вас нет прав для выполнения данной команды.