Possible bug

[dx876234]

When I run a waypoint file it gives me a message about which waypoint is closest and executes it before moving on to next in file as expected.

Loaded waypoint path tt.xml
No return path with default naming tt_return.xml found.
We use the normal waypoint path tt.xml now.
Waypoint #2 is closer then #1. Hence we start with waypoint #2.
Moving to waypoint #2, (65, 60)
WP 2
Moving to waypoint #3, (-47, 62)
WP 3
Moving to waypoint #4, (-51, 13)
WP 4
Moving to waypoint #1, (10, 11)
The game client did not crash.
3:25pm - Script forcibly terminated.

But, if I set reverse execution in onload section the same message gets written and it skips two waypoints before executing.

Loaded waypoint path tt.xml
No return path with default naming tt_return.xml found.
We use the normal waypoint path tt.xml now.
Waypoint #2 is closer then #1. Hence we start with waypoint #2.
Moving to waypoint #4, (-51, 13)
WP 4
Moving to waypoint #3, (-47, 62)
WP 3
Moving to waypoint #2, (65, 60)
The game client did not crash.
3:23pm - Script forcibly terminated.

In this last execution I expected the execution order to be 2, 1, 4, 3...

The waypoint file I tested with is as below, just a simple square in house:

Code: Select all

<?xml version="1.0" encoding="utf-8"?><waypoints>
	<onLoad>
		__WPL:setDirection(WPT_BACKWARD)  -- With or without this one in tests
	</onLoad>
	
	<!-- #  1 --><waypoint x="10" z="11" y="0">print("WP 1")</waypoint>
	<!-- #  2 --><waypoint x="65" z="60" y="0">print("WP 2")</waypoint>
	<!-- #  3 --><waypoint x="-47" z="62" y="0">print("WP 3")</waypoint>
	<!-- #  4 --><waypoint x="-51" z="13" y="0">print("WP 4")</waypoint>
</waypoints>

I'm not sure if this is as designed or a bug?

Best regards
DX

[Vengefulmilk]

I think the problem is that you're setting the bot up to fail by using almost equidistant rectangles. Everything i've ever seen is in lines.

[dx876234]

Na, this is just a small waypoint where I've isolated the bug - I seen this issue in big waypoints where points are way apart.

-dx

[rock5]

The function is working the way it's supposed to. The problem you are having is because you are using it in the onload.

Usually, if you change direction at a waypoint, this is what happens
1. You arrive at the waypoint, eg. wp #2.
2. Before it executes the code in the waypoint it sets the next waypoint it's going to go to, in this case wp #3.
3. When you change direction, because you are already at wp#2, instead of going to 3 you want to go to 1.

See, it has to minus 2 from the current 'next' waypoint.

This causes a problem in the onload. There is probably more than one way to deal with this. The easiest I can think of is just to re-set the next waypoint after the reverse.

Code: Select all

__WPL:setWaypointIndex(__WPL:getNearestWaypoint(player.X,player.Z,playter.Y))

[dx876234]

Great, thx Rock

-dx

P.S. Works as a charm with the re-set the next waypoint code.