Как корректно фильтровать инвентарь [High Five 5]

[Projack]

Контекст:
- High Five p273
- xdat + interface.u(исходники с шары)



Пытаюсь сделать себе фильтр по предметам инвентаря, но сталкиваюсь с тем, что нужно костылить и держать дополнительный список итемов и постоянно обновлять его перед фильтрацией. Собственно отсюда вопрос.

Может есть нормальный способ обратиться к списку предметов персонажа, который лежит в основе InventoryItem(тот который обновляется сервером)? Поиск мне как-то не помог.

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

 

[xDarkDelux]

Нормальный - это как? InventoryItem - он же ItemWindow, в нем все предметы, что еще нужно?)

 

[default_npc]

Ну по моему там есть нативка:

native function RequestItemList();

которая запрашивает пакет с итемами. Хватит просто просить пакет и отсеивать его через условный InStr.

Ну или можно просто не дёргать сервер на каждый чих, а реально хранить всё в чём то вроде:

var array<ItemInfo> ItemList;

и работать уже с ним при поиске. Но так выйдет немного больше кода, + нужно его постоянно обновлять.

 

[Projack]

Нормальный - это как

Нормальный это минимизировать копирования. Т.е не хранить дополнительный itemlist, а обращаться к уже существующему, например, который мог бы храниться где-то на результат RequestItemList() и заполнять собой ItemWindow.
Я понимаю, что ItemWindow сам по себе контейнер, но верилось, что можно каким-то образом дотянуться до результата внутреннего запроса item list'a.

дёргать сервер на каждый чих

Этого конечно максимально не хочется)

Но так выйдет немного больше кода, + нужно его постоянно обновлять

Да, это то к чему все склоняет и это кажется костылем замедляющим работу клиента. У unrealscript 2 сам по себе медленный движок, как утверждает дока. А тут еще и копированием заполнять список.

Игрался сортировкой инвентаря и на неотсортированном массиве заметен фриз. Ладно там вписано(в тех исходах, что я смотрю) разбиение по группам айтемов и сортировка пузырьком(я её конечно заменил), но не фриз же при клике Фильтр конечно менее требовательный чем сортировка, как минимум там нет ужасных swap'ов. Но тоже может привести к видимым проблемам, особенно когда начинает действительно быть нужным(если инвентарь расширить до 350+ и забить по фул)

Чисто теоретически возможно ли найти место где хранится результат RequestItemList(), если конечно оно хранится глобально и расширить нативный API random access доступом? И вообще можно ли расширять API, чтобы иметь к нему доступ через unreal script? Там реверс nwindow.dll или чего-то в таком роде
Да что уж, если иметь возможность править, то просто расширить UItemWindowHandle интерфейс методами hide, show и научить их показывать - не показывать и вообще прекрасно

 

[default_npc]

Да нормально там всё у UC со подобным будет, даже 1к предметов не шибко проблема.


Я писал подобные поиски для гмов, когда есть портянка в 30к итемов, а потом они просеиваются по введённым буквам в реалтайме - слегка подтормаживает, но не слишком критично. А уж соткой-другой в инвентаре это вообще всё моментально.
Посмотри хотя бы какую херобору написали корейцы в новых клиентах и как там лагает инвентарь, так что я бы не парился.





Ну конечно можно. Пиши экстендер, можно в целом всё UC перебросить в сю и всё начнёт работать раз в 10 быстрее.

 

[Projack]

Эх хочется конечно, улучшать, а не ухудшать навороченное корейцами) Спасибо за идею окошка для GMов) Стандартный A+G item search подбешивает

можно в целом всё UC перебросить в сю

Не то чтобы у меня была куча свободного времени, но звучит соблазнительно никому не нужно, но соблазнительно

 

[MrKirill1232]

Вроде клиент при закрытии инвентаря или при соритровке высылает пакет "RequestSaveInventoryOrder", который можете подхватит и выстроить как угодно, ну и выслать item list потом.
Правда это вызовет сильный провис клиента.

 

[xDarkDelux]

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

 

[default_npc]

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

Так можно же сам итемвиндоу прогонять циклом и удалять по индексу то, что не совпадает с введённым. А при очистке поиска - запрашивать целиковый лист с пакета

Шило на мыло, такой же массив.

 

[Projack]

А при очистке поиска - запрашивать целиковый лист с пакета

А если стерли один символ?) Пока видимо так и остается вариант держать базовую копию списка и по ней фильтровать постоянно(ну можно оптимизировать и при увеличении количества символов фильтровать в itemwindow, а если символов меньше, то обратно по списку

 

[xDarkDelux]

Так можно же сам итемвиндоу прогонять циклом и удалять по индексу то, что не совпадает с введённым. А при очистке поиска - запрашивать целиковый лист с пакета

Шило на мыло, такой же массив.

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

А если стерли один символ?) Пока видимо так и остается вариант держать базовую копию списка и по ней фильтровать постоянно(ну можно оптимизировать и при увеличении количества символов фильтровать в itemwindow, а если символов меньше, то обратно по списку

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