Версия для печати темы

Нажмите сюда для просмотра этой темы в обычном формате

UoKit.com Форумы _ Общий _ Выбор эмулятора

Автор: Ubu 18.7.2018, 14:11

Привет!

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

Автор: Juzzver 18.7.2018, 15:39

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

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

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

Автор: Ubu 18.7.2018, 15:50

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

Автор: Juzzver 18.7.2018, 15:55

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

Автор: Ubu 18.7.2018, 16:08

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

Автор: olduo.com 18.7.2018, 16:09

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

Автор: RL_ka 18.7.2018, 16:33

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

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

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

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

Автор: Ubu 18.7.2018, 16:33

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

Автор: Juzzver 18.7.2018, 16:34

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

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

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

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

Автор: Atheist 18.7.2018, 20:08

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

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

Автор: Ubu 19.7.2018, 0:13

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

Автор: Wap 19.7.2018, 1:04

Цитата(Atheist @ 18.7.2018, 18:08) *
открытый код исходника, правда я не замечал чтобы он особо комуто нужен был что на рануо что на сфере smile.gif
На РанУО не меняя код ядра можно сделать только унылый клон. Вообще... на РанУО внятного ядра вообще нет, просто часть C# классов компилируется раньше, и это типа ядро... толк от этого есть только если делать OSI клон, основанный на скачанном коде.

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

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

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

Автор: Juzzver 20.7.2018, 9:56

Цитата
Новичок-одиночка из РанУО сервер, подобной Сфере сделает очень нескоро

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

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

Автор: Atheist 20.7.2018, 11:00

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

Автор: Ozzy Osbourne 21.7.2018, 14:28

Цитата(Ubu @ 18.7.2018, 14:11) *
Привет! Если бы вы сейчас запускали новый серв, так сказать, с "чистого листа", какой бы эмуль взяли и почему?


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

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

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

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

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

>> де_ьмо

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

Автор: StaticZ 21.7.2018, 14:56

Цитата(RL_ka @ 18.7.2018, 16:33) *
пол - если тебе хочется ковырять уо, делать что-то своё, непохожее ни на что. простой скриптовой язык ескрипт, который конечно намного проще чем ООП на ранке, а так же замена скриптов на лету без перезапуска сервера и отключения клиентов
У пола есть один недостаток - жиденькое сообщество, в рузоне так вообще достаточно сложно найти людей с опытом работы с полом (можно судить по тойже активности форума). Ну а делать свое в принципе можно на чем угодно, как по мне тут RunUO проще и приятнее, даже без всяких мануалов во всем не сложно разобраться и понять..


Цитата(RL_ka @ 18.7.2018, 16:33) *
сфера - мммм... сфера.... это кривой-косой квазимода, синтаксис скриптов которого повергает в ужас и шок даже опытных программистов, потому как там вообще нихрена не понятно laugh.gif В те времена когда я хоть что-то знал о сфере это был наименее кастомизируемый эмулятор. Может быть сейчас это не так, я запускал сферу последний раз лет 15 назад
Полностью согласен, когда вижу скрипты сферы сразу вспоминается китайский язык )))

Автор: Ubu 31.3.2021, 22:26

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

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

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

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

Автор: Ubu 1.4.2021, 2:55

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

Автор: Ozzy Osbourne 1.4.2021, 10:23

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

Автор: Ubu 3.4.2021, 0:58

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

Автор: Juzzver 3.4.2021, 3:20

Цитата(Ubu @ 3.4.2021, 0:58) *

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

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

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

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

Автор: Ubu 3.4.2021, 4:37

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

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

Автор: Ozzy Osbourne 3.4.2021, 13:43

Цитата(Ubu @ 3.4.2021, 0:58) *

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

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

Автор: Ubu 3.4.2021, 13:54

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

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

Автор: Juzzver 3.4.2021, 19:38

Цитата(Ozzy Osbourne @ 3.4.2021, 13:43) *

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

RunUO is coming back in 2021....
http://runuo.com/
Цитата
подскажите с CentrEd+, как изменения в игру добавить? второй день е..сь sad.gif

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

Автор: Ubu 3.4.2021, 20:56

Цитата
RunUO is coming back in 2021....

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

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

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

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

Автор: Juzzver 3.4.2021, 22:40

Цитата(Ubu @ 3.4.2021, 20:56) *

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

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

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

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

Автор: nullptr 18.8.2021, 17:24

Цитата(Juzzver @ 4.4.2021, 0:40) *

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

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

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

Автор: Aimed 18.8.2021, 18:16

Цитата(nullptr @ 18.8.2021, 16:24) *

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

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

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


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

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

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

Автор: nullptr 18.8.2021, 19:52

Цитата(Aimed @ 18.8.2021, 20:16) *

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


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

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

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

https://www.techempower.com/benchmarks/#section=test&runid=8721f3a4-7b13-4703-9cd8-91b6779668c2&hw=ph&test=plaintext

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


Автор: PrintScrin 18.8.2021, 22:16

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

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

Автор: Aimed 18.8.2021, 22:49

