Enabling EVENTS on other platforms

[AnnulusGames]

I installed Arch using Nuget for Unity, but I cannot use the event functionality because it is via a dll. Those codes are wrapped in #if EVENTS, but since the dll is already compiled it will be impossible to add them.

While it is understandable that these features are optional for performance reasons, the above reasons make them difficult to use on platforms such as Unity. Is there any solution to this problem other than creating my own fork?

[AnnulusGames]

It is also possible to add the source code directly to the project, but it makes package versioning difficult. Shouldn't these features be true by default? Alternatively, if there is a distribution method that supports the Unity Package Manager, we can support #define, but are there any plans to support UPM?

[AnnulusGames]

I attempted to port Arch for the Unity Package Manager, but found it difficult: the main body of Arch is written in code that requires C#10 or higher, but must be downgraded to C#9 if it is to be Unity compatible. This makes simple porting nearly impossible, as the default constructor for struct is no longer available. (The latest Unity has a higher version of Roslyn, so C#10 or later can be used with the compiler options. However, this is not the official recommendation and some features are not available due to runtime limitations).

[genaray]

Hey there! :)

Have you looked at : https://github.com/genaray/Arch/wiki/Integration-Guides#unity

Theres an Project that uses Arch via dll. Theres also a Buildscript in /Scripts to build the different Variants as dlls. Somewhere was a pr Back then or a discussion which explained Its usage.

Besides that Arch is "Performance First". Thus the Flags stay deactivated by Default. A own fork could Help Here, or building the fitting dlls manually or via the Script :)

[AnnulusGames]

Thank you for your reply!
Of course, I understand that Arch prioritizes performance. Performance is very important!

However, Arch depends on several packages such as System.CompilerServices.Unsafe and Arch.LowLevel. Of course, it is possible to download the dlls from all of these and add them to the Plugins folder, but it is very cumbersome. I also don't think Arch should encourage forking to use this. Events are almost a must-have feature.

When using these packages in Unity, your best bet is to use Nuget For Unity to resolve dependencies. (In fact, prominent libraries such as R3 and ZLogger have adopted this method of distributing Unity, and MessagePack-CSharp is also moving to this method.)
Is it possible to use another method instead of preprocessor?

[genaray]

Thank you for your reply! Of course, I understand that Arch prioritizes performance. Performance is very important!

However, Arch depends on several packages such as System.CompilerServices.Unsafe and Arch.LowLevel. Of course, it is possible to download the dlls from all of these and add them to the Plugins folder, but it is very cumbersome. I also don't think Arch should encourage forking to use this. Events are almost a must-have feature.

When using these packages in Unity, your best bet is to use Nuget For Unity to resolve dependencies. (In fact, prominent libraries such as R3 and ZLogger have adopted this method of distributing Unity, and MessagePack-CSharp is also moving to this method.) Is it possible to use another method instead of preprocessor?

How would Arch have to be prepared for UnityNugget? Is there anything to consider?

[AnnulusGames]

NugetForUnity is a Nuget client for the Unity editor and works by placing the dll under Assets/Packages. Therefore, there is no need to do anything on the Arch side, but the preprocessor is not available due to its specification.

My suggestion would be to enable the event feature by default, but I agree that there are performance concerns. But honestly it seems to me that there is no other solution as far as going through the dll.

[skelitheprogrammer]

I would like to put my 2 cents into this conversation (please correct me where I'm completely wrong) :)

What the point of EVENTS logic inside of World class? Implementation of callbacks?
From Wiki:

Events are awesome, you can easily and efficiently hack into the API and execute logic when an entity is created, destroyed or modified. Arch supports this, but since not everyone wants this (because it affects efficiency somewhat), it is hidden behind a preprocessor flag. You can enable events with the "#define EVENTS" flag and an Arch fork.

For me it seems that this area should be redesigned.

What problems does `World' solve?
From Readme:

The world acts as a management class for all its entities, it contains methods to create, destroy and query them and handles all the internal mechanics.

Should the world really have that many concerns? Maybe World should only act as a container/hub/collection of entities, and we should delegate the rest of our concerns to other systems?

For example, Command Buffer (and the Command pattern in general) can have full control over entity management (as Bevy does, for example), and World can gain these capabilities through `extension methods'.

So what about EVENTS, should they be inside the world directly? Maybe it should be a separate package that extends the world and allows the user to create their own, pretty callbacks?
Personally, I would like to get such EVENTS, which allowed me to execute systems based on EVENT execution (because who told that systems should always run continuously?).

For me its sounds like that Arch should become framework and ECS part should be Arch.ECS module XD
I understand, that is a gigantic work, but what if? :D

[genaray]

#201 Could come in handy here.
I don't think that events can be added by simple extension methods. You would have to hack into Arch itself to generate events from the method calls ^^

[skelitheprogrammer]

#201 Could come in handy here. I don't think that events can be added by simple extension methods. You would have to hack into Arch itself to generate events from the method calls ^^

Yea, by events I meant something like in this direction.