I have distributed turtles on the world having size x and I wish to increase their size to y but the I want to keep their location of their lower further point same (Check figure below). How can one accomplish this?
EDIT:
I wished to write a procedure that could be applicable for all turtle heading, that is if the turtle is heading 0 or 90 or 45. Direct math in such case could be complicated.
As Seth said, this should be relatively straight forward math. If you don't want to do the math, though, and this is only for visual purposes, you could make a new turtle shape, where the "bottom" of the shape is actually at the center. Then, when turning, it will like the turtle is turning around their bottom. When changing size, again, the "bottom" will stay in the same place.
Related
I want to move my turtles and I want that they don't go out of my field.
For example, If turtles 1 have to attack the goal that is in the right place of the screen, I don't want that the turtles 1 that is in the left side go out from the field and reappear on the right side(and viceversa).
I initial found a possibile solution by set the goal position, and use :
facexy-nowrap goal-xcor goal-ycor
But It doesn't help me because I use this command only for attack behavior, and I prefer to not use it...
So there is another solution? like using field lines?
In setup, I draw a bunch of turtles--as small circles--to display two curves defined by functions. A very simple way to do this is
ask patches with [pycor = (myfunction pxcor)] [sprout 1 [...]]
and that's what my code does at present. It's kind of wasteful, since every patch has to be consulted--in random order--for each curve, but it's simple and easy to read, and it only happens during setup.
However, there's a little bit of a pause as the curves are constructed. If I move the speed slider all the way to the right, the pause is not noticeable. If I wrap the curve display routines in no-display and display, the user doesn't see the curves being constructed, but the speed is unchanged, AFAICS. If I move the slider to the left, it takes a long time to construct the curves even with no-display; the user doesn't see the points being placed one by one, but nevertheless has to wait while twiddling her/his thumbs.
Is there a way to set the model speed programmatically (for normal, "headfull" use)? I don't want to tell users "Move the speed slider to the right, then press setup, then move it back to the center before pressing go.
If not, maybe I'll code the curves properly using loops, but I thought I'd ask. Seems like there would be a way to do this, but I haven't found anything in the dictionary or programming docs so far.
(edit: no-display, if it did help, isn't available in NetLogo Web, which I am targetting along with regular NetLogo.)
I don't believe there is. However, you are asking all patches, when you could simply ask the pxcor values. This should speed it up a lot - square root of the number of iterations if a square world. Something like:
to testme
clear-all
let counter min-pxcor
while [counter <= max-pxcor]
[ let fn-out (function counter)
if fn-out >= min-pycor and fn-out <= max-pycor
[ ask patch counter fn-out [ set pcolor red]
]
set counter counter + 1
]
end
to-report function [#invalue]
report #invalue ^ 2
end
can I set the min/max pxcor and pycor in Netlogo interface from code? Want to choose a state, and then use its min/max lat/long to set the display so it fills up the whole world. I guess the alternative is to make the world wide enough and high enough for the biggest state and then adjust all lat/long values to fit that. I'm only looking at lower 48 states since Alaska is huge and Hawaii spread out, but still makes Rhode Island teeny next to Texas.
Sure. Just take a look at the resize-world primitive.
Just be aware that:
As a side effect, all turtles and links die, and the existing patch grid is discarded and new patches created.
I have an app with large boxes falling on top of the small red box. I would like to know when the small red block reaches a certain weight (X blocks are resting on top of it). I couldn't find a weight property for the red block. Any suggestions?
EDIT: Just to clarify. The boxes falling from the top will be random sizes, and falling from random positions. So there isn't really a way to keeping track of what landed on top of the red block. I need some way to measure the downward force being applied to the red block
You can calculate the weight for each node the following way and then add them together.
redBox.PhysicsBody?.mass
I have used face in NetLogo without any problems, but isn't towards just the same? (in the context of an agent facing towards the direction of a patch/agent)
towards
towards agent
Reports the heading from this agent to the given agent.
If wrapping is allowed by the topology and the wrapped distance (around the edges of the world) is shorter, towards will use the wrapped path.
Note: asking for the heading from an agent to itself, or an agent on the same location, will cause a runtime error.
set heading towards turtle 1
;; same as "face turtle 1"
See also face.
Is there any scenario in which using set towards heading is better than using face?
towards only reports the heading
face is like towards and set heading combined into one.
Are there circumstances in which you would like to know the heading towards something without actually turning to face it? I'm sure you could think of many. One example situation would be choosing between two possible headings according to some criteria.
Let's say you want to face one of two agents, whichever one requires you to turn the least amount:
let first-heading towards first-agent
let second-heading towards second-agent
; compare my current heading to the two calculated headings:
let first-angle subtract-headings heading first-heading
let second-angle subtract-headings heading second-heading
if-else abs first-angle < abs second-angle
[ rt first-angle ]
[ rt second-angle ]
(In real life, you would probably do things a bit differently, but I hope this carries the point across.)