Specific Components and Properties having built-in Numbers (other maths too)? Constructive criticism

Feature Requests
1

In other words, I think specific Components and Properties should have built in numbers (*that you can customize accordingly) (which I’ll list eventually). The reason I ask for this is because it’s already confusing where the “number” logic should go with certain input/outputs. Allow me demonstrate an example of what I am talking about:

Always - (in) Number (5) - (x) Impulse

Now of course, this is correct and it works. So why did I just demonstrate that? Look at it this way; are people really going to know where to put the number at when first starting out? When I first started flowlab, this is what I tried:

Always - (x) Impulse - (in) Number 5

(strangely enough, both methods sent the object flying in different directions :/)

And both worked! But…why? And when I ask why, I also mean; will either set-up AFFECT any following behaviors that I need to add? And it probably does. And if it does?

That is why I think having to add numbers as an input/output is unnecessary. Not just the fact that it probably affects follow-up behaviors, but for many other reasons as well. Which are:

  1. Many other problems could be solved beforehand if the number was put in the right place, which would therefore lead to a minimized amount of forum posts for help. This leads to point 2:
  2. Once the beta of flowlab is over, the administrators will probably have bigger things that need to be taken care of. But hey, if you guys want to help everyone, I totally respect that too.
  3. Minimized behavior creation time
  4. It would be easier for beginners to know what they’re doing (in my opinion).

All in all, when I first started out, I was wondering why some behaviors NEEDED a number. I mean, if the number wasn’t in the behavior’s properties, I assumed that a number was built-in (and a “pre-built” behavior itself, if that makes any sense). And because of that assumption, I didn’t know if adding a number was going to affect the behavior with it’s built-in number, if it had one. And, if I am affecting the built-in number, is there something I’m doing wrong? More importantly; I’m one person (who’s over analytical). As one person, I would assume that most beginners would have assumed what I just assumed.

If a built-in number isn’t added, I would suggest making a note in the documentation, such as:
Needs number (Does not have built-in number)
Something along those lines, just to clear things up for people.

But here are the components and properties that I think need a built in number:

Components:
Motor
Impulse
Emit (maybe)
(As a side note; scroll view was dead on with built numbers. It made things “feel” simpler)

Properties:
Position (Real quick, think about it:
Always - (x) Position; with the number built in and selected. Would that not make things so much simpler? I think it would)
Rotation
Alpha
Percent
Velocity

Well. There you have it.
Input?
Honestly, if you guys liked this post, I can post more pertaining to little things about flowlab that confuse me and could possibly confuse others.

2

Hey Muphins, thanks a lot for the thoughtful feedback. I really appreciate hearing about what people find confusing.

I do agree that especially for the always (and once) triggers, adding the ability to select their output value would make the logic simpler in many cases. I have refrained from doing that mostly because I felt that this would seem more complicated and less consistent.

If I added the ability to adjust the output of all trigger behaviors, that would probably make them simpler to use while keeping their behavior consistent. There would also need to be a way to easily see what number each trigger is set to as well.

Anyway I will give this some serious thought, so thanks again for the input. Anyone else who reads this feel free to chime in as well.

3

-I do agree that especially for the always (and once) triggers, adding the ability to select -their output value would make the logic simpler in many cases. I have refrained from -doing that mostly because I felt that this would seem more complicated and less -consistent.

Just for the sake of trying to understand this, I think by “adding the ability to select their output value” means within the Always/Once trigger, correct? (or for the following behaviors?) Regardless, I still have a suggestion for that.

To make it less confusing, you could make selecting the once’s/always’s value optional. For example, click on the trigger and you will see this:

? Use custom value?
Select value: _______

That square is a checkbox btw. I don’t think that’s complicated. If you want advanced options, click on the behavior itself like the rest of the behaviors, no?

Although I don’t suggest that method, I would suggest the opposite. Which is implementing the custom value within the components/properties, not the trigger itself.

-If I added the ability to adjust the output of all trigger behaviors, that would probably -make them simpler to use while keeping their behavior consistent. There would also -need to be a way to easily see what number each trigger is set to as well.

Simple solution; add the text, or label, so it shows up at the top right of the behavior/trigger, if that makes any sense. You know how you can add a label to a number logic? Replicate that :slight_smile: