ВКонтакте

ui нового расширенного банка и склада

  • Автор темы Автор темы BadLuck
  • Дата начала Дата начала
Статус
В этой теме нельзя размещать новые ответы.
BadLuck

BadLuck

Участник ЗБТ
1. ВашеЛисичество
2. Описание предложения: доработать ui нового расширенного банка и склада.
3. В обновленном формате ориентироваться сложно. И дело не только в большой площади - размер почти одинаковый и в длину, и в высоту. Очень неудобно без дополнительных разделений на более локальные секторы, особенно если нужно найти что-нибудь быстро.
За годы игры в пв люди привыкли к вертикальной развертке хранилищ, поэтому хотелось бы предложить 2 пункта:
- сделать обычное открытие новых вкладок банка по старому - вертикально.
- дополнительное расширение с помощью новых итемов оформить как второе склеенное окно, оставив между ними заметную для зрителя спайку. На примере ниже я использовала для этого тайл боковой грани обычного банка. Так будет проще организовывать пространство, а разделитель визуально останется в логике общего внешнего вида.
bank.webp
 
Лучше бы увеличенный инвентарь починили и визуал там убрали который мешает крайний столбец использовать....
 
В принципе и самому можно и в таком квадрате расставить все по полочкам, но лишним не будет +
 
Давно не хватает какого то поиска что по инвентарю, что по банку. Разделение тоже будет неплохо +
 
Гусяо написал(а):
Давно не хватает какого то поиска что по инвентарю, что по банку. Разделение тоже будет неплохо +
Нажмите для раскрытия...
в этой версии игры это нереализуемо кажется из-за того что в ядре игры нет определения по названию предмета из-за переводов, потому что китайские друзья-разрабы оригинального кода нетрадиционной ориентации(там поиск по айдишникам, нужно будет делать переводчик текст-код-текст-запрос-код-ответ на каждый клик по клавиатуре), поэтому поиск будет так сильно фризить клиент что захочется выдрать себе вены
 
  • Удивление
Реакции: Sai
metazorg написал(а):
в этой версии игры это нереализуемо кажется из-за того что в ядре игры нет определения по названию предмета из-за переводов, потому что китайские друзья-разрабы оригинального кода нетрадиционной ориентации(там поиск по айдишникам, нужно будет делать переводчик текст-код-текст-запрос-код-ответ на каждый клик по клавиатуре), поэтому поиск будет так сильно фризить клиент что захочется выдрать себе вены
Нажмите для раскрытия...
оно и так фризит везде где можно..
по теме + но вряд ли реализуемо
 
metazorg написал(а):
в этой версии игры это нереализуемо кажется из-за того что в ядре игры нет определения по названию предмета из-за переводов, потому что китайские друзья-разрабы оригинального кода нетрадиционной ориентации(там поиск по айдишникам, нужно будет делать переводчик текст-код-текст-запрос-код-ответ на каждый клик по клавиатуре), поэтому поиск будет так сильно фризить клиент что захочется выдрать себе вены
Нажмите для раскрытия...
Откуда ты вообще берешь эту информацию?
images (3).webp
 
Ment написал(а):
Откуда ты вообще берешь эту информацию?
Посмотреть вложение 37804
Нажмите для раскрытия...
потому тебя это должно ебать и зачем ты мне во второй теме уже что-то предъявляешь?
даже не зная как это выглядит и что там есть внутри мне достаточно опыта в программировании на с++, чтобы сказать как бы оно было в консольном приложении, не говоря уже об игре в которой мало того что нужно отображать каждый кадр, так ещё и поверх этого всего обратится к базе данных и высрать запрос, но если тебе нужны детали, то давай я тебе разжую как для дошкольника:
1) каждый предмет в игре хранится в виде "15038" и имеет псевдоним
2) при нажатии на кнопку сортировки у тебя прям на этом сервере шары из коробки 1-8 сортируются не 1-2-3-4-5-6-7-8 а 1-2-3-4-5-7-6-8 из этого мы делаем вывод, что буквально вся бэкэндовая работа над шарами происходит по ID, а сортировка этот ID просто расставляет по порядку (в данном случае возрастания), потому что в старых версиях привязанные шары китайские разрабы 6 и 7 перепутали местами, иначе сортировка бы проходила по алфавитному порядку
+ ко всему, сортировка большого инвентаря на 150+ слотов занимает довольно большое время, а это по сути просто расстановка предметов по возрастанию, прикинь че будет если каждый предмет из 4) сравнивать по 2-3 раза?
3) ID предмета это по сути адрес на ряд, столбец и полку книги в библиотеке
4) если ты ищешь какой-то предмет ты:
I) ты вводишь букву "ш". Клиент отправляет GET-запрос на сервер:search?q=ш
II) сервер выполняет тяжелый SQL запрос: SELECT * FROM items WHERE name LIKE '%ш%' (ищет букву "ш" в любом месте названия) это грузит и процессор и базу данных
III) сервер возвращает тебе, скажем, 4000 предметов (все, где есть буква ш).
IV) ты еще не допечатал, а уже вводишь "а".
V) клиент отменяет предыдущий запрос (или игнорирует его) и шлет новый: search?q=ша
VI) сервер снова, не используя результаты прошлого поиска, лезет во всю базу и ищет LIKE '%ша%'.
VII) постоянные перезапуски тяжелых запросов создают фризы, потому что сервер тратит время на перебор текста, а эта операция ЗНАЧИТЕЛЬНО тяжелее чем просто вычитать хп из моба

мне впадлу парсить 60к вхождений из базы данных, можешь попросить условный chatgpt посчитать сколько времени займет 4), но я предсказываю что на каждое нажатие кнопки по клаве будет уходить минимум 2-3 секунды фриза
можешь ещё глянуть как работает strstr какой-нибудь который прям в плюсах сравнивает две строки, ахуеешь как это долго локально делается
есть вариант конечно каждый создавать локальную таблицу, хешировать её и проходиться по этому хешу каждый раз, когда происходит ввод символа, но для этого нужно сделать select * что займет секунды 2-3 времени и возможно(может быть, я хз оно так работает или нет) откроет уязвимость, поскольку будет интерфейс для SQL инъекции, но этот вариант будет работать почти моментально
 
metazorg написал(а):
потому тебя это должно ебать и зачем ты мне во второй теме уже что-то предъявляешь?
даже не зная как это выглядит и что там есть внутри мне достаточно опыта в программировании на с++, чтобы сказать как бы оно было в консольном приложении, не говоря уже об игре в которой мало того что нужно отображать каждый кадр, так ещё и поверх этого всего обратится к базе данных и высрать запрос, но если тебе нужны детали, то давай я тебе разжую как для дошкольника:
1) каждый предмет в игре хранится в виде "15038" и имеет псевдоним
2) при нажатии на кнопку сортировки у тебя прям на этом сервере шары из коробки 1-8 сортируются не 1-2-3-4-5-6-7-8 а 1-2-3-4-5-7-6-8 из этого мы делаем вывод, что буквально вся бэкэндовая работа над шарами происходит по ID, а сортировка этот ID просто расставляет по порядку (в данном случае возрастания), потому что в старых версиях привязанные шары китайские разрабы 6 и 7 перепутали местами, иначе сортировка бы проходила по алфавитному порядку
+ ко всему, сортировка большого инвентаря на 150+ слотов занимает довольно большое время, а это по сути просто расстановка предметов по возрастанию, прикинь че будет если каждый предмет из 4) сравнивать по 2-3 раза?
3) ID предмета это по сути адрес на ряд, столбец и полку книги в библиотеке
4) если ты ищешь какой-то предмет ты:
I) ты вводишь букву "ш". Клиент отправляет GET-запрос на сервер:search?q=ш
II) сервер выполняет тяжелый SQL запрос: SELECT * FROM items WHERE name LIKE '%ш%' (ищет букву "ш" в любом месте названия) это грузит и процессор и базу данных
III) сервер возвращает тебе, скажем, 4000 предметов (все, где есть буква ш).
IV) ты еще не допечатал, а уже вводишь "а".
V) клиент отменяет предыдущий запрос (или игнорирует его) и шлет новый: search?q=ша
VI) сервер снова, не используя результаты прошлого поиска, лезет во всю базу и ищет LIKE '%ша%'.
VII) постоянные перезапуски тяжелых запросов создают фризы, потому что сервер тратит время на перебор текста, а эта операция ЗНАЧИТЕЛЬНО тяжелее чем просто вычитать хп из моба

мне впадлу парсить 60к вхождений из базы данных, можешь попросить условный chatgpt посчитать сколько времени займет 4), но я предсказываю что на каждое нажатие кнопки по клаве будет уходить минимум 2-3 секунды фриза
можешь ещё глянуть как работает strstr какой-нибудь который прям в плюсах сравнивает две строки, ахуеешь как это долго локально делается
есть вариант конечно каждый создавать локальную таблицу, хешировать её и проходиться по этому хешу каждый раз, когда происходит ввод символа, но для этого нужно сделать select * что займет секунды 2-3 времени и возможно(может быть, я хз оно так работает или нет) откроет уязвимость, поскольку будет интерфейс для SQL инъекции, но этот вариант будет работать почти моментально
Нажмите для раскрытия...
Что ты несешь вообще? Хах, открой комку, посмотри на поиск, нажми кнопку и удивишься.
 
