WoW-Pro Guides

WoW-Pro Guides

3M Downloads

A step type that completes when the coordinate is reached

CodingDino opened this issue ยท 21 comments

commented

From Cladhaire (TomTom's author)

Originally posted by Jiyambi

Forgive me if this has been answered elsewhere.

My addon makes extensive use of TomTom. I was wondering if there is any way for my addon to
know when a waypoint is checked off in TomTom. I know I can have my addon check the
character's position in relation to the coordinate, but I'd prefer not to duplicate something TomTom
already does if I don't have to.

Basically, with my guide addon, I would like to be able to automatically complete a step when a
character arrives at a waypoint.

Thanks again for you wonderful addon, Cladhaire!

You can supply a callback table with a distance callback and the callback function will be called when the player is within x yards of the waypoint. Unfortunately I don't think there is an easy way right now to get the default callbacks (minimap_onclick, minimap_tooltip_show, minimap_tooltip_update, the same for world and the clear and arrival distance callbacks) in addition to your own custom ones. You'd need to provide implementations for the prior. If you're not using minimap/world icons, then that's easy.

Give it a shot and let me know what you think.

commented

I'm honestly not quite sure how to implement this. Oh my wonderful, more experienced addon authors - any recommendations?

commented

Okay, that makes a bit clearer, thanks Silvann. I'll look into this soon, unless you want to :)

Essentially I'd like to add another step type that completes once the last set of coordinates is reached, and/or add that on to the R step type. (if they get to the named zone first, then auto-complete then, otherwise auto-complete when they reach the coordinate).

commented

Hmm, let me see if I get... so the step (R or another one) will contain a set of coordinates [(x1,y1),(x2,y2),etc], that should be walked by the player in that order. Each coordinate is shown by TomTom in the order, as the player goes through them. When the last coordinate in the set is reached, the step is completed. Is that it?

commented

Yes indeed!

Note that in my current implementation I feed the coordinates to TomTom in reverse order, since it uses the coord most recently added as the current waypoint.

commented

Yeah. If you check the TomTom:AddZWaypoint function in TomTom.lua (which is the function called by WoWPro), you'll see there's an argument called custom_callbacks. This is a set (table) of functions, that can defined by us (WoWPro), which are called by TomTom when certain events happen. One of these events is what we want: "a player is within from the waypoint", where distance in our case is a small value, close to the waypoint.

If no custom_callbacks is provided when the function TomTom:AddZWaypoint is called, which is what's happening now in WoWPro_Mapping.lua, then TomTom uses its default functions instead.

But if we do pass the custom_callbacks functions, since it's a single packed table, we have to provide all of them, including the ones for all the other events we ar enot really interested in (basically tooltips in the maps and stuff). But we can just reproduce what their default functions do in our code. What we cant do is call these default functions directly from TomTom.

commented

Ok, I'll take care of this.

commented

<3

Thanks a ton!

commented

Almost done, I just need my home internet connection back so I can test and commit and such. :/

It's using the R action, because I thought it made more sense, instead of creating another. It works with any number of coordinates, including a single one. So the R action now will not be auto-completed with zone/subzone when at least one coordinate is provided, but only when the player actually get near the waypoint (or at the final waypoint, if it's more than one).

One more thing: the way I'm implementing is... if more than one coordinate is given, the player should walk all the waypoints in the order given until the final one, in order to get the completed step. Because I figured the multi-walking could be used to lead the player into locations that are at diferent floor levels, like a cave. If the step completes whenever he gets to the final waypoint, regardless of the previous ones, them he could unexpectedly get the step completed while walking above or below the point, like on his way to the previous waypoint (p. ex. the cave entrance).

For another hand, if the player is already closer to the final waypoint, he wouldnt be too happy about going the other way around first.

So, thoughts?

commented

Well, first off, I'm wondering if it would be possible to introduce a toggle tag for the behavior of the run step completion. Basically, it will normally complete when you get to that area, but if you put in an tag (maybe |CC| for coordinate completion? I have no idea) it completes based on coordinates, instead. Dunno if that's do-able.

For the second one - maybe also use some sort of toggle? Though maybe we'd be getting ridiculous at that point :D Anyone else have any thoughts?

commented

Yeah, I did what you suggested. But I need a few more days to test the last changes and to commit.

commented

Thanks a ton Silvann :) You're really being a HUGE help!

commented

Is this still coming? I wanna use this.

It seems to me the only way to avoid running into the problem of being sent around the long way by mistake is for the user to follow the guide EXACTLY. Of course, this has always really been the case, as in the current (live) edition, I often find it's a little insensible for me to follow some steps in a particular order because I usually am hearthed at Dal, no matter what. This means sometimes I am told to go around one way, but am running past turn-ins or mobs I need and will be coming back to eventually, because I end up hearthing to a different location than the guide writer assumed I would be. Not a huge ordeal, and I usually find it's best to take the time to get back on track with the guide than to try to work against the flow. In other words, you gotta use the guide as intended.

Finally, it seems like this makes a good point for guide writers. If you're going to use this, it's probably best to use fewer, rather than more waypoints, and it is always important to keep in mind the potentiality for finalizing a step if running past the final coordinate, so you may need to use separate steps. Separate steps may also be useful for long trips.

commented

I think Silvann has been away for a while on a trip of some sort. Hopefully we will see the fruits of his/her labor soon, since I'm still not really sure how to go about doing this.

I agree that in general less is more. I usually try to include only one waypoint unless it seems really logical to give a bit more direction - for example, in a cave complex where they would almost certainly need to go in a different direction first. Even then it can lead to complications, so multiple waypoints need to be used sparingly.

However, I wouldn't encourage using duplicate steps (if that's what you are thinking). It can really muddy things up and confuse the reader if they use a multiple step view, or look at the current guide pane. If you are implying using multiple steps that are different (say a run step followed by a quest completion step, for example) then that's a different story.

Also keep in mind that I'm very much in favor of making the coordinate based auto-completion a toggle rather than an automatic thing. So it should only happen if the guide author intends it to.

commented

I agree the toggle is crucial.

My thoughts about multiple steps would be like this: let's say in a cave you wanna guide the user around, and there are mobs on multiple z's at the same x,y. You don't want to complete the step halfway through if you're walking the user in a spiral. So if you have to put the same x,y in more than once, then it seems logical to use a second R step rather than say, a single R step with multiple coords that would autocomplete before the user had reached the desired destination.

Please advise if there is a better way to do this! ty - you're the best!

commented

In this situation, I'd probably send them to the original area with a run step, then use a complete or partial complete step for the later steps with multiple coordinates, without the coordinate based autocomplete. If two waypoints are directly on top of one another, they will both clear, but honestly I think this happens rarely enough that it's not a concern, and will my above example you could still cover two levels - how often will there be three levels with mobs in the exact same place on every level all relating to a single step, which users must be directed to? I'd tentatively say never. I know the barrow den style caves are very up and down, but usually you just direct the user to one area and set them loose until the next step.

commented

I'm back, checking this again. :)

commented

Ok, I send a pull request. As soon as Jiyambi approves it, you can start testing it. For now, only the |CC| tag is implemented, which means it will autocomplete when reaching final destination, regardless of the previous waypoints. For the following waypoints in the given order option, it turns out a default TomTom function was overwriting mine, so I still have to think how to do this.

commented

Git is complaining that your edits will conflict with the current version. When I get some time (possibly tomorrow) I'll go through what you have and make sure nothing will break the current code, and things ready for testing. Thanks a ton for this, the following in a given order option is a bit lower priority, but the |CC| tag will be really nice. w00t! :)

commented

Yeah, there's probably some merge conflicts, since I had to alter some of your own line codes, so please check it out before accepting. I already found and corrected a minor issue, but I'll wait to change a bit more things before sending another pull request.

commented

Ok, implemented the |CS| tag, to autocomplete when arriving in the final waypoint, but player should follow the waypoints in the given order. I had to mess a bit with some TomTom options, but it should work well. Later on, I may propose changes to TomTom itself. Also, fixed some bugs. But I'll wait before pushing the changes to my forked version, to not overwhelm Jiyambi. ;)

commented

Should be in current version in the repository. Marking "resolved". Thanks Silvann!