Patch 4.0.1.2433

[rock5]

That's how it behaved for me when I was testing a version of the new memorytables.lua file. The one that was committed worked fine. Is it possible you tried one of those earlier versions and just have a conflicting file? If so, right click the memorytables.lua file and select "TortoiseSVN/Revert".

[nokirk]

That's how it behaved for me when I was testing a version of the new memorytables.lua file. The one that was committed worked fine. Is it possible you tried one of those earlier versions and just have a conflicting file? If so, right click the memorytables.lua file and select "TortoiseSVN/Revert".

no, didn't work unfortunately. I deleted the file and downloaded a fresh one and still:

Wir benutzen nun die normale Wegepunktdatei EXT cot_tele.xml.
Id 111813 not found
Die Option 'HARVEST_DISTANCE' wurde von '120' auf '450' geändert.
Wir gehen zum Wegpunkt #1, (4863, -1909)
target_NPC(): Bitte geben Sie den Namen des NPC an, der gesucht werden soll.
Drücke MACRO: RoMScript ausführen "ChoiceOption(2);".
Drücke MACRO: RoMScript ausführen "ChoiceOption(1);".
Stopping execution.

Won't even find Malatina.

A friend of mine had a problem which is connected, I think: She tried to make a new path but got the error:

...ide/Saved Games/micromacro2/scripts/rom/settings.lua:1263: table index is nil

I checked settings.lua and around line 1263 bot tries to make a table with item id and set skill. When we deleted the whole for- loop it worked again.

[SpiralV]

It looks like the memory table doesn't work on 64bit systems since last patch.
the problem is a small table there is no way out.
I've changed few things in memorytable.lua

Inserting all known address values

Code: Select all

	if not IdAddressTables then
		local tablePointer = memoryReadIntPtr( getProc(), addresses.tablesBase, addresses.tablesBaseOffset )
		local startAddressOffsets = {0,addresses.tableStartPtrOffset, addresses.tableDataStartPtrOffset}

		-- table insert all known addressLines
		for i = 1, 27 do
			local dataPointer = memoryReadIntPtr( getProc(), tablePointer + (4 * (i - 1)), startAddressOffsets) - lineSize
			local id = memoryReadInt(getProc(), dataPointer + addresses.idOffset )
			IdAddressTables = {[id] = dataPointer}
		end
	end

Seeking backwards causing the problems so force a forward search

Code: Select all

	-- Finds the nearest address in 'IdAddressTables' with the closest id to '_id'
	-- but not higher to force a search in forward direction
	local function FindNearestIdAddress(_id)
		local closestId
		for i,v in pairs(IdAddressTables) do
			if closestId == nil or math.abs(_id - i) < math.abs(_id - closestId) and _id - i > 0 then
				closestId = i
			end
		end
		return IdAddressTables[closestId]
	end

not in connection with the problem but I think it's a good idea to check the value before calculations are performed

Code: Select all

			local offset8 = memoryReadInt( getProc(), dataPointer + 8);
			-- Read a valid value? Has it reached the end of the table?
			if not offset8 or offset8 < 0x100000 then
				return
			end

[rock5]

It looks like the memory table doesn't work on 64bit systems since last patch.

It has been working on my 64 bit Windows 7 pcs.

the problem is a small table there is no way out.

Are you saying it gets stuck even when using valid ids? That sucks and doesn't make sense. If it works the way you believe it works, then it shouldn't get stuck.

I've changed few things in memorytable.lua

Inserting all known address values

That's a good idea. I nearly did that myself but didn't.

I've tried this new file but I got an error.

Code: Select all

0:44am - ...(x86)/micromacro/scripts/rom/classes/memorytable.lua:78: table index is nil

I printed out the datapointers and got this.

Code: Select all

