Unity пересоздает объекты, но не обновляет ссылки

[Alkos26Rus]

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

Это прям смешно, GC коллектор проверяет все ссылки на объект, но может удосужиться проверить статус объекта удален\не удален? А для того что бы GC не делал лишнюю работу, не проще ли очищать память при удалении объекта, тогда не будет таких диких скачков от GC? Мало ли что можно руками сделать, это вопрос здравого смысла, я удаляю - значит он мне больше нафиг не нужен, ни в каких видах, я хочу и расчитываю очистить память под другие объекты, но нет, память засоряется не пойми чем, что ты в 99% случаях не когда не запросишь, ну не бред ли это? Нет такого случая когда бы тебе потребоволось ссылаться на удаленный объект, если тебе такое потребуется в 0.0001% случаях, то сделай систему на сохранения данных сам, это же логично.

[TeslaGan]

Это прям смешно, GC коллектор проверяет все ссылки на объект, но может удосужиться проверить статус объекта удален\не удален? А для того что бы GC не делал лишнюю работу, не проще ли очищать память при удалении объекта, тогда не будет таких диких скачков от GC? Мало ли что можно руками сделать, это вопрос здравого смысла, я удаляю - значит он мне больше нафиг не нужен, ни в каких видах, я хочу и расчитываю очистить память под другие объекты, но нет, память засоряется не пойми чем, что ты в 99% случаях не когда не запросишь, ну не бред ли это? Нет такого случая когда бы тебе потребоволось ссылаться на удаленный объект, если тебе такое потребуется в 0.0001% случаях, то сделай систему на сохранения данных сам, это же логично.

а все потому что нет метки удален ли ваш объект... в большинстве своем задача была бы простой... но все портят неуправляемые ресурсы. они есть во всех языках. они портят жизнь всем программистам. они в 99% случаев не нужны(ну ладно, в 90%)... но из-за них приходится менять подходы к взаимодействию с объектами.
вообще этот диалог сводится к ситуации:
-мне дали персонажа, он умеет бегать, прыгать, приседать, но вот делать двойной прыжок нет.
-ну так допиши ты ему второй прыжок, там есть такая возможность
-нет, он обязан делать двойной прыжок по умолчанию

[Alkos26Rus]

а все потому что нет метки удален ли ваш объект... в большинстве своем задача была бы простой... но все портят неуправляемые ресурсы. они есть во всех языках. они портят жизнь всем программистам. они в 99% случаев не нужны(ну ладно, в 90%)... но из-за них приходится менять подходы к взаимодействию с объектами.

В том то и дело что такая метка есть, посмотри на ссылку после удаления объекта, она отлична от Null. Вот ошибка которую тебе выдаст, если ты попытаешся удалить удаленный объект "MissingReferenceException: The object of type 'test2' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object."

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

Это не корректная аналогия, скорее мне дали персонажа который не может ходить.

[1max1]

GC: ждет пока программист обнулите все ссылки на объект.
Программист: ждет пока GC сам обнулит все ссылки на объект.
Объект: охреневает от происходящего))

[TeslaGan]

создал тему на зарубежном форуме. посмотрим что они скажут

[TeslaGan]

ну и вот собственно ответ:

Here is what's happening:

In C#, you do not release memory until all the references to an object get destroyed. You have an active reference to an instance of ScriptTwo class. This is vastly different than its gameobject! And this is important! The game object you have the ScriptTwo on just holds another reference to the instance of ScriptTwo.

When you destroy the gameobject, you destroy ONE reference to the instance of ScriptTwo. You still have another one in your ScriptOne script. So the instance will not be cleared up by the Garbage Collector.

In these cases you need to set your reference to null manually. Unity cannot do this.

или в переводе:
C# не освобождает память до тех пор, пока все ссылки на объект не будут уничтожены. У вас есть активная ссылка на экземпляр класса ScriptTwo. Игровой объект также содержит ссылку на ScriptTwo.
Когда вы уничтожаете игровой объект, вы уничтожаете ОДНУ ссылку на экземпляр ScriptTwo. Но в вашем скрипте ScriptOne остается ссылка. Таким образом, экземпляр не будет очищен сборщиком мусора.
В этих случаях вам необходимо вручную установить для ссылки значение null. Unity не может этого сделать.

[1max1]

Unity cannot do this.

И треснул мир напополам... дымит пукан...

[TeslaGan]

В том то и дело что такая метка есть, посмотри на ссылку после удаления объекта, она отлична от Null. Вот ошибка которую тебе выдаст, если ты попытаешся удалить удаленный объект "MissingReferenceException: The object of type 'test2' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object."

а вот ответ и на этот вопрос подвезли https://blog.unity.com/technology/custo ... we-keep-it

[Alkos26Rus]

В том то и дело что такая метка есть, посмотри на ссылку после удаления объекта, она отлична от Null. Вот ошибка которую тебе выдаст, если ты попытаешся удалить удаленный объект "MissingReferenceException: The object of type 'test2' has been destroyed but you are still trying to access it.
Your script should either check if it is null or you should not destroy the object."

а вот ответ и на этот вопрос подвезли https://blog.unity.com/technology/custo ... we-keep-it

Как я понял основное оправдание этой хрени, это более информативная ошибка и проблемы с женитьбой с# и с++, как вобщем то я и говроил что это недоработка, а не фича. Фальшивые C# объекты оболочки, это конечно топ, вроде не видишь бобра, а он есть.

[Razor89]

Вот и получается, как написано в статье, что даже при использовании некоторых стандартных функций по типу GetComponent<T> по отношению к "уничтоженным" объектам, каждый такой запрос будет выделять память. И как я понял происходит утечка в конечном итоге, которую невозможно отследить, если ты не знаешь таких нюансов работы с объектами на более низком уровне. Что собственно вроде-как и не должен знать, ведь для этого и были придуманы GC. То- есть исходя из такой логики, попытки оставить ссылки на обьект и с ним как то взаимодействовать после его удаления могут приводить даже к переполнению памяти, грубо говоря. При этом проблема может скрываться в одной ссылке которую забыл удалить, даже если сделал Destroy. И редактор тебе об этом никогда ничего не скажет, просто со временем приложение будет жрать все больше памяти пропорционально времени его работы.

[TeslaGan]

Вот и получается, как написано в статье, что даже при использовании некоторых стандартных функций по типу GetComponent<T> по отношению к "уничтоженным" объектам, каждый такой запрос будет выделять память. И как я понял происходит утечка в конечном итоге, которую невозможно отследить, если ты не знаешь таких нюансов работы с объектами на более низком уровне. Что собственно вроде-как и не должен знать, ведь для этого и были придуманы GC. То- есть исходя из такой логики, попытки оставить ссылки на обьект и с ним как то взаимодействовать после его удаления могут приводить даже к переполнению памяти, грубо говоря. При этом проблема может скрываться в одной ссылке которую забыл удалить, даже если сделал Destroy. И редактор тебе об этом никогда ничего не скажет, просто со временем приложение будет жрать все больше памяти пропорционально времени его работы.

ну вобщем-то все осталось так же, как и было 100 лет уже... если наследил где-то, не забудь ссылочку убрать...

[Razor89]

Вот и получается, как написано в статье, что даже при использовании некоторых стандартных функций по типу GetComponent<T> по отношению к "уничтоженным" объектам, каждый такой запрос будет выделять память. И как я понял происходит утечка в конечном итоге, которую невозможно отследить, если ты не знаешь таких нюансов работы с объектами на более низком уровне. Что собственно вроде-как и не должен знать, ведь для этого и были придуманы GC. То- есть исходя из такой логики, попытки оставить ссылки на обьект и с ним как то взаимодействовать после его удаления могут приводить даже к переполнению памяти, грубо говоря. При этом проблема может скрываться в одной ссылке которую забыл удалить, даже если сделал Destroy. И редактор тебе об этом никогда ничего не скажет, просто со временем приложение будет жрать все больше памяти пропорционально времени его работы.

ну вобщем-то все осталось так же, как и было 100 лет уже... если наследил где-то, не забудь ссылочку убрать...

https://docs.unrealengine.com/4.26/en-US/ProgrammingAndScripting/ProgrammingWithCPP/UnrealArchitecture/Objects/Optimizations/

Unreal implements a garbage collection scheme whereby UObjects that are no longer referenced or have been explicitly flagged for destruction will be cleaned up at regular intervals. The engine builds a reference graph to determine which UObjects are still in use and which ones are orphaned. At the root of this graph is a set of UObjects designated as the "root set". Any UObject can be added to the root set. When garbage collection occurs, the engine can track all referenced UObjects by searching the tree of known UObject references, starting from the root set. Any unreferenced UObjects, meaning those which are not found in the tree search, will be assumed to be unneeded, and will be removed.

One practical implication here is that you typically need to maintain a UPROPERTY reference to any Object you wish to keep alive, or store a pointer to it in a TArray or other Unreal Engine container class. Actors and their Components are frequently an exception to this, since the Actors are usually referenced by an Object that links back to the root set, such as the Level to which they belong, and the Actor's Components are referenced by the Actor itself. Actors can be explicitly marked for destruction by calling their Destroy function, which is the standard way to remove an Actor from an in-progress game. Components can be destroyed explicitly with the DestroyComponent function, but they are usually destroyed when their owning Actor is removed from the game.

Интересно то, что в Unreal можно явно помечать обьекты для удаления сборщиком мусора.

[TeslaGan]

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

[AngryCat]

Ну ты можешь ипользовать в классе интерфейс IDisposable и оборачивать класс в using