* provide the ability for component adapters to support multiple components per entity
* add missing explicit keywords
* updates following review feedback - update how template logic works
* small updats (fix typo, remove redundant includes)
* add missing this->
* naming change, common -> controller
* add [[maybe_unused]]
The priority threshold to consider a task high priority can now be configured through the Settings Registry under key "/O3DE/AzFramework/Spawnables/HighPriorityThreshold".
This introduces an EditorViewportIconDisplayInterface that will eventually be used to outright remove CIconManager, it provides a simple interface for loading 2D image assets and rendering them on-screen. It also introduces AtomBridge::PerViewportDynamicDraw for getting a dynamic draw instance on a per-viewport basis
This commit fixes a crash that could happen when a spawnable ticket was deleted before all requests in the queue had completed. Because of this crash the requests now only hold on to the payload of the ticket but not the ticket itself. As a side effect, callbacks can no longer provide the ticket itself so instead a unique id for the ticket is returned.
It's now possible to have high and normal priority calls on the spawnable entities manager. This allows for events like (de)spawning and retrieving information to be executed before already queued requests, though requests cannot be reordered on the same ticket. High priority calls are executed twice per frame, while normal priority calls are called only once.
Spawnables had support for moving, but as the base class AZ::Data::AssetData doesn't support moving this was causing subtle issues. Moving spawnables wasn't used so it was removed.
There are already APIs for getting a relative product path from an absolute source path, or getting a relative source path for an *existing* source file, but there were no APIs for getting a relative source path for a *new* source file. Prefabs will need this ability to be able to correctly generate a relative source path inside the prefab file before the file has been saved.
The logic for relative source paths is a little bit tricky because the paths are relative to the watch folders, and the watch folders can be nested, with different priorities to explain which should take precedence. The input paths can also include specifiers like "." and "..", which need to be reconciled before creating the final correct relative path. The included unit tests test all of the tricky edge cases that I was able to identify.
* Fixed generation of Monolithic builds StaticModules.inl
A project's gem module RUNTIME_DEPENDENCIES were not visited to
determine any dependent gem modules that needed to load.
Therefore the CreateStaticModules function were missing
CreateModuleClass_* function calls required initialize the gem's AZ::Module
derived class in monolithic builds
* Removed the logic to strip the Gem:: and Project:: prefix from the Server Launcher gem dependencies
When associating gem dependencies with the server target there was CMake logic left over in it to strip the beginning of the target name if it began with "Gem::" or "Project::"
jonawals
igarri
John Jones-Steele
greerdv
Tom Hulton-Harrop
michabr
Alex Peterson
srikappa
Terry Michaels
chiyteng
sconel
AMZN-koppersr
Nicholas Van Sickle
cgalvan
Mike Balfour
srikappa-amzn
Chris Galvan
Ken Pruiksma
lumberyard-employee-dm
greerdv
SJ
Hasareej
pappeste
Benjamin Jillich