Админ-бот v.1

[execution]

Система предназначена для помощи младшей администрации. Игрок в админ чат посылает запрос и высвечивается старшей администрации, одобрить или нет. Делал под себя, так-что измените, что надо. Нам понадобится foreach, Pawn.CMD

В начало мода.


const
MAX_BOT_REQUEST = 3, // Максимальное кол-во запросов для бота
MAX_BOT_REQUEST_LENGTH = 8; // Максимальная длина запросов

new
ADMIN_BOT_SUPPORT[MAX_BOT_REQUEST][MAX_BOT_REQUEST_LENGTH] = // Сами запросы
{
"/mute",
"/prison",
"/jail"
},
ADMIN_BOT_TEXT[128]; // Массив с хранением полного запроса (причина/ник)

Ко всем командам.


CMD:admin(playerid, params[])
{
if(/*проверка на администратора*/)
{
if(!(0 < strlen(params) < 90))
return SendClientMessage(playerid, -1, !"Используйте больше 1 символа и меньше 90");

new
string[128];

format(string, sizeof(string), "[A] %s [%d]: %s", /*Массив с ником админа*/, playerid, params);
SendAdminMessage(-1, string);

for(new k = MAX_BOT_REQUEST-1; k != -1; k--) // Перебираем все существующие запросы
{
if(strfind(params, ADMIN_BOT_SUPPORT[k], true) != -1) // Смотрим, присутствуют ли в тексте
{
strdel(params, 0, strfind(params, ADMIN_BOT_SUPPORT[k], true)); // Если да, то удаляем всё, до найденного запроса
format(ADMIN_BOT_TEXT, sizeof(ADMIN_BOT_TEXT), "%s // %s", params, /*Массив с ником админа*/); // Сохраним запрос в массив
format(string, sizeof(string), "%s запросил помощь о выдаче наказания. Одобрить Y, отказать N", /*Массив с ником админа*/);
SendAdminMessage(-1 , string); // Отправим текст администраторам.
break; // Обрываем цикл, после найденного запроса.
}
}
}
return 1;
}
alias:admin("a");

В OnPlayerKeyStateChange


if(newkeys == KEY_YES) // Если нажали Y
{
if(ADMIN_BOT_TEXT[0] != '\0')
{
if(/*Проверка на администратора*/)
{
PC_EmulateCommand(playerid, ADMIN_BOT_TEXT); // Отправим запрос
ADMIN_BOT_TEXT[0] = EOS; // Обнулим массив.
}
}
}

else if(newkeys == KEY_NO) // Если нажали N
{
if(ADMIN_BOT_TEXT[0] != '\0')
{
if(/*Проверка на администратора*/)
{
new
string[(48 + MAX_PLAYER_NAME + 1) - 2];

format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", /*Массив с ником админа*/);
SendAdminMessage(-1, string);
ADMIN_BOT_TEXT[0] = EOS;
}
}
}

В начало мода или ко всем итераторам


new
Iterator:Connect_Admin<MAX_PLAYERS>; // Итератор , где будем хранить всех администраторов

При добавлении/заходе администратора


if(!Iter_Contains(Connect_Admin, /*админ*/)) Iter_Add(Connect_Admin, /*админ*/);

При выходе/снятии администратора


if(Iter_Contains(Connect_Admin, /*админ*/)) Iter_Remove(Connect_Admin, /*админ*/);

Сток для отправки сообщения администраторам


stock SendAdminMessage(color, const string[])
{
foreach(new i : Connect_Admin)
{
SendClientMessage(i, color, string);
}
return 1;
}


https://i.imgur.com/3mtcRlO.png
У кого не грузит: https://imgur.com/3mtcRlO
Буду рад увидеть конструктивную критику, а так-же идеи для следующей версии.
Автор: Я

[Long-]

Хм, а чем тогда твой итератор Connect_Admin отличается от простого Player?
Тем не менее, можно сделать независимую систему от форича, тобишь:


stock SendAdminMessage(color, const string[])
{
#if defined foreach
foreach(new i : Connect_Admin)
#else
{
for(new i = GetPlayerPoolSize(); i > -1; --i)
{
if(IsPlayerConnected(i))
#endif
{
SendClientMessage(i, color, string);
}
#if !defined foreach
}
#endif
return 1;
}

[DeimoS]

Хм, а чем тогда твой итератор Connect_Admin отличается от простого Player?

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

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

[Long-]

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

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

А, я думал там написано просто в onplayerconnect, и в onPlayerdisconnect, но выделять под этот итератор 500 ячеек, не слишком много?

[DeimoS]

А, я думал там написано просто в onplayerconnect, и в onPlayerdisconnect, но выделять под этот итератор 500 ячеек, не слишком много?

А ты никак меньше не выделишь, если не создашь второй массив (http://pro-pawn.ru/showthread.php?15081-%D0%98%D1%82%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80%D1%8B-%D0%B2-Pawn&p=84616&viewfull=1#post84616)

[Long-]

А ты никак меньше не выделишь, если не создашь второй массив (http://pro-pawn.ru/showthread.php?15081-%D0%98%D1%82%D0%B5%D1%80%D0%B0%D1%82%D0%BE%D1%80%D1%8B-%D0%B2-Pawn&p=84616&viewfull=1#post84616)

Всм, так же можно:


new
Iterator:Connect_Admin<10>;

не?

[DeimoS]

Почитай внимательно пост, ссылку на который я скинул

[Long-]

И немного пессимизации:


format(string, sizeof(string), "%s запросил помощь о выдаче наказания. Одобрить Y, отказать N", /*Массив с ником админа*/);


strcat(string, /*Массив с ником админа*/);
strcat(string, !" запросил помощь о выдаче наказания. Одобрить Y, отказать N");

[execution]

И немного пессимизации:


format(string, sizeof(string), "%s запросил помощь о выдаче наказания. Одобрить Y, отказать N", /*Массив с ником админа*/);


strcat(string, /*Массив с ником админа*/);
strcat(string, !" запросил помощь о выдаче наказания. Одобрить Y, отказать N");

Спасибо, учту.

[nickmate]

В таком случае, почему бы просто не сделать так (естественно, если не использовать foreach):


new bool:adminStatus[MAX_PLAYERS]; (или в enum)

При выдаче админ прав
adminStatus[playerid] = true;

И сам цикл


for (new i = 0, j = GetPlayerPoolSize(); i <= j; i++)
{
if (!IsPlayerConnected(i)) continue;
if(!adminStatus[i]) continue;
// doSomething();
}


-------------------------------------


new string[(48 + MAX_PLAYER_NAME + 1) - 2];


Неплохо, но зачем каждый раз считать символы в строке, если можно сделать так (способ от DC):



static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), fmt_str, /* Имя администратора */);

[Nexius_Tailer]

new string[(48 + MAX_PLAYER_NAME + 1) - 2];


Неплохо, но зачем каждый раз считать символы в строке, если можно сделать так (способ от DC):



static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), fmt_str, /* Имя администратора */);

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

