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

[krisadr]

Дабы не разводить демагогию зачем и почему - спрошу сразу, возможно ли подручными способами перехватывать вывод лога из ядра java и засовывать допустим в textbox того же visualStudio? (чтобы вместо консоли использовался textbox)

и пользуясь случаем - как на ваш взгляд, замена mysql на сериализацию экземляров, это совсем бредовая идея?) (поддержка сайта, статистики не интересует)

[shegan]

Дабы не разводить демагогию зачем и почему - спрошу сразу, возможно ли подручными способами перехватывать вывод лога из ядра java и засовывать допустим в textbox того же visualStudio? (чтобы вместо консоли использовался textbox)

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

и пользуясь случаем - как на ваш взгляд, замена mysql на сериализацию экземляров, это совсем бредовая идея?) (поддержка сайта, статистики не интересует)

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

[krisadr]

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


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

Может в других проектах mysql и используется как полноценная бд, но только не в эмулях l2. Сколько не смотрел, ни искал связи в бд, так ничего и не нашел. Все логика и структура прописана в самом коде, так что могу с 90% ой увереностью сказать, что да тут мускул используется тупо для хранения данных. Ну может исключением является отсутствие дубликатов primary key. И да спасибо за разъяснение что такое сериализация, не знал XD. Так почему бы не увеличить скорость чтения\записи в разы?

ps. про перенос вывода напрямую в текстбокс так и нет( ну что же сделаю пока что тупо парсер log.txt

pss. бога ради остановите меня серьезными аргументами если я совсем заблуждаюсь

[ProDev]

Может в других проектах mysql и используется как полноценная бд, но только не в эмулях l2. Сколько не смотрел, ни искал связи в бд, так ничего и не нашел. Все логика и структура прописана в самом коде, так что могу с 90% ой увереностью сказать, что да тут мускул используется тупо для хранения данных. Ну может исключением является отсутствие дубликатов primary key. И да спасибо за разъяснение что такое сериализация, не знал XD. Так почему бы не увеличить скорость чтения\записи в разы?

ps. про перенос вывода напрямую в текстбокс так и нет( ну что же сделаю пока что тупо парсер log.txt

pss. бога ради остановите меня серьезными аргументами если я совсем заблуждаюсь

Неверное утверждение. WHERE CAUSE - весомый довод? Например, самый банальный вывод онлайна (для тех, кто еще до сих пор берет его из БД, а не через API) - SELECT... WHERE online = 1. Как вы это на файлах будете реализовывать?

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

Вот чего действительно стоит опасаться, так это таблиц KEY-VALUE. Если речь о HF - посмотрите в сторону ServerVariables, вот уж поле для рефакторинга.

[krisadr]

Неверное утверждение. WHERE CAUSE - весомый довод? Например, самый банальный вывод онлайна (для тех, кто еще до сих пор берет его из БД, а не через API) - SELECT... WHERE online = 1. Как вы это на файлах будете реализовывать?

писал же еще в самом начале. (поддержка сайта, статистики не интересует) - это все будет делаться отдельно через самописный java-webserver и апплеты

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

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

Не проверял, но думаю врятли l2jserver такие дураки чтобы к саббу привязывать персонажа.
зачем тут связи в бд? переменная в class Player - subbclassId.
И все - новый персонаж, естественно будет другой subbclassId.(а не в class Subbclass (playerObjId))

[KID]

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

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

зы.
перехват console.out для отрисовки его в textBox'e - вот это действительно импрувмент для повышение скорости, вот реально для чего это свистоперделка? гуй для сервер лянчера?XD

статистика

очень зря что вы ею пренебрегаете

[krisadr]

перехват console.out для отрисовки его в textBox'e - вот это действительно импрувмент для повышение скорости, вот реально для чего это свистоперделка? гуй для сервер лянчера?XD

статистика

очень зря что вы ею принебрегаете

в точку) гуй), на скорость сервера влияние его будет минимальным, ибо работать будет отдельно. а с java gui я не дружу ну ни как. Может потому что среды разработки удобнее чем visualstudio я не найду. Мне к тому же надоела концепция текстовых конфигов, в идеале их тоже бы туда зафигачить, и внедрять напрямую в среду выполнения, но мне кажется это уже слишком извращенно xD + сделать онлайн вывод статистики серверной нагрузки и в графиках тд и тп (для администрирования.)

