Функция Wait внутри плагина

Каким образом возможно приостановить выполнение плагина на n-ое количество кадров/секунд?

Morphinistka пишет: Каким образом возможно приостановить выполнение плагина на n-ое количество кадров/секунд?

Самый простой способ — window.setTimeout, вот так:

Этот подход хорош тем, что он простой, но время ожидания может не на 100% соответствовать кадру в игре (т.к. setTimeout принимает число в миллисекундах, а не в кадрах, и может быть не очень точным). Хотя обычно эти проблемы не важны — можно использовать этот вариант и не волноваться.

Другой вариант — добавить счётчик кадров, который уменьшается в команде функции update (например, Scene_Map.prototype.update, если речь о карте), и выполнять какое-то действие, когда счётчик станет равным нулю.

Подробнее и с примерами я описывал тут .

Спасибо, дружище, обнимаю. ♥

Dmy пишет:

Morphinistka пишет: Каким образом возможно приостановить выполнение плагина на n-ое количество кадров/секунд?

Самый простой способ — window.setTimeout, вот так:

Code:

window.setTimeout(function () { /* тут код, который выполнится после задержки */ }, 1000); //1000 миллисекунд — 1 секунда

Причем тут пауза выполнения плагина ?

DK пишет: Причем тут пауза выполнения плагина ?

Тема называется «Функция Wait внутри плагина», а внутри предполагает, что речь о внутренностях конкретного плагина (а не о чужом плагине, во внутренности которого мы не лезем).

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

Задержка выполнения чужого плагина — это интересный (но, пожалуй, не решаемый в общем случае) вопрос, но эта тема называется «Функция Wait внутри плагина».

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

P.S. Использование setTimeout считается костылем. Лучше пользоваться паузами в update сцены, как Dmy написал.

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

На количество секунд — почти всегда гарантирует. Обычно погрешность там на пару десятков миллисекунд, и такую погрешность люди вполне могут себе позволить.

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

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

Зачем придираться к ответу, в котором нет ошибок — хоть убей не понимаю.

DK пишет: P.S. Использование setTimeout считается костылем.

Кем считается? Всё нормально с setTimeout, в большинстве случаев его более чем достаточно.

DK пишет: Лучше пользоваться паузами в update сцены, как Dmy написал.

В инженерных задачах не бывает 100% «лучше», там бывают лишь компромиссы и «лучше для конкретной ситуации». В данном случае у нас выбор между простотой кода (у setTimeout) и точностью (у update).

Бывают ситуации, где setTimeout лучше.

Простота кода — это тоже важный критерий. Простота кода облегчает его поддержку в будущем, поиск багов, редактирование другими людьми и т.п. Поэтому если не нужна точность до последнего кадра, то обычно setTimeout лучше. Поэтому я его и привёл первым.

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

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

Особенно, если с апдейтом мейкера решат изменить частоту кадров

Не хотелось бы развивать тему оффтопа, но придётся вмешаться. Господа, я понимаю, что осуждать - это здорово, но если так, давайте и предлагать, за одно? Если settime плохой вариант, какой тогда хороший? А то уже пятый пост в теме и ноль инфы, кроме: "Так делать нельзя", а как можно то?

Демий пишет: Не хотелось бы развивать тему оффтопа, но придётся вмешаться. Господа, я понимаю, что осуждать - это здорово, но если так, давайте и предлагать, за одно? Если settime плохой вариант, какой тогда хороший? А то уже пятый пост в теме и ноль инфы, кроме: "Так делать нельзя", а как можно то?

Уже же сказали, что update текущей сцены или сцены плагина.

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

Это зависит от многих факторов. По моему опыту, обычно код с setTimeout наоборот проще для отладки, чем код с переписыванием update.

Переписывание update требует заведения как минимум одной новой переменной, её надо держать в уме при чтении. Т.е. это усложнение кода.

Демий пишет: Если settime плохой вариант, какой тогда хороший?

Я же написал с самого начала. Ещё до того, как DK стал писать свои придирки — видимо, он не читал мой ответ перед тем, как писать свой.

Вот о минусах setTimeout и об альтернативном варианте (выделено синим):

Dmy пишет:

Morphinistka пишет: Каким образом возможно приостановить выполнение плагина на n-ое количество кадров/секунд?

Самый простой способ — window.setTimeout [...]
Этот подход хорош тем, что он простой, но время ожидания может не на 100% соответствовать кадру в игре (т.к. setTimeout принимает число в миллисекундах, а не в кадрах, и может быть не очень точным). Хотя обычно эти проблемы не важны — можно использовать этот вариант и не волноваться.

Другой вариант — добавить счётчик кадров, который уменьшается в команде функции update (например, Scene_Map.prototype.update, если речь о карте), и выполнять какое-то действие, когда счётчик станет равным нулю.

Подробнее и с примерами я описывал тут .

Если перейти по ссылке , то там будут примеры и setTimeout, и переписывания update. Заодно сравните сложность примеров.

Dmy пишет: Переписывание update требует заведения как минимум одной новой переменной, её надо держать в уме при чтении. Т.е. это усложнение кода.

Уж очень притянуто за уши...

DK пишет:

Dmy пишет: Переписывание update требует заведения как минимум одной новой переменной, её надо держать в уме при чтении. Т.е. это усложнение кода.

Уж очень притянуто за уши...

По-моему притянуты за уши ваши придирки к setTimeout.

«Считается костылём» — это какое-то суеверие. «Нельзя здороваться через порог», «нельзя сидеть на камнях», «нельзя использовать setTimeout» — одного поля запреты.


________________

Добавлено в 15:23:

Код с setTimeout:

Код с update:

Я не знаю, в какой вселенной сложность второго варианта «притянута за уши». По-моему усложнение очевидно.

Твой update можно сократить на несколько строк...

А если нужно изменять переменную каждый кадр, то твой setTimeout может промахнуться на несколько миллисекунд, что пойдет другой кадр.

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

Тут я опять согласен с ДК - писать код надо так, чтобы он вписывался в общую логику и работал предсказуемо.

DK пишет: Твой update можно сократить на несколько строк...

Да можно вообще в одну строчку записать, какая разница? Важно не количество строк, а количество производимых кодом действий.

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

Аналогично, можно в теории заменить две переменных одной: можно хранить иногда числовые значения, иногда булевые (допустим). Но нагрузка на чител_ьниц кода останется той же: им-по прежнему придётся следить за состоянием «затемнение нужно?» и «сколько ожидать осталось?»

DK пишет: А если нужно изменять переменную каждый кадр, то твой setTimeout может промахнуться на несколько миллисекунд, что пойдет другой кадр.

Ну да. Я это признаю. (И сразу признавал. В моём первом ответе в этой теме уже сразу было указано.)

Однако в 99% случаев выгода от простоты кода неизмеримо больше, чем выгода от формальной точности. Поэтому setTimeout предпочтительнее.

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

____________________

Добавлено в 17:00:
Есть разные ситуации.

Если в скрипте «показать сообщение о новом квесте» некоторые сообщения будут показываться 5 секунд, а некоторые — 5,1 секунд, то разницу никто не заметит. Здесь достаточно setTimeout.

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

И будем честны. Большинство скриптов, которые мы пишем, похожи на первый случай, а не на второй.

Сколько ответов.. Функция сетТаймаут у меня не работает должным образом(скорее всего мой трабл), воспользовалась советом с update, работает как надо. Да и в принципе более импонирует второй вариант.

еще раз спасибо.

В общем, тут даже спорить не о чем было. Игра работает по кругу:
Проверить нажатые кнопки -> Обновить состояние -> Обновить картинку на экране -> Проверить нажатые кнопки -> ...

Вставляешь свои действия на нужный шаг и все гарантированно работает гладко... ¯\_(ツ)_/¯

Morphinistka пишет: Сколько ответов.. Функция сетТаймаут у меня не работает должным образом(скорее всего мой трабл), воспользовалась советом с update, работает как надо. Да и в принципе более импонирует второй вариант.

еще раз спасибо.

Только вот жалко, что большинство скриптеров/программистов в основном пишут для себя( сообществу очень пригодились бы новые лица и новые плагины...