Is it possible to convert/bake Subscenes into Entities without using the com.unity.platforms and BuildConfiguration assets? Or do I have to use this extraneous build process to do so?
#For DOTS 0.51, how do I Convert/Bake SubScenes into Entities in Standalone Builds?
restive dew
dire gazelle
it's been forever since i looked at 0.51 but yeah i think we got rid of that only for 1.0
1.0 is also way better than 0.51
and, like, supported and stuff
restive dew
yes, yes. my company is currently just stuck in 0.51 due to us having started building out game way back in 0.17 days.
we're looking into going to 1.0, but it's requiring major overhauls
dire gazelle
yep. but hopefully you'll see big speed as a result
restive dew
I'm running into a really bizarre problem where I recently altered our automated build pipeline to use a BuildConfiguration asset to build a standalone build. However, when the build is complete, it tries to automatically open the build.
dire gazelle
is the asset set to build and run or something
restive dew
that's a weird thing, because that "build and run" is not stored on the asset.
it is a dropdown in the editor, but our automated build machine doesn't have a graphics card, so I can't open the editor
so that's the dropdown you're talking about, on the BuildConfiguration asset
dire gazelle
yep
huh. yeah, i mean those always had a ton of unexpected behavior in my experience. do you know what you changed when it started happening?
restive dew
(this is a screenshot from my personal machine)
the only thing I am aware of that I changed is "hey, stop using this old build process because we now have a subscene that needs to convert entities"
to "start using the BuildConfiguration asset"
the commandline commands to trigger the build are exactly the same
dire gazelle
oh i see, so maybe it always had this problem
restive dew
it seems to be a unique problem for our automated build machine too.
like if I ask my personal machine to build from the commandline, it doesn't try to auto-run the build
same git commit, no code differences
dire gazelle
curiouser and curiouser
this makes no sense but what if you run with -nographics
(to emulate not having a gfx card)
restive dew
so I don't want my automated build machine to run it at all
dire gazelle
no i know
what if you run the editor with -nographics
so it's closer to the build machine experience
restive dew
oh on my personal machine? yeah, I tested that. It does not try to auto-open the build.
dire gazelle
geez!
restive dew
yeah it's really very bizarre
dire gazelle
yeah i mean this stuff was always a nightmare for me to dive into as well. the code of those things is not pleasant.
you do have it, so if you really need to you can dive in
but if it were me i would just upgrade to 1.0 and try to make a build from there
we've fixed a crapload of player-build-specific bugs in 1.0 as well that i bet are still there in 0.51
(i'm not making light of the work it will take to upgrade, to be clear. i just think it's a better investment of time than diving into this old code that won't exist later anyway.)
restive dew
well we are on that path to 1.0, which does make it frustrating that in the meantime 0.51 isn't working out, but these are internal struggles for me and my company of course
i agree with you about not trying to spend a lot of times on getting this to work when we are in the process of moving to 0.51 and just accepting our automated builds may be broken right now
dire gazelle
oh interesting you're moving TO 0.51
restive dew
because the build DOES succeed, it's just the autoopening makes the automated build fail
no no
we're moving to 1.0
from 0.51
dire gazelle
oh ok
i think for some projects there could be an argument for goign from 0.17 to 1.0 via 0.51 because maybe the scriptupdaters are better or something
but i suspect it's probably not net better
and sounds like that's not your situation anyway
dire gazelle
well. one poorly-advertised bit of 1.0 is that we have new alternatives to Entities.ForEach that take 4x less time to compile 🙂 which means that iteration time should improve significantly after you migrate that stuff (but to be clear EFE still works in 1.0, it's just less recommended for that exact reason)
restive dew
oh yeah, we're well aware of the benefits to moving to 1.0
we just started our game in 0.17
and moved to 0.51 for netcode, and then after that 1.0 stuff started coming out
so we've been in a constant state of trying to keep something going while also upgrading
dire gazelle
yep, makes sense.
restive dew
anyway, I may submit a bug ticket for this BuildConfiguration stuff and try to convince my company that automated builds may just be broken
dire gazelle
you could try to kill the build after that or something, maybe?
i strongly doubt a bug ticket would matter for this particular area, since nobody really owns those things
upbeat ravine
Wish we could move to 1.0 at work
0.51 but not even on 2021 due to a huge amount of unexpected issues, though we'll have to resolve that by July due to end of life console support on 2020.3 lts, just hoping we can launch before then
We have like 2 years of 2021 lts (I think lts support changes to 3 from 2 years in 2021?) before we'd be forced to upgrade to 1.0 or end project life
So yeah I feel your pain tylo!
dire gazelle
are the things forcing not to upgrade just fear of 22.2 instability? or amount of code written in the 0.51 way? or something else?
upbeat ravine
mostly the effort required
and the constant, we're about to launch no time, oh never mind delayed -_-
a quick count we have at least 550 EFE and JWC so we'd need to rewrite enormous amounts to code to get iteration benefits
i believe it's probably more though as we have 544 implementations of SystemBase (many have manual jobs though)
it's just a really old project started, i'm not 100% certain as I wasn't at the company at the time, but probably around 0.12 or 0.10
i very much look forward to starting our new project where we can do things right
restive dew
I figured out the problem.
Looking in the source code for BuildConfigurationInspector.cs the dropdown value gets saved into EditorPrefs which I believe works similar to PlayerPrefs
so running the build from the command line was using the default value of EditorPrefs which is BuildAndRun
I found out what the key is, and manually set it to do Build before running my Build from the command line
Basically, whatever value you last set the BuildConfigurationInspector to be will be "remembered" when you build from commandline and used
because it is looking at the value in EditorPrefs
I've been burned by the usage of PlayerPrefs before, since those values are stored in like....the Windows Registery I think?
restive dew
EditorPrefs.SetInt("BuildConfigurationInspector.CurrentActionIndex", 0); forces the BuildConfiguration to do a Build
BuildAndRun is 1, and is also the default value if the setting isn't set properly
upbeat ravine
Interesting, we don't use build configs that much (because we don't use subscenes in this project 😫) but I am definitely going to keep this in mind just in case
restive dew
We didn't use subscenes either until we started using Netcode
As far as I know you have to convert your components that have ghostfields at editor time, or they don't work
upbeat ravine
Yeah in 1.0 you can actually use GhostPrefabCreation api but no alternative in 0.51 as far as I'm aware