Привет!

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

RunUO, за то что:
-Вменяемый язык программирования C#.
-Открытый исходный код
-Куча форков и большая база готовых скриптов.
-Скрипты на реальном ООП
-Поддержка последних версий клиентов (другие эмули вроде уже тоже этим владеют, но мне не известно насколько там гладко всё это).
-Поддержка оси, где из коробки уже куча крутых фишек и систем идёт.

Другие эмуляторы по сравнению с RunUO, на мой взгляд уже дохлые, не смотря на то, что появились их исходники. Найти дева под уо на C++ труднее и дороже, а саму разбираться - это жизнь посвящать надо тому, что уже землей засыпают.

А в остальном, всё от задач зависит. Если нужна копия пираток начала 2000х годов - сфера и пол лучше подходят.
Современное уо - тут однозначно RunUO.

Спасибо! Ожидал подобный ответ. Лет 7 не рисерчил этот вопрос.
А что по поводу ServUO?

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

Мне кажется или на сайте runuo не работает половина разделов, форум в архиве и тп?

смотря для чего сервер. простота кастомизации ПОЛа зашкаливает, любой стиль игры делать просто. если нужно для последних клиентов то конечно runuo. пользуюсь полом, но иногда доходит до того что смотрю код ядра runuo на предмет работы с пакетами, чтобы понять что мой ПОЛ делает не так, т.е. РАНУО это точно ориентир ну все плюсы что описал Juzzver

Обсуждали уже много раз. Итог:

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

ранка/сервуо - если тебе ничего не охота делать, а просто запустить и играть в подобие ОСИ. Всё сделано за тебя.

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

Juzzver, смотри посмотри лс, пожалуйста.

последние года 2 разработчики оф. ранки забили на эмулятор и на форум, с тех пор он работает с большими перебоями. Вроде месяц назад еще работал. Возможно через месяца 2 вновь заработает

Самый свежий форк от бывшего участника команды RunUO - https://github.com/runuo/runuo
Это чистая ранка с поддержкой последних клиентов. Типа неофициальные версии от 2.3 до 2.6 версии.

А скрипты можно и из сервуо дёргать. По большей части они совместимы с ранкой: https://www.servuo.com/archive/
Но это не на долго , т.к. они уже внедрили достаточно изменений и зависимостей, в связи с чем новые скрипты, которые будут выкладываться - будут всё менее совместимы с обычной ранкой.

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

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

Мнения разделились :)

На РанУО не меняя код ядра можно сделать только унылый клон. Вообще... на РанУО внятного ядра вообще нет, просто часть C# классов компилируется раньше, и это типа ядро... толк от этого есть только если делать OSI клон, основанный на скачанном коде.

А вот на Сфере скрипты хорошо обособлены и дают высокую степень автономии. Но скрипты очень медленные про сравнению с С# или C++.

Лично я бы сейчас выбирал платформу семейства РанУО, так как более современный язык и работа с такой платформой более полезна для самосовершествования.
Но есть один подвох. Новичок-одиночка из РанУО сервер, подобной Сфере сделает очень нескоро, а пока он этого не сделает, игроками это все будет восприниматься как "Ранка" = "переделанный ОСИ-клон". Что в рунете не самый популярный жанр.

С ПОЛом не работал, ничего не могу сказать. Но в целом, судя по серверам на разных платформах, полностью плохих эмуляторов среди этих трех нету, есть плохие разрабы.

Но как я уже подметил выше, есть множество форков, где присутствует та же ранка на сфера-стайл моде.
Наиболее популярный вроде как Imagine Nationhttps://github.com/jyourstone/imaginenation

Ну если скриптить драконов для пещер - то да

кстати да IN:X 51я сфера-стайл тарановская рануошка

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

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

Учитывая что УО сейчас мягко сказать мало кому нужна, зачем тебе убивать свою жизнь на изучение того же шарпа т.к. технологичнее он круче сферы? В чем смысл если твоя идея к примеру де_ьмо и твой сервер некому не будет нужен что на шарпе, что на сфере, что на поле?) Обкатай идею на том где порог вхождения ниже, а дальше наймешь программистов и они тебе хоть свой эмулятор запилят, главное что бы были деньги =)

>> Регистрация: 5.8.2003

Только увидел у себя.
Блин, это что ж 15 лет жизни на этом форуме?
Половина жизни? Вот де_ьмо почему мне не сказали что эта игра настолько цепляет xD

>> де_ьмо

И почему это какашка - стала вырезатся антиматом
15 лет назад такого небыло xD

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


Полностью согласен, когда вижу скрипты сферы сразу вспоминается китайский язык )))

Привет. Подскажите, на какие средства для разработки стоит обратить внимание?
Интересует работа с клиентом\картой и тп.

Что вообще сейчас используют в дополнение к ServUO, в основном?

http://dev.uoquint.ru - тут какие-то интересные наработки есть, они вообще живые? Или сейчас есть более юзабильные решения?

Интересует список инструментов, который расширит мои возможности работы в связке с ServUO.
Спасибо.

Если кто-то готов проконсультировать нормально, пишите в ЛС, договоримся.

Зависит от плотности работы с клиентом, которая тебе нужна
Если прямо ковырять клиент - ClassicUO
Работа с картой как всегда Центред+
Ну и эмулятор ServUO, ранка, сфера или что там у тебя по вкусу

хоть убейте, так и не понял чем рануо от сервуо отличается в приниципе, кроме того что сервуо больше контента

Ну тем и отличается
Качеством кода отличается.

Если делать ренесанс версию, то нет смысла брать сервуо с её контентом, ибо будет только лишняя нагрузка на производительность и плотные сейвы с параметрами, которые не будут использоваться, + косяки повылазят точно, т.к. там не сильно смотрят под какие эры правки делаются. А с недавних пор они вообще отказались от поддержки ренесанса и начали выпиливать код, так что последние паблиши вовсе негодные под ренесанс версию. Так что тут либо брать предыдущие паблиши (до <= 54 publish), либо вовсе отказаться и взять чистую ранку, где ничего не вылезет, но придется приложить немного руку - чтобы что-то появилось по контенту Из сервуо всегда можно будет что-то вырвать и перенести на рануо, правда не без крови, т.к. они там уже пишут совсем как попало, количество зависимостей неимоверное теперь.

Если делать максимально по оси что-то, то брать сервуо со всеми их изъянами, благо можно поправить, это будет проще чем писать тонны контента с нуля.

А подскажите плиз как в CentrEd+ карту сохранить?

изменения не появляются. файлы, которые mul пробовал копировать в папку с сервером и тп, все равно в игре ничего нет. Захожу в CentrEd+ изменения есть.

RunUO is no longer officially supported by a core team.
If you wish to find support in a wider UO development commuity, visit ServUO - Ultima Online Emulation

Ozzy, понял, спасибо.

подскажите с CentrEd+, как изменения в игру добавить? второй день е..сь

RunUO is coming back in 2021....
http://runuo.com/

Создай тему в соответствующем разделе, а то каша получается.
https://forum.uokit.com/index.php?showforum=8

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


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

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

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

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

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

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

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

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

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

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

Проблема даже не в коде, просто собрав проект на .net 5 вместо .net framework(4 - 4.5.2) можно получить до 35% производительности в стандартных операциях.

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

На каком месте находиться .net core(.net5) по показателю request/per second?
Как мы знаем http базируется на tcp.

https://www.techempower.com/benchmarks/#sec...;test=plaintext

По поводу того, что Batman, топит за архитектурные решения, его дело.
Я понимаю, что для кого-то алокация при использовании string, ничего не значит, но для кого-то нет ничего кроме span.

хотел написать aimed тут уже оставил свой пост?

а он уже отписался, шустрый парень...

Завидуешь?

Миграция на net5 - окей, засчитано. До 35% в контексте УО сервера, сильно сомневаюсь, скорее всего прирост есть только в каких-нить супер специфических кейсах, которые больше как приятный плюсик, но в целом просто пшик.

А причем тут HTTP протокол? O_o УО сервер не использует HTTP протокол, все летит по TCP. Или это в контексте ваших планов на веб интерфейс для модификации мира? Дык там нагрузка через HTTP просто смехотворной будет, это ж админская утилита.

И нет, как раз таки Batman топит за слишком слабые/маленькие архитектурные решения, которые чаще даже просто являются переписыванием кода на новые структуры данных и просто больше похожи на оптимизации/микро оптимизации. Больше работы со стеком, меньше аллокаций и меньше работы для GC. Тот-же span, на который теперь все дрочат, как будто это просто мега открытие из-за которого, внезапно, можно написать очень быстрый код, является просто синтаксическим сахаром. Со стэком, в unsafe контексте можно работать ещё с самого создания C#/.NET.

