SCROLLING MAP TO PLAYER [VX ACE]
Posts
Pages:
1
So I've hit on a bit of a problem in VX Ace. I've been using scroll map a bit and for various reasons I'm not sure where the scrolling will take me. But I want the screen to go back to the player. Is there any way to scroll back the map to the player?
You can use Galv's Cam Controls, it has the following options:
Besides smooth cam slide effect.
It can focus on an event, scroll to a coordinate, and also return to player.
https://galvs-scripts.com/galvs-camera-control/
Besides smooth cam slide effect.
It can focus on an event, scroll to a coordinate, and also return to player.
https://galvs-scripts.com/galvs-camera-control/
I was thinking variables. You can keep track of the x / y / map id of the player. But I'm not sure how to get the map to scroll back to those variables. You could do a transfer event, fade none, designation with variables. Just set common event that is parallel process to keep track of player.
I guess scripts have to be the way to go.
Transfer works, but it's not very smooth.
Thanks for the help!
Edit: Aw shit that script only works with default screen size...
Transfer works, but it's not very smooth.
Thanks for the help!
Edit: Aw shit that script only works with default screen size...
Strange, I've used it on different screen resolution and it works fine for me.
Are you by chance using any script that alters maps in some ways, like a zoom script etc.?
Are you by chance using any script that alters maps in some ways, like a zoom script etc.?
author=Kaneshon
Strange, I've used it on different screen resolution and it works fine for me.
Are you by chance using any script that alters maps in some ways, like a zoom script etc.?
Resolution script?
This line should do:
$game_map.set_display_pos($game_player.x - $game_player.center_x, $game_player.y - $game_player.center_y)
Credit Galv, I stole it from his script.
It says at the top of the page that it only works for the default resolution, and after playing around with it a bit, it's very buggy in 640x480 resolution. It seems to spazz out and move back and forth sometimes. Not sure I would want to take a chance with something that doesn't always work.
@Cap_H
That's neat. Although it doesn't scroll, sadly. I might use that if nobody has a better suggestion.
@Cap_H
That's neat. Although it doesn't scroll, sadly. I might use that if nobody has a better suggestion.
Oh, I skipped that, while reading. You need to add speed somehow. I'm not any good with coding.
Or maybe try variables. Every move can change it and that branches camera moves, so they remember the path. If the camera goes left and then right it will add 1 and then subtract it. You should need two variables for this and its probably unnecessary.
Or maybe try variables. Every move can change it and that branches camera moves, so they remember the path. If the camera goes left and then right it will add 1 and then subtract it. You should need two variables for this and its probably unnecessary.
Yeah I figured that too, there's a problem with using variables though. If you hit on the edge of the map, the screen won't scroll even though you are adding to the variable, and there's no way to check if you're at the edge of the map (that I know of), so when you're scrolling back again it won't go exactly the same.
The way Game_Interpreter does the "scroll map" functionality...
...makes me think that "$game_map.start_scroll" might be the thing to use, if the difference between position of the camera, and the position of the player is known. The position of the camera might be obtained from the functions $game_map.display_x and $game_map.display_y. My guess is $game_player.x and $game_player.y would be how the position of the player would be ascertained.
Anyway, going by the inputs of the event-command, the first parameter is the direction the camera moves in, probably re-formatted as 2, 4, 6, 8 to translate as down, left, right, up respectfully. The second parameter is the distance, in tiles, the camera moves. The third parameter is the speed of the scroll, where a 1 would indicate "8x slower than normal" and a 6 would indicate "4x faster than normal".
To be completely fair, I haven't tested any of this. However, the theory is that there would be two calls to $game_map.start_scroll: one for the x-coordinate, and another for the y-coordinate. I don't know if passing a negative value for how much the camera would move in a given direction would throw an exception, but, my gut tells me that it would. Though, I would try it anyway, just to see if it would work, because if it does, it will make life so much easier!
def command_204 return if $game_party.in_battle Fiber.yield while $game_map.scrolling? $game_map.start_scroll(@params[0], @params[1], @params[2]) end
...makes me think that "$game_map.start_scroll" might be the thing to use, if the difference between position of the camera, and the position of the player is known. The position of the camera might be obtained from the functions $game_map.display_x and $game_map.display_y. My guess is $game_player.x and $game_player.y would be how the position of the player would be ascertained.
Anyway, going by the inputs of the event-command, the first parameter is the direction the camera moves in, probably re-formatted as 2, 4, 6, 8 to translate as down, left, right, up respectfully. The second parameter is the distance, in tiles, the camera moves. The third parameter is the speed of the scroll, where a 1 would indicate "8x slower than normal" and a 6 would indicate "4x faster than normal".
To be completely fair, I haven't tested any of this. However, the theory is that there would be two calls to $game_map.start_scroll: one for the x-coordinate, and another for the y-coordinate. I don't know if passing a negative value for how much the camera would move in a given direction would throw an exception, but, my gut tells me that it would. Though, I would try it anyway, just to see if it would work, because if it does, it will make life so much easier!
Nice find Marrend. I tried it out and after lots of fiddling and problems I managed to get it to work. The most annoying thing was probably that the camera variable isn't the same as the players map position, so you need to add 9.5 to the variable to get them to match up. Here's what I managed to cook up, note that it only deals with the X plane, because that's all I needed. You could easily make it work with both X and Y though, if you wanted. This seems to work perfectly, but if anyone can spot an error feel free to point it out. Thanks for the help!


Pages:
1

















