Skip to content
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

XML import semantics different between Groot and BT? #125

Open
Beaudidly opened this issue May 4, 2021 · 3 comments
Open

XML import semantics different between Groot and BT? #125

Beaudidly opened this issue May 4, 2021 · 3 comments

Comments

@Beaudidly
Copy link

Hi, first off would like to show my gratification for your work!

Context: I am trying to create multiple separate "libraries" of commonly used nodes that projects can pick and choose which to include. One of my goals with this is to have it be easily maintainable. I started off not using Groot to edit, but have found it quite helpful to edit and visualize. So ideally I would have these projects work with Groot!

My attempt:

<root>
    <TreeNodesModel>
        <Action ID="MiscNode1"/>
        <Action ID="MiscNode2"/>
    </TreeNodesModel>
</root>

I created multiple "library" xml files that just look like the above example. Some of these files may have subtrees I may want to use, and others may not. As I understand, the TreeNodesModel section is only to satisfy Groot with "forward" declaring nodes, and is not needed by BT.

I have two issues with using this that seems to be maybe an inconsistency between how BT and Groot uses these files. I thought the <include path="path/to/xml"/> would have worked here. But on BT runtime, it errors out because there are no declared <BehaviorTree>s. This is just a small inconvenience as I can create a dummy tree that I won't use on runtime.

But the other issue is that this include doesn't semantically seem to work with Groot. If I include by path, it will say it can't find those nodes/subtrees. I understand that loading palettes via the gui can be a solution for nodes, but that is not very maintainable as it just copies the declaration text into the project file.

I might be fully misunderstanding something, but is it possible to use Groot with tree files that include from other xml files similar to C++? I place this here as its a cooperation between the two projects.

@ekouters
Copy link
Contributor

ekouters commented May 4, 2021

is it possible to use Groot with tree files that include from other xml files similar to C++?

How would you imagine this in Groot? The trees from included xml files, would they then be read-only? Or would Groot need to remember per tree which xml file to save the changes to?

Groot currently loads all trees into memory, and dumps everything in a single file when saving. If you included trees from other xml files, everything would still end up in a single file if you make changes and save the changes.

@Beaudidly
Copy link
Author

How would you imagine this in Groot? The trees from included xml files, would they then be read-only? Or would Groot need to remember per tree which xml file to save the changes to?

I need to spend more time understanding how Groot works under the hood, but the concept of read-only for the subtrees would be more than fine I think. And these portions (subtrees and declarations) included could be flagged as included so they wouldn't be persisted to the same file. There may be other patterns that tackle this problem, but I don't want to just blindly complain.

I am curious how others tackle problems like this? Where you want to reuse nodes/trees between projects, and treat them as libraries. I can see the import palette option, but I think that falls apart quick as the libraries change/get updated.

@Albert-Genius
Copy link

Albert-Genius commented Nov 21, 2024

@Beaudidly Hi,
Here is may patch which can solve your problem. The patch based on Groot 3.8.
opt_groot_for_multi-xml_configration.tar.gz

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants