Repository navigation
Support transferring and cloning of agents between models #69
Description
Turtles:
ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>- Can transfer/clone (kill in one, create in another) between models with the same turtle/breed variable names. That is, can copy if:
- Does a breed with the same name as the turtle's breed exist in the target model?
- Take all the names of the turtle's turtle and breed vars. Do variables with the same names exist in the target model?
- Does the turtle's shape exist in the target model? (we could just default shape if not)
- If yes to these questions, can transfer.
- Variables are matched up by name, except for position
- Position is tough since the worlds will have different dimensions, and even if they have the same dimensions, it's unlikely that the user will want the turtle's position to be preserved. Right now, I think the turtle should just appear at 0,0, and there should be an optional command block that it runs upon creation that receives
xcoras?1andycoras?2.
Patches:
- Clone only
Links:
- Not sure
Activity
arthurhjorth commentedon May 15, 2016
I like this idea. I think we tried solving it a few years ago with agents as first order LevelSpace objects. I'd really like to see some implementation of it. My thoughts:
This assumes a Controller type model that moves agents between child mdoels. We should allow for moving from the current model to child models too. See below for a suggested solution.
It's possible that people want concurrent representations in different models of the same agent. I think we should not kill, but only clone. It's easy enough for people to kill a turtle in NetLogo anyway.
My suggestion would therefore be to split into a command a reporter. The reporter reports a TPL-set. The command takes one and clones.
Speaking of which...
I'd love this to be more flexible. Can we add a variable to agents that isn't declared in
-owncalledvariablesor something? That way we can clone all data that exists in the model, and put the rest in a key-value map? If that is possible, we can do stuff with an agent in model a, clone it to model b and have it do stuff, and then send it back to model a with some updated information based on what happened in model b, but without losing information.I don't think it is. I think your suggestion addresses everything that should be addressed, and I agree 100%.
arthurhjorth commentedon May 15, 2016
Something like
I am trying to wrap my head around potential ClassLoader issues with passing this to other LevelSpace extension objects. Maybe I shouldn't?
edit: no wait, I definitely should. We will have ClassLoader issues if we want to let people clone to other LS extension objects, i.e. across more than one generation, or even within generation depending on the structure of the model ecology. So that's something to consider too.
qiemem commentedon May 15, 2016
I was hoping to keep it all in one procedure exactly to avoid dealing with custom levelspace objects so we don't have to deal with classloader issues.
How about an
ls:selfto allow cloning and transferring with the parent? e.g.qiemem commentedon May 15, 2016
Map thing:
Let's do compatible models first. It's a strict problem. We'll want that to work as described no matter what. The map thing is pretty tough. We can add turtle variables, so we have to store in the extension itself. But then you could end up with more than one map per turtle when having >2 levels.
SethTisue commentedon May 26, 2016
I'm picturing https://en.wikipedia.org/wiki/Wood_between_the_Worlds . disoriented turtles waking up with rings taped to their shells
arthurhjorth commentedon Jul 24, 2016
I don't know if @SethTisue meant it (mostly?) as a joke, but I actually really like that analogy. I also like the post-hexy milestone.