SolarStrike Software

I do see that there was an update for the game, but everything seems to be working fine for me. No address changes or anything. I would first recommend that you update the scripts to make sure you've got the latest stuff. If you're running the latest scripts and still have problems, please run rom-b...

If you have the latest version of rom-bot, you should have the addrtest script. Do you have the scripts in a folder with a different name instead of "rom-bot"? i have addrtest.xml inside rom folder OK, so you just have the folder named "rom" instead of "rom-bot"? And, ...

When you go through the portal, the game reloads a bunch of stuff, which moves around things in memory. What I think is happening is that the skills are moved so when the bot tries to read information about the skill, it reads the wrong information (because it is reading from the old location, not n...

If you have the latest version of rom-bot, you should have the addrtest script. Do you have the scripts in a folder with a different name instead of "rom-bot"?

You've got a pretty old set of scripts, then. I know this has been a long-standing issue with you, but I don't recall if there's a reason you're using old scripts. I think you're playing on a private server; is that right? If so, what is the game version that shows at the title screen?

Yes, works fine on Windows 11.

You've definitely got something out of date. Compare your version of userfunction_swimhack to this one: https://github.com/SolarStrike-Software ... imhack.lua

Also, what happens if you run this:

Can one of you confirm if the fix is working for you?

I believe I've found the issue. You can update your scripts and it should start working as expected for you.


Alternatively, it can be manually fixed by changing addresses.skillbook.skill.as_level (line 234 of addresses.lua) to 0xc instead of 0x18.

Can I get more details? After the 3rd cast, it looks like it is getting a failed error for whatever reason; after that, does it stop using Flame for a few seconds, for the rest of the battle, or until you restart the bot? The debug message you've got there seems to be indicating that perhaps there's...

Have you tried running in a VM? If you're using Windows 10/11, try Hyper-V . It isn't a "full" VM (It is a hypervisor, instead) like VMWare or VirtualBox, but that's actually kind of a good thing -- it is a bit closer to the hardware so you're likely going to get better performance. Altern...

Got it. It seems the client is a very old version so I'm not entirely sure what to recommend here. You could start grabbing old versions of the scripts, run the addrupdate script, and hope for the best. But, doing so is going to be like looking for a needle in a haystack.

That game version does not look right to me. Are you playing on a private server?

Have you tried running rom-bot/addrupdate to see if it is able to patch the addresses?

Try this instead:

Try putting the settings.load() above settings.loadSkillSet(). Might help.

I'm not able to reproduce the issue after the updates I had made to functions.lua. You might have some luck removing these lines from that waypoint though: player = CPlayer.new(); player:update(); Since the call to waitForLoadingScreen() should take care of that for you now, everything should still ...

Open up functions.lua. Around line 1556, there should be this code: -- Check if fully in game by checking if RoMScript works if not 1234 == RoMScript("1234")then print("RoMScript isn't working. Lets wait until it works.") repeat rest(500) until 1234 == RoMScript("1234")...

I think I figured out what the problem was. It's a bit of a pain in the butt, and I'll skip out on explaining the issue, but I've just pushed up a patch. If you update your scripts, it should now be working for you. Please let me know what happens. The commit to fix this can be reviewed here: https:...

This wasn't a mistake on your end. I've provided an update that should resolve this issue. It isn't always accurate (some items have the durability available on the item struct, while others have a seemingly random value and use a durability of 80 -- exactly what determines which value to use is unk...

I think you misunderstood; you need to move the call, not remove it. It should look like this: if dqCount == 10 then sendMacro("}LoginNextToon=true;a={") sendMacro("Logout();"); waitForLoadingScreen(); player = CPlayer.new(); player:update(); settings.loadSkillSet(player.Class1);...