[nickmate]

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

Я буду просто считать количество спецификаторов, а не количество символов в каждой строке. В любом случае, ты можешь использовать любой вариант, главное чтобы тебе было удобно. Я лишь показал один из способов, предложенным Daniel Cortez

[Nexius_Tailer]

Я буду просто считать количество спецификаторов, а не количество символов в каждой строке. В любом случае, ты можешь использовать любой вариант, главное чтобы тебе было удобно. Я лишь показал один из способов, предложенным Daniel Cortez
Ну так при изменении строки нередко изменяется и количество спецификаторов, потому тебе и придётся всё равно всё пересчитывать, если нужно будет как-то более значимо изменить строку.

[DeimoS]

А для подсчёта символов в строке достаточно использовать нормальный редактор (то бишь, практически всё, кроме Pawno), в котором вшита функция подсчёта выделенных символов. От полученного значения отнять спецификаторы и получится размер строки без спецификаторов. На деле это будет быстрее, чем прописывать все эти "static const" и "sizeof(...)".

Вариант от Кортеза хорош в очень длинных строках, которые, к тому же, часто изменяются. Хотя и в том случае это может вызвать ряд сложностей, например, при попытке изменить порядок спецификаторов (очень легко изменить не тот спецификатор/переменную, которую нужно было изменить, так как текст сообщения со спецификаторами и переменные будут находится в разных частях кода)

[Daniel_Cortez]

Хотя и в том случае это может вызвать ряд сложностей, например, при попытке изменить порядок спецификаторов (очень легко изменить не тот спецификатор/переменную, которую нужно было изменить, так как текст сообщения со спецификаторами и переменные будут находится в разных частях кода)
Знаю, что немного поздно, но всё же спрошу: каким образом вышесказанное относится именно к моему методу подсчёта (насколько знаю, такому классу ошибок подвержены все известные ныне методы)? Не говоря уже о скромном замалчивании того факта, что при ручном подсчёте точно так же можно неправильно "сосчитать" размер не только спецификаторов, но и самой форматной строки - например, редактор кода показал "48", но ты случайно записал "46" (просто опечатка или показалось не то число - неважно). К слову, именно от этого типа ошибок и перестраховывает использование sizeof.

P.S.: Ни в коем случае не пытаюсь добиться признания неправильным того или иного подхода к подсчёту размера строк - понятное дело, что однозначно правильного способа нет и всё зависит от индивидуального выбора каждым компромисса между скоростью написания кода и надёжностью. Тем не менее, хотелось бы видеть справедливое обсуждение всех плюсов и минусов, а не только доводы против одного метода и в пользу другого.

[DeimoS]

Знаю, что немного поздно, но всё же спрошу: каким образом вышесказанное относится именно к моему методу подсчёта

Я уже в одной из тем (вроде, как раз в теме с описанием твоего метода) приводил пример этих слов, но ладно, приведу ещё раз.

Речь идёт про такой вариант реализации:

static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
// Тут какой-либо другой код (например, определение максимального размера для массива, если мы имеем несколько static const, а не один)
// Тут какой-либо другой код (то бишь, часто код очень нужный конкретно в данном месте, а не до/после массива/форматирования)
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
// Тут какой-либо другой код
format(string, sizeof(string), fmt_str, /* Имя администратора */);

Очень часто встречал такие реализации при использовании метода подсчёта с sizeof и если появится нужда изменить порядок спецификаторов, придётся совершать, как минимум, лишние движения глазами вверх/вниз (что, согласись, гораздо больше сбивает, чем если бы текст и спецификаторы были на одной строке).

При этом, даже без какого-либо кода между массивом и форматированием, читаемость такого варианта на порядок ниже, ибо когда ты смотришь на format, тебе придётся каждый раз отделять переменные от массива для заполнения и массива с текстом

static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), fmt_str, name); // Ты так сразу не увидишь, что в строку записывается всего 1 переменная, так как всё будет сливаться
В отличии от простого варианта, где всё подсвечивается редактором:

new string[45+ (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name); // Тут уже сразу видно где находятся переменные, ибо они отделяются текстом от массива для заполнения
И к этому никак не привыкнуть, ибо практически в каждом случае форматирования у переменных будут уникальные имена разной длины, из-за чего нельзя просто "на автомате" пропустить несколько первых переменных.

[Geebrox]

При этом, даже без какого-либо кода между массивом и форматированием, читаемость такого варианта на порядок ниже, ибо когда ты смотришь на format, тебе придётся каждый раз отделять переменные от массива для заполнения и массива с текстом

static const fmt_str[] = "[A] Администратор %s отказал в запросе о помощи";
new string[sizeof(fmt_str) + (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), fmt_str, name); // Ты так сразу не увидишь, что в строку записывается всего 1 переменная, так как всё будет сливаться
В отличии от простого варианта, где всё подсвечивается редактором:

new string[45+ (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name); // Тут уже сразу видно где находятся переменные, ибо они отделяются текстом от массива для заполнения
И к этому никак не привыкнуть, ибо практически в каждом случае форматирования у переменных будут уникальные имена разной длины, из-за чего нельзя просто "на автомате" пропустить несколько первых переменных.

А как тогда (по твоему методу) считать длину таких строк:


static const query_content[] =
"SELECT " \
"id," \
"HEX(password_hash) as hash," \
"HEX(password_salt) as salt " \
"FROM "ACCOUNT_DATA_BASE_TABLE" " \
"WHERE " \
"name='%q'";


:pardon:

[DeimoS]

А как тогда (по твоему методу) считать длину таких строк:


static const query_content[] =
"SELECT " \
"id," \
"HEX(password_hash) as hash," \
"HEX(password_salt) as salt " \
"FROM "ACCOUNT_DATA_BASE_TABLE" " \
"WHERE " \
"name='%q'";


:pardon:

Вручную? Точнее, при помощи редактора, выделяя текст каждой строки
https://i.imgur.com/3ZPfhzW.png
Хотя, думаю, если поискать, можно найти готовый плагин для ST, который позволяет подсчитывать размер текста сразу для нескольких строк, а не только для одной. Меня просто и такой вариант вполне устраивает. Я просто копирую текст таких сообщений в отдельную вкладку и удаляю все переносы, дабы получилось что-то типа такого:

SELECT id,HEX(password_hash) as hash,HEX(password_salt) as salt FROM "ACCOUNT_DATA_BASE_TABLE" WHERE "name='%q'
На деле такой вариант всё равно будет быстрее, чем прописывание static const и sizeof (хотя и вариант с выделением каждой строки в отдельности будет быстр, если у тебя всё хорошо с математикой).

[Geebrox]

На деле такой вариант всё равно будет быстрее, чем прописывание static const и sizeof

Да брось :agree:, пресчитывать каждую строчку потом в голове ещё сумировать всё это, убирать лишние или делители пробелы между строками, если есть ещё и константы то посомтреть содержимое константы и потом её длину тоже добалять ко всему полученному в голове и т. д. и т. п. Серьезно думаешь, что это быстрее, чем просто прописать sizeof? Это все действии не учитывая ещё и изменение в будущем. Например ты понял, что не правильно написал 1 букву в запросе после того как всё это ели просчитал, и....

[DeimoS]

Да брось :agree:, пресчитывать каждую строчку потом в голове ещё сумировать всё это, убирать лишние или делители пробелы между строками, если есть ещё и константы то посомтреть содержимое константы и потом её длину тоже добалять ко всему полученному в голове и т. д. и т. п. Серьезно думаешь, что это быстрее, чем просто прописать sizeof? Это все действии не учитывая ещё и изменение в будущем. Например ты понял, что не правильно написал 1 букву в запросе после того как всё это ели просчитал, и....

Именно, это будет быстрее. Ты забываешь, что прописать нужно не только sizeof, но ещё и static const + составить формулу со всеми вычетами заполнителей (когда я это могу сделать прямо в момент выделения текста, пропуская лишнее) + прописать в format вызов массива static const. К тому же, размер контакнт нужно будет смотреть и в случае использования static const.

Да и с чего ты решил, что обязательно всё нужно считать в уме? Как я сказал, можно легко найти плагин на любой вкус. Вот, например, поставил первый попавшийся (называется "Word Count"), который считает весь выделенный текст
https://i.imgur.com/sCj9rkr.png
И это при том, что изначально плагин заточен не на подсчёт символов, а на автоматический подсчёт слов. Так что я уверен, что, при желании, можно найти плагин, который позволит гораздо удобнее рассчитывать размер сразу для всего выделенного текста, раз тебе так сложно в голове складывать, в большинстве своём, простые числа.

Вариант со static const будет лидировать только в том случае, когда сама строка оформлена крайне ужасно. А-ля:

static const query_content[] =
"SELECT "
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"id,"
"HEX(password_hash) as hash,"
"HEX(password_salt) as salt "
"FROM "ACCOUNT_DATA_BASE_TABLE" "
"WHERE "
"name='%q'";
Вот в таких случаях действительно может быть быстрее прописать static const (если формула окажется не очень запутанной и не придётся тратить дополнительное время на перепроверку того, правильные ли ты значения прописал для того или иного заполнителя. То бишь, как раз тут в силу вступает та ситуация, которую я описал пару постов назад для Кортеза). В остальных случаях "ручной" подсчёт будет в разы быстрее и, в итоге, позволит коду остаться читабельнее/компактнее (хотя даже в этом случае можно придумать варианты быстрого перерасчёта размера в случае изменения строки. Было бы желание).


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


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

[Geebrox]

Именно, это будет быстрее. Ты забываешь, что прописать нужно не только sizeof, но ещё и static const + составить формулу со всеми вычетами заполнителей (когда я это могу сделать прямо в момент выделения текста, пропуская лишнее) + прописать в format вызов массива static const. К тому же, размер контакнт нужно будет смотреть и в случае использования static const.

Раз ты полагаешься на плагины для подсчёта, то почему для static const + sizeof не подумал о сниппетах??? Благо они есть в нормальных редакторах, так вот используя сниппеты ты не должен будешь прописывать всё в ручную.

- - - Добавлено - - -


А все твои "вот если строку изменить!...." - это обычное надумывание положительных моментов, для которых я так же могу придумать десяток отрицательных

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

[DeimoS]

Раз ты полагаешься на плагины для подсчёта, то почему для static const + sizeof не подумал о сниппетах??? Благо они есть в нормальных редакторах, так вот используя сниппеты ты не должен будешь прописывать всё в ручную.


Потому что, во-первых, ситуации бывают разные (разное количество строк, как минимум) и универсальный сниппет ты никак не составишь. Во-вторых, если бы проблема "static const" была только во времени набора символов, никаких вопросов бы не было (я, например, за то, чтоб вместо всяких макросов "f" писать полноценно "format"). Но помимо лишнего времени на набор, есть ещё убитая читаемость, раздуваемый код и надуманный плюс о том, что так подсчёт строки будет происходить в несколько раз быстрее, когда на деле этот метод будет выигрывать только в крайне длинных и крайне криво оформленных строках, а в большинстве случаев наоборот лишь время на написание кода отнимать.


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

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

+ в том-то и дело, что сугубо во время разработки конкретной системы ты будешь трогать её строки (да и то, только в довольно крупных и запутанных системах можно постоянно мудрить со строками). Но рано или поздно ты закончишь написание этой системы и больше не притронешься к строкам в ней. При этом, на выходе ты получишь, как минимум, дополнительную строку кода для каждого из сообщений, которая, будучи длинной, может занимать и более одной строки. В итоге, ради того, чтоб пару раз во время разработки не пересчитывать размер (хотя этого изначально можно избежать, как я описал выше), ты захламишь свой исходник, ещё больше убивая, тем самым, читаемость.

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



Хотя я не особо понимаю к чему вообще весь этот разговор. У варианта "static const + sizeof" есть объективные минусы, хочешь ли ты это принимать или нет. И я не призываю никого отказываться от этого варианта, а лишь указываю на объективные недостатки, которые люди подчас не хотят видеть, напридумав положительных моментов (как это было с тем же foreach для игроков/транспорта в зоне стрима).

Желаете пользоваться подобным подсчётом? Пожалуйста, вас никто не держит. Только понимайте все плюсы и минусы этого метода, а так же не забывайте говорить о минусах, когда в очередной раз советуете кому-то этот метод. Потому что пока я вижу лишь вред от того, что всякие понтокодеры подхватили идею такого подсчёта и, в итоге, лепят что-то подобное:

static const
msg_1[] = "...",
msg_2[] = "...";
new
string_1[sizeof(msg_1)+...],
string_2[sizeof(msg_2)+...];
format(string_1, sizeof(string_1), msg_1, ...);
SendClientMessage(playerid, -1, string_1);
format(string_2, sizeof(string_2), msg_2, ...);
SendClientMessage(playerid, -1, string_2);
не говоря уже о различных извращениях, часть которых я описал в предыдущих сообщениях, которые в ноль убивают читаемость

[Daniel_Cortez]

Не люблю поднимать темы, но думаю, на сей раз оно всё же стоит того.


В отличии от простого варианта, где всё подсвечивается редактором:

new string[45+ (-2 + MAX_PLAYER_NAME)];
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name); // Тут уже сразу видно где находятся переменные, ибо они отделяются текстом от массива для заполнения

Собственно, иллюстрация того, что я написал ранее о том, как легко ошибиться при подсчёте без sizeof. В цитате выше неправильно указан размер форматной строки "45", в то время как редактор при выделении текста указывает "47".


А для подсчёта символов в строке достаточно использовать нормальный редактор (то бишь, практически всё, кроме Pawno), в котором вшита функция подсчёта выделенных символов. От полученного значения отнять спецификаторы и получится размер строки без спецификаторов.
Тоже неверно. Получится не размер, а длина строки - для размера нужно добавить ещё "+1" под завершающий символ '\0' (т.е. для примера выше правильным будет не "45" и не "47", а "48"). Ещё одна мелочь, из-за которой легко допустить ошибку, и ещё один минус к подсчёту без sizeof.

[DeimoS]

Собственно, иллюстрация того, что я написал ранее о том, как легко ошибиться при подсчёте без sizeof. В цитате выше неправильно указан размер форматной строки "45", в то время как редактор при выделении текста указывает "47".

Это не ошибка, а привычка сразу высчитывать спецификаторы :) Просто забыл убрать "-2" в формуле (точнее, просто не обратил внимание на оставшуюся формулу, так как посыл был именно в замене sizeof).
Хотя даже в этом виде никакой проблемы не будет за счёт 4-ех дополнительных символов MAX_PLAYER_NAME (ну разве что кто-то не решится позволять игрокам изменять ник, делая его длиннее 20 символов) , хоть формула получилась и не совсем верной.



