[Tutor] Livewires questions
tmikk at umn.edu
Fri Jul 27 21:54:39 CEST 2007
Luke Paireepinart wrote:
>> def place_robot():
>> global robot_x
>> global robot_y
>> global robot_shape
>> robot_y = random_between(0,47)-0.5
>> robot_x = random_between(0,63)-0.5
> I'm not too clear why you're subtracting 0.5 here.
> Doesn't this make the robot's center on the grid lines, rather than
> having the robot occupy a full square on the grid?
> I guess that's the intended behavior, huh?
This is particular to Livewires module I believe. I am dealing with the
circle (player) whose position is defined by the center of the circle
and a square (robot) whose position is defined by the first two
coordinates of the square. I subtract 0.5 here so that when the random
numbers picked for both the circle and the the square are the same, then
visually the square is right on top of the circle.
>> robot_shape = box(10*robot_x,
>> def move_player():
>> while 1:
>> global player_x
>> global player_y
>> if 't' in keys:
> You can't reuse your place_player function here, because you put the
> initialization (the creation) of the graphics that represent the
> player _inside_ of the place_player function. Well, technically you
> could, but it would be better instead to use move_to(player_shape, x,
> y) because this doesn't overwrite the old player_shape circle.
> Also, will this work if the player presses "T"?
Ok, I made some progress on the pressing of the "T" key, but it is still
not entirely correct. The reason why pressing the 't' key was not
working initially was because I had omitted the 't' key in the main
while loop. As a result, the code never executed the move_player code
when I pressed the 't' key. Now if I execute the code above, I get a
new player circle placed on the grid, but the old player stays there as
well. I somewhat expected this because I am not getting rid of the old
player by calling place_player() function. How could I eliminate the
old player circle from the grid? When I use the move_to(player_shape,
player_x*10, player_y*10), then the player just stays in the same
place. This too I expect, since by using move_to, I am not calling new
player_x and player_y coordinates.
>> if '8' in keys:
>> move_to(player_shape,player_x*10 ,player_y*10 + 10)
>> player_y = player_y + 1
>> if player_y > 47:
>> player_y = player_y -1
> 'if' statements don't have to have an 'else' clause.
> is just a waste of 2 lines. 'pass' does nothing, and since the 'else'
> is not required, you may as well leave it off.
I thought so too. Part of the problem I had with testing my code was
that I was using the PythonWin editor that comes with ActivePython.
Often the PythonWin editor would crash and I wasn't always sure if it
was because of my code, or because of the editor itself. It somehow
seemed that when I had the else: pass in the code, the editor behaved
better. I have since then started to use IDLE which works much better.
Thank you for pointing this out BTW. It takes some of the guess work
> This big block of movement code can be shortened into a few lines.
> I am not sure how much python you know, so if any of this doesn't make
> sense, let me know.
I am just a newbie in Python. I like the way you were able to think
about the code to make the code much more succinct. I will need to
learn a bit more before I understand it exactly. For now, I will try to
stick with my long, ugly, inefficient code, that I have puzzled together
and understand. Your example has not gone wasted however, it will be
used later when I am more familiar with Python and try to improve my code.
> Also, I just realized that you're using a while loop inside of your
> move_player and move_robots function.
> But you only call these functions if you KNOW that a movement key was
> Basically, this means that one of your 'if' conditions will ALWAYS be
> true inside of your while: loops, and you'll break out of it.
> The only reason why you might want this is that it would immediately
> exit as soon as it finds the first key that was pressed, but the
> same thing could be performed using an if-elif chain. But I doubt you
> want this to happen.
I will experiment with the if statements there. Is it better to use
if-elif chain over the while loop when both can work?
> Also there are other problems - eg. your keys is assigned to the keys
> that were currently pressed, so if during the time.sleep(0.5) I might
> press and then release a key, and it would be lost in your code.
Yes, I see this when I run the code. Unfortunately, I don't know how
else to do it since it is the only way that they show in the Livewires
exercise. I am OK it being imperfect for now.
> The code with the changes I mentioned included is attached to this
> Also, note that I didn't test this code ( I don't have livewires
> installed) so if any of it doesn't work, let me know.
I ran the code that you had included, thank you for this. It did
produce the player and the robot on the grid, but the keyboard commands
did not work. I wasn't entire sure why, but I thought I would let you know.
Thanks again for your help. If you have suggestions on the 't' key,
please share them. This seems to be the one issue preventing me from
More information about the Tutor