I'm new in netlogo, and i want to know is it a right way to set turtles vision by using this code?
set leader patches in-radius vision
the vision is set as slider and can change from 0-10. The problem is, when i vary the vision from 0-10, seems nothing is change in turtles behavior. Really need some advice on this. thanks for help.
to setup
setup-leader
end
to setup-leader
ask max-n-of 10 turtles [count turtles in-radius 3]
[
set leader? true
set color black
set size 1.5
set leader self
set leader patches in-radius vision
]
end
This part of your code doesn't make sense:
set leader self
set leader patches in-radius vision
If you set leader twice in a row, the second set overwrites the first, so you might as well just omit the first.
In itself, this line:
set leader patches in-radius vision
could be correct, depending on what you're trying to do, although calling a variable containing a patch set leader is strange.
re: "when i vary the vision from 0-10, seems nothing is change in turtles behavior", impossible to comment without seeing the code for the turtles behavior. (If you were expecting set leader ... to have some effect on the turtles behavior all by itself, that won't happen. That one line just sets a variable. If nothing is looking at the value of that variable, then nothing further will happen as a result.)
I'd suggest looking at some of the many models in Code Examples and Sample Models that give turtles some kind of "vision", so for example Flocking, Fireflies, and so forth.
Related
I am brand new to Netlogo and am coding a world with caching animals. They will go to their caches (I set them as blue patches) if their energy value falls below 10. They can find these caches based on a random 'memory' value given to them which is used as an in-radius value. That way, they will face and go towards a cache within their in-radius memory if they are about to die. I am starting to incorporate a home-base system where the turtle remains in a smaller area with their own caches. Does anyone know how I can make a patch belong to an individual turtle? This would allow turtles to have their specific caches in their territory. I have looked into using links and breeds, but links are only between turtles and making the individual breeds for the 50+ turtles at a time seems ineffective and complex. I apologize I don't have any code attempting to have a cache (patch) belong to a turtle, I don't know where to start. Any ideas?
If you want a turtle to remember anything (patches or income or anything else), then you need to assign a variable in a turtles-own statement and then set the value appropriately. Here's some example code fragments. They won't work, and you actual code would likely look a lot different because you will need some design about the conditions under which a cache will be assigned, but they show you what a variable solution looks like.
turtles-own
[ my-caches
]
set my-caches (patch-set my-caches patch-here) ; code when a turtle finds a new cache site
If you want a patch that belongs to a turtle to make that patch unavailable to other turtles, then also set up a patch variable to store its owner.
patches-own
[ my-owner
]
ask turtles
[ if [my-owner] of patch-here = nobody [set my-caches (patch-set my-caches patch-here)]
ask patch-here [set my-owner myself]
]
I suggest you do several NetLogo tutorials, then look at some library models (and understand them) before starting your own model. You need to understand basic concepts like turtles/patches, variables, ticks before trying to build a model.
I have a programme that sets up a number of different breeds of turtles. Each breed needs to have a leader turtle and a follower turtle. I have assigned these as global variables as they come up a lot in the code further down.
I need to assign these variables to turtles in the breeds and then create a link from the leader to the follower. There are a lot of conditions in the interface that determine how many and which breeds are created so i cannot assign by turtle number.
I am receiving an error (not all of the time) 'turtle cannot link with itself' which i presume occurs when they overwrite the first set command and assign the same turtle to the two variables. Does anybody know a condition i can put in that will allow it to set up everytime without the error. ( I have tried if statements, is-turtle?, one-of other, other)
breed [flinks flink] ;; linked turtles that will turn away from sources
globals [
flink-leader
flink-followers]
to set-up
clear-all
setup-turtles
reset-ticks
end
to setup-turtles
create-flinks 2 [
set flink-leader one-of flinks
set flink-followers one-of other flinks
ask flink-followers [create-link-with flink-leader]
ask flink-followers [set color pink]
ask flink-leader [
setxy 10 4]
ask flink-followers [
setxy 19.5 4]
]
end
to go
fd 1
end
There would be many different ways to approach this. Here is one that doesn't stray too far from the code you have provided:
to setup-turtles
create-flinks 2
set flink-leader one-of flinks
ask flink-leader [
set flink-followers one-of other flinks
setxy 10 4
]
ask flink-followers [
create-link-with flink-leader
setxy 19.5 4
set color pink
]
end
Note that your intuition about using other to make sure that the follower(s) is/are different from the leader was correct.
To understand what was going on, you need to grasp the notion of "context" in NetLogo. Some primitives, like ask, of and create-turtles, are "context switching": one of their argument is a code block (the part between [ and ]) that runs in the context of a particular turtle. Other primitives depend on the context in which the code is running: the primitive named other, for example, will report all the agents from a given agentset, except the one in the context of which the block is running.
In your version, you wrapped most of the code inside a code block provided for create-flinks. That meant that the code block was run once for each turtle that was created. So your calls to set flink-leader, set flink-followers and so on were all run twice, each time in a different turtle context. Can you see how that was messing things up?
Keeping track of the different context in NetLogo can be challenging at first (the frequent confusion between self/myself being a case in point), but once you get it, it should become easy and natural.
One last point as an addendum. You say:
i cannot assign by turtle number
Good! Never¹ assign anything by turtle number! It leads to brittle, error prone, more complex, less general, unnetlogoish code. If you think you need to use turtle numbers anywhere in your code, come ask another question here. Someone will most likely suggest a better way to do it.
¹ Well, almost never.
I am trying to build a model in which turtles decide to change colour depending on their environment in a network.
The approach would be to "check" the colour of the surrounding turtles and then set an if statement for the turtle in question to switch colour (there will only be 2 colours).
Specifically I would like to know how can a turtle "see" or check other turtles' colour (or other properties).
If possible I would also like to create a slider for "how many links away" can turtles see their neighbouring turtles' (or neighbours of neighbours, etc) colour.
I am new to both Netlogo and Stackoverflow, so please let me know if I should make any modifications to my model and/or question.
Thanks!
Welcome to Stack Overflow! Typically you'll want to stick to a single question per post, both for simplicity and for the benefit of future users with similar questions. As well, in cases where its applicable you should try to include some code to show what you've tried so far, as well as any setup necessary- you want to make a minimal, complete, and verifiable example. In this case, I think you're okay since your questions are clear and well explained, but if you have more complex questions in the future you will be more likely to get useful answers by following those guidelines.
For your first question, it looks like you want the of primitive- check out the dictionary entry for details. of can be used in a few ways, including allowing agents to check the value of a variable (such as color) of another agent. Check out this example code:
to setup
ca
reset-ticks
crt 10 [
setxy random 30 - 15 random 30 - 15
create-link-with one-of other turtles
]
end
to go
ask turtles [
set color [color] of one-of link-neighbors
]
end
Every time the go procedure is called, one of the turtles changes its color to the color of one of its link-neighbors. If you run it long enough, all connected turtles should end up with the same color.
For your second question, I suggest you check out the Nw extension, which is an extension built to deal more easily with Netlogo networks. Specifically, have a look at nw:turtles-in-radius, which should work with your slider approach. To get it working, include the extension using
extensions [ nw ]
at the start of your code. Then, assuming the same setup as above, you can play around with something like
to network-radius
ask one-of turtles [
set color red
ask other nw:turtles-in-radius 2 [
set color white
]
]
end
When you call the network-radius procedure above, you should see one turtle turn red, and any turtles within 2 links of that turtle turn white. To switch to a slider, just swap the "2" out for your slider variable. Hope that helps!
What actually happens to hidden turtle? I mean after we hide the turtle it continue to live in invisible mode occupying memory as I guess.
I hide few turtles but did not ask them to be shown back and when I inspected the hidden turtles continuing simulation their attribute were changing as per my commands. So, what exactly hiding a turtle sense for.
In one of my simulations, turtles represent people making decisions about whether to protect themselves during an epidemic. There are tens of thousands of these turtles, with potentially hundreds on some patches. The turtles don't move, but they each make their own decision based on personal characteristics like attitude and environmental perception such as how close the epidemic is.
Having these turtles visible would just clutter up the screen. Instead, I hide them and colour the patch based on what proportion have adopted protective behaviour. This is much more informative.
In my most recent simulation, though, I make the turtles size 0 instead of hiding them. This still makes them disappear, but I can still right-click on the world view to access the list of turtles where I have clicked.
Another reason to hide turtles is when you are simulating an infinite plane and turtles outside the view should simply be hidden.
Note that if you are moving turtles using setxy rather than forward you should test to make sure the patch you are about to move to exists since setxy throws a runtime error if it is given coordinates outside the world. From NetLogo documentation:
ifelse patch-at (new-x - xcor) (new-y - ycor) = nobody
[ hide-turtle ]
[
setxy new-x new-y
show-turtle
]
In my simulation each turtle has a my-home variable which is the patch agent family lives in, so agents with same Family-ID have same my-home until one of agents moves out or family grows to more than 7 agents.
when an agent wants to move out , I have to check if there is any patch nearby which is not another's agent my-home, what I have done is to store all my-homes in a list and check if any selected possible next home is not a member of this list, but I believe there should be better way to do this:
let all-homes [my-home] of agents with [belongs_to = BS]
set my-home min-one-of patches with [not member? self all-homes and label_ = BS][distance m]
m is current home address
min-one-of patches with ... assesses every patch in the entire world before picking a winner. That's going to be slow. I'd suggest searching nearby patches first, then farther patches, and so forth. Most of the time the turtle will find a new home after only a very brief search, so you'll have replaced code that's O(n) in the number of patches with code that's O(1)-ish. That should fix the main performance problem with this code.
The simplest such search routine I can think of is for the turtle to simply head in a random direction and keep moving fd 1 until it lands on a free patch. But if you want to do something more rigorous that always results in finding the closest possible new home, you could do that too; you'll just have more code to write.
Building the all-homes list is probably only a secondary performance problem here, but it's fixable too. The simplest fix I can think of is to add:
patches-own [home?]
initialize it with ask patches [ set home? false ], and then make sure that whenever a turtle adopts a patch as its home, it does ask my-home [ set home? true ]. Now you can replace member? self all-homes with simply home?. After all, you don't really need to know what all of the home patches are; you only need to know whether some particular patch is a home patch.