Лидеры

Если OC положил сервер, то кк безлимитной озу и халявным крафтом убьет сервер и одним компьютером...

Затравочный пост о лагомерках и лагодромах Выполняя обещание, данное в других темах, привожу список известных мне лагомерок без их подробного анализа: os.clock() растёт быстрее при нехватке вычислительных ресурсов сервера. Предоставляет единственно верный способ оценить шансы приближения TLWY. Но значения os.clock() относительны и зависят от множества факторов. computer.pullSignal(0) в норме выполняется около 4 раз за тик, но во время лагов количество вызовов за тик уменьшается. Вносит минимальный вклад в лаги сервера, т. к. почти всё время тратится на сон. Оно ненулевое, как может показаться. Оценка соотношения роста computer.uptime() и реального времени сервера позволяет вычислить значение TPS. Но падение TPS в чанке не всегда указывает на лаги сервера, так могут проявлять себя штатные механики Майнкрафта и модов. Обращения к периферии в норме требуют для своего выполнения одного тика. Время, затраченное сверх одного тика, сигнализирует о лагах сервера и о возможном устаревании данных, полученных компами от периферии. Во всех лагомерках заложено фундаментальное противоречие. Информацию о лагах требуется получать оперативно, в реальном времени, каждый тик. Но интенсивно работающая лагомерка вносит собственный вклад в лаги сервера. По этой причине я призываю отказаться от интенсивных замеров лагов на игровых серверах. Например, если критичный к лагам код планируется выполнить через минуту, то почти всё это время имеет смысл потратить на сон, а интенсивность измерений наращивать по мере приближения к критическому моменту. Нет смысла измерять то, что утратит свою актуальность к моменту использования. Кроме того, любой интенсивно работающий код имеет ненулевой шанс аварийно завершиться с ошибкой too long without yielding. Этой ошибки на 100% может избежать лишь код, 100% времени проводящий в ожидании. Во всех остальных случаях возникновение TLWY определяется лишь вероятностью. Поэтому, скрипт должен дольше спать и меньше работать. Чем больший вклад вносит скрипт в лаги сервера, тем с большей вероятностью он аварийно завершится по TLWY. Оборачивание кода в pcall не даёт 100% гарантии избежать аварийного завершения по TLWY. Шансы зависят не только от интенсивности вычислений в самом коде, но и от перегруженности сервера. На стабильном сервере pcall почти всегда спасает код от завершения по TLWY. Но на сильно лагающем сервере pcall почти всегда не успевает. В этом посте я не раскрыл всех деталей использования перечисленных способов обнаружения лагов. Также, возможно, я забыл упомянуть другие достойные способы или даже не знал их. Поэтому задавайте вопросы, предлагайте свои решения, проводите собственные исследования, не дожидаясь моих. По результатам обсуждения я попробую собрать подробный гайд о лагомерках и лагодромах.

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

Про лагомерки и лагодромы ответил здесь

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

Привет всем! Когда я искал библиотеку для создания изображений, отрисовки и т.д. я не нашёл ни одной хорошей библиотеки. Поэтому я написал свою библиотеку, tifAPI! Вам может показаться, что это уже существующее расширение .tif(.tiff), но .tiff расшифровывается как "Tagged Image File Format", а мой - "Text Image Format". А теперь вопросы и ответы (Только на ComputerCraft) Легко, пишем команду pastebin get EnZksdhv installerTIFAPI после скачивания файла пишем следующую команду installerTIFAPI <Папка, в которой будет папка с библиотекой> . Скачивание файлов библиотеки закончиться, когда очиститься экран, и будет надпись "tifAPI has been installed!". Вот Это цвета от 1 до 9 и a, b, c, d, e, f А вот и шпаргалка цветов --[[ a - Номера цветов(colors) b - Сами цвета c - HEX цвет ------------------- a b c 1 0 #F0F0F0 2 1 #F2B233 4 2 #E57FD8 8 3 #99B2F2 16 4 #DEDE6C 32 5 #7FCC19 64 6 #F2B2CC 128 7 #4C4C4C 256 8 #999999 512 9 #4C99B2 1024 a #B266E5 2048 b #3366CC 4096 c #7F664C 8192 d #57A64E 16384 e #CC4C4C 32768 f #191919 ]]-- TifImage - таблица, в которой храниться изображение Да будут.