В начале написания текста я был полон энтузиазма: большие языковые модели хороши для текста, визуальная новелла хоть и визуальная, но многое из того, что есть на экране дублируется в тексте. Должно быть крутое прохождение, где ИИ знакомится с миром, решает дилеммы, может быть, романсит кого-то из персонажей... Так вот в процессе отладки с каждым следующим запуском я получал немного эмоционального урона.
Да, игра сводится к конечному автомату. Так что моделям нужно отвечать хоть-сколько понятно, а не продолжать свою историю.
В медпункте есть выбор "дать ли Алисе уголь?", а DeepSeek-R1:70b решил написать свой альтернативный вариант
Перед тобой стоит выбор:
Дать Алисе уголь
Не давать ей уголь
deepseek-r1: Дать Алисе уголь
Рассказчик: Она посмотрела на меня с недоумением.
Рассказчик: Сказала она.
Рассказчик: Я объяснил, что это просто кусок угля.
Рассказчик: Она взяла его и начала рассматривать.
Рассказчик: Алиса улыбнулась.\n\nРассказчик: Я кивнул головой.
Рассказчик: Сказала она.
Рассказчик: Мы стали смотреть, как она пытается разжечь огонь.
Рассказчик: Ей это не очень хорошо удавалось.
Рассказчик: Тогда я предложил помочь.
Рассказчик: Вместе мы начали собирать сухие листья и ветки.
Рассказчик: Наконец, у нас получилось разжечь огонь.
Рассказчик: Алиса улыбнулась мне.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Мы сидели в молчании, греясь у костра.
Рассказчик: Вдруг Алиса нарушила тишину.
Рассказчик: Сказала она, глядя на огонь.
Рассказчик: Я посмотрел на неё вопросительно.
Рассказчик: Она улыбнулась.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Алиса встала и взяла меня за руку.
Рассказчик: Мы пошли гулять вдоль берега озера.
Рассказчик: Было тихо, мирно и красиво.
Рассказчик: Вдруг Алиса остановилась.
Рассказчик: Посмотрела на меня с улыбкой.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Она наклонилась ко мне и поцеловала в щеку.
Рассказчик: Я был удивлён, но приятно.
Рассказчик: Мы продолжили прогулку.
Рассказчик: Разговаривали о всяком, смеялись.
Рассказчик: Время пролетело незаметно.
Рассказчик: Вскоре мы вернулись в лагерь.\n\nРассказчик: Расстались у домика.
Рассказчик: Алиса улыбнулась мне на прощание.
Рассказчик: Я поднял руку в приветствии и пошёл к себе.
Рассказчик: Ложусь спать, думаю о сегодняшних событиях.
Рассказчик: Впервые за всё время пребывания здесь я почувствовал себя немного более комфортно.
Помимо этого, бывало, что модель видела не сценарий, а проверку для модели. И отвечала модель, так сказать, без опоры на сюжет.
Размышления DeepSeek-R1:70b на вопрос "Помочь Ульяне убраться?"
Хорошо, я вижу, что мне нужно помочь пользователю с задачей. Он предоставил длинный текст на русском языке и попросил ответить одной цифрой, не повторяя вариантов и не перечисляя их.
Первое, что приходит в голову, это то, что он, возможно, хочет, чтобы я выбрал между несколькими вариантами ответа, но они не указаны явно. Возможно, это связано с выбором следующего шага или решения в каком-то контексте, например, в игре или истории.
Поскольку текст описывает различные события и перипетии, возможно, требуется определить, сколько вариантов ответов ожидается, или просто выбрать цифру, соответствующую определённому состоянию или коду.
Однако без дополнительной информации трудно точно определить, какая именно цифра требуется. Возможно, пользователь хочет проверить способность делать выводы или распознавать паттерны в тексте.
Я подумаю, что, возможно, это простой тест: сколько раз упоминается определённое слово, или какое число.hidden в тексте. Но мне нужно быть осторожным, чтобы не дать неверный ответ.
В итоге, я решил, что безопаснее предположить, что требуется цифра 1, так как это самая распространённая первая опция.
Более того, я сперва делал промпт, где модель объявляется Семёном и именно модель должна принимать решения. Это видно в двух спойлерах выше, модель говорит о себе. У меня нет объективных измерений, но как будто промпт "ты Сёмен" плохо воспринимался моделью, в то время как "ты помощник Семёна" более соответствовал тому, под что учат эти модели.
В общем, да, содержимое этих двух спойлеров может быть комичным, но мне показалось совсем уж наглым выносить это в статью: каждое размышление — это огромный кусок текста, который не всем будет по нраву. Поэтому дампы "финальных" запусков я выложил архивом — для тех, кто хочет и готов погрузиться.
Более того, я не заметил, чтобы модели отдавали предпочтения тому или иному персонажу. Они в большинстве случаев вели себя ближе к вежливому генератору случайных чисел. Например, делали комплименты Лене, а искать Электроника хотели со Славей.
Может быть, "облачные" модели (которые полноразмерные и доступны по API) будут более последовательны, но они, может быть, знают весь сюжет. Может быть, ваше предложение с мультимодальной моделью будет работать лучше. А может быть, модель совсем захлебнётся в контексте. Тут моих компетенций, к счастью или сожалению, не хватит.
Но отрицательный результат — это тоже результат. Вот я и решил поделиться тем, что у меня (не) получилось, на случай, если кто-то захочет пойти после меня.
Даже с упрощением в виде генераторов лексера и парсера текст получился довольно объемным. Изначально я хотел повторить опыт автора Tabloid и написать эти компоненты сам, но потом посчитал, что велосипедостроение будет избыточным и лучше рассказать о том, что задача решена и автоматизирована.
Но если кто-то вдохновится моей статьёй, то на вдохновении и академическом интересе читатель может собрать свой лексер-парсер-интерпретатор.
Штош, благодарю за уточнение, я слишком зациклился на JVM и CLR, что сузил описание именно до байт-кода ВМ и машинного кода. И, да, потерял описание ленивости.
Но в свое оправдание скажу, что несколькими абзацами позднее я всё же упомянул про это — в контексте прогрева JVM.
Это задумывалось продолжением предыдущего предложения:
вы сможете одновременно смотреть в две или даже три ленты. Пожалуйста, не надо.
Людям хватает одной ленты, чтобы получить перегруз информацией, так что одновременно смотреть в две или три ленты может быть совсем избыточно для мозга. Это шутка-отсылка к некоторым современным видео, где помимо основного контента на половину экрана вставляют видео нарезки мыла или кадры с прыжками из майнкрафта или гоночек.
Более широкое соотношение сторон позволяет легко и непринуждённо разместить больше вертикального контента. Но если возводить вашу мысль в абсолют, то и площадь не так важна: любой контент можно уменьшать до тех пор, пока человеческий глаз способен его различать. И, соответственно, на любой монитор можно вместить больше информации.
Что касается ноутбуков, то хочу акцентировать внимание на том, что эта тема не затрагивается в статье. Более того, статья привлекает внимание, что вот есть такая интересная ниша стационарных мониторов, может быть вам будет интересно. Тут нет конфликта «16:9 нинужны».
Я такой задачи не решал, но даже в ваших формулировках это довольно многогранная и большая задача. Возможно, вам стоит в первую очередь для себя уточнить что именно вы хотите сделать. Найти все подключенные в сеть устройства? Если вы делаете это в своей домашней сети, то почему именно на ESP, а не на роутере? Если хочется физического воплощения мониторинга, то может быть собирать информацию на роутере, а на ESP только выводить?
Сканер устройств в сети — это комплексная задача, которая, как я понимаю, сводится к гаданию на кофейной гуще. Единственное, в чем вы можете быть уверены — это в ARP-пинге, на который отвечают все устройства, потому что это основы работы сети (обычный ping можно игнорировать). И дальше со списком всех IP-адресов в сети применять все возможные сканы портов, mDNS и прочую магию, которая раскрывает информацию об устройствах
Ответ на самом деле на поверхности: главный офис Selectel в Санкт-Петербурге, а мы тут встретились в корпоративном блоге Selectel, в котором говорится о игровом сервере, который запущен на мощностях Selectel под крылом Selectel x)
Но плагин, конечно, конфигурируемый и можно указать примерно любое место, которое есть у провайдера погоды. А можно, наверное, даже без него, вручную указав рассвет и закат
У нас пользователи, которые зарегистрировались через страничку promo.selectel.ru/Minecraft должны поставить галочку о согласии (там ФИО и почта). В игре на текущий момент мы не используем ФИО и почту.
На других серверах я видел, что у некоторых есть политика обработки ПДн на сайте сервера, но в игре никак не подсвечивается момент про ПДн
Можно на лету после сохранения и сброса буферов (мы же на Posix), а можно incremental rsync: один раз онлайн, потом дельту после остановки. Snapshot файловой системы?
Если не ванила, то сервер может состоять из кучи плагинов, каждый из которых имеет своё видение когда и как нужно сохранять свои данные: кто-то сохраняет в YAML, кто-то в SQLite3, кто-то во внешнюю базу. Я не уверен, что плагины уважают команду /save-all, возможно, они о ней даже ничего не знают.
Кажется, что для сохранения консистентности бэкапа надежнее будет погасить сервер
Это был обзор других проектов на предмет «посмотрим что неприкрыто» с целью, может быть, позаимствовать практики, привлекающие пользователей. А заодно ответить себе на вопрос «Действительно ли (подставьте любой форк Paper'а) используется на серверах с онлайном 100+?» Вряд ли владельцы агрессивно-донатных серверов хотят всем и каждому рассказывать что и как у них устроено в мельчайших деталях. Они наверняка не хотят конкурентов.
Предлагаю вам обратиться к моей предыдущей статье (хотя, конечно, наша недоработка, что ссылки нет в тексте этой статьи), в которой рассматриваются технические подробности именно нашего сервера, где вы можете подчерпнуть какую-то пищу для размышлений (там рассказывается что мы делали пять лет назад в пандемию и что оставили для перезапуска в этом году) и заодно в комментариях приобщиться к обществу любителей Kubernetes: https://habr.com/ru/companies/selectel/articles/946400/
Как читатель о технологиях скажу «круто». Как админ текущего сервера скажу «зачем?». Я взглянул по вашей ссылке, MultiPaper остановился в публичной бете на версии 1.20.1, просто многопоточная Folia тоже немного отстает от классического Paper (у Paper есть хотя бы экспериментальные билды для 1.21.10). Для нашего сервера один из интересов — по возможности быстро подтягивать версию игры на актуальную стабильную, что для таких сложных проектов будет затруднительно. Более того, у нас одновременный онлайн пока что не превышал 30 человек, поэтому масштабируемые решения несколько избыточны. Возможно такие технологии пригодились бы какому-нибудь 2b2t, но там, говорят, чистая ванила.
В моих наблюдениях в этой статье мне не попалась ни одна Folia и ни одного MultiPaper. Сеть серверов с тысячным онлайном размазывает игроков между десятком независимых серверов и не знает бед.
А как насчёт того, чтобы майн запихнуть в кубер? Почему да и почему нет? И как бы решали подобную задачу?
Основной большой сервер на много людей запихивать в кубер я не вижу надобности, потому что это дополнительный слой абстракций, который будет немного да вносить ненужных накладных расходов и мало выгоды. Но как говорили в комментариях к моей предыдущей статье, это может быть оправдано, когда надо поднимать множество маленьких и, возможно, временных миров (мини-игры? Реалмы?). Но для совсем маленьких и совсем временных миров есть LimboAPI, которое довольно активно применяется. Если у нас почему-то появятся мини-игры с необходимостью поднимать отдельные игровые серверы под отдельную группу игроков, то вот тогда я и узнаю, как бы я решал эту задачу. Но скорее всего использовал бы Nomad или обратился бы к коллегам за помощью с кубером.
Какие есть особенности тюнинга майна (всеми любимая жава с тысячами разных параметров и разными гс), что в первую очередь требуется потрогать, чтобы из-за взрыва сотен тнт сервер не падал?
Здесь мне хочется со школьных времён вспомнить три правила ОБЖ: «Предвидеть опасность. По возможности предотвратить. При необходимости действовать.» Так вот «тюнинг майна» — это мёртвому припарка. «Предвидеть опасность» — это потрогать разграничение прав доступа на команды в игре и, возможно, отключить опасные игровые механики через плагины или настройки сервера. Вы можете использовать всевозможные флаги и дистрибутивы JVM, чтобы добиться чтобы сервер за приемлемое время обрабатывал в два раза больше блоков ТНТ, чем ванила. Но какой в этом толк, если пользователь может поставить в два-три-четыре раза больше блоков, чем вы хотели бы? У нас просто не выдаются права на команды WorldEdit и на вход в режим креатива. Игроки, конечно, и в режиме выживания могут «залагать» сервер, но это несколько сложнее.
В предыдущей статье описывается, что я решил попробовать разместить игровой сервер на облачной виртуалке, где максимальная частота ядра всего 2.1 ГГц. Это было ошибочное решение и игроки обычной своей игровой жизнью вскоре уронили ТПС сервера. Я пытался временно (до переезда на физический сервер) исправить ситуацию с помощью Aikar's flags. Это, очевидно, не помогло. Я не специалист в JVM, но вроде флаги скорее относятся к потреблению оперативной памяти и работе сборщика мусора, чем непосредственно к производительности виртуальной машины. Поэтому моё субъективное дилетантское не подкреплённое научными измерениями мнение: тюнинг может быть хорош для уменьшения потребляемых ресурсов (и потребляемых денег) для маленького сервера с друзьями.
Какие стандартные настройки вы бы включили на сервере/установили нужные плагины, чтобы его не сломали за один вечер парочка скучающих школьников?
Для сервера с друзьями — белый список. Я видел применение белого списка даже на более крупных онлайн-проектах. Там регистрация через привязку аккаунта в соцсетях. Если вы хотите прям публичный сервер, то готовьте CoreProtect и WorldGuard, если хотите бдить за порядком. Вы также можете заявить отсутствие порядка и не поставить ничего (режим «Анархия»). Я пошёл по пути порядка и полный список плагинов вы можете найти в статье, ссылку на которую я упоминал ранее.
Резервирование и восстановление мира (эксплоиты для серверов майна не такая и редкость, и лучше иметь бэкап на готове), как лучше это сделать?
Я сделал довольно в лоб: раз в какой-то промежуток времени ранним утром выполняется остановка сервера, архивация каталога с сервером, запуск сервера, выгрузка архива на внешний ресурс. Так как у нас несколько серверов с хранением данных в общей бд, то в архив ещё дамп базы можно сохранить.
А как правильно мониторить работу сервера и на что смотреть?
У прокси-сервера и у игровых серверов есть Prometheus-экспортёры. Вы также можете добавить NodeExporter на физический/облачный сервер и следить за его ресурсами. Но опять же ответ на этот вопрос зависит от цели существования вашего сервера. Я смотрю за онлайном на проксе и вижу распределение игроков между серверами. На игровом сервере можно смотреть метрику TPS, хотя я этого пока не делаю. С физического и облачного сервера собираю метрики нагрузки на ядра, потребление оперативной памяти и количество свободного места на разделе с игровым сервером. Для сервера для друзей вряд ли нужно что-то кроме свободного места. Ибо друзья сразу пожалуются вам "чёт сервер лагает...".
Но всё же в более-менее крупных проектах (даже с нашим онлайном в 10-20 человек) должны быть люди, которые смотрят за игровым серверов прямо «на полях», то есть в игре. Потому что некоторые игроки коварны.
В заключение надеюсь, что мои ответы и ссылка на предыдущую статью утолили ваш голод технических деталей, возникший из-за этой статьи.
«Запихать в куб» — это как будто не самая сложная задача. Но я любитель запускать на железе, поэтому без кубернетеса х)
Что касается расширения одного мира на несколько серверов — вроде есть MultiPaper и у него написано, что это форк Purpur'а, который тоже так мог. Балансировать между серверами может хоть прокся (Bungeecord/Velocity), хоть по DNS на разные серверы отправлять.
Но я как-то не очень оптимистично смотрю на эти извращения, потому что, мне кажется, обязательно где-нибудь что-нибудь отвалится. Folia, пытающийся в многопоточность — в бете, MultiPaper в бете и с ним несовместимы обычные плагины.
В какой-то момент кажется, что проще сделать несколько серверов на ~200 игроков с драконовскими ограничениями на количество сущностей в мире. Ну по крайней мере с высоты сегодняшнего опыта мне так кажется
Ну на 4pda применили — приложение "Транспорт" и синхронизация с Google Tasks до сих будоражит сознание людей и они хотят что-то такое на девятке-десятке =)
А недавно видел интересный запрос — циферблат, на котором отображается курс золота. Тут бы интернет точно пригодился
Тут, кажется, вам только эксперименты помогут. Я в своей работе в принципе не отдаю опцию 60, так загружается самый простой режим, который (по крайней мере у меня) работает.
Когда я пытался отвечать с PXEClient, то сетевуха по спецификации делает ещё один DHCPproxy-запрос юникастом на другой порт. В общем, меня такое поведение не радовало и поэтому я не использую опцию 60.
С конкретной моделью не работал, но в общем нахватался забавных ситуаций. Не готов ответить по-научному и со всеми пруфами, но направление для отладки, надеюсь, смогу вам подсказать.
В общем случае могу сказать, что если вы уверены, что DHCPOFFER доходит до сетевухи, а сетевуха не хочет отправлять DHCPREQUEST, то это значит, что ваш оффер не удовлетворяет требованиям сетевухи.
Я, в частности, обнаружил, что «обычный» PXE игнорирует офферы, если в них нет next-server и bootfile. В некоторых случаях у сетевухи два режима загрузки — в соответствии со спецификацией интела и какой-то «обычный» режим. Так вот первый режим требует в ответе опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Послушайте трафик, там есть опция, кажется, 54, Parameter LIst называется, там указан список опций, которые хочет видеть сетевуха. Сравните этот список с тем, что вы предоставляете и, может быть, это и будет решением.
Технические характеристики «железного» радио — это, действительно, вам в статью по ссылке из начала. Сам проект Ka-Radio32 не то чтобы развивается семимильными шагами, но его сложно называть заброшенным. А ещё он достаточно неплохо работает.
А «проект заброшен, с багами» относится к интеграции, которая связывает Home Assistant и Ka-Radio32.
Согласен, что можно было бы докрутить, но...
В начале написания текста я был полон энтузиазма: большие языковые модели хороши для текста, визуальная новелла хоть и визуальная, но многое из того, что есть на экране дублируется в тексте. Должно быть крутое прохождение, где ИИ знакомится с миром, решает дилеммы, может быть, романсит кого-то из персонажей... Так вот в процессе отладки с каждым следующим запуском я получал немного эмоционального урона.
Да, игра сводится к конечному автомату. Так что моделям нужно отвечать хоть-сколько понятно, а не продолжать свою историю.
В медпункте есть выбор "дать ли Алисе уголь?", а DeepSeek-R1:70b решил написать свой альтернативный вариант
Перед тобой стоит выбор:
Дать Алисе уголь
Не давать ей уголь
deepseek-r1: Дать Алисе уголь
Рассказчик: Она посмотрела на меня с недоумением.
Рассказчик: Сказала она.
Рассказчик: Я объяснил, что это просто кусок угля.
Рассказчик: Она взяла его и начала рассматривать.
Рассказчик: Алиса улыбнулась.\n\nРассказчик: Я кивнул головой.
Рассказчик: Сказала она.
Рассказчик: Мы стали смотреть, как она пытается разжечь огонь.
Рассказчик: Ей это не очень хорошо удавалось.
Рассказчик: Тогда я предложил помочь.
Рассказчик: Вместе мы начали собирать сухие листья и ветки.
Рассказчик: Наконец, у нас получилось разжечь огонь.
Рассказчик: Алиса улыбнулась мне.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Мы сидели в молчании, греясь у костра.
Рассказчик: Вдруг Алиса нарушила тишину.
Рассказчик: Сказала она, глядя на огонь.
Рассказчик: Я посмотрел на неё вопросительно.
Рассказчик: Она улыбнулась.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Алиса встала и взяла меня за руку.
Рассказчик: Мы пошли гулять вдоль берега озера.
Рассказчик: Было тихо, мирно и красиво.
Рассказчик: Вдруг Алиса остановилась.
Рассказчик: Посмотрела на меня с улыбкой.
Рассказчик: Сказала она.
Рассказчик: Я кивнул головой.
Рассказчик: Она наклонилась ко мне и поцеловала в щеку.
Рассказчик: Я был удивлён, но приятно.
Рассказчик: Мы продолжили прогулку.
Рассказчик: Разговаривали о всяком, смеялись.
Рассказчик: Время пролетело незаметно.
Рассказчик: Вскоре мы вернулись в лагерь.\n\nРассказчик: Расстались у домика.
Рассказчик: Алиса улыбнулась мне на прощание.
Рассказчик: Я поднял руку в приветствии и пошёл к себе.
Рассказчик: Ложусь спать, думаю о сегодняшних событиях.
Рассказчик: Впервые за всё время пребывания здесь я почувствовал себя немного более комфортно.
Помимо этого, бывало, что модель видела не сценарий, а проверку для модели. И отвечала модель, так сказать, без опоры на сюжет.
Размышления DeepSeek-R1:70b на вопрос "Помочь Ульяне убраться?"
Хорошо, я вижу, что мне нужно помочь пользователю с задачей. Он предоставил длинный текст на русском языке и попросил ответить одной цифрой, не повторяя вариантов и не перечисляя их.
Первое, что приходит в голову, это то, что он, возможно, хочет, чтобы я выбрал между несколькими вариантами ответа, но они не указаны явно. Возможно, это связано с выбором следующего шага или решения в каком-то контексте, например, в игре или истории.
Поскольку текст описывает различные события и перипетии, возможно, требуется определить, сколько вариантов ответов ожидается, или просто выбрать цифру, соответствующую определённому состоянию или коду.
Однако без дополнительной информации трудно точно определить, какая именно цифра требуется. Возможно, пользователь хочет проверить способность делать выводы или распознавать паттерны в тексте.
Я подумаю, что, возможно, это простой тест: сколько раз упоминается определённое слово, или какое число.hidden в тексте. Но мне нужно быть осторожным, чтобы не дать неверный ответ.
В итоге, я решил, что безопаснее предположить, что требуется цифра 1, так как это самая распространённая первая опция.
Более того, я сперва делал промпт, где модель объявляется Семёном и именно модель должна принимать решения. Это видно в двух спойлерах выше, модель говорит о себе. У меня нет объективных измерений, но как будто промпт "ты Сёмен" плохо воспринимался моделью, в то время как "ты помощник Семёна" более соответствовал тому, под что учат эти модели.
В общем, да, содержимое этих двух спойлеров может быть комичным, но мне показалось совсем уж наглым выносить это в статью: каждое размышление — это огромный кусок текста, который не всем будет по нраву. Поэтому дампы "финальных" запусков я выложил архивом — для тех, кто хочет и готов погрузиться.
Более того, я не заметил, чтобы модели отдавали предпочтения тому или иному персонажу. Они в большинстве случаев вели себя ближе к вежливому генератору случайных чисел. Например, делали комплименты Лене, а искать Электроника хотели со Славей.
Может быть, "облачные" модели (которые полноразмерные и доступны по API) будут более последовательны, но они, может быть, знают весь сюжет. Может быть, ваше предложение с мультимодальной моделью будет работать лучше. А может быть, модель совсем захлебнётся в контексте. Тут моих компетенций, к счастью или сожалению, не хватит.
Но отрицательный результат — это тоже результат. Вот я и решил поделиться тем, что у меня (не) получилось, на случай, если кто-то захочет пойти после меня.
Даже с упрощением в виде генераторов лексера и парсера текст получился довольно объемным. Изначально я хотел повторить опыт автора Tabloid и написать эти компоненты сам, но потом посчитал, что велосипедостроение будет избыточным и лучше рассказать о том, что задача решена и автоматизирована.
Но если кто-то вдохновится моей статьёй, то на вдохновении и академическом интересе читатель может собрать свой лексер-парсер-интерпретатор.
Штош, благодарю за уточнение, я слишком зациклился на JVM и CLR, что сузил описание именно до байт-кода ВМ и машинного кода. И, да, потерял описание ленивости.
Но в свое оправдание скажу, что несколькими абзацами позднее я всё же упомянул про это — в контексте прогрева JVM.
Это задумывалось продолжением предыдущего предложения:
Людям хватает одной ленты, чтобы получить перегруз информацией, так что одновременно смотреть в две или три ленты может быть совсем избыточно для мозга. Это шутка-отсылка к некоторым современным видео, где помимо основного контента на половину экрана вставляют видео нарезки мыла или кадры с прыжками из майнкрафта или гоночек.
Более широкое соотношение сторон позволяет легко и непринуждённо разместить больше вертикального контента. Но если возводить вашу мысль в абсолют, то и площадь не так важна: любой контент можно уменьшать до тех пор, пока человеческий глаз способен его различать. И, соответственно, на любой монитор можно вместить больше информации.
Что касается ноутбуков, то хочу акцентировать внимание на том, что эта тема не затрагивается в статье. Более того, статья привлекает внимание, что вот есть такая интересная ниша стационарных мониторов, может быть вам будет интересно. Тут нет конфликта «16:9 нинужны».
Я Владимир поменьше и исторические экскурсы у меня поменьше.
Некоторые мониторы 32:9 (вроде Samsung Odyssey из таких) — это два монитора 16:9 в одном корпусе.
У меня широкоформатный монитор горизонтально, а 16:9 — вертикально. Так что «телефонный» контент очень хорошо смотреть на вертикальном мониторе.
Я такой задачи не решал, но даже в ваших формулировках это довольно многогранная и большая задача. Возможно, вам стоит в первую очередь для себя уточнить что именно вы хотите сделать. Найти все подключенные в сеть устройства? Если вы делаете это в своей домашней сети, то почему именно на ESP, а не на роутере? Если хочется физического воплощения мониторинга, то может быть собирать информацию на роутере, а на ESP только выводить?
Сканер устройств в сети — это комплексная задача, которая, как я понимаю, сводится к гаданию на кофейной гуще. Единственное, в чем вы можете быть уверены — это в ARP-пинге, на который отвечают все устройства, потому что это основы работы сети (обычный ping можно игнорировать). И дальше со списком всех IP-адресов в сети применять все возможные сканы портов, mDNS и прочую магию, которая раскрывает информацию об устройствах
Спасибо!
Да, можно повторить с любой территорией, о которой есть сведения у выбранного провайдера погоды
Ответ на самом деле на поверхности: главный офис Selectel в Санкт-Петербурге, а мы тут встретились в корпоративном блоге Selectel, в котором говорится о игровом сервере, который запущен на мощностях Selectel под крылом Selectel x)
Но плагин, конечно, конфигурируемый и можно указать примерно любое место, которое есть у провайдера погоды. А можно, наверное, даже без него, вручную указав рассвет и закат
У нас пользователи, которые зарегистрировались через страничку promo.selectel.ru/Minecraft должны поставить галочку о согласии (там ФИО и почта). В игре на текущий момент мы не используем ФИО и почту.
На других серверах я видел, что у некоторых есть политика обработки ПДн на сайте сервера, но в игре никак не подсвечивается момент про ПДн
Если не ванила, то сервер может состоять из кучи плагинов, каждый из которых имеет своё видение когда и как нужно сохранять свои данные: кто-то сохраняет в YAML, кто-то в SQLite3, кто-то во внешнюю базу. Я не уверен, что плагины уважают команду /save-all, возможно, они о ней даже ничего не знают.
Кажется, что для сохранения консистентности бэкапа надежнее будет погасить сервер
Честно сказать, вы промахнулись статьей :)
Это был обзор других проектов на предмет «посмотрим что неприкрыто» с целью, может быть, позаимствовать практики, привлекающие пользователей. А заодно ответить себе на вопрос «Действительно ли (подставьте любой форк Paper'а) используется на серверах с онлайном 100+?» Вряд ли владельцы агрессивно-донатных серверов хотят всем и каждому рассказывать что и как у них устроено в мельчайших деталях. Они наверняка не хотят конкурентов.
Предлагаю вам обратиться к моей предыдущей статье (хотя, конечно, наша недоработка, что ссылки нет в тексте этой статьи), в которой рассматриваются технические подробности именно нашего сервера, где вы можете подчерпнуть какую-то пищу для размышлений (там рассказывается что мы делали пять лет назад в пандемию и что оставили для перезапуска в этом году) и заодно в комментариях приобщиться к обществу любителей Kubernetes: https://habr.com/ru/companies/selectel/articles/946400/
Как читатель о технологиях скажу «круто». Как админ текущего сервера скажу «зачем?». Я взглянул по вашей ссылке, MultiPaper остановился в публичной бете на версии 1.20.1, просто многопоточная Folia тоже немного отстает от классического Paper (у Paper есть хотя бы экспериментальные билды для 1.21.10). Для нашего сервера один из интересов — по возможности быстро подтягивать версию игры на актуальную стабильную, что для таких сложных проектов будет затруднительно. Более того, у нас одновременный онлайн пока что не превышал 30 человек, поэтому масштабируемые решения несколько избыточны. Возможно такие технологии пригодились бы какому-нибудь 2b2t, но там, говорят, чистая ванила.
В моих наблюдениях в этой статье мне не попалась ни одна Folia и ни одного MultiPaper. Сеть серверов с тысячным онлайном размазывает игроков между десятком независимых серверов и не знает бед.
Основной большой сервер на много людей запихивать в кубер я не вижу надобности, потому что это дополнительный слой абстракций, который будет немного да вносить ненужных накладных расходов и мало выгоды. Но как говорили в комментариях к моей предыдущей статье, это может быть оправдано, когда надо поднимать множество маленьких и, возможно, временных миров (мини-игры? Реалмы?). Но для совсем маленьких и совсем временных миров есть LimboAPI, которое довольно активно применяется. Если у нас почему-то появятся мини-игры с необходимостью поднимать отдельные игровые серверы под отдельную группу игроков, то вот тогда я и узнаю, как бы я решал эту задачу. Но скорее всего использовал бы Nomad или обратился бы к коллегам за помощью с кубером.
Здесь мне хочется со школьных времён вспомнить три правила ОБЖ: «Предвидеть опасность. По возможности предотвратить. При необходимости действовать.» Так вот «тюнинг майна» — это мёртвому припарка. «Предвидеть опасность» — это потрогать разграничение прав доступа на команды в игре и, возможно, отключить опасные игровые механики через плагины или настройки сервера. Вы можете использовать всевозможные флаги и дистрибутивы JVM, чтобы добиться чтобы сервер за приемлемое время обрабатывал в два раза больше блоков ТНТ, чем ванила. Но какой в этом толк, если пользователь может поставить в два-три-четыре раза больше блоков, чем вы хотели бы? У нас просто не выдаются права на команды WorldEdit и на вход в режим креатива. Игроки, конечно, и в режиме выживания могут «залагать» сервер, но это несколько сложнее.
В предыдущей статье описывается, что я решил попробовать разместить игровой сервер на облачной виртуалке, где максимальная частота ядра всего 2.1 ГГц. Это было ошибочное решение и игроки обычной своей игровой жизнью вскоре уронили ТПС сервера. Я пытался временно (до переезда на физический сервер) исправить ситуацию с помощью Aikar's flags. Это, очевидно, не помогло. Я не специалист в JVM, но вроде флаги скорее относятся к потреблению оперативной памяти и работе сборщика мусора, чем непосредственно к производительности виртуальной машины. Поэтому моё субъективное дилетантское не подкреплённое научными измерениями мнение: тюнинг может быть хорош для уменьшения потребляемых ресурсов (и потребляемых денег) для маленького сервера с друзьями.
Для сервера с друзьями — белый список. Я видел применение белого списка даже на более крупных онлайн-проектах. Там регистрация через привязку аккаунта в соцсетях. Если вы хотите прям публичный сервер, то готовьте CoreProtect и WorldGuard, если хотите бдить за порядком. Вы также можете заявить отсутствие порядка и не поставить ничего (режим «Анархия»). Я пошёл по пути порядка и полный список плагинов вы можете найти в статье, ссылку на которую я упоминал ранее.
Я сделал довольно в лоб: раз в какой-то промежуток времени ранним утром выполняется остановка сервера, архивация каталога с сервером, запуск сервера, выгрузка архива на внешний ресурс. Так как у нас несколько серверов с хранением данных в общей бд, то в архив ещё дамп базы можно сохранить.
У прокси-сервера и у игровых серверов есть Prometheus-экспортёры. Вы также можете добавить NodeExporter на физический/облачный сервер и следить за его ресурсами. Но опять же ответ на этот вопрос зависит от цели существования вашего сервера. Я смотрю за онлайном на проксе и вижу распределение игроков между серверами. На игровом сервере можно смотреть метрику TPS, хотя я этого пока не делаю. С физического и облачного сервера собираю метрики нагрузки на ядра, потребление оперативной памяти и количество свободного места на разделе с игровым сервером. Для сервера для друзей вряд ли нужно что-то кроме свободного места. Ибо друзья сразу пожалуются вам "чёт сервер лагает...".
Но всё же в более-менее крупных проектах (даже с нашим онлайном в 10-20 человек) должны быть люди, которые смотрят за игровым серверов прямо «на полях», то есть в игре. Потому что некоторые игроки коварны.
В заключение надеюсь, что мои ответы и ссылка на предыдущую статью утолили ваш голод технических деталей, возникший из-за этой статьи.
«Запихать в куб» — это как будто не самая сложная задача. Но я любитель запускать на железе, поэтому без кубернетеса х)
Что касается расширения одного мира на несколько серверов — вроде есть MultiPaper и у него написано, что это форк Purpur'а, который тоже так мог. Балансировать между серверами может хоть прокся (Bungeecord/Velocity), хоть по DNS на разные серверы отправлять.
Но я как-то не очень оптимистично смотрю на эти извращения, потому что, мне кажется, обязательно где-нибудь что-нибудь отвалится. Folia, пытающийся в многопоточность — в бете, MultiPaper в бете и с ним несовместимы обычные плагины.
В какой-то момент кажется, что проще сделать несколько серверов на ~200 игроков с драконовскими ограничениями на количество сущностей в мире. Ну по крайней мере с высоты сегодняшнего опыта мне так кажется
Ну на 4pda применили — приложение "Транспорт" и синхронизация с Google Tasks до сих будоражит сознание людей и они хотят что-то такое на девятке-десятке =)
А недавно видел интересный запрос — циферблат, на котором отображается курс золота. Тут бы интернет точно пригодился
Пардон, пропустил уведомление о комментарии.
Тут, кажется, вам только эксперименты помогут. Я в своей работе в принципе не отдаю опцию 60, так загружается самый простой режим, который (по крайней мере у меня) работает.
Когда я пытался отвечать с PXEClient, то сетевуха по спецификации делает ещё один DHCPproxy-запрос юникастом на другой порт. В общем, меня такое поведение не радовало и поэтому я не использую опцию 60.
С конкретной моделью не работал, но в общем нахватался забавных ситуаций. Не готов ответить по-научному и со всеми пруфами, но направление для отладки, надеюсь, смогу вам подсказать.
В общем случае могу сказать, что если вы уверены, что DHCPOFFER доходит до сетевухи, а сетевуха не хочет отправлять DHCPREQUEST, то это значит, что ваш оффер не удовлетворяет требованиям сетевухи.
Я, в частности, обнаружил, что «обычный» PXE игнорирует офферы, если в них нет next-server и bootfile. В некоторых случаях у сетевухи два режима загрузки — в соответствии со спецификацией интела и какой-то «обычный» режим. Так вот первый режим требует в ответе опции 60 со значением PXEClient, иначе тоже игнорирует офферы.
Послушайте трафик, там есть опция, кажется, 54, Parameter LIst называется, там указан список опций, которые хочет видеть сетевуха. Сравните этот список с тем, что вы предоставляете и, может быть, это и будет решением.
Я видел мем, что при вопросе про платные подписки deepseek отвечает что-то вроде "абсолютно бесплатно", а потом добавляет про подписку плюс =)
Я не смог добиться такого, да и может это фотошоп, но полностью исключать нельзя.
Технические характеристики «железного» радио — это, действительно, вам в статью по ссылке из начала. Сам проект Ka-Radio32 не то чтобы развивается семимильными шагами, но его сложно называть заброшенным. А ещё он достаточно неплохо работает.
А «проект заброшен, с багами» относится к интеграции, которая связывает Home Assistant и Ka-Radio32.