Выбор эмулятора Опции

[Ubu]

Привет!

Если бы вы сейчас запускали новый серв, так сказать, с "чистого листа", какой бы эмуль взяли и почему?

[Ubu]

RunUO is coming back in 2021....

интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит...

Создай тему в соответствующем разделе, а то каша получается.

done, извиняюсь)

@Juzzver ответь в асю плиз

[Juzzver]

интересно, а что говорят интересного будет? или молчат пока и не факт что будет что-то?) Почему-то мне кажется, что последнее, судя по тому как обычно все происходит...

Там на сайте ссылка на дискорд, в котором шумиху эту обговаривают. Собралось уже человек 200, из которых многие из старых разработчиков RunUO и просто знатных девов. Из того что сделали - подняли бекап старого сайта со всеми данными, скриптами и прочей инфой.
Что говорят - особо не вникал, и до сих пор вроде активных действий еще не было. Я думаю они размышляют в каком направлении двигаться, читал разговоры про ранку на js фреймворках и прочие идеи, но пока это только разговоры.
Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо.

@Juzzver ответь в асю плиз

Аськой перестал пользоваться.
Пиши в дискорд или скайп:
Juzzver#6102

[nullptr]

Там же есть дев от ModernUO, который уже внес большой вклад в форк ранки, переписывает её уже пару лет под современные технологии, добился хороших показателей в плане оптимизаций, кросфплатформенности и еще ряда решений, так-же еще много планов на пути. Активно отвечает всем заинтересовавшимся его проектом, и есть хорошая вероятность что плоды его работы возьмут для рануо.

У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же.

В планах создать веб интерфейс для возможности редактирования мира через меню.

Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода.
Пример
https://vimeo.com/523271600

[Aimed]

У ModernUO, самый большой плюс современный tcp стек, что значительно снижает пинг при больших обменах(замесы итд), Runtime code generation, хоть это и актуально только для разработчиков, но всё же.

В планах создать веб интерфейс для возможности редактирования мира через меню.

Ну и мой вклад, это система модификация мира без перезапуска сервера, можно изменить дроп где угодно, прямо из игры, без каких либо знаний программирования, уже разрабатываем веб интерфейс в котором можно будет конфигурировать сервер вне кода.
Пример
https://vimeo.com/523271600

Что такое "современный" tcp стек? Очередное модное слово? Я смотрел что он там делает, там по большому счёту микро оптимизации старого кода и небольшие архитектурные оптимизации, которые главных проблем никак не решают. Сервер всю игровую логику на одном потоке обрабатывает, практически никак другие ядра не утилизирует для самых ЦПУ интенсивных задач и никаких планов по этому поводу нету. По крайней мере год назад точно не было. А сегодня уже доступны сервера с 64 ядрами.

Глянул я ваш "современный tcp стек", правда бенчмарк тестов я там не увидел, что бы можно было сравнивать "профит" по сравнению со старым кодом. Имхо, совершенно неэффективная трата времени и сплошной фейл в плане идей. Можно было бы в разы, а может и на целый порядок больше профита получить, если добавить в УО протокол концепцию "buffer" пакетов и заимплементить это на сервере, в Орионе, КлассикУО и сделать патч для официального клиента. Вместо того что бы слать каждый пакет по отдельности, как сейчас, и спамить в тех самых замесах или как это делается в Vita-Nex. Можно буферизировать пакеты и высылать их клиентам всегда одной пачкой, одним пакетом и всегда строго по интервалу в Х ms, таким образом сильно стабилизруя нагрузку на сеть, вместо того что бы переделывать старый асинк код и на пару % больше выжимать из железа, по сравнению с тем что было раньше. А может там и вовсе никакого профита нету, потому что бенчмаркинга я так и не нашёл. C# это все таки не плюсы и тут можно запросто получить нежданчик в виде оптимизаций на уровне CLR.

А что значит "значительно снижает пинг"? Пинг в основном определяется расстоянием и количеством узлов между сервером и клиентами и он в тысячи раз выше, нежели обработка данных на сервере и отправка пакетов. Если у тебя сервер начинает лагать так что начинаются проблемы с пингом, то у тебя точно проблемы не на уровне сети, а на уровне обработки игровой логики - скриптов. Сервер не справляется с нагрузкой на его основной поток и не может во время выслать пакеты клиентам и в результате все клиенты лагают. Нагрузка на сеть в УО сервере просто микроскопическая ( при условии что там нету идиотизма в скриптах, где на 1 тике 1 клиент спамит всех вокруг кучей пакетов ) по сравнению с нагрузкой на главный поток, к тому же что даже при старом коде все сокеты работали асинхронно.

[Juzzver]

