eu_tomat
-
Публикации
2 666 -
Зарегистрирован
-
Посещение
-
Победитель дней
331
Сообщения, опубликованные пользователем eu_tomat
-
-
@HixOff задал в чате вопрос об интеграции Advanced Rocketry с OpenComputers:
ЦитатаHixOff 25 Ноября 0:41
пщщ, никто не вкурсе, были любители прикручивания advRocketry к OC? А то сами по себе они не умеют, а вот раздербанить чужие костыли...Отвечаю:
На данный момент возможна частичная интеграция этих модов. Максимум, чего удалось достичь мне, это получить доступ к инвентарям машин с помощью мода OpenPeripheral. -
8 минут назад, NEO сказал:если вызвать randomseed без аргументов он берёт для генератора два сида - это time(NULL) и адрес lua_State
У меня этот трюк не проходит:
$ lua5.2 -e 'math.randomseed()print(math.random())' lua5.2: (command line):1: bad argument #1 to 'randomseed' (number expected, got no value)
-
Только что, Totoro сказал:Ну, во-первых, вызывать randomseed перед каждым вызовом random не нужно.
А кто утверждал, что нужно вызывать перед каждым? Приведённые примеры демонстрируют высокую степень предопределённости первого числа. Остальные числа также предопределены, это легко проверяется. Изначально речь шла о том, что именно в Lua эта предопределённость заметна невооружённым глазом, в отличие, например от Python.
2 минуты назад, Totoro сказал:Ну а что касается Питона, он просто сам задаёт сид основанный на времени. Насколько я знаю.
Возможно, там присутствуют миллисекунды или микросекунды, и я физически не смог запустить скрипт с такой точностью. В серьёзных задачах такая случайность тоже может не играть решающей роли, поэтому есть, например, /dev/random. Его, конечно, тоже можно хакнуть, но это уже лежит на ответственности админа, допускающего подключение устройств, способных выдавать себя за достоверные источники энтропии. А источники энтропии существуют. По крайней мере, на существующем технологическом этапе они могут считаться таковыми.
-
36 минут назад, Totoro сказал:Ну это всегда и везде же так.
Именно поэтому нужен метод math.randomseed(...).
Не всегда и не везде. Например:
$ 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
-
15 минут назад, NEO сказал:Псевдо-случайное.
Исправил. Кстати, пост выше чётко демонстрирует отсутствие настоящей случайности.
-
29 минут назад, hohserg сказал:Видимо, в 5.2, где еще не выделен int. Хотя в 5.2 у ТС не возникли бы проблемы с этим
В 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
-
1 минуту назад, 8urton сказал:Разве math.floor() не делает из 4.0 - 4?
Да, делает. Мой вопрос оказался не по адресу. Тут кто как понял вопрос автора, тот так на него и ответил.
А вопрос автора оказался неоднозначным. Потому как math.random возвращает либо целое число, которое изначально не требует дополнительного округления, либо возвращает вещественное число, отбросив дробную часть которого, мы всегда будем получать ноль.
1 час назад, ArtHacker сказал:Просто math.random() в конце ещё .0 добавляет. Нам не нужно дробное число.
А в какой версии Lua так происходит?
-
3 минуты назад, 8urton сказал:можно использовать math.floor()
Можно. Но для какой цели?
-
- math.random() генерирует псевдослучайное вещественное число в диапазоне[0 до 1]
- math.random(upper) генерирует целое число в диапазоне [1..upper];
- math.random(lower, upper) генерирует целое число в диапазоне [lower..upper].
-
2
-
1
-
В сказке: слетел сокол с дуба, ударился оземь и обернулся добрым молодцем.
В майне: слетел свин с дрона, ударился оземь и обернулся добрым холодцом.
-
1
-
5
-
-
1 час назад, maxutka99 сказал:Только так свинью очень легко ушатать
Как "так"? Беспроводной платой первого уровня?
-
2
-
-
1 час назад, Doob сказал:Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе?
Да, при штатной работе программы достаточно соотнести тики реактора с тиками, которые смог обработать компьютер. TPS как таковой вообще не обязательно знать. Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора.
2 часа назад, BrightYC сказал:Мне непонятно зачем гнаться за "должен жрать очень мало ресурсов".
Чем меньше ресурсов потребляет комп, чем чаще он находится в простое, тем ниже вероятность, что он отключится по TLWY. Правда, на практике может оказаться, что наш код выполнил уступку времени на несколько тиков, передав управление методу компонента, и поэтому формально наш компьютер простаивает. При этом сам майн, обрабатывая вызванный кодом метод, может лагать. Это предстоит выяснить экспериментально.
Но в целом это правило подтверждается: чем больше времени код тратит на вычисления и чем реже обращается к периферии, тем меньше его вклад в лаги, и тем меньше вероятность возникновения TLWY конкретно для этого компьютера.
2 часа назад, BrightYC сказал:Ибо дефолтная сейчас заставка MineOS лагодромит в разы больше, чем если какой-то микроконтроллер будет дёргать фс раз в полторы секунды.
MineOS кроме прочих несёт ещё и эстетическую функцию в "мирное" время. И аварийное отключение компа с MineOS во время лагов меня не огорчит. Но лагомерки в наших watchdog'ах, должны погаснуть в последнюю очередь.
6 часов назад, BrightYC сказал:Проблема в том, что os.time, что computer.uptime возвращает майновское время. Во время низкого тпс'а тикать начнёт медленнее - соответственно computer.uptime при стабильных 20 тиках в секунду и 10-15 тпс будет одинаков. Нужно сравнивать реальное время, только так можно определить тпс.
Это не проблема, если отказаться от измерения именно TPS. Более того, как верно заметил @Doob, тикрейт может быть штатно изменён модами.
Да, метод computer.uptime всегда показывает тики, хотя и представляет их в виде секунд. Фокус же в том, что выполнение одного и того же кода может занимать разное количество тиков в зависимости от лагов сервера. И для лагомерки я предлагаю эксплуатировать именно эту особенность.
-
1
-
-
В 20.11.2019 в 21:23, BrightYC сказал:Моё мнение - вырубать реактор при ТПС ниже допустимого.
Я сейчас прогулялся по морозцу и свежим мозжечком вот что надумал. Ты прав. Пытаться во что бы то ни стало включить комп, управляющий реактором, сейчас является плохой идеей. Идя по этому пути, готовые схемы микроконтроля реакторов я ещё долго не выложу.
Как я вижу схему аварийного включения сейчас:
- Есть компьютер или микроконтроллер, управляющий реактором. Он выполняет свою основную задачу, заодно анализируя её выполнимость в текущих условиях. Это несложно. Если расчёты указывают на невозможность решения, комп пытается более-менее управляемо остановить процесс (в зависимости от использованной схемы) и переходит в режим лагомерки. Когда ситуация нормализуется, программа возобновит управление реактором. Если, конечно, не выключится сам комп.
- Рядом с основным компьютером стоит микроконтроллер, который в режиме ожидания отслеживает статус соседа. Если тот погас, то микроконтроллер включает лагомерку, а когда лаги стихнут, с некоторой периодичностью пытается разбудить комп. Этот микроконтроллер наибольшую часть работы будет тратить на сон. Но если и он погаснет, то лишь во время чего-то действительно страшного и опасного.
Тут главное, чтобы сами лагомерки создавали минимальную нагрузку на сервер.
Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода?
for i=1,3 do computer.pullSignal(0) end computer.pullSignal(0.01) t = computer.uptime()
Такой код по идее должен жрать очень мало ресурсов.
-
13 минуты назад, Doob сказал:Вообще-то сетевая карта генерирует сигналы. И любой компонент будет генерировать, но управлять им не получится.
Да, оказалось, генерирует. Но только во включенном компьютере. А красная карта генерирует событие даже в выключенном, без процессора и памяти.
21 минуту назад, Doob сказал:Логика в том, что это самый простой способ разграничить видимость. Если усложнять, то придется, при добавлении нового компонента, писать для него кучу исключений. Что неизбежно будет добавлять багов.
Теперь понятно. Логика в том, что такова механика на данный момент. И уже не так важно, для каких компонентов событие генерируется только во включенном состоянии содержащего их корпуса, а для каких даже в выключенном. Просто надо быть готовым к тому, что может прийти сообщение от компонента с другого компа в той же сети.
25 минут назад, Doob сказал:А с монитором все очевидно, он не сохраняет состояние после перезагрузки. Раньше вообще, апдейт блоков не работал в некоторых способах загрузки чанка, поэтому схемы на редстоуне приходилось постоянно пинать, чтобы прошел апдейт.
С глюками обновления понятно. Но отключение и включение монитора красным сигналом разве является фичей?
Оказалось, является. Нигде не нашёл упоминания об этом в документации, но помог код tileentity/Screen.scala:
override protected def onRedstoneInputChanged(args: RedstoneChangedEventArgs) { ... origin.buffer.setPowerState(!origin.buffer.getPowerState) -
А что это? Баг или фича?
Ставим на монитор кнопку.
Нажимаем кнопку, монитор гаснет.
Нажимаем ещё раз, монитор снова показывает картинку.
Включать картинку можно не только нажатием кнопки, а также выходом из игры и повторным входом.
-
1 час назад, Doob сказал:Вообще, это логично. В старых версиях тоже должно работать.
Если компонент находится в другом корпусе, у него только отключается видимость, а функционал остается. Т. е. компонент в одну сторону имеет доступ, а к нему доступа нет.
Что-то при такой логике вопросов больше чем ответов.
Да, функционал остаётся. Но разве он должен быть доступен для другого компьютера?
Тогда, может, и сетевая карта тоже должна генерировать события в другом компьютере? Но не генерирует.
И почему доступно событие от компонента без доступности самого компонента?
-
Я намеренно избегаю применения других модов в этой теме, чтобы не уходить в нюансы их использования. Почти всегда есть мод, который решает ту или иную задачу лучше другого, и, погружаясь в модоведенье мы рискуем надолго застрять в нём. Если существует решение задачи, позволяющее обойтись без дополнительных модов, то я предпочиту исследовать именно его. Моды же позволят улучшить это решение в зависимости от предпочтений игрока или администратора сервера.
7 часов назад, whiskas сказал:На грег тече крутые реакторы, там новые виды стержней которые больше дают больше греются и тд, новые компоненты которые больше остужают но жрут енергию. Можна творить чудеса
Насколько я помню, в GT наиболее существенным нововведением для реакторов IC2 является охлаждение охлаждающих капсул в холодильнике. А новые стержни просто имеют другие соотношения выработки энергии и тепла при сохранении общей механики. Поэтому микроконтроль сохранит свою актуальность и для GT тоже, позволяя творить новые чудеса на новом поле чудес.
2 часа назад, Doob сказал:Не понял, в чем проблема, плавятся только блоки индастриала и ванильные.
Можно инверторы и репитеры из других модов поставить и все прекрасно контролируется.
Нет проблемы, но есть задача. Существуют решения и без модов, просто их поиск более сложен. Этим я и занимаюсь в этой теме.
-
20 минут назад, NEO сказал:Предлагаю написать продвинутый симулятор реактора.
Мне кажется, это не поможет. Все обсуждённые здесь экстремальные схемы можно подтвердить или опровергнуть расчётами, без симуляции. Главная проблема этих схем в другом. Тут на первое место выходит время обработки операций компьютером даже с хорошим TPS. При снижении TPS возникает заметная рассинхронизация реакторов и компьютеров. Но для некоторых схем даже рассинхронизация не критична.
Тут нужен симулятор не реактора, а всего Майнарафта с модами.
18 минут назад, NEO сказал:Так я не буду писать, а вы.
По крайней мере, не для текущей задачи. А так да, почему бы и нет.
-
7 минут назад, BrightYC сказал:Моё мнение - вырубать реактор при ТПС ниже допустимого. Нашёл старенький код, позволяющий определить кол-во тиков в секунду.
Да, код немного кривоват, склонен к завышению TPS, имеет неконтролируемое дрожание, но идея понятна. Всё же это не мой путь на данном этапе. Сейчас я буду пытаться держать реакторы включенными до последнего и, по возможности, улучшать алгоритмы поддержания их живучести. А момент отключения я буду выбирать, скорее всего, измерением не TPS сервера, а запаса времени между действиями, необходимыми для управления реактором.
-
2 минуты назад, BrightYC сказал:А зачем его включать? Вручную 1 раз включил, если погас - значит что-то плохое происходит. Пусть разбирается тот, кто монтировал реактор. Нет смысла предугадывать лаги майна, лучше обесточить 1 реактор, чем получить дырку вместо базы.
Собственно, такую экстремальную цель я и поставил: обеспечить устойчивость управления даже в случае лагов сервера. Реактор должен продолжать работу не смотря ни на что. Насколько мне это удастся в той или иной схеме, это другой вопрос. Часть из обсуждённых схем не будет стабильной даже при 20 TPS. Другая часть сможет работать даже при сильных лагах. Вот, я и хочу выяснить предел прочности этих схем. Но для начала надо обеспечить бесперебойную работу управляющего компьютера.
-
Только что, BrightYC сказал:Микроконтроллер с редстоуном и платой беспроводной сети. Сгорел микроконтроллер или кончился заряд - реактор остывает. И редстоун-факела не нужны.
Да, микроконтроллер является хорошим вариантом. И, кстати, он у меня ни разу не сгорал. Но при использовании беспроводной сети возникает вопрос: кто включит погасший микроконтроллер? Они с компьютером будут постоянно обмениваться пакетами? Но это повысит нагрузку на сервер.
-
17 минут назад, BrightYC сказал:1. Редстоун-плата подаёт красный камень, инвертируем его красным камнем. Если компьютер выключился - подаётся редстоун-сигнал на компьютер. Так же сделать резервное питание компьютеру на случай отключения.
2. Записать программу на EEPROM.
3. Ядерный реактор отключится, когда компьютер выключится. Он же от редстоун-сигнала работает.
4. Это последнее что должно заботить. Пара факелов и 1 компьютер не сильно нагрузит сервер.
Да, эта схема будет работать в случае холодного реактора. Но реакторы бывают и горячими тоже. Учитывая, что реактор управляется с помощью красной платы, то компьютер оказывается в горячей зоне. В лучшем случае компьютер имеет одну сторону, смежную с холодным блоком. А в твоей схеме с факелом нужны минимум две такие стороны. Поэтому часть обвязки редстоуном оказывается в горячей зоне, рано или поздно сгорает, и компьютер теряет возможность автоматического включения. Этот способ не работает с горячими реакторами.
-
Я, кажется, нашёл мелкий баг в 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: Компы не обязательно ставить в смежных блоках. Соединив их кабелем, получаем тот же эффект.
-
2
-
-
Прошёл месяц, но наши ядерщики не рвутся сообщать о результатах своих экспериментов. И в связи с этим у меня возникают вопросы. Я предложил слишком сложный эксперимент? Или без игрового сервера нет никакой мотивации погружаться в Майн? Или тема реакторов уже неинтересна? Или каждый надеется на то, что эксперимент проведёт кто-то другой, или же я наконец сдамся и продолжу вести диалог сам с собой?
Ну и ладно, я не спешу. Я продолжаю прыгать от темы к теме, и в процессе написания вырисовывается приоритет их публикации. Кажется, в первую очередь следует подготовиться к худшему сценарию: управляющий компьютер отключился, активная зона реактора расплавилась, радиация пошла в атмосферу, местные жители превратились в зомби, которые теперь заняты разрушением остатков АЭС. Этого никак нельзя допустить.
Предлагаю всем неравнодушным ядерщикам подумать над следующими вопросами:
- Как не допустить отключения управляющего компьютера?
- Как в кратчайшие сроки включить погасший управляющий компьютер?
- Как не допустить расплавления компонентов реактора или взрыва, пока компьютер выключен, а реактор предоставлен самому себе?
- Как всё это сделать с минимальной нагрузкой на сервер?
Публикация возникших соображений приветствуется.
Что делает Item Selector мода OpenPeripherals?
в Компоненты
Опубликовано:
Селектор выдаёт на компьютер сигналы при нажатии его кнопок. Вид кнопок определяет сам игрок, размещая нужные ему блоки в интерфейсе селектора.
Быстрый старт:
Внимание! Сигналы селектора имеют нестандартный формат вида "slot_click", slot_number, address. Также была тема о том, что событие выдаёт адрес не самого селектора, а чего-то другого. Это надо проверять.