Behavior: Request to publicize ConditionUtils.CheckConditions

Unity Engine
, , ,
1

Hey Behavior team,

I’ve got a fairly simple request, I think. ConditionUtils has a nice function that all of the conditional based comparisons are using to determine each tick if the conditions have been satisfied or not. Unfortunately, this function is currently set to internal so only classes built with the Unity.Behavior assembly can use it. From what users can see when inspecting the decompiled code, it’s not doing anything complex that requires the use of the internal keyword. Marking it as internal means that anyone who wants to utilize conditional checks in their own custom nodes will have to have a copy of that code in their own assembly rather than using the same code the rest of the behavior system uses.

I ran into this when implementing a Wait (Conditional) node (which may be a good request in itself for a generic node to be added) for a certain behavior I was working on. I can workaround for now and just copy the code its using, but it would be better to directly use what the other conditional based nodes are using in case things change with future upgrades to the package. Thanks!

Edit: Spoke a little too soon, I’m guessing something is using IConditional to control the drawing of the actual special condition sections of the in-built nodes as simply serializing a List of Conditions and the boolean for RequiresAllConditions does not show the assign condition section in the inspector. IConditional may also need to be public rather than internal in that case

2

I completely agree with you. I think we tried to do something quite similar.
I tried to create a more generic action inspired by ConditionalGuardAction to wait until the condition was met. However, when I saw the number of members marked as internal, I gave up. I’d have to replicate the entire verification logic.
I ended up deciding to make a more specific action just to meet that purpose.

3

Hi @zkrizo

Thank you for raising this, we are currently working toward our feature planning for the upcoming year and your point has been raised and put on the board during the meeting (especially the point about exposing Utility function we use for built-in node).

Several users has been asking for the same in regard to IConditional so we will probably look into it sooner or later.

Sorry for the inconvenience and thank you for your patience :bowing_man:

4

I know nothing will change here but this is something that happens way too much with unity packages. There isn’t really a good reason to mark so many things internal all the time.

But there is a workaround, you can create a assembly reference to the assembly you want to have code in and it will then be considered internal.

I also just created a @jhmaverick ConditionalWaitAction, and using the assembly reference method i seemed to be able to do it, by duplicating about 4 files and renaming. I kept looking for a simpler way or to be able to override but ended up having to duplicate a lot of stuff at least it was mostly just rename after that.

But once you do that you could make a more friendly version possibly to use outside of that internal package.

image
image949×211 22 KB

5

Hi @daxiongmao

Thanks for bumping this issue. We tends to put any API internal by default until it reaches enough maturity or until we think it will brought values to users while being relevant to maintain.

I know we had plan to expose ConditionUtils along with IConditional, but a lot happened and this has been de-prioritized.

Saying that, I would be interested to know what are those files that you had to duplicate. When we got time that would be a starting point for us to investigate.

6

I have run into the internal issues several times trying to expand or extend functionality in other packages.
I can see why it could be a design thing as you mention, but with unity’s track record of dropping support for packages a lot of time trying to extend things later just makes it more difficult. But not to get stuck on that issue.

This is the function that seems pretty safe to expose in ConditionUtils
internal static bool CheckConditions(List<Condition> conditions, bool allRequired)
Granted its pretty easy to duplicate as well and does not use any internal things i think. But I couldn’t achieve what i wanted external to the package as I detail below so didn’t end up needing it external.

My goal in the other case of trying to make a conditional wait action was a bit more involved.
Usually when its that much trouble i have to ask myself am i trying to do something that it wasn’t designed to do.

After floundering around trying to make my own action with conditions and failing.
Mostly because the way the inspectors seem to be done for the conditionals list are not like others in the behavior package? or at least like unity where it would show the right inspector based on say List<Condition>.

After more digging i came across the ConditionalGuardAction. Which is like 99% of what i wanted.
I wanted an Action to check at Start for the conditions, but instead of failing, it should continue to check in OnUpdate. But again trying to implement my own version of this hit an internal roadblock.

ConditionalGuardAction is marked internal, the IConditional interface is internal. So trying to implement my own action like it did wasn’t allowed in the main project. So I did the assembly hack to insert my code into the project.

This still did not work even though the action was created and visible in the graph. I tried creating my own, inheriting and overriding ConditionalGuardAction and nothing seemed to get the inspector to show the conditional list.
After searching more for the usage of ConditionalGuardAction I came across the other files needed.

I have attached the files and they are basically search and replace copies from the ConditionalGuardAction.

I was just a little surprised it was so difficult after all the other awesome work that was done with this package and its UI.
Maybe i missed a simpler way to get the conditional list exposed in the inspector.

Thanks,

ConditionalWaitAction.cs (1.6 KB)
ConditionalWaitNodeModel.cs (1.6 KB)
ConditionalWaitNodeInspectorUI.cs (1.4 KB)
ConditionalWaitNodeUI.cs (1.3 KB)

7

Thank you for sharing these details.

The authoring UI part of the graph is quite complex in general. The conditional system involves multiple interconnected components (Node Model, Node UI, Node Inspector, and more) that all need to work together properly. This complexity is one of the main reasons we’ve kept these APIs internal for now.

I’ve checked and we don’t have a public ticket for exposing the IConditional and providing built-in support of List. If this missing feature is blocking you (or hinders your ability to efficiently use the tool), I strongly encourage you to open one through our feedback channels. User-submitted tickets, especially those that receive multiple upvotes, help us prioritize what to tackle next.

Thanks again for your patience :folded_hands:

8

Thanks,
I can see that as i was going through the code.
I will see about adding a ticket.

Right now I am able to workaround the issue with using the assembly method and duplicating the files.