Add Where condition to Listeners, eg. call handlers every Nth time about unity-atoms HOT 15 CLOSED

[something] ----raises ----> [Atoms Event] ---- notifies ----> [listener]

the listener itself is a developer-class not a library-class. a really small subset of listeners will use this logic. for the cases where they are needed a developer could just add 3 lines of code:

[SerializeField][HideInInspector] private int counter;
[SerializeField] repeatAmount;

.... some code, and first line of the listener method:

    if( ( (++counter) % repeatAmount ) != 0 ) return;

I - personally - don't see the need to include it. But I might be wrong, and the demand for this functionality is higher than i thought

from unity-atoms.

What do you mean it's developer-class not library-class?

@soraphis Where do you add those 3 lines of code? I wanted to use an Int Listener/Float Listener etc with that functionality, so I can't modify their code, because it's compiled into a package.

EDIT: Yeah, I just want to add those 3 lines of code, but in a package (and make a non-generic Listener class, I'm just working on that and will push here changes in my fork).

from unity-atoms.

I think that instead of adding this specific logic to the Listener it would be better to add a BoolFunction to the Listener that you can apply your own logic to, eg.responseCondition. Wouldn't mind a PR for this.

from unity-atoms.

Disregard my previous comment.

What I think we should do
Instead of doing a specific solution (call handlers only every nth time) we should do a general solution. I'm thinking that we should add a "Where" condition to Listeners. It would be a AtomFunction<bool>, AtomFunction<bool, T1> or AtomFunction<bool, T1, T2> depending on if the condition should care about the data being sent in or not. The AtomFunction will basically just implement its own logic for if the Event should be let through and the handlers / responses should be called.

We could also add some basic conditions, for example:

• Every nth time (AtomFunction<bool>)
• If a Variable (must not be "related" to the Listener) has a value (AtomFunction<bool>)

Just using the built in property drawers for this solution would probably make it pretty messy. I would suggest making a customer property drawer where one could add "Where" conditions via a "plus button" and then choose what type of "Where Function": AtomFunction<bool>, AtomFunction<bool, T1> or AtomFunction<bool, T1, T2>.

I would be really appreciate someone making a PR on this. Make sure to read the guidelines before starting + assign yourself (or ask me) to the issue.

from unity-atoms.

I want to start working on it as the next feature, but I need help. I got a problem with variable type in Where condition. We all agree that it has to be AtomFunction which returns bool. But I don't know how to make that Where condition flexible to support a few types of AtomFunction.
For example:

• Atom Listener Component (parameterless) could support only AtomFunction<R> (where R is bool)
• Int Listener Component could support AtomFunction<R> and AtomFuntion<R, T1> (where R is bool, but T1 could be passed int value by Listener)
• Int x 2 Listener Component could support AtomFunction<R> and AtomFunction<R, T1, T2> (where R is bool, but T1 and T2 are passed int values by Listener).

Do you have any idea how it should be done? Am I thinking right?

EDIT: Do you think we need more specific non-generic class for AtomFunctions? Like Variables got with those "abstract object" etc.

from unity-atoms.

this feature is a monstrosity. btw. it has very few actual use cases and is itself a turing complete language.
(all where clauses are and-connected, you can put in AtomFunctions that represent or's -> reminds me on 3-SAT, which is turing complete) (i think i was drunk there, that does not make any sense, about turing completenes ... just ignore it)

to do this feature in a useable way I'd say its a week or two work. if not even more.
a proper solution would resemble a kind of visual scripting. (not node based, but kind of)

as it is now, the spec's are way to vague. I'd like to see a valid use case and since this could be a turing complete graphical scripting language, the scope of this should be addressed more precisely

from unity-atoms.

My use case would be: I want to add a new gameobject to my existing gameobject (as a child) as a response of an event. This response may only trigger if my global gamestate is in a certain state, my parent gameobject is 'selected' and the collider of my gameobject that I want to place doesn't collide with other gameobjects. My response may only trigger when all these conditions are true.

from unity-atoms.

I want to add a new gameobject to my existing gameobject (as a child) as a response of an event.

so you've already got a script that instantiates this gameobject. why not add references to your state machine and all those checks in there?

my parent gameobject is 'selected'

this is a piece of logic, which only makes sense in your head. has it a "selected" tag? is it an AtomTag? has it a selected component? or is there an AtomsVariable named "selected" which points to the gameObject.

collider of my gameobject that I want to place doesn't collide with other gameobjects.

this is such a specific case, maybe later you'd want to use only specific physics layers.... does such a check really has to be in unity atoms?

In your use case: how would the AtomsEvent be extended to solve those conditions?

if all conditions should be wrapped in an AtomsFunction this means, you've got to write those AtomFunctions and their logic yourself.

So your instantiation script could simply use a List of AtomsFunctions which all return bool and check if all of them return true.

ALSO you later may find, that your event should be handled every time not just when a condition applies, because in an error case (where no instantiation will happen) you probably want to tell the player this (e.g. by playing an error sound, showing an error message, "not enough minerals", "building obstructed")

from unity-atoms.

My example was maybe a bit too specific. My application uses a lot of events and it is not only for instantiating gameobjects. I would also use it for enabling UI, disable gameobjects, starting an animation etc. I was thinking about an extension where I have a list to which I can add a condition. Each condition exposes parameters to the inspector which will be compared before the response trigger. This image shows what I was thinking about.

I had these conditions in separate scripts before and that became difficult to manage when multiple layers of conditions are needed.

from unity-atoms.

On my fork I have a branch with such implementation:



Sample IntCondition script:

Seems to work:

What's missing:

• Can't serialize the IntCondition script exposed variables like "public RigidBody2D something;" to be edited in the condition list itself as in the mock-up picture in the previous comment. This is really annoying as it's really hard to refer to the GameObject's Components for example.
• No generator support
• No documentation or tutorial for the feature

Improvement:
Basically an "AtomCondition" is simply an AtomFunction with a method of a specific signature (bool Evaluate(T value)) so if it's at all possible I would remove the AtomCondition implementation and replace it with a solution that uses AtomFunctions instead. Maybe the AtomFunction simply has to implement an interface that forces the method to exist.

Code available here:
miikalo@f9a1bd4

from unity-atoms.

Summary of the discussion on from the Discord.

Adam
A cool addition to @petokeksi solution would be to make AtomFunctions / AtomCondition References, which would work exactly like the corresponding Variable and Event References. Function / Condition References could reference an Atom Function or a Monobehaviour that implements an abstract class, eg. AtomMBFunction<T1...,Tn, R>

Another possibility is to use Unity Bolt to let the user design its own conditions.

Thimo
This is as I see it. There is a certain signature needed (bool return, certain amount of input variables). The func is difficult to visualize in the inspector so each condition must be manually written I believe. To make this proccess easier we can implement a "create condition" button and let the user make a condition visually with Unity Bolt's visual scripting.

Soraphis:
Bolt integration should imho be entirely optional for Atoms. Encapsulated in its own package.

but on the other hand, this would probably require an clever solution for custom inspectors. a modular component based approach could be necessary, since the bolt package would try to override the core packages custom inspector...
separating those is quite a challange on its own, without the actual feature itself

I think the only actual way is:
create an own subclass of AtomFunction naming ... dunno .. AtomBoltCondition

this would give all the options for custom inspectors, but on the other hand:

where could you use such a Function?

__

trying again:

depending on the Atoms.BaseAtoms package:

• add a BoolFunction to the BaseAtoms package (not just BoolBollFunction)
• make AtomBoltCondition derive from BoolFunction
• also create AtomBoltBoolCondition where you've got a bool as argument
  • do so for all variables
  • hack into the atoms generation to allow generation of AtomBoltXCondition classes to be generated ....

from unity-atoms.

@miikalo

The Interface being called IEvaluatable is quite strange, with return type bool. Since a function could be evaluated, too.

to go with .NET terms, it probably should be a predicate

public inteface IEvaluatable<R, T> { ...

public interface IPredicate<T> : IEvaluatable<R, T> { ....

from unity-atoms.

@miikalo

The Interface being called IEvaluatable is quite strange, with return type bool. Since a function could be evaluated, too.

to go with .NET terms, it probably should be a predicate

public inteface IEvaluatable<R, T> { ...

public interface IPredicate<T> : IEvaluatable<R, T> { ....

You're right, Predicate makes way more sense. "Evaluatable" was the first thing to pop in mind from "evaluating a condition".

from unity-atoms.

It is possible to serialize the Condition objects in the listener inspector, using code @ThimoDEV found online, I get these results:

As you can see, the instances are arranged below some other items in the listener inspector. This is the code that was used as-is: https://forum.unity.com/threads/editor-tool-better-scriptableobject-inspector-editing.484393/

Maybe someone with more knowledge can fix it? I lack understanding of Unity Editor programming. I can include the code in the PR for reference if necessary.

from unity-atoms.

Closing this as there was already a PR that implements this partially, maybe this can be looked at again when there is feedback on the conditions implentation.

from unity-atoms.