А что значит "значительно снижает пинг"? Пинг в основном определяется расстоянием и количеством узлов между сервером и клиентами и он в тысячи раз выше, нежели обработка данных на сервере и отправка пакетов. Если у тебя сервер начинает лагать так что начинаются проблемы с пингом, то у тебя точно проблемы не на уровне сети, а на уровне обработки игровой логики - скриптов. Сервер не справляется с нагрузкой на его основной поток и не может во время выслать пакеты клиентам и в результате все клиенты лагают.

В уо можно сказать есть свой внутренний пинг, который таки напрямую зависит от скорости обработки игровой логики. Это видно через внутренний пинг, через пакеты сервера, что можно проверить разором/стимом, и т.д., где разбег может быть сумасшедшим от 20мс до 500 и 1000. Так что один лишь переход на .net 5 - уже оказывает существенное влияние.

Про tcp оптимизации не знаю, но уверен что таки имеет место быть на уровне тех же вызовов по стеку, но визуально это будет видно слабо в контексте уо сервера.

По поводу аутлендса, они ж таки лагали дико после открытия, когда онлайн начал превышать ожидания, и там были применены какие-то оптимизации, которые решили данную проблему. Кто над этим работал не знаю, но Бэтмен у них в команде, не исключаю что имело место быть его рука.

Он так-же помог оптимизировать дико лагающий сервуо, но там тоже скорее всего имел место быть .нет 5.

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

Value у проекта сомнительный исходя из того, что штатный юзер не будет понимать к чему все эти оптимизации/перформанцы, и возьмет сервуо за счет контента. Но если браться за серьезный проект, я бы как минимум присмотрелся к модерн уо, изучив его получше. Работы активно ведутся уже пару лет, так что вполне вероятно что-то заслуженное там уже присутствует (пока не нашел времени во всем этом глубже разобраться, проекту не хватает какого нибудь вики).

Я это все к тому, что как форк - вполне себе имеет место быть. Приятно видеть что кто-то уделяет время скучным оптимизациям, даже в столь мало актуальных местах сервера, интересно к чему это все со временем приведет. Так же он активно отвечает всем заинтересованным, помогает, делится планами на будущее. Такому энтузиазму можно позавидовать, учитывая текущее положение уо в целом (IMG:style_emoticons/default/rolleyes.gif)

[Aimed]

В уо можно сказать есть свой внутренний пинг, который таки напрямую зависит от скорости обработки игровой логики. Это видно через внутренний пинг, через пакеты сервера, что можно проверить разором/стимом, и т.д., где разбег может быть сумасшедшим от 20мс до 500 и 1000. Так что один лишь переход на .net 5 - уже оказывает существенное влияние.

Все что выше 1 мс, это уже лаги сервера и кривой код в скриптах/ядре, потому что в ранке нету ограничения по тикрейту или чего-нить подобного, ограничевающего работу ядра. Если пришёл пакет, его кидает в очередь для обработки и сразу срабатывает мейн тред ядра для его обработки + заодно таймеры и все остальное, что там ещё есть, обрабатывается. Ты, скорее всего, нашёл какой-то корнер кейс со Стимом/Разором. Какие именно пакеты ты спамил? Что-то связанное с текстом? В ранке был/есть кусок говнокода, который мы ещё на УОРПГ фиксили. Там 1 игрок на Стиме мог тупо заставить сервер лагать, это при том что там есть система троттлинга пакетов, которая нихера не работает, судя по всему )) А фикс был очень простым. Когда приходил определенный пакет, от которого лагало, смотрели сколько таких пакетов с текстом пришло от текущего нетстейта за послехних Х мс и если их было слишком много, тупо не обрабатывали его. Просто свой, очень простой троттлинг сделали. Его Вап вроде делал, если не ошибаюсь.
Так что в целом, при таком высоком внутреннем пинге, больше решают точечные фиксы кода ранки, для этого не нужно сразу весь фреймворк менять. Да, нет5 он лучше и пошустрее, но на .NET Framework уже много лет дофига огромных аппликаций работает и он не сильно хуже в целом. Там в основном просто натягивание совы на глобус и маркетинг. Наделали бенчмарков для отдельных элементов, которые являются мега корнер кейсами и вообще ничего общего с реальностью не имеют. Что-то вроде итерирования по списка с 1кк записей ( там такого нету, но почти все бенчмарки у них такого типа ) и в итоге у них там получается +30% прирост, лол. А в реальном мире такого никогда не будет, по крайней мере точно не в контексте УО сервера. А потом давай бложики пилить, а кое-кто начитался и теперь папугайничает тут у нас, вместо того что бы своей головой думать. Да, там однозначно хорошо оптимизировали стек для asp.net, так что теперь любой нюбас, создавший веб аппликацию на asp.net core из темплейта сможет на Х тысяч больше CCU обслуживать на том же самом железе. Но в контексте УО сервера вся эта оптимизация мало что решает, если там куча других, куда более критических дыр, в самом коде сервера.

