MV 1.6: Что нового?

Как многие уже заметили, на днях в Steam обновился RPG Maker MV до версии 1.6. Авторы настоятельно рекомендовали сохранить копию своего проекта и как оказалось не зря.

Помимо того, что ПРИНУДИТЕЛЬНО обновились базовые скрипты в «старом» проекте, выяснился один не ОЧЕНЬ приятный (лично для меня) момент. Изменилась область видимости переменных в скрипте плагина и как следствие практически все мои скрипты «встали колом».

Например раньше можно было написать:

И наша переменная aaa была доступна в любой части проекта, в том числе к ней можно было обратиться внутри базовых классов rpg maker. После обновления переменная более недоступна и единственный способ либо выносить её за пределы function() и делать глобальной, либо не ставить в начале var.

С чем это связано я не знаю, возможно EvilCat или DK смогут объяснить, но факт остаётся фактом. Шанс того что глобальная переменная с таким же именем перетрётся другим плагином 50 на 50

Видимо придётся меня стиль написания, отказываться от простых function и оформлять в виде своего класса



Предлагаю собрать в теме какие ещё «нововведения» затронули ваши проекты?

Все нововведения связаны с поддержкой ES6: habrahabr.ru/post/305900/

Mur, разве так было? Ведь оборачивание в самовызываемую анонимную функцию всегда служило лишь предотвращению засорения глобального пространства временными переменными. Нет никакой другой необходимости писать такую неуклюжую конструкцию вместо простого
Иначе говоря, (function() {...})() - это не какое-то хитрое заклинание, чтобы строчки кода запустились. Без него прекрасно всё запустится. Но переменные, объявленные как var, будут все глобальными, а если их обернуть в функцию - то они будут ограничены рамками этой функции.

Я так понял, у Mur переменная стала не видна при использовании в дополнениях к мейкеровским классам, которые(дополнения) объявлены внутри function() { дополнения }()?

Или в других плагинах?

EvilCat пишет: Mur, разве так было?

В каком смысле было? Работало раньше? Ну как бы да.

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

Ну собственно да, именно для этого обёртку и делали.

EvilCat пишет: Иначе говоря, (function() {...})() - это не какое-то хитрое заклинание, чтобы строчки кода запустились. Без него прекрасно всё запустится. Но переменные, объявленные как var, будут все глобальными, а если их обернуть в функцию - то они будут ограничены рамками этой функции.

Да не, по function() у меня вопросов нет, вопрос был в другом:

Для наглядности пример:

До версии 1.6, при запуске мы получим в отладчике сообщение:

Начиная с 1.6 мы получаем сообщение об ошибке, что aaa undefined

Но! Если мы уберём в начале var:

То и версии 1.6 получим желаемый результат.

Сейчас я вообще делаю по другому, не знаю насколько это правильно, но подсмотрено у Galv:

Ну как я понимаю в такой конструкции больше обёртка (function() { ... })(); не нужна?

Lekste пишет: Я так понял, у Mur переменная стала не видна при использовании в дополнениях к мейкеровским классам, которые(дополнения) объявлены внутри function() { дополнения }()?

Ну собственно выше всё и рассказано.

Lekste пишет: Или в других плагинах?

не не не, от других плагинов мы собственно и экранировались с помощью function()

Мур, пожалуйста, записывай в Imported версию плагина, не булевую переменную

Зач м вобще нужно это Imported, если пожно проверить переменную с объектом NPC?

Только что скачал MV, проверил что версия 1.6.0, проверил твой пример для наглядности и... работает. Может кто подтвердить что [strike]я особенный[/strike] баг воспроизводится?

Lekste пишет: Зач м вобще нужно это Imported, если пожно проверить переменную с объектом NPC?

Ты о чем ?

DK пишет: Мур, пожалуйста, записывай в Imported версию плагина, не булевую переменную

А в чём разница? Я могу и внутри своего класса хранить версию в переменной?

Я просто к чему это, так многие делаю, вот тот же Yanfly например:

Lekste пишет: Зач м вобще нужно это Imported, если пожно проверить переменную с объектом NPC?

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

Не знаю, что у тебя там не так, но твой пример нормально работает в 1.6 версии мейкера. Создал для тест новый проект на версии 1.6, скопировал твой пример и

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

Amphilohiy пишет: Только что скачал MV, проверил что версия 1.6.0, проверил твой пример для наглядности и... работает. Может кто подтвердить что [strike]я особенный[/strike] баг воспроизводится?

Ээээ…

А вот это уже странно ибо действительно стало работать

Ну тут два варианта, либо что-то обновили втихоря, либо как-то у меня «совпали звёзды», ибо точно не работало

Dk, я о том, что почему бы не проверять на Mur.NPC != undefined и не использовать лишний объект Imported?
А версию, как было сказано Mur, брать из самого плагина.