Тоже неверно. Получится не размер, а длина строки - для размера нужно добавить ещё "+1" под завершающий символ '\0' (т.е. для примера выше правильным будет не "45" и не "47", а "48"). Ещё одна мелочь, из-за которой легко допустить ошибку, и ещё один минус к подсчёту без sizeof.

Не нужно придираться к словам :)
Собственно, выше я уже написал причину того, почему формула именно такая. В своём коде я не извращяюсь с явным вычитанием спецификаторов, а делаю просто так:

new string[45+MAX_PLAYER_NAME+1];// В собственном моде ещё, обычно, делаю макрос, в котором хранится "реальный" размер ника (20 символов), который и использую при составлении таких формул
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name);
Если очень хочется добиться истины, могу скинуть в личку какой-нибудь старый скрипт с подобным подсчётом, дабы проверил его на наличие ошибок.




Хотя крайне опрометчиво с твоей стороны пытаться приписывать ошибку в формуле в качестве одного из минусов ручного подсчёта. При "автоматическом" подсчёте такая возможность в несколько раз увеличивается за счёт "раздутости" кода и лишних телодвижений при попытках определить последовательность переменных в format.
Уже на каком-нибудь вот таком варианте:
format(query_string, sizeof(query_string), fmt_string, Houses[i][Houses_Name], Houses[i][Houses_Cost], Houses[i][Houses_UpKeep], Houses[i][Houses_UpKeepLeft], Houses[i][Houses_Buyout], Houses[i][Houses_Interior], Houses[i][Houses_Car], Houses[i][Houses_Lock], Houses[i][Houses_Rentabil], Houses[i][Houses_RentCost], Houses[i][Houses_HealUpgrade], Houses[i][Houses_ArmourUpgrade], Houses[i][Houses_PickupX], Houses[i][Houses_PickupY], Houses[i][Houses_PickupZ], Houses[i][Houses_PickupA], Houses[i][Houses_InteriorX], Houses[i][Houses_InteriorY], Houses[i][Houses_InteriorZ], Houses[i][Houses_InteriorA]);
можно испытать немало проблем (особенно если это не твой код и ты не знаешь на память размеры тех или иных переменных)

В случае с обычным подсчётом я просто сделал так
https://i.imgur.com/XX6qypX.png
Собственно, это как раз пример работы с чужим кодом. За счёт того, что у меня перед глазами были как строка с порядком спецификаторов (а это хорошо помогает понять, массив перед тобой, целочисленная переменная или вещественная), так и список самих переменных, составление формулы заняло не больше минуты, а на определение ДЛИНЫ строки ушло, в худшем случае, чуть больше времени, чем я писал бы код автоподсчёта (и то потому что я на сразу занимался вычитанием спецификаторов из конечной длины строки, а не указывал это в формуле. Так что, вполне возможно, что я сделал закончил с составлением формулы даже быстрее, чем сделал бы это с автоподсчётом, не прописывая каждый раз "-2").

P.S. Самой формулы на скрине нет, ибо она строк на 15 выше, так как там появилось ещё несколько случаев применения массива после того, как я рассчитал размер под этот format (и вот тут с автоподсчётом я бы знатно попотел, ибо пришлось бы через весь экран глазами "прыгать"). Массив я уже дописал для скрина, дабы было понятно, что всё получилось вполне компактно и лишних движений глазами практически не нужно делать.

[Daniel_Cortez]

Просто забыл убрать "-2" в формуле

Это не ошибка
Даже не знаю, что и сказать.



Хотя даже в этом виде никакой проблемы не будет за счёт 4-ех дополнительных символов MAX_PLAYER_NAME (ну разве что кто-то не решится позволять игрокам изменять ник, делая его длиннее 20 символов) , хоть формула получилась и не совсем верной.
Это справедливо только для тех случаев, когда в формуле есть что-то с "запасом".



Не нужно придираться к словам :)
Если ты на словах так легко путаешь понятия, то и на практике можешь забыть об отличии длины строки от размера. Раньше уже приходилось наблюдать подобное и на форуме, и просто при общении с другими людьми. Но если для тебя проще называть это придирками, то, наверное, я не могу запретить тебе это делать.



В своём коде я не извращяюсь с явным вычитанием спецификаторов, а делаю просто так:

new string[45+MAX_PLAYER_NAME+1];// В собственном моде ещё, обычно, делаю макрос, в котором хранится "реальный" размер ника (20 символов), который и использую при составлении таких формул
format(string, sizeof(string), "[A] Администратор %s отказал в запросе о помощи", name);
Ок, т.е. вместо расписывания части формулы ты пытаешься просчитать эту часть в уме. Вот только чем больше вещей стараешься делать в уме, тем больше вероятность ошибки - ты сам же и показал это выше.
Собственно, в чём и отличие наших подходов к подсчёту: твой способ - для тех, кому нужна скорость написания, мой - для тех, кому важнее правильность расчётов и надёжность. Можешь апеллировать к тому, что работать с форматной строкой, вынесенной в отдельный массив, неудобно, но лично я не вижу никаких проблем в том, что строка смещена на сантиметр или два выше вызова format.



Хотя крайне опрометчиво с твоей стороны пытаться приписывать ошибку в формуле в качестве одного из минусов ручного подсчёта. При "автоматическом" подсчёте такая возможность в несколько раз увеличивается за счёт "раздутости" кода и лишних телодвижений при попытках определить последовательность переменных в format.
Уже на каком-нибудь вот таком варианте:
format(query_string, sizeof(query_string), fmt_string, Houses[i][Houses_Name], Houses[i][Houses_Cost], Houses[i][Houses_UpKeep], Houses[i][Houses_UpKeepLeft], Houses[i][Houses_Buyout], Houses[i][Houses_Interior], Houses[i][Houses_Car], Houses[i][Houses_Lock], Houses[i][Houses_Rentabil], Houses[i][Houses_RentCost], Houses[i][Houses_HealUpgrade], Houses[i][Houses_ArmourUpgrade], Houses[i][Houses_PickupX], Houses[i][Houses_PickupY], Houses[i][Houses_PickupZ], Houses[i][Houses_PickupA], Houses[i][Houses_InteriorX], Houses[i][Houses_InteriorY], Houses[i][Houses_InteriorZ], Houses[i][Houses_InteriorA]);
можно испытать немало проблем (особенно если это не твой код и ты не знаешь на память размеры тех или иных переменных)

В случае с обычным подсчётом я просто сделал так
...
Собственно, это как раз пример работы с чужим кодом. За счёт того, что у меня перед глазами были как строка с порядком спецификаторов (а это хорошо помогает понять, массив перед тобой, целочисленная переменная или вещественная), так и список самих переменных, составление формулы заняло не больше минуты, а на определение ДЛИНЫ строки ушло, в худшем случае, чуть больше времени, чем я писал бы код автоподсчёта (и то потому что я на сразу занимался вычитанием спецификаторов из конечной длины строки, а не указывал это в формуле. Так что, вполне возможно, что я сделал закончил с составлением формулы даже быстрее, чем сделал бы это с автоподсчётом, не прописывая каждый раз "-2").

P.S. Самой формулы на скрине нет, ибо она строк на 15 выше, так как там появилось ещё несколько случаев применения массива после того, как я рассчитал размер под этот format (и вот тут с автоподсчётом я бы знатно попотел, ибо пришлось бы через весь экран глазами "прыгать"). Массив я уже дописал для скрина, дабы было понятно, что всё получилось вполне компактно и лишних движений глазами практически не нужно делать.
Ну, раз уж на то пошло, то...

static const fmt_str[] =
"INSERT INTO house("
"house_name,house_cost,up_keep,up_keep_left,"
"buyout,interior,car,house_lock,"
"rentabil,rent_cost,heal_upgrade,armour_upgrade,"
"pickup_x,pickup_y,pickup_z,pickup_a,"
"interior_x,interior_y,interior_z,interior_a"
") VALUES ("
"'%s','%d','%d','%d',"
"'%d','%d','%d','%d',"
"'%d','%d','%d','%d',"
"'%f','%f','%f','%f',"
"'%f','%f','%f','%f'"
")";
new query_str[];
format(
query_string, sizeof(query_string), fmt_string,
Houses[i][Houses_Name], Houses[i][Houses_Cost], Houses[i][Houses_UpKeep], Houses[i][Houses_UpKeepLeft],
Houses[i][Houses_Buyout], Houses[i][Houses_Interior], Houses[i][Houses_Car], Houses[i][Houses_Lock],
Houses[i][Houses_Rentabil], Houses[i][Houses_RentCost], Houses[i][Houses_HealUpgrade], Houses[i][Houses_ArmourUpgrade],
Houses[i][Houses_PickupX], Houses[i][Houses_PickupY], Houses[i][Houses_PickupZ], Houses[i][Houses_PickupA],
Houses[i][Houses_InteriorX], Houses[i][Houses_InteriorY], Houses[i][Houses_InteriorZ], Houses[i][Houses_InteriorA]
);

Я разделил форматную строку на несколько строк кода и сгруппировал в ней названия столбцов из БД со значениями - довольно простой способ убедиться, что ничего не упустил. Впрочем, время на написание кода я считать не возьмусь, поскольку не привык работать с запросами (к тому же, у меня нет доступа к твоему коду, ту же форматную строку пришлось переписывать и додумывать по скрину).


P.S.: Надеюсь, в твоей системе домов у игроков нет возможности напрямую изменять содержимое поля Houses_Name.

[DeimoS]

Даже не знаю, что и сказать.

Иными словами, в коде таких ошибок я, соответственно, не допускаю. Просто потому что в коде я пишу формулу с нуля, а тут заменил лишь sizeof, дабы была видна разница "ручного" подсчёта и "автоматического"


Это справедливо только для тех случаев, когда в формуле есть что-то с "запасом".

Я и не спорю. Это сказано было лишь к слову. Как уже выше сказал, в "боевых" условиях ещё никогда не было такой проблемы, просто потому что формулу составляю с нуля и понимаю, что нужно быть внимательным.


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

Я не подразумевал под словами "размер строки" понятия, связанного с программированием. Это просто плохая привычка и не более.

Хотя, к слову, я никогда раньше не встречал такого ярого контроля этих двух понятий, хоть и перечитал кучу форумов по программированию. Всегда, когда о строке говорят как просто о строке, а не строке и массиве, люди правильно понимали смысл этой фразы. Ну да ладно, тут нет смысла противится.


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

Вот именно поэтому я и говорю, что ты придираешься к тексту :) Мне кажется, и без лишних объяснений понятно, что формула, помимо замены "sizeof" на "45", не претерпела никаких изменений (это видно по её виду). А ты пытаешься из этого какие-то аргументы высосать при том, что изначально в моём сообщении и про определения не было какой-то речи, и про правильное составление формулы. В нём просто показывался визуальный вид двух вариантов и не более. Так что не очень понятно зачем ты до сих пор строишь свои аргументы именно на придирках.

И да, я не провожу каких-то сложных математических вычислений в уме. Когда вижу, что редактор, например, показывает мне "47", то просто начинаю считать на убывание все символы спецификаторов, контролируя себя мышкой (дабы не пропустить символ или не посчитать его дважды). То бишь, вижу спецификатор "%s" и сначала отнимаю "s", в голове держа число "46", а потом отнимаю "%", держа "45". Думаю, понятно, что на такой перерасчёт уходят считанные миллисекунды.


Собственно, в чём и отличие наших подходов к подсчёту: твой способ - для тех, кому нужна скорость написания, мой - для тех, кому важнее правильность расчётов и надёжность. Можешь апеллировать к тому, что работать с форматной строкой, вынесенной в отдельный массив, неудобно, но лично я не вижу никаких проблем в том, что строка смещена на сантиметр или два выше вызова format.

Как же лихо ты упускаешь составление формулы, с которой страдает достаточно много народа, что пользуется твоим способом (за пруфами можешь на p-i сходить, глянув какой-нибудь раздел с командами, например). Не говоря уже о случаях, когда у нас есть несколько разных строк :)

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



Я разделил форматную строку на несколько строк кода и сгруппировал в ней названия столбцов из БД со значениями - довольно простой способ убедиться, что ничего не упустил. Впрочем, время на написание кода я считать не возьмусь, поскольку не привык работать с запросами (к тому же, у меня нет доступа к твоему коду, ту же форматную строку пришлось переписывать и додумывать по скрину).

Ну всё то же самое можно и прямо в format сделать, если что.



P.S.: Надеюсь, в твоей системе домов у игроков нет возможности напрямую изменять содержимое поля Houses_Name.

Во-первых, не в моей :) Это, вроде как, система Open-GTO, если заказчик не переписывал/изменял её.
Во-вторых, естественно, нет :) Да и если ты намекаешь на инъекцию, то этот код просто заполняет таблицу данными из массива (да, в Open-GTO данные о домах/бизнесах дублируются и в массиве, и в файле(хотя сейчас это БД). И это старый вариант кода, от которого я уже отказался), если вдруг она пуста, поэтому игрок никак не влияет на этот код.

[Daniel_Cortez]

Я не подразумевал под словами "размер строки" понятия, связанного с программированием. Это просто плохая привычка и не более.
Даже если предположить, что это была просто путаница в словах и не более, мы всё же находимся на форуме, посвящённом программированию.



я не провожу каких-то сложных математических вычислений в уме
Это не исключает ошибок от человеческого фактора.



Как же лихо ты упускаешь составление формулы, с которой страдает достаточно много народа, что пользуется твоим способом (за пруфами можешь на p-i сходить, глянув какой-нибудь раздел с командами, например). Не говоря уже о случаях, когда у нас есть несколько разных строк :)
Если ты про вероятность ошибки при подсчёте длины форматируемых значений, то я уже говорил, и не раз, что она и при твоём подходе останется. Избавиться от неё можно разве что лишь написав какую-нибудь программу с графическим интерфейсом специально для подсчёта. Но, во-первых, ИМХО, это того не стоит, а во-вторых, это не исключит человеческого фактора полностью (вместо неправильного подсчёта будет вероятность неправильного ввода данных).



И ты, вроде, всегда за компактность кода ведь, не? Противник "развернутой" записи, ибо нужно экономить вертикальное пространство. Как-то странно от тебя слышать, что вариант, который и больше времени занимает, и усложняет/раздувает код - эт норм. Хотя нет, я понимаю почему ты так говоришь, но не понимаю, почему предпочитаешь игнорировать все проблемы своего метода, которые перетекли из "ручного" подсчёта и приумножились?
Ты точно что-то путаешь, я, наоборот, против чрезмерной экономии вертикального пространства, т.к. это приводит к длинным строкам кода, из-за которых постоянно приходиться тянуться к полосе горизонтальной прокрутки в редакторе (сначала чтобы прочитать строку до конца, а затем чтобы вернуть область видимости в прежнее положение, дабы можно было начать читать следующую строку).
И что именно ты называешь "всеми проблемами"? То, что форматная строка отделена от вызова format? В простых примерах с малым количеством форматируемых аргументов это не проблема, а если аргументов много и форматная строка большая, то переводить взгляд придётся при любом подходе.

[DeimoS]

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

Так я и не отрицаю этого. А ты почему-то предпочитаешь факт ошибки приписывать именно для "ручного" подсчёта, утверждая, что с твоим вариантом его не будет. Только ты почему-то упускаешь тот факт, что если человек не может "вручную" нормально подсчитать, делая ошибки по невнимательности, то с твоим вариантом у него не меньше шансов допустить ошибку при составлении формулы (а то и больше, ибо из-за явных вычитаний спецификаторов длина формулы увеличивается на 3 символа для каждого спецификатора).

И смотри как получается на деле.
Ты приписываешь своему методу более точный подсчёт, ибо при "ручном" подсчёте есть шанс ошибиться, но факт в том, что и твой вариант не защищён от ошибок при написании формулы (и упор на меньшее число ошибок ты делаешь как сейчас, так и в теме с "разрушением мифов").
Ты говоришь про скорость изменения размера массива при изменении строки без изменения спецификаторов, но почему-то умалчиваешь, что в большинстве случаев само расписывание всей этой мишуры со "static const" и "sizeof" будет отнимать больше времени, чем "ручной" подсчёт. А с учётом того, что большая часть строк в скриптах никогда и не меняется, на деле ты лишь теряешь кучу времени с таким вот методом подсчёта.

И, если говорить про ту тему с мифом, то ты почему-то делаешь упор на то, что при "ручном" подсчёте размер массива обязательно записывается одним числом, что крайне странно.


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

Про горизонтальное пространство и так понятно. Я тебе говорю, например, про такие ситуации:

if(IsPlayerAdmin(playerid))
{
SendClientMessage(playerid, -1, "Вы админ");
}
Если мне не изменяет память, не так давно ты мне писал на этот счёт, говоря, что скобки тут лишние и лишь тратят вертикальное пространство.


И что именно ты называешь "всеми проблемами"? То, что форматная строка отделена от вызова format? В простых примерах с малым количеством форматируемых аргументов это не проблема, а если аргументов много и форматная строка большая, то переводить взгляд придётся при любом подходе.

Давай поступим проще: распиши все плюсы своего метода, которые ты видишь в нём. Прямо форумным списком. А я уже в следующем сообщении рапишу минусы твоего метода и преимущества "ручного" подсчёта

[Daniel_Cortez]

А ты почему-то предпочитаешь факт ошибки приписывать именно для "ручного" подсчёта, утверждая, что с твоим вариантом его не будет.
Это уже твои додумки, не более. Я такого не утверждал (или, во всяком случае, никогда не намеревался утверждать). Ок, ещё раз:

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



Ты говоришь про скорость изменения размера массива при изменении строки без изменения спецификаторов, но почему-то умалчиваешь, что в большинстве случаев само расписывание всей этой мишуры со "static const" и "sizeof" будет отнимать больше времени, чем "ручной" подсчёт.
Во-первых, если ты про данное обсуждение, то я этого не упоминаю только потому, что ты сам уже сказал об этом. Зачем повторять одно и то же дважды?
Во-вторых, я уже не раз говорил, что мой метод для тех, кому важна правильность подсчёта и скорость отходит на второй план.



