eu_tomat

Вот скрин ошибки, запускается программа не с первого раза, помогает перезагрузка.

Странно. Если и монитор и видеокарта третьего уровня, то такая ошибка при смене разрешения не должна возникать, и её появление не должно зависеть от используемой OS.

немного багованно

Нужна конкретика. Иначе нечего обсуждать и улучшать.

Первый (в порядке появления, а не по важности) совет: освоить шестнадцатеричную запись цветов. Записиь вида

robot.setLightColor(0xFF8080) сегодня понятна не только программистам, но и многим дизайнерам. Даже они, далёкие от тонкостей систем счисления, оценили удобство такой записи. В результате промежуточная функция colorRGB() становится ненужной, а запись выглядит компактнее. Впрочем, для кого-то запись из трёх десятичных чисел более понятна, и потому имеет право на существование.

 

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

	local powerSteps = #cl
	local e = tonumber(pc.maxEnergy())
	local pStep = math.floor((e / powerSteps))

	local function currentPowerStep()
		e = pc.energy()
		local result = powerSteps
		local process = true
		for i = 1, powerSteps-1 do
			if (e < (pStep*i)) and process then
				result = i
				break
			end
		end
		return result
	end

Здесь используется цикл и проверка условия внутри него. В зависимости от текущего состояния робота выполняется соответствующее количество итераций. Но это вычисление можно всегда выполнить за одну итерацию.

local idx = math.ceil(computer.energy() / computer.maxEnergy() * #colors)
robot.setLightColor(colors[ idx>0 and idx or 1 ])

Такой код записывается короче, выглядит проще, а работает быстрее. И памяти меньше требует.

@@HeroBrine1st, можешь пояснить назначение этого хитрого участка кода?

	print("Перезапись ключа в ОЗУ 35 раз")
	for i = 1, 35 do
		psk = string.random(psk:len())
	end
	print("Удаление ключа из ОЗУ")
	psk = nil

Насколько я знаю, достаточно последней строчки, если речь идёт об OpenComputers, а в контексте языков, приближенных к машинным, достаточно лишь один раз переписать находящийся в RAM ключ. Или есть иная информация?

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

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

Как работает реактор, я не знаю. Прокомментирую только вывод этой масштабной ASCII-картинки. Я бы предпочёл избавиться от кучи gpu.set, чтобы снизить шансы на ошибку в номерах строк:

-- вывод многострочного текста на gpu

local com = require "component"
local gpu = com.gpu

local text = [[
string111
string222
string333
string4
string5
]]

local row=0

for txt in text:gmatch( "([^\n]+)" ) do
  row = row + 1
  gpu.set( 1, row, txt )
end

-- альтернативный вариант кода:
text:gsub( "([^\n]+)", function( txt )
  row = row + 1
  gpu.set( 1, row, txt )
end)

Люди в реальной жизни смысл найти не могут, а вы тут пытаетесь обнаружить его в Майнкрафте =)

Мы не ищем смыслы. Мы их создаём.

И если человек говорит о какой-то стратегии, значит, у него есть цель, и он знает смысл. Вот, его-то мы и пытаемся понять.

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

 

А чтобы эта индикация не жрала много энергии, для начала следует оптимизировать код. Например, не вычислять в цикле то, что легко вычисляется и без цикла.

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

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

Он называется microcontroller. Вполне адекватный мод как я понимаю. С руководством по командам. И блоком памяти. Но там не lua, там какие-то низкоуровневые команды. Подобное программирование встречал в игре TIS-100.

О, ассемблер. Неплохо. Это поинтереснее, чем проводками в комбинаторы тыкать.

 

И вот как раз для техники есть мод aai programmable structures и aai programmable vehicles позволяющий ставить структуры ввода/вывода логических сигналов, которые связаны с техникой по id техники. Хотя AAI модов немного больше, это также специальные атакующие машины, сборщики руд. И всё можно программировать комбинаторами посредством логических сигналов.

AAI тоже интересно выглядит, но программируется всё теми же комбинаторами.

 

Я играл в Fcatorio. В начале было интересно, но на поздних стадиях игры хочется чего-то другого.

 

Чего-то похожего на screeps. В идеале, чтобы все стационарные объекты обслуживались мобильными юнитами, а те управлялись бы пользовательским скриптом. И чтобы можно было с ранних стадий игры обойтись одними лишь мобильными юнитами первого уровня без лент и манипуляторов, а на поздних – без автоматических дронов, как транспортных, так и строительных.

 

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

 

Такие смутные мысли крутились у меня во время игры в Factorio.

Чтобы новые панели делали иридий для новых панелей.

Предположим, стратегия и её цель – одно и то же:

 

Новые панели делаются, чтобы сделать еще больше панелей.

Посты на форуме пишутся, чтобы написать ещё больше постов на форуме.

