eu_tomat

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

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

Это очень странно выглядит. А если снести этот улей и построить заново, не помогает?

Что значит другие ульи? Всё в порядке с другими большими ульями, или с ульями другого типа?

Что значит никто? Автор давно не только заметил косяк, но и описал его. А описанный в документации баг становится фичей. Может, таки было задумано.

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

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

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

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

Так вроде бы @Doob давал ссылку на мою тему. Тема немного о другом, а именно о вычислении константы шума, но там я как раз и рассматривал дискретную природу шума геосканера. Знание константы шума и набора возможных плотностей блоков позволяет вычленить из общего сигнала геосканера как шумовую составляющую, так и плотность блока. А так, да: урок мутноватый, его поймут только подготовленные умы. Я стараюсь писать ясно и просто, но не продолжил серию. Зато взялся @Doob. Если он не захочет переписать этот урок, эту эстафету может принять кто-то другой, чтобы описать методику понятным языком. Сам я надеюсь вернуться к этой теме, но не в ближайшее время.

Ошибка сообщает о попытке вызвать неопределённую функцию. Как определена функция redpulse?

Мысли об измерителях TPS: • Измеритель TPS, даже хорошо написанный, в среднем будет выдавать значение чуть выше 20TPS на слабо нагруженном сервере, не смотря на плановое значение в 20TPS. Моментальное значение за счёт микролагов может отличаться сильнее, уходя как в плюс, так и в минус. • На перегруженных серверах не только снижается средние значение TPS, но и возрастает разброс моментальных значений. Поэтому приходится применять более сильное усреднение. • Как написать правильный TPS-метр, это тема для отдельного гайда. Скажу больше: измеритель TPS является настолько тонким инструментом, что всю программу желательно строить вокруг него. Интеграция же в существующую программу требует дополнительной модификации самого измерителя. • Измерение TPS для пересчёта счётчика энергии вряд ли оправдано, если частоту тиков не планируется изменять какими-либо модами. Обычно достаточно исходить из предположения, что TPS=20. Это позволит легко сопоставлять значения, полученные компьютером, со значениями в интерфейсах механизмов. Комментарии к этой реализации счётчика и формулировке вопроса: • Для оценки правильности данных, выводимых компьютером, следует сравнивать значение, выдаваемое им, со значением в интерфейсе измерителя средней мощности, с которого снимаются показания, а не с молекулярного преобразователя. Уменьшение звеньев в логической цепи снижает шанс ошибиться в конечном выводе. • Усреднение реализовано некорректно. Первые 9 измерений выдадут сильно заниженный результат за счёт нулей в массиве. • Для подобных измерений я рекомендую вычислять не среднее арифметическое, а среднее экспоненциальное. Такое решение позволит уменьшить как требуемый объём памяти, так и вычислительную нагрузку.

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

Оказалось, что web-версия GitHub также имеет ограничение частоты запросов. Правда, OpenComputers настолько сильно ограничивает скорость приёма данных, что ограничения самого GitHub перестают играть реальную роль. Я обнаружил это случайно во время поиска по двум ключевым словам в репозитории. Одно ключевое слово я вводил в поисковой запрос на странице репозитория, а другое слово искал на странице средствами браузера. Если слово на странице не обнаруживалось, я быстро пролистывал страницу и выбирал следующую. На пропуск каждой бесполезной страницы уходит секунды две времени. Если второе слово на странице присутствует, то времени на анализ страницы уходит больше. Примерно на 15-ой странице я вместо страницы с результатами поиска получил следующий текст: Если коротко: GitHub обнаружил злоупотребление и предлагает мне замедлиться. Фраза же "Whoa there!" вообще пытается намекнуть на мою неадекватность.

Я говорил именно про объявление локальной переменной внутри цикла, это чисто косметический эффект. Если мы хотим избавиться от индексирования таблицы, переменная создаётся в любом случае – явным образом или нет. Да, я понял. Мне показался слишком категоричным призыв отказаться от использования итератора ipairs. Но сейчас твоя позиция мне полностью понятна.

