Kst

Мы, (Kara-Online отныне magicsea) заинтересованы в развитии сообщества и давно предлагали передать нам его с целью развития и поддержания интереса к приватным серверам. Если бы передали, проблем с финансами, наработками не испытывали бы. Соберите план развития, обозначьте сумму и мы поддержим. А просто ежегодно скидывать на лицензию, без особых стараний со стороны администрации развить сообщество - такое себе

стрелочка снизу открывает и скрывает чат, но коммуникацию в пвп планируем сделать войсом с каналами (отряд/гильдия/общий) и отправку аудиосообщений в чат

Hi my friend You can write in English. We are going to work with people from different city, so our team is learning English. We'll use google translate if we don't understand you Thank you for your feedback.

а анимация где?

C# прост, да согласен C++ войдет в шарп быстро, а поймет ли он функциональность dotnet'a так, чтобы поддерживать на равне с плюсами не могу даже догадываться, т.к не работал. Если вы считаете что он прост и плюсовик легко за 1-2 дня разберётся, спорит не буду, поверю на слово. Но для меня это было бы странно) Основная кодовая база C++, а сервер на C#. Надо понимать, что тогда нужно повторять остальной код предназначенный для обеих сторон с C++ на C#. Мне кажется переводить сервер на C# из-за одного dotnet'a это серьёзный шаг) Имейте ввиду что за собой нужно тянуть odbc, libdbc, common. Последующая доработка может усложнить работу) А всё ещё усложнится в GameServer'e, где есть LUA, который может с сетью работать. Мне кажется вы не видите множество других проблем, рекомендую хорошо подумать. Сделаете, поймёте что придётся много дорабатывать, закончится свободное время и бросите проект. Имели мы опыт, когда приглашали C++ разраба специально на работу с серверами. Оказалось что человек хорошо знает Java и вообще раньше писал сервера на Java. Как только он меня не уговаривал переписать сервера на Java, аргументы типо быстрее, лучше, безопаснее да и вообще это круто отлетали быстро из-за простой бизнес модели о которой я говорил выше. Открывать вакансию в штате на должность, где у человека только 1 узконаправленная работа (сервер) - глупо, либо всё переписать на Java, либо придерживаться одной кодовой базы, чтобы доработка была проще. В соло весь проект не потащишь, а как начинаешь расширять команду появляется вопрос порога вхождения, требования и заработной платы. Брать C++ разраба с задачей идти разобраться с C#? Думали над этим, но пока не собираемся. Я бы не назвал основные города непрерывными, там нету караванов или других мероприятий. Только данжи, которые тоже нельзя назвать непрерывными. А даже если они и были, дамп слепка игрового мира и его загрузка с доп. логикой решит проблему непрерывности.

Ну и по поводу DDos, защищать его на серверной стороне нынче глупо, ИМХО. Шаблонные TCP фильтры отобьют 90% атак различных стрессеров, остальные 10% нужно вкладывать в специфичный софт на стороне роутера и логику самого микросервиса коим наша пиратия и является (Gate, Group, Account, Game). Чтобы банально каждое новое подключение не вызывать конструктор на фулл класс клиента и закрывать общий пул мьютексом, а при большом количестве подключений распределять нагрузку между 2 и более первыми точками входа (Gate) через какой-нибудь load-balancer. Рекомендую посмотреть очень интересный ролик про микросервисную архитектуру World Of Tanks К слову мы в своё время переписали все сервера ( почти)) Гейм остался ) и запихнули их в докер и дальше в кубер с настройкой авто-скейлинга. Любой трафик просто распределиться между всем. Останется только 1, переписать гейм сервер чтобы не 1 карта - 1 гейм, а по координатам, с автозапуском если в эту локацию кто-нибудь заходит. И сервера готовы выдержать десятки тысяч клиентов. P.s на любом языке Но давать + dotnet'у за отражение DDos атак, такое себе))

