Thanks Luís and Ernesto, that's really helpful. I imagine that extending MasonGeometry will have a lower overhead than maintaining a map of Geometry->Agent. Ernesto, what are the implications of having to make Agent serializable? MasonGeometry implements Serializable, I can continue to implement Steppable. Thanks in advance, Nick On Tue, 22 Mar 2016 14:57:22 +0000, Ernesto Carrella <[log in to unmask]> wrote: >The two easiest solutions are probably to either keep a map >Geometry-->Agent somewhere or to subclass MasonGeometry to add a field >linking it back to the Agent. >First is probably better since you don't have to worry about making Agent >serializable as well (although you might not care) > >On Tue, Mar 22, 2016 at 1:56 PM Nick Malleson <[log in to unmask]> >wrote: > >> Hi all, >> >> This might have an easy answer, apologies if I have missed something on >> the list. >> >> I am using a GeomVectorField to store my agents. I need to be able to get >> back to the original Agent object, not just its associated MasonGeometry. I >> create agents and add them to the GeomVectorField a bit like this: >> >> Agent a = new Agent(); >> agentGeomVectorField.addGeometry(a.getGeometry()); >> schedule.scheduleRepeating(a); >> >> That basically works fine, but now I want to be able to get back to the >> underlying agent. I guess I could maintain a separate List of agents as >> well as the GeomVectorField, or I could add the agent to its >> MasonGeometry's userData field. >> >> Any opinions on which would be best? How else have people stored their >> agents and their geometries using geomason? >> >> Thanks in advance, >> Nick >> >