Building Tree View

[codecorsair]

Quote from Brad:

At the very basic I need something like this.

The tree will be small, so the whole thing can be pushed to the UI anytime it is changed.  I just need to know what format that would take.  Also, when the selected item changes, I would need some callback with some form of identifier.  I'm not sure how that works in TypeScript or whatever.  I can keep a map of unique name to tree position on my side if necessary.  Or we could encode position in the name by something like Grandson == 1_1_1 and StepChild = 1_2_1.  Doesn't matter.

The more complicated problem is when you click on 'Add Child', I need to be able to let the user decide what to add.  At the simplest this could just be a couple droplist that you select before clicking 'Add Child' but the permutations are large.

Here are the options:

MorphType - Scale or Cylinder.
  Scale - scale amount.  1/4, 1/2.
  Cylinder - no options at the moment.
Transform Type - Rotate or Skew
  Rotate - Axis (X, Y, Z) and Amount (multiples of 45 degrees.  45, 90, 135, etc.)
  Skew - Axis.

Even more complicated is they transforms can be a stack (not tree) themselves.  So you could combine a Rotate and Skew or something.  Initially we can just have them add another child on the tree above but that means an extra, unused Morph.  Not a problem for prototyping.  I'm just putting it out there for consideration.

Thanks,
--Brad

[WheezardX]

Design has changed a bit since I originally wrote this. You can ignore the last paragraph!

[Mehuge]

Though doing add/remove child and having the siblings behave like a stack would have been doable.

[Mehuge]

I understand this is to be part of the building UI, where in the building UI does it fit?

Not sure I understand what the 'add child' options are. A real example might help (ie a tree data with actual values). Are we talking something along the lines of:-

+ Morph
| + Scale
| | + 1/4
| + Cylinder
+ Transform
| + Rotate
| | + Axis
| | | + X
| | + Amount
| | | + 45
...

[WheezardX]

So, the design of this is really up in the air. For now all I really need is the tree control, with callbacks when the selected item in the tree changes, and the add/remove buttons.

When you click on Add button, we need to determine what to add. The only existing options are 'scale' and 'cylinder'. To future proof it (some), we should also probably add 'rotate'. These can be a different control, like a droplist or something, that is fine. Or even 3 Add buttons, one for each.

I'm thinking we should keep it as simple as possible for now, until I better know what we need.

It should be a new floating/resizable window, like the other parts of the Building UI.

[Mehuge]

Gotcha

[Mehuge]

How are IDs and Remove Child going to work?

If we go 1_2_1 for StepChild (or 1-0 in zero based, root node implied) and I remove GrandSon, GrandDaughter and Child, then StepChild is now 0-0 not 1-0.

If you can generate a unique ID for each node, the client doesn't have to then worry about it, and an Add Child request would simply specify the unique ID of the parent. I would probably need to be given the generated ID as the response to the Add, so I have it if a child is also added to that before receiving an update from the server for the whole tree.

[Mehuge]

Proposed OnBuildingTreeChanged parameter format (TreeThingNode):-

{
  "root": {
    "id": "1000", "value": "Root",
    "children": [
      { "id": "1001", "value": "Child",
        "children": [
          { "id": "1003", "value": "GrandSon" },
          { "id": "1004", "value": "GrandDaughter" }
        ]
      },
      { "id": "1002", "value": "Sibling",
        "children": [
          { "id": "1005", "value": "StepChild" }
        ]
      }
    ]
  }
}

id: string - anything as long as it is unique within the tree
value: string or number - the value of this node (displayed to the user)
children?: [optional] array of TreeThingNodes

Can be expanded/changed as necessary. Having a name?: string might be an option, so we can have name and value pairs, and the tree would display as name: value.

[Mehuge]

Question:

Is [ Remove Child ] really a remove child or a remove node function?

ie.

Remove Child:-

I am on a parent and press Remove Child, I remove the last child added and call cuAPI.RemoveBuildingNode(parent.id)

Remove Node:-

I am on a node, and press [ Remove Node ]. I remove that node and call cuAPI.RemoveBuildingNode(node.id)

[WheezardX]

It should remove whichever node you currently have selected. Not its child as it could have multiple children and that would be ambiguous. So yes, the button should probably not be labeled "Remove Child". Good catch!

[Mehuge]

https://github.com/Mehuge/Camelot-Unchained/tree/cu-tree-control

Don't know if you want me to PR this yet or you can checkout from my branch while we are still ironing out the details.

[codecorsair]

submit it to this repo on a branch please. Then I can get something set up for Brad to test it.

[Mehuge]

https://github.com/CUModSquad/Camelot-Unchained/tree/building-tree-control