Ещё раз моё мнение: нужно основательнее подходить к данному вопросу, с самого верху, включая клентскую часть, потому что теперь есть Орион и КлассикУО.
Даже на старой ранке/сервуо "тупой" производительности больше чем хватает. Тот же Outlands сервер довольно хорошо справился с нагрузками при минимальных изменениях в ядре. А серверов с таким высоким онлайном, скорее всего, больше не будет. Если уж и переделывать что-то настолько основательно, то надо делать это так, что бы модернизация затрагивала УО как игру, а не только сам эмулятор, и на уровне архитектуры позволяла внедрять фичи, которые поднимут геймплей на новый уровень.

Хорошо, давай детально. HTTP реализован на TCP имеет свои заголовки и свой формат передачи, что бы добиться таких цифр req/per second, нужно было переписать полностью работу сокетов.

Я повторяюсь TCP(Soscket) .net 4 - 4.5.2 просто ужасны.

Ранка дала жизнь всем другим серверам, это самый большой взнос в комьюнити UO + C#.

Я выше уже написал:

Это и правда хорошо, но если это единственный плюс, то кхм, нахера тогда было создавать ещё один форк ранки? Можно было и её просто перевести на net5.

И причем тут опять HTTP протокол? УО не использует HTTP и там может быть не мало оптимизаций и на уровне HttpClient/в хендлерах у эндпоинтов и вообще то что ты кинул, это хендлинг HTTP запросов в веб аппликациях.
1) Если пройтись по твоей же ссылке - там нету данных о перформансе .NET Framework для сравнения.
2)Опять таки, все эти бенчмарки делаются под кейсы с миллионами реквестов под типичное использование фреймворка, а это вполне может означать что значительная часть перформанса была в самом создании коннекшенов для http запросов, а не в передаче данных. В УО серверах не надо постоянно создавать миллионы коннекшенов. Это бесполезный перформанс буст, который в итоге даст чуть больше чем нихера.
3) Самый большой УО сервак - UO Outlands, на пик имел под 2к коннекшенов. Это просто тотальный пшик. Супер модный и современный код пишется, время тратится, а итоговый value чуть больше 0



Спасибо кєп, сильное заявление, тем паче на этом то форуме/в рунете, где ранка наименее популярна.

RunUO использует socket, если точнее то System.Net.Sockets.
WebRequest использует System.Net.Sockets.

Ну и образно, на сколько нужно было улучшить
System.Net.Sockets в .net 5, чтобы попасть в топ 5 лучших ?

Вот Http запрос на сокете, если так будет легче.

var socket = new Socket(AddressFamily.InterNetwork, SocketType.Stream, ProtocolType.Tcp);
socket.Connect("127.0.0.1", 80);
string GETrequest = "GET / HTTP/1.1\r\nHost: 127.0.0.1\r\nConnection: keep-alive\r\nAccept: text/html\r\nUser-Agent: CSharpTests\r\n\r\n";
socket.Send(Encoding.ASCII.GetBytes(GETrequest));

Это чистая спекуляция уже начинается. Я сверху свой пост отредактировал, посмотри его ещё раз.
Там вполне себе реальная ситуация что весь твой перформанс идёт от улучшенного создания коннекшенов и парсинге стрингов, потому что речь тут о ХЕНДЛИНГЕ HTTP запросов, а не в создании самих запросов, как в твоём примере с кодом.

И в контексте УО всё это чуть больше чем бесполезно, в плане оптимизации. Я не знаю как тебе это ещё обьяснить.

nullptr, почитай как работает HTTP request lifecycle, а потом посмотри УОшный network код ( вот тебе ссылочка ) и скажи мне причем здесь все то что ты тут понаписал?

П.С. Я не смотрел исходники самого Socket.cs на .NET Framework и net5 для сравнения, но уверен на 99.9999% что там практически ничего не было улучшено в плане передачи данных. Потому что там попросту НЕКУДА улучшать. В нетворк стрим копируется массив с байтами. В контексте передачи данных этот класс практически напрямую связан с апи самой ОС и просто кормит в ОС все что попадает в его стрим, дальше ОС передаёт данные в сетевую карту и так далее.

