createpath + getid + getpos together

[rock5]

Here is my current createpath.lua including quest accept,complete and choiceoption by name. i guess I have to include my english file too.

createpath.lua

(24.84 KiB) Downloaded 147 times

english.lua

(17.04 KiB) Downloaded 129 times

The window swapping should work as it is now except I think current beta vesion of MM will resize the client window from maximized to windowed. The version I'm using doesn't do that and I'm pretty happy with it. Hopefully it wont be much longer that Administrator will release it as an official beta.

I tested it with the game in fullscreen mode. It does work but does eventually crash. To make it more stable you need to make the in game resolution the same as your display and disable aero on your display then it works pretty good.

I'll let you play with the new options to see how they work. Have fun.

Let me know if there are any bugs.

[Bill D Cat]

And here is my version of createpath that polls the questbook for changes and adds the appropriate command automatically. I did not incorporate the screen swap options that you implemented, so the window will still minimize/restore as in my previous version.

I also do not have the additional code to modify the global waypoint movement type that I see you added as well.

[Bill D Cat]

I'll let you play with the new options to see how they work. Have fun.

Let me know if there are any bugs.

With the change you did to add the global waypoint movement type, you didn't change the prompt to reflect the options. It still uses (T)ravel, (R)un or (N)ormal, but pressing anything other than 1-6 results in Normal.

[rock5]

I understand the intent of your method. It's not a bad idea and I'm not sure which way I will go. But your functions are messed up. Looks like you are having trouble with tables. You are are actually not creating any. If it seemed to work for you it might be because the quest you were testing would always end up last in the list.

For example:

Code: Select all

	quests = {};
	if numquests > 0 then
		for lidx0 = 1, numquests do
			_, _, quests["qName"], _, _, _, _, _, quests["qId"], _, _ = RoMScript("GetQuestInfo("..lidx0..")")

You are not filling a table. You are changing the same 2 variables, quests.qName and quests.qId, each time it goes through the loop. I think you meant

Code: Select all

	quests = {};
	if numquests > 0 then
		for lidx0 = 1, numquests do
			quests[lidx0] = {}
			_, _, quests[lidx0]["qName"], _, _, _, _, _, quests[lidx0]["qId"], _, _ = RoMScript("GetQuestInfo("..lidx0..")")

That will create a table.

And, this ones funny,

Code: Select all

		for kb, vb in pairs(quests2) do
			if quests.qId == quests2.qId then
				foundflag = true;
				break
			end
		end

You are supposedly iterating though the quests2 table but you never use kb or vb. You just keep comparing the same 2 values quests.qId and quests2.qId.

Here, I made those changes.

[Bill D Cat]

Yeah, this was my first attempt at working with tables. Now that I've had some exposure, and seen what I did incorrectly, my next foray may go better. I like the way your method works as well; and if I'm looking at this correctly, we could even use it to replace the current Option 6 since those options would be exposed in the NPC dialog.

[rock5]

The problem with replacing option 6 is, there are times when you might prefer to use ChoiceOption instead of ChoiceOptionByName. The main reasons being is that it is language independent and simpler. To make ChoiceOptionByName language independent requires the use of the language converter or a knowledge of how to scan it in memory as I believe Lisa does. And you only really need to use it if there is a possibility that the option may move.

The one downside to my version is if the user makes the mistake of accepting more than one quest with the same name then it could end up with the wrong id. I think it needs to check and warn the user if they do that.

[rock5]

While trying to add a warning about duplicate quests with the same name, I find I'm not happy with the results. One thing that occurred to me is, what happens if a user wants to accepts the daily and public quests with the same name at the same time? So we need the reliability of your poling method. Now I'm thinking maybe, after the user makes a selection, the bot can get the list of questlog quest, select the selected quest, then pole the questlog again to see which was added. It would make it easier on the user too. One less step they have to do because they wont have to manually select the quest/option. It also means it will immediately have access to the id so it can immediately use the id in the print message. I'm liking this idea. I'll get to work on it.

[rock5]

Ok, here it is.

createpath.lua

(26.26 KiB) Downloaded 146 times

english.lua

(17.17 KiB) Downloaded 132 times

I rather like it, a merger of out 2 ideas.

I decided that users wouldn't notice important messages such as when they make a mistake so now messages that users need to take note of appear in redish orange text and beep once.

[Bill D Cat]

Functionally, it works pretty good. But there's one thing that I really do not like about this version. I'll see if I can explain it in enough detail.

Code: Select all

Start rom/createpath on a new human character in Pioneer's Colony.
Press 1 to enter the first waypoint near Laif Cindai.
Double-click on the NPC and press 5 to start the dialog option.
Press - to start the QuestByName sequence, enter 1 to accept "Report In".

Now, at this point everything is working fine, except the NPC dialog is still open and asking you to accept the quest. Kind of confusing.

Code: Select all

Move towards Leighton and press 1 a few times to create intermediate waypoints.
Double-click on Leighton and press 5 to start the dialog option.
Press - to start the QuestByName sequence, enter 2 to complete "Report In".

Now once again, the NPC dialog is not "in sync" with what quests you've done, as it's still asking for you to complete the quest. In order to accept the next quest ("Claiming Weapons") you have to manually close and reopen then NPC dialog before you can use the QuestByName option again.

[rock5]

So what is your problem? That the dialog doesn't close? Do you think users would get confused with the wrong displayed dialog? The tests I was running, the dialog always closed so I didn't notice that behavior. I guess it depends on the npc and quests.

I guess we can just issue a command to close the dialog. Note: the created wp file should work fine, there is nothing that needs to be added to the wp file because Accept/CompletQuestByName function already retarget the npc before each operation specifically to handle that bug.

[Bill D Cat]

