Добро пожаловать на Pro Pawn - Портал о PAWN-скриптинге.
Страница 2 из 2 ПерваяПервая 1 2
Показано с 11 по 19 из 19
  1. #11
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от PawnoNoob Посмотреть сообщение
    Исключается ли возможность "краша" или каких-либо других проблем при редактировании и компиляции кода, если адаптировать редактор под pawn по Вашей инструкции? (Ну, например, кодировка (символы всякие))
    Ну начнём с того, что данный редактор, в отличии от того же Pawno, не работает с файлом напрямую, а загружает его в память и впоследствии все изменения производятся именно с загруженной копией. Обращение к основному файлу происходит лишь при сохранении этого файла и когда, например, происходит компиляция, редактор сначала сохраняет файл, а после уже запускает компилятор. В общем, возможность "краша" если и есть, то она уж точно ниже, нежели у Pawno. Но, естественно, нужно редактор настроить правильно.

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

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

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  2. Пользователь сказал cпасибо:
    PawnoNoob (09.05.2017)
  3. #12
    Аватар для Nexius_Tailer
    Пользователь

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от Nash_Brigers Посмотреть сообщение
    В теории правильнее использовать локальную переменную, но на практике - глобальную. Это моё мнение.
    p.s. DC в этом плане против и ругается...
    На одного человека ругается больше, на одного меньше. А если судить по объективным причинам, то это немного как с goto - юзая в ситуациях, где это не необходимо, никакого реального профита человек не вынесет, а лишь запутает свой код и повысит шансы на допущение ошибок.
    С наличием глобальной переменной нужно всегда следить, чтобы она вовремя форматировалась и полностью перезаписывалась новыми данными (особенно актуально, если к ней применяются ещё и strcat и прочие, которые её не чистят), да ещё и в памяти почти всегда, когда нужна она там ненадолго, но это уже не так важно. С локальной же можно быть уверенным: в каком блоке (теле) её объявил - в том она и проработает, и по повторному вызову функции можно быть также полностью уверенным, что строка чистая.

    Хотя есть и третий вариант: юзать static. Объявляется в локальных областях, но живёт в итоге всё оставшееся время работы, как глобальная, т.е. чистить её также нужно будет. Возможно, с таким подходом будет чуть нагляднее, чем с юзанием глобальных переменных вообще.

    Цитата Сообщение от SooBad Посмотреть сообщение
    P.S. Размер маленьких строк можно считать вручную, либо использовать сервисы по подсчёту символов(в некоторых редакторах это уже предусмотрено). При работе с большИм кол-вом спецификаторов следует использовать метод, описываемый DC. В принципе, можно всё вручную считать, но дорого ли такому человеку время?
    А я вот немного не понимаю. С изменением текста, как правило, меняется и его содержание, и его длина, и количество этих спецификаторов, что в итоге требует и правок формул подсчётов. Тем самым, смысл от такого удобства сомнительный. Хотя возможно кому-то и заходит...
    Последний раз редактировалось Nexius_Tailer; 09.05.2017 в 00:14.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

  4. Пользователь сказал cпасибо:
    PawnoNoob (09.05.2017)
  5. #13
    Аватар для SooBad
    Пользователь

    Статус
    Оффлайн
    Регистрация
    02.04.2017
    Адрес
    Краснодар
    Сообщений
    83
    Репутация:
    20 ±
    Цитата Сообщение от Nexius_Tailer Посмотреть сообщение
    А я вот немного не понимаю. С изменением текста, как правило, меняется и его содержание, и его длина, и количество этих спецификаторов, что в итоге требует и правок формул подсчётов. Тем самым, смысл от такого удобства сомнительный. Хотя возможно кому-то и заходит...
    С локальным массивом то же самое.
    Придётся вручную подсчитывать добавленные символы и втюхивать в массив недостающее кол-во ячеек.
    Профита также нет.
    Глобальный массив - это уже что-то из оперы RLS...
    Единственное возможное применение вижу только в форматировании строк просто гигантских размеров, типо сводок общих правил и подобного. Хотя даже тут, можно банально скрепить строки, разбив общий массив для форматирования на несколько локальных.

  6. #14
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от SooBad Посмотреть сообщение
    С локальным массивом то же самое.
    Придётся вручную подсчитывать добавленные символы и втюхивать в массив недостающее кол-во ячеек.
    Профита также нет.
    Nexius имел ввиду то, что вариант, описанный Кортезом, не так хорош на деле, как о нём кричат ярые защитники.
    Особенно радует, когда таким вот методом пытаются подсчитать строку из 10 символов, которую больше никогда не будут редактировать в дальнейшем (если зайти на п-и в раздел команд, можно кучу примеров найти этого ужаса).
    Или когда массив с текстом объявляется в одном месте, а сам format через несколько строк ниже. И мало того, что все параметры начинают сливаться
    PHP код:
    //

    format(stringsizeof(string), fmt_strplayeridstringplayeridstringplayeridstring);// Вот это разве удобно? Чтоб понять где находится третий параметр, нужно прилично так вглядываться. А если рядом будет другой код - всё ещё плачевней становится

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

    Цитата Сообщение от SooBad Посмотреть сообщение
    Единственное возможное применение вижу только в форматировании строк просто гигантских размеров, типо сводок общих правил и подобного. Хотя даже тут, можно банально скрепить строки, разбив общий массив для форматирования на несколько локальных.
    Это лучше делать локально и с применением static. Выискивать глобальный массив, что находится за сотню-другую строк от его места применения - такое себе удовольствие.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

    Широко известно, что идеи стоят 0.8333 цента каждая (исходя из рыночной цены 10 центов за дюжину).
    Великих идей полно, на них нет спроса.
    Воплощение идеи в законченную игру требует долгой работы,
    таланта, терпения и креативности, не говоря уж о затратах денег, времени и ресурсов.
    Предложить идею просто, воплотить – вот в чём проблема

    Steve Pavlina

  7. #15
    Аватар для Nexius_Tailer
    Пользователь

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от SooBad Посмотреть сообщение
    С локальным массивом то же самое.
    Придётся вручную подсчитывать добавленные символы и втюхивать в массив недостающее кол-во ячеек.
    Профита также нет.
    На опыте лично для себя нашёл оптимальный вариант: выделять заведомо чуть больше. Для удобства это чаще всего числа, являющиеся степенью двойки (16, 32, 64, 128) для не очень больших строк, где этот хвост из пустых ячеек ни на что не повлияет. А считать более точно резонно уже более громоздкие массивы, да и то можно, как уже сказал выше, объявить через static и не париться. Так что профит от точного подсчёта ячейка в ячейку вообще в принципе под вопросом, если уж так рассуждать.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

  8. #16
    Аватар для SooBad
    Пользователь

    Статус
    Оффлайн
    Регистрация
    02.04.2017
    Адрес
    Краснодар
    Сообщений
    83
    Репутация:
    20 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Nexius имел ввиду то, что вариант, описанный Кортезом, не так хорош на деле, как о нём кричат ярые защитники.
    Особенно радует, когда таким вот методом пытаются подсчитать строку из 10 символов, которую больше никогда не будут редактировать в дальнейшем (если зайти на п-и в раздел команд, можно кучу примеров найти этого ужаса).
    Или когда массив с текстом объявляется в одном месте, а сам format через несколько строк ниже. И мало того, что все параметры начинают сливаться
    PHP код:
    //
    format(stringsizeof(string), fmt_strplayeridstringplayeridstringplayeridstring);// Вот это разве удобно? Чтоб понять где находится третий параметр, нужно прилично так вглядываться. А если рядом будет другой код - всё ещё плачевней становится
    // 
    так ещё и приходится постоянно сверяться с текстом массива, дабы определить, совпадает ли порядок спецификаторов с порядком переменных. И постоянно приходится выискивать нужную переменную/спецификатор, ибо чем больше их становится, тем труднее сходу ориентироваться в этой каше кода.
    В общем, этот метод нужно использовать исключительно там, где он будет полезен, а не везде, где только можно. Ибо чаще получается так, что и подсчитать вручную было бы быстрее размер, и код впустую раздулся на несколько лишних строк.
    Это лучше делать локально и с применением static. Выискивать глобальный массив, что находится за сотню-другую строк от его места применения - такое себе удовольствие.
    Так я про то же самое и писал)

    Цитата Сообщение от Nexius_Tailer Посмотреть сообщение
    На опыте лично для себя нашёл оптимальный вариант: выделять заведомо чуть больше. Для удобства это чаще всего числа, являющиеся степенью двойки (16, 32, 64, 128) для не очень больших строк, где этот хвост из пустых ячеек ни на что не повлияет. А считать более точно резонно уже более громоздкие массивы, да и то можно, как уже сказал выше, объявить через static и не париться. Так что профит от точного подсчёта ячейка в ячейку вообще в принципе под вопросом, если уж так рассуждать.
    Правда инициализация пустых ячеек будет занимать на пару микросекунд дольше
    Так суть-то и в том, что это многовариационный момент. Автор спрашивает про удобство конкретного способа. Но порой, даже задействование метода, описанного DC - будет не менее комфортным. Ну, по крайней мере в плане экономии времени, особенно при подсчёте строк длинной в 150-200 а то и больше символов (зависит от ситуации).
    Наиболее рациональный вариант - редактор. Можно даже перенаполнять массив лишними ячейками(как ты и говоришь), не вычитая длину спецификаторов, а лишь прибавляя величину их макс.значения.

  9. #17
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Ок, я обновил свой урок по подсчёту размера форматного массива, добавив список преимуществ/недостатков метода, а также добавил советы по поводу того, где подсчёт следует использовать, а где он будет лишним.

    Буду рад услышать ваше мнение, если не согласны по какому-либо из критериев в добавленном списке. И да, спасибо всем тем в этой теме, кто предоставил критику по поводу того метода.


    Касаемо глобальных/локальных массивов, во многих случаях можно обойтись локальными. Рассмотрим это на примере команды /admins, выводящей список админов онлайн.
    • Стандартный размер секции стека/кучи в Pawn - 16384 байт или 4096 ячеек. Из них будет безопасно взять 4000 под массив для выводимого текста - остальные 96 оставим под цепочку вызовов (OnPlayerCommandText -> [командный процессор] -> CMD:admins) и прочие "непредвиденные расходы". Если же массивов больше одного, то их суммарный размер должен быть не более 4000.
    • SendClientMessage и ShowPlayerDialog прекрасно понимают упакованные строки - так почему же не использовать их? В результате емкость увеличится в 4 раза и в итоге ёмкость составит примерно 16000 символов.
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

  10. #18
    Аватар для Nexius_Tailer
    Пользователь

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от SooBad Посмотреть сообщение
    Можно даже перенаполнять массив лишними ячейками(как ты и говоришь), не вычитая длину спецификаторов, а лишь прибавляя величину их макс.значения.
    С этим ничего по сути не изменится. При изменении строки, в т.ч. добавлении спецификаторов тебе всё равно нужно будет что-то прибавлять, что в итоге выйдет той же формулой, просто без отниманий их длин

    Цитата Сообщение от Daniel_Cortez Посмотреть сообщение
    Касаемо глобальных/локальных массивов, во многих случаях можно обойтись локальными. Рассмотрим это на примере команды /admins, выводящей список админов онлайн.
    • Стандартный размер секции стека/кучи в Pawn - 16384 байт или 4096 ячеек. Из них будет безопасно взять 4000 под массив для выводимого текста - остальные 96 оставим под цепочку вызовов (OnPlayerCommandText -> [командный процессор] -> CMD:admins) и прочие "непредвиденные расходы". Если же массивов больше одного, то их суммарный размер должен быть не более 4000.
    • SendClientMessage и ShowPlayerDialog прекрасно понимают упакованные строки - так почему же не использовать их? В результате емкость увеличится в 4 раза и в итоге ёмкость составит примерно 16000 символов.
    Оно-то можно, но иногда реально проще и быстрее просто объявить через static и не опасаться того, что появись в этот момент где-то в этой области ещё пара подобных массивов, и все перестраховки в свой лимит на 4000 будут абсолютно бесполезными. И конечно в такой ситуации виноват будет скриптер, потому что недоглядел, но сам факт того, что это надёжнее и требует меньше телодвижений уже кажется более оптимальным вариантом. Но это касаемо реально больших массивов
    Последний раз редактировалось Nexius_Tailer; 09.05.2017 в 02:31.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

  11. #19
    Аватар для Daniel_Cortez
    "Это не хак, это фича"

    Статус
    Оффлайн
    Регистрация
    06.04.2013
    Адрес
    Novokuznetsk, Russia
    Сообщений
    2,192
    Репутация:
    2589 ±
    Цитата Сообщение от Nexius_Tailer Посмотреть сообщение
    Оно-то можно, но иногда реально проще и быстрее просто объявить через static и не опасаться того, что появись в этот момент где-то в этой области ещё пара подобных массивов, и все перестраховки в свой лимит на 4000 будут абсолютно бесполезными.
    Я этого и не отрицал. Собственно, в этом и заключается дилема: оптимальный расход ресурсов против удобства. Нет единственно верного решения, выбор должен строиться индивидуально для каждого случая.
    Индивидуально в ЛС по скриптингу не помогаю. Задавайте все свои вопросы здесь (click).

 

 
Страница 2 из 2 ПерваяПервая 1 2

Информация о теме

Пользователи, просматривающие эту тему

Эту тему просматривают: 1 (пользователей: 0 , гостей: 1)

Ваши права

  • Вы не можете создавать новые темы
  • Вы не можете отвечать в темах
  • Вы не можете прикреплять вложения
  • Вы не можете редактировать свои сообщения
  •