Why requirements for Quotes in BehaviorTree so inconsistent? Screenshot included

[BracerParticipant]

Incase Image Cropped, this is the image:
http://s16.postimg.org/f6pk4mks4/image.jpg

I imagined people using the frame work consistently torn between whether there are actual coding issues on their own or maybe if they were to just add quotes here, it might work.

This inconsistency is then further compounded if lots of variables are used, then there will be so many combinations, say you have to fill in just four textboxes in the behavior three, there will be 16 possibilities, example, 1 with quotes, three without quotes, 2 with quotes, 2 without quotes…all these combinations just to get the behavior tree to work because of quote usage inconsistencies, and all these assuming the programmer’s code that interacts with Rain AI have no error.

Is there a hard and fast rule to know when to use quotes when not to ?

Can these inconsistencies be taken out ?

• This topic was modified 2 months, 2 weeks ago by  Bracer.
• This topic was modified 2 months, 2 weeks ago by  Bracer.

[SigilKeymaster]

Your rules for quoted string are this:

1. The only fields that will ever take a quoted string have an “e” by them, which indicates that they can take an expression.
2. An expression can be a variable (no quotes, no spaces, similar to code variables) or a constant (10, true, 1.5, (1, 2, 1), “Hello”, etc). This page explains more.
3. The only way RAIN will ever interpret a string is as a name of a RAIN object, either a navigation target, a waypoint route, waypoint network, sensor, or aspect. We will never do a search of GameObjects or similar in an attempt to find the object.

That said, the common mistake is to write a name into an expression field without quotes, which RAIN interprets to be a variable (from memory or earlier in the tree). It isn’t an error, but it won’t give you the result you expect.

Outside of that you will have to infer what the field wants as to whether a string makes sense. If you are specifying a target, a string will search for a navigation target with that name. If you are specifying a waypoint route or network, a string will search for a waypoint route or network with that name. On the detect node there is a sensor and aspect, a string will look for sensors and aspects with that name. You would never use a string on a field that wants a speed, that would have to be a variable (that evaluates to an integer or float) or a number.

The documentation is out of date (and unfinished), but the fields for the behavior tree nodes do explain these most of the time. The wording could be better though.

[Author]

Posts