I must tell you this story.

More than 2 years ago, when I was a player, I was far away hunting, at the entrance of captured stronghold. It's always a long walk to go there, but I like this place. Close to the double door there is this obelisk. Beside this obelisk has a nice story, when you examine it, I was thinking: "That would be so cool, if this obelisk would be a kind of waypoint, we can fast travel here." That was when the idea was born.

At that time I had only access to public data, so I tried to build a kind of waypoint with the limited example pool. Believe me it's much easier, if you have working code, you can look in and grap some lines, than to search every line by your own, studying c source code to get next syntax you need.

My dream was, to go to that obelisk and apply it to open a waypoint menu using our npc talk interface. I didn't thought, it would be that hard, to do this.

Our npc talk interface is limited mainly to npcs. Client is not sending good data back. So server gets the talk message and check the player target or pick a npc close to player to talk to.

We have some "hacks" in this talk mechanic for our /help system and for a /qlist command.

I also tried the idea from person using a magic ear on same spot like the waypoint. For sure this needed also a small "hack" so a "/talk /say hello" reached the ear.

So this was the state I reached more than 2 years ago. The obelisk you can apply once and the ear under listening, so this npc interface somehow worked with non npc's.

This was not my dream. My dream was to add one object with an apply event and a script behind poping up this nice npc interface with working linking.

Also at that point I had not the abilities and the rights to add the say hack on my own. And it was frustating. I had all this ideas, but not the abilities and the rights to make this working. And the only activ dev person had not the time, to code my 1k ideas for me. What a shame. 

Then it was petar pushing me and talking the whole day to person, that dolfo need the rights to commit things and need access to the non public data. And rtt standing for sure behind petar saying the same.

That was the day, when my real life ended. In this 2 years I stumbled in so many bugs, from the smallest to the biggest bugs. So my todo list was massiv and this waypoint idea shifted more and more outside my view.

Also each day talking with players, I got more requests or bug reports. And it is always time, so i needed to decide again and again, what I do next. Beside time it's also mind. Some days we are better in thinking, other days not.

But 2 weeks ago I decided to grap that old waypoint prototyp and try to make it running. It was a lot read in first. Try to understand how client and server communicate when using this npc interface. Testing and looking where I can go in. As I said the dream was to apply an item and then this npc interface pops up. I jumped in more walls I needed to climb first, like how to convert a string value to a uint32 value with validation, if value is in allowed range. Luckyly I have the world behind me. And google is very good in helping me find the web for things I search. So thanks to world and google. But on the other side world can be also stupid and do things unnecessary complicated. I spend several days till I deciced, write that "string to uint32" function on your own. World has bad or slow tools to convert string to unsigned types.

With my own function I was able to wrap my "hack" via talk interface to server.

Client sending

@count:message

this triggers the server now to parse the count and search on the player spot for this object. If this object has an apply event, server starts the script with the message as an apply event on this object.

Its the eqivalent to the normal talk, where server uses the player target or search for near npcs to talk to.

Sadly I need a small extra function for preparing this talk hack in my lua scripts. I have a small function adding "@count:" to the talk message. Atm I have not the time, the mind and the abilities to go in client and change client/server protocols for npc interface, launch a client update for windows clients and build a linux runable whatever packet.

So for now scripters need
local function prep_for_apply_talk(data)
   return "@" .. count .. ":".. data
end
on their buttons, links, selects to make the linking working on non npc objects.

Yesterday I was finally at the stage to make this all working. I spend the whole day, only searching for good spots for waypoints, adding this to maps, uploading all nessessary code to trunk, main and daiserv with additionally savety checkings.

I also added a new arch waypoint_player, and all maps use this, so we can change grafics or animations of waypoints in one file for all maps, if we want change this.

But after 2 weeks and 2 years and for sure 2 month and behind this again 2 weeks and 2 days to up and present this idea, I need a break.

