* Improve the errors in EngineFinder.cmake
Added additional info on one of the errors to help users resolve the
issue (engine registration).
Improved readability of the errors.
Signed-off-by: amzn-phist <52085794+amzn-phist@users.noreply.github.com>
* Adds another error message to EngineFinder.cmake
An error message where the user's manifest is present and valid
but no matching engine name was found has been added.
Signed-off-by: amzn-phist <52085794+amzn-phist@users.noreply.github.com>
* Convert resolved wildcard paths to relative path before saving in database.
Warn if file could not be converted to a relative path.
Fix FindWildcardMatches path handling that could result in pathMatch missing the first character
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Handle abs path wildcard dependencies
Remove dependencies outside of scan folder
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Switch to AZ::IO::PathView for abs path check
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
* Made code a little more clear
Signed-off-by: amzn-mike <80125227+amzn-mike@users.noreply.github.com>
The Test runs with a wait_for_condition, and the original timeout was right on the edge of how long the test takes to reach that condition.
Signed-off-by: amzn-sean <75276488+amzn-sean@users.noreply.github.com>
The test was relying on immediate updates from the prefab system which are now scheduled for a later tick - this reworks the tests to wait for deferred updates before validating state
Signed-off-by: nvsickle <nvsickle@amazon.com>
* Added anchor key parameter to the SettingsRegistry MergeSettings
This allows the MergeSettings function to write JSON data anchored
underneath the supplied anchor path.
Upgraded the SignalNotifiers calls in SetObject, MergeSettings and
MergeSettingsFileInternal to query the type of the merge value at the anchor path
and supply that as the type to the notification event.
Also the the above functions now supply the anchor key root as the
path that was modified instead of assuming root ""
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Fixed whitespace inconsistencies in SettingsRegistryImpl
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* Added a queue for storing SignalNotifier calls when a thread is
currently signaling.
The queued calls are invoked by that thread after it has signaled it's
current queue of events
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
* {lyn7251} Add material component example in Python
adds a AZ::Render::EditorMaterialComponent as an example of how to
override the default material from the scene building pipeline
Signed-off-by: jackalbe <23512001+jackalbe@users.noreply.github.com>
* Only set the cube to a gray material
Skip loading the asset, instead just set the outPrefabAssetPath for the Prefab system to load
Signed-off-by: jackalbe <23512001+jackalbe@users.noreply.github.com>
* stablizing the sub-id of procedural prefab groups
Signed-off-by: jackalbe <23512001+jackalbe@users.noreply.github.com>
The AZ_ENABLE_TRACING check was preventing the Archive System from using the sys_PakPriority value set from the CVar system
Signed-off-by: lumberyard-employee-dm <56135373+lumberyard-employee-dm@users.noreply.github.com>
- Updated the RenderViewportWidget::event method to call 'SendWindowResizeEvent' on specific events
- Moved the onResize to one of the events in RenderViewportWidget::event
Signed-off-by: Steve Pham <spham@amazon.com>
Removing PhysXSamples gem since its assets are outdated generating issues:
- Uses old material file format .mtl
- All FBXs info assets (.fbx.assetinfo) were generated before Assimp and the mesh unification work.
- All script canvas were created before new Physics API, which reflected events differently as AZ::Events.
- It heavily depends on slices (legacy system)
sig/core approved this removal at 15-OCT/2021 meeting: https://github.com/o3de/sig-core/blob/main/meetings/notes/SIG-Core-Notes%20-%202021-OCT-15.md
Signed-off-by: moraaar moraaar@amazon.com
The EntityOutlinerListModel was violating the QAbstractItemModel contract in a few cases, as reported by `QAbstractItemModelTester`. The important ones causing issues were:
- Entry order was not guaranteed, leading to model indices pointing at invalid data
- Parent/child relationships could be temporarily invalid due to a change I made in EditorEntityModel::RemoveEntity to try to avoid an unnecessary reparent operation - as it turned out, the parent/child data was being cached even for recreated entities and not clearing child data could cause issues
- `EntityOutlinerListModel::ProcessEntityUpdates` was emitting data changed between two indices that didn't necessarily share a parent, which is [undefined behavior](https://doc.qt.io/qt-5/qabstractitemmodel.html#dataChanged)
The other reported issues (that weren't really causing issues with `QTreeView`) were:
- The root index had flags other than `Qt::ItemIsDropEnabled`
- `rowCount` showed all columns as having children
- `parent` showed indices as being parented to a non-0 column
This change introduces fixes for the above issues, namely:
- Reverts my change to `EditorEntityModel::RemoveEntity` to ensure we don't have invalid parent/child references sitting in the cache
- Ensures `EditorEntityModelEntry` child ordering is guaranteed sorted by EntityId, to prevent the `EntityOutlinerListModel` from having indices pointed at invalid data*.
- Fixes various model sanity issues, such as `rowCount` being 0 for indices with a non-0 column
Two unit tests were added to reproduce the invalid behavior and validate the fix: TestCreateFlatHierarchyUndoAndRedoWorks and TestCreateNestedHierarchyUndoAndRedoWorks
This change focuses on correctness over performance. My subjective in-Editor outliner experience is about the same, but it may be worthwhile to expand the test coverage with a benchmarking suite to look into areas for optimization.
*As a rough illustration of the previous child ordering behavior, consider the following entity hierarchy:
```
Root (EID 9999)
|_ Child1 (EID 2)
|_ Child2 (EID 3)
|_ Child3 (EID 4)
```
With an representations like the following pseudocode:
```
// EditorEntityModel representation
EditorEntityModelEntry root;
root.children[0] = 2;
root.children[1] = 3;
root.children[2] = 4;
// EditorOutlinerListModel representation
// row, column, user data (64 bit uint)
child1 = QModelIndex(0, 0, 2)
child2 = QModelIndex(1, 0, 3)
child3 = QModelIndex(2, 0, 4)
```
When removing a child, the `EditorEntityModel` used to do roughly the following:
```
// Swap and pop the last child
int indexToRemove = 0;
swap(root.children[indexToRemove], root.children[root.children.size() - 1]);
root.children.resize(root.children.size() - 1);
model.notifyRemoved(root, indexToRemove); // model removes the row indicated
// Leading to this EditorEntityModel state
root.children[0] = 4;
root.children[1] = 3;
// And this EntityOutlinerListModel state, note that the row indices are swapped from the indices in the backing storage
child2 = QModelIndex(0, 0, 3)
child3 = QModelIndex(1, 0, 4)
```
A QModelIndex having a row that doesn't match its underlying data is undefined behavior, and was the source of an intermittent crash in our `QSortFilterProxyModel` as subsequent updates to the wrong row led to an invalid proxy state.
Signed-off-by: nvsickle <nvsickle@amazon.com>