Новые моды выпрашиваются, чтобы выпросить ещё больше новых модов.

 

Кажется, в этом нет никакого подвоха.

Недавно мод скачал на комбинатор программируемый. Можно то есть самому писать свои команды.

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

Как хотите.Будет тогда поле.

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

 

А про цель стратегии ты так и не ответил.

А стратегия это производство иридия для новых панелей.

Это всем понятно: производство иридия для новых панелей для производства иридия для новых панелей. Это суть стратегии. А цель стратегии всё-таки в чём?

Такая стратегия не только у меня.

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

Ты не понял.Я не про то,сколько утиля выйдет  из определенного количества предметов,а скорость переработки этих предметов в утиль.

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

Таким образом, в современных версиях имеет смысл ставить и больше 10 ускорителей для достижения большей скорости, но нужно организовать высокоскоростную подачу вещей (вплоть до полного стака за тик)

Стак сырья за тик тебя устроит?

По скрину видно что не принимает более двухзначные числа, потому-что local utm = computer.uptime()

print('КОмпьютер уже работает'..utm) Показывает 7к секунд, а я задал перезагрузку через 100 секунд, пк в итоге не перезагрузился

Не заметил это сообщение сразу, отвечу сейчас:

Проверить, какие числа принимаются, а какие нет, можно, вставив для контроля print() сразу же за read():

local vremua = io.read("*n")
print(vremua)

Такой отладочный код поможет увидеть, что число всегда возвращается верное.

 

И почему-то не заметил это:

А еще программа пропускает  zn = io.read()

Действительно, после чтения числа через 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.

16 утиля в секунду нужно.Алекс же уменьшил шанс выхода утиля.Так что сложно добиться такой скорости.

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

 

А кроме того

Я думаю,что будет больше лагов от пол сотни обычных механизмов чем от одного улучшенного.

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

 

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

Ну если бы не было етих противных скобочек local krua  = (10*10) print (krua) код бы выдавал правильный ответ, а не то что я написал((( ЖАль что нету аргумента для io.read() типо '*n' который присваивает етой переменной хначение без "" (надеюсь понятно сформулировал речь)

Эта задача решается даже с противными скобочками:

local expr="2+2*2"
print( load("return "..expr)() )

И еще раз говорю, io.read тут не при чём, дело в синтаксисе языка.

 

Можно и так:

local value = load("return " .. io.read() )()
print( value )

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

Advanced Machines - дополнение к моду Industrial Craft,добавляющее улучшенные механизмы.Достоинства этих механизмов заключаются в их скорости,но они требуют больше энергии и ресурсов для крафта.

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

А не можешь подсказать как сделать что бы при записи переменной через io.read она записываласчь не как "переменная" а переменная без "" Просто ето убивает много моих говнокодов

Если я верно понял вопрос, то никак. И дело не в 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

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

НУ короче) У меня мой говнокод почему-то не очень работает, и принимает значения для vreuma только двухзначные тоесть значение 100 уже не принимает, вижно на скрине)

А как на скрине можно увидеть, что значение 100 не принято?

 

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

 

Если код переписать код таким образом: zn == "y", то он выполнит сравнение переменной zn с символом "y", в случае успеха направив выполнение программы по первой ветви. Аналогичным образом следует поправить и вторую ветвь условия.

есть пара возражений

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

 

Открытие двери не требует вот прямо моментальной реакции как правило

Есть и контрпримеры. Основным процессом может быть запущена zip-архивация, в результате работы которой двери будут открываться фоновым процессом с лагом в несколько секунд. А динамические схемы ядерных реакторов вообще требуют контролируемой задержки. Нужна уверенность в том, что при вызове computer.pullSignall() задержка будет иметь погрешность в пределах одного тика. Работа такой программы в фоне может привести к взрыву реактора.

 

Упрощённые компьютеры - это замечательно, но если дверей/люков десяток, а игроков, которые ходят через них туда-сюда не так много (зачастую один владелец привата) , то один выделенный компьютер может быть более выгодным и легче расширяемым вариантом.

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

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

 

rc кроме всего прочего позволяет в rc.conf хранить конфиг к модулю и не переписывать код при добавлении новых сенсоров и редстоун-контроллеров

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

 

 

Итог всё тот же: решение может считаться плохим или хорошим лишь применительно к конкретной задаче.

 

Ну, а применительно к нашему форуму задачей вообще может оказаться получение опыта работы с RC. Тут выбор очевиден, против этого не возразить. И уж точно, не смотря на существование альтернатив, твой код заслуживает внимания. Это не оспаривается. Хорошая работа.

Ответ по существу уже прозвучал, но меня смущает формулировка вопроса:

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

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

 

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

завтра скину куда нибудь на пастебинчик.  Спать уже иду. Там прожка детская на 60-120 строчек, если выкинуть фейк-таблу юзверей и комменты к коду.

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