weighted random selector/sequence

[lostptr]

Description

To better encapsulate the random manipulation logic for composites, I created a RandomizedComposite node that should never be used as is; it is only so that logic can be shared for SelectorRandom and SequenceRandom (or else, I would have to copy and paste a hundred lines on both scripts)

This new class contains the seed settings, option to specify weights for each child and the shuffle logic.

⚠️ Thorough testing needed
The editor for weights works fine but I noticed it is sometimes finicky. I had to reopen the scene for it to work again. Maybe this happened because I was constantly changing the code but I would like to be sure that it is all working properly.

Addressed issues

• Closes Weighted random selectors/sequences #194

Screenshots

Weights editor:

Proof of concept

I made a little test to make sure that the weights are actually affecting the random sampling by recording all of the times a node was picked as the first child.
After 36698 times:

• Action "First" with weight 40 was picked 39.69% of the times
• Action "Second" with weight 30 was picked 30.03% of the times
• Action "Third" with weight 15 was picked 15.12% of the times
• Action "Forth" with weight 15 was picked 15.16% of the times
  

[bitbrain]

Looking great - don't forget to also add some tests for this.

[bitbrain]

@lostptr a couple of findings:

• renaming a child node affected by a weight resets the weight
• If I set the weight of Node A to 50 but the weight of node B to 10, currently node B gets invoked more often which is rather confusing - is this intentional? As your description suggestes that a higher weight equals more likelihood to be executed. e.g. if I set weight of Node A to 30 and of node B to 70, A is called way more often which seems to be wrong

weight-issue.zip

[lostptr]

renaming a child node affected by a weight resets the weight

Yeah I noticed that too but I had no ideia how to deal with that and thought it wasn't such I big deal. However, I can see how that can be annoying and cause a bunch of silly bugs because people would not notice. I found a way to fix that, albeit not very elegant 😆.

If I set the weight of Node A to 50 but the weight of node B to 10, currently node B gets invoked more often which is rather confusing - is this intentional? As your description suggestes that a higher weight equals more likelihood to be executed. e.g. if I set weight of Node A to 30 and of node B to 70, A is called way more often which seems to be wrong

Oops!
I made a little change in the SequenceRandomComposite and forgot to do the same with the SelectorRandomComposite. The weights were having the exact opposite effect, it should work now.

[bitbrain]

renaming a child node affected by a weight resets the weight

Yeah I noticed that too but I had no ideia how to deal with that and thought it wasn't such I big deal. However, I can see how that can be annoying and cause a bunch of silly bugs because people would not notice. I found a way to fix that, albeit not very elegant 😆.

If I set the weight of Node A to 50 but the weight of node B to 10, currently node B gets invoked more often which is rather confusing - is this intentional? As your description suggestes that a higher weight equals more likelihood to be executed. e.g. if I set weight of Node A to 30 and of node B to 70, A is called way more often which seems to be wrong

Oops! I made a little change in the SequenceRandomComposite and forgot to do the same with the SelectorRandomComposite. The weights were having the exact opposite effect, it should work now.

@lostptr Why didn't the test fail? Or was the test broken too?

[lostptr]

Why didn't the test fail? Or was the test broken too?

There where no tests for the selector thats why. I have added them in the latest commit.