Page 2 of 3
Re: Patch 4.0.1.2433
Posted: Wed Aug 17, 2011 10:52 am
by 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".
Re: Patch 4.0.1.2433
Posted: Wed Aug 17, 2011 11:25 am
by nokirk
rock5 wrote: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.
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 6:35 am
by 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
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 11:26 am
by rock5
SpiralV wrote: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.
SpiralV wrote: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.
SpiralV wrote: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.
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 11:28 am
by rock5
I forgot to say. An easy fix is to check the id first
Code: Select all
if id then
IdAddressTables = {[id] = dataPointer}
end
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 1:32 pm
by SpiralV
rock5 wrote:
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.
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 7:11 pm
by 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.
Re: Patch 4.0.1.2433
Posted: Thu Aug 18, 2011 11:43 pm
by 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.
Re: Patch 4.0.1.2433
Posted: Fri Aug 19, 2011 3:23 am
by nokirk
for those that have cot crashing, when deleting or commenting out line 137
it'll work again. Just have to manually get into and out of the instance
Re: Patch 4.0.1.2433
Posted: Fri Aug 19, 2011 8:31 am
by 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.
Re: Patch 4.0.1.2433
Posted: Fri Aug 19, 2011 12:43 pm
by SpiralV
rock5 wrote: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.
Re: Patch 4.0.1.2433
Posted: Fri Aug 19, 2011 1:23 pm
by rock5
You obviously understand it alot more than I do. Keep up the good work. I hope you figure it out soon.
rock5 wrote: 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.
Re: Patch 4.0.1.2433
Posted: Fri Aug 19, 2011 6:48 pm
by 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.
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 7:27 am
by 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
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 9:37 am
by rock5
Neither causes any errors. The only difference I notice was thet first version reported the card and recipe ids as not found.
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 9:59 am
by SpiralV
rock5 wrote: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
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 11:07 am
by rock5
Initially I noticed no errors but now I'm noticing some ids return nil until they are viewed, eg. this command
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
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 11:52 am
by 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
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 12:07 pm
by 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.
Re: Patch 4.0.1.2433
Posted: Sun Aug 21, 2011 12:25 pm
by SpiralV
ah ok I understand then there is no reason to change anything.