So what is your problem? That the dialog doesn't close? Do you think users would get confused with the wrong displayed dialog? The tests I was running, the dialog always closed so I didn't notice that behavior. I guess it depends on the npc and quests.

I know it confused me for a minute. I thought that I still had to manually click the option since the NPC dialog still showed it was waiting for input. It wasn't until I noticed in the RoM chat window that the quest had been accepted that I realized what was going on.

I guess we can just issue a command to close the dialog. Note: the created wp file should work fine, there is nothing that needs to be added to the wp file because Accept/CompletQuestByName function already retarget the npc before each operation specifically to handle that bug.

Agreed, the waypoint file looks good to me. I guess it is just my personal esthetics of coding that would include the semi-colon after the Accept/CompleteQuestByName() and before the comment with the quest name. (Ref lines 295 and 311). I get a little OCD about the way things look in my code, which is what got me started on the cleanup of the skills.xml in the first place.

Also, I did notice that I missed one instance in the code where I fixed the close tags. At the end of the save routine at line 337:

Code: Select all

	-- If we left a tag open, close it.
	if( tag_open ) then
		hf_line = hf_line .."\n".. closeformat;
	end

should now be:

Code: Select all

	-- If we left a tag open, close it.
	if( tag_open ) then
		if ( hf_data ) then
			hf_line = hf_line .. "\n" .. closeformat
		else
			hf_line = hf_line .. closeformat
		end
	end

And I guess the commented code at line 349 is redundant now as well.

Code: Select all

--[[
	if( tag_open ) then
		file:write("\n\t</waypoint>\n</waypoints>\n");
	else
		file:write("</waypoints>\n");
	end
]]

[rock5]

Agreed, the waypoint file looks good to me. I guess it is just my personal esthetics of coding that would include the semi-colon after the Accept/CompleteQuestByName() and before the comment with the quest name. (Ref lines 295 and 311). I get a little OCD about the way things look in my code, which is what got me started on the cleanup of the skills.xml in the first place.

I get a bit OCD too In fact, now that you've mentioned it, I think i'll go through and remove all those semicolons. Semicolons have no place in lua. The only reason they show up so much in the bot code is because of people coming over from C+ related languages that need it, like Administrator. The only time I use semicolons is when adding lines somewhere and all the other lines have semicolons so I add them just so the lines I add don't look out of place, eg. when adding default values to an existing class.

Also, I did notice that I missed one instance in the code where I fixed the close tags.

Ok. Added.

And I guess the commented code at line 349 is redundant now as well.

Yep. Already deleted.

I'm just doing a review of the messages to make sure they have a consistent feel, they are all over the place at the moment.

[Bill D Cat]

Semicolons have no place in lua.

Yes and no, IMHO. If just used to end a line of code for the sake of having some sort of punctuation, then I'd agree. Stringing together multiple commands on one line of code would still require it. The argument there, of course, is to just break your code up into one line each, but some people are just used to coding that way I suppose.

And I found this in a very OLD thread:

http://solarstrike.net/phpBB3/viewtopic.php?f=21&t=3742

I think he meant how do you invoke fly so you can mark waypoints in the air while creating the waypoint. Just start the commandline in another instance of micromacro and type fly() or flyoff() when needed.

What do you think about adding a key to toggle this in createpath now?

[rock5]

Stringing together multiple commands on one line of code would still require it.

Well, actually, no it isn't, although you might find it easier to distinguish between the separate commands. I can tell you I don't use semicolons when putting multiple commands on one line. For instance in my compact RomCode command in my latest createpath.lua,

Code: Select all

	local text, typ, index = RoMCode("n="..num.." c=0 for k,v in pairs(g_SpeakFrameData.option) do if v.objtype~=1 then c=c+1 if c==n then a={v.title,v.type,v.id} break end end end")

No semicolons there.

About fly(), fly is a userfunction so I wouldn't add that. Although, I guess we could copy the code over. I'll think about it some more.

[Bill D Cat]

About fly(), fly is a userfunction so I wouldn't add that. Although, I guess we could copy the code over. I'll think about it some more.

I wasn't sure if createpath could just call the functions itself, as well as adding the fly() and flyoff() commands to the waypoint.

[rock5]

I don't think it can because the userfunctions are not loaded, why would they be? But you could add the code to one button. Maybe a toggle fly option using a function something like this.

Code: Select all

function toggleFly()
	local offsets = {addresses.charPtr_offset, addresses.pawnSwim_offset1, addresses.pawnSwim_offset2}
	local active = 4
	
	local current = memoryReadIntPtr(getProc(), addresses.staticbase_char, offsets);
	if current ~= active then
		memoryWriteString(getProc(), addresses.swimAddress, string.rep(string.char(0x90),#addresses.swimAddressBytes));
		memoryWriteIntPtr(getProc(), addresses.staticbase_char, offsets, active);
	else
		memoryWriteString(getProc(), addresses.swimAddress, string.char(unpack(addresses.swimAddressBytes)));
	end
end

[Bill D Cat]

If we added this, would we also want to include the fly() and flyoff() in the waypoint file we are creating? Or should we just leave that as code the user can enter with option 0?

[rock5]

Good question and that starts to complicate things. I first thought the option would just turn fly off or on as needed but users might be confused and think that the fly command will be added. I certainly don't think we should add a separate button to add the fly on or off as they are really easy commands to add via 0 key and I don't think they should be added automatically because the user could just be turning it off or on because they need to use it, not because they want to add it to the waypoint file.

What if when the fly key is pressed it toggles the flying and asks the user if they want to add the command to the waypoint file?

[Bill D Cat]

That's probably the best option, a simple yes or no question. Anything beyond that would start to complicate things more than they need to be. I would be happy with that configuration.

[rock5]

How about this?