UEngine.Ru

использование наследования вместо интерфейсов
_________________
прикрепленные картинки с radikal не смотрю.

тогда мне мне прийдется приводить все к определенному типу класса... что мягко говоря не гибко совсем...
в частности потому что нет возможности расширить дефолтные классы, которыми используются в движке везде.
ведь все готовые функции заточены именно на дефолтные классы.
Если сделать свой класс от них, прийдется потом постоянно новый тип класса указывать. Неудобно это совсем.
Прицепить интерфейс к наследнику дефолтного классу более оптимальное решение на мой взгляд.?
На плюсах такие(не виртуальные функции класса, а внешний интерфейс) интерфейсы как работают, должен же быть способ ограничить доступ отовсюду?
_________________
we need to go deeper
Последний раз редактировалось Snake 06 сен 2017, 10:09, всего редактировалось 1 раз.

можно в интерфейсе требовать передачу павна, тогда не сможешь случайно юзать не из павна
_________________
прикрепленные картинки с radikal не смотрю.

не совсем представляю как это должно выглядеть....
на пальцах примитивный пример:
предположим есть интерфейс контроллера - "сет фокус", на входе актор для фокуса.
есть павн который кудато должен идти и использует этот интерфейс контроллера для установки фокуса.
мне никак не заблокировать "сет фокус интерфейс" контроллера от вызовов от куда угодно.


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

Павн может существовать без контроллера, контроллер без павна обычно неактивный. ТОесть вполне логично обращаться к павну, а тот если ему нужно общается со своим контроллером. Хочется инкапсулировать определенный интерфейс контроллера внутри павна.
Но что-то возможности такой я не вижу. Если такая существует то напишите.
А так прийдется быть аккуратным при написании логики, чтоб не вызывать функции от куда они не должны вызываться. Но бдительность дает сбои)
_________________
we need to go deeper

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

хм...ну да точно проверять внутри функции кто вызвал... а при вызове передавать вызывающего... не изящно конечно, но если сильно нужно то можно и так, да. НО я все же наверное все же отдельную категорию(благо их можно категоризировать) таких функций сделаю, ну и бдить чтоб не из павна туда(в эту категорию) даже не залазить.
_________________
we need to go deeper
Последний раз редактировалось Snake 06 сен 2017, 11:23, всего редактировалось 1 раз.

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

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

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

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

мда чет я сегодня туго соображаю, можно все же функциями абстрактного класса обойтись. Это будет простое(существующие функции покопировать) даже для переделки и уже изящное решение.
Спасибо, я хоть и сопротивлялся, но со второй попытки мозги в нужную сторону стали.
_________________
we need to go deeper

Создал Fpm_bp наследованный от актора, положил в него модельку и в EventGraph написал функцию с входными параметрами и точно обозначил как public.

Положил этот bp в другой bp посредством перетягивания в components. Оно неожиданно сменило класс на Child actor component и потеряло возможность вызова функций от Fpm_bp.

При попытки кастануть обратно вылазит 'Fpm Bp' does not inherit from 'Child Actor Component' ( Cast To fpm_bp would always fail).

Что лучше всего сделать?

ну логично что эктор не может содержать эктор, если тебе нужен Child actor component то его и делай
_________________
прикрепленные картинки с radikal не смотрю.