createpath + getid + getpos together

[Bill D Cat]

We might want to look at either tightening up the range to use for cards and recipes or else adding a failsafe so that unused numbers in the range don't cause the bot to crash.

[Bill D Cat]

Adding a check to see if itemId == 0 seems to fix it.

Code: Select all

   if itemId >= 770000 and itemId <= 772000 then
      itemId = memoryReadInt( getProc(), itemAddress + addresses.idCardNPCOffset );
      if itemId == 0 then return end
      itemAddress = GetItemAddress( itemId );
      name = getTEXT("SYS_CARD_TITLE")   -- "Card - "
   elseif itemId >= 550000 and itemId <= 553000 then
      itemId = memoryReadInt( getProc(), itemAddress + addresses.idRecipeItemOffset );
      if itemId == 0 then return end
      itemAddress = GetItemAddress( itemId );
      name = getTEXT("SYS_RECIPE_TITLE")   -- "Recipe - "
   end

[rock5]

Ok, done.

[Bill D Cat]

I realize that the bot uses different memory reading techniques than in-game add-ons use, but do you think that support for recipes and cards could be added to your tooltips addon as well?

[rock5]

We don't have any memory reading in game. We can only use existing functions and their returned values.

Recipes seem to be working fine for me. Cards aren't. Looks like a couple of addons I have overwrite the id, namely yaCIt and MonsterCardTooltip. With both of them disabled I get the id. Unlike other addons that hook into functions and add information to the tooltip, these addons completely replace the tooltip and overwrite any info already there.

I can't see any easy way to fix it. Either I add a print to the chat box or hook into the card addons functions. Adding hooks would require support added for each addon. How many addons are there that overwrite the card tooltip like this? How much do you need to know the card id? Why do you need to know the card id?

[Bill D Cat]

I suppose the use would be limited in needing to know recipe or card IDs for the most part, whether via in-game scripts or through the bot. The only use I can see for the bot is via inventory:useItem() to be language independent. Not really much use in the game itself, much like knowing the IDs of mobs or other items. Sometimes it's just nice to be able to compare them to what the bot is reading.

I don't have a problem with the info being sent to the chat box, in the same format as the buff/debuffs do when you mouse-over them.

[rock5]

I don't like adding print messages if I can avoid it. I did a search and only found those 2 addons for monster cards so I just added exceptions for both of them.

You mentioned recipes. Are they working for you?

[Bill D Cat]

Yeah, recipe tooltips are working fine, I guess it is just the cards that don't show an ID.

On a slightly different note:

Code: Select all

function getKeyStrings(text, returnfirst)
	-- Heavily filtered to make the speed usable but should find most texts. If not found, use language converter tool.
	-- Excludes key strings beginning with "Sys". They are for ids so you can use GetIdName instead.

I don't see how the second note is really applicable. What I mean is GetIdName() accepts an ID as it's argument and returns the assigned string, whereas getKeyStrings() accepts text and tries to find the corresponding ID. So saying you can use GetIdName() to find the ID of any key string that begins with "Sys" is really not true.

Also, I noticed that getKeyStrings() does some pattern matching for substrings. We should probably include the <S>, $PLAYERNAME and text override patterns to it's code as well.

[rock5]

I don't see how the second note is really applicable. What I mean is GetIdName() accepts an ID as it's argument and returns the assigned string, whereas getKeyStrings() accepts text and tries to find the corresponding ID. So saying you can use GetIdName() to find the ID of any key string that begins with "Sys" is really not true.

What I meant was you don't need to find the keystring of an id because you can just use the id with GetIdName. Example GetIdName(123456) == getTEXT("Sys123456_name"). Of course this only applies to 'name' key strings and now also plurals. shortnotes and any other strings are not included. I had to exclude Sys key strings because they make up the bulk of the key strings and makes the function too slow.

Also, I noticed that getKeyStrings() does some pattern matching for substrings. We should probably include the <S>, $PLAYERNAME and text override patterns to it's code as well.

Yes it doesn't support $PLAYERNAME. I believe <s> is supported because it's not excluded. So when it passes the subKeyString to getTEXT it should work.

On another note I noticed that subsubstrings are not supported in getTEXT. That is, if a translated substring includes another substring it isn't converted. I fixed it by changing

Code: Select all

			translatedSubTEXT = memoryGetTEXT(subKeyString)

to

Code: Select all

			translatedSubTEXT = getTEXT(subKeyString)

A simple fix but it works. I should probably test to see what effect it has on performance. Just tested it. It's comparable and in some cases faster because getTEXT uses cached values and memoryGetTEXT doesn't.

[Bill D Cat]

What would you think about adding a separate function that only searched the "Sys######" strings for matching text? The reason I ask is I think we could get createpath to return the ID of quest reward items that way. Since it would be separate from the main function, it won't impact the perfomance when looking for other quest related strings. Right now I'm just using an in-game macro to search for the IDs, but I think a memory reading function would still be a lot faster than looping through all the Sys values until a match is found.

[rock5]

Surely we could do it some other way. I have a version of the questlogclass that includes the rewards.Here is the code related to it.

