МР
Решил. Мне надо было не сохранять значения переменных после выхода с игры. Решается тэгом [NonSerializable] на нужных полях
Стесняюсь спросить: а с каких пор в СОшниках сохраняются значения по умолчанию?
Size: a a a
2020 May 31
RE
Стесняюсь спросить: а с каких пор в СОшниках сохраняются значения по умолчанию?
Я менял значения в рантайме и после выхода из игры они сохранялись, мне это не подошло
МР
Я не уверен, но вроде так не должно работать.
RE
Я не уверен, но вроде так не должно работать.
Так работает, я проверил) и это логично. Создаёшь экземпляр, вписываешь свои значения и они там навсегда сохраняются. Это как вечноживущий экземпляр класса
МР
И ещё одно. СОшники, в первую очередь сделаны в качестве модели данных, а не места сохранения.
МР
Так работает, я проверил) и это логично. Создаёшь экземпляр, вписываешь свои значения и они там навсегда сохраняются. Это как вечноживущий экземпляр класса
Так что это как раз и не логично
RE
И ещё одно. СОшники, в первую очередь сделаны в качестве модели данных, а не места сохранения.
После этого даже подумал, а почему никто не делает систему сохранения, основанную на scriptable object
NP
После этого даже подумал, а почему никто не делает систему сохранения, основанную на scriptable object
А значения в SO можно меня через скрипт?)
RE
А значения в SO можно меня через скрипт?)
Ну конечно, значения экземпляра
RE
СО - это просто класс, экземпляр которого создаётся при создании файла СО и удаляется только при удалении файла СО
RE
Не считая случаев, когда его экземпляр создают в коде, но я даже не понимаю, зачем так делать
KE
А значения в SO можно меня через скрипт?)
SO для масштабности и избавления от повторений данных ненужных, как хранение игровых сохранение и прочее вообще не подходит
RE
Я их вообще юзаю для хранения данных объектов, вместо хранения этих данных в префабах. И ещё всякие конфиги и настройки
МР
А как вы обращаетесь к СОшнику? По ссылке или Resources.Load<>()?
NP
Я знаю что такое со) но Яне менял значения экземпляра через код, а использовал значения прописанные там
RE
А как вы обращаетесь к СОшнику? По ссылке или Resources.Load<>()?
По ссылке, потому что например, я могу сделать несколько конфигов какого-то объекта на сцене и указывать ссылку на конкретный конфиг, который я к нему хочу применить
E
И по тэгам сравнивать в 21 веке моветон. Уже давно существуют интерфейсы и абстрактные классы.
А почему теги плохо?)
RE
А почему теги плохо?)
Например, потому что это неявное указание, их можно случайно где-то поменять и потом долго дебажить какой-нибудь случайный баг
RE
Разве что все тэги указывать в каком-нибудь scriptable object и обращаться к ним через него
RE
Типа if (collider.tag == MySO.PlayerTag)