Closed termx88 closed 2 years ago
Closing this for now because currently it inputs keys in menu. And I want to add some other changes.
@termx88 why did you close this?
I fixed the inputted keys in menus already, but I mostly tested on crystal and missed that red/blue/yellow has a different turning speed so it messes up the movement. And it seems like the turn takes about as much or more time than walk so I have to find another way to make the walking work on it. So basically I opened the pull prematurely.
@termx88 thanks for the info. Perhaps it could be just enabled when playing crystal, unless you also plan to make it work for red/blue
I added different movement timers for yellow and it gets pretty close. But I've also made that the walk can be repeated if needed, so it should solve problems of something going wrong. The repeat also solves NPCs getting in the way or walking away, so it's necessary anyway. I'll reopen when I clean up the code a bit and do some more testing.
From the initial pull request date, I remade large portions of the script, solving a lot of edge cases. And added walking to camera. Also this now uses version 2.4 as a base. For the full description of the pull, see the edited pull description.
Key bind for walking to camera is "w". Key bind for walking to the selected item is "i". Walking can be stopped by pressing a controller key. As in A, B, Select, Start, L, R or a direction key. When walking to item, it will try activating the destination when it can't be passed. Such as an NPC or signpost. Will activate NPC's behind counters. For example, nurse in pokemon center and clerk in mart. Deals with HM tiles appropriately by type. In Red/Blue/Yellow, HM tiles have to be activated from the pokemon selection menu, so HM tiles aren't activated.
Some more detailed/technical notes on how it works: Presses directional key and waits for walk to finish. Repeats until reached destination. Determines, if reached destination by checking if on map, or on a different map, or standing at coordinates. Otherwise, if tried walking into destination twice, while standing next to it. Then walk has ended and player is facing destination. Twice, because player might have not been facing destination at first, so it's possible to only turn without walking onto it. Gold/Silver/Crystal has check, if player is on bike. And uses different frame values when on bike. Frame values are kept in rby.lua and gsc.lua at top of file. Can be overwritten for individual games, by placing them in game's main.lua file. The way different HM tiles are treated: Presses A on bushes, when entering water, whirlpool. Does not press A when going up a waterfall, because there's no way to make sure player is actually facing it. Does go down waterfalls. It still doesn't find path through boulders, because the pathfinding doesn't find path through them.
Changes to original script that are necessary: Edited functions find_path_to and pathfind to return path. And relocated the reading part into a new function called read_pathfind. Also renamed speak_path to read_path. on_map function changed that now, most menus return false, So doesn't try walking in them. Also in Gold/Silver/Crystal added check of some screen transitions. This solves script going crazy, when trying to find path at specific frame, when entering battle while swimming. clean_path's HM command formatting moved into a function. Which in the walk script, is used to get direction from HM commands.
New messages, which need translating: "Standing on destination", "Camera on player", "Walk end.", "On way to", "Camera". The "On way to" message reads in game as "On way to ash's house" or "On way to camera".
Changes to original script that are slightly outside the scope of this: I'll remove/adjust them, if requested. Made function handle_user_actions filter out num lock, caps lock and scroll lock. Readme Changes. Added new keys. Made item a new section, while making minor terminology standardization adjustments. Also removed comment about making sure num lock is off. Fixed typos. All instances of inpassible and passible, renamed to impassable and passable respectfully. Removed unused height and width from find_path_to.
Problems of the script: In Yellow will walk into player's pikachu before activating it. When pikachu is standing on an entrance, this results in walking into a building. Can't filter out destination by sprite, because there are non-player pikachu that are impassable. Filtered out when camera is beyond a map connection. Otherwise would result in a crash. Could make camera walk extend beyond map connections, but not more than by one tile. At least without removing or redoing check, if player entered a new map. Because frame values are tweaked for individual games. In cases where walking values differ, such as crystal clear's bike, the walking is sub optimal, but does still work. on_map function's changes don't perfectly filter out menus, because in Red/Blue/Yellow's pokedex data screen, area map and town map returns true. Which isn't too much of a problem because the worst that can happen is exiting out of that menu, otherwise might scroll through the map location or print "no path" instead of "not on a map". In Gold/Silver/Crystal pokedex, maps, and PKHeX badges screen. This leads to worse possible consequences. As in it's possible to accidentally fly to a semi random location. Or may change selection in fly map or pokedex.
It might be possible to make the on_map better. By using screen.tile_lines, to see if there's any text. Filtering out when map's name is displayed, by checking if second line matches MAPNAME_PATTERN. It would almost perfectly filter out menus, with the exception of some map screens without text. But I found that Elm's lab has tiles that make text appear in tile_lines. The text is always the same, though in different locations, based on where the object is on screen. So it would be possible to filter it out. But I don't know if there are other locations/objects that do that. Or if it was used as an individual testing location?
Another problem in Crystal which I think might be from the vba-rr front. Is some NPC's gain an impassable tile in front of them. The script might try walking to them till it times out. I think it only happened when I was cheating, specifically adding badges I think? I didn't thoroughly test it though.