Вся активность
Этот поток обновляется автоматически
- Последний час
-
Как я могу использовать команду print() в программе для EEPROM???
- Сегодня
-
Да, делает. Мой вопрос оказался не по адресу. Тут кто как понял вопрос автора, тот так на него и ответил. А вопрос автора оказался неоднозначным. Потому как math.random возвращает либо целое число, которое изначально не требует дополнительного округления, либо возвращает вещественное число, отбросив дробную часть которого, мы всегда будем получать ноль. А в какой версии Lua так происходит?
-
Разве math.floor() не делает из 4.0 - 4?
-
Можно. Но для какой цели?
-
math.random() генерирует случайное вещественное число в диапазоне[0 до 1] math.random(upper) генерирует целое число в диапазоне [1..upper]; math.random(lower, upper) генерирует целое число в диапазоне [lower..upper].
-
proga.lua lol kek local args = {...} print(args[1]) print(args[2]) > lol > kek
- 1 ответ
-
- 1
-
-
Как принимать аргументы? Типо "SUPERPROG.lua lol" и это "lol" заточить в переменную И если несколько аргументов "SUPERPROG.lua lol kek chebyrek" то как каждое это слово разделить по разным переменным? Или в массив
- 1 ответ
-
- 1
-
-
Как получить рандомное число? Просто math.random() в конце ещё .0 добавляет. Нам не нужно дробное число.
-
Штурман, у нас разрыв свиньи! Придётся катапультироваться.
-
В сказке: слетел сокол с дуба, ударился оземь и обернулся добрым молодцем. В майне: слетел свин с дрона, ударился оземь и обернулся добрым холодцом.
-
Не знаю как в новых версиях, но раньше было так - пока сущность в воздухе, у нее накапливается урон от падения в какой-то аккумулятор. Например, можно каким-нибудь образом парить несколько секунд на высоте в один блок и приземлившись, получить повреждения, несовместимые с жизнью. Игра любой отрыв от поверхности, считает за падение, моды со всякими крыльями это обходят. Для полетов на свинолете, надо в точке назначения иметь озеро с водой 5x5 блоков, тогда можно безопасно летать.
-
Если резко опускаться.У меня свинья висела на одном блоке над землёй, я её опустил ещё и она не выдержала.
-
Если резко опускаться.У меня свинья висела на одном блоке над землёй, я её опустил ещё и она не выдержала.
-
Как "так"? Беспроводной платой первого уровня?
-
Да, при штатной работе программы достаточно соотнести тики реактора с тиками, которые смог обработать компьютер. TPS как таковой вообще не обязательно знать. Но когда реактор остановлен, нужен инструмент косвенной оценки лагов сервера, без реактора. Чем меньше ресурсов потребляет комп, чем чаще он находится в простое, тем ниже вероятность, что он отключится по TLWY. Правда, на практике может оказаться, что наш код выполнил уступку времени на несколько тиков, передав управление методу компонента, и поэтому формально наш компьютер простаивает. При этом сам майн, обрабатывая вызванный кодом метод, может лагать. Это предстоит выяснить экспериментально. Но в целом это правило подтверждается: чем больше времени код тратит на вычисления и чем реже обращается к периферии, тем меньше его вклад в лаги, и тем меньше вероятность возникновения TLWY конкретно для этого компьютера. MineOS кроме прочих несёт ещё и эстетическую функцию в "мирное" время. И аварийное отключение компа с MineOS во время лагов меня не огорчит. Но лагомерки в наших watchdog'ах, должны погаснуть в последнюю очередь. Это не проблема, если отказаться от измерения именно TPS. Более того, как верно заметил @Doob, тикрейт может быть штатно изменён модами. Да, метод computer.uptime всегда показывает тики, хотя и представляет их в виде секунд. Фокус же в том, что выполнение одного и того же кода может занимать разное количество тиков в зависимости от лагов сервера. И для лагомерки я предлагаю эксплуатировать именно эту особенность.
-
Только так свинью очень легко ушатать
-
Зачем измерять тпс майна, если можно спокойно наблюдать прохождение тиков в самом реакторе? К тому же, при лаге, реактор не будет сваливать тики в кучу. Он их может пропускать, но в такой ситуации, сервер уже лежит и не шевелится. Искусственное изменение тпс другими модами и плагинами легко отследить - изменение тиков реактора на >10%
-
Мне непонятно зачем гнаться за "должен жрать очень мало ресурсов". Ибо дефолтная сейчас заставка MineOS лагодромит в разы больше, чем если какой-то микроконтроллер будет дёргать фс раз в полторы секунды.
-
Проблема в том, что os.time, что computer.uptime возвращает майновское время. Во время низкого тпс'а тикать начнёт медленнее - соответственно computer.uptime при стабильных 20 тиках в секунду и 10-15 тпс будет одинаков. Нужно сравнивать реальное время, только так можно определить тпс.
- Вчера
-
Я сейчас прогулялся по морозцу и свежим мозжечком вот что надумал. Ты прав. Пытаться во что бы то ни стало включить комп, управляющий реактором, сейчас является плохой идеей. Идя по этому пути, готовые схемы микроконтроля реакторов я ещё долго не выложу. Как я вижу схему аварийного включения сейчас: Есть компьютер или микроконтроллер, управляющий реактором. Он выполняет свою основную задачу, заодно анализируя её выполнимость в текущих условиях. Это несложно. Если расчёты указывают на невозможность решения, комп пытается более-менее управляемо остановить процесс (в зависимости от использованной схемы) и переходит в режим лагомерки. Когда ситуация нормализуется, программа возобновит управление реактором. Если, конечно, не выключится сам комп. Рядом с основным компьютером стоит микроконтроллер, который в режиме ожидания отслеживает статус соседа. Если тот погас, то микроконтроллер включает лагомерку, а когда лаги стихнут, с некоторой периодичностью пытается разбудить комп. Этот микроконтроллер наибольшую часть работы будет тратить на сон. Но если и он погаснет, то лишь во время чего-то действительно страшного и опасного. Тут главное, чтобы сами лагомерки создавали минимальную нагрузку на сервер. Как вам идея в качестве лагомерки использовать замеры computer.uptime() при циклическом выполнении этого кода? for i=1,3 do computer.pullSignal(0) end computer.pullSignal(0.01) t = computer.uptime() Такой код по идее должен жрать очень мало ресурсов.
-
всё так, но не совсем так. Взгляни на это под другим углом. К примеру, для тебя и меня засушенная муха на подоконнике, это просто муха, а для какого-то энтомолога это целый кладезь знаний и потенциальный объект пристального изучения под микроскопом. Ему интересно возиться с этой мухой. Он видит в ней неисчерпаемый источник знаний и огромный интерес. А также не забывай про новых игроков 2010+ года рождения. Это, например, тебе или мне майновский индастриал реактор надоел давным давно, а эти игроки потенциально только открывают мир майнкрафта и индастриала, и для них там всё в диковинку
-
8urton изменил свою фотографию
-
Ну с сигналами логика строгая. Редстоун карта работает всегда, но управлять ей может только включенный комп. Сетевая карта не генерирует сигналы, пока не открыт порт. Если комп выключен, то порты закрыты. Если комп выключен и установлено wake-up сообщение, то никаких сигналов не посылается, кроме внутреннего на корпус. Это при получении wake-up -
Прикольно -
Да, оказалось, генерирует. Но только во включенном компьютере. А красная карта генерирует событие даже в выключенном, без процессора и памяти. Теперь понятно. Логика в том, что такова механика на данный момент. И уже не так важно, для каких компонентов событие генерируется только во включенном состоянии содержащего их корпуса, а для каких даже в выключенном. Просто надо быть готовым к тому, что может прийти сообщение от компонента с другого компа в той же сети. С глюками обновления понятно. Но отключение и включение монитора красным сигналом разве является фичей? Оказалось, является. Нигде не нашёл упоминания об этом в документации, но помог код tileentity/Screen.scala: override protected def onRedstoneInputChanged(args: RedstoneChangedEventArgs) { ... origin.buffer.setPowerState(!origin.buffer.getPowerState)
