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

    Статус
    Оффлайн
    Регистрация
    08.12.2018
    Адрес
    Россия
    Сообщений
    146
    Репутация:
    25 ±
    Предложу свой форк foreach от ziggi: https://github.com/punkochel/foreach
    Тут просто добавлена совместимость с open.mp в силу изменений GetPool*Size, при инициализации инклуда.

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

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от punkochel Посмотреть сообщение
    Предложу свой форк foreach от ziggi: https://github.com/punkochel/foreach
    Тут просто добавлена совместимость с open.mp в силу изменений GetPool*Size, при инициализации инклуда.
    Можно было бы заодно тогда и fixes.inc учитывать, т.к. он их поведение также менял.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

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

    Статус
    Оффлайн
    Регистрация
    08.12.2018
    Адрес
    Россия
    Сообщений
    146
    Репутация:
    25 ±
    Да, спасибо. Добавлю.

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

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Как я понимаю, вопрос решён?

    Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
    Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.

      Открыть/закрыть
    Nexius же считает, что плагин должен сам волшебным образом подстраиваться под любой скрипт (видимо, в плагин нужно ИИ вшивать, который отдельно бы, после каждой компиляции, часами изучал исходники и определял то, сколько они должны, в идеале, обрабатываться), учитывая ещё и какие-то внешние нагрузки. Правда, сколько я ни пытался от него добиться ответа, он так и не уточнил, какую в этом случае должен давать полезную информацию плагин (да и примеров из других ЯП со схожими системами дать он не смог). Ибо я не вижу ничего полезного в замерах того, какую нагрузку выдаёт мод вместе с другими процессами, запущенными в системе. Эту задачу прекрасно выполняет какой-нибудь "Диспетчер задач" из Windows или команда "ps aux" для Linux. При этом, текущее назначение данного функционала мне вполне понятно (да и примеры подобного функционала в других ЯП имеются). Но непонятый гений Nexius не слушает никакие аргументы и всё равно настаивает на своём
    Последний раз редактировалось DeimoS; 19.01.2023 в 21:22.
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

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

    Steve Pavlina

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

    Статус
    Оффлайн
    Регистрация
    08.12.2018
    Адрес
    Россия
    Сообщений
    146
    Репутация:
    25 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Как я понимаю, вопрос решён?

    Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
    Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.

      Открыть/закрыть
    Nexius же считает, что плагин должен сам волшебным образом подстраиваться под любой скрипт (видимо, в плагин нужно ИИ вшивать, который отдельно бы, после каждой компиляции, часами изучал исходники и определял то, сколько они должны, в идеале, обрабатываться), учитывая ещё и какие-то внешние нагрузки. Правда, сколько я ни пытался от него добиться ответа, он так и не уточнил, какую в этом случае должен давать полезную информацию плагин. Ибо я не вижу ничего полезного в замерах того, какую нагрузку выдаёт мод вместе с другими процессами, запущенными в системе. Эту задачу прекрасно выполняет какой-нибудь "Процессор задач" из Windows. Но непонятому гению виднее
    Я согласен с Nexius. Дело в том что определять long_call_time для pawn-скриптов не самое лучшее занятие. pawn.cc это самый примитивный компилятор, который мало что умеет оптимизировать и ни о каких inline-функциях тут и речи не идет.
    Если мы в GameModeInit вызовем функцию, которая создает объекты на сервере, то мы в любом случае получим сообщение long_call_time.
    Если-же мы пишем мод в одном файле, дублируя многие участки кода и т.д. то наверное мы могли бы добиться чуть большей производительности. Но если мы пишем "модульный" мод, в котором системы раскиданы по различным директориям и использование модулей осуществляется через функции, то long_call_time будет выдавать нам сообщение довольно часто, а об использовании рекурсии можно вообще забыть, если бояться подобных сообщений.

    UPD:
    Да, на beta стадии можно ради спортивного интереса посмотреть какие функции нагружают систему сильнее, но как таковой практической пользы эта функция не несет.
    Последний раз редактировалось punkochel; 19.01.2023 в 21:31.

  8. Пользователь сказал cпасибо:
    Nexius_Tailer (20.01.2023)
  9. #16
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от punkochel Посмотреть сообщение
    Я согласен с Nexius. Дело в том что определять long_call_time для pawn-скриптов не самое лучшее занятие. pawn.cc это самый примитивный компилятор, который мало что умеет оптимизировать и ни о каких inline-функциях тут и речи не идет.
    Если мы в GameModeInit вызовем функцию, которая создает объекты на сервере, то мы в любом случае получим сообщение long_call_time.
    Если-же мы пишем мод в одном файле, дублируя многие участки кода и т.д. то наверное мы могли бы добиться чуть большей производительности. Но если мы пишем "модульный" мод, в котором системы раскиданы по различным директориям и использование модулей осуществляется через функции, то long_call_time будет выдавать нам сообщение довольно часто, а об использовании рекурсии можно вообще забыть, если бояться подобных сообщений.
    Эмм, так подбери актуальное значение для long_call_time, если уверен, что текущая конфигурация твоего скрипта работает достаточно эффективно для тебя, и не будет никаких "ложных" вызовов.

    Ты, видимо, тоже не особо понимаешь как работает "long_call_time", судя по написанному. Ибо всё, что она делает - замеряет то, как долго обрабатывается код в коллбэке, после сверяет результат со значением из "long_call_time" и если первое превышает второе - выдаёт предупреждение. Соответственно, всё, что тебе нужно - это замерить то, сколько у тебя обрабатывается тот же OnGameModeInit, а после вызвать в нём же "SetCrashDetectLongCallTime" и указать в неё замеренное ранее время с некоторым запасом. Всё, "ложные" срабатывания волшебным образом прекратились.
    А можешь поступить ещё более невероятным образом: отключить данный функционал через вызов "DisableCrashDetectLongCall" в OnGameModeInit для всего мода, а после включать его (EnableCrashDetectLongCall/SetCrashDetectLongCallTime) только для тех функций, время обработки которых тебе хотелось бы контролировать.
    В общем, как я уже как-то говорил Nexius - все ваши "ложные" срабатывания сугубо от того, что вы не понимаете для чего нужен данный функционал и как именно его использовать. Хотя вообще профилировщик - это достаточно тривиальная штука. И на тот же плагин "profiler" почему-то никто не кидается с криками: "Он сообщает мне о том, что мой код работает медленно!". А когда тот же самый профилировщик вставили в crashdetect (плагин, который существует для дебага), некоторые вдруг не опознали в профилировщике профилировщика (да и вообще, судя даже по твоему сообщению, не особо поняли с чем имеют дело и каким оно должно, по их мнению, быть на самом деле) и начали говорить про какой-то кривой функционал.

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

    Цитата Сообщение от punkochel Посмотреть сообщение
    UPD:
    Да, на beta стадии можно ради спортивного интереса посмотреть какие функции нагружают систему сильнее, но как таковой практической пользы эта функция не несет.
    Эмм, весь плагин "crashdetect" создан для отладки кода. Пускать вместе с ним сервер в прод = замедлять и без того не шустрый Pawn.
    А касаемо "спортивного интереса": ну когда ты будешь писать код либо на заказ, либо с целью создать что-то серьёзное, а не просто скриптики для себя в свободное время - тогда и поймёшь, зачем может понадобиться контролировать те или иные участки кода на предмет того, что они не обрабатываются дольше определённого времени (например, проверять то, что секундные таймеры срабатывают именно за секунду? Или что код в OnPlayerUpdate не вызывает серьёзных задержек?). И тут ты уже вспомнишь о "long_call_time", поблагодарив Y_Less за него, ибо тебе не придётся изобретать собственный велосипед или же пытаться вычленить нужную информацию из отчёта плагина "profiler", а будет готовое решение, которое легко интегрируется и управляется. Ну либо, потенциально, в проде игроки поймают лаги/диссинхроны и тебе придётся впопыхах страдать над оптимизацией
    Последний раз редактировалось DeimoS; 19.01.2023 в 21:58. Причина: Объединил сообщения
    Связаться со мной в VK можно через личные сообщения этой группы
    Заказы не принимаю

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

    Steve Pavlina

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

    Статус
    Оффлайн
    Регистрация
    08.12.2018
    Адрес
    Россия
    Сообщений
    146
    Репутация:
    25 ±
    Не понимаю почему ты так к этому прицепился. Но лично для меня, да и думаю что многих других тоже, эта функция скорее помеха чем фича, потому-то необходимо тратить время на её отключение, так как она включена по умолчанию. А для замера скорости тех или иных реализаций для меня прекрасно подходит этот Профайлер. Ну а замерять целые куски кода, которые определяются совокупностью тех или иных реализаций, как по мне это не то чем нужно заниматься.

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

    Подведу итог:
    В наше время программируя на pawn и при этом цепляться за каждый упущенный такт процессора это весьма сомнительная работа. Сейчас даже микроконтроллеры в будильнике мощнее чем в инженерных калькуляторах 2000-х годов.
    Подобное можно сравнить вот с этим:
      Открыть/закрыть
    Последний раз редактировалось punkochel; 19.01.2023 в 22:06.

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

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Ну и глупости от Nexius касаемо "long_call_time" советую не слушать. Человек не понял (и отказывается понимать) для чего создан данный функционал и зачем-то пытается своими странными выводами заразить других.
    Функция полезная, если хочется следить за тем, чтоб никакой участок кода в моде не обрабатывался дольше определённого количества миллисекунд (а если не хочется - уже указали на то, как её отключить). Просто требует ручной донастройки под конкретный скрипт.
    Той "глупости", которую и сам автор этого нововведения признаёт как дефект? Из предыдущего диалога это ты отказываешься понимать очевидную вещь: то, что даёт ложных больше, чем не ложных - изначально плохой инструмент. То, что не указывает на реальную причину, но лишь на следствие - изначально плохой инструмент. Конкретно у этого плоха сама задумка, потому что хорошая и относительно не заморочанная реализация в данном случае это много костылей по исправлению фундаментально неправильного подхода к детекту задержек.

    Цитата Сообщение от DeimoS Посмотреть сообщение
      Открыть/закрыть
    Nexius же считает, что плагин должен сам волшебным образом подстраиваться под любой скрипт (видимо, в плагин нужно ИИ вшивать, который отдельно бы, после каждой компиляции, часами изучал исходники и определял то, сколько они должны, в идеале, обрабатываться), учитывая ещё и какие-то внешние нагрузки. Правда, сколько я ни пытался от него добиться ответа, он так и не уточнил, какую в этом случае должен давать полезную информацию плагин (да и примеров из других ЯП со схожими системами дать он не смог). Ибо я не вижу ничего полезного в замерах того, какую нагрузку выдаёт мод вместе с другими процессами, запущенными в системе. Эту задачу прекрасно выполняет какой-нибудь "Диспетчер задач" из Windows или команда "ps aux" для Linux. При этом, текущее назначение данного функционала мне вполне понятно (да и примеры подобного функционала в других ЯП имеются). Но непонятый гений Nexius не слушает никакие аргументы и всё равно настаивает на своём
    Не, Nexius считает и неоднократно тебе писал о том, что плагин должен вполне себе реальными проверками учитывать внешние факторы физического сервера, на котором работает сервер самповский и иметь динамические лимиты таймингов (которые будут регулироваться фактом наличия достаточного количества доступных ресурсов для программы извне) вместо константных, которые тем более уж никак не дают реальную картину происходящего в павн скриптах, если сервер не вывозит вообще не из-за них. Дальнейшее выдуманное уже поверх всего этого посторонними челами, это, как раз, глупость. Слушать такое не нужно (да и писать тоже).

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

    Если бы крашдетект встраивал только фичу детекта мертвых зависаний, реализация бы не потребовала большого количества ресурсов и сложности, и всё ещё была бы более-менее точной на уровне других имеющихся диагностик. Но поскольку это взяло на себя ещё и задачу по отлову просто медленно выполняющегося кода - оно должно было быть реализовано соответствующе или не включено по умолчанию, чтобы каждый первый потом не хотел это отключать после того, что он видит в консоли на вполне адекватно и эффективно работающем алгоритме своего скрипта.
    Последний раз редактировалось Nexius_Tailer; 20.01.2023 в 03:33.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

  12. Пользователь сказал cпасибо:
    punkochel (20.01.2023)
  13. #19
    Аватар для DeimoS
    Модератор?

    Статус
    Оффлайн
    Регистрация
    27.01.2014
    Адрес
    Восточный Мордор
    Сообщений
    5,588
    Репутация:
    1984 ±
    Цитата Сообщение от punkochel Посмотреть сообщение
    Но лично для меня, да и думаю что многих других тоже, эта функция скорее помеха чем фича, потому-то необходимо тратить время на её отключение, так как она включена по умолчанию.
    То, что она включена по умолчанию и кому-то не нужна - это не делает её бесполезной или сломанной.
    Напомню, что мы не качество и удобство плагина crashdetect тут обсуждаем. Мы обсуждаем то, является ли профайлер, встроенный в crashdetect, сломанным или же всё же кто-то не смог/не захотел понять то, как пользоваться тем функционалом, который ему предоставили.

    Цитата Сообщение от punkochel Посмотреть сообщение
    А для замера скорости тех или иных реализаций для меня прекрасно подходит этот Профайлер.
    Как ты собираешься через этот профайлер проверять то, как быстро у тебя код внутри таймера срабатывает? Пол мода переносить внутрь этого профайлера, чтоб соблюсти все зависимости?
    И если да, то насколько удобно будет делать это после каждой новой правки кода таймера и функций, которые вызываются в таймере? Вопрос риторический.

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

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

    Цитата Сообщение от Nexius_Tailer Посмотреть сообщение
    Той "глупости", которую и сам автор этого нововведения признаёт как дефект?
    Покажи где именно он это признаёт? Что-то в PR от Y-Less, который и добавляет данный функционал, нет ни слова про какие-то там дефекты. И есть даже те, кто прекрасно понимает зачем нужен данный функционал. Да и в других темах тоже что-то подобной истины я найти не смог. Вот есть даже неофициальный релиз от всё того же Y-Less, где тот фиксит баг long_time, связанный с Linux, но что-то и там нет признания, что сама идея функционала - "дефект" и на самом деле она должна работать так, как фантазируешь тут ты.
    Но может я просто недостаточно долго искал. Кидай ссылки, пролей свет на ситуацию.

    На остальную чушь даже отвечать не хочется. Опять начались басни про какой-то учёт внешних нагрузок. Ещё раз: покажи хоть один пример такой волшебной библиотеки в других ЯП, занимающейся тем, о чём ты тут фантазируешь, а потом уже пытайся делать вид, что твои слова имеют смысл.
    Хотя давай я даже облегчу тебе задачу: просто скинь ссылку на программу или библиотеку, которая способна определять то, сколько ресурсов понадобится для работы тому или иному коду, и которая, при этом, сам этот код не воспроизводит для анализа (ой, это же невозможно ). Ты же этого хочешь получить от crashdetect (иначе непонятно как он должен "динамически" понимать какой задумывалась нагрузка от твоего кода изначально, чтоб её ещё и с внешней нагрузкой учитывать). Так давай, дерзай.

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

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

    Steve Pavlina

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

    Статус
    Оффлайн
    Регистрация
    04.01.2015
    Адрес
    Гомель, Беларусь
    Сообщений
    547
    Репутация:
    158 ±
    Цитата Сообщение от DeimoS Посмотреть сообщение
    Покажи где именно он это признаёт? Что-то в PR от Y-Less, который и добавляет данный функционал, нет ни слова про какие-то там дефекты. И есть даже те, кто прекрасно понимает зачем нужен данный функционал. Да и в других темах тоже что-то подобной истины я найти не смог. Вот есть даже неофициальный релиз от всё того же Y-Less, где тот фиксит баг long_time, связанный с Linux, но что-то и там нет признания, что сама идея функционала - "дефект" и на самом деле она должна работать так, как фантазируешь тут ты.

    Опять начались басни про какой-то учёт внешних нагрузок. Ещё раз: покажи хоть один пример такой волшебной библиотеки в других ЯП, занимающейся тем, о чём ты тут фантазируешь, а потом уже пытайся делать вид, что твои слова имеют смысл.
    Тык (пару раз ещё обсуждалось в других каналах помимо omp-support, но этого вполне хватает). Фантазирую тут не я, как видишь. В собственном форке, который я здесь же скинул ранее, Y_less пофиксил лишь некоторые, самые очевидные и легко поддающиеся фиксу косяки, а с остальным скорее всего пока просто решил не заморачиваться, потому что сам прекрасно понимает объём работы до той кондиции, когда это станет нормально выполняться из коробки (хотя этому человеку в целом было и ранее свойственно предлагать изменения, долгосрочную ответственность за работоспособность которых он нести не был намерен, но здесь начали жаловаться на его же YSI при подключенном крашдетекте, так что ему пришлось поднапрячься и всё таки сделать с этим что-то. И как видно, не на стороне YSI).

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

    Цитата Сообщение от DeimoS Посмотреть сообщение
    То, что она включена по умолчанию и кому-то не нужна - это не делает её бесполезной или сломанной.
    Напомню, что мы не качество и удобство плагина crashdetect тут обсуждаем. Мы обсуждаем то, является ли профайлер, встроенный в crashdetect, сломанным или же всё же кто-то не смог/не захотел понять то, как пользоваться тем функционалом, который ему предоставили.
    Да, все кругом не понимают, сплошь и рядом. Всё проще: никто не использует крашдетект как профайлер, ровно как и не используют профайлер в целях, для которых был создан крашдетект. Когда надо отловить ошибки и краши в рантайме - подключают первое, которое (до последней диагностики) выдавало причину любой сообщаемой проблемы. Обсуждаемая диагностика её не выдаёт, что абсолютно в этот плагин и не вписывается (в дополнение к тому, что это ещё и имеет подавляющее большинство ложных срабатываний без их фикса вручную в каждой области их возникновения, а передергивание на то, что мы тут что-то "настраиваем", пытаясь не замечать, что строим велосипеды для обхода ложных, совсем ни на кого не работает, увы).

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



    Цитата Сообщение от DeimoS Посмотреть сообщение
    Ну и сразу говорю, что любые дальнейшие сообщения, никак не вносящие в обсуждение какой-либо конструктив (то бишь, если не будет пруфов тем или иным высказываниям), будут считаться оффтопом и выпиливаться согласно правилам форума. Так что советую заранее подумать, стоит ли трать время на то, чтоб в очередной раз метнуть стрелки, не оставив никаких ссылок, подтверждающих свои высказывания.
    Ну и сразу говорю, что непониманию, по какой причине ты адресуешь это мне, учитывая, что я всегда веду разговор по теме, а любые отклонения от неё как правило на собеседнике (тебе ли этого не знать). Советую просто принимать вещи такими, какие они есть, даже если очень хочется с кем-то поспорить. В данной ситуации уже не первый раз тебе предоставляют аргументы по одной и той же теме обсуждения, по которой уже говорили и ставили точку в прошлый.
    Последний раз редактировалось Nexius_Tailer; 20.01.2023 в 19:41.
    Не хотите постоянно проверять обновления моих скриптов?
    Подключите его последним, после всех остальных
    Nexius's Update Checker

 

 
Страница 2 из 3 ПерваяПервая 1 2 3 ПоследняяПоследняя

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

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

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

Ваши права

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