ID:118285
 Sep 8 2011, 9:35 am (Edited on Sep 10 2011, 9:51 am)
|
|||||||||||||
Resolved
| |||||||||||||
walk_to() and step_to() seem to be non-functional for pixel movement. This works fine as long as the mob's step_size is default. As soon as I change the step_size, nothing will happen. If I replace walk_to() with walk_towards(), then it will work fine (just a little dumber).
| |||||||||||||
|
Sep 8 2011, 12:52 pm
|
|
Hiro the Dragon King
 |
It seems that the issue is when two pixel movement enabled oject are used as arguments. It works fine if both are tile based orif either is tile based and the other is pixel based, but not when both are tile based.
|
I said demo, not snippet. This snippet isn't enough alone to plug into a debug project because it makes assumptions about other vars in the world and at the very least I'd have to know what to plug into it. The only time a snippet is adequate to reproduce a bug is when it exists in isolation or the same conditions in its environment are easily recreated.
Every test I have run on walk_to() to try to reproduce your issue has failed. I tried walking from one pixel mover to another. I tried this with changing my mob's step_size from its default (4). I tried with changing the speed by adding an argument to walk_to() (e.g., walk_to(usrc,src,0,0,speed). In every case I was successful. I also verified that the distance argument (which is still in tiles) still operates correctly. | |
I can't isolate it from our source. It doesnn't happen in a test project even using the relevant bits from the source. Something in this source is triggering it, but I haven't the slightest clue what it could be, considering that the snippet below doesn't function between two movables with step_size defined.
mob/verb/PM() | |
Quick test: Put in some debugging code to print out the bounds, loc and step_x/y, and step_size of src, and do the same for m. Also, put debugging info into Move(). If you like you can always set a flag that only turns on once you've called the walk routine.
atom/movable Then before walk_to(), call DebugPos(usr), m.DebugPos(usr), and set src.debugmove = usr. This should at least give you an idea what the conditions are for the move and whether it's being attempted. | |
Move() is not being attempted. walk_to() seems to just fail. On that note, src << step_to(src,m) outputs 0 while src << walk_to(src,m) won't compile, giving a "missing expression" error.
As for DebugPos(), I'll write out two lines, but any more than that and I'll have to give you a file because I'm using a phone to post. If I've missed any part of the debug, let me know as my phone cuts off the code section at step_size. HiroTDK loc: 193:5,10:12 | bounds: 8,8 ; 9,11 | speed: 6 stalagmite loc: 194:0,10:0 | bounds: 8,8 ; 16,16 | speed: 32 | |
I really need a test case for this. If you can't distill this down to a demo, you need to make a copy of your source and set it up in such a way where I can login and immediately see the issue. Any instructions included should be highly detailed and clear. Zip up the whole shebang and send it to me at [email protected], or you can upload it as a visible (but not listed) file in your member space and send me the link.
| |
Unfortunately, the whole shebang is large. Bigger than my member's space, I think. If I can, I'll e-mail it to you. If not, I'll have the project leader give you access to the DropBox and I'll put it in there.
| |
Okay. Use whatever method works best. Just make sure I know how to get to the place where I can see the bug, and that I have full instructions on how to trigger it.
| |