Все объекты в l2jserver

[parrx]

Хроники

1. Infinite Odyssey

Исходники

Присутствуют

Сборка

l2jserver

Всем привет

кто нибудь может ткнуть как в l2jserver сборках реализовать поиск по всем игрокам\нпц
на лост\овер сборках

for(Player player : GameObjectsStorage.getPlayers())
{
    //
}

а вот в лыже подобной что то не могу придумать как это сделать

 

[LifeGame32]

Всем привет

кто нибудь может ткнуть как в l2jserver сборках реализовать поиск по всем игрокам\нпц
на лост\овер сборках

for(Player player : GameObjectsStorage.getPlayers())
{
    //
}

а вот в лыже подобной что то не могу придумать как это сделать

for (L2PcInstance p : L2World.getInstance().getPlayers())
{
}
for (L2Object obj : L2World.getInstance().getVisibleObjects())
{
}

 

[Solution]

Можно все сделать ещё гараздо проще и понятнее в плане кода если пару вечеров покурить инфу по стримам и ещё парочку попрактиковаться

 

[Fred1]

Можно все сделать ещё гараздо проще и понятнее в плане кода если пару вечеров покурить инфу по стримам и ещё парочку попрактиковаться

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

 

[Solution]

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

За бесплатно я наталкиваю человека что б сделал сам, так же и в посте выше, я указал что почитать

 

[4ipolino]

Solution, мне одному не понятно куда уже проще? И так дан пример полного перебора хранилища в цикле.

 

[Desquire]

Мне одному кажется это бредом гонять в цикле все персов или т.п.?

 

[4ipolino]

Мне одному кажется это бредом гонять в цикле все персов или т.п.?

Каким другим способом сделать выборку или отправить всем запрос\сообщение ? Что бы не использовали - внутри метода будет цикл.

 

[Desquire]

Что возвращает L2World.getInstance().getPlayers() я не знаю.
Визуально, похоже что возвращает массив обьектов игроков.
Если это так, то там врядли тянется пару таблиц, + идет всякие доп. условия при загрузке.
У каждого же чара есть уникальный ид, по которому и можно все загрузить.
Для перфоманса будет лучше загрузить только список игроков, по определенным критериям, и позже уже загрузить всю необходимую инфу.

 

[LifeGame32]

for (L2PcInstance p : L2World.getInstance().getPlayers()) // только игроки которые на данный момент в мире
{
}

for (L2Object obj : L2World.getInstance().getVisibleObjects()) // все игровые объекты в мире на данный момент игроки нпс предметы петы двери
{
}

 

[4ipolino]

Что возвращает L2World.getInstance().getPlayers() я не знаю.
Визуально, похоже что возвращает массив обьектов игроков.
Если это так, то там врядли тянется пару таблиц, + идет всякие доп. условия при загрузке.
У каждого же чара есть уникальный ид, по которому и можно все загрузить.
Для перфоманса будет лучше загрузить только список игроков, по определенным критериям, и позже уже загрузить всю необходимую инфу.

Ничего грузить в данном случае не надо. Мы получаем список плееров\обектов из уже загруженного хранилища.
Ничего нового в данном случае не придумать.

    private static final Map<Integer, Player> PLAYERS = new ConcurrentHashMap<>(Config.MAXIMUM_ONLINE_USERS);

    public static Collection<Player> getPlayers()
    {
        return PLAYERS.values();
    }

 

[Desquire]

Ничего грузить в данном случае не надо. Мы получаем список плееров\обектов из уже загруженного хранилища.
Ничего нового в данном случае не придумать.

    private static final Map<Integer, Player> PLAYERS = new ConcurrentHashMap<>(Config.MAXIMUM_ONLINE_USERS);

    public static Collection<Player> getPlayers()
    {
        return PLAYERS.values();
    }

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

 

[Rozhek]

Ну вообще для конкретных задач можно в сторадже отдельную мапку создавать и хранить. Там же есть разные мапки, для игроков/для нпц/все объекты вообще. Просто настройте ее пополнение/очищение.
Если нужно что то забродкастить всем игрокам раз в 10 лет, ничего страшного если пройдёт цикл из 500 итераций в getplayers.
Но вот если вы часто перебираете все объекты getvisibleobjects, которых в мапке 100 тыс лежит - предметы и нпц и плееры и Петы. А метод просто фильрует 100 тыс по признаку видимости и выдаёт результат - это не очень то хорошо)

 

[Rovskoi]

Что возвращает L2World.getInstance().getPlayers() я не знаю.
Визуально, похоже что возвращает массив обьектов игроков.
Если это так, то там врядли тянется пару таблиц, + идет всякие доп. условия при загрузке.
У каждого же чара есть уникальный ид, по которому и можно все загрузить.
Для перфоманса будет лучше загрузить только список игроков, по определенным критериям, и позже уже загрузить всю необходимую инфу.

простите, отвлекли перед отправкой, а за это время ребята выше ответили

Спойлер

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

Для поднятия всех плееров с базы должен быть метод где-то в DAO прослойке, соответственно если нужно поднимать все референсы то логично будет вытащить всех плееров, после ОДНИМ запросом вытащить остальные референсы через obj_id in (1,2,3,4, ..., n). Тем самым будет минимальное кол-во запросов в базу. (Делать кверю с обращением в референсные таблицы для каждого плеера из базы - очень плохая идея, но это только при условии массового поднятия плееров)

 

[Rozhek]

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

 

[Desquire]

простите, отвлекли перед отправкой, а за это время ребята выше ответили

Спойлер

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

Для поднятия всех плееров с базы должен быть метод где-то в DAO прослойке, соответственно если нужно поднимать все референсы то логично будет вытащить всех плееров, после ОДНИМ запросом вытащить остальные референсы через obj_id in (1,2,3,4, ..., n). Тем самым будет минимальное кол-во запросов в базу. (Делать кверю с обращением в референсные таблицы для каждого плеера из базы - очень плохая идея, но это только при условии массового поднятия плееров)

На счёт SQL- он зачастую быстрее. Если правильно индексы выставить...

 

[Rozhek]

На счёт SQL- он зачастую быстрее. Если правильно индексы выставить...

Запрос в rdbms быстрее чем взятие объекта из оперативной памяти ? Вы наверное что то перепутали)

 

[kick]

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

 

[Rovskoi]

На счёт SQL- он зачастую быстрее. Если правильно индексы выставить...

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

 

[Rozhek]

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

Для подобных задач в Java 8 введены stream. И такая задача решится так listItem1.stream().filter(listItem2::contains).collect()
. При этом не происходит итераций цикла в цикле, стрим не так немного работает.
Но можно и Джойн сделать в бд. Но если переносить туда подобный функционал, бд как слабое место может начать тормозить работу приложения. Особенно если не заложена асинхронность работы такого функционала. И тут уже понадобится hibernate, и простой процесс превратится в сложный.