CMD: id

[StevenH]

Почему 3 для i? Трудно поверить, но возможно на его сервер зайдет 1000 игроков.

И? Даже если будет 1000 ID (а такое иногда бывает, хотя ID должны быть от 0 до 999), то у такого игрока должно быть имя в 24 символа (тогда возможно 1 символ не покажется), но такого никогда не будет, т.к. MAX_PLAYER_NAME равен 24, а максимальная длина в имени - 20.

Поэтому даже если игрок будет с 1000 ID и именем в 20 символов, в любом случае будет все корректно показано.

[Kucklovod00]

И? Даже если будет 1000 ID (а такое иногда бывает, хотя ID должны быть от 0 до 999), то у такого игрока должно быть имя в 24 символа (тогда возможно 1 символ не покажется), но такого никогда не будет, т.к. MAX_PLAYER_NAME равен 24, а максимальная длина в имени - 20.

Поэтому даже если игрок будет с 1000 ID и именем в 20 символов, в любом случае будет все корректно показано.

А точно, спасибо. Прошу прощения.

[ziggi]

И? Даже если будет 1000 ID (а такое иногда бывает, хотя ID должны быть от 0 до 999), то у такого игрока должно быть имя в 24 символа (тогда возможно 1 символ не покажется), но такого никогда не будет, т.к. MAX_PLAYER_NAME равен 24, а максимальная длина в имени - 20.

Поэтому даже если игрок будет с 1000 ID и именем в 20 символов, в любом случае будет все корректно показано.

Максимальная длина имени - 24 символа, можно задать с помощью SetPlayerName, а 20 символов - это ограничение клиента.
А про 1000 ID - это вряд ли.

[Daniel_Cortez]

Другое дело, что есть возможность увеличения макс. кол-ва слотов в будущих версиях, ибо есть проекты с 2 и более серверами на 1000 игроков - и тогда уже понадобится 4 ячейки под ID игрока. Но кому какое дело? Нужно жить настоящим.

UPD:

DeimoS, это такая шутка, да?

[StevenH]

Максимальная длина имени - 24 символа, можно задать с помощью SetPlayerName, а 20 символов - это ограничение клиента.
А про 1000 ID - это вряд ли.

