* Update CHANGELOG
* Update version in documentation to 4.4.4
* Remove reference to Examples directory
* Update package-lock.json
* Update API documentation
When using an Event Reference Listener with a variable, GetOrCreateEvent() is sometimes called after TriggerInitialEvents(). This commit solves this issue.
* Fixed collection deserialization problem
ScriptableObjects arent granted to be initialized on a particular order and might be used by the collection before they are initialized.
* Update CHANGELOG.md
Co-authored-by: eduardo <eduardo@firasoft.com>
Co-authored-by: Casey Hofland <hofland.casey@gmail.com>
Some tutorials now have animation in them to give a clearer explanation of how things work. Added a short tutorial about creating Atoms with the new Search function. Documentation about installation has also changed.
* Speedup Atom Generation
This simple change will speed up atom generation via an AtomGenerator. The whole thing will only take 10 seconds instead of +1 minute.
* Update the changelog
* compatibility with dynamic assemblies
* fixing #232
fixed a case where the class namespace might be null
* fixing #232 + corrections, fixing #233
* Fix nested types not being generated correctly
VALUE_TYPE_NAME_NO_PAIR had an incorrect value if the type was nested.
* Reimagine the Generators Type Selector Layout
UNTESTED! I will test if the generator later this week (18/01).
UNCOMMENTED! Same as above.
The new selector will neatly separate namespaces from types, is ordered alphabetically and goes down a new level for every subnamespace. It will now also display nested types as such (so nested type Bar is displayed as Foo+Bar). This means that types of the same name but in different namespaces are now supported.
It will also ignore any abstract or generic types as Atoms can only generate solid types (...I think?)
If you want to check it out, I recommend looking at how NamespaceLevel works. It splits types up into types that have reached their namespace level and types that can still go deeper, in which case they are rooted as part of the NamespaceLevel. From there, it can handle adding dropdown items and finding a selected Type.
* Enable all GenerationOptions by default
Or on a Reset of the SO
* Ensure instantiated generator has unique assetpath
This can otherwise lead to weird behaviour if a new asset is created at the path of an existing asset
* Use variables for SerializedProperties
* Make objectfields to generated scripts readonly
These should not be edited which may lead to errors.
* Add comments
* Use hash to find which type belongs to which DropdownItem
* Use level to distinquish between namespace levels
Using TrimStart was also trimming off characters after dots (.) if appropriate.
* Safety measure
Ensure serializedObject.Update is called in the beginning of OnInspectorGUI.
* Fix size of Dropdown
It will now neatly cover all the generator options. This doesn't really matter at all, I just think it looks neat, plus it ensures there is always enough view to not have trouble selecting a type.
* Use CompilationPipeline to get assemblies
Pros: It only collects Unity Assemblies that are not Editor Only. This ensures that every type will 100% be compatible in builds.
Cons: It doesn't find any assemblies outside of Unity, for example the System assembly.
Personally I like this way better since it ensures support even for cross platform development. Imagine someone generating a type you can only find in Windows, then trying to build for Mac. We can still populate the base package with the base values from systems and people will still be able to create Atoms for unsupported values, just not using the generator.
Alternatively we could create an "unsafe" toggle.
* Use CompilationPipeline to get assemblies
Pros: It only collects Unity Assemblies that are not Editor Only. This ensures that every type will 100% be compatible in builds.
Cons: It doesn't find any assemblies outside of Unity, for example the System assembly.
Personally I like this way better since it ensures support even for cross platform development. Imagine someone generating a type you can only find in Windows, then trying to build for Mac. We can still populate the base package with the base values from systems and people will still be able to create Atoms for unsupported values, just not using the generator.
Alternatively we could create an "unsafe" toggle.
* Add Safe Search toggle to AtomGenerator
Previously, the AtomGenerator was only able to generate types that were Unity compatible and either Serializable or ScriptableObjects.
The first change is that it now also searches for Objects to account for prefabs.
The second change is a toggle next to the generator to differentiate between searching for Unity compatible types and searching for all types (denoted as "unsafe types"). This does what it promises: it gets all the (dynamic) assemblies it can find, retrieves all exported types, and makes no distinction between serializable or nonserializable. This returns the functionality to generate for example strings and ints with the generator.
* Add Quality of Life improvements to the Editor
Co-authored-by: Casey Hofland <hofland.casey@gmail.com>
