Not enough memory error since new patch...

[Administrator]

I had made the change yesterday but did not update the zip that I uploaded. I did that just now so that users won't have to do it manually.

[rock5]

I found another bug with 1.03 b2. memoryReadUStringPtr crashes MM. This is the command I was using.

Code: Select all

memoryReadUStringPtr(getProc(),0xEEE44EB8,4))

I tested it with the current version of MM 1.03 on the main page and it works, so it's something that was changed since then. memoryReadUString still works.

[Administrator]

Good catch, fixed it and re-uploaded the package.

This is what happens when you have (void*)&readBuffer as opposed to (void*)readBuffer.

[rock5]

That works but...

Code: Select all

if fw ~= getHwnd() and ( ah == 0 or fw ~= ah ) and (__targetWindow or __targetWindow ~= fw) then

Close but not close enough. Supposed to be

Code: Select all

if fw ~= getHwnd() and ( ah == 0 or fw ~= ah ) and (__targetWindow == nil or __targetWindow ~= fw) then

[rock5]

I've been thinking about this a bit.

Can foregroundWindow() ever be 'nil'? If not then if __targetWindow == nil then it won't equal fw. Therefore we could simplify it further like this

Code: Select all

if fw ~= getHwnd() and ( ah == 0 or fw ~= ah ) and (__targetWindow ~= fw) then

For that matter can fw ever equal 0? If not we could simplify it even further.

Code: Select all

if fw ~= getHwnd() and ( fw ~= ah ) and (__targetWindow ~= fw) then

ANd because we use ah only once we should probably write it like this so it doesn't do the "getAttachedHwnd()" unless it really has to.

Code: Select all

if fw ~= getHwnd() and (__targetWindow ~= fw) and (getAttachedHwnd() ~= fw) then

I've tested it a bit with 2 clients and 2 MMs and it still works correctly.

[Administrator]

It should never return nil, but may return 0 in some (mostly undocumented) instances (note: NULL is 0, not nil).

[s018mes]

I am getting this error. It cause the bot to stop and then in mid-battle I die.

I have 8 gigs of ram. Is it normal for micromacro.exe to use 1.4 to 1.8 gigs of ram? That seems extremely excessive. Runes of magic only uses 900k ram.

[s018mes]

I am continuing to have this problem. I can no longer bot past a few hours. When I watch the processes on my computer I see that micromacro.exe starts out with 15k memory and then over time it grows well past 1.5 gigs! At that point the program just crashes. Yes, I do run 2 instances of micromacro, but I always have. I use to be able to run it for day or more with no problems. Is there a plan on how to fix this in future releases?

[rock5]

What version of MM are you using? Try the latest beta version which is also available on the micromacro download page. That might help.
http://www.solarstrike.net/micromacro

[s018mes]

Yes, I didn't know there was a new version of Micromacro. That has SOLVED the issue. Thanks so much.

[trinity1]

just updated to the new beta and svn everything is working except it gives a error because of my onload

here is my onload

Code: Select all

<onLoad> 
	-- Change Profile Option 
	changeProfileOption("ANTI_KS", true) 
	changeProfileOption("MAX_TARGET_DIST", 150) 
	changeProfileOption("INV_AUTOSELL_QUALITY", "white,green,blue")
	</onLoad>

and here is the error

10:34am - C:/Users/User/Desktop/micromacro/scripts/rom/functions.lua:1183: C:/Us
ers/User/Desktop/micromacro/lib/mods/cli.lua:72: attempt to call global 'tostrin
g' (a nil value)

[Administrator]

Either grab the stable (non-beta) version, or you can add add this:

Code: Select all

local tostring = global.tostring;

to micromacro/lib/mods/cli.lua at line 28 (just below all the similar lines).

[rock5]

That's a strange one. I don't know how tostring, definitely an existing function, could be nil. I can make a couple of suggestions though.

Having the micromacro folder on the desktop has been reported as causing problems. I don't know if this is related but I suggest you put it somewhere such as the "Program Files" folder or in the root directory and just have a shortcut to the folder on your desktop.

Make sure there were no corrupt rombot files after your last svn update. If any of the files have red or yellow icons next to them then do an svn revert on the 'rom' folder.

[trinity1]

ok made the change that administrator said and that worked only thing it don't print the changes in the onload like the old one used too but it works

[Administrator]

That's a strange one. I don't know how tostring, definitely an existing function, could be nil. I can make a couple of suggestions though.

It is because I moved sprintf() to the cli module. Inside the module, it does not default to global scope so you need to explicitly call global functions through the _G table.