Такое бывает, но редко (я про 1000 ID). Помнится играл на открытии Diamond RP (да и не только при открытии, такое бывает когда фулл сервер), то в ТАБе показывало Online: 1001, а ID`s у игроков в ТАБе был от 0 до 1000 (соответственно 1001 игрок), но больше никогда не видел. Что касается в клиенте, там я никогда 1001 игрока не видел.

[Geebrox]

DeimoS, это такая шутка, да?

я думаю это связано с тем, что он перевел message_template прямо в процесс форматирование (что не советую делать)

[DeimoS]

UPD:

DeimoS, это такая шутка, да?

Ни в коем случае. Решением той темы, что вы тут подняли, является создание макроса, который бы хранил нужное значение (собственно, я так и делал в своём моде). Но предлагать автору делать такой макрос лишь для данного случая - довольно странная идея, которая приведёт ко всем известному RLS, где можно найти с десяток функций для получения ника игрока. Угадывать наперёд: сколько же там будет максимальный онлайн в следующих версиях - тоже ничего хорошего, ибо получится тот же самый вариант с магическими числами. Поэтому логично просто взять значение с расчётом на максимальное значение Integer в Pawn, дабы избавить автора от всех проблем (ну разве что 11 можно на 10 изменить, ибо онлайн не будет отрицательным, но тогда и от MAX_PLAYER_NAME следовало отнимать 4).

Вообще довольно странно было поднимать эту тему в разделе с вопросами, где всё затеряется. Если уж и пытаться учить кого-либо уму-разуму, то стоит писать статью.

я думаю это связано с тем, что он перевел message_template прямо в процесс форматирование (что не советую делать)

А я не советовал бы ради строки в 10 символов добавлять какой-то не нужный автоподсчёт этого размера в 10 символов, который всё равно потребует составления формулы. Да ещё и строки, содержимое которой будет редактироваться лишь раз при написании кода и, в крайнем случае, ещё пару раз позже. Раздувая код, ты лишь усложняешь его поддержку в будущем, не избавив себя ровно ни от чего, а лишь убив читаемость.

[Geebrox]

А я не советовал бы ради строки в 10 символов добавлять какой-то не нужный автоподсчёт этого размера в 10 символов, который всё равно потребует составления формулы. Да ещё и строки, содержимое которой будет редактироваться лишь раз при написании кода и, в крайнем случае, ещё пару раз позже. Раздувая код, ты лишь усложняешь его поддержку в будущем, не избавив себя ровно ни от чего, а лишь убив читаемость.

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

[DeimoS]

Ты не знаешь, что он хочет выводить в сообщение, может он еще добавит строку с размером на 20 символов.

Это не отменяет того факта, что в будущем он не станет изменять эту строку постоянно.

Я наоборот не усложняю читабельность, как это выглядит у тебя.

Как раз таки в твоём случае он и усложняется, ибо:
1) Убивается синтаксис format (не так наглядно видно где находится сама форматируемая строка, а где уже остальные параметры. С этим так же будет связано то, что опишу в конце)
2) Лишняя строка. Точнее, на каждый такой подсчёт будет лишняя строка. В итоге, часть твоего кода будет занимать именно эти строки, которые для тебя никакой смысловой нагрузки не несут, а только разбавляют код.

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

Серьёзно? Удобнее? А теперь представим, что у нас есть форматирование в цикле с кучей кода, типа:

  Открыть/закрыть

    static const message_template[] = "ID: %d | Имя: %s ID: %d | Имя: %s ID: %d | Имя: %s ID: %d | Имя: %s ID: %d | Имя: %s";
    new
        message[формула];
        player_name[MAX_PLAYER_NAME],
        bool:isfound = false;

    SendClientMessage(playerid, -1, !"Результаты поиска:");
    
    for(new i = 0; i < GetPlayerPoolSize(); i++)
    {
        if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
        {
            else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
            {
                else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                {
                    else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                    {
                        else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                        {
                            else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                            {
                                continue;
                            }
                            continue;
                        }
                        continue;
                    }
                    continue;
                }
                continue;
            }
            continue;
        }
        else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
        {
            else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
            {
                else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                {
                    else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                    {
                        else if(!GetPlayerName(playerid, player_name, MAX_PLAYER_NAME))
                        {
                            continue;
                        }
                        continue;
                    }
                    continue;
                }
                continue;
            }
            continue;
        }
        else if(strfind(player_name, name_part, true))
        {
            isfound = true;
            format(message, sizeof(message), message_template, i, player_name, i, player_name, i, player_name, i, player_name, i, player_name);
            SendClientMessage(playerid, -1, message);
        }
    }  

(пример, конечно, утрированный, но на практике таких ситуаций, когда между объявлением массива со строкой и самим форматированием куча строк, можно найти много)

Если я решу изменить порядок переменных в массиве, мне придётся изрядно так попотеть, чтоб сначала найти глазами static const, подсчитать порядковый номер нужного заполнителя, потом найти format (который никак синтаксически выделяться не будет, ибо нет строки в нём) и лишь потом начать искать нужную переменную, рискуя промахнуться, ибо все параметры в format сливаются.
Не говоря уже о том, что с самой формулой часто гораздо больше мороки, нежели составление её вручную (можем даже провести тест, кто быстрее будет составлять формулы: ты, с твоим автоподсчётом или я, с функцией подсчёта символов выделенного текста в Sublime Text)


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

[Geebrox]

Это не отменяет того факта, что в будущем он не станет изменять эту строку постоянно.

Вот именно! Для этого и нужно такой медот, чтобы удобно было поддерживать изменение строки. А ты говорил:

Да ещё и строки, содержимое которой будет редактироваться лишь раз при написании кода и, в крайнем случае, ещё пару раз позже.

Серьёзно? Удобнее? А теперь представим, что у нас есть форматирование в цикле с кучей кода, типа:

(пример, конечно, утрированный, но на практике таких ситуаций, когда между объявлением массива со строкой и самим форматированием куча строк, можно найти много)

Да серьезно, удобнее. Так как мне всего лишь нужно выйти из тела цикла и перед моими глазами будет содержимое формата строки.
А в твоем случае, если будет такой код, ты будешь искать этот сранный format по всем блокам кода

Если я решу изменить порядок переменных в массиве, мне придётся изрядно так попотеть, чтоб сначала найти глазами static const, подсчитать порядковый номер нужного заполнителя, потом найти format (который никак синтаксически выделяться не будет, ибо нет строки в нём) и лишь потом начать искать нужную переменную, рискуя промахнуться, ибо все параметры в format сливаются.[/SIZE]

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

Никто не спорит, что вилкой есть спагетти удобнее, нежели ложкой. Но это не значит, что и суп будет удобно есть вилкой.

Совершенно верно, только тебе необходимо определить кто тут пытается есть суп вилкой м?