OnCollisionEnter запускает даже на выключенном скрипте(

[seaman]

включён только один

Для начала - узнайте что такое "включен". Почитайте мануал, чтобы не было "бреда".
https://docs.unity3d.com/ru/530/ScriptR ... viour.html
" Флажок выключающий MonoBehavior (в редакторе) будет только предотвращать выполнение функций Start(), Awake(), Update(), FixedUpdate(), и OnGUI()."

[greatPretender]

Ок, тонкая организация женской души Юной Юнити))
Но почему при уничтожении объекта через Destroy вызывается OnCollisionEnter? - точнее... это для меня неожиданность. О каком соприкосновении коллайдеров тут идёт речь о коллайдере объекта и террейна чтоли?))

[seaman]

Во первых Destroy не сразу удаляет объект, поэтому вполне возможно OnCollisionEnte успевает сработать.
Во вторых кто знает, что Вы там в проекте делаете.
Юнити точно не вызывает OnCollisionEnte при вызове Destroy.

[greatPretender]

Во первых Destroy не сразу удаляет объект, поэтому вполне возможно OnCollisionEnte успевает сработать.

Ну вот разве так должно быть? Как делаются ААА-проекты, если в движке не прописано, чтобы OnCollisionEnte не срабатывал, если запущена Destroy. Я может что-то не понимаю, но как работать, когда такое в алгоритмке происходит? Как делаются сложные огромные проекты, в кот-ых занято сотни человек? А оказывается всё крашиться из-за такого бага, кот-го быть не должно.

[1max1]

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

[greatPretender]

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

Ок. ладно, я пока это как обошёл. Если будет выстреливать, буду думать...

[samana]

Если я правильно понял, то у вас на одном объекте есть коллайдер и два скрипта атакующий/оборонительный и вы хотите при столкновении коллайдера вызывать метод атаки или обороны в зависимости от состояния объекта (атакует или обороняется?). Тогда может завести enum с двумя этими состояниями, а при столкновении коллайдера, исходя из этого состояния выполнять нужный метод.

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

using UnityEngine;

public class Unit : MonoBehaviour
{
    public enum UnitState
    {
        Attack,
        Defense
    }

    public UnitState currentState; // виден в инспекторе

    private void OnCollisionEnter(Collision collision)
    {
        // в зависимости от состояния, выполняем нужный метод.
        // в метод передаётся текущая коллизия, но это не обязательно, вдруг вам она не нужна.
        if (currentState == UnitState.Attack)
        {
            attackAction(collision);
        }
        else if (currentState == UnitState.Defense)
        {
            defenseAction(collision);
        }
    }

    private void attackAction(Collision collision)
    {
        // делаем что-то в состоянии атаки
    }

    private void defenseAction(Collision collision)
    {
        // делаем что-то в состоянии защиты
    }
}
 

А чтобы коллизия не срабатывала после уничтожении юнита (если вдруг такое получается, хотя странно), то ставьте ему какое нибудь свойство, например isDestoy=true, а в методах коллизии, просто проверяйте это свойство и выполняйте return в самом начале, если оно true.

Синтаксис:

Синтаксис: [ Показать ]

Используется csharp

private void OnCollisionEnter(Collision collision)
{
    if (isDestroy) return;

    // остальной код
}

[greatPretender]

Если я правильно понял, то у вас на одном объекте есть коллайдер и два скрипта атакующий/оборонительный и вы хотите при столкновении коллайдера вызывать метод атаки или обороны в зависимости от состояния объекта (атакует или обороняется?). Тогда может завести enum с двумя этими состояниями, ...

По сути, да. Но я Сделал два скрипта, чтобы избежать этих вечных if и switch, тк по мимо проверки на атак/оборона юниты делятся на юнитов Живого Игрока и Компьютера, а так же на Управляемые ИИ Игрока или Управляемые ИИ Компьютером. Выглядит очень не удобно делать все эти if-ы при проверки каких-л условия состояний юнита и какие методы вызывать для каждого конкретного , поэтому сгруппировал их по скриптам атаки и обороны, т.к. в бою у юнита только один скрипт, выбранный заранее.