Updated to latest EcsRx 3.11 stream + Some Separation

The new EcsRx version has done away with IEntityCollectionManager and now has an IEntityDatabase and IObservableGroupManager which do each bit that the collection manager used to do.

This update also allows you to use the persistence plugin if you want to use that.

Finally there is a bit of a change in terms of how the editor and application based classes are structured, this allows them to be more pluggable, and hopefully more work will be done on this going forward.

Fix for ResolveAll

A fix was put into the last version which made named bindings work correctly, but this had a knock on effect where ResolveAll doesnt actually resolve all, only things without names/ids. So have added a workaround for this issue.

Oh my golly gosh an update?!

This isnt a huge update, but it fixes some minor issues with the Extenject bindings in cases where you were using names (and we have switched to Extenject now).

There is also a unity specific IUpdateScheduler implementation bound now so that makes cross platform plugins and IBasicSystem implementations use native unity/unirx scheduling/time objects under the hood.

Other than that not much else to report.

Who needs to ever leave Release Candidate Status?

We are skipping over release 1.0 and moving to 2.0 as an RC!

Think of this a bit like ARK where they release some DLC while still in early access, just in this case we are not charging you for the privilege :D.

So this release was hopefully going to be more, but there is a lot going on so it seemed better to get a smaller (but still useful) release out in the wild and then look at trying to separate the Editor into its own library as there is quite a few quirks with it and I dont want it holding up the main EcsRx releases.

SO WHATS NEW?

Well from the unity side of things not much, its just a bump of the underlying EcsRx framework version, but that contains a LOAD of new stuff, which you can read about here:

https://github.com/EcsRx/ecsrx/releases/tag/3.0.x

Some highlights are:

• Supports struct based components
• Some internal stuff moving to plugins
• Added batched systems for more performance oriented use cases (can be used with structs or class components)
• Moved to use C# 7.3 SO UH OH we need Unity 2018.3 now
• Performance gains in most areas, especially with batching and structs

Will hopefully get around to adding some more examples soon as well as updating docs, if anyone feels brave and/or helpful drop into the Discord channel and offer your services and we would love to let you help out with alpha builds and doc/example additions!

Adopting EcsRx 2.* Application Lifecycle

This is not a huge release but brings the lifecycle of the unity application in line with the core application (as due to the Monobehaviour requirement we cannot easily inherit from EcsRxApplication).

See the lifecycle information here:
https://github.com/EcsRx/ecsrx/blob/master/docs/application-infrastructure.md

Extension updates and lifecycle changes

This release is mainly life cycle improvements and adding more extension methods to assist in common scenarios.

• EcsRxApplicationBehaviours now inject on themselves after modules have been loaded
• Extension methods for Zenject DiContainer to allow getting observable groups (incase you use that directly)
• Updated auto registration to correctly factor in priorities

The rest of the updates are updating documentation.

This will hopefully be the last release before it becomes the next official release.

Beta Release 2

This release has some breaking changes around the way the application is created and managed, as well as the way that view systems operate.

View system changes

There is now a DynamicViewResolverSystem which allows you to create the view in the system, rather than using prefab that cannot be changed, this latter scenario is the better one in most cases as you can pool it easier.

Zenject separation

To assist users who do not wish to use Zenject and have their own DI approach we have begun moving out the Zenject specific logic into its own folder which is currently bundled with but can easily be removed.

This being said there are still some dependencies on Zenject such as the [Inject] attribute which we are hoping to abstract away a bit further in future releases. Another change is that the IInstantiator from Zenject has been abstracted away with a more generic IUnityInstantiator which has no hard dependency on Zenject, so if you just need to instantiate a prefab then use this, if you need more Zenject specific functionality stick to the IInstantiator.

As part of this you will now get the EcsRxApplicationBehaviour from the Zenject part as this specifically depends upon the scene context, this may be abstracted out further going forward but for now its not.

Bug fixes

There was an issue with how Zenject events were being handled, so we have now correctly used the post install event rather than pre-install event, so this should stop issues where installers were being run AFTER the app was setup.

Beta Release

This version should be stable, no big changes just a fix that makes stuff work :)

Update to EcsRx 0.3.0 and some fixes

This is mainly an update to fix the outstanding issues with pooling and entity removal.

There is still an ongoing issue with Zenject injection timings which will be looked at next.

Alpha release 2

New Release

This one builds off the progress made on the other one, we now have MAJOR performance benefits to almost all aspects of the system. There are some breaking changes which are detailed primarily in the EcsRx release notes.

There are a few breaking changes specific to the unity library, mainly around UnityViewResolvers now called PrefabViewResolvers and same name changes with pooled view resolvers.

Other noteworthy changes

There have been some helpers added so you no longer need to create the auto binding installer references in the scene context, you can instead just use extension methods for applications such as BindAllSystemsWithinApplicationScope, these can be seen in almost the examples.

This uses conventional based loading and will look within the same namespace as the application for classes in Systems or ViewResolvers namespaces. If you want to make your own conventions for your own applications then just wrap up BindAnySystemsInNamespace.

ZENJECT UPDATE

We are using the latest zenject 7 now, so you will need to update to that, not updated to latest unirx yet as there are some teething issues with some unity components.

Known Issues

There are still a couple of issues related to Zenject use cases and there is a known issue with pooling which is being worked on.

Next Release?

Hopefully the next release will fix the outstanding issues, update unirx and also look to move over to the newer editor scripts from the old branch for v2 (before the .net move over) no timeline on this yet.