My dream was. Apply this obelisk at captured stronghold close to the door and have a waypoint. This is done. I also added another waypoint in the mountain passage before old outpost. That was another dream to have a waypoint there. The other 15 waypoints I don't spoil. But they are all at usefully places, to make player traveling life easier.

Technically informations about this waypoint system.
It's self learning.
Atm server knows 17 waypoints.
If mapmaker want to add a new waypoint, he simply add an object with an apply event targeting the waypoint_apply.lua script.
First time a player applies this waypoint, server add this to his global list, beside adding it to this player list.
If mapper must move his waypoint to another spot or map, he can also do. Logic is updating map position changes for waypoints.
If mapper need to remove a waypoint, he need an admin or a sa removing this waypoint behind. Script has a sa remove dialog for that. Players don't get updated, they keep this old waypoint in their list, but when they try to warp there, it's a "poof" and the waypoint is deleted for this player.

With 17 waypoints we come closer to the limit of this npc interface. So at some point could be cool to have more sides in waypoint menu. Also a waypoint sort or a prioritization would be nice for players. Behind this adding a kind of grouping to the waypoint idea, could be also an interesting feature opening new tools for mapers, like building in waypoints only for their maps.

But that's something for in 2 weeks. 

Yeah I know. I also thought about this. But my primary goal was to make this apply object talk working somehow and then to finish my waypoint prototyp script. This apply object logic is not restricted to waypoints only. We can use npc interface with other objects independent from the player target.

Sure a grafical map behind looks cool, but I spend so much time now in finishing this logic and I had this functionally prototyp. Time and mind said me : "No, try to finish first your originally idea/prototyp."

We also have some difference in our view. My idea was not to use a /waypoint command and jump to a waypoint from whereever a player is. My view was more like a gate system, where players can travel from one waypoint to next. So they need to walk first to a waypoint and jump from there.

Next difference is, I build my idea as a self learning logic. There is no work anymore nessessary to add a new waypoint than to add a non blocked object on a map with mapmaker, give it a name, insert an apply event and link it to the lua script. Next time a player applies this new waypoint, logic has learned it.

I like dynamic and the less work to add waypoints. With a map behind someone need to adjust the button on this map each time we have changes. If its also in c code directly, there is no way for a mapmaker to link a new waypoint without help from a coder.

Next problem on this static map is, where to put waypoints not on this map, like Guildhall or Stonehaven? Or a waypoint deep in an underground map?

Behind this, when we plan map changes or add new map content and want to add there more waypoints, someone need to build a new static map. At this point all buttons need also a rework. There is a forum thread you are talking with myth about a lot of planned map changes. I know myth stopped on that, but the plan is still there.

So using a static map is the absolut opposite of my dynamic self learning idea, also when it looks better.

I want test your new interface at some point, but as you have said, its currently limited to buttons and text is coming from popups. I also don't know, if it can scroll down like npc interface can do. So without this scroll down, place to use is lesser than npc interface.

And for a good usage we need to add more code, so it can be targeted by lua script. I really spend more days working on this current idea, than i have fingers and toes on my body. I am lucky that waypoints are working now.

I don't want trade this self learning system, making "adding new waypoints" that simply against this static map logic, with always extra work behind for new waypoints.

If we can combine both ideas, this would be cool. But atm I see not a way to make a static generated map, self learning without a lot non automatized extra work?

Perhaps add a script, where mappers can add new waypoint buttons to this map? But as i said above, this static map is limited to the time, when it was generated and to the place when it comes to waypoints out of this map.

I can't say, what is a good use of your time. This is your life. Honestly atm I am a little drained. Need to find a restoration spell somewhere. My motivation is also in relation of actitvity from players and atm it looks like they all prefer to do other things with their life time. So I also slow down. This waypoint was a big load on my shoulders. As I said at start of this topic, I started this scripting in relation to waypoints over 2 years ago. And this unfinished waypoint idea was always a big todo on my list. With this waypoints done I could remove one of my oldest entries from my todo list. I don't think I want touch waypoints this year again, except behind cleaning and bug fixing.