eu_tomat

15 минут назад, hohserg сказал:

Правильно ли я понимаю, что собственное охлаждение теплоотводов работает независимо от охлаждения корпуса реактора?

Типо, нагретый теплоотвод даже в горячем реакторе остывает с той же скоростью, что и в холодном? И при этом и нагретый и полностью целый теплоотвод охлаждают реактор одинаково?

Да, независимо. Корпус реактора охлаждается одинаково что холодным, что нагретым теплоотводом.

Разогнанный теплоотвод рассеивает тепло со скоростью 20 hu/s независимо от поступления тепла с корпуса реактора. Но может рассеивать и меньше 20 hu/s, если теплоотвод не содержит в себе достаточного количества тепла.

И наоборот, если корпус реактора содержит в себе достаточно тепла, разогнанный теплоотвод будет принимать его тепло со скоростью 36 hu/s независимо от своей способности рассеивать это тепло.

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

25 минут назад, hohserg сказал:

нагретый теплоотвод даже в горячем реакторе остывает с той же скоростью, что и в холодном

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

2 часа назад, Doob сказал:

Значит схема в мусорку.

Торопишься как @serafim . Он сначала бросился писать код, не оценив схему, а потом, посчитав её безнадёжной, поспешил закончить разработку.

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

 А вот и свежая для меня идея, добытая благодаря обсуждению:

2 часа назад, Doob сказал:

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

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

2 часа назад, Doob сказал:

И получаем лагодром.

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

По предложенным оптимазациям:

2 часа назад, Doob сказал:

просто в фазе охлаждения на 1-2 стержня меньше, следовательно, и энергии немного меньше... Вкл/выкл это не эффективно.

Всё верно. Сейчас можно оптимизировать схему и в этом направлении тоже. А на последующих этапах эта оптимизация станет обязательной. Я же опасаюсь, что пока мы не найдём оптимальные ТВЭЛ'ы и их расположение относительно друг друга, все предшествующие оптимизации придётся повторить.

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

Друзья, если вам что-то непонятно, берите инициативу в свои руки, задавайте вопросы. Иначе я буду ориентироваться на уровень понимания @Doob , а диалоги у нас с ним получаются специфические.

8 часов назад, Doob сказал:

Задачу можно решить и динамическим программированием

Это пока лишнее. Задачу можно решить, оперируя лишь математикой и логикой школьного уровня.

8 часов назад, Doob сказал:

А вот с MOX наоборот, эффективность сильно прыгает

Предлагаю пока разобраться с ураном. MOX требует других подходов.

22 минуты назад, Doob сказал:

Попробовал в оптимизацию руками, цель - максимальная эффективность и выхлоп энергии.

Получается, что алгоритм будет сначала разгонять реактор с максимум EU/t, потом выкидывает стержни и охлаждает корпус, затем опять докидывает стержней.

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

Теперь схема из двух реакторов генерирует 1540 eu/t, создавая избыточное тепло со скоростью 3312 – 8*9*20 = 3312 – 1440 = 1872 hu/s. В фазе охлаждения энергия не генерируется, а компоненты охлаждаются со скоростью 6*9*2*20 = 2160. Для приведения теплового баланса к нулю доля времени, занимаемого фазой генерации, должна составлять 0.536, а фаза охлаждения – 0.464, и таким образом, средний выход энергии с одного реактора составит 0.536*1540/2 = 412 eu/t. До этой оптимизации было всего 334 eu/t.

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

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

В фазе генерации реактор генерирует 1540 eu/t, создавая избыточное тепло со скоростью 3312 – 2*9*20 = 3312 – 360 = 2952 hu/s. В фазе охлаждения энергия не генерируется, но компоненты охлаждаются со скоростью 6*9*20 = 1080 hu/s. Для приведения теплового баланса к нулю доля времени, затрачиваемого на генерацию энергии, должна составлять 0.268, а фаза охлаждения – 0.732, и таким образом, средний выход энергии с одного реактора составит 0.268*1540 = 412 eu/t.

Что и требовалось доказать. Второй реактор никак не влияет на увеличение средней производительности реактора.

