SolarStrike Software

just a heads up: next patch announced and coming tomorrow...
bots will not work after the patch!^^

just trying to stop 10 threads from being opened with "omg, why is my bot not working?" lol

Of course addresses will change, they usually do for patches.

Your title made me think frogster has announced bots won't work after patch lol

This would be a good time for people to check out the find memory addresses topic I created, the How to Guide.
http://www.solarstrike.net/phpBB3/viewt ... =21&t=2580

Not sure if I will have the time today to get the new addresses after patch.

Im not completely up to date with that thread lisa, but from memory you were building up a database (screenshots I think) of patterns (asm code snippets) to use to help make finding the addresses easier.

How far did you get with that, and is it perhaps worthwhile creating a new thread with a zip file containing said images and the address name of the address they should help find? perhaps even just a post with the asm snippets and addresses in code blocks. i.e.:

PATCH: 4.0.4.2456.en

actionBarPtr - 0xA2077C

My intention with the thread was to help people learn about memory and finding addresses. If I did a list of exactly what to search for then I'm not really just teaching people I am just spoon feeding them lol
You really only learn something by doing it yourself.

I made a few youtube videos as a bit of a tutorial to help.

You know the old saying, give someone a fish and they eat for a day, teach them to catch fish and they can feed themselves forever.

lisa wrote:Your title made me think frogster has announced bots won't work after patch lol

sorry about that^^ just wanted to stop people that can't read from creating those annoying cry-threads lol

and even if they had announced that they would make bots stop working, it wouldn't have been the first time and it certainly wouldn't be the first time you and rock found a way to make them work again in notime

edit: hm, really weird, but my bot is working fine lol
how come this patch hasn't broken the bot? i'm confused

cause they barely changed Client.exe - they changed a couple of bytes near the end of the program - not sure if them byte changes are even code-related.

MRC_Optimized, Pet Crafting, Cot_Tele, survivalR5 and a general waypoint file still seem to work okay. WooHoooooo.

http://us.runesofmagic.com/us/news,id25 ... h_405.html

On the 22nd November 2011, the level-cap will be raised from 67 to 70, allowing you to access a brand new region, Tergothen Bay, via the foothills of the Redhill Mountains.

Expect a BIG patch next Tuesday...

hmm...sounds like there will be more content updates, but don't know if that will require many changes for Client.exe as there is nothing 'new' from the games point of view (other than the content which is dynamically loaded anyway).

Fingers crossed there'll be little to no changes to client.exe as a result.

I have found 2 issues, both are probably similar with the new patch. I have updated to version 673
1) the code in the profile to open the level bags is not consistently working.
<onLoad><![CDATA[
inventory:update();
if(player.Level == 1) then
openGiftbags1To10(player.Level);
end;
]]></onLoad>
2) the skill updates are not occurring at all
<onLevelup><![CDATA[
sendMacro("SetSpellPoint(4, 2);");
sendMacro("SetSpellPoint(4, 3);");
openGiftbags1To10(player.Level);
if(player.Level < 5) then
sendMacro("SetSpellPoint(4, 2);");
sendMacro("SetSpellPoint(4, 3);");
end;

]]></onLevelup>

are you getting an error or is this stuff just not working at all?

I have additional info. It seems to be associated with using the LoginNextChar(). When restarting the bot from rom/bot.lua, skills and bags level. When the bot finishes and it loads the next character with the code below, it does not. It still runs fine, but there is no log info when the character levels up. I have tried adding the loadProfile() function, but it gives an error on load due to duplicate key 0 lines. This may not be related to the patch.

selectedChar = selectedChar+1;
print("logging out");
ChangeChar(selectedChar,LogID);
print("changing character to", selectedChar);
waitForLoadingScreen();
yrest(30*1000) -- wait 30 sec after screen loads
player:update();
yrest(4000);
player:update();
yrest(4000);
loadPaths("Level1-10/Hunting2");

try something like this I used to use that when I did my 1-10/10 script, this is from a year ago though.

Yea, tried that. The new code for the macro is causing that function to now fail on second call when starting the next character. It says that the key 0 is already allocated to MACRO so it cannot also be allocated to MACRO. I was going to review the code to see where the new rom code is causing the issue and report a fix.

I found the fix. In setting.lua, the if statement uses "_key" instead of "_name" in the following text

BEFORE AFTER _key is a number and NOT ever == to MACRO. The intent of the if statement should be to use _name to test for the "MACRO" string.

BillDoorNZ wrote:cause they barely changed Client.exe - they changed a couple of bytes near the end of the program - not sure if them byte changes are even code-related.

yea but usually everything they do messes up their addresses and thus the bot... but whatever lol
next weeks patch will probably brake the bot though, since the new area + levelcap is coming

Kazaroth wrote:_key is a number and NOT ever == to MACRO. The intent of the if statement should be to use _name to test for the "MACRO" string.

To tell you the truth, I can't quite follow that bit of code but it sounds right. 'name' is the one that equals 'macro', not 'key'. The important question is, have you tested it and does it work now?

yes, the change in setting.lua from _key to _name in the if statement for testing MACRO worked.

I also found to have a next character execute the "<onLevelUp>" section in the profile, you need to reset the player.level_detect_levelup variable in the waypoint file. If you also need the "<onLoad>" items, more code is needed not listed here.

I thought you just needed to reinitialise the player as we did in the past.

Kazaroth wrote:I found the fix. In setting.lua, the if statement uses "_key" instead of "_name" in the following text

BEFORE

Code: Select all

		if( v.name ~= _nil and	-- empty entries from deleted settings.xml entries
		    v.key == _key  and
		    string.upper(_key) ~= "MACRO" and	-- hotkey MACRO is allowed to set more then once
		    v.modifier == _modifier ) then

AFTER

Code: Select all

		if( v.name ~= _nil and	-- empty entries from deleted settings.xml entries
		    v.key == _key  and
		    string.upper(_name) ~= "MACRO" and	-- hotkey MACRO is allowed to set more then once
		    v.modifier == _modifier ) then

_key is a number and NOT ever == to MACRO. The intent of the if statement should be to use _name to test for the "MACRO" string.

I'm doing a commit so I re-examined this. I think '_key' is correct. What that bit of code is doing is looking for entries in 'check_keys' that have the same hotkeys. 'MACRO' is a valid value for 'key' and just means that it uses a macro instead of pressing a key. You can have more than one function using 'MACRO' so that's why it's omitted from the check. It's not really being used at the moment, I think, but it doesn't hurt to leave it as it is.

So I think your issue is something else. The commit I'm going to do resolves some reloging issues so I suggest, when I commit, update and see if that helps.

Edit: I've committed to revision 674.
http://www.solarstrike.net/phpBB3/viewt ... =30&t=3171