Discussion Is there shared component code?

I have about 300 lines of code common to every scene. I moved this into a separate CommonLib (not the actual name) file which uses MonoBehaviour as its base class and reference that file in each of two scenes.

Only the first scene I enter loads and ultimately calls Awake and Start. To be clear I thought since one scene is unloaded that the common component would begin fresh when the second scene loaded. Doesn't seem to be the case.

Have I made an assumptive error or overlooked some "unload this" option? And/or is there a preferred method for sharing code in scenes that need their own instances?

 

After more experimentation and thought I'm coming to the conclusion that I can have "do almost nothing" Awake and Start methods and then add an Initialization method that can be called by the scene it is used in prior to use. Due to the nondeterministic loading of scripts (I believe) I have to actually place such a call in the Update() method of the scene and have a Boolean flag to determine whether it has been called in the scene yet.

Is there a better way? Perhaps someone can acknowledge it as "workable" or suggest something better.

 

Do you have an instance of this object in both scenes, where one gets destroyed and the other instantiated? Or do you have the first object set to DoNotDestroy and are keeping it around?

If you're using the same object, I wouldn't expect to see Awake/Start called again, so that sounds like it's working perfectly. Similarly, if you have the object set up to be accessed as a singleton, you'd have a similar result there. But if they're two different objects being used, this is surprising behavior that I'd be curious to learn more about.

 

Thanks for the reply. The first thing I checked was for DoNotDestroy and I don't see it anywhere and since a player leaves one scene and enters another destroying was the point. It is definitely not a singleton. Now this is a multiplayer app using Photon PUN but I wouldn't expect the class methods to act differently. I did wonder if PUN somehow kept the class around longer and Unity somehow reuses it. Didn't make any logical sense.

The basic behavior now is as I have it below. (That's my logger so don't be confused) but as you can see Awake and Start do nothing now. I added a RoomStart method that takes the place of Start() that my "rooms" call one time in their first Update(). So I get a single copy of the code and the ability to customize a bit via parameters.

If a common class should just work (as we expected) I'll continue to look around but at least for now the common code is isolated.

public class RoomSceneCommon : MonoBehaviour

private void Awake()
{
Logger.Trace($"{nameof(RoomSceneCommon)}.Awake");
}


private void Start()
{
Logger.Trace($"{nameof(RoomSceneCommon)}.Start");
}

 

I've been testing scenarios for days. This simply makes zero sense. I can't even guess what it might be due to. I have 2 "rooms/scenes" school and outdoor. Each has a .cs file associated with it and they both use a common script that my rooms need. They are not marked to not unload, they are not singletons. Whichever room I enter first it executes Awake and Start on the common class. It also executes an activate method to customize the class instance. I leave that room and enter the other one and Awake and Start do not execute and ONLY THE BEGINNING of the RoomStart method executes. There are no errors, things work it just appears that either the logging decides to stop or it has failed to execute the remainder of the method.

The first one is just outputting some additional nonsense log messages and you can see they do not appear when entering the second room but clearly RoomSceneCommon.RoomStart is executing as the first log line shows

... enter the first room

<color=#94EFFC>SchoolSceneManager.Start</color>

<color=#94EFFC>RoomSceneCommon.Awake</color>
<color=#94EFFC>RoomSceneCommon.Start</color>

<color=#94EFFC>RoomSceneCommon.ActivateSchool</color>
<color=#94EFFC>RoomSceneCommon.RoomStart room=School</color>
<color=#94EFFC>RoomSceneCommon.RoomStart 1</color>
<color=#94EFFC>RoomSceneCommon.RoomStart 2</color>
<color=#94EFFC>RoomSceneCommon.RoomStart what=what</color>
<color=#94EFFC>RoomSceneCommon.RoomStart</color>
<color=#94EFFC>OutdoorSceneManager.Start</color>

... enter the second room

<color=#94EFFC>RoomSceneCommon.ActivateOutdoor</color>
<color=#94EFFC>RoomSceneCommon.RoomStart room=Outdoor</color>

 

And because I can't stop wondering what is causing this... I once again duplicated RoomSceneCommon creating 2 copies with only the names changed. Pointed each of my room to the appropriate version and there is an Awake, a Start call and all the logging occurs in each of them.

This is so odd.

 

Finally... I have no idea why but log messages that are static only logged a single time. So the Awake and Start methods were in fact called (which explains why the code worked). But it didn't log the simple "awake" and "start" messages. I added a timestamp to it and it now logs in every case.

So the shared code question is answered, it works. Now only the logging behavior requires an explanation.

 

Ooooh. Do you have the Collapse toggle enabled in the Console window? If that's enabled, instead of seeing multiple entries for duplicate logs, they get collapsed into one and you get a number bubble on the right showing you how many times that message has occurred. Throwing the timestamp in there is just causing the messages to not match and consequently not be collapsed, but you can do this without the timestamp by deactivating the function.

 

That was it... I've posted this in a number of forums and the Pun support guy guessed it as well. Mystery solved! Kind of a double-edged sword I'd say. I'd like the collapse if I logged "asset created" in a loop 10 times but "player left" from two different rooms and possibly minutes apart seems funky.

Thanks.

 

Well, understand that the code is doing exactly the same thing in both cases. It's just the Console window that's collapsing like messages together. There is some sort of threshold on it, because I know even with Collapse enabled I've seen the same message multiple times if enough happen in between, but I can't tell you what the conditions are that cause that.

As someone who was using Unity before the Collapse option was provided, I can say I'm happy it's here. In the rare occasions where you find yourself needing to throw out a log message during Update, you'll flood your console with messages and be unable to find the differing value if you can't lump similar ones all together.

And from the preachery-teachery angle, I'll say it's worth spending the time learning the ins and outs of your tools so you can avoid this kind of confusion in the future.

 

I understand the underlying principle. There are other ways to handle the issues of logging in an update and of course if your update log message includes variable information it doesn't collapse right? So it seems limited at best (to me).

I don't think it is "preachery" but it might be like my suggesting that you learn all about fuel injection before you drive your car. This isn't the only tool and new features are added faster than I can absorb. Practicality suggests that I can't learn all the ins and outs of things before beginning to use at least some of them. In any case I appreciate your answers.

 

Oh, man. I re-read my other post and it definitely comes off way worse than I intended. But that aside, this is one of those situations where I've been using a tool for so long that things that seem obvious to me are absolutely not to someone starting out. I apologize for my lack of perspective, there.

Based on this whole conversation, though, it sounds like you're actually doing fantastic so far. When you ran into something that didn't work how you expected, you didn't just come up with a workaround and move on to the next thing. Nor did you complain and whine or give up to go do something more fun. You stopped to ask what was off about your understanding, discovered it was nothing, and then started troubleshooting. That's a recipe for success as a programmer if ever I've seen one!

 

Please don't even think twice about it. Just 40 years of business software development I retired and thought VR would be a stretch goal It is.

 

Nice! If it's not already on your radar, keep your eyes on VRMADA's upcoming UltimateXR framework, releasing next week! I've been following its progress over the last few years and was stunned to find out recently they're releasing it as a free offering. It should make creating engaging VR experiences in Unity so much more accessible to developers that I honestly expect it to spur a wave of quality VR experiences in the coming 2-3 year period because of it.