DigitalOneThe (25 мая 2023 - 21:48) писал:
Нажмите сюда, чтобы прочитать это сообщение. [Показать]
У меня должно быть что то типа такого?
stock ShowFurnitureListDialog(playerid) {
if (!Iter_Count(iFurniture))
return SCM(playerid, -1, "На сервере нету мебели.");
new dialog_string[47+(29+(11)+(20)+(MAX_PLAYER_NAME))*MAX_FURNITURE_ON_PAGE+1] = "{bcbcbc}ID Object:\t{bcbcbc}Количество:\n";
new page = GetPVarInt(playerid, "pVar__FurniturePage");
new start = GetPlayerFurnitureListLastIndex(playerid, page);
if (start > Iter_Count(iFurniture)) {
page = -1;
if (page < 0) return 0;
SetPVarInt(playerid, "pVar__FurniturePage", page);
start = page * MAX_FURNITURE_ON_PAGE;
}
new end = start+MAX_FURNITURE_ON_PAGE;
if (end > Iter_Count(iFurniture)) {
end = Iter_Count(iFurniture);
}
new idx = -1;
//new lastIdx = g_player_furniture_list[playerid][page][PBL_INDEX] - 1;
foreach(new i: iFurniture) {
if (strcmp(eFurniture[i][eFurniture_Owner], pName(playerid))) {
printf("continue: %d", i);
continue;
}
SetPlayerFurnitureListIndex(playerid, page, ++ idx, i);
if (++idx < start) continue;
if (idx >= end) break;
//printf("g_player_furniture_list[playerid][%d][PBL_INDEX][%d] = %d", page, idx, i);
format(dialog_string, sizeof(dialog_string), "%s{ffd966}%d\t{3d85c6}%d\n", dialog_string, eFurniture[i][eFurniture_OBJ], eFurniture[i][eFurniture_Count]);
}
if (Iter_Count(iFurniture) > MAX_FURNITURE_ON_PAGE) {
if(end < Iter_Count(iFurniture))
{
strcat(dialog_string, "\n{93c47d}>>>\t\t");
}
if(page)
{
strcat(dialog_string, "\n{f44336}<<<\t\t\n");
}
}
return SPD(playerid, dFurniture_ListMain, DIALOG_STYLE_TABLIST_HEADERS, "Список вашей мебели", dialog_string, "Выбрать", "Закрыть");
}
Теперь давай сравним логику работы твоего и моего кода. Начнём, наверное, с твоего: Переменная start хранит максимально доступный идентификатор на последнем из индексов. Собственно, интуитивно, не сложно догадаться. Потом идёт проверка на то, не является ли последний из индексов больше, чем количество имеющейся мебели на сервере(хотя, к слову, это крайне субъективный итератор, который, судя по всему, обязан хранить всеобщее количество мебели, но не мебели конкретного дома). Смоделируем ситуацию: всего имеется 20 элементов(от 0 до 19) и, выходит так, что если последний элемент(19) не равен 20, а это оно так и будет, то конца мы не достигнем. Так или иначе, не до конца ясно, к чему делается такое, ибо, кроме того, сама по себе логика выполняющегося блока сформирована неправильно и он не выполнится вовсе. Разберёмся, в чём же основная проблема: если всё же условие каким-то загадочным образом сработает, то переменной, хранящей текущую страницу игрока, будет присвоен -1 и, в свою очередь, исходя из второй проверки(if(page < 0)), мы вернём нуль, тем самым выйдем из функции, прекратив последующую обработку. Переменная end, в то же время, имеет результат, исходя из суммы переменной start и директивы MAX_FURNITURE_ON_PAGE. А теперь опять представь ситуацию: start равен 19, прибавляем к нему MAX_FURNITURE_ON_PAGE(допустим, она равна 20) и получаем 39. Казалось бы, ничего такого, проитерируемся до 39. Но, у нас ведь элементы могут быть размещены далеко не в последовательном порядке. То бишь, вполне себе может быть суммарно 40 элементов, но, если первые 20 могут иметь индексы, начиная от нуля и до 19, то остальные 20, могут быть, скажем, в диапазоне от 40 до 60 или воообще, размещены в хаотичной последовательности(то есть, не по порядку). И выходит так, что если исходить из запрограммируемой тобою логики, мы можем не получить соответствующие числа. О проверке, находящейся ниже создания переменной end я вообще молчу, потому что она не сумеет спасти никоим боком от вышеописанного. Подходим к основной части, а именно к циклу, получающему идентификаторы из контейнера. Проверка, проверяющая то, принадлежит ли мебель игроку работает соответствующим образом(хотя, не до конца ясна архитектура массива eFurniture, хранящего мебель дома. В данном случае нужно чётко спроектировать массив, что, конечно же, не так уж и сложно. Если взять во внимание тот факт, что максимальное количество мебели на дом известно, то, в соответствии с этим, можно поступить следующим образом: максимальное количество домов | максимальное количество мебели для дома. Потом, при загрузке мебели, столбец, отвечающий за id дома, будет выступать индексом для доступа к первой мере массива и, в свою очередь, столбец, отвечающий за позицию текущей получённой мебели, будет выступать индексом для доступа ко второй из них. Либо, если не хочется выделять под это всё дело, можно привязать получённые метаданные непосредственно к созданному объекту мебели(о данной вещи я упоминал вчера, когда затрагивал функции, оперирующиеся датой в Streamer'e)) и, в то же время, функция SetPlayerFurnitureListIndex тоже, присваивая последнему автоинкрементируемому индексу значение, находящееся в контейнере IFurniture(с ним тоже не до конца понятно, ибо какой предмет туда попадает - я не знаю, от слова совсем. Вчера помню, что туда попадал первый из доступных слотов того же таки контейнера, потом Ты изменил на то, чтобы туда попадал непосредственно идентификатор мебели в базе данных. До конца неизвестно, что тебе по итогу нужно). Но далее начинается сюрреализм: кроме того, что ты путаешь получаемый из контейнера предмет(речь о переменной i) и автоинкрементируемый индекс(переменная idx) для записи предмета, так ещё и лишний раз прибавляешь тот же таки автоинкрементируемый индекс. Да и сами по себе проверки, по сути дела, имеют своё место. Насчёт первой проверки, то передавать в неё стоит входящий итерируемый предмет(то бишь, переменную i) и, в тоже время, сверяться ровно в тот момент, когда речь идёт о перелистывании на следующую страницу, чтобы нам не продемонстрировало элементы, ниже за последний индекс. Что касается второй проверки, то она не нужна вовсе. Если ты внимательно изучал кодовую базу, предоставленную мною ранее, то мог бы понять, как обойтись без такого: достаточно проверить то, не достигла ли переменная, отвечающая за автоинкрементируемый индекс для записи входящего итерируемого предмета соответствующего лимита(то бишь, учитывая то, что изначально автоинкрементируемый индекс равен -1, ибо мы данные записываем от нуля, используя префиксный инкремент, то нашим лимитом, в данном случае будет директива, хранящая максимальное количество мебели на странице - 1, чтобы не выйти за границы массива и, в то же время, закончить обработку цикла). Что касается проверок, конкатенирующих >>> и <<<, то с ними особо проблем не заметил(наверное потому, что не сумел имплементировать ситуацию). Давай, теперь, разберём суть моего кода в деталях(тут я уже распишу его на максимум, если ты и в этот раз не поймёшь, то я уж не знаю, что делать):
#define MAX_BUSINESS_LIST_PAGES (1000 / MAX_BUSINESS_ON_PAGE)
Не сложно догадаться, что это обозначает: максимальное количество страниц, основывающееся на результате деления 1000(под 1000 имеется ввиду максимальное количество бизнесов) и MAX_BUSINESS_ON_PAGE(20). По итогу получаем 50 страниц.
enum E_PLAYER_BUSINESS_LIST_STRUCT
{
PBL_INDEX[MAX_BUSINESS_ON_PAGE],
PBL_COUNT
}
Структура, хранящая некие данные о текущем предмете на странице: PBL_INDEX - массив, размером в MAX_BUSINESS_ON_PAGE, хранящий индекс для доступа к основному массиву, хранящему некие метаданные о бизнесе; PBL_COUNT - целочислительный элемент, хранящий количество предметов находящихся на странице.
new g_player_business_page[MAX_PLAYERS],
g_player_count_listed_busin[MAX_PLAYERS],
g_player_businesses_list[MAX_PLAYERS][MAX_BUSINESS_LIST_PAGES][E_PLAYER_BUSINESS_LIST_STRUCT];
Переменные: хранит текущую страницу игрока; хранит количество перелистанных элементов игроком; хранит список элементов игрока с некими метаданными, исходя из страницы.
О сути функций я писать не буду, потому что и без того понятно, что за что отвечает.
Разберём кое-какие моменты из функции ShowPlayerBusinessListDialog
if(is_page_prev == false)
{
new start = GetPlayerBusinessListLastIndex(playerid, page);
if(is_first_page == false)
{
IncrementPlayerBusinessPage(playerid);
page = GetPlayerBusinessPage(playerid);
}
foreach(new i : bIterator)
{
if(start != 0)
{
if(i == start)
continue;
}
if(is_page_prev == false)
{
if(i < start)
continue;
}
else
{
if(i > start)
continue;
}
if(idx == (MAX_BUSINESS_ON_PAGE - 1))
break;
SetPlayerBusinessListIndex(playerid, page, ++ idx, i);
format
(
result_str, sizeof result_str,
fmt_str,
i,
"Alex"
);
strcat(dest, result_str);
}
if(!idx)
return SendClientMessage(playerid, -1, "У Вас нет своих бизнесов");
SetPlayerBusinessListCount(playerid, page, idx + 1);
AddPlayerCountListedBusinesses(playerid, idx + 1);
}
else
{
new count = GetPlayerBusinessListCount(playerid, page);
DecrementPlayerBusinessPage(playerid);
page = GetPlayerBusinessPage(playerid);
new count_ex = GetPlayerBusinessListCount(playerid, page);
for(new j, index; j < count_ex; j ++)
{
index = GetPlayerBusinessListIndex(playerid, page, j);
format
(
result_str, sizeof result_str,
fmt_str,
index,
"Alex"
);
strcat(dest, result_str);
}
DivPlayerCountListedBusinesses(playerid, count);
}
if(GetPlayerCountListedBusinesses(playerid) != 43)
strcat(dest, "\n{93c47d}>>>\t\t");
if(is_page_prev == false)
свидельствует о том, что игроку продемонстрирована либо следующая, либо начальная страница(но, кроме того, для неё ещё имеется аргумент is_first_page, суть которого мы разберём далее).
if(is_first_page == false)
{
IncrementPlayerBusinessPage(playerid);
page = GetPlayerBusinessPage(playerid);
}
Как раз таки тот аргумент, отвечающий за то, продемонстрирована ли первая страница. В случае, если принимает true(по умолчанию установлен именно в true), то демонстрируются начальные элементы, в количестве MAX_BUSINESS_ON_PAGE, иначе другие 20 элементов. Но, всё же, нас интересует суть условия: как видно оно находится в блоке с условием, о котором шлось выше, дабы оно срабатывало ровно тогда, когда нужно: то бишь если нажата не предыдущая страница и, в тоже время, это не первая страница, мы инкрементируем текущую страницу, перезаписав её в переменную page, дабы, в последующем, записывать данные на уже новую страницу.
foreach(new i : bIterator)
{
if(start != 0)
{
if(i == start)
continue;
}
if(is_page_prev == false)
{
if(i < start)
continue;
}
else
{
if(i > start)
continue;
}
if(idx == (MAX_BUSINESS_ON_PAGE - 1))
break;
SetPlayerBusinessListIndex(playerid, page, ++ idx, i);
format
(
result_str, sizeof result_str,
fmt_str,
i,
"Alex"
);
strcat(dest, result_str);
}
if(start != 0)
{
if(i == start)
continue;
}
Если последний из индексов не равен нулю, то бишь, мы находимся на другой странице и в, то же время входящий итерируемый предмет равен последнему из индексов, то, в таком случае, пропустим итерацию.
if(is_page_prev == false)
{
if(i < start)
continue;
}
Если нажата следующая страница, то наша задача не получить предметы, идентификатор которых менее за тот, который находится в последнем индексе.
Другая проверка, срабатывающая если is_page_prev, не нужная хуйня, можешь удалять, ибо у нас, во первых, имеется другой блок под то, если нажата предыдущая страница и, кроме того, благодаря трёхмерной вариации, мы храним данные непосредственно о странице, поэтому, переключаясь обратно, мы попросту декрементируем текущую страницу, потому можешь избавиться от проверки вовсе.
if(idx == (MAX_BUSINESS_ON_PAGE - 1))
break;
Как раз то, о чём я говорил ранее: проверка на то, не достиг ли автоинкрементируемый индекс для записи данных в массив конца.
SetPlayerBusinessListCount(playerid, page, idx + 1);
AddPlayerCountListedBusinesses(playerid, idx + 1);
Первая из функций устанавливает количество предметов для текущей страницы игрока, исходя из позиции автоинкрементируемого индекса + 1. То бишь: допустим 20 элементов, значит idx будет равен 19, а если ещё прибавить единицу, то 20. Собственно, 20 элементов. Для чего нужна эта функция и чем чревато её отсутствие я рассказывал в предыдущей теме, однако, продублирую:
Допустим, если вдруг у нас есть 43 элемента(как в примере) и, скажем, переключаемся мы вплоть до третьей страницы(в нашем случае это будет конец, учитывая то, что 43 не кратно 20 и, по итогу, мы получим ещё 3 элемента) и потом, возвращаясь назад, мы, как известно, отнимаем от массива g_player_count_listed_busin, отвечающего за хранение всеобщего количества просмотренных listitem'ov количество находящихся элементов на текущей странице, а вот, допустим, если бы у нас отсутствовал данный элемент перечисления(PBL_COUNT), то у нас бы не было понимая того, сколько нужно отнять. Чем это чревато? Тем, что, отняв заместо трёх элементов со страницы десять и потом, вернувшись на первую(то бишь отнимем ещё 40 элементов), мы получим в g_player_count_listed_busin далеко не то число, которое соответствует нашим требованиям(в моём примере это 43, но у тебя это результат функции GetPlayerCountOfBusinesses, так или иначе суть одна и та же) и, на основе этого, система конкатенирует >>>, потому как сработает условие, так как число из GetPlayerCountListedBusinesses не будет равно 43(у тебя это GetPlayerCountOfBusinesses). Вторая же из функций прибавляет к текущему количеству перелистанных элементов ещё это.
else
{
new count = GetPlayerBusinessListCount(playerid, page);
DecrementPlayerBusinessPage(playerid);
page = GetPlayerBusinessPage(playerid);
new count_ex = GetPlayerBusinessListCount(playerid, page);
for(new j, index; j < count_ex; j ++)
{
index = GetPlayerBusinessListIndex(playerid, page, j);
format
(
result_str, sizeof result_str,
fmt_str,
index,
"Alex"
);
strcat(dest, result_str);
}
DivPlayerCountListedBusinesses(playerid, count);
}
Разберём блок, отвечающий за то, если нажата предыдущая страница.
new count = GetPlayerBusinessListCount(playerid, page);
Получает количество элементов на странице, до декрементирования, то бишь с текущей. Для того, чтобы в дальнейшем отнять то количество от всеобщего количество перелистанных элементов.
DecrementPlayerBusinessPage(playerid);
page = GetPlayerBusinessPage(playerid);
new count_ex = GetPlayerBusinessListCount(playerid, page);
for(new j, index; j < count_ex; j ++)
{
index = GetPlayerBusinessListIndex(playerid, page, j);
Декрементируем текущую страницу игрока, перезаписывая результат в переменную page. count_ex, в свою очередь, получит количество имеющихся элементов на уже предыдущей странице, тем самым до той границы будет идти цикл, получая данные из массива g_player_businesses_list, исходя из ид игрока, его страницы и j индекса, возвращая сохранённый идентификатор в переменную index.
На этом всё, дальше я думаю расписывать нет смысла, итак потратил около трёх часов на это дело почти что. Ну и от пваров советовал бы отказаться, в угоду обыкновенных переменных. Ибо память выделяемая под них(касается целочислительных и вещественных), очищается не после удаления, а в момент выхода игрока, а до того сохраняется в оперативной памяти сервака, что, может привести к её исчерпанию. Ну и названия пваров проще сохранять перед этим в массив, чтобы, если вдруг указав не то имя, компилятор сповестил нас об этом, ибо это одна из распространённых ошибок в пварах, потому что у них отсутствует генерация ошибки(можно, в теории, написать свою самопалку, со следующими аргументами: SetCustomPVar(playerid, type), где playerid - ид игрока, к которому нужно привязать пвар; type - тип пвара(можно, как вариант, замутить целое перечисление, хранящее список типов пваров) и потом уж создать массив на n кол-во ячеек и со структурой, имеющей следующие элементы: имя пвара(string); субтип пвара(то бишь целый, вещественный, строковый); Естественно, это не освободит нас от использования линейно-исполняющего свитча, ибо придётся перебрать субтип пвара, вызывая функцию для установки пвара, исходя его из субтипа, но это всего лишь перебор трёх элементов, а не n-ного количества, который вполне себе мог бы быть, если бы сделали акцент не на быстродействии, а на экономии выделяемой под мод памяти.
Вход
Регистрация
Помощь