Про tcp оптимизации не знаю, но уверен что таки имеет место быть на уровне тех же вызовов по стеку, но визуально это будет видно слабо в контексте уо сервера.

Для этого делают бенчмарки, о чем я сразу и начал говорить. Батман почему-то на заморачивался сделать бенчмарки, что бы иметь хоть какие-то обьективные данные, но зато перелопатил кучу кода. Вот это меня сильно смущает. Смысл оптимизировать, если ты не знаешь какой прирост производительности в итоге получаешь??? Разве это не странно?

По поводу аутлендса, они ж таки лагали дико после открытия, когда онлайн начал превышать ожидания, и там были применены какие-то оптимизации, которые решили данную проблему. Кто над этим работал не знаю, но Бэтмен у них в команде, не исключаю что имело место быть его рука.

Он так-же помог оптимизировать дико лагающий сервуо, но там тоже скорее всего имел место быть .нет 5.

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

Это как раз те самые точечные фиксы cамой ранки о которых я и говорил выше. Даже переработку/оптимизацию таймеров можно назвать точечным фиксом. Кстати, реализация таймеров в РанУО довольно хороша с архитектурной точки зрения и по производительности не должно быть с ней огромных проблем. Там есть более критические зоны где все куда хуже с этим делом. ServUO все ещё на .NET Framework судя по их гитхабу. Да и наврядли на UO Outlands в то время кинулись переходить на .NET Core, потому что через месяц после их выпуска только анонсировали релиз .NET Core 2.2 который не имел стольких оптимизаций на тот момент. Да и скорее всего что Outlands все ещё на .NET Framework и Mono.

Value у проекта сомнительный исходя из того, что штатный юзер не будет понимать к чему все эти оптимизации/перформанцы, и возьмет сервуо за счет контента. Но если браться за серьезный проект, я бы как минимум присмотрелся к модерн уо, изучив его получше. Работы активно ведутся уже пару лет, так что вполне вероятно что-то заслуженное там уже присутствует (пока не нашел времени во всем этом глубже разобраться, проекту не хватает какого нибудь вики).

Я это все к тому, что как форк - вполне себе имеет место быть. Приятно видеть что кто-то уделяет время скучным оптимизациям, даже в столь мало актуальных местах сервера, интересно к чему это все со временем приведет. Так же он активно отвечает всем заинтересованным, помогает, делится планами на будущее. Такому энтузиазму можно позавидовать, учитывая текущее положение уо в целом (IMG:style_emoticons/default/rolleyes.gif)

Конечно имеет место быть! Это ж опен сорс! А value сомнительный, потому что делаются оптимизации, которые 99% а может и всем 100% шардов никогда и не понадобятся, при этом вбухивается куча человекочасов во все это дело. Чувак просто ловит кайф от написания максимально оптимального кода на новом стеке, вот как сейчас выглядит MUO для меня.

Не знаю всех тонкостей по оптимизации, но не так давно пинг на ауте был 250+, сейчас же пинг 115.

Это скорее больше с хостингом связано. Возможно перенесли сервак куда-нить, где путь между узлами более оптимальный для тебя.
Если б скорость обработки игровой логики ( внутренний пинг, как его называет Juzzver ) была раньше 100+ мс, то на UO Outlands никто не смог бы комфортно играть.

[nullptr]

Скора net 6 выйдет, не исключаю, перехода (IMG:style_emoticons/default/biggrin.gif)

[Aimed]

Скора net 6 выйдет, не исключаю, перехода (IMG:style_emoticons/default/biggrin.gif)

Если это я тебя в Linkedin нашёл, то ты живой пример воплощения в жизнь сценария из фильма "Идиократия". ~14 лет уже в разработке софта и не можешь понять разницу между бенчмарками в миллионы итераций сортировок/http запросов из бложиков работников майкрасофта и то как это будет в реальных ситуациях проявляться и масштабироваться, особенно в контексте УО сервера + совершенно игнорируя факт что УО сервер это целая гора кастомного кода со своими, как проблемами, так и наоборот очень хорошими, в плане оптимизации решениями.

Я тебя уже даже носом ткнул в Socket.cs, что б показать что там нет никакой магии и что в конкретных местах, которые, например, рануо использует, эти оптимизации настолько несущественны, что Батману пришлось сильно поменять буфферизацию для сетевого кода и внедрить концепт пайпов, что бы использовать другой метод по отправке данных, где оптимизация в .net5 будет давать куда более существенный результат. И самое забавное тут то что ВЕСЬ этот код можно было самому написать и на старом C# и .NET Framework 2.0, если очень хотеть и уметь. Ничего революционного там нету, совершенно ничего. Просто теперь новые аппки из коробки чуть лучше и шустрее будут работать.