Lekste пишет: Dk, я о том, что почему бы не проверять на Mur.NPC != undefined и не использовать лишний объект Imported?

Хм, как показал поиск по зарубежным форумам, на самом деле этот Import не нужен. Это пришло из Ruby и по сути в JavaScript не используется. А проверить загружен ли плагин, можно спросив PluginManager._scripts и он вернёт список загруженных плагинов

Другой вопрос это с

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

Lekste пишет: А версию, как было сказано Mur, брать из самого плагина.

А в каком случае эта версия может вообще понадобится? Если только оооочень что-то глобально поменялось в модуле?

Но даже если и так, и например не найден метод BBB в библиотеке AAA, то не важно какая версия, главное обработать эту ошибку и как-то сообщить, нэ?

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

Без всяких prototype именно благодаря ES6? или я опять что-то путаю?

Ещё что нового: после апдейта Аваст, довольный как кот, сообщил, что впервые за много лет наконец-то остановил угрозу: страшный файл nw.exe из папки Мейкера... %)

Mur пишет: И да, раз уже пошел разговор про структуры, я так понимаю, что теперь можно делать просто:

Code:

MUR.NPC.set_block = function (blockId, restart_blocks) { ... }

Без всяких prototype именно благодаря ES6? или я опять что-то путаю?

Мне не хватает знания об устройстве плагина, чтобы ответить точно... Просто перескажу, как работают прототипы.

Возьмём объект Кот и вызовем у него метод Мяу. У объекта Кот либо есть поле под названием "Мяу", либо нет. Если его нет или если оно не исполняемое (не функция), то получится ошибка.

Но что если мы создали Кота с помощью функции "СемействоКошачьих"? Тогда объект Кот будет считать, что у него есть конструктор - функция СемействоКошачьих. Функции - тоже объекты, и если у СемействаКошачьих есть поле под названием "прототип", то прежде чем отчаяться найти поле Мяу, Кот обратится к полю "прототип" своего конструктора. Если в этом поле объект, у которого есть поле под названием "Мяу", то это всё равно, как если бы у самого Кота было такое поле.

Таким образом, когда мы вызываем "MUR.NPC.set_block(...)", то либо у самого объекта MUR.NPC должно быть поле под названием "set_block"... Либо MUR.NPC должно быть создано с помощью какого-нибудь конструктора (функции), у которого есть поле под названием prototype, и в этом поле лежит объект с полем под названием "set_block"... Если MUR.NPC не создано с помощью конструктора, но само имеет поле prorotype, в котором записаны какие-то функции под какими-то названиями - то вызов MUR.NPC.set_block(...) даже и не подумает к ним обратиться.

Как и в случае с (function() {...})(), запись с prototype - это не какой-то извращённый способ добавлять методы классу вместо простого def, а механизм, имеющий определённую логику и назначение.

Если верить тому, что написано по ссылке DK, теперь можно писать вобще:
Ну и еще, возможно будет очень удобно вместо такого:
можно сделать:

Mur пишет: Для наглядности пример:

Code:

(function() { var aaa = "Test!"; var Game_Event_setupPageSettings = Game_Event.prototype.setupPageSettings; Game_Event.prototype.setupPageSettings = function() { Game_Event_setupPageSettings.call(this); console.log("aaa=" + aaa); } })();

До версии 1.6, при запуске мы получим в отладчике сообщение:

Code:

aaa=Test!

Начиная с 1.6 мы получаем сообщение об ошибке, что aaa undefined

Но! Если мы уберём в начале var:

Code:

(function() { aaa = "Test!";

То и версии 1.6 получим желаемый результат.

Если убрать в начале var, переменная будет объявлена как глобальная и будет доступна с таким названием отовсюду (где нет локальной переменной с таким же названием).

Что касается того, доступна ли локально объявленная переменная в функциях, созданных в той же области (как в данном примере функция "Game_Event.prototype.setupPageSettings"... То ответ - "да": это как раз раньше был неуклюжий единственный способ иметь "приватные" поля объекта, а также лишние данные, которые вечно оставались привязаны к создаваемым функциям, занимая память - следовало обращаться с этим осторожнее во избежание утечек.

Я сильно сомневаюсь, чтобы это изменилось в ES6, поскольку на этом нюансе реализации (псевдо приватных полях) были основаны многие веб-сайты. Разве что там могли добавить какое-нибудь ключевое слово (let? не уверена), инструктирующее не давать доступ к данной переменной дочерним функциям области.

Lekste, второй вариант неправильно написан, потому что надо писать GameScene_update.call(this), чтобы у функции был привязан контекст.
На счет третьего варианта не уверен. Скорее всего не будет работать, потому что стандартные "классы" не написаны через классы ES6.
Первый вариант вроде как рабочий.