Поэтому, я УВЕРЕН что весь этот перформанс ( 5е место по твоей ссылке ), это в основном, улучшение работы с самими коннекшенами на уровне эндпоинтов в asp.net core и парсинге хттп стрингов. Что имеет ровно 0 отношения к УО серверам или даже просто апплкациям, где вручную создаётся менеджмент коннекшенов через TcpListener/Async колбэки на сокет обжектах.

Суть не в том, что ты отправляешь, а чем ты отправляешь, если у шарпа это system.net.sockets, то там хоть письмо, хоть бандероль.
Http, буфер, пакеты, один хрен.

Ибо всё это в конечном итоге, буфер байтов, которые записывают в сокет.

И Ключевой момент будет играть, исключительно реализация socket на конечной платформе.
net framework vs .net 5

Реализация Socket.cs в разных контекстах по разному утилизируется. Если речь о хендлинге миллионов http запросов, то будет дикая нагрузка не только на код по отправке данных, но и на код связанный с созданием и закрытием коннекшенов, потому что так работает HTTP протокол. И я уже, честно говоря, устал это повторять. В УО сервере открытие и закрытие коннекшена это довольно таки редкое явление, в отличии от отправки данных. И это мы ещё не начали говорить о десериализации данных, которая никак не связана с Socket.cs, на который ты так здесь молишься.

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

net framework
https://referencesource.microsoft.com/#Syst.../Socket.cs,1306

net5 https://github.com/dotnet/runtime/blob/main...Windows.cs#L202


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



Что бы этот метод утилизировать, Batman создал класс Pipe<T> https://github.com/modernuo/ModernUO/blob/m...Network/Pipe.cs
Который и возвращает такой массивчик из буфферов. Все таки он частично внедрил буфферизацию пакетов, о которой я говорил в самом начале. Хотя это все равно субоптимальное решение в целом.

Смотри ты узнал, что-то новое на этом и закончим.

Вот тебе bechmark стандартных операций
https://devblogs.microsoft.com/dotnet/perfo...ments-in-net-5/
Но там сравнение с .net framework 4.8, если брать 4 - 4.5.2 то там все 70% будет.

Это не я тут что-то новое узнал, это тебя здесь учат, предоставляя обьективные доказательства к аргументации, и заодно обучают критическому мышлению. А в ответ мне приходится читать джуниорские ответы, ссылки на бенчмарки и бложики, которые к нетворкингу УО сервера имеют незначительное отношение.

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

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

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

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

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

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

Я это все к тому, что как форк - вполне себе имеет место быть. Приятно видеть что кто-то уделяет время скучным оптимизациям, даже в столь мало актуальных местах сервера, интересно к чему это все со временем приведет. Так же он активно отвечает всем заинтересованным, помогает, делится планами на будущее. Такому энтузиазму можно позавидовать, учитывая текущее положение уо в целом

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

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



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



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



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



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

Может и перенесли, явно лучше сделали.
Раньше рыдали, но играли при 250+)) а теперь во всем СНГ и РФ пинг чуть ли не на 100-ку упал.

Скора net 6 выйдет, не исключаю, перехода

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

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

Поговорил с Jaedan об UO Outlands и их миграции на .net5. Оказалось что они все же мигрировали, так что тут я ошибся. Но, мои рассуждения о полезности net5 для УО сервера, в контексте перформанса, были полностью подтверждены. Он сказал практически то же самое что и я здесь, ещё в самом начале.




А вот его ответ по поводу внутреннего пинга в 200-1000мс на локалхосте:



Получается что спад пинга у UO Outlands все же связан с переездом на более высокочастотный ЦПУ в комбинации с новым нетворк стаком, который Jaedan написал под винду на С и который работает на 1 треде. Так что тут я маленько ошибся, по поводу того что сетевой код не может вызвать такой лаг. Т.к. это больше зависит от главного треда, где обрабатывается игровая логика. Но если у тебя с тредами жопа на сервере, из-за асинк сокет кода и главный тред начинает из-за этого прерывать, то тут да... эт большая проблема и об этом я не знал. Но вы ошиблись больше xD потому что net5 никакого отношения к улучшению их ситуации с пингом не имеет.

На сколько я знаю, Batman и Jaedan, знакомые.
В данный момент Jaedan, просит отделить Ядро MUO, От контента, что бы можно было использовать со своим контентом. Так что думаю не так уж всё и хорошо на Outlands.

Опять он думает ))
Про мега приросты по производительности для УО сервера, после миграции на нет5, уже не думаешь?

П.С. В 10ке есть полезная функция по вырезанию скринов Win + Shift + S