After weeks of testing and bug fixing, my latest plug-in, Advanced Multi-Sceneis now available on the Asset Store.
The plug-in addresses some of the shortcomings of using Unity’s built-in Multi-Scene features. Features include:
Automatic save and restore of your multi-scene setup in editor
Automatic load of your scene setup at runtime (with options on how to load)
Ability to ‘bake’ (merge) a sub-scene into your main scene at build-time, reducing load times and alleviating order-dependent script issues.
Automatic save & restore of cross-scene references in the editor AND at runtime, allowing a reference from Scene-A to correctly reference an object in Scene-B.
Here is a video showing off the plug-in and highlighting some Unity functionality as well as the features of the plugin:
This looks great, and I appreciate all the work you must have been doing to keep AAS playing nicely with the rapid pace of Unity updates.
Here’s a question about AMS for you… will you be able to tuck a subscene under a node in the hierarchy, or must they all live at the root level? I loved (and built my architecture around) the fact that AAS references could be anywhere.
Unfortunately not. I tried convincing the developers this was desirable but failed. As it currently stands, no reparenting of a scene and you are unable to load the same scene multiple times without first merging a scene. I’d be extremely happy if you brought up this functionality in a more visible place because it always looks like I’m the only one advocating these features and I think Unity thinks I’m crazy.
Yes, those appear to be a few oversights when not using cross-scene references.
The AmsMultiSceneSetup object is not mandatory on non-main scenes, but it is difficult to determine if a scene is going to be a main scene or not (hence the checkbox). I believe Unity internally marks the scene as the “active scene” during the save process, so there’s not a whole lot we can do about that.
For now, I don’t have a good strategy to detect a new scene is opened (apparently that API is coming in 5.4), so I can’t do much to address points 1 and 3, but have made an effort to address point #2. Please send me an e-mail if you’d like the beta.
AMS is working well! We did encounter one problem that may have more to do with Unity than with AMS though, but perhaps you could still take a look at it.
When you bake a NavMesh with multiple scenes open, the navmesh file gets baked in a directory named after the active scene. The file gets REFERENCED, however, by every scene you currently have open. So in our case we have subscenes that are used by multiple scenes, and they just accumulate navmeshes. Then you end up with either an error that navmesh settings have to be the same, or if every scene has the same settings, with multiple navmeshes on top of each other (which, in case you’re wondering, confuses the hell out of navmesh agents).
Our current stop-gap solution is to bake the navmeshes for every main scene, then open all the subscenes seperately and clear their navmeshes (or revert changes to the other scenes with version control). It works, but it’s not really ideal.
It’d be nice if there were some way to bake navmeshes ONLY to the active scene (or even only to a selected subscene).
Indeed we’ve had that issue and it is a Unity issue. What we do is right-click on the scene and hit “unload scene” on all scenes you don’t want referencing (or contributing to) the NavMesh. You can then re-open them after the bake.
You can use this same strategy if you bake your lightmaps you’ll also encounter a similar issue where it will bake for all open scenes, but generates a new lightmap per scene. The issue with lightmaps is that regardless of your geometry in those scenes, having four or more scenes opened just killed my machine by running out of memory.
Send a PM about my e-mail address. But the rest of the issues are that you need to avoid the cross-scene referencing in Awake(). The reason is that even though it’ll work in a real build when baking, the Editor callbacks are a frame behind (it’s a Unity issue). For this reason you need to push your initialization code from Awake() to Start() and hopefully the issues will be solved after that.
There’s a new beta that I’ve been working on to resolve some issues with cross-scene references and baked levels. I haven’t yet submitted it to the store but when you send me an e-mail I’ll send you the latest.
Hi, I’ve just purchased the plugin and testing it out. It looks like reference in UnityEvent listener does not get save. For example, uGUI’s Button class has a OnClick UnityEvent which user can add listeners to. Having a reference to another scene and saving the main scene produce the following error:
Ams Plugin: Could not perform a runtime resolve on cross-scene reference TestScene’/Base Level’ (UI.Button).m_OnClick.m_PersistentCalls.m_Calls,0.m_Target => TestScene2’/Static’ (GameObject).
Reason: Cross-Scene Ref: TestScene’/Base Level’ (UI.Button).m_OnClick.m_PersistentCalls.m_Calls,0.m_Target => TestScene2’/Static’ (GameObject). Could not Resolve fromObject . Please review Documentation.
UnityEngine.Debug:LogErrorFormat(Object, String, Object[ ])
CodingJar.MultiScene.AmsDebug:LogError(Object, String, Object[ ]) (at Assets/CodingJar/MultiScene/Scripts/AmsDebug.cs:59)
CodingJar.MultiScene.Editor.AmsCrossSceneReferenceProcessor:SaveCrossSceneReferences(List1) (at Assets/CodingJar/MultiScene/Editor/AmsCrossSceneReferenceProcessor.cs:205) CodingJar.MultiScene.Editor.AmsSaveProcessor:HandleCrossSceneReferences(IList1) (at Assets/CodingJar/MultiScene/Editor/AmsSaveProcessor.cs:72)
CodingJar.MultiScene.Editor.AmsSaveProcessor:OnWillSaveAssets(String[ ]) (at Assets/CodingJar/MultiScene/Editor/AmsSaveProcessor.cs:35)
UnityEditor.GenericMenu:CatchMenu(Object, String[ ], Int32)
You’re quite right, the serialization path was more tricky than I expected. I’ve got a fix, e-mail me at the address in the Documentation and I’ll send you the beta fix. Everyone else can expect a fix submitted to the store in the next week.
If there are two components of same type in the same game object, the serialization has trouble distinguish them. In some cases it throws error (for two PlayMaker FSM in the same object), other times it only saves one of the references (each component have a UnityEvent) without any warning. I know that the path is ambiguous in this case but is there a way around it? At the very least throw error if it can’t correctly serialize it.
The path is ambiguous. It should be throwing an error. It’s next on my TODO list to fix this (so the serialization does work, and CAN be distinguished). Send me an e-mail if you want the beta, I’m going to be working on it later this week.
Now that GDC is finished my team and I are interested in updating from Unity 5.1 and the last version of AAS to Unity 5.3 and AMS.
I was wondering if you might have some advice as to the best way for us to approach the update, since our game is relatively large and makes heavy use of nested subscenes.
Each of our levels are broken into a number of room subscenes, and each of those rooms have quite a few subscenes of their own. So on average a level is comprised of well over 200 individual scenes. I’ve looked at the upgrade section of the readme for the new AMS and upgrading everything by hand as described in that document seems like it would be a huge pain.
We’re also sort of at a loss on how we are going to handle the loss of nested subscenes and how that is going to affect our workflow. I had substantially extended AAS for the team, as well as built a number of internal tools which used AAS’s features extensively.
For instance I made a room generating wizard for the level design team so they could easily make setup a room with all it’s need subscenes from a template file:
And here you can see a shot of our internal level map / portal editor, as well as a shot of our hierarchy so you can see how our levels are generally setup:
It has a number of features like drag an drop a scene from the project view and auto add it to the hierarchy as a sub scene.
I want to keep to be able to keep the subscenes in the individual rooms because it’s really nice for situations like when the environment artists are tweaking geo in Level_Static and the animator is working in the cinimatics subscene without any conflicts ect.
But It seems like our work flow is going to need to substantially change once we upgrade.
I was just wondering is you might have any advice for me to help make the transition as smooth as possible for my team.
Thanks for your work and we’ve really enjoyed what AAS has allowed us to do so far.
That’s quite a substantial workflow. I have made changes to Advanced Additive Scenes since 5.3 came out which should allow you to sunset AAS over time (i.e. it should work in 5.3). In one of my AAS projects, I have imported Advanced Multi-Scene and the two currently co-exist before we’re ready to finish the switch. Depending on your expected lifecycle of this project (e.g. if it is maintenance-only / critical fixes only) you may be able to get away with AAS for the remainder of your development.
Having said that, AMS brings better cross-scene referencing support which will work even with additive-ly loaded scenes (which I would guess is what you’re trying to achieve – a sort of streaming system?) The cross-scene references also work without modifying the destination scene, so it’s a bit nicer. It’s also the system currently in development, and follows the Unity-“blessed” workflow of no SubScenes.
You wouldn’t want to manually convert this project over. You would need to write a conversion script. Here’s a strategy I would use. Start by having the plug-ins live side-by-side in Unity 5.3.
Old SubScenes to Multi-Scenes
Make sure all of the SubScenes are loaded
Unlock all of the SubScenes (this restores the cross-scene references)
Call SceneManagerment.NewScene and give it a name like AMS-OldName for every SubScene
Inverse-transform the AAS SubScene Objects, move them to the root, then use SceneManagement.MoveGameObject to move those objects to the newly created scene.
Optional: Save the scenes now, and do a sanity check to make sure your cross-scene references are intact
Destroy the now-empty AAS GameObjects.
Destroy the AAS placeholder objects (e.g. ! SceneData).
Save
If your workflow relies on the hierarchy of the SubScenes, you’re in a bit more trouble. You can write scripts to reparent at runtime (if using Additive Loading) or during the baked step (using Baked Loading). Note: There’s a bit of kludge right now for the baking process due to some incompatibilities with Unity’s method which will hopefully be alleviated in 5.4 (it exists in two places - one for running in Editor and one for the actual build).
One of the nice things about AMS is I’ve released it as source-code only, so no building DLLs which became unwieldy with the amount of Unity releases there are. For that reason when you grab the package, you have the full source code right there and the functionality is a lot easier to manage so hopefully your custom editor scripts will be easier to port over.
I have a main scene with additional 4 baked scenes running in the editor.
In my current test I’m seeing the loading order of the objects be rearranged and muddled. It would seem that some components reach Update before other components even do Awake even on the same object.
From what I understand, the way AMS handles the cross-scene references and reloading is by killing and recreating things, and doing this it means that objects don’t obey normal initialization order at all.
I have a component which other components on the same object look for and register to (on Start); if they don’t find that component they kill themselves. If the container component finds itself empty on Update it kills itself.
—The container is killing itself, but the registering objects aren’t, which would suggest they are getting Start called after the container gets it’s first update.—
[Edit (Correction): Upon further inspection, I noted that not all of the objects with such containers were having issues. I revise my previous assessment. I now believe that the components are being swapped out piecemeal in a relatively arbitrary order resulting in the registering components registering themselves to a component that is then destroyed and remade, resulting in it being empty. Odd, as the container has no cross-scene references. I’ll test this hypothesis.]
Can you work/are you working to improve this? Are there workarounds?
It also seems that Awake happens before the cross-references are reapplied. Is this the “baked scenes in editor issue”?
Is there an ETA on when the beta will really release? Depending on the timeframe I might send you an email about that beta test.
Thanks! The plugin offers really great functionality and works well outside of the quirks mentioned here and in your post above.
[Edit (Addendum): Tested hypothesis above. Seems to be correct; the component is destroyed containing registrations. I managed a workaround by getting the components on the container’s OnEnable rather than having them register, but this limits their power. I’m not sure why the component is killed and recreated if it has no cross-scene references to apply, but this makes it sound like the issue could actually be caused by the editor timing issues. I’m not sure of the extent of that.
I have one last issue I’ve not seen elsewhere: does the cross-scene referencing not support arrays/lists? I have an object which refers to objects in other scenes as a list. The list doesn’t seem to get populated properly.]
[Edit (Addendum 2): Does the cross-reference replacement happen after Awake on a component? Is that an editor issue? Is it fixed in the beta / being worked on?]
