Start waypoint file at its mid...

[pumbatoo]

Is there any way to start a waypoint file not(!) from its beginning?
I want to start the waypoint file after little changes from a point at the mid of the file...

thanks for response

p.s: I search a way to start the file from its mid either by mm console or from within another waypoint file.

[botje]

Code: Select all

__WPL:setWaypointIndex(1) -- or whatever point you want it to go to first.

Botje

[pumbatoo]

thank you for the fast response, botje!
and sry, don't know how I could overlook it...

[botje]

your welcome mate

Botje

[pumbatoo]

Sorry, still have problems there.
When I start a new bot.lua instance and choice my waypoint file, it is not jumping to #19 as I expect
In the waypoint file I prepared to jump to my tagged waypoint index:

Code: Select all

<waypoints type="RUN">
	<onLoad>
		__WPL:setWaypointIndex(__WPL:findWaypointTag("devStep"));
	</onLoad>
	<!-- #  1 --><waypoint x="-x" z="-z">	</waypoint>
	...
	<!-- # 19 --><waypoint x="-x2" z="-z2" tag="devStep">
</waypoints>

The MM console says:

Code: Select all

Loaded waypoint path Tester.xml
Waypoint #19 is closer then #1. Hence we start with waypoint #19.
No return path with default naming Tester_return.xml found.
We use the normal waypoint path Tester.xml now.
Moving to waypoint #16, (..., ...)
Moving to waypoint #17, (...,...)

What's the problem there? I tried with waypoint type RUN and NORMAL, no difference.

[rock5]

Are you sure that the waypoint that says "<!-- # 19 -->" isn't actually your 16th waypoint? The only way to be sure which waypoint the mm window is talking about is to look at the coordinates x= xxxx, y=yyyy and match them to the ones in the waypoiont file.

[pumbatoo]

I just double checked again.

First I checked the numbering in my waypoint file - it seems to be correct - so the #19 is the 19th waypoint. Second, I checked the waypoints mm is walking through agains the coordinates in my waypoint file. But for any reasons he don't starts at my tagged waypoint.

I recognized that the bot is starting at the nearest waypoint from its current position and ignores my instruction to start at waypoint #19.

[rock5]

This was an issue that was brought up before and I'm pretty sure it was setup to work but I just tested it and it doesn't work. I'll have a look at it.

[rock5]

The way I'm looking to set it up is, first it loads the profile, then it loads the waypoint file, then it runs the profile onload and lastly it runs the waypoint onload. I think that's right? We want the waypoint onload settings to override any profile onload settings.

[rock5]

Committed to revision 619. Try it now. It should work.

[pumbatoo]

very nice rock5, thank you for the fast response and committing.
It's now working like expecting.

[pumbatoo]

Seems like there is an problem in r619.
The onLoad event of the waypoint file will be loaded after the profile one - like the solution should work.

But since r619 the onLoad event will not be executed after continue a waypoint file by loading (loadPaths) another one:

Code: Select all

waypoint_file1.xml
<waypoints>
	<onLoad>
		cprintf(cli.red, "waypoint_file1 successfully loaded!\n");
	</onLoad>
	<waypoint x="-1234" z="-1234">loadPaths(waypoint_file2);</waypoint>
</waypoints>

Code: Select all

waypoint_file2.xml
<waypoints>
	<onLoad>
		cprintf(cli.red, "waypoint_file2 successfully loaded!\n");
	</onLoad>
	<waypoint x="-1234" z="-1234">loadPaths(waypoint_file1);</waypoint>
</waypoints>

The message "waypoint_file1 successfully loaded!" will be shown, but there will be no output from the second file.

I localized the problem to the changes in file 'waypointlist.lua' of the commit.

[rock5]

Good point. I guess what we want is the onload to run when loadPaths is run, as it did before, but make an exception for when starting the bot. In that case it should wait until after the profile onload has run.

How about when changing character? Do we need to make exceptions there too? I don't have much experience with that. What do we expect when changing character?

[rock5]

Should be fixed in latest revision.