Ment написал(а):
Что ты несешь вообще? Хах, открой комку, посмотри на поиск, нажми кнопку и удивишься.
Нажмите для раскрытия...
в комке ничего не нужно сравнивать чтобы подсвечивать предмет
в комке ты вводишь слово и нажимаешь на кнопку поиска, когда у тебя уже есть готовая таблица и ты выбрал нужный айдишник тебе просто нужно вывести его, тебе не нужно проверять айдишники для 150 предметов и проверять их в прямом эфире, я тебе буквально привел пример с сортировкой в инвентаре
 
metazorg написал(а):
в комке ничего не нужно сравнивать чтобы подсвечивать предмет
в комке ты вводишь слово и нажимаешь на кнопку поиска, когда у тебя уже есть готовая таблица и ты выбрал нужный айдишник тебе просто нужно вывести его, тебе не нужно проверять айдишники для 150 предметов и проверять их в прямом эфире, я тебе буквально привел пример с сортировкой в инвентаре
Нажмите для раскрытия...
=)
В общем, пусть будет так.
 
metazorg написал(а):
потому тебя это должно ебать и зачем ты мне во второй теме уже что-то предъявляешь?
даже не зная как это выглядит и что там есть внутри мне достаточно опыта в программировании на с++, чтобы сказать как бы оно было в консольном приложении, не говоря уже об игре в которой мало того что нужно отображать каждый кадр, так ещё и поверх этого всего обратится к базе данных и высрать запрос, но если тебе нужны детали, то давай я тебе разжую как для дошкольника:
1) каждый предмет в игре хранится в виде "15038" и имеет псевдоним
2) при нажатии на кнопку сортировки у тебя прям на этом сервере шары из коробки 1-8 сортируются не 1-2-3-4-5-6-7-8 а 1-2-3-4-5-7-6-8 из этого мы делаем вывод, что буквально вся бэкэндовая работа над шарами происходит по ID, а сортировка этот ID просто расставляет по порядку (в данном случае возрастания), потому что в старых версиях привязанные шары китайские разрабы 6 и 7 перепутали местами, иначе сортировка бы проходила по алфавитному порядку
+ ко всему, сортировка большого инвентаря на 150+ слотов занимает довольно большое время, а это по сути просто расстановка предметов по возрастанию, прикинь че будет если каждый предмет из 4) сравнивать по 2-3 раза?
3) ID предмета это по сути адрес на ряд, столбец и полку книги в библиотеке
4) если ты ищешь какой-то предмет ты:
I) ты вводишь букву "ш". Клиент отправляет GET-запрос на сервер:search?q=ш
II) сервер выполняет тяжелый SQL запрос: SELECT * FROM items WHERE name LIKE '%ш%' (ищет букву "ш" в любом месте названия) это грузит и процессор и базу данных
III) сервер возвращает тебе, скажем, 4000 предметов (все, где есть буква ш).
IV) ты еще не допечатал, а уже вводишь "а".
V) клиент отменяет предыдущий запрос (или игнорирует его) и шлет новый: search?q=ша
VI) сервер снова, не используя результаты прошлого поиска, лезет во всю базу и ищет LIKE '%ша%'.
VII) постоянные перезапуски тяжелых запросов создают фризы, потому что сервер тратит время на перебор текста, а эта операция ЗНАЧИТЕЛЬНО тяжелее чем просто вычитать хп из моба

мне впадлу парсить 60к вхождений из базы данных, можешь попросить условный chatgpt посчитать сколько времени займет 4), но я предсказываю что на каждое нажатие кнопки по клаве будет уходить минимум 2-3 секунды фриза
можешь ещё глянуть как работает strstr какой-нибудь который прям в плюсах сравнивает две строки, ахуеешь как это долго локально делается
есть вариант конечно каждый создавать локальную таблицу, хешировать её и проходиться по этому хешу каждый раз, когда происходит ввод символа, но для этого нужно сделать select * что займет секунды 2-3 времени и возможно(может быть, я хз оно так работает или нет) откроет уязвимость, поскольку будет интерфейс для SQL инъекции, но этот вариант будет работать почти моментально
Нажмите для раскрытия...
lmao.
Я сначала хотел расписать тебе подробно почему и где ты неправ, но чёт подумал что ну его нафиг, бумага такого не выдержит.
Так что просто кратко - ты неправ, и практически во всём что ты написал.
Ты б понты поумерил просто, а то с твоего текста стойкое ощущение что ты по верхам нахватался и решил блеснуть знаниями.
Как говорится лучше помолчи, за умного сойдёшь
 
Здравствуйте!
Мы рассмотрели ваше предложение.

— Обдумаем над возможностью реализации текущего разделения


Благодарим вас за вашу идею!
 
Статус
В этой теме нельзя размещать новые ответы.
Назад
Сверху