Feature Request: Nested Behavior Parameter Access

[ccattywampus]

First of all: FlexBe is amazing and I am forever in your debt. Now, on to business.

My Problem
So I have a configuration in which a top-level behavior has several sub-behaviors within it.
Several 'global variables' which are used by these sub-behaviors are determined by the top level behavior.

If these behaviors were instead states, then I would set the global variables in the private configuration of the top-level behavior and use them as parameters to its states.

However, this is a problem with behaviors containing behaviors. There is no way to pass them parameters that I've found outside of the runtime-control gui, while I plan on invoking behaviors as actions.

My Crackpot Theory
In looking at your code, I am wondering if it would be possible to add this feature by modifying the creation() function with an optional dict argument, which could become part of the state machine instance as in private configurations variables.

Then, as the top level state machine is created, you could potentially invoke this creation() with the top-level behavior's private configuration as the optional dict argument.

I assume there are problems with this theory.... But I thought I'd throw it out there anyway

TL;DR
I would love it if there were some way to have sub-behaviors receive or inherit parameters from their parent behavior at the state machine definition stage.

[pschillinger]

Thanks for your suggestion, I agree that a feature like this would be helpful.

However, I am still struggling with a good idea how to integrate it. A behavior has "parameters" and "private configuration". The same feature as described here of a state is called "parameters". Still, the parameters of a behavior already have a slightly different meaning.

What do you think of the following: An including behavior can explicitly set any of the behavior parameters of an included behavior. These parameters will then be hidden from the Runtime Control panel. All parameters which are not explicitly set will still be offered.

[ccattywampus]

I think this sounds good!

Would these parameters become fields that would be filled in the state machine editor?? That would effectively be exactly what I imagined!

[pschillinger]

Yes, I would like to add them to the property panel (the one that opens on the right side of the editor) of an included behavior in the same way as the "parameters" entry of a state. So far, included behaviors don't have this category yet. Great, then I will check in detail to estimate the effort of this addition.

[pschillinger]

The feature itself has been added to a new branch and works already: feature/sub_parameters

However, supporting it from the user interface side requires changes to code generation/parsing as well as at several GUI elements. I will try to find some time for this during the next days.

[pschillinger]

@Errogant the feature is now available, can you test if it addresses sufficiently what you had in mind?

To test it, please switch to the branch "feature/sub_parameters" in both the "flexbe_behavior_engine" and the "flexbe_app" repos.

[ccattywampus]

@pschillinger Thank you for being so quick to implement!

I've pulled, cleaned and built the branches, but I don't see any changes reflected in the GUI. I see that the HTML and js files have been modified, so I am not sure if this is just something strange with my build? Thank you for your quick response and helpfulness

[pschillinger]

Building or cleaning should not make any difference here, nothing of the changes depends on a re-build.

If you are on the correct branches, a change you should see is that the version number (top-right corner of the App) says "2.2.0". The way the feature is implemented is that an included behavior in the Statemachine Editor will now have a "Parameters" section similar to states. But this is only the case if this included behavior specifies parameters, i.e., you added something to the bottom-left box in the Behavior Dashboard of the included behavior.

[ccattywampus]

Ah, yes I understand now how it works. This is fantastic, great job!

[ccattywampus]

So, this is only a semi-related issue in terms of the feature, but one that is important to my use case.
I need to have a list of strings, but this is not an available type for behavior parameters. I can go in and change it for the top level instance, but it gets returned to a wrong format upon being inherited.

Would it be possible to implement a 'list' type? Or string_list, numeric_list, etc...?

[pschillinger]

It should be possible to implement a list type, but not sure if this would be the way to go.

In general, the parameters of a behavior should be simple (in the sense that an operator can enter them quickly for each start of a behavior with low mental load). This is why I would rather prefer to stick to simple data types.

A workaround might be to have a (space or comma)-separated list as string paramter and then ".split()" the string when using it. This makes it also easy to enter. I see that this might not be ideal and of course, we can discuss whether a list type should be added despite the reason above.

[ccattywampus]

I agree that the behavior parameters make the most sense as smaller values that can be set at runtime.

Ideally, I would say that the data I want to pass would actually be in the 'private configuration', which could then be passed to the private configuration of the sub-behaviors. However, I'm not sure if this is possible.

I still believe that the ability to inherit high-level behavior parameters (as opposed to high-level behavior private configuration variables), but it seems like a different use case from the one I have

[dcconner]

Any further discussion on this topic?