RMRK is retiring.
Registration is disabled. The site will remain online, but eventually become a read-only archive. More information.

RMRK.net has nothing to do with Blockchains, Cryptocurrency or NFTs. We have been around since the early 2000s, but there is a new group using the RMRK name that deals with those things. We have nothing to do with them.
NFTs are a scam, and if somebody is trying to persuade you to buy or invest in crypto/blockchain/NFT content, please turn them down and save your money. See this video for more information.
[VXA] Script Repair/Improvement

0 Members and 1 Guest are viewing this topic.

**
Rep:
Level 73
Impossibre!
Participant - GIAW 11
Hey all you scripters! I am in need of assistance!

This script: "Pathfinding, by cozziekuns" is a great script, but it has a rough edge that needs buffed. For some reason, the script doesn't recalculate when you call for the same destination a second time. For instance, I go into the movement script call and type "find_path(7,7)." The script says "Hey, that's up 3 and right 2 from here" and then when I tell it to go to 7,7 again, it just goes up 3 and right 2 again...

It seems like it would be a simple fix, but I know none Ruby. Please help?

*
*crack*
Rep:
Level 64
2012 Best Newbie2012 Most Unsung MemberFor frequently finding and reporting spam and spam bots
Umm, I don't see what the issue is.
The idea is to find the quickest path, so it will naturally do the same move route if it's the quickest.
All of my scripts are totally free to use for commercial use. You don't need to ask me for permission. I'm too lazy to update every single script post I ever made with this addendum. So ignore whatever "rule" I posted there. :)

All scripts can be found at: https://pastebin.com/u/diamondandplatinum3

*
Rep:
Level 82
It's based on a search algorithm (essentially a rule or set of rules) that finds the fastest way from A to B and moves the character in that direction. If A and B are the same, the result will always be the same.

Let me try to determine, though, what might be the problem.

Let's assume point A is at (5, 5) and B is at (7, 7). Your goal is to move from A to B. That's +2 in the x, and +2 in the y. From the first time you call, it determines you need to move (+2, +2), right? And that's what happens. Are you then calling it again, from another position that's not (5, 5) and it's going (+2, +2), rather than calculating from the new (x, y) to (7, 7)? For example, you are calling it at (2, 2) and it's going to (4, 4), and not (7, 7) like expected?

That's the only thing I can think of that would be a bug. If you are calling it again from (5, 5), then it's working as intended. But if you go from (5, 5) to (7, 7) on the first call, then the second call from (7, 7) makes it go to (9, 9) instead of staying still (since it's already there), then it's a problem.
(Why do I always feel like it's the end of the world and I'm the last man standing?)

**
Rep:
Level 73
Impossibre!
Participant - GIAW 11
Yes, Marc, that is the precise problem. I'm trying to make an NPC go back to its post after moving to random spots... so yeah.

*
Rep:
Level 82
So, I've managed to recreate this problem myself, and that is useful isn't it. Heh. I'll give it a look through when I can and see if I can identify the problem. I know the original version had an issue with recalculating paths but I believe that was only in the case the path was interrupted during the event's movement (say you stood in the way - it was unable to recalculate where to go and would just stop moving). This is a different problem, and I don't know if it was in the original. If it is, then it's not just an oversight during porting, so I'll have to test that out first. Otherwise, MA needs to know about it too, so he can fix the VX version.

Edit: Just an quick edit. This problem does also occur on the VX version. However, there are some inherent flaws in the way it works, some of which haven't been fixed as of version 2.0 of the VX version, and these flaws naturally carried into the port to VXA. Rather than working on a fix, I'm going to rewrite the script from scratch using both my own knowledge of A* search algorithms and the original scripts as basis including the flaws. This means it might take a bit longer to get a fix for it, what with other things I have to do.

I do know what the problem is, though.
« Last Edit: December 05, 2012, 01:31:40 PM by LoganF »
(Why do I always feel like it's the end of the world and I'm the last man standing?)

**
Rep:
Level 73
Impossibre!
Participant - GIAW 11
That is awesome! Thanks for keeping me posted.
« Last Edit: December 12, 2012, 01:50:16 AM by Solar Eclipse »

**
Rep:
Level 73
Impossibre!
Participant - GIAW 11
Hey! Sorry to double post and whatnot. How's the script comin', Logan?

*****
Rep:
Level 84
This text is way too personal.
Bronze - GIAW 11 (Hard)Silver - GIAW Halloween
The problem you're experiencing was, as Logan stated, a problem present in MA's version as well. The pathfinding script, when find_path is used, recycles the move route coordinates created in the first iteration of the find_path script rather than creating another path each iteration. When a path is forced via force_path, the pathfinding script creates a new move route rather than adding additional move commands into the original move route. find_path was never meant to be called multiple times by the same event, and when I selfishly ported it to VXA I only intended to use force_path anyways. Fixing find_path is slightly annoying because of how RPG Maker handles move_routes that move other characters.

A workaround until Logan or I fix the script is possible, but slightly complicated. You can use the force_path method instead via a regular script call (not in your move_route).

@>Script: $game_map.events[event_id].force_path(x, y)
@>

That would force the event to recalculate the path each time.

**
Rep:
Level 73
Impossibre!
Participant - GIAW 11
Sweet! This should work very well until a real fix comes around. Thanks!