[DEV] StormCore (Java WoW Emu)
 

Вот, решил начать писать emu пресловутой игры на Java, так как данная игра и язык представляют для меня большой интерес. Хочется совместить приятное с полезным и углублять свои знания в Java. Может кого-нибудь заинтересует моя задумка...
На данный момент удалось реализовать аутентификацию с реалм сервером.
Выкладываю исходники своего творения. Прошу строго не судить.

[HIDE="Устарело"]
Проект переехал с http://github.com/ШтормКоре в http://github.com/JMaNGOS
git clone git://github.com/JMaNGOS/storm.git

В данный момент проект storm заморожен.

UPDATE:
storm закрыт полностью все наработки перебрались в JMaNGOS
[/HIDE]

В свою очередь все наработки были перенесены в новый проект "JMaNGOS". И сейчас все работы ведутся над "JMaNGOS".
Проект http://github.com/JMaNGOS
git clone git://github.com/JMaNGOS/JMaNGOS.git

задумку поддерживаю. сделайте репозиторий.

Вот ссылка: git://github.com/stormcore/storm.git

stormcore =)

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

Спасибо большое за патч, но на тот момент была поддержка только для клиента 1.12.x.

А поддержку 2.4.3 и 3.3.5a я уже дописал в субботу, но забыл добавить во внешний репозиторий.
На данный момент я уже добавил.

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

to RomanRom2: спасибо за совет.

не за что. в рамках необходимой мне прокачки скилла java programming с удовольствием по принимаю участие. обращайся.
пока слежу только. но с пристрастием =)

насчет названия хотел только добавить: storm уже был - StormCraft. года 2005-2008 примерно. джаваэму звучало лучше. может быть wowjava, wowjmu, wowjava, wowjavemu... в общем не упускай слово java, можно будет обыграть с жабой потом в логотипах и дальнейших ассоциациях =)

JMaNGOS
я выбрал такой вариант =) т.к. по большей части, результат - это фактически повторное использование кода мангоса и его частей.

советую использовать
http://commons.apache.org/dbcp/
http://commons.apache.org/pool/
для фабрики соединений с БД, т.к. в любом случае понадобится более одного соединения с БД

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

ну это у кого как...
если у вас "опять началось в колхозе утро", то это утопия и мы это уже проходили с Delphin. я все же искренне надеюсь, что хоть кто то наконец сможет отойти от линейной объектной модели мангоса и подумать самому на начальном этапе. пока не поздно =)

хозяин - барин. в целом не важно, хоть "петухом" его назови, суть то не изменится. но с другой стороны, "как корабль назовешь, так он и поплывет" :yes3:

Delphin - Delphi? Поискал действительно пишут делфи...
А что вы называете "линейной объектной модели мангоса"?

Наследие демона XD

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

писали. сейчас давно уже не пишут.
изначально он назывался DelphEmu и сотворил его всем нам хорошо известный user456. потом присоеденилась банда и узурпировала власть =)))

моделью
то что происходило в TeamPython, то что происходило в wowd и его многочисленных форках, и то что происходит сейчас в мангосе. точнее то что происходило примерно года два-три назад, сейчас я потерял всякий интерес к кодам. не так давно, может полгода назад мельком заглянул снова (что то кому то показать и где то даже писал об этом, здесь на форуме) - воз и ныне там. заплатка на затычке, затычка на заплатке. патчами подгоняет. одно только ваше "карта в карте" для транспорта чего стоит :censored: началось конечно осторожное поползновение в сторону структурной объектной модели, но... слишком поздно :pardon:

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

Авось пригодится запрос на выборку всех текущих банов, что бы при коннекте пользователей не делать по 500 запросов с проверкой =)))

а где и когда такой запрос может пригодится?
плюс ко всему в нем же вложенный запрос, что соответствует 500 запросам один фиг, если парент и чайлд запросы возвращают много записей =)

при запуске логин сервера выбираем все текущие забаненные йп, в любом случае их будет не много...храним все в коллекции. При логине пользователя проверяем не из БД, а из коллекции, то есть экономия на одном запросе при логине...дает меньшую нагрузки на БД при массовых реконнектах ( перезапуске сервера)
вложенный запрос очень простенький... "WHERE unbandate > UNIX_TIMESTAMP()" отсекает все устаревшие...
запрос был бы попроще, если поле ip в бд было единственным ключем, а так из-за совместимости с БД мангос....
Кстати, а вот реалмлист хранится отдельно почему и бан лист не хранить?

to Minimajack: А если во время работы сервера на кого-нибудь повесить бан?

добавить в коллекцию и добавить в бд не? :pardon:

в общем есть контроллер BanIpController...при запуске сервера происходит инициализация (загрузка текущих банов)
при коннекте посредством этого контроллера проверяем наличие йп пользователя в списке банов
при бане используя этот контроллер добавляем бан в бд и коллекцию
при разбане удаляем из кол-ции и из бд

при всяких хз каких случаях есть метод reload...

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

Aven вроде-бы и сейчас что-то пишет там. Правда на канал заходил гдето с пол-года назад, он там был почти один )) (Еще паренек с ним, но видно Авен пишет один).

По поводу сабжа - ребята, как Рома сказал - ищите собственные пути развития. Это принесет вам и опыт и славу и главное - удовольствие от работы. От банального копипаста вы всего этого не получите. Ну переписали вы Мангос на яву - и что? :) А поиск собственных решений, возможно (при серьезном подходе) принесет значительно лучший результат нежели у ребят из Мангоса :yes3:

Быдлокод - это зло, боритесь с ним и не пытайтесь изобретать велосипед.

золотые злова, Юрий Венедиктович =)))

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

боже мой, ребята... какой бан-контроллер, какие хранимые функции...
флаг на аккауте banned в true и все. при логине все равно читаете данные аккаунта.

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

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

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

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

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

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

еще плюсом сюда можно приплеплести изобретение дополнительной ненужной фунциональности, типа бана подсетей. распыляемся на этом, получается ни там ни сям.

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

я изначально начал с того, что не надо копировать все с мангоса, там малина только сверху, внутри если приглядеться - :censored:
=)

Роман. К тараканам по оппкодам, сорри конечно что загаживая чужую тему.
Но есть ли у вас данные по флай системе классика с вашими гигами сниффов?
МЗ тугое в этом отношении. С флай там вообще глухотень.
Если конечно разобранных опкодов не жаль)

move flag = $300 - для полетов. и сплайн из нескольких точек в А9 и monster_move с обязательным дублированием последней точки два раза. флая в классике не было. больше ничего особенного.

ЗЫ. тему не загаживаем, а наполняем тематическим контентом =)

А что с хувером?
Парение на месте как было реализовано?

какие идеи по поводу DAO
работать интерфейсами моделей, реализацию брать у фабрики...
пример http://java.sun.com/blueprints/corej...essObject.html

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

ну вообще по феншую в джаве используют entity для доступа к базе.

Я тогда был после шашлыков с коньяком и хорошо помню только за наш разговор за Вада)) То что вспомнилось из детства XDXD
Из далеких лет.

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

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

А за повторный вопрос все-таки сорри)) На нетрезвую голову не все и упомниш)

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

to madlove: stormcore / authserver / ClientConnection.java
не до конца читаешь буфер...а именно структуру sAuthLogonProof_C, оставил не прочитанными 2 байта в буфере, а потом его обнулил...прокатило. Не уверен конечно, что клиент может посылать за раз несколько опкодов, но если такое возможно, то ты просто выбросишь кусок опкода(ов)...
да и вынеси с подвала четыре переменные связанные с srp6...теряются :pardon:

to Minimajack:
1. За раз читается один пакет, не читал два последних так как не использовал.
Сейчас буду переписывать обработку полученных пакетов и учту 2 байта.
2. Еще не определился с форматом кода. Может? Константы вверху поля внизу.

существует же стандарт на оформление java кода, разработанный и продвигаемый гуглом. eclipse и netbeans, например, используют его в своих автоформатилках. все интерфейсы класса нужно объявлять вверху, вначале файла. затем идет имплементация конструктора, затем методов.

В проекте уже лежит форматор кода "stormcore-formatting.xml" и используется в проекте. Про поля не согласен некоторые описываю вверху, а некоторые внизу.
Про конструкторы и методы бесспорно в такой последовательности.

согласен - не согласен... я говорю существует стандарт и имеет смысл его придерживаться.

как насчет структур? dbc, vmap ...
Гугль приводит к javolution Struct, но может просто конвертировать в хмл?

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

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