Не это, то что вы описали верно, но в моем понимании синглетон которые доступен через Instance не должен уничтожаться в принципе за время жизни приложения.
.Проверка ссылки на null в юнити дял UnityEngine.Object перегружена и вернет будет true
Это справедливо только для редактора, для того, чтобы иметь возможность в Unity проверять ссылки на их объекты. В режиме билда, будет самый null. Это известный прикол уже)
представьте что у вас 1000 объектов в сцене, и только 100 из них оверрайдят метод Update. Вызов пустых методов для 90% объектов, несмотря на то, что они пустые, приведет к ощутимой потере производительности. Собственно оно и сейчас не рекомендуется (я лично по рукам бью) оставлять пустые методы Start и Update в скриптах.
Допустим это появилось в IL2CPP, а как это работало до него в 3 и 4 юнити, где было чисто Mono. Как бы можно было бы понять это всего дело, но C# код это не скрипты, он не разбирается на части через строки, так как это делается с lua. C# код компилируется и при сборке проекта запихивается весь в dll-ку CLI сборка. Из этой dll уже можно конечно вытащить методы, но я не совсем понимаю, как вытащить приватные метод из класса завернутого в dll. Если вы знаете механизм, буду рад услышать. Просто уже реально интересно.
Методы-события не обязательно должны быть приватными.
В этом то и суть) по барабану может быть только из-за рефлексии.
Из C#. Когда у вас ядро на плюсах, а шарп — скрипты, то проблема решается иначе.
Объясните механизм, как получить доступ к методу (публичные не берем в счет) из C++, при как вы называете C# скриптах. Вы же понимаете, что C# скрипты, это не скрипты в понимании настоящем (аля Lua), когда компиляция идет на этапе исполнения. В Unity все скрипты компилируются автоматически при изменении оных, до того как вы что-либо запустите, иначе у вас ни инспектор поля не отобразит да и в принципе ничего работать не будет.
А учитывая то, что на многих платформах теперь вообще ILtoCPP, то рефлекшн там и не может использоваться. Равно как он не используется, судя по всему, ядром Unity. Я могу конечно ошибаться, но насколько я понимаю, из C++ кода вы отражения .NET никак не можете использовать.
IL2CPP это плюсовый интерпретатор C# кода по сути, то что делает CLR (точне CIL/MSIL) в виндовз. Цель простая С++ код работает быстрее. При этом использование рефлексии в коде С# дозволено даже при использовании IL2CPP.
Среди разработчиков бытует мнение, что «магические» методы (Update, Start, OnSceneGUI и другие) реализованы по средствам System.Reflection в C#, однако есть информация, что это не так, и за их работу стоит благодарить C++ ядро Unity3D
Странное какое-то получается мнение о том, что Unity не использует рефлексию для методов Start и etc., а неким интересным способом Mono получает эту информацию и кэширует. Причем способ явно не описан и данное мнение ничем не подтверждается. Получить данные о приватном методе в C# можно только через рефлексию. То что Unity кэширует ссылки на найденные методы это понятно без слов. Я надеюсь, что никто не думает, что каждый вызов Update происходит через поиск MethodInfo по имени.
PS: при компиляции проекта под VS (Windows Store платформа), там тоже Mono выдает каким-то образом информацию о приватных методах?
Хуже будет дальше, когда они начнут делать масштаб и пытаться зарендерить все кружочки попавшие в камеру и весь мир))), а еще попытаться сохранить масштаб кружочка персонажа, чтобы при увеличении карты он не стал размером с пиксель.
Ну что-ж вы так реагируете) Будьте терпимы. Sound Manager это не Вавилонская башня, это реальная вещь, к которой так или иначе придешь, если начнешь делать более или менее серьезные проекты. В 4 юнити без нее вообще никуда, в 5 стало попроще из-за наличия Mixer.
В статье о том и речь, что если объект не перемещается но при этом анимирован, то вот можно его не NavMeshObstacles помечать, а апроксимировать кубами и запечь в карту NavMesh.
Ну так описанная ситуация не к NavMesh имеет отношения, а к физике это раз и к поведению персонажей это два.
Если в первом случае, надо настраивать правильно физические представления, ибо чем меньше значения оных, тем менее точно физика работает. Если у вас коллидеры по 0.1f размером, это не тоже самое, что при 10f. Будут артекфакты, их можно убрать через способ определения колизии, поменять дискретный, на непрерывный.
А в лучшем случае, персонажи не должны давить друг на друга.
NavMeshObstacles, апроксимированный кубами, по тому же принципу что вы описали, для построения сетки пути, работает ровно также. Делали большой проект, пользовались только им для описания статичных не перемещающихся NPC. Все работает отлично в поиске пути. Проблем не замечено. Можете описать, что за проблемы у вас были с NavMeshObstacles
На самом деле если такой вариант вообще случается, то что-то не так в архитектуре игры)). А если по существу, то в данном варианте системы, проверка происходит внутри действия. Поскольку экшены оперируют с внешними данными и объектами, то в них же и проверяется факт удаления или деактивации объекта, если же экшен (а он есть компонент на объекте) работает с сами объектом, то поступаем также.
Интересно, но есть вопросы. А как это система относится к изменениям в цепочках команд? И что если в цепочке у нас может быть 8-10 событий? Или например в каких-то командах после тестов гейм-дизайнерами необходимо поменять передаваемые данные? Или нам надо протестировать в этой цепочки источник и конечного элемент, а у нас еще не готов код промежуточных команд?
На самом деле, при синхронном вызове, узнать откуда пришло событие достаточно просто. Поскольку описанные выше системы построены на вызове функций сохраненных в хеше через рефлексию, то фактически происходит синхронный вызов методов у других классов через прослойку скрывающую от нас реализацию этих классов. Точно также можно ставить точки остановки, получать стэк вызовов (а если пошаманить в Unity, можно получить полный стэк).
Самая большая проблема это ассинхронные сообщения, но это совершенно отдельная история.
SendMessage это вообще рудимент, использовать его для системы сообщений мягко сказать плохо. Единственный его плюс, в возможности вызвать метод у компонента, без получения экземпляра класса, причем любой.
Согласен, тем более, что описанные системы в своей сути синхронны до мозга костей, это надо было уточнить наверное. Если нужны ассинхронные сообщения, тогда надо использовать несколько другой подход.
Это справедливо только для редактора, для того, чтобы иметь возможность в Unity проверять ссылки на их объекты. В режиме билда, будет самый null. Это известный прикол уже)
а можно пример? если не затруднит, давно на С++ кодил, лет 10 назад.
В этом то и суть) по барабану может быть только из-за рефлексии.
Объясните механизм, как получить доступ к методу (публичные не берем в счет) из C++, при как вы называете C# скриптах. Вы же понимаете, что C# скрипты, это не скрипты в понимании настоящем (аля Lua), когда компиляция идет на этапе исполнения. В Unity все скрипты компилируются автоматически при изменении оных, до того как вы что-либо запустите, иначе у вас ни инспектор поля не отобразит да и в принципе ничего работать не будет.
IL2CPP это плюсовый интерпретатор C# кода по сути, то что делает CLR (точне CIL/MSIL) в виндовз. Цель простая С++ код работает быстрее. При этом использование рефлексии в коде С# дозволено даже при использовании IL2CPP.
Странное какое-то получается мнение о том, что Unity не использует рефлексию для методов Start и etc., а неким интересным способом Mono получает эту информацию и кэширует. Причем способ явно не описан и данное мнение ничем не подтверждается. Получить данные о приватном методе в C# можно только через рефлексию. То что Unity кэширует ссылки на найденные методы это понятно без слов. Я надеюсь, что никто не думает, что каждый вызов Update происходит через поиск MethodInfo по имени.
PS: при компиляции проекта под VS (Windows Store платформа), там тоже Mono выдает каким-то образом информацию о приватных методах?
Если в первом случае, надо настраивать правильно физические представления, ибо чем меньше значения оных, тем менее точно физика работает. Если у вас коллидеры по 0.1f размером, это не тоже самое, что при 10f. Будут артекфакты, их можно убрать через способ определения колизии, поменять дискретный, на непрерывный.
А в лучшем случае, персонажи не должны давить друг на друга.
Самая большая проблема это ассинхронные сообщения, но это совершенно отдельная история.
SendMessage это вообще рудимент, использовать его для системы сообщений мягко сказать плохо. Единственный его плюс, в возможности вызвать метод у компонента, без получения экземпляра класса, причем любой.