запуск ядра java не через bat а через c#

[krisadr]

Ну так можно же сделать решение под веб \o/
Тут и кроссплатформенность, и гуй рисовать проще (имхо), и на родной джаве можно писать (а можно и не на джаве), и не нужен доступ к машине. И продавать проще будет

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

[shegan]

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

[krisadr]

ну чтож, спасибо) и пожелайте мне удачи) надеюсь я хоть в 4й раз доведу дело до конца)

[shegan]

Ну так есть смысл сделать бложик)
И людям интересно, и себе полезно.

[ProDev]

Что касается конфигов - я бы посмотрел в сторону embedded-конфигов - то есть зашивать все внутрь JAR + делать ext-параметры с override'ом. Посмотрите в папку ./config - в ней десятки файлов, а параметров на круг пару сотен наберется, а то и больше. А теперь можно прикинуть статистику - сколько пользователей использует более 10% из них? Я думаю, что их будет минимум. Обычно настраивают порты, СУБД параметры, рейты. Почему бы не избавить пользователей от ненужной рутины? Это очень удобно, лаконично и практично.

[KID]

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

сколько можно боятся итерировать тонны данных, нынешние железо-мощности позволяют это делать, а объемы оперативной памяти - все это складывать.
к примеру расчет расстояния по xyz одного объекта по отношению к 100 тыс других объектов занимает 167k нс. но в л2 все еще процветает сегментированный мир, а уж особо тяжелые расчеты с полигонами можно переложить на gpgpu. застрял движек л2 в прошлом.

[ProDev]

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

сколько можно боятся итерировать тонны данных, нынешние железо-мощности позволяют это делать, а объемы оперативной памяти - все это складывать.
к примеру расчет расстояния по xyz одного объекта по отношению к 100 тыс других объектов занимает 167k нс. но в л2 все еще процветает сегментированный мир, а уж особо тяжелые расчеты с полигонами можно переложить на gpgpu. застрял движек л2 в прошлом.

Насколько же в точку! Полностью согласен. Сюда же я бы добавил борьбу за каждую наносекунду в каких-то мелочах (вспоминаем кастомные коллекции от ArrayList'a с перестановкой членов) и ряд других know-how. Все это, безусловно, здорово, вот только в то же время почему-то проблемы архитектурного уровня никто не упоминает. То, что большая часть застряла в прошлом - факт. Причем во многом, начиная с таких самых банальных вещей как логирование. Я думаю, что вся проблема в нежелании ковыряться к недрах и что-либо рефакторить. Прошло уже десять лет, пожалуй, а в тех же L2PcInstance/Player классах по 10+к строк и ничего не меняется, совсем

[Awakardia]

удачи, думаю у вас всё получится

[krisadr]

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

Добавлено через 12 минут

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

сколько можно боятся итерировать тонны данных, нынешние железо-мощности позволяют это делать, а объемы оперативной памяти - все это складывать.
к примеру расчет расстояния по xyz одного объекта по отношению к 100 тыс других объектов занимает 167k нс. но в л2 все еще процветает сегментированный мир, а уж особо тяжелые расчеты с полигонами можно переложить на gpgpu. застрял движек л2 в прошлом.

Блин потому что такой уж у меня принцип, зачем засирать железо методами, без которых можно обойтись, если чуть сильнее напрячь извилины? Ну не нравиться мне как все это визуально выглядит код коннекта к мускулу и вообще не нравиться мне мускул. Мое право) если до меня когда нибудь дойдет что мускул был рациональнее и удобнее, ну что поделать. За то уж попробую. Всего сразу не учтешь. Еще не нравиться что для единичных объектов почти не используют статик классы. ООП все дела но блин все в программировании должно все быть логично. И убивает что на каждый блин пакет тоже создают объект... На мой взгляд вообще бессмысленно.

[ProDev]

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

Добавлено через 12 минут

Блин потому что такой уж у меня принцип, зачем засирать железо методами, без которых можно обойтись, если чуть сильнее напрячь извилины? Ну не нравиться мне как все это визуально выглядит код коннекта к мускулу и вообще не нравиться мне мускул. Мое право) если до меня когда нибудь дойдет что мускул был рациональнее и удобнее, ну что поделать. За то уж попробую. Всего сразу не учтешь. Еще не нравиться что для единичных объектов почти не используют статик классы. ООП все дела но блин все в программировании должно все быть логично. И убивает что на каждый блин пакет тоже создают объект... На мой взгляд вообще бессмысленно.

Боюсь, что все упрется в рефакторинг. Посмотрите любой код (что l2j, что оверов и код поверх них) - сервисного слоя как такового нет - логика распихана (по-другому не скажешь) везде, от пакетов до модели. То есть что-то происходит в пакетах (в том числе и DAO, которого, как отдельной сущности, не существует), и в модели (см. Player/L2PcInstance), и еще где-то. Как следствие, связанность кода зашкаливает, рефакторинг превращается в целое приключение. Добавим сюда использование Reflection + Concatenation и эти бессмысленные на 90% скрипты - все, отрефакторить что-то становится целым приключением. Ваша IDE банально не увидит некоторые зависимости и проблемы начнутся уже на простом rename/move. Я думаю, это причина №1 движения по накатанной. Из всего, что я видел, только команда JTS, которая продавала код HF отдельно, пошла по правильному пути и развязала этот узел (хотя бы судя по структуре проекта, но, думаю, где-то так оно и есть).