по поводу статистики - собираюсь писать свой api для этого дела - выше уже описывал, я ей не принебригаю, просто откладываю, ибо объем работ огромен, и не до статистики сейчас. Благо есть время, энтузиазм, деньги, и пока что уверенность что в этом нуждаются ^^. Много кто говорит эмули гав*о, то гав*о се гав*о, но не многие решаются взять блин и переписать все с нуля, заранее сделав схему объектов, и логики их обработки, поддерживая модульность и самое главное - KISS. Вот собственно мои мотивы. Можете смело поливать грязью

ps. Да к тому же знаю что это такое, сам уже не первый раз пробую переписать. Как раз таки последний раз бросил это дело потому что зае*бался с mysql ом, тогда меня хватило на 2 месяца.

[shegan]

Может в других проектах mysql и используется как полноценная бд, но только не в эмулях l2. Сколько не смотрел, ни искал связи в бд, так ничего и не нашел. Все логика и структура прописана в самом коде, так что могу с 90% ой увереностью сказать, что да тут мускул используется тупо для хранения данных. Ну может исключением является отсутствие дубликатов primary key. И да спасибо за разъяснение что такое сериализация, не знал XD. Так почему бы не увеличить скорость чтения\записи в разы?

ps. про перенос вывода напрямую в текстбокс так и нет( ну что же сделаю пока что тупо парсер log.txt

pss. бога ради остановите меня серьезными аргументами если я совсем заблуждаюсь

TL;DR

Использование RDB в эмулях - так исторически сложилось. Перенос на другую модель хранения данных - затратно и цели не совсем ясны.
Если уж с нуля делать - то может оно того и стоит.

Я рад, что у нас совпадает видение на то, что такое "сериализация"
Хоть уже до меня высказались по этому поводу, и я согласен с этими точками зрения, все-таки вставлю 5 копеек.
Пока в запросах есть "WHERE" - реляционная модель актуальна, и уж точно для нынешний реализаций эмулей ладвы, пусть я знаком с их малым количеством.
Пока актуальны запросы типа "хочу чаров из такого-то клана", "хочу инфу о маноре из такого-то замка" и т.п. В случае с RDB достаточно написать запрос.
А как это организовать путем сериализации объектов и хранении их в каком-то кеше?
Или для каждой нынешней сущности, пусть для самой маленькой, потребуется сделать кеш (я о хранилищах key-value). Плюс связями придется очень вручную руководить, что может породить много ошибок.
Или если эти сущности будут вложенные, то кешей будет меньше, но для поиска этих самых маленьких сущностей придется делать SomeCache.getInstance().getAll() и бегать по этим всем сущностям, делая проверку тонны условий.

[krisadr]

всегда было интересно зачем пораждать объект, если он используется ТОЛЬКО в единичном экземпляре.(SomeCache.getInstance().getAll()) почему бы его не сделать static, с блокировкой при чтении\записи.

[shegan]

в точку) гуй), на скорость сервера влияние его будет минимальным, ибо работать будет отдельно. а с java gui я не дружу ну ни как. Может потому что среды разработки удобнее чем visualstudio я не найду. Мне к тому же надоела концепция текстовых конфигов, в идеале их тоже бы туда зафигачить, и внедрять напрямую в среду выполнения, но мне кажется это уже слишком извращенно xD + сделать онлайн вывод статистики серверной нагрузки и в графиках тд и тп (для администрирования.)

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