Is it possible to change a range of patches color in the code tab? Instead of setting each individual coordinate. This would be done as part of initial model setup. I am essentially trying to "draw" a map for a battle simulation with patch colors. Below is the code I have but its obviously slow going. If i could use a range of coordinates it would be way faster
ask patches at-points[[-16 -16] [-15 -16] [-14 -16] [-13 -16] [-12 -16] [-11 -16] [-10 -16] [-9 -16] [-8 -16] [-7 -16] [-6 -16]] [ set pcolor brown ]
You can definitely address patches within a range of coordinates values, by using with and remembering that pxcor and pycor are nothing more than patch variables for which each patch holds specific values:
to setup
clear-all
ask patches with [pycor = -16 AND pxcor < -5] [
set pcolor brown
]
end
The code above does the exact same thing as your example.
If instead you have a situation in which there is no particular pattern to follow, but you still want some very specific patches to change color, I am afraid that you will have to hard code it. Doing it with at-points is a way to do it, and I don't think it is particularly inefficient.
Maybe creating an agentset of patches (i.e. a patch-set) and then asking them to change color would be faster? I don't know, you can find it out using the Profiler extension if you want.
If instead for some reason you don't want to have those lines of code in your model, an option would be to create your initial environment once and then use export-world to export it as a file that can be read at later moments using import-world.
Related
I have a fairly simple question: is there a way to define a patch-set based on a patch-variable? In my model, I have a large set of patches that form the food object, and food is a patch-variable. I have the turtles change color when they find themselves on the food, but I have previously manually defined the patch-set on which they change color. However, I want to adjust the location of the food, and I don't want to go through the work of checking and redefining all the food patches. Thanks!!
to setup-food
if (distancexy (0.8 * min-pxcor) (0.8 * min-pycor)) < 5
[set food 5
if food > 0
[set pcolor cyan]]
end
TO look-for-food;; procedure that controls turtle color change on food
let potential-leaders foragers-on (patch-set patch -38 -16 patch -37 -16 patch -36 -16 so on..)
[do things]
end
````````````
you can create such a patch set explicitly like:
let foods patches with [food > 0]
ask foods [ set pcolor cyan ]
This is a local variable that is thrown away (hence let) when the procedure is over, but you can also create a global variable if you are going to need this patchset in lots of places in your code, just remember to update it when the food runs out on a patch.
And you also do this implicitly whenever you use with
ask patches with [food > 0] [set pcolor cyan]
For example, I would like to get the coordinates of the first patch above, below, to the left and right of the patch the turtle is currently on, as well as the value of a variable for each of those patches, such as plabel or pcolor. Essentially I would like to use this information so that then the agent can make a decision as to which patch to move to.
I think neighbors4 might be how to do this but I'm not quite sure of the code needed. For accessing variable values, I have been trying
let LabelsOfPatches neighbors4 [plabel]
or
let ColorOfPatches neighbors4 [pcolor]
But I get an error saying a command was expected in between the square brackets.
A one-liner that does the same thing would be
let NeighborList [(list pxcor pycor pcolor plabel)] of neighbors4
It can be run by either a turtle or a patch. of is great for making lists of values drawn from another agent or agentset.
I have seemingly done what I wanted by using
let NeighbourList []
ask neighbors4 [set ValuesOfInterest (list (pxcor) (pycor) (pcolor) (plabel))
set NeighbourList lput ValuesOfInterest NeighbourList
]
I have some netlogo code that I would like to make more descriptive.
So instead of:
MOVE-TO ONE-OF PATCHES WITH [ PCOLOR = BLUE ]
It would say:
MOVE-TO ONE-OF PATCHES WITH [ WATER ]
In java I would create an enum to accomplish this. How can I do it in Netlogo?
Alan's answer is fine, but I would also consider the possibility of creating a patch variable instead of relying on the patch color. For example:
patches-own [ water? ]
If you set this to true for each water patch, you can then say things like:
move-to one-of patches with [ water? ]
The main reason for doing this is that you might want to change the color of the water patches at some point: make them a slightly darker or lighter blue, for example, or use color to temporarily highlight patches with some other characteristic.
Separating presentation and program semantics is generally good practice.
Another, different way to achieve this would be to create an agentset with your water patches during setup. For example, supposing you declare water-patches as a global variable, you would do:
set water-patches patches with [ pcolor = blue ]
And then you can do:
move-to one-of water-patches
The water-patches agentset is not affected if you change the color of a patch. It might also be a bit faster since you only construct it once instead of filtering over all patches over and over again.
to-report water ;patch proc
report pcolor = blue
end
Alan's answer is perfectly fine, but this question suggests to me a different conceptualisation. What you really mean is that the patch is coloured blue because it is water, but you are coding it the other way around so that colour is indicating its status as water. If other aspects of your model (eg travel speed, type of crops) depend on whether it is water or not, then you could consider a different construction.
patches-own
[ water?
]
to setup
ask patches
[ set water? FALSE
if random-float 1 < 0.2
[ set water? TRUE
set pcolor blue
]
]
end
In this construction, you have a true/false variable for each patch that indicates it is water (if true). Then you can directly have statements such as ask patches with [water?] []. You can also set up a global variable that holds the patch-set of water patches and then make statements like ask water-patches []
If you have multiple types of land style (eg water, sand, soil, rock...) then you colour is more likely to be the way to go since you don't want separate variables for all of these. Even then, though, you could have one attribute for land style and have constructions that are ask patches with [ type = "water"]
I have mouse and cats moving across the view, and I'd like to be able to make a smell trail to the mouses. The smell should fade away with time, simulating the intensity of the smell. If a cat enter on the smell trail, the cat must follow the smell trail to kill the mouse.
I will leave a part of my code, in case it helps:
...
mice-own [energy refX refY]
...
to setup
ca
setup-patches
setup-agents
reset-ticks
end
to setup-patches
ask patches[
let x 28
let y 48
if pycor mod 2 = 0
[set x 48 set y 28]
ifelse pxcor mod 2 = 0
[set pcolor x]
[set pcolor y]
]
end
to setup-agents
create-mice N-mice
[
set shape "mouse side"
set color 4
setxy random-pxcor random-pycor
set energy 50
set refX 25
set refY 25
....
to move-mice
ask mice
[
let x one-of neighbors
move-to x
set energy energy - 1
if energy <= 0 [die]
ifelse show-energy?
[set label energy set label-color black]
[set label ""]
]
end
Thanks for the help.
There is a primitive diffuse that does exactly that. Look it up in the truly amazing netlogo dictionary. There are several models in the model library that use it most famously the ant foraging model.
Pair that with the primitive downhill and your model will almost write itself.
you might want to consider adding some decay to the smell. if not, there's mouse smell everywhere!
additionally some minimal awareness threshold will possibly also get your cats to pursue other leisures than teasing mice.
I'm having some issues with the in-cone command in Netlogo. I am trying to identify the sum / mean of all the patch variables directly in front of my turtles current location (ie the sum of all the variables it crosses). However, this only appears to be working when my turtle is at the center of a patch (co-ordinates are integers not decimals), which also means I can only move my turtles at right angles. I'm yet to find any other questions pertaining to the same issue on Stackoverflow or elsewhere. So if anyone could offer some insight, I'd be greatly appreciative.
Below is the simple sample code. And I've annotated where making the changes causes this to not work.
Cheers
Paul
turtles-own [value]
patches-own [value-test]
to Set-Up
ca
reset-ticks
ask patches [if pycor > 150 [set value-test 1]]
ask patches [if pxcor > 150 [set value-test 1]]
ask patches [if value-test = 1 [set pcolor red]]
create-turtles 1
ask turtles[
;It works when the turtle is created at the origin (0 0), or at defined coordinates (but not random-xcor random-ycor)
;setxy random-xcor random-ycor
set value 0
set size 10
set color yellow]
end
to go
ask turtles[
;heading has to be 0, 90, 180, or 270.
set heading 270]
ask turtles[
let test mean [value-test] of patches in-cone 10 1
print test
print xcor
print ycor
ask patches in-cone 10 1 [set pcolor blue]
forward 10]
end
in-cone is not the right tool for the job. Unfortunately, NetLogo doesn't have a primitive that looks ahead in a straight line. It does, however, have patch-ahead, which reports a single patch at a given distance. We can use that to build something similar to what your looking for:
to-report patches-ahead [ dist step ]
report patch-set map patch-ahead n-values (dist / step) [ step + ? * step ]
end
This code may look puzzling at first, but what it does it actually quite simple:
It uses n-values to build a list of incrementing values: n-values (dist / step) [ step + ? * step ]. For example, if dist was 1 and step was 0.2, you'd get [0.2 0.4 0.6 0.8 1]. These values represent the distances at which we are going to be looking for a patch.
It uses map to call patch-ahead for each of values in the list and build a list of patches. Note that this list can contain duplicate patches, especially if step is small, since patch-ahead 0.1 and patch-ahead 0.2, for example, may very well be the same patch.
It uses patch-set to turn that list in a proper agentset of patches, without duplicates.
(You could achieve the same thing with a while loop and an incrementing counter, but the code would be longer, more error prone, and much less elegant.)
To use it, just replace instances of patches in-cone 10 1 in your code by something like patches-ahead 10 0.1.
You will notice that there is a trade-off between precision and speed: the smaller step is, the less likely it is to "skip" the corner of a patch, but the longer it will take to run. But I'm sure that you can find a value that works well for you.
Nicolas has a much better answer solving the problem of looking in a straight line but if you simply what look at the patch directly ahead use patch-ahead 1 it works at all angles and coordinates and is much faster than in-cone.
Completely an aside but probably the reason you found this bug is because your cone was set to 1 degree wide and 10 patches long. Long narrow cones tend to break up.