The locator goal can take the following types as input:
Mesh, Line, Polyline, Point, Arc
It’s really just a way of keeping track of the indices of a number of particles, and reconstructing some point based geometry using the updated positions of the particles at these indices after the solver has moved them around (for the ‘show’ component).
I didn’t really imagine people scripting with the library would have much use for it, since then you have direct access to the indices of all goals and particles you create, which I think should be simpler than using Locator.
After you’ve called AssignPIndex on a goal (which finds the indices of the particles in that goal if they already exist in the system, and adds new particles if they don’t), you can use its PIndex to see which particles from the particle list it is acting on, get their new positions and make updated geometry using these positions.
Regarding the list structure of GetOutput - I’ll have a think about whether anything can be done to make it easier for scripters to organise their goals in more convenient ways. I can say now though - I don’t think that will ever involve putting Grasshopper datatrees inside the KangarooSolver.dll (which as much as possible is kept separate from Grasshopper, since in the long run the intent is to do other Rhino stuff with it, with Kangaroo.gha handling all the interface with GH).
In your mesh example, I don’t understand what you mean in your step 2.
If you have a mesh with consistent normals, then Kangaroo moves the points around, if you keep the vertices in the same order, and the same face information as before, then the normals will remain consistent.