1 f51f60
2 c2f1b80
3 c486240
4 d58a1e0
5 d587040
6 d586f40
7 d586d00
8 d7bde80
9 d990420
10 d9f8580
11 ecb3fe0
12 ef26e00
13 ef26b40
14 fa70b60
15 fb505e0
16 fb9fb40
17 fbfffe0
1:22am - ...(x86)/micromacro/scripts/rom/classes/memorytable.lua:80: table index is nil

Each of those addresses should point to the beginning of a table. The 17th table is the 1000 to 1010 range. It doesn't point to anything.

I can't figure out why it would do that.

I tried restarting the game, changing accounts and restarting the computer but it always does it. Strangely it worked fine on my other computer. Both are win7 64bit pcs.

[rock5]

I forgot to say. An easy fix is to check the id first

Code: Select all

			if id then
				IdAddressTables = {[id] = dataPointer}
			end

[SpiralV]

Are you saying it gets stuck even when using valid ids? That sucks and doesn't make sense. If it works the way you believe it works, then it shouldn't get stuck.

no it's the same problem as in your screenshot.
ok then we got some clear answers. The IDtables are fragmented into 64k blocks reserved by client.exe via vmalloc and now it's sure to say the search index can't follow the block order.
I need some more time to think about this fact.

[Simon]

The only insight I have to offer atm is that it works on my stationary PC but not my laptop, both running Windows 7 64 bit and the bot is shared via dropbox so it's the exact same files.

[rock5]

VMMap is an interesting tool. I had a look at it. I noticed that all the other 27 dataPointers point to 64k regions but the bad datapointer points to a 36k region. I'm not sure if that tells you anything. On my other pc that doesn't have this problem, all addresses point to 64k regions.

[nokirk]

for those that have cot crashing, when deleting or commenting out line 137

Code: Select all

flyoff()

it'll work again. Just have to manually get into and out of the instance

[rock5]

SpiralV, I noticed a bug. You can't use this inside the loop at line 78 because it assigns 1 value to the variable replacing any previous value.

Code: Select all

			IdAddressTables = {[id] = dataPointer}

So after the 27 loops it will only still have 1 value.

You need to, first declare the variable outside of the loops

Code: Select all

	--first initialization
	if not IdAddressTables then
		IdAddressTables = {}

And then use

Code: Select all

			IdAddressTables[id] = dataPointer

Once this is fixed I printed out the IDAddressTables and notice I have 2 problems. One is table 17 returns an id of nil and table 24 returns a huge value like 336134144.

At the moment I'm ommitting those 2 tables but I'm getting alot of "Id ###### not found" and/or "Wrong value returned in update of item id: ######". I even tried reverting to the original memorytables.lua file but it's still not working, but it used to. So now I'm wondering if I have a corrupt file somewhere and if I should reinstall the game.

[SpiralV]

VMMap is an interesting tool. I had a look at it. I noticed that all the other 27 dataPointers point to 64k regions but the bad datapointer points to a 36k region. I'm not sure if that tells you anything. On my other pc that doesn't have this problem, all addresses point to 64k regions.

This instruction jumps back one line into the 64k/36k region the rest of 28k is unalocated = nil or ???? in IE

Code: Select all

local dataPointer = memoryReadIntPtr( getProc(), tablePointer + (4 * (i - 1)), startAddressOffsets) - lineSize

all of these instructions '- lineSize' '+ lineSize' need more logic
for instance
0xFDBFFE0 + lineSize = 0xFDC0000 <- big fail is is one other 64k region
0xFDB0000 - lineSize = 0xFDAFF0E <- the same problem
we can check this

Code: Select all

-- for + lineSize movement
if (datapointer + lineSize) % 0x10000 == 0 then datapointer = 'next 64k region up' else datapointer = datapointer + lineSize end
--and
-- for - lineSize movement
if datapointer % 0x10000 == 0 then datapointer = 'next 64k region down' else datapointer = datapointer - lineSize end

the problem is to say where is the next 64k region up and down. this is the part where I'm working.

[rock5]

You obviously understand it alot more than I do. Keep up the good work. I hope you figure it out soon.

I even tried reverting to the original memorytables.lua file but it's still not working, but it used to.

I spoke too soon. When I reverted memorytables.lua, it reverted to an older version. When I fixed that, it worked fine, or seems to.

I tried just adding the 1-27 loop to add addresses and I got a lot of "Ids not found" and "wrong value returned" errors.

[bobdole]

I had this same problem and as directed I reverted back to rev 637, I then looked to see what files changed in the next 2 updates and I saved a copy of them and then updated back to rev 639 then by process of elimination I found by overwriting both the bot.lua and memorytable.lua from rev 637 everything continued to work fine. So something is broke in those files.

[SpiralV]

rock you can check the two versions if they work?
Edit: I change the memorytable.lua
I've forgotten to change that

Code: Select all

			-- Id not found. Get next dataPointer.
			if currentId > IdToFind then
				if offset0 == offset8 then
					dataPointer = dataPointer + lineSize
				else
					dataPointer = offset0
				end
			elseif currentId < IdToFind then
				if offset0 == offset8 then
					dataPointer = dataPointer - lineSize
				else
					dataPointer = offset8
				end
			end

into

Code: Select all

			-- Id not found. Get next dataPointer.
			if currentId > IdToFind then
				if offset0 == offset8 or offset0 == IdTableHeader then
					dataPointer = dataPointer + lineSize
				else
					dataPointer = offset0
				end
			elseif currentId < IdToFind then
				if offset0 == offset8 or offset8 == IdTableHeader then
					dataPointer = dataPointer - lineSize
				else
					dataPointer = offset8
				end
			end

I've replaced the file
I play for a while with the versions I prefer memorytable.lua i'ts the better one

[rock5]

Neither causes any errors. The only difference I notice was thet first version reported the card and recipe ids as not found.

[SpiralV]

Neither causes any errors. The only difference I notice was thet first version reported the card and recipe ids as not found.

I fixed it in the new file

[rock5]

Initially I noticed no errors but now I'm noticing some ids return nil until they are viewed, eg. this command

Code: Select all

print(GetIdName(530001))

If I do the "GetCraftRequestItem" command then it works. Looks like it's possible for the address to exist and point to the data area which exists but the data, like the address that points to the name, is missing. Doing the GetCraftRequestItem fixes it.

I fixed it by changing the GetIdName function like this.

Code: Select all

-- Returns the name for a given id
function GetIdName(itemId)
	if itemId ~= nil and itemId > 0 then
		local itemAddress = GetItemAddress(itemId)
		if itemAddress ~= nil and itemAddress > 0 then
			local name = memoryReadStringPtr(getProc(), itemAddress + addresses.nameOffset, 0)
			if name == nil then
				-- Item data not totally substanciated yet. Do "GetCraftRequestItem", then the address will exist.
				RoMScript("GetCraftRequestItem("..itemId..", -1)")
				name = memoryReadStringPtr(getProc(), itemAddress + addresses.nameOffset, 0)
			end
			return name
		end
	end
end

[SpiralV]

Do we need this in the GetItemAddress function ? i delete this to see whats happens

Code: Select all

function GetItemAddress(id)
	local addressline = GetIdAddressLine(id)
	if addressline then
		local address = memoryReadIntPtr( getProc(), addressline + 0x10, 0x8)
		return address
	else
		printf("Id %d not found\n", id)
	end
end

[rock5]

Yes you do, because the original reason for adding it was because sometimes it wouldn't return an address because the item data area didn't exist. You need to execute that command to make it exist then there will be a valid address to return. Without the command it can't return a valid address.

Now the item data area exists so it returns a valid address but the data isn't complete, ie. the address to the name is missing probably along with other info. It's a separate check that, because it's related to the name, I thought it best to put it in the GetIdName function. I could have put it in the GetItemAddress function but that function has to do with the address and doesn't need to check the name to return a valid address so it's not really the right place.

[SpiralV]

ah ok I understand then there is no reason to change anything.