Не совсем то, что я хотел услышать, но вопрос писался

быстро и да, недостаточно прозрачен. подойду с другой стороны.

есть AMyActor { UPROPERTY() UMyObject obj; }

AMyActor A;
A.obj = do_smth();
AMyActor B = CopyObject(A);

Что будет в B->obj? Что будет там, если UMyObject isA UTexture2D ?

не, на самом деле я чет кажется криво подвожу к Instanced

Вот у меня было две версии, instanced и resource, но ты так напираешь на именно texture, что я подумал, что ты хочешь про rhi послушать

identifier CopyObject(A) is undefined?

Instanced в данном случае понятие какого уровня?

Property specifier

@ufnah я читаю ваш диалог и не понимаю вообще о чем вы говорите. только из контекста догадался, что как бы Владимир намекает, что uobject по-умолчанию не может создавать инстансы? Это как... Когда я создаю новый экземпляр класса через newObject() он же создает инстанс без проблем. Ровно как и спавн экторов. Поэтому то, что oubject не может инстанцироваться для меня новость. Если вообще моя догадка верна. Про resource вообще непонятно. Что вы имели в виду, написав "Вот у меня было две версии, instanced и resource"? А по поводу самого вопроса. Про копирование uobject'a... Такой расплывчатый вопрос да еще и толкающий на преступления против стандартных процедур спавна/создания. Расплывчатый - потому что неизвестно как эта функция copyobject работает. Она делает глубокое копирование или поверхностное? Если глубокое, то согласно понятия глубокого копирования должна создаться новая текстура. Хотя вряд ли сам движок это позволит, т.к. для того они и указатели и были вообще в программировании изобретены, чтоб не копировать данные многомегабайтные. Ну и вообще, я бы по рукам надавал тому, кто копирует AActor вместо того чтоб заспавнить нового AActor как положено, через spawnactor. Ну или newobject, если мы говорим о uobject'ах. Потому что у эпиков использование нестандартных способов порождения/поиска/инициализации чего бы то ни было с высокой вероятностью приводит к крашам зависаниям и неожиданному поведению.