Zander_driver

А в чем проблема? При трансфере, указывается id адресата-нового владельца. Затем передаваемые итемы приобретают game_vertex_id & level_vertex_id, идентичные таковым у нового владельца. Это если смотреть на операцию "трансфер", с точки зрения движка. При трансферах там нужны именно id - что передаем, от кого передаем, кому передаем. А вот если со стороны скриптов плясать... наверное, проблема начинается там, где в качестве аргументов/операторов, доступных скрипту функций, выступают игровые объекты (game_object), а не их id. Можно сделать скриптовые функции с измененной сигнат

А вы точно убеждены, что в файлах движка находятся конфиги? Я могу конечно, чего-то не знать, но что-то я сомневаюсь - в нормальном движке, такого быть не должно.

Ну если только так... Я бы не называл это полноценным присвоением, когда сид сам по себе УЖЕ присутствует в файлах при запуске игры. Потому и сказал, что так не работает. Присвоение - это типа такого: function set_story_id(sobj) local sid = 1 while alife():story_object(sid) do sid = sid + 1 end alife():assign_story_id(sid, sobj.id) return sid end -- Т.е. выполняется поиск свободного сид и его занятие, прямо при запуске функции. --И затем сразу, а не после сейв-лоада, мы можем получать наш объект через alife():story_object(sid)

Для начала придется этот самый CGameObject изрядно переписать Он же при создании/загрузке, кучу своих параметров загружает из серверного объекта. Стало быть, чтобы такое создание было в принципе возможно, надо ему указать некие другие источники данных)

Если у вас не модифицированный движок, то даже через нетпакеты ничего не выйдет - ваши манипуляции с параметром сид в нетпакете, НЕ вносят этот предмет в реестр объектов имеющих story_id, в чем и заключается смысл функции assign_story_id. Проще говоря, на не-модифицированном движке, нормально присвоить сид - нельзя. Так чтобы объект обнаруживался по alife():story_object(ваш_сид) Можно это сделать на X-Ray Ext, или на OGSR. Там функции для присвоения сида штатно есть в движке, и все делается легко и просто. На оригинале никак, и никакие костыли тут не помогут.

Можно делать скриптовый постпроцесс. И к нему добавлять какие угодно функции. https://www.amk-team.ru/forum/topic/7450-spravochnik-po-funkciyam-i-klassam/?do=findComment&comment=473063

Это просто описание инфопоршня и его свойств. Выдавать статью в ПДА, когда выдали поршень. Тоже объявление-описание Естественно, нету. Инфопоршень не выдается ведь. И от того что его описали, он сам собой не выдастся. Повторяю еще раз) Чтобы что-то работало, надо не только конфиги заполнять. Но и писать код в скриптах. Вылет из-за дублирования инфопоршня... такой уже есть. Они ведь уникальными должны быть.

В этом случае, сообщение на худ руками добавляют. В скрипт, отдельно. Движком оно само не выводится Тут надо ловить свою флешку в on_item_take в биндере актора. И там уже проверять, та ли это флешка, впервые ее взяли или нет, и что с этим делать (выдавать инфопоршни как вариант).

Скорее всего, в этом файле (info_escape.xml) что-то не так с синтаксисом. Синтаксис xml довольно широко употребляемая вещь, так что его легко можно проверить. Вот например, первый попавшийся чекер по запросу xml syntax check online Засовываешь туда свой файл, чекер тебе сообщает где и что не так, исправляешь - и когда с синтаксисом будет все ок, игра его примет. Прекондишен это вообще говоря, функция. В которой может быть все что угодно в т.ч. и инфопоршни.

Это какие-то фейковые предметы для каких-то внутри-скриптовых манипуляций? А зачем? Вроде бы, вкл/выкл фонарика, равно как и использование чего угодно мыслимого, с какой угодно функциональной логикой, на движке OGSR не должно таких костылей требовать.

Вполне Неа. Ровно в тот самый момент, станет уже поздно.

Я полагаю, что - чем далее в будущее, тем более, он будет нужен. И полагаю, что лучше бы ему появиться ДО релиза S-2. Существенно ДО. Хоть он и будет первое время, вероятно, пустовать - со временем наполнится, дело наживное. имхо, конечно же...

Вопрос: Будет ли (и если будет, то когда), в разделе "школа моддинга", создаваться под-раздел, посвященный геймдеву/моддингу на UE4-5 ?

Значит эта гора мобов заспавнилась на СТАРОМ патче. Они уже жили там с того сейва, который вы загрузили. Это не новый спавн, а так было. При переходе от скриптовой системы компрессии, к движковой, из всех старых (заспавненных ДО этого перехода), мобов, исчезают трофеи. Да, так оно устроено. В тех мобах, которые будут спавниться уже после перехода на движковую систему, с трофеями будет все нормально.

profile_timer вставленный в нетспавн неписей, чем не устраивает? функционально аналогичен performance.now из javaScript...