createpath + getid + getpos together

[Bill D Cat]

I was messing around creating a waypoint for Yrvandis Hollows and was having to constantly open a second MM window to run rom/getid.lua to pick up the correct ID's to enter into the createpath prompts. Then it occurred to me that I could just combine the two into one file and save all the hassle. So here's my modified createpath.lua file that will display the output from the getid.lua function in the MM window title while createpath is running.

Enjoy!

[rock5]

I love it. I think I'll update it, as is.

[Bill D Cat]

Of course I couldn't just be satisfied with this one addition to Createpath. This update still has the getid output in the MM window title, but when you do not have your mouse over a reportable NPC or Object the window title will reflect the current player position.

[rock5]

Another good idea.

Of course I thought of getpos when you did your first version but I thought there wouldn't be enough room for the player coords and you don't really need it anyway because if you need to change the waypoint coords you have to stop createpath anyway before you can edit the file.

But I didn't think of alternating the display. Good idea. And it can be useful. For instance if you mark a waypoint and then realize you marked the wrong spot you could use the player coords to add a comment, using Num 0, to change it later. Or if you got sidetracked while creating a waypoint file, you can use the coords to find your place to continue. Or if you are creating a looping waypoint file and there aren't any good landmarks to show where you started you could use the coords. So all in all I'd say it is useful.

I think I might change the display a bit to make it more clear. It looks a bit too compact for me. Also for it to be useful like I said, when marking waypoints it needs to show the coords as well. At the moment it doesn't

Code: Select all

