Making builds doesn't update Build Settings scene list, possibly causing crashes in builds with some other assets
Closed this issue · 3 comments
Hiya, I'm currently investigating a strange crash that can happen in (Android) builds when opening a scene, and I'm not really sure what causes it yet, but I think it might be a case of multiple assets that aren't working together.
Sometimes builds work, and sometimes a build will always crash upon opening a certain scene. It seems random whether a build works or doesn't. The error looks like this:
The file '/data/app/<PACKAGE_NAME>-1RxH_ypcSUORDI0MIb4cYA==/base.apk/assets/bin/Data/level1' is corrupted! Remove it and launch unity again!
[Position out of bounds!]
Which might be related to #125.
We have Odin Inspector installed in the project, which does an AOT scan on the project. But this always seem to use the scene list that's in the build settings, and not the scene list that's passed onto BuildPipeline.BuildPlayer as SuperUnityBuild does.
After talking with my senior about this it's weird that SuperUnityBuild doesn't automatically (or at least have an option to) automatically set up the scene list, in case other plugins require this to set up the builds properly. I know the "Configure Editor Environment" button does set this up, but I also expected the "Build" button to also do this.
Worth noting that we build multiple apps (with different scene lists) from a single project. This is a VR project, targeting Oculus and Pico devices. Unity 2020.3. We make out builds both locally and via GameCI.
This is still on SuperUnityBuild v5.0.4: #111 is blocking us from updating to the latest version.
I haven't used Odin before but I might be able to answer a few things here...
We have Odin Inspector installed in the project, which does an AOT scan on the project. But this always seem to use the scene list that's in the build settings, and not the scene list that's passed onto
BuildPipeline.BuildPlayeras SuperUnityBuild does.
Correct, since BuildPlayer just uses what you provide it to create the build and prefers not to change your settings in case you have multiple "sets" of scenes for different types of deployments. Essentially, it discards the input and there's probably no easy way for Odin to read it after the fact.
After talking with my senior about this it's weird that SuperUnityBuild doesn't automatically (or at least have an option to) automatically set up the scene list, in case other plugins require this to set up the builds properly. I know the "Configure Editor Environment" button does set this up, but I also expected the "Build" button to also do this.
I believe the idea is that you might have multiple different "releases" and (like above) wouldn't want to mess with the editor settings after performing a build. And if this feature did exist, at first glance it wouldn't be very helpful if you build multiple different releases as you'd only get the changes from the last completed one.
I have a fork of the project called Stellar Unity Build which allows you to do the reverse; always sync the scene list for a release with the contents of the Build Settings list. But if your releases have different scene lists I can see where it becomes an issue.
This is still on SuperUnityBuild v5.0.4: #111 is blocking us from updating to the latest version.
The fix for this is applied in Stellar, which also includes the most up to date changes from SuperUnityBuild. Though I don't think anything changed that could help your situation unfortunately.
Going back to the Build Settings sync after build feature, it shouldn't be too hard to add as an option since the functionality already exists from the environment configuration setting. You might also have some luck creating a Build Action that changes the editor settings after a build is performed, however quickly looking at it, it might be the case that the build scenes are not exposed in the callbacks. You will get a reference to the "Release" though, and through that if you feed in the SuperUnityBuildSettings as a parameter you may be able to parse through the data to collect the build scenes for that release.
That's just a guess though and I realize it creates more hassle than necessary. Let me know if that direction doesn't work out and I can definitely consider adding it natively to Stellar, which may eventually make its way here too.
I haven't used Odin before but I might be able to answer a few things here...
That's just a guess though and I realize it creates more hassle than necessary. Let me know if that direction doesn't work out and I can definitely consider adding it natively to Stellar, which may eventually make its way here too.
While I definitely appreciate you taking the time to help on this topic, I would've preferred if the work done in Stellar was integrated into SuperUnityBuilder as opposed to you coming into the issues on the core repo to pull people into a project which specifically states that it might fragment this community! (I.e.: the READ.ME on Stellar mostly lists non-breaking changes and none of your planned breaking changes?)
Edit: To be a bit more explicit, as I wrote this initially during a sprint review and wanted to come back to it:
My concern is that the dev strength around open-source devops for Unity is already extremely fragmented and splitting the community on what seems to be choices in design that could be picked up in Actions would be quite disrupting. Is there any chance that you could work with SuperUnityBuilder to integrate your ideas?
My concern is that the dev strength around open-source devops for Unity is already extremely fragmented and splitting the community on what seems to be choices in design that could be picked up in Actions would be quite disrupting. Is there any chance that you could work with SuperUnityBuilder to integrate your ideas?
Totally understand your concern, but I think some context might help: I've already been submitting PRs to SUB for many months already and unfortunately the maintainers have been too busy to merge in/tag an official release for the past few months or so. I don't have any issue with waiting but I personally wanted some stuff fixed and adjusted for an easier time making builds, especially for a game I'm releasing soon. So I made Stellar as a way to get my ideas implemented more quickly and share them too in case they're useful.
This is only briefly implied in the README (sorry about that, I'll try and clarify there), but I do intend to have the improvements from Stellar merged into SUB eventually; I just didn't want to overwhelm the maintainers, especially since my work often builds upon previous commits. Currently I'm waiting on #116 and when that's done it's up to the maintainers to merge into main and tag a release. If they approve of my proposed changes I will cherry pick commits to be sent as PRs.
With the two projects structured like this, I believe it's only beneficial to the SUB/open-source devops users because it lets me/others play around with experimental ideas in a timely manner that will eventually improve the base project.
While I definitely appreciate you taking the time to help on this topic, I would've preferred if the work done in Stellar was integrated into SuperUnityBuilder as opposed to you coming into the issues on the core repo to pull people into a project which specifically states that it might fragment this community! (I.e.: the READ.ME on Stellar mostly lists non-breaking changes and none of your planned breaking changes?)
Of course I'm naturally biased because I worked on the project haha but I wasn't intending to just push people into Stellar on a whim so I'm sorry if that wasn't clear. For most people I'd still recommend using regular SUB and if you want advanced "experimental" features and fixes then I wanted people to be aware that Stellar exists. In this case, since #111 was fixed and depending on the use case for scene lists, I believed some of the changes in Stellar might help.
As for breaking changes, besides maybe having to rebuild your settings file, there should be none, and nothing is planned which could break the API either. I simply wanted to warn people of possible future changes which is why the readme says not to rely on compatibility. But for now it's only because the changes have not been submitted to SUB yet, not because of any design difference; i.e. SUB doesn't have the new features/fields that were added.
In the end though, my original comment suggested an Action-based approach that works with the standard SuperUnityBuild and only if that doesn't work or is too inconvenient is when advance changes could be made to Stellar, and then eventually merged into SUB when I see some progress on the current PRs. I'm open to suggestions though and if you'd like me to try submitting the work I have now I don't mind, but be aware that it may take a while to review.