#I'm confused about Awake() and script

1 messages · Page 1 of 1 (latest)

craggy hollow
#

Awake is called when you hit play
Yes, but not after script reload

dense tide
#

Are you trying to get code to run in the editor whenever you attach a script?

vocal flower
#

I would not expect Awake to run again after a hot-reload

craggy hollow
#

No, I'm just trying to handle script reload without my scripts breaking

dense tide
#

As in - recompiling during playmode?

craggy hollow
#

presuambly hot-reload is not supposed to break scripts, which means it either should call awake and deserialize, or you actually cannot rely on awake for initialization

#

(I've read that you should put init stuff in OnEnable instead)

dense tide
#

I would say just give up on the notion of changing code while the game is running

#

I've never seen it work properly

craggy hollow
#

But surely recompilation during run is supposed to work, right?

dense tide
#

In like ten years of unity, I have seen no evidence to assume it should

craggy hollow
#

that's surprising, since it seems to reload during run by default

craggy hollow
vocal flower
#

I don't really bother with it myself

#

It loses any non-serializable state

dense tide
#

Yeah I just exit play mode and start it again

vocal flower
#

so, for example, a dictionary would get lost

#

there's a third-party hot reloading system that I haven't tried

craggy hollow
#

If I understand correctly with domain reload enabled it recreates every monobehavior (as in new())
and then tries to restore the state via deserialize, just like it would during entering play mode

#

but for whatever reason it just does not call awake after that

vocal flower
#

are you talking about the "enter play mode options"?

#

which lets you disable the domain and scene reload on entering playmode

#

that would not be relevant for recompilation

craggy hollow
#

I interpret "use awake to init" (when entering play mode) as: we deserialized all the public fields, now you can init any private state based on those

craggy hollow
#

either way from what I gather the unity model is supposed to be simple:
serialized fields are supposed to fully describe object state, such that the important state can be persisted and reset properly
private and static state simply needs to be derived from those when initializing and running your code

vocal flower
#

serialized fields are supposed to fully describe object state

This is not true.

#

They simply describe the state that should be saved in scenes and prefabs.

#

It's very common to store a lot of state entirely in non-serialized fields.

craggy hollow
#

what kind of state for example?

vocal flower
#

a unit's current health

#

If you keep everything in serialized fields, then yes, the built-in hot reload should work

craggy hollow
#

Why not serialize health? because you never want to place a untiy at lower health in the editor?
Again I'm a unity noob, but in my c++ projects I serialize things like health because I also use serialization for savegames

#

State that might not need to be persisted would be things like: animation state or any internal "cached" variables

vocal flower
#

If you use Unity serialization to save the game, then yeah, you'd want to keep all non-recreatable state in serialized fields

#

In that case, it does sound annoying to not have a callback after a hot reload

#

I jsut haven't thought about or dealt with that before

craggy hollow
#

Well, seems like Unity has a less rigorous model than I assumed
Possibly because script reloading was a bit of an afterthought

#

Then I'm going to see if the OnEnable trick fixes it

#

I'm a bit surprised however that there does not seem to be a common best practice here, maybe there are more complications I'm missing

#

Thanks for the help!

#

By the way, currently it's my singleton statics that get reset to null and fail to be initialized
Still not sure how to do singleton script classes properly