Recorded [#  1] WP, Continue to next. Press Num 3 to save and quit

There is probably not enough room to put the coordinates but I think "Continue to next" is not necessary. So I suggest something like.

Code: Select all

Recorded [#  1] WP, (-11899, 41823, 792) Press Num 3 to save and quit

[Bill D Cat]

I think that would be a good enhancement for it as well. Anything to make it more robust without completely overcrowding or complicating it would be nice. I'm all for having the coordinates displayed as it records the waypoints. That way you'd see the last recorded waypoint in the text area of the window, and your current coordinates in the title. Could help if you are trying to judge how far apart to space your waypoints as well.

[Bill D Cat]

I've made yet another enhancement to this utility. Now when you use the option to insert a Merchant, NPC or Object command into the current waypoint, it will use the ID in the command, and add the name as a comment. This should help the sharing of waypoints when used with different game languages.

Old style:

Code: Select all

player:target_NPC("Galis Faidley");

New style:

Code: Select all

player:target_NPC(120561); -- Galis Faidley

[rock5]

Good. If you hadn't thought of adding the comment, I would have.

[rock5]

Now I realized, when I added the coordinates to the printed lines again, that it does it for all actions which makes the lines too long. We really only need coordinates for the waypoints and harvest points. So I added in a check for that. It keeps the output neater.

[Bill D Cat]

I've added another set of fail safe enhancements for this utility. The save routine now checks for an existing file name and will prompt the user to overwrite it if necessary. It will also check to see if the user just pressed enter without entering a file name and will use "__unnamed" instead of nil. These changes would need to have two more entries added to each of the language files. I would use the Bing translator to attempt it, but it probably should be translated by someone who speaks the language.

Code: Select all

	[524] = "File save failed. Please verify the name and try again.\n",
	[525] = "File name already exists! Overwrite? [Y/N] > ",

Here's the modified code for the start of the save routine.

Code: Select all

function saveWaypoints(list)
    while (not file) do
		keyboardBufferClear();
		io.stdin:flush();
		cprintf(cli.green, language[500]);	-- What do you want to name your path
		tempname = io.stdin:read()
		if tempname ~= "" and tempname ~= nil then
			filename = getExecutionPath() .. "/waypoints/" .. tempname  .. ".xml";
		else
			filename = getExecutionPath() .. "/waypoints/__unnamed.xml";
		end
		filechk, err = io.open(filename, "r");
		if (filechk) then
			cprintf(cli.yellow, language[525]); -- Filename already exists! Overwrite? [Y/N]
			overwrite = io.stdin:read()
			filechk:close();
		end
		if (not filechk) or string.lower(overwrite) == "y" then
			file, err = io.open(filename, "w");
			if( not file ) then
				cprintf(cli.green, language[524]); -- File save failed. Please verify the name and try again.
			end
		end
	end

[rock5]

Excellent idea. There have been times where I lost all my hard work because I wrote the file name wrong.

[rock5]

I don't know if you had any more planed but I've committed what we've done so far.
http://www.solarstrike.net/phpBB3/viewt ... 861#p52861

[Bill D Cat]

I was toying with the idea of getting it to detect the IDs of quests from the NPC, but there's likely going to be issues with having it complete quests automatically when there are multiple quest rewards to choose from. So for the immediate future, what is in the utility now is all I'm planning on doing until I can resolve the other issues.

[Bill D Cat]

My latest update: Use the keypad "*" to change the forced waypoint movement mode at any waypoint.

The following are the additions to the language file that are required for this to work.

Code: Select all

	[526] = "  (%s)\tChange Waypoint movement type\n",
	[527] = "Change to (T)ravel, (R)un, or (N)ormal > ",
	[528] = "Forced Waypoint Mode changed to \"%s\"\n",

[rock5]

I've actually been thinking of getting keyboard input from in the game for "ChoiceOption". I find it annoying to have to change windows just to press 1 key. I wonder if we could avoid having to switch windows to select the wp type as well.

Another, probably easier, option, might be to just bring the MM window to the foreground so you could immediately enter the value using showWindow(getHwnd(), sw.shownormal). The benefit of this is you could use it for all input. You could even have the game automatically restored after you have entered your input.

If we are going to have this extra command, I think we have to also consider a way to set the starting type, eg.

Code: Select all

<?xml version="1.0" encoding="utf-8"?><waypoints type="TRAVEL">

Maybe, instead of using another key, we ask the user which type to use when createpath is first run.

[Bill D Cat]

Yeah, I was thinking about that as well. I noticed the default settings at the top of the file, and was considering how best to implement that idea. Adding an question, or short series of questions about setting up the default state of the waypoint file could be useful.

The other idea I've been messing with is an APPEND mode. I was thinking that createpath could read in an existing file and parse backwards to find the "</waypoints>" line and keep everything before it, then just start adding new waypoints after that point. You wouldn't need to worry about entering the proper waypoint number in the comment since we have the renumber utility now. And by not renumbering, you can see where each new section was appended to the end.

And what do you think about adding an "Undo Last Entry" option?

[rock5]

Yeah, I was thinking about that as well. I noticed the default settings at the top of the file, and was considering how best to implement that idea. Adding an question, or short series of questions about setting up the default state of the waypoint file could be useful.

I don't know if you need a 'series of questions', it's only one option.

The other idea I've been messing with is an APPEND mode. I was thinking that createpath could read in an existing file and parse backwards to find the "</waypoints>" line and keep everything before it, then just start adding new waypoints after that point. You wouldn't need to worry about entering the proper waypoint number in the comment since we have the renumber utility now. And by not renumbering, you can see where each new section was appended to the end.

I don't know if that's necessary. If a waypoint file is long enough to warrant an eppend instead of restarting then you most likely will be editing it so you might as well create another waypoint file and then copy and paste the contents to the main waypoint file when you edit it.

And what do you think about adding an "Undo Last Entry" option?

I would just add a comment to it then delete it later when editing the file. So I think it would be a waste of a button that could be used for something else.

I think in the end there is a limit to what we can accomplish with this format of createpath. What would be ideal is a GUI version that would give you a whole lot of possibilities. Such as a visual representation of the waypoints, a table of example code to insert, the ability to click a waypoint and have it move to it to verify it's position, delete waypoints, edit waypoints, etc, etc. I actually did think about making the current createpath more complex by using submenus but gave up on the idea because it would become too complex and would always be limited.

[Bill D Cat]

Yeah, I was thinking about that as well. I noticed the default settings at the top of the file, and was considering how best to implement that idea. Adding an question, or short series of questions about setting up the default state of the waypoint file could be useful.

I don't know if you need a 'series of questions', it's only one option.

What I was thinking about at startup was something like this:

Do the initial startup and prompt the user for what movement type to make the waypoint default.

If the default selected is "NORMAL" then prompt the user to see if they want to specify default mobs to add to the hunt and kill list in the <onload> section.

As for the other options, I agree that a GUI based utility would be far superior than nesting multiple text levels of options. I was just thinking of what options might be useful to have.

[rock5]

I think putting anything in the onload is too much to ask. And changing the mob list is usually a rare occurance so I think it's an unnecessary question.

As to option we could add, we would add the most commonly used to the least used, but there is no real limit. The obvious ones are Accept/CompleteQuestByName, player:mount(), getQuestStatus, loadPaths, etc. But any commonly used snippets of code could be included. In a GUI there wouldn't be any limit to how much stuff we could use.

[Bill D Cat]

AcceptQuestByName() is easy. The issue lies in CompleteQuestByName() where there are multiple quest rewards to pick from. I've managed to work up my own custom code block that picks the best option based on your current primary class, but that might not always be the optimal option to choose.

player:mount(), yrest(), getQuestStatus() are short and easy to type in using the insert code option. I never could remember the correct format to change the movement method, so I added that as an option. Adding a tag="" to a waypoint, and the corresponding code to jump to that tag would be better in a GUI or just manually editing the file. Having one to add a loadPaths() could be useful, but not entirely necessary.

The only other option I could see going into the <onload> header would be a player:mount() call if you prompted the user to ask if they wanted to start out mounted. Any further customization of the <onload> would best be done by editing the saved file.

[rock5]

Yep tags are another good idea. But if we did a gui there really is no limit to how many commands we could add. It's just that a gui is not easy to do.