Не всё так плохо. Конечно, в синтетических тестах с пустым циклом разница получается значительная. В реальных же циклах разница не столь велика, потому что вклад ipairs в общую нагрузку снижается на фоне вычислений внутри цикла. А циклы-то обычно не пустые. При этом использование ipairs позволяет писать более читаемый код, позволяя отказаться как от использования индексов, так и от объявления локальной переменной внутри цикла. Ценой такого решения будет снижение быстродействия, но оно не всегда критично, а читаемость кода может оказаться важнее. Как найти оптимум, это отдельный и сложный вопрос. Пожалуй, хорошей привычкой будет писать обычные циклы for i=1,#tbl, и если код кажется трудно читаемым, хорошенько подумав о последствиях, применять for i,v in ipairs(tbl).

Да, дело именно в этом. Вместо else нужно было писать elseif not ply1.online and not ply2.online then, а также поменять знак при сравнении offline_time.

А если отказаться от скачивания web-версии файла и разбирать сразу ссылку, как говорилось здесь: То время сократится до 90-100 секунд. А если web-версию использовать лишь для подстраховки при отказе обслуживания API, то время сократится ещё сильнее. @hohserg Мы выше разбирали вариант с API, но есть трудность:

Кстати, да. С утра мне это тоже показалось бессмысленным. Нам же не обязательно скачивать и разбирать web-страницу файла. Достаточно разобрать ссылку! И если обнаружена ссылка на файл, то можно сразу скачивать её raw-версию: https://github.com/{AUTHOR}/{REPO}/tree/{BRANCH}/{PATH} https://github.com/{AUTHOR}/{REPO}/blob/{BRANCH}/{PATH}/{NAME} https://raw.githubusercontent.com/{AUTHOR}/{REPO}/{BRANCH}/{PATH}/{NAME} Строки ссылок короткие, поэтому тут можно смело применять шаблоны, не опасаясь TLWY.

Сам разбор работает очень быстро, если использовать find без шаблонов. Медленно работает получение страницы, тратя один такт времени на каждый кусок. А кусков много, Web-версия гораздо объёмнее, нежели API. Очень странный подход у владельца гитхаба – ограничивать быстрый и компактный вариант, не ограничивая медленный. С этим я согласен. Но инсталляция требуется один раз, на эксплуатации программы это никак не скажется. Зато программист может не тратить своё внимание на обновление установщика при каждом изменении. Но я не настаиваю на этом решении. Я могу лишь предлагать. Почему же бессмысленно? Фраза id="raw-url" встречается на странице лишь один раз или не встречается вовсе.

Тогда я не вижу другого варианта кроме использования find без шаблонов. Код распухнет строк на 10, но, как ни странно, он работает гораздо быстрее библиотечных функций: local sHead, sTail = 'data-pjax="#repo-content-pjax-container" href="', '">' local pTail, pHead = 1 while true do pHead = html:find( sHead, pTail, true ) if not pHead then break end pTail = html:find( sTail, pHead+#sHead, true ) if not pTail then break end print( html:sub(pHead+#sHead,pTail-1) ) pTail = pTail+#sTail end На моём компьютере этот код можно выполнить примерно 1-1.5 тысячи раз до наступления TLWY, запас огромный.

@AlexCatze Предлагаю вместо этой конструкции: html:gsub( 'data%-pjax="#repo%-content%-pjax%-container" href="(.-)">', function(s)os.sleep(0)print(s)end ) использовать такую: for s in html:gmatch( 'data%-pjax="#repo%-content%-pjax%-container" href="(.-)">')do os.sleep(0)print(s)end Работает раза в два быстрее. Web-версия оцелота успешно отработала этот код.

У меня аналогичный опыт. Но это очень странно. Веб-версия оцелота отработала до истечения таймаута на два порядка больше итераций пустого цикла, чем в игре на моём компьютере. Зато при обработке gsub почему-то валится в TLWY. Может, Ocelot кривоват?

@AlexCatze Похоже, на этом железе и на таком объёме данных gsub не успевает выполнить даже одну итерацию за отпущенный ему таймаут. Жаль. Придётся использовать более сложные способа разбора.

Да, верно. А хоть что-нибудь успевает распарситься?