свои небольшие пять копеек вставлю: 1. libdbc - по идеи 3rdparty library, которая должна быть и тут и там. При доработке сетевой части клиента - отдельно дорабатывать C# сервер.. Иметь C++ и C# разраба (если ты сам не делаешь и то и то) в штате в таком случае глупо, унификация кода экономит деньги и время. 2. Non boost asio - https://think-async.com/Asio/ 3. Мы перенести libdbc на linux и уже давно оттестировали. Всего 35 #ifdef _WIN32 во всём libdbc (включая udp сокет), при этом 8-15 - это отключить дебильный WSA от WinAPI. Буквально фулл день с тестами и последующие мелкие фиксы в процессе работы. Такой текст в защиту C# может написать только тот кто работал с dotnet долгое время и доверяет этой библиотеке. Тут осуждать считаю глупо, каждый Д**чет как он хочет ))

У тебя есть опыт работы с кроссплатформенными приложениями? Линукс хотя бы. Каждый новый стандарт сразу не выходит стабильным под все компиляторы, мы у себя в проекте используем 17 стандарт и абсолютно себе ни в чем не отказываем. Функции реализованные в STL не сразу адаптируются и под все платформы тоже. К примеру filesystem под MacOS отсутствует. Баги тоже не сразу исправляются, к примеру в MSVC sizeof(std::vector<int>) между debug и release под 17 стандартом имеет разные показатели, а в mingw, clang и gcc всё ок. Адаптация под gcc старого формата 6-8 тоже не обходится без танцев с бубнем и поиска аналогов в других STL функциях А если потащишь какую-то готовую либу с STL'ем, скомпилированную где-то там, под каким-то другим компилятором и когда появятся неизвестные крашики ещё больше появится отвращения к STL) Готовые библиотеки собранные под STL и имеющие API методы использующие в аргументах этот STL как-нибудь std::string на разных компиляторов разных версиях будет обрабатывать регистры по разному. По этому смотри осторожней с готовыми библиотеками где есть зависимость от STL, лучше тащи в проект как исходники и собирай сам, а соберётся ли она на каком-то gcc6-8? или MinGW, уже будет вопросом и новым квестом)) Я не пытаюсь вызвать какой-то холивар в чатике, просто когда вижу что разработчики бегут за цифрой не смотря на возможные баги и проблемы STL, хочется предупредить о возможных проблемах. P.s никто не мешает работать в VS2022 и использовать 14, 17 стандарт) А ещё больше советую обратить внимание на IDE CLion или хотя бы модуль Resharper в студии, очень сильно поможет, автоматический рефактор исходного кода хорошо поможет) Друг мой, goto это мелочи)) после трёх лет рефактора всего этого китайского гавна меня уже ничего удивляет)) Как захочешь перевести на mingw или gcc, сразу увидишь много интересного)) using namespace std в header'e, диффы между #define max / #define min с std::max / std::min, call jack в ассерте, копирование структур во рендере/фрейм (MindPower3D рендер эффектов). Это только начало

А почему STL 20? Вроде нету там чего-то того что необходимо, думаю 14 там за глаза, не надо гнаться за цифрой, больше проблем будет. Рекомендую начать с адаптации исходного кода под CMake. Мы переписывали Gate, Group, Account базируясь на том же lidbc, могу сказать что если его чуть подшаманить (семфор и мьютексы перекинуть), то работать можно, не советую переписывать всё глобально, там очень много китайщины от которой не знаешь чего ожидать. Рекомендую обратить внимание на наше опенсурсное решение клея между lua и cpp https://github.com/Alex2772/cpp_lua_glue, что-то типо sol2, но хеадер онли и с дикой абстракцией с шаблонами. Используем у себя клиенте самые последние коммиты, дорабатываем часто. Желаю удачи, надеюсь хоть кто-то на этом форуме потратит своё собственное время в пользу комьюнити.

Предлагаю данные замечания внести в публичный репозиторий https://github.com/PKO-Community-Sources/ClientSide-Sources/blob/bebbf1b7ea45de3ba56b137b4a4cc3e90a1e28d0/Engine/sdk/src/MPResManger.cpp#L1959

Хорошая сборка, удачи

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

Разработчики Пиратии допустили ошибку в самом коде. В своём клиенте, когда столкнулись с ней, отдебажили и исправили.

Пиратия работает на DirectX 8, которую давно не обновляют

Ну, как скажешь, к сожалению помочь ничем не могу.