И, если говорить про ту тему с мифом, то ты почему-то делаешь упор на то, что при "ручном" подсчёте размер массива обязательно записывается одним числом, что крайне странно.
Не припоминаю, чтобы писал о таком в цикле уроков про мифы. Если же ты про урок с моим методом подсчёта, я уже давно начал готовить обновлённый вариант с исправлением множества недочётов и планирую закончить его, когда появится свободное время после открытия Pro-Pawn Wiki.



Про горизонтальное пространство и так понятно. Я тебе говорю, например, про такие ситуации:

if(IsPlayerAdmin(playerid))
{
SendClientMessage(playerid, -1, "Вы админ");
}
Если мне не изменяет память, не так давно ты мне писал на этот счёт, говоря, что скобки тут лишние и лишь тратят вертикальное пространство.
Сколько не изучал чужой код на Си-подобных языках, видел подобное только когда скобки есть ещё и в ветке else, внутри которой больше одного предложения. И если в каком-то коммите после изменений в ветке if (без else) оставалось только одно предложение, фигурные скобки, как правило, убирались. Правда, фигурные скобки в каждом if прописаны обязательным требованием в нескольких популярных проектах на JavaScript - не знаю, почему (могу предположить, что сообщество просто подхватило это правило на волне хайпа какого-нибудь очередного модного фреймворка, в котором это правило было изначально из-за личных предпочтений одного автора).
Поэтому уверен, практически любой адекватный программист (любители смузиJavaScript не в счёт :) ) скажет, что от фигурных скобок в твоём примере попросту нет никакой пользы. Скажешь тогда, что каждый программист - ярый сторонник экономии вертикального пространства?



Давай поступим проще: распиши все плюсы своего метода, которые ты видишь в нём. Прямо форумным списком. А я уже в следующем сообщении рапишу минусы твоего метода и преимущества "ручного" подсчёта
Скажу как есть: я устал повторять, что мой метод не избавляет от всех ошибок (хоть и снижает вероятность конкретных видов ошибок за счёт автоматизации) и он больше подходит для тех, кому точность расчётов важнее скорости набора текста на клавиатуре.

Предлагаю такой вариант: я распишу все плюсы и минусы (по мере своих знаний) в обновлённом уроке, о котором упомянул выше, и там ты попробушь доказать, что мой метод неправильный. Тем более, это будет куда более приемлемое место для подобных обсуждений (напомню, мы сейчас находимся в теме с мануалом; не можем же мы вечно "угонять" чужую тему?)

[DeimoS]

Часть высказываний оставлю без ответа, ибо мы уже от темы отходить начали и это больше в полемику превратилось. Без обид :blush2:


Это уже твои додумки, не более. Я такого не утверждал (или, во всяком случае, никогда не намеревался утверждать). Ок, ещё раз:
"чем больше вещей стараешься делать в уме, тем больше вероятность ошибки"
и таких вещей больше в твоём методе за счёт подсчёта в уме части формулы. Чисто логика.
Ты действительно считаешь, что сделать ошибку, отнимая в уме по одному символу от получившегося числа, гораздо легче, чем составлять формулу для нескольких строк с кучей спецификаторов в твоём варианте?



Не припоминаю, чтобы писал о таком в цикле уроков про мифы.

https://i.imgur.com/oLjrNKY.png
Тут ты описываешь вариант с формулой так, будто он возможен только в твоём варианте (иначе непонятно зачем ты вообще этот пункт написал)


Скажу как есть: я устал повторять, что мой метод не избавляет от всех ошибок (хоть и снижает вероятность конкретных видов ошибок за счёт автоматизации) и он больше подходит для тех, кому точность расчётов важнее скорости набора текста на клавиатуре.

Ну ладно, не так выразился. Не от всех ошибок, а от каких-то конкретных.
В любом случае, снижая вероятность допустить ошибку, например, при подсчёте размера строки, ты увеличиваешь вероятность допустить ошибку при составлении формулы, так как она становится более громоздкой.
Я, собственно, тоже устал повторять, что практически каждое твоё "снижение вероятности" имеет негативные последствия, которые, по сути, нивелируют всю пользу. И доказательства моих слов лежат в открытом доступе на том же p-i, где люди, видимо, начитавшись твоих статей, пытаются всунуть твой способ во все возможные щели, но на деле делают только хуже, либо усложняя код, либо составляя неправильно формулу.
КПД у твоего метода такой, что польза начинает проявляться только на строках, которые очень часто изменяются (а таких не так уж и много бывает). В остальных ситуациях гораздо разумнее потратить чуть больше времени и внимания (хотя, при должной сноровке, его может тратиться и меньше, как я уже выше говорил), но сделать код более компактным, простым и читаемым, а не раздувать его на кучу строк ради ситуаций, которые никогда и не случатся (я про изменение строки сейчас говорю, если что).

[vovandolg]

Так, хорошо, ушёл я в афк, накидали запросов оверкучу, возвращаюсь из афк что дальше будет?))
Глазами пробежался не тестил, но вроде как такого нету что если весь сервер начнёт давить запросами то окажется последний, а как же остальные?
А что если весь сервер в сговор войдёт и закидает запросами?)) Это намёк на какой нибудь простенький антифлуд что ле))

[execution]

Так, хорошо, ушёл я в афк, накидали запросов оверкучу, возвращаюсь из афк что дальше будет?))
Глазами пробежался не тестил, но вроде как такого нету что если весь сервер начнёт давить запросами то окажется последний, а как же остальные?
А что если весь сервер в сговор войдёт и закидает запросами?)) Это намёк на какой нибудь простенький антифлуд что ле))

Это только первая версия, буду дополнять в следующей.

[whale]

Это только первая версия, буду дополнять в следующей.

4 месяца уже прошло)
Может пора вторую версию опубликовать?