That is very old code, from back when we were first implementing Joey/K2 in GHPython. I’ll see if I can dig up some more up-to-date examples for you.
It assigns a particle index for the particles (i.e. points to operate on) in the goal. That is, instead of managing the topology of the particles/goals yourself, this method handles that for you. This is slower, but simpler. Though, one of the benefits of scripting K2 is exactly managing the topology of the system.
Yes it would, you can really do whatever fits your needs the best. This is a key advantage of scripting K2 IMO, in that one can actually simplify things quite a lot (as compared to the somewhat hoop-jumping of structuring/re-structuring datatrees). As I recall we also added a property on the goals that allowed one to tag them with a string (for explicitly naming/structuring the goals data), but I think that was only for the goal output. I forget, anywho. Yes you can.
Yes, exactly. You would go something like:
import clr
clr.AddReferenceToFile("KangarooSolver.dll")
import KangarooSolver as ks
# Make goals list
goals = []
for l in lines:
if mode == "spring":
g = ks.Goals.Spring(l.From,l.To,0.00,1.00)
elif mode == "constantTension":
g = ks.Goals.ConstantTension(l.From,l.To,-1.0)
goals.append(g)
It can admittedly be a bit difficult figuring what the input parameters mean, but maybe just have a look at the corresponding component, which is generally well documented:
Though that can also be confusing, since for instance the Spring goal is named Length in its component implementation.
I forget exactly (ping @DanielPiker), but I believe it’s ps.Step(GoalsList, RunParallel, KineticEnergy). One could also use the simpler ps.SimpleStep(GoalsList) when implementing a solver. There’s also the momentum step method, and I think one more 