когда мы поворачиваем предметы отдельно по осям плагин прибавляет либо убавляет значения конкретных осей, но он не следит затем чтобы эти значения укладывались в человеку понятные значения от 0 до 360 и от -1 до -360
если хотябы один из предметов удален как только до него доходит цикл обработки предметов он останавливается и переключается на следующее действие т.к. такая логика перешла из одиночных отмены повтора, такая логика в корне неверна и нужно сделать так чтобы плагин мог дальше отменять повторять если каких либо предметов нет, если же в групповой отмене повторе участвовал один предмет и тот уже умер то тогда нужно просто переключатся к следующему действию как это есть сейчас.
по результатам при отмене повторе групповых действий с 200 предметами, просадка var снизилась с 11 до 7-8 в принципе это как раз то что нужно чтобы без жертв в скорости работы использовать пред проверки в отмене повторе.
есть одно узкое место, объекты с системе отмена повтора идентифицируются в виде hammerid для того чтобы когда мы отменяем и повторяем действия мы делали это с одними и теми же предметами над которыми были произведены и записаны действия.
но проблема заключается в том что чтобы найти предмет который имеет нужный нам hammerid нам нужно перебрать все 2048 возможных пропов, выходит если вы делали действия с 200 предметами и хотите их отменить то сумма итераций цикла неободимых для того чтобы найти нужные предмета будет: 200 на 2048 = 409600 итераций, это очень много..
для групповых действий которые по сути своей личные для игроков, можно сделать вот что:
вместо того чтобы искать каждый предмет всегда по новому нужно перед запуском отмены/повтора группового действия сделать цикл с с данными из стека объектов игрока где хранятся данные с уникальными entity refference ссылками к пропам и записывать hammerid предмета в качестве ключа а в качестве значения entity refference код пропа, так вот у нас получится готовая пачка данных и серверу не придется делать 409600 итераций, мы это сделаем за 200 собрав данные перед запуском цикла отмены, дальше уже цикл отмены будет просто обращатся к KeyValue пакету указывая hammerid получая entity refference код предмета.
нужно подключить в отмену повтор отключаемый дефайном кластер проверок с счетчиком исходя из проблемы, к примеру при групповой отмене чтоб считал например на стольки то предметах кто-то стоит, или столько то предметов могут оказаться на игроках.
нашел обходной маневр с weapon_spawn которому можно прописать нужный m_weaponID на этапе создания, надо обновить разрешенные m_weaponID добавив туда взрывчатку и в меню указать покупку через другой класс, далее надо в базе у всех заменить взрывчатку на другой класс.