Open qiemem opened 8 years ago
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:
ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>
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.
Can transfer/clone (kill in one, create in another) between models with the same turtle/breed variable names.
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...
That is, can copy if: [.....]
I'd love this to be more flexible. Can we add a variable to agents that isn't declared in -own
called variables
or 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.
Position is tough [...]
I don't think it is. I think your suggestion addresses everything that should be addressed, and I agree 100%.
Something like
let ls-agentset ls:agent-set turtles with [color = red]
ls:clone-agents <model-id> ls-agentset [ command-block ]
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.
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:self
to allow cloning and transferring with the parent? e.g.
ls:clone-agents ls:self [turtles with [ color = red]] child-model [ initialization ]
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.
I'm picturing https://en.wikipedia.org/wiki/Wood_between_the_Worlds . disoriented turtles waking up with rings taped to their shells
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.
Turtles:
ls:move <source-model> <reporter-of-turtle/turtleset> <target-mode> <optional-initialization-block>
xcor
as?1
andycor
as?2
.Patches:
Links: