-
Notifications
You must be signed in to change notification settings - Fork 194
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Naming nodes #31
Comments
Update: I found out you can "Label" nodes. What about adding extension method or member method to node like new Selector(...).Labeled("Steering"); or "fake decorator" like NPBehave.Labeled("Steering", new Selector(...)); Probably best solution would be to add this directly in the constructor like so new Selector("Steering", ...); But that would require a lot of changes |
Hey, so the intended syntax for the labelling is quite similar to your first idea it goes like this:
adding your idea wouldn't be much work, but maybe you can work already with the syntax we have? |
Checked it briefly, it's fine but "Fake Decorator" would be still a little better due to information flow. Because then you have label next to actual node definition and not after this. |
OK. We can maybe also go for the one to include it in the constructor, but it will increase amount of mandatory fields. I would like to keep it optional if possible... With 2.0 I'll probably have to rethink the way we handle growing amounts of fields in the constructors. Not sure if there is any better way to describe the trees by Code. But I would like to also reduce the amount of constructors if possible. Maybe we could prefer using named parameters somehow, but I'm not sure if it works with the composites so well. Maybe we could live with something like
|
Actual utility method would look more or less like this now that I look at it: public static class NPBehaveUtils
{
public static Node Label(string label, Node node)
{
node.Label = label;
return node;
}
} Now, you can just add Label("Steering", new Selector(
...
)); |
I also think, after second thought that it would be the best solution due to it being universal for every Node |
right. Let's keep it simple for now. For 2.0 we can rethink this |
I touched this asset again and I noticed big flaw when it comes to debugging. Currently we cannot name nodes like selector or sequence in easy way. This is key feature in my opinion.
Without this debugging is basically pointless
With naming we would be able to explicitly say "this part of tree is handling steering"
The text was updated successfully, but these errors were encountered: