eu_tomat

А кто утверждал, что нужно вызывать перед каждым? Приведённые примеры демонстрируют высокую степень предопределённости первого числа. Остальные числа также предопределены, это легко проверяется. Изначально речь шла о том, что именно в Lua эта предопределённость заметна невооружённым глазом, в отличие, например от Python. Возможно, там присутствуют миллисекунды или микросекунды, и я физически не смог запустить скрипт с такой точностью. В серьёзных задачах такая случайность тоже может не играть решающей роли, поэтому есть, например, /dev/random. Его, конечно, тоже можно хакнуть, но это уже лежит на ответственности админа, допускающего подключение устройств, способных выдавать себя за достоверные источники энтропии. А источники энтропии существуют. По крайней мере, на существующем технологическом этапе они могут считаться таковыми.

Не всегда и не везде. Например: $ lua5.2 -e 'print(math.random(),math.random(5))' 0.84018771715471 2 $ lua5.2 -e 'print(math.random(),math.random(5))' 0.84018771715471 2 $ python -c 'import random;print random.random()' 0.721716743456 $ python -c 'import random;print random.random()' 0.0560445795169 Как можно видеть, python как-то сам инициализирует генерацию ПСЧ. Насколько случайно зерно, и берёт ли python энтропию из системы, я не проверял. Зато неслучайность генерации ПСЧ на Lua обнаруживается даже примитивным экспериментом. А насколько случайно зерно в randomseed, это отдельный вопрос. В большинстве случаев кода его значение тоже далеко от случайного: $ lua5.2 -e 'math.randomseed(100500)print(math.random())' 0.58517133751194 $ lua5.2 -e 'math.randomseed(100500)print(math.random())' 0.58517133751194 Замена зерна на os.time() тоже не много меняет, хотя и добавляет чуть-чуть случайности. Но совсем немного: $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.26793141616508 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.68165180506185 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.68165180506185 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.094727045390755 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.094727045390755 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.094727045390755 $ lua5.3 -e 'math.randomseed(os.time())print(math.random())' 0.0091965580359101

Исправил. Кстати, пост выше чётко демонстрирует отсутствие настоящей случайности.

В 5.2 тоже нормально: $ lua5.2 -e 'print(math.random(),math.random(5))' 0.84018771715471 2 $ lua5.3 -e 'print(math.random(),math.random(5))' 0.84018771676347 2

Да, делает. Мой вопрос оказался не по адресу. Тут кто как понял вопрос автора, тот так на него и ответил. А вопрос автора оказался неоднозначным. Потому как math.random возвращает либо целое число, которое изначально не требует дополнительного округления, либо возвращает вещественное число, отбросив дробную часть которого, мы всегда будем получать ноль. А в какой версии Lua так происходит?

Можно. Но для какой цели?

math.random() генерирует псевдослучайное вещественное число в диапазоне[0 до 1] math.random(upper) генерирует целое число в диапазоне [1..upper]; math.random(lower, upper) генерирует целое число в диапазоне [lower..upper].

В сказке: слетел сокол с дуба, ударился оземь и обернулся добрым молодцем. В майне: слетел свин с дрона, ударился оземь и обернулся добрым холодцом.

Как "так"? Беспроводной платой первого уровня?

Да, при штатной работе программы достаточно соотнести тики реактора с тиками, которые смог обработать компьютер. TPS как таковой вообще не обязательно знать. Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора. Чем меньше ресурсов потребляет комп, чем чаще он находится в простое, тем ниже вероятность, что он отключится по TLWY. Правда, на практике может оказаться, что наш код выполнил уступку времени на несколько тиков, передав управление методу компонента, и поэтому формально наш компьютер простаивает. При этом сам майн, обрабатывая вызванный кодом метод, может лагать. Это предстоит выяснить экспериментально. Но в целом это правило подтверждается: чем больше времени код тратит на вычисления и чем реже обращается к периферии, тем меньше его вклад в лаги, и тем меньше вероятность возникновения TLWY конкретно для этого компьютера. MineOS кроме прочих несёт ещё и эстетическую функцию в "мирное" время. И аварийное отключение компа с MineOS во время лагов меня не огорчит. Но лагомерки в наших watchdog'ах, должны погаснуть в последнюю очередь. Это не проблема, если отказаться от измерения именно TPS. Более того, как верно заметил @Doob, тикрейт может быть штатно изменён модами. Да, метод computer.uptime всегда показывает тики, хотя и представляет их в виде секунд. Фокус же в том, что выполнение одного и того же кода может занимать разное количество тиков в зависимости от лагов сервера. И для лагомерки я предлагаю эксплуатировать именно эту особенность.

Я сейчас прогулялся по морозцу и свежим мозжечком вот что надумал. Ты прав. Пытаться во что бы то ни стало включить комп, управляющий реактором, сейчас является плохой идеей. Идя по этому пути, готовые схемы микроконтроля реакторов я ещё долго не выложу. Как я вижу схему аварийного включения сейчас: Есть компьютер или микроконтроллер, управляющий реактором. Он выполняет свою основную задачу, заодно анализируя её выполнимость в текущих условиях. Это несложно. Если расчёты указывают на невозможность решения, комп пытается более-менее управляемо остановить процесс (в зависимости от использованной схемы) и переходит в режим лагомерки. Когда ситуация нормализуется, программа возобновит управление реактором. Если, конечно, не выключится сам комп. Рядом с основным компьютером стоит микроконтроллер, который в режиме ожидания отслеживает статус соседа. Если тот погас, то микроконтроллер включает лагомерку, а когда лаги стихнут, с некоторой периодичностью пытается разбудить комп. Этот микроконтроллер наибольшую часть работы будет тратить на сон. Но если и он погаснет, то лишь во время чего-то действительно страшного и опасного. Тут главное, чтобы сами лагомерки создавали минимальную нагрузку на сервер. Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода? for i=1,3 do computer.pullSignal(0) end computer.pullSignal(0.01) t = computer.uptime() Такой код по идее должен жрать очень мало ресурсов.

Да, оказалось, генерирует. Но только во включенном компьютере. А красная карта генерирует событие даже в выключенном, без процессора и памяти. Теперь понятно. Логика в том, что такова механика на данный момент. И уже не так важно, для каких компонентов событие генерируется только во включенном состоянии содержащего их корпуса, а для каких даже в выключенном. Просто надо быть готовым к тому, что может прийти сообщение от компонента с другого компа в той же сети. С глюками обновления понятно. Но отключение и включение монитора красным сигналом разве является фичей? Оказалось, является. Нигде не нашёл упоминания об этом в документации, но помог код tileentity/Screen.scala: override protected def onRedstoneInputChanged(args: RedstoneChangedEventArgs) { ... origin.buffer.setPowerState(!origin.buffer.getPowerState)

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

Что-то при такой логике вопросов больше чем ответов. Да, функционал остаётся. Но разве он должен быть доступен для другого компьютера? Тогда, может, и сетевая карта тоже должна генерировать события в другом компьютере? Но не генерирует. И почему доступно событие от компонента без доступности самого компонента?

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

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

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

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

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

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

Я, кажется, нашёл мелкий баг в OpenComputers-MC1.7.10-1.7.5.1290-universal.jar, на других версиях не проверял. Спавним компьютер командой /oc_sc, в интерпретаторе Lua запускаем что-то вроде while true do print(computer.pullSignal())end и наблюдаем за поступающими событиями. Вплотную к корпусу компа ставим ещё один корпус, ловим событие component_added, но это не удивительно. Вставляем в пустой корпус красную плату, событие не ловится, что тоже неудивительно: корпус-то другой. Ставим рядом со вторым корпусом красный факел и... ловим событие redstone_changed в первом компе. Компонент redstone отсутствует в списке компонентов первого компа, но событие этого компонента ловится. Второй корпус пустой, в нём нет ничего кроме красной платы. Upd: Компы не обязательно ставить в смежных блоках. Соединив их кабелем, получаем тот же эффект. 

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

Более подробно об использовании символических ссылок я рассказывал в этом посте:

Да, это другое. У тебя более жестокая штука.

У меня работает и на новой версии (OpenComputers-MC1.7.10-1.7.5.1290-universal.jar) тоже. При повышении нагрузки сначала начинают тупить компы, а затем появляются фризы в Майнкрафте.