Чтобы попасть в закрытый Telegram чат с доступом навсегда, то можете отправить мне донат на любую сумму от 100 рублей на сервис Boosty: boosty.to/makeyourgame , а я пришлю ссылку в течение 24 часов. Только убедитесь, что у вас открыты сообщения на Boosty. ================================= Группа в ВКонтакте: vk.com/makeyourgameunreal ================================= Подписка на канал - только приветствуется! ================================= #games #unreal #unrealengine
Смотри: у меня файтинг, где по краям экрана есть 2 невидимые стены, пол и потолок, которые ограничивают передвижение ПЕРСОНАЖА, а ещё снаряды определённого типа могут взрываться/останавливаться, отскакивать от, и всё такое. И я делаю КАСТ на каждый снаряд и вызываю поведение в зависимости от того, что там за снаряд и что должно произойти. В итоге стена несёт на себе все снаряды в игре, даже если играть не за персонажа, который может этими снарядами СТРЕЛЯТЬ. Вывод: я хоть и не дурачок, но не обладал ЗНАНИЯМИ... А автор видео мне эти знания ДАЁТ. Теперь надо сделать выводы и исправить ЛОГИКУ в стенах, чтобы они не тащили на себе санки с пятью мужиками.
Это было очень полезно, ранее сталкивался с интерфейсами и особо не заценил их эффективность, пересмотрел свое восприятие...Благодарю автор!!! Все очень понятно и подробно.
Спасибо за видео, если не ошибаюсь Does Implement Interface нода не нужна, интерфейс будет работать без нее отлично только у тех акторов у которых есть интерфейс, во время отсутствия интерфейса - ошибки не будет. Можете залайкать - людям будет полезно.
Демонстрацию получения переменных через интерфейс еще не на одном видео не встречал по данной тематике, а ведь это, наряду с функциями, основополагающая вещь.
отдельно отметил для зрителей, в уроке 16 про интерфейсы, примерно на 50 секунде, для получения переменных от иного объекта вы рекомендуете использовать casting, есть output интерфейса, который можно использовать как get, это наблюдение и послужило причиной моего замечания, но насколько это профитней сказать не могу, может кто внесет ясность о целесообразности подобных манипуляций. Или же наследование от с++ класса с набором используемых переменных и функций (без mesh, particle и прочего тяжелого) и каст к нему не хуже в плане производительности, а может даже и лучше. А вообще, в данной теме упоминают, что компоненты и композиция для взаимодействия объектов лучше всего, что это за концепция я не представляю, буду рад увидеть что-то из этого.
Основная проблема кастров в том, что логика объектов с которыми мы взаимодействуем прописывается в нашем персонаже. Логика должна быть разделена. А с кастом как в этом примере смена материала вызывается в персонаже. И теперь что бы поменять логику кубика надо лезть в персонажа, а если с кубиком взаимодействует несколько объектов - это совсем грусть будет.
Уроки твои очень помогают начать понимать анриал. Жаль тебе некогда отвечать на вопросы по видео. Ты приводишь в начале пример в котором через секвенцию делают несколько кастов на разные типы объектов. Это сразу выглядит неоптимально, о чём ты и говоришь. Но разве нет команды сделать луч и сообщить с чем он столкнулся, а лучше не только первое столкновение, но и все дальше? Луч делаем один раз и получаем например сразу список всего что он "пробил" по своему пути в порядке удаления. А дальше уже этот список как-то обрабатываем. В описанном тобой методе через отправку сообщений через интерфейс о том, что мы "кидаем луч" - если три разных объекта будут на одной линии один за другим, отработает только первый объект? Можно сделать так, чтобы они все узнали что они на том луче, который мы кинули, один на первой позиции, другой на второй позиции, а третий - на третьей позиции от нас?
Добрый день! Очень понравилось видео. По факту это интерфейсы из c++, ну и других языков, предназначеные показать что данный объект точно имеет в себе реализацию какого-то функционала. Единственное все-таки разделять интефейсы для разных задач, а не запихивать все в один. Если я простолушал про этот момент очень извеняюсь. Спасибо большое за видео.
Понятно. Не хватает только простого упоминания про разделение логики объектов. Логика левых предметов не должна находится "внутри" персонажа. Лайк вам)
Спасибо полезно! А такого плана вопрос: Если я сделал библиотеку функций и в ней создал один раз через каст ссылки основные (игрок, плайер контроллер и гейм мод)
Спасибо за ролик. Мне нравится твое объяснение на пальцах, мне было интуитивно не понятно как работают интерфейсы. Обязательно посмотрю твои ролики про касты и интерфейсы. Теперь мне надо перешить все свои блюпринты. Ох... потная катка будет, учитывая что я чуть ли не в каждом БП делал касты. Тысячи их! XD
Недавно посмотрел ваш урок с стаминой, там у вас каст в виджете выносливости на персонажа с целью его сохранения в перменную персонажа, но переменная персонажа не была задействована в дальнейшей логике., данные качались через каст, а не через переменную с персонажем. Это была пропущено потому что торопились с уроком или потому что если каст сделан. то взаимодействие с этими переменными уже не приводят к дополнительной СУЩЕСТВЕННОЙ нагрузуки?
Урок полезный, единственное, что смущает в интерфейсе- само название сущности. Потому что в Анриле уже есть UMG интерфейсы и сам первое время путался, когда изучал. Если бы разрабы заменили слово интерфейс на "посредник", ясности было бы больше. Ну и еще не понял чисто по механике, в какой момент "подгружается" класс, на который делаешь каст. В момент, когда стрелочка на него приходит, или когда вытягиваешь синюю ноду "as actor". Так как сам использую каст только для проверки класса, но из актора логику другого актора никогда не вызываю, так как это не слишком оопэшно.
А можно видео, где касты уместны? Я сейчас пытаюсь через кастомный notify state сделать трейс у оружия и кроме каста похоже там ничего использовать не получится или есть другой путь?
Так, стоп, получается при каждом касте создается еще один дубликат актера? То есть его из одной копии можно надюпать 10 тысяч? То есть его даже в наследовании лучше избегшать, не кастить к предмету? (абстракт) - приведение к предмет (бутылка огненной воды) ? Будет дюп актера "предмет"?
А как применить интерфейс если у меня коллмзия сфера при пересечении шейдит оутлайн материал при окончании пересеяения выклбчается как делать это без кастов!?
Немного поправлю, если то что вы говорите правда, то это просто провал в ООП, что бы каждый раз в момент каста грузился весь класс, уверен вы допускаете ошибку в своем высказывание, такое поведение на каст - убило бы разработку в многопоточной среде. Пример: Два объекта наносят урон персонажу, оба выполняют каст его внутри своей логики, для последующего вычитания общего количества ХП, и получается что разработчики движка сделали так - копируют при касте, но тогда каждый из тех кто кастует получит копии, первое они будут уменьшать ХП каждый у своей копии , и самое главное основному персонажу вообще как то нет дела, ведь он отдал от себя клонов. Скорее всего идет речь о том что сам каст по себе , подгружает ссылку на игрока а не хранит ее в себе постоянно, это и плохо для работы, потому как реально при наличии множества , ему нужно будет каждый момент грузить эти данные, а потом удалять. Интерфейсы совершенно не решают эту проблему - это разные подходы, "композиция" и наследование. Обратите внимание композиция тут в кавычках - потому что ее нет, просто есть каст который выполняет приведения типа во временной функции. А вот если вы действительно хотели бы рассказать о преимуществе интерфейса, то пример нужно было строить не от отдельного Events, а к примеру создать внутри вашего Класса или Блюпринта, в вашем случае три объекта Куб, Плайн и Сферу, а далее в момент создания класса или блюпринта получить через какст единожды и сохранить полученные данные в эти ссылки , тем самым убрав дорогую операцию в отдельных Events. Вот тогда бы мы увидели зачем нам нужны интерфейсы, когда внутри нашего класса нам бы пришлось выбирать из вашего примера одного из трех, а потом из 20 и так далее, нежели просто использовать назначенный им интерфейс.
Это не мои слова. Я же специально показал, что в описании к касту самими разработчиками указано, что загружается весь блюпринт и это дорого. И да, при касте вы можете получить и достать все что угодно. И нет, это не провал ООП. Это облегчение разработки в некоторых случаях. Те, кто хотят ООП - пожалуйста, есть наследование, прайват переменные, интерфейсы и т.д.
В данном конкретном случае секвенция одновременно кастуется сразу на несколько блюпринтов. Одновременный каст и одновременная логика. Если потребуется какая-нибудь задержка, то нужно делать delay между секвенциями и создавать прочие зависимости. Секвенция будет на себе тащить много всего и много на ней будет завязано, что неудобно
А, в этом плане. Я уж подумал из-за какой-то негативной производитеьлности непосредственно самого этого нода. Тогда можно было просто пустить ветки через Cast Failed. Не одновременно, а последовательно. Нод даже переводится так. За кадр пройдет все по порядку. А вот delay это куда большее зло. Лучше стараться их избегать архитектурно.@@makeyourgame2210
Я вообще не понимаю зачем в разных курсах изучают сначало каст. мало того что создаёт как по мне путаницу, так ещё и вешает на себя работу актора загружая проект. Не вижу даже простоты его использования к тому же, я перфекционист и плачу от мишуры с кастами
Очередная пугалка кастами и введение в заблуждение, что-бы сделать аналогичное взаимодействие с кучей объектов нужен 1 каст на 1 класс т.к. наследование и полиморфизм никто не отменял. То что интерфейсы удобней тут не спорю, но всё остальное это страшилки.
Человек делающий уроки про С++ не знает? А вообще очень просто что если данный класс на который делается каст не существует то он будет загружен в память, в случае же с персонажем который с вероятностью 99.9999 уже есть ничего произойдёт т.к. данный класс используется и в памяти уже есть. @@makeyourgame2210
Вот мне кажется что вы заблуждаетесь. А что на счёт каста на один объект из которого идёт наследование и полиморфизм? И весь ваш интерфейс уже к чертям катится и погружает вообще все объекты с этим интерфейсом. Все должно быть в меру!
Замечание справедливое, но отвечу. Я не зря в видео сказал, что давайте представим, что куб - враг, планка - патроны, сфера - транспорт. Думаю вы поняли на что я намекаю. Ни один здравомыслящий человек не будет наследоваться от транспорта, чтобы сделать патроны.
@@makeyourgame2210Хорошо, но ведь в любом случае можно сделать условно 7 родительских классов, это не так много, тем более вешать можно не на сиквенс, а на каст фэил. Тем более если делать что либо по сети - как работать с интерфейсами - не ясно, ведь он не реплицируется.
@@DisoftGDmedia ну хорошо, а что если в одном из семи родительских классов нужна будет другая логика чтобы вызывалась? Ну вдруг понадобилось. Как тогда из ситуации будете выходить? Как будете другую логику из одного каста вызывать, который является родительским для всех других? Делать бранчи? А если в двух дочерних классах поменять что-то? Ещё один бранч? Вообще дискуссия о том, что касты нужно использовать с примирением всяких кастфэйлов + с использованием дочерних классов я считаю неуместной, когда САМИ ЖЕ РАЗРАБОТЧИКИ на САМОЙ НОДЕ пишут о том, что каст может убить оптимизацию.
@@makeyourgame2210 Ну почему нельзя просто переопределяться функцию? Как по мне самый логичный вариант для другой логики. Никаких проблем не вижу. А вот проблемы с интерфейсами я вижу. Как использовать их в сетевом проекте - я не знаю, вроде как нельзя. Ну а кастить с персонажа на разные классы я считаю нормой. Ну а делать наоборот - не очень, лишь в качестве исключений
@@DisoftGDmediaПо сети все прекрасно работает. Но ваша точка зрения - правильная. Если вы работаете с деревом классов, то вам хватит обычного каста. Достаточно переопределить функцию в наследниках и все пойдет как по маслу. Интерфейсы пригодятся когда, например враг, может быть и AActor и APawn и UObject. В таком случае дерево классов не возможно, а общее поведение необходимо. Не все системы (оружие как пример) можно расписать деревом классов.
Чтобы попасть в закрытый Telegram чат с доступом навсегда, то можете отправить мне донат на любую сумму от 100 рублей на сервис Boosty: boosty.to/makeyourgame , а я пришлю ссылку в течение 24 часов. Только убедитесь, что у вас открыты сообщения на Boosty.
=================================
Группа в ВКонтакте: vk.com/makeyourgameunreal
=================================
Подписка на канал - только приветствуется!
=================================
#games #unreal #unrealengine
Смотри: у меня файтинг, где по краям экрана есть 2 невидимые стены, пол и потолок, которые ограничивают передвижение ПЕРСОНАЖА, а ещё снаряды определённого типа могут взрываться/останавливаться, отскакивать от, и всё такое. И я делаю КАСТ на каждый снаряд и вызываю поведение в зависимости от того, что там за снаряд и что должно произойти. В итоге стена несёт на себе все снаряды в игре, даже если играть не за персонажа, который может этими снарядами СТРЕЛЯТЬ. Вывод: я хоть и не дурачок, но не обладал ЗНАНИЯМИ... А автор видео мне эти знания ДАЁТ. Теперь надо сделать выводы и исправить ЛОГИКУ в стенах, чтобы они не тащили на себе санки с пятью мужиками.
Какое же понятное разъяснение. Спасибо большое
Это было очень полезно, ранее сталкивался с интерфейсами и особо не заценил их эффективность, пересмотрел свое восприятие...Благодарю автор!!! Все очень понятно и подробно.
Спасибо за видео, если не ошибаюсь Does Implement Interface нода не нужна, интерфейс будет работать без нее отлично только у тех акторов у которых есть интерфейс, во время отсутствия интерфейса - ошибки не будет. Можете залайкать - людям будет полезно.
Демонстрацию получения переменных через интерфейс еще не на одном видео не встречал по данной тематике, а ведь это, наряду с функциями, основополагающая вещь.
Я раза четыре в видео повторил, что если нужно посмотреть как работает все это - есть отдельные видео. Здесь видео о принципиальных отличиях
отдельно отметил для зрителей, в уроке 16 про интерфейсы, примерно на 50 секунде, для получения переменных от иного объекта вы рекомендуете использовать casting,
есть output интерфейса, который можно использовать как get, это наблюдение и послужило причиной моего замечания, но насколько это профитней сказать не могу, может кто внесет ясность о целесообразности подобных манипуляций.
Или же наследование от с++ класса с набором используемых переменных и функций (без mesh, particle и прочего тяжелого) и каст к нему не хуже в плане производительности, а может даже и лучше. А вообще, в данной теме упоминают, что компоненты и композиция для взаимодействия объектов лучше всего, что это за концепция я не представляю, буду рад увидеть что-то из этого.
он просто новичок.Это есть у киберстарт. но там просто про использование без аналитики. Ваш урок очень ценный!!!@@makeyourgame2210
Основная проблема кастров в том, что логика объектов с которыми мы взаимодействуем прописывается в нашем персонаже. Логика должна быть разделена. А с кастом как в этом примере смена материала вызывается в персонаже. И теперь что бы поменять логику кубика надо лезть в персонажа, а если с кубиком взаимодействует несколько объектов - это совсем грусть будет.
Уроки твои очень помогают начать понимать анриал.
Жаль тебе некогда отвечать на вопросы по видео.
Ты приводишь в начале пример в котором через секвенцию делают несколько кастов на разные типы объектов. Это сразу выглядит неоптимально, о чём ты и говоришь.
Но разве нет команды сделать луч и сообщить с чем он столкнулся, а лучше не только первое столкновение, но и все дальше? Луч делаем один раз и получаем например сразу список всего что он "пробил" по своему пути в порядке удаления. А дальше уже этот список как-то обрабатываем.
В описанном тобой методе через отправку сообщений через интерфейс о том, что мы "кидаем луч" - если три разных объекта будут на одной линии один за другим, отработает только первый объект? Можно сделать так, чтобы они все узнали что они на том луче, который мы кинули, один на первой позиции, другой на второй позиции, а третий - на третьей позиции от нас?
Добрый день! Очень понравилось видео. По факту это интерфейсы из c++, ну и других языков, предназначеные показать что данный объект точно имеет в себе реализацию какого-то функционала. Единственное все-таки разделять интефейсы для разных задач, а не запихивать все в один. Если я простолушал про этот момент очень извеняюсь. Спасибо большое за видео.
Класс, все понятно как 2х2
Интерфейсы явно лучше и лично мне их удобней использовать. Хотя к ним я пришёл не сразу и тоже часто использовал касты.
Понятно. Не хватает только простого упоминания про разделение логики объектов. Логика левых предметов не должна находится "внутри" персонажа. Лайк вам)
Очень полезный видео, спасибо
Спасибо полезно! А такого плана вопрос: Если я сделал библиотеку функций и в ней создал один раз через каст ссылки основные (игрок, плайер контроллер и гейм мод)
Тем временем ведущие студии: у нас высокотехнологичная игра, возможно вам стоит обновить железо
Спасибо за ролик. Мне нравится твое объяснение на пальцах, мне было интуитивно не понятно как работают интерфейсы. Обязательно посмотрю твои ролики про касты и интерфейсы. Теперь мне надо перешить все свои блюпринты. Ох... потная катка будет, учитывая что я чуть ли не в каждом БП делал касты. Тысячи их! XD
Такая же фигня, знал что дорого поэтому вызывал только на бэгин плэй, теперь тоже кучу всего нужно переделать))
@@grand3dgames ы
Шикарно, спасибо! А есть или будет тутор по ивент диспатчеру?
Спасибо, ради повышения фпс можно и интерфейсы изучить.
7.56 юмор ОГОНЬ!)))))
Хороший канал, теперь есть куча полезных не просмотренных роликов:)
5:26 кастишь к виджету характер, а там еще касты😂
спасибо большое!!!
Недавно посмотрел ваш урок с стаминой, там у вас каст в виджете выносливости на персонажа с целью его сохранения в перменную персонажа, но переменная персонажа не была задействована в дальнейшей логике., данные качались через каст, а не через переменную с персонажем. Это была пропущено потому что торопились с уроком или потому что если каст сделан. то взаимодействие с этими переменными уже не приводят к дополнительной СУЩЕСТВЕННОЙ нагрузуки?
Урок полезный, единственное, что смущает в интерфейсе- само название сущности.
Потому что в Анриле уже есть UMG интерфейсы и сам первое время путался, когда изучал. Если бы разрабы заменили слово интерфейс на "посредник", ясности было бы больше.
Ну и еще не понял чисто по механике, в какой момент "подгружается" класс, на который делаешь каст. В момент, когда стрелочка на него приходит, или когда вытягиваешь синюю ноду "as actor". Так как сам использую каст только для проверки класса, но из актора логику другого актора никогда не вызываю, так как это не слишком оопэшно.
UMG (Unreal Motion Graphics) - Виджеты (UUserWidget). Не интерфейсы.
А можно видео, где касты уместны?
Я сейчас пытаюсь через кастомный notify state сделать трейс у оружия и кроме каста похоже там ничего использовать не получится или есть другой путь?
Так, стоп, получается при каждом касте создается еще один дубликат актера? То есть его из одной копии можно надюпать 10 тысяч? То есть его даже в наследовании лучше избегшать, не кастить к предмету? (абстракт) - приведение к предмет (бутылка огненной воды) ? Будет дюп актера "предмет"?
Спасибо
Спасибо за ролик. Можешь объяснить, как работает EQS
Это очень сложная система. На объяснение может целый курс понадобиться
А как применить интерфейс если у меня коллмзия сфера при пересечении шейдит оутлайн материал при окончании пересеяения выклбчается как делать это без кастов!?
Супер
Здаров! А как тогда через интерфейс обратится в отдельный виджет? Без каста я что-то не догоняю как сделать!
Тоже недавно столкнулся с данной проблемой... Не подскажете что вам удалось сделать?
очень полезно!
Немного поправлю, если то что вы говорите правда, то это просто провал в ООП, что бы каждый раз в момент каста грузился весь класс, уверен вы допускаете ошибку в своем высказывание, такое поведение на каст - убило бы разработку в многопоточной среде. Пример: Два объекта наносят урон персонажу, оба выполняют каст его внутри своей логики, для последующего вычитания общего количества ХП, и получается что разработчики движка сделали так - копируют при касте, но тогда каждый из тех кто кастует получит копии, первое они будут уменьшать ХП каждый у своей копии , и самое главное основному персонажу вообще как то нет дела, ведь он отдал от себя клонов. Скорее всего идет речь о том что сам каст по себе , подгружает ссылку на игрока а не хранит ее в себе постоянно, это и плохо для работы, потому как реально при наличии множества , ему нужно будет каждый момент грузить эти данные, а потом удалять. Интерфейсы совершенно не решают эту проблему - это разные подходы, "композиция" и наследование. Обратите внимание композиция тут в кавычках - потому что ее нет, просто есть каст который выполняет приведения типа во временной функции. А вот если вы действительно хотели бы рассказать о преимуществе интерфейса, то пример нужно было строить не от отдельного Events, а к примеру создать внутри вашего Класса или Блюпринта, в вашем случае три объекта Куб, Плайн и Сферу, а далее в момент создания класса или блюпринта получить через какст единожды и сохранить полученные данные в эти ссылки , тем самым убрав дорогую операцию в отдельных Events. Вот тогда бы мы увидели зачем нам нужны интерфейсы, когда внутри нашего класса нам бы пришлось выбирать из вашего примера одного из трех, а потом из 20 и так далее, нежели просто использовать назначенный им интерфейс.
Это не мои слова. Я же специально показал, что в описании к касту самими разработчиками указано, что загружается весь блюпринт и это дорого. И да, при касте вы можете получить и достать все что угодно. И нет, это не провал ООП. Это облегчение разработки в некоторых случаях. Те, кто хотят ООП - пожалуйста, есть наследование, прайват переменные, интерфейсы и т.д.
И чем плохи Sequence?
В данном конкретном случае секвенция одновременно кастуется сразу на несколько блюпринтов. Одновременный каст и одновременная логика. Если потребуется какая-нибудь задержка, то нужно делать delay между секвенциями и создавать прочие зависимости. Секвенция будет на себе тащить много всего и много на ней будет завязано, что неудобно
А, в этом плане. Я уж подумал из-за какой-то негативной производитеьлности непосредственно самого этого нода. Тогда можно было просто пустить ветки через Cast Failed. Не одновременно, а последовательно. Нод даже переводится так. За кадр пройдет все по порядку. А вот delay это куда большее зло. Лучше стараться их избегать архитектурно.@@makeyourgame2210
Я вообще не понимаю зачем в разных курсах изучают сначало каст. мало того что создаёт как по мне путаницу, так ещё и вешает на себя работу актора загружая проект.
Не вижу даже простоты его использования
к тому же, я перфекционист и плачу от мишуры с кастами
Очередная пугалка кастами и введение в заблуждение, что-бы сделать аналогичное взаимодействие с кучей объектов нужен 1 каст на 1 класс т.к. наследование и полиморфизм никто не отменял. То что интерфейсы удобней тут не спорю, но всё остальное это страшилки.
А в чем страшилки? В том, что я прочитал примечание разработчиков, что каст делает блюпринт тяжелее за счет другого каста?
И в этом тоже, прочитать то прочитал, а понял ли?@@makeyourgame2210
@@GMTechArt ну тогда расскажите мне пожалуйста, как это нужно правильно понимать?)
Человек делающий уроки про С++ не знает? А вообще очень просто что если данный класс на который делается каст не существует то он будет загружен в память, в случае же с персонажем который с вероятностью 99.9999 уже есть ничего произойдёт т.к. данный класс используется и в памяти уже есть. @@makeyourgame2210
Вот мне кажется что вы заблуждаетесь. А что на счёт каста на один объект из которого идёт наследование и полиморфизм? И весь ваш интерфейс уже к чертям катится и погружает вообще все объекты с этим интерфейсом. Все должно быть в меру!
Замечание справедливое, но отвечу. Я не зря в видео сказал, что давайте представим, что куб - враг, планка - патроны, сфера - транспорт. Думаю вы поняли на что я намекаю. Ни один здравомыслящий человек не будет наследоваться от транспорта, чтобы сделать патроны.
@@makeyourgame2210Хорошо, но ведь в любом случае можно сделать условно 7 родительских классов, это не так много, тем более вешать можно не на сиквенс, а на каст фэил. Тем более если делать что либо по сети - как работать с интерфейсами - не ясно, ведь он не реплицируется.
@@DisoftGDmedia ну хорошо, а что если в одном из семи родительских классов нужна будет другая логика чтобы вызывалась? Ну вдруг понадобилось. Как тогда из ситуации будете выходить? Как будете другую логику из одного каста вызывать, который является родительским для всех других? Делать бранчи? А если в двух дочерних классах поменять что-то? Ещё один бранч?
Вообще дискуссия о том, что касты нужно использовать с примирением всяких кастфэйлов + с использованием дочерних классов я считаю неуместной, когда САМИ ЖЕ РАЗРАБОТЧИКИ на САМОЙ НОДЕ пишут о том, что каст может убить оптимизацию.
@@makeyourgame2210 Ну почему нельзя просто переопределяться функцию? Как по мне самый логичный вариант для другой логики. Никаких проблем не вижу. А вот проблемы с интерфейсами я вижу. Как использовать их в сетевом проекте - я не знаю, вроде как нельзя. Ну а кастить с персонажа на разные классы я считаю нормой. Ну а делать наоборот - не очень, лишь в качестве исключений
@@DisoftGDmediaПо сети все прекрасно работает. Но ваша точка зрения - правильная.
Если вы работаете с деревом классов, то вам хватит обычного каста.
Достаточно переопределить функцию в наследниках и все пойдет как по маслу.
Интерфейсы пригодятся когда, например враг, может быть и AActor и APawn и UObject.
В таком случае дерево классов не возможно, а общее поведение необходимо.
Не все системы (оружие как пример) можно расписать деревом классов.
❤спасибо большое❤