AD
тут больше интересно влияют ли неактивные элементы на производительность?
если ты про .SetActive(false), то нет не влияют, только когда включаются выключаются будут немного больше тратить ресурсов
Size: a a a
2020 April 08
V
если ты про .SetActive(false), то нет не влияют, только когда включаются выключаются будут немного больше тратить ресурсов
это и хотел узнать, спасибо
AD
это и хотел узнать, спасибо
рада помочь, и не слушай тех кто советует прятать объекты через перемещение в бесконечность и сжатием скейла в 0, а то потом получишь не нужные баги)
V
таким не занимаюсь)
AD
Привет, столкнулся с проблемой наследования. У меня есть два типа сущностей с уроном:
1. снаряды, которые при попадании автоматически наносят урон и их нужно проверять в OnColliderEnter
2. враги и гранаты, которые наносят урон после вызова метода с их стороны
Я попробовал в наследование и добавил IDamagable(тот кто может получать урон) и IDamaging(тот кто урон наносит). Как правильно реализовать различную логику?
1. снаряды, которые при попадании автоматически наносят урон и их нужно проверять в OnColliderEnter
2. враги и гранаты, которые наносят урон после вызова метода с их стороны
Я попробовал в наследование и добавил IDamagable(тот кто может получать урон) и IDamaging(тот кто урон наносит). Как правильно реализовать различную логику?
так наследование возможно от двух интервейсов, разве нет? а так изложенная тобой логика норм будет
F
так наследование возможно от двух интервейсов, разве нет? а так изложенная тобой логика норм будет
Я так и думал наследовать два интерфейса, но как правильно обрабатывать это все не придумал пока, какие методы лучше выделить и кто их будет дергать
AD
Я так и думал наследовать два интерфейса, но как правильно обрабатывать это все не придумал пока, какие методы лучше выделить и кто их будет дергать
ну, сначала реализуй, а там посмотришь)
AD
по ходу дела приходят годные мысли) я так систему всплывающих подсказок реализовала
RM
На 5й версии юнити я могу создать экземпляр класса-наследника monobehaviour через new и соответственно дёргая конструктор в том числе с параметрами. На новых версиях, получается только через AddCompinent? Тогда необходимо будет обязательно открывать нужные при создании поля, чтобы их ручками задать?
F
кек, хотелось бы конечно узнать как лучше сделать сразу, а то годные мысли иногда быстро не приходят
AD
кек, хотелось бы конечно узнать как лучше сделать сразу, а то годные мысли иногда быстро не приходят
не думаю, что тебе так просто тут скажут) начинай реализовывать, а там уже подскажем)
AD
На 5й версии юнити я могу создать экземпляр класса-наследника monobehaviour через new и соответственно дёргая конструктор в том числе с параметрами. На новых версиях, получается только через AddCompinent? Тогда необходимо будет обязательно открывать нужные при создании поля, чтобы их ручками задать?
>открывать нужные при создании поля, чтобы их ручками задать
вот этого не поняла, объясни
вот этого не поняла, объясни
RM
>открывать нужные при создании поля, чтобы их ручками задать
вот этого не поняла, объясни
вот этого не поняла, объясни
Получается, создаю экземпляр :
Myclass mc = gameobject.AddComponent<Myclass>();
mc.x=5;
mc.y ="xD";
x и y должны быть открыты
Myclass mc = gameobject.AddComponent<Myclass>();
mc.x=5;
mc.y ="xD";
x и y должны быть открыты
AD
На 5й версии юнити я могу создать экземпляр класса-наследника monobehaviour через new и соответственно дёргая конструктор в том числе с параметрами. На новых версиях, получается только через AddCompinent? Тогда необходимо будет обязательно открывать нужные при создании поля, чтобы их ручками задать?
вообще, компоненты лучше всего задавать в эдиторе, добавлять компоненты не очень хорошо в апдейте
RM
Где Myclass наследник monobehaviour
AD
Получается, создаю экземпляр :
Myclass mc = gameobject.AddComponent<Myclass>();
mc.x=5;
mc.y ="xD";
x и y должны быть открыты
Myclass mc = gameobject.AddComponent<Myclass>();
mc.x=5;
mc.y ="xD";
x и y должны быть открыты
да, они паблик должны быть
RM
вообще, компоненты лучше всего задавать в эдиторе, добавлять компоненты не очень хорошо в апдейте
Это норм практика, когда не хочу руками дергать. Во время инициализировать в коде. Но вот мне не нравится, что приходится открывать данные, нужные только при создании. И по сути, которые не должны быть открыты везде...
AD
и лучше тогда кешировать такие моменты, типа
а потом в него в эдиторе закидывать этот класс (объект с скриптом этого класса)
[SerializableField] private MyClass mc;
а потом в него в эдиторе закидывать этот класс (объект с скриптом этого класса)
SR
Привет, столкнулся с проблемой наследования. У меня есть два типа сущностей с уроном:
1. снаряды, которые при попадании автоматически наносят урон и их нужно проверять в OnColliderEnter
2. враги и гранаты, которые наносят урон после вызова метода с их стороны
Я попробовал в наследование и добавил IDamagable(тот кто может получать урон) и IDamaging(тот кто урон наносит). Как правильно реализовать различную логику?
1. снаряды, которые при попадании автоматически наносят урон и их нужно проверять в OnColliderEnter
2. враги и гранаты, которые наносят урон после вызова метода с их стороны
Я попробовал в наследование и добавил IDamagable(тот кто может получать урон) и IDamaging(тот кто урон наносит). Как правильно реализовать различную логику?
паттерн Visitor
RM
и лучше тогда кешировать такие моменты, типа
а потом в него в эдиторе закидывать этот класс (объект с скриптом этого класса)
[SerializableField] private MyClass mc;
а потом в него в эдиторе закидывать этот класс (объект с скриптом этого класса)
Я понял, благодарю...) Но я хочется без рук)))