disable saving procedural prefabs in the Editor since the templates are backed by asset files that will change outside the Editor
Signed-off-by: jackalbe <23512001+jackalbe@users.noreply.github.com>
* Add function to Prefab Instances allowing to get a reference to a nested instance by alias.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Refactor the Prefab Focus Handler to use RootAliasPaths to store the reference to the currently focused prefab instance instead of the previous method (entityId of the prefab container).
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Use existing FindNestedInstance method instead of adding new one.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Minor fixes to style and comments
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Removing indexing in GetInstanceReferenceFromRootAliasPath, turn variables into constants where possible.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Modified the Prefab Focus test fixture to ensure the entity hierarchy is generated under the Prefab EOS, allowing tests to work with the new implementation of the focus mode handler.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Ensure RootAliasPath is iterated by reference in GetInstanceReferenceFromRootAliasPath
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
- Deduplicated code for StoreInstanceInPrefabDom.
- Used QueueLoad to load an asset instead of starting a load by getting a new asset instance.
- Extended the error information when failing to load an asset.
- RefreshPrefabDom no longer returns a boolean as it wasn't used.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
At the root the problem is that some editor-only components store information to construct an asset for the runtime component but not the asset itself. This behavior caused the assets to not be correctly detected in two places.
The first place was due to the recent move to PrefDocument to avoid repeated (de)serialization of the PrefabDOM when converting to spawnables. Due to the caching the change from editor-only component to runtime component didn't record the new asset. This has been fixed by allowing assets to be collected on store as well and to check the cache validity when retrieving the list of referenced assets.
The second problem was with loading assets from the in-memory spawnable that's created for Play-In-Editor. Because the newly created assets wouldn't be loaded they need to be explicitly loaded. The original code used the collected list of assets from the PrefabDocument and checked if they were loaded, depending on hot-reloading to trigger a reload on the actual asset. This turned out to not be universally applicable, so instead the Serialize Context is now used to find all the assets that aren't loaded yet and queues a load. This is a bit more expensive to do, but to offset this cost checks are done to only do any operations on assets that haven't been loaded yet which reduces the number of calls to the Asset Manager.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
PrefabCatchmentProcessor::ProcessPrefab was no longer updating the ProcessedObjectStore's referenced object list, this change exposes the referenced asset list in the new PrefabDocument API and uses them to update the referenced asset list.
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
When a PrefabDOM was taken from a PrefabDocument the Instance would continue to have the data from the original Prefab, which means they'd no longer be in sync as the Prefab would be empty. This was fixed by resetting the Instance so they're both clear.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
The new PrefabDocument handles the Prefab and the Instance. This reduces the number of times the Instance has to be reloaded from the Prefab and keeps the entity ids stable between steps. The intention is for all the PrefabDocument to conceptually manipulate the Prefab DOM, although behind the scenes it will manipulate the Instance for now. The Instance should only be directly used in case the PrefabDocument doesn't provide the functionality yet.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
This fixes issues with entities that are moved to another Prefab and have a parent that was also moved to the same Prefab. Entities that have their parent moved to another Prefab continue to work as is because a placeholder entity is always left behind. Entities that are moved to another Prefab but have a parent that's still in the original Prefab will currently not work correctly. This will be a addressed in a future commit.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
In some cases entities created for use as a Spawnable Entity Alias would share an entity id with their original. This is no longer working due to a reverse lookup from an entity id to its PrefabDOM. Upon further investigation this turned out to not matter as instances that are created by the PrefabCatchmentProcessor would create new entity ids any way. This cause unexpected behavior at runtime as entity relations may be broken. This will be addressed in a future fix.
Testing the above also highlighted a possible double delete in the builder when aliases were registered. This has also been fixed.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
While processing prefabs into spawnables new prefabs can be added for later processing. Because the new prefabs were immediately added to the list of prefabs it could happen that the new prefabs would be added to the active processor for processing, which could lead to infinite recursion. Adding prefabs while iterating prefabs now delays the addition until the iteration has completed.
Signed-off-by: AMZN-koppersr <82230785+AMZN-koppersr@users.noreply.github.com>
* Fix several Prefab outliner ordering issues
This change does a few things to address instability in entity order when prefabs are enabled:
- Changes ordering behavior on entity add to always be "insert after the last selected sibling of the new entity, or at the end if there is no selected sibling"
- Adds some logic to ensure selection stays frozen during prefab propagation to allow this behavior to be used
- Alters delta generation in `PrefabPublicHandler::CreateEntity` to use the template instead of reserializing the DOM - this avoids a whole bunch of patching issues caused by EditorEntitySortComponent doing post-hoc order fix-up and should generally be safer/faster as we're producing patches for the actual target for those patches
- Because the duplicate action is DOM-driven, and there's some thorniness around making changes that will affect the template during propagation, this adds `PrefabPublicHandler::AddNewEntityToSortOrder` to directly patch the DOM for the duplicate case
Two bits of this come from patches from the incredibly helpful @AMZN-daimini
- Alters `PrefabPublicHandler::GenerateUndoNodesForEntityChangeAndUpdateCache` behavior for determining what's an override: we now check to see if we're part of the current focused instance but *not* owned by the focus instance directly. This lets entity order for nested prefabs get saved to the owning prefab instead of as an override. I'm putting this up for discussion without a feature flag gating it, but we may wish to make this a toggle or disable it outright for stabilization (in which case entity order won't be saved to the owning prefab)
- Adds a custom serializer for EditorEntitySortComponent. This isn't strictly necessary now, but it was very useful for debugging and ended up receiving much more manual testing its migration path and save/load path more than I've tested without using the serializer.
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Add missing serializers
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Address some review feedback
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Generate patch in `PrefabPublicHandler::CreateEntity` using the instance's fully evaluated template in-memory
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Fix up comment
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Fix Linux build
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Try to make test less timing dependent (haven't been able to repro failure locally)
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Fix another build issue
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Fix unit test failures
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Fix a duplicate issue with sanitization that was causing sporadic test failure (thanks, test!)
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* One more Linux fix...
Signed-off-by: Nicholas Van Sickle <nvsickle@amazon.com>
* Replace Instance References with EntityId of the Prefab Container (WIP)
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Use the invalid entity id for the root instance and get the root instance every time to prevent weird Prefab EOS shenanigans.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Revert unnecessary changes, fix IsOwningPrefabBeingFocused to match previous behavior. Disable some tests that no longer apply correctly due to the testing environment not relying on the Prefab EOS.
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>
* Fix minor typo in test comment
Signed-off-by: Danilo Aimini <82231674+AMZN-daimini@users.noreply.github.com>