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, >> 10*robot_y,10*robot_x+10,10*robot_y+10) >> def move_player(): >> while 1: >> global player_x >> global player_y >> if 't' in keys: >> place_player() >> break >> > 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 >> else: >> pass >> > 'if' statements don't have to have an 'else' clause. > else: > pass > 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 out :-). >> >> > 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 > pressed. > 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 > e-mail. > 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 going forward. Tonu _______________________________________________ Tutor maillist - Tutor@python.org http://mail.python.org/mailman/listinfo/tutor