Для реакторов, максимизирующих выход энергии, есть правило №2: каждый слот должен приносить максимальную пользу.

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

С охлаждающими элементами всё понятно: ничто другое не сравнится с разогнанным теплоотводом, рассеивающим 20 hu/s. Теперь следует оптимизировать схему размещения ТВЭЛ.

Кто догадался, в чём недостаток использованной схемы размещения ТВЭЛ? И как вычислить удачную схему?

В 06.08.2020 в 14:56, eu_tomat сказал:

Твоя схема генерирует 3312 hu/s, а рассеивает в идеале 9*8*20=1440 hu/s. Если регулярно останавливать реактор для охлаждения теплоотводов, то средняя выработка энергии снизится до 466 eu/t, а если учесть, что в схеме работают два реактора, то получаем жалкие 233 eu/t на реактор. Схема явно нуждается в оптимизации.

Я ошибся в расчёте теплового баланса. В фазе генерации энергии компоненты схемы нагреваются на 3312 – 1440 = 1872 hu/s, а в фазе отдыха охлаждаются на 1440 hu/s. Средняя производительность реактора составит 334 eu/t, что более оптимистично. Но потенциал для оптимизации всё равно сохраняется.

Кому удалось ответить на вопрос и обнаружить неэффективность работы одного из реакторов в фазе охлаждения?

Даю ещё одну подсказку: Основной реактор охлаждает компоненты со скоростью 2*9*20 = 360 hu/s, а дополнительный (в идеале): 6*9*20 = 1080 hu/s. В чём причина неэффективности основного реактора? И как её устранить?

2 часа назад, Doob сказал:

Можно не страдать над алгоритмом. Если переложить задачу на язык машинного обучения, то она сразу решится (т. к. цикл реактора статический). Только тут надо писать эмулятор, либо его подобие, чтобы удобно было зарешать.

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

В 06.08.2020 в 19:44, whiskas сказал:

Ну и задержка в 1 тик звучит не сильно много. Но это 1 тик на действие что длится 1 тик. Тоесть в 2 раза медленее

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

В случае одной операции накладные расходы удваиваются. А в случае 100 операций они составляют всего один процент.

Если цепочки перемещений длинные, то имеет смысл вспомнить о роботах. Они способны перемещать 8 стак*блок/тик. Транспозеры же перемещают всего 2 стак*блок/тик. Транспозеры в 4 раза медленее, при этом они требуют в 8 раз больше операций на единицу времени и в 32 раза на единичное перемещение стака.  Поэтому роботы более предпочтительны для транспортировки на дальние дистанции. Минус роботов лишь в ожидании погрузки и разгрузки, но на длинных дистанциях это не критично.

51 минуту назад, Doob сказал:

хранилище на умных трубах, всяко умнее "умных воронок".

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

А в остальном я с тобой согласен: не надо заставлять сервер молотить то, что можно получить без молочения.

7 минут назад, Doob сказал:

Если же пускать стержень по кольцу из реакторов, то тепловыделение можно свести в ноль

Кольцо реакторов решает задачу ускорения сжигания топлива. А @serafim своей схемой пытается поднять производительность отдельного реактора. Цели он пока не достиг, но скоро достигнет. При желании обе задачи можно объединить, прогоняя десять урановых сборок через десять реакторов, если сервер справится с нагрузкой.

55 минут назад, serafim сказал:

без OC оно не буде работать от слова совсем

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

Когда-то я писал в своём блоге про сизифов код. Это наш случай: плохой алгоритм невозможно спасти хорошим кодом.

51 минуту назад, serafim сказал:

Идея было заставить работать реактор беспрерывно, но это невозможно,

Реактор может работать непрерывно, если не требовать от него невозможного.

46 минут назад, serafim сказал:

Никак, городить ещё отстойников не вариант, их также придётся учитывать в расчёте конечной энергии

Спрошу иначе. Какой из двух реакторов в твоей схеме более эффективен в фазе охлаждения? И что мешает другому реактору быть таким же эффективным?

14 минуты назад, serafim сказал:

Жаль, но из за постоянных простоев в следствии быстрого израсходования теплоотводов дальнейшая разработка не актуальна 

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

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

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

2 минуты назад, serafim сказал:

Да реактор отключается, изначально пытался менять на горячую, но в конечном итоге теплоотвод выгорал полностью

Да, в конечном итоге выгорят все теплоотводы. Твоя схема генерирует 3312 hu/s, а рассеивает в идеале 9*8*20=1440 hu/s. Если регулярно останавливать реактор для охлаждения теплоотводов, то средняя выработка энергии снизится до 466 eu/t, а если учесть, что в схеме работают два реактора, то получаем жалкие 233 eu/t на реактор. Схема явно нуждается в оптимизации.

9 минут назад, serafim сказал:

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

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

5 минут назад, serafim сказал:

Беспрерывно на 1540 eu/t они и не работает, присутствуют простои, теплоотводы слишком быстро изнашиваются

А что происходит во время простоев? Основной реактор просто отключается, ожидая, пока теплоотводы охладятся?

6 минут назад, serafim сказал:

Программа не привязана к схеме, она занимается отслеживанием и заменой теплоотводов

А чем оправдан обмен теплоотводов между реакторами в этой схеме?

6 минут назад, serafim сказал:

На данный момент я отлаживаю прогу инструмент, если всё получится тогда будем думать о схеме

Я боюсь, что после доработки схемы прогу придётся переписывать.

4 минуты назад, serafim сказал:

После некоторых доработок бесконечно, но некоторые моменты в работе проги меня не устраивают

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

14 минуты назад, whiskas сказал:

емм это вроди невозможно. Там можна контроллер инвентаря вроди но транспоузер подключить нельзя

Засовываем транспозер в контроллер во время сборки.

В EEPROM пишем код:

-- EEPROM для микроконтроллера со встроенным транспозером:
-- ладодром, переносящий предметы снизу вверх.

local transfer = component.proxy(component.list"transposer"()).transferItem

while true do
  transfer(0,1)
end

Работает, проверено на OC 1.7.5.

14 часа назад, hohserg сказал:

В задаче с конвейером виртуальные компоненты очень помогут.

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

С задачей увеличения производительности виртуальные компоненты пока справляются плохо. Но в этой идее есть рациональное зерно.

В 05.08.2020 в 12:04, whiskas сказал:

к каждому внешнему компоненту подключать компютер и подключать его к серверу. Потом написать программу что будет виртуализировать компоненты компов для сервера

Предлагаю расширить изначальную идею и считать виртуальным компонентом весь удалённый компьютер (микроконтороллер, робот, дрон) с любыми подключенными к нему реальными компонентами.

А вместо синхронно управляемого конвейера я предлагаю систему умных воронок.

Умная воронка это микроконтроллер со встроенным транспозером и простой программой в EEPROM, которая принимает к исполнению задачу от управляющего компьютера. Задачи могут быть любыми: перемещать все обнаруженные предметы с максимальной скоростью с запада на юг, или с востока и севера наверх; выбирать направление перемещений в зависимости от типов предметов или других условий; сообщать управляющему компьютеру об изменениях в инвентаре; и т.п.

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

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

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

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

40 минут назад, serafim сказал:

просто пытался выжать как можно больше eu/t совмещая стержни

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

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

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

Вопрос: как долго сможет проработать предложенная тобой схема (якобы на 1540 eu/t)?

33 минуты назад, whiskas сказал:

(Селекторов 16 шт) Иза бага там нельзя использовать .setSlots(). Приходится юзать setSlot(). В итоге 9*16 = 144 тика идет на выведение вещей на селекторы.

Соглашусь. Тут приходиться костылить всеми доступными способами.

34 минуты назад, whiskas сказал:

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

А это сомнительно. Есть рабочие примеры такого трюка?

35 минут назад, whiskas сказал:

Также видил прогу что выводит содержымое кучи сундуков на монитор. Там можна розпаралелить и тогда можна будет обновлять сундуки каждый тик а не каждых (количество сундуков/20) сек.

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

41 минуту назад, whiskas сказал:

Можна будет заюзать в реакторах для ускореной замены стержней и охладителей (меньше шанс взорвать).

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

Да и в других задачах тоже нет смысла использовать виртуальные компоненты или групповое управление компонентами. Это неэффективно. Нужна возможность передать на исполнение свой кусок задачи и периодически контролировать состояние исполнителей.

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

1 час назад, whiskas сказал:

Можна сделать комп что будет мониторить куча реакторов и их состояние.

Можно. Но какое преимущество тут дают виртаульные компоненты?

59 минут назад, whiskas сказал:

у меня возникла идея

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

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

54 минуты назад, whiskas сказал:

Тогда теоретичиски можна будет ускорить работу многих програм засчет обхода ждания тика.

Многих? Можешь привести десяток примеров, где ускорение окажется ощутимым?

Да, теоретически можно ускорить работу некоторых специфических программ в некоторых специфических условиях. Но надо учесть лаги: лаг на отправку команды по сети, лаг на отправку ответа и лаг на приём всех ответов.

2 часа назад, serafim сказал:

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

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

• Какова схема размещения компонентов во втором реакторе?
• Какой цели достигает использованное решение? В чём заключается его основное преимущество?
• Каков общий тепловой баланс обоих реакторов?
• Как решается проблема перегрева компонентов?

7 часов назад, serafim сказал:

Но конфигом не снять ограничение в 8192 eU/t, почему то разрабы IC2 против того, чтоб мы пользовались неограниченной энергией.

Разрабы, скорее всего, и знать не знают, что кто-то пытается снять с реактора больше 8192 eu/t. А если и узнают, то, как минимум, потребуется добавить приёмники такой энергии.

Интересно, а GT снимает с реакторов ограничение по выработке энергии? Там же есть соответствующие провода, трансформаторы и энергохранители.

10 часов назад, yura0138 сказал:

Плохо, по крайней мере для меня

А что мешает вместо красного контроллера использовать красную плату?

4 часа назад, yura0138 сказал:

вопрос, при рестарте ПК и робот отрубаются, отрубится ли реактор?

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

4 часа назад, yura0138 сказал:

Прога встаёт, можно ли сделать так, чтоб она не вставала, если надо заменить больше 2-ух кондеров?

Это возможно. По крайней мере, теоретически.  В пределе можно заменить и 10 конденсаторов между реакторными тиками, но это уже на грани возможного. Малейший лаг приведёт к сгоранию конденсатора. На реальном же сервере всё зависит от лага OC относительно тиков реактора.

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

28 минут назад, hohserg сказал:

Кстати, до сих пор я не видел чисел. Проводились ли кем-то статистические исследования TLWY? Известна ли зависимость вероятности возникновения TLWY от тпс при использовании какого-то эталонного кода(типо, бесконечный цикл с ожиданием 0 сек внутри)?

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

9 часов назад, hohserg сказал:

А если сделать кучу вложенных pcall? Это позволит размазать вероятность TLWY по ним всем и тем самым уменьшить вероятность TLWY на pcall верхнего уровня?

Каждый дополнительный уровень вложенности кода в pcall позволяет немного снизить шанс аварийного отключения компьютера. Для устремления этого шанса к нулю размер вложенности должен стремиться к бесконечности.

Имеющиеся ограничения в OpenComputers позволили мне достичь лишь 195 вложений pcall, а на 196'ом я получил «stack overflow».

Поэтому на сильно перегруженном сервере большинство лагодромов завершится синим экраном с надписью «too long without yielding». Максимальная же вложенность кода в pcall позволит лишь немного отсрочить неизбежное.

20 минут назад, Taruu сказал:

Те из разряда те ошибки которые я со своими часами делал?

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

Сервер можно положить с помощью как CC, так и OC. CC немного облегчает задачу, но и OC тоже имеет достаточный потенциал. Для этого не нужны даже 8 человек, достаточно и одного игрока, если тот поставит перед собой такую задачу. И проблема не столько в количестве самих компов, сколько в количестве и качестве лагодромав, запущенных на компах.