Reply to Re: Taking Dink x and y coordinates
If you don't have an account, just leave the password field blank.
The screen script executes before the sprites are created, so it makes sense because Dink has't been placed on the new screen yet.
That's what I thought too initially. However as Dink has sprite number 1, I assumed that Dink was the first to be placed on the new screen. So attaching the script to another sprite (which has to have a sprite number above 1) would solve the problem. However attaching it to another sprite does the exact same thing as attaching it to the screen. So it isn't that straightforward from my point of view...
Anyway, the thing that bothers me the most is what if Dink enters via the left near the bottom, or via the bottom near the left? How do you know where he came then?
I placed a small patch of hardness in every corner. It might not be the prettiest solution, but it does the trick... That's also where my small tolerance for error came from.
You can check sp_x/y before and after a wait to deal with this and you won't need the freeze. A big change in y means Dink came from the bottom, a big change in x means Dink came from the left. Much more elegant solution.
Indeed
Going to use that.
EDIT: Also, I can't use a workaround such as storing the previous value for &player_map into a global as I do screen changes without physically changing screens, so the value for &player_map would be highly deceiving... So unfortunately those hardness patches are there to stay.
That's what I thought too initially. However as Dink has sprite number 1, I assumed that Dink was the first to be placed on the new screen. So attaching the script to another sprite (which has to have a sprite number above 1) would solve the problem. However attaching it to another sprite does the exact same thing as attaching it to the screen. So it isn't that straightforward from my point of view...
Anyway, the thing that bothers me the most is what if Dink enters via the left near the bottom, or via the bottom near the left? How do you know where he came then?
I placed a small patch of hardness in every corner. It might not be the prettiest solution, but it does the trick... That's also where my small tolerance for error came from.
You can check sp_x/y before and after a wait to deal with this and you won't need the freeze. A big change in y means Dink came from the bottom, a big change in x means Dink came from the left. Much more elegant solution.
Indeed
Going to use that.
EDIT: Also, I can't use a workaround such as storing the previous value for &player_map into a global as I do screen changes without physically changing screens, so the value for &player_map would be highly deceiving... So unfortunately those hardness patches are there to stay.