Code: Select all

		-- Get regular rewards
		tmp.Rewards={}
		for i = 1, 5 do
			local tmpid = memoryReadInt(getProc(), address + (i-1)*4 + 0x340)
			if tmpid == nil or tmpid == 0 then
				break
			end
			tmp.Rewards[i] = {}
			tmp.Rewards[i].Id = tmpid
			tmp.Rewards[i].Name = GetIdName(tmpid)
			tmp.Rewards[i].IdType = memoryReadInt(getProc(), GetItemAddress(tmpid) +4)
			tmp.Rewards[i].NumReq = memoryReadInt(getProc(), address + (i-1)*4 + 0x354)
		end

		-- Get choice rewards
		tmp.ChooseRewards={}
		for i = 1, 5 do
			local tmpid = memoryReadInt(getProc(), address + (i-1)*4 + 0x318)
			if tmpid == nil or tmpid == 0 then
				break
			end
			tmp.ChooseRewards[i] = {}
			tmp.ChooseRewards[i].Id = tmpid
			tmp.ChooseRewards[i].Name = GetIdName(tmpid)
			tmp.ChooseRewards[i].IdType = memoryReadInt(getProc(), GetItemAddress(tmpid) +4)
			tmp.ChooseRewards[i].NumReq = memoryReadInt(getProc(), address + (i-1)*4 + 0x32C)
		end

Still, I can't see how we could incorporate it into createpath. It was always my opinion that more info on rewards is only useful for some sort of custom function that chooses the best reward for the current character. If you had the rewards ids what would you do with them (in the context of createpath)?

[Bill D Cat]

The way it currently runs, it just adds the possible rewards as a comment after completing the quest. I'd like to just expand on that so the comment also included the IDs of those items. It would make the manual coding of special functions to equip gear a little easier. I would not want to add that type of extra code to createpath since it is very specific, and not always optimal.

Code: Select all

 -- Some Cloth Robe (123456), Some Leather Armor (123457), Some Chain Armor (123458)

Like I said, right now I just use an in-game macro that I wrote to look up each item from the rewards list and manually enter that in a second comment. I edit it all later if I want to be able to equip the items when the waypoint is run. Useful for starting zones, and potentially even further up. I'm hoping to create a series of complete zone waypoints that will almost play the entire starting continent for you.

I don't know how useful it would be for people who only try to automate a daily quest, or a mini-game, but for my full zone series it will be very helpful.

[rock5]

Actually, before it does the search for matches that include substrings it does an exact match search using findPatternInProcess. Because it's so fast it's range isn't limited. So it will in fact return the keystrings that begin with "Sys" as long as it doesn't include a substring, which should be most if not all names. So we should be able to use getKeyStrings to add ids to the rewards comment.

[Bill D Cat]

I was just messing around with trying to integrate the quest reward IDs into createpath when I noticed we still support the player:mouseclickL() option. With all the improvements to memory reading to get information and target items in the game, I don't think I'd ever use it. Removing it from createpath won't effect older waypoint files that have the command as the bot would still recognize it correctly. It would just free up another key for possible use later.

I was just curious if there was a compelling reason to still keep it around.

[rock5]

Good point. It could probably go the next time you have a great idea for a new feature.

[Bill D Cat]

Here's what I've got to add the IDs to the quest rewards. So far it seems to be working pretty well. It may not always get the right ID if there are more than one item with the same name, but typically the various rewards all seem to have sequential numbers to each other. So while not perfect, it is still a lot better than not having any IDs at all.

Changes applied at createpath.lua line 321

Code: Select all

			if v.rewards then
				tmptext = tmptext .. "\n\t\t\t-- Rewards: "
				for k,v in ipairs (v.rewards) do
					local rewardId = getKeyStrings(v,true)
					tmptext = tmptext .. sprintf("[%d] %s (%s) ", k, v, rewardId:sub(4,9))
				end
			end

[rock5]

I think it should cater for the possibility that getKeyString might return no value, just to be on the safe side, eg.

Code: Select all

local rewardId = getKeyStrings(v,true)
if rewardId then rewardId = rewardId:sub(4,9) else rewardId = 0 end
tmptext = tmptext .. sprintf("[%d] %s (%s), ", k, v, rewardId)

I added a comma in the print too to help make it clearer.

[Bill D Cat]

I am updating my waypoint files to use the changes to getTEXT() and GetIdName(). Might be a good time to consider a commit for those changes before you get too far into the international language support.

[rock5]

I intended the last commit to be the one before the language support work, but I ended up doing more edits. I thought I would wait a bit longer until I'm sure what I'm going to do for the language support before committing, just in case I come up with any more edits before then. Your up to date aren't you? Is there anything I talked about that I didn't post? Still.. it might be worth committing if you are going to end up testing it.

[Bill D Cat]

I'm up to date with everything we've discussed and quoted in this thread. If you want I can attach an archive with my copy of the functions.lua and memorytable.lua. I think we are synced on createpath now as well.

I've tested the updates on as many situations as I can think of and so far createpath has performed flawlessly.