Цитата(PrintScrin @ 18.8.2021, 21:16) *

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

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


Завидуешь?

Автор: Aimed 18.8.2021, 23:22

Цитата(nullptr @ 18.8.2021, 18:52) *

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

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

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

https://www.techempower.com/benchmarks/#section=test&runid=8721f3a4-7b13-4703-9cd8-91b6779668c2&hw=ph&test=plaintext

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


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

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

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

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

Автор: nullptr 19.8.2021, 0:01

Цитата(Aimed @ 19.8.2021, 1:22) *

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

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

Цитата(Aimed @ 19.8.2021, 1:22) *

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

Автор: Aimed 19.8.2021, 2:34

Цитата(nullptr @ 18.8.2021, 23:01) *

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

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


Я выше уже написал:
Цитата(Aimed @ 18.8.2021, 22:22) *

Миграция на net5 - окей, засчитано.

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

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

Цитата(nullptr @ 18.8.2021, 23:01) *

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


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

Автор: nullptr 19.8.2021, 2:54

Цитата(Aimed @ 19.8.2021, 4:34) *

Только причем тут HTTP протокол? УО не использует HTTP.

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));

Автор: Aimed 19.8.2021, 3:14

Цитата(nullptr @ 19.8.2021, 1:54) *

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 код ( https://github.com/modernuo/ModernUO/tree/main/Projects/Server/Network ) и скажи мне причем здесь все то что ты тут понаписал?

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

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

Автор: nullptr 19.8.2021, 3:25

Цитата(Aimed @ 19.8.2021, 5:04) *

Зачем серверу слать HTTP запросы и главное, кому? Клиентам?

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

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

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

Автор: Aimed 19.8.2021, 4:37

Цитата(nullptr @ 19.8.2021, 2:25) *

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

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

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


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

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

net framework
https://referencesource.microsoft.com/#System/net/System/Net/Sockets/Socket.cs,1306

net5 https://github.com/dotnet/runtime/blob/main/src/libraries/System.Net.Sockets/src/System/Net/Sockets/SocketPal.Windows.cs#L202


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

Код
          
WSABuffer[] WSABuffers = new WSABuffer[count];
GCHandle[] objectsToPin = null;
objectsToPin = new GCHandle[count];


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

Автор: nullptr 19.8.2021, 14:23

Цитата(Aimed @ 19.8.2021, 6:37) *

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

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

Автор: Aimed 19.8.2021, 16:43

Цитата(nullptr @ 19.8.2021, 13:23) *

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

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


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

Автор: Juzzver 24.8.2021, 7:46

Цитата(Aimed @ 18.8.2021, 18:16) *

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

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

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

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

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

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

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

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

Автор: M0rBiT 24.8.2021, 9:54

Цитата(Juzzver @ 24.8.2021, 7:46) *



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





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

Автор: Aimed 24.8.2021, 18:36

Цитата(Juzzver @ 24.8.2021, 6:46) *

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


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

Цитата(Juzzver @ 24.8.2021, 6:46) *

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


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

Цитата(Juzzver @ 24.8.2021, 6:46) *
По поводу аутлендса, они ж таки лагали дико после открытия, когда онлайн начал превышать ожидания, и там были применены какие-то оптимизации, которые решили данную проблему. Кто над этим работал не знаю, но Бэтмен у них в команде, не исключаю что имело место быть его рука.

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

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



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

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

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


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

Цитата(M0rBiT @ 24.8.2021, 8:54) *

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


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

Автор: M0rBiT 25.8.2021, 8:40

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

Автор: nullptr 25.8.2021, 11:08

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

Автор: Aimed 27.8.2021, 0:55

Цитата(nullptr @ 25.8.2021, 10:08) *

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


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

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

Автор: Aimed 27.8.2021, 3:44

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

Цитата

Jaedan — Today at 01:40
Well, as with anything, it's complicated
First, we are hosted on AWS in us-east-1
On purpose - best balance of latency for our players
We changed from an r5a.2xlarge to a z1d.2xlarge and this made a massive difference
RunUO is fundamentally single threaded. There's a little bit of fan out, but not really in the game logic
So moving to a high frequency instance is most important
Just updating to .net 5 I don't think gives much improvement. It's worth something, but not much
But it does give us a new c# version and we can use that to make our code much more efficient
Outlands uses a totally different network stack. RunUO stack absolutely can introduce enormous latency like that
When the server is busy, it's at the mercy of getting it's threads scheduled to run

Val — Today at 02:22
Are u using a library for that or something made yourself?
Wait, so you didn't move regions, how come players have 110ms latency compared to 250ms in the past?

Jaedan — Today at 02:25
I wrote a new network stack in C
You can't write a high performance network stack using the c# standard library. It just doesn't work the right way

Val — Today at 02:25
I agree :slight_smile:

Jaedan — Today at 02:26
This is why even things like asp.net use libuv, not native .net



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

Цитата
Jaedan — Today at 02:48
I don't see how it can happen locally if you have at least 4 cores and your system isn't at max cpu
The issue with the existing stack in RunUO is that it schedules tasks onto the c# threadpool
And if you have 8 cores and 1500 tasks
Those tasks don't seem to get scheduled in order always. It can take a long time for the task to actually get CPU time
The tasks also do blocking CPU operations, so the thread pool keeps spawning more threads because it's set is blocked
So you end up with hundreds of threads executing thousands of tasks
And this can even interrupt the main game thread - that's when it gets bad

Val — Today at 03:00
Okay, so to clarify it one last time, you didn't switch regions within AWS and you also didn't switch from some other hosting provider to AWS, after the release of UO Outlands?

Jaedan — Today at 03:01
We switched to AWS in 2018 right after launch to mitigate DDoS and we haven't changed region since. We did just recently change the instance type and that made a big difference


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

Автор: nullptr 27.8.2021, 9:15

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

Автор: Aimed 28.8.2021, 11:06

Цитата(nullptr @ 27.8.2021, 8:15) *

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


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

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

Автор: nullptr 28.8.2021, 13:34

Цитата(Aimed @ 28.8.2021, 13:06) *

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

Увы, эксперта по .net из тебя не выйдет, попробуй блеснуть знаниями в разделе сферы.
Или реализовать tcp стек, на embedded, столько сразу умных вещей узнаешь.

Автор: Aimed 28.8.2021, 18:56

Цитата(nullptr @ 28.8.2021, 12:34) *

Увы, эксперта по .net из тебя не выйдет, попробуй блеснуть знаниями в разделе сферы.
Или реализовать tcp стек, на embedded, столько сразу умных вещей узнаешь.


smile.gif Ладно, лучше я тебя оставлю в покое, все таки что-то полезное делаешь. Ток в ЛС 1 вопрос хочу задать, очень уж интересно с кем имею дело.

Автор: nullptr 19.9.2021, 20:05

Новые релизы MUO, первым будут поддерживать возможность создания интерфейса без использования гампов.

https://vimeo.com/609102412

Автор: Aimed 22.9.2021, 22:08

Цитата(nullptr @ 19.9.2021, 19:05) *

Новые релизы MUO, первым будут поддерживать возможность создания интерфейса без использования гампов.

https://vimeo.com/609102412


А как же клиент?

Автор: nullptr 23.9.2021, 13:29

Цитата(Aimed @ 23.9.2021, 0:08) *

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

Движок https://github.com/c-smile/sciter-sdk
реализация под win 8 метров.

p.s: У меня нет особого желания, писать клиент дальше.
Было бы интересней это увидеть в Orion.

Автор: Aimed 24.9.2021, 3:15

Цитата(nullptr @ 23.9.2021, 12:29) *

Клиент на базе CUO выложу после тестов, в данный момент модифицировал стандартный протокол, что бы можно было получать данные без перегрузки формы ​и использовать привязки в react.

Движок https://github.com/c-smile/sciter-sdk
реализация под win 8 метров.

p.s: У меня нет особого желания, писать клиент дальше.
Было бы интересней это увидеть в Orion.


А ты договаривался с Тимуром что б он это в Орион внедрил?
А Андреа дал добро на пулл реквест в КлассикУО?

Автор: nullptr 24.9.2021, 11:48

Цитата(Aimed @ 24.9.2021, 5:15) *

А ты договаривался с Тимуром что б он это в Орион внедрил?
А Андреа дал добро на пулл реквест в КлассикУО?
Хотрайду, написал, как протестирую протокол после изменений, сделаю реквест.

Автор: nullptr 1.10.2021, 14:08

Исходники последней версии, на базе неё в дальнейшем будут создаваться, инструменты для администрирования сервера в основном репозитории.
https://github.com/nullptr-w8/ClassicUO

Видео работы, сервер можно взять из ветки ModernUO/webrender

[+]

Автор: Juzzver 1.10.2021, 17:39

Цитата(nullptr @ 1.10.2021, 14:08) *

Исходники последней версии, на базе неё в дальнейшем будут создаваться, инструменты для администрирования сервера в основном репозитории.
https://github.com/nullptr-w8/ClassicUO

Видео работы, сервер можно взять из ветки ModernUO/webrender
[+]


отлично smile.gif
Все стили поддерживаются или есть какие либо ограничения в текущий момент?
Как насчет подгрузки изображений для html разметки?

Автор: nullptr 1.10.2021, 17:57

Цитата(Juzzver @ 1.10.2021, 19:39) *

отлично smile.gif
Все стили поддерживаются или есть какие либо ограничения в текущий момент?
Как насчет подгрузки изображений для html разметки?
sciter-js, фигово работает с некоторые css селекторами, так что boostrap 4 не зацепить, остальное всё работает отлично. И ресурсы, лучше грузить не из cdn ибо чувствуется погрузка, (можно отдавать в body html или хранить на клиенте) Изображения можно записать в html в виде base64 и спокойно юзать.
Финальные тестовые утилиты
https://github.com/c-smile/sciter-js-sdk/tree/main/bin/windows/x32
usciter рендер, что бы проверить что работает, а что нет.

Русская версия Invision Power Board (http://www.invisionboard.com)
© Invision Power Services (http://www.invisionpower.com)