SolarStrike Software

"The communication to the game with the MACRO function seems not to work.
Define ingame an empty macro at the FIRST macro space and assign that to your MACRO hotkey '0'."

I finally decided to download and set up the bot and this is one of the error messages I received. I did (well, I think I did) exactly what it asked and set up a blank macro and placed in on the '0' space on the action bar. Is this correct?

It still gave me that error though.

That is where I placed it. It adds the following code to it: However, it still gives me the same error even after it adds that.

try reverting it to an older reversion..

This is how it looks on my screen. The text in the macro is what was put there when I ran createpath.lue

thanks for the detailed bug description. the bug is that some function in createpath.lua is trying to run "RoMScript("000");" witch is bad. debugging.. hmm

i couldn't figure out the problem, because i didn't get it. please revert createpath.lua to reversion 217

Ok. 217 does seem to work for me. I haven't actually created any waypoints yet, but the options to do so are now available.

Avaryan wrote:It still gave me that error though.

I can reproduce it by starting the cratepath.lua . It seems some timing thing. Sometimes it works. Mostly not. I set a 'yrest(2000)' before the check in settings.lua. It seems to help, so I thought perhaps a cooldown thing preventing from executing the macro? But I only helps sometimes. At 50% the error is still there.

I checked it after getting the error. The submited macro is stored in the place 1. But there are no return values at macro place 2. So the macro seems only to be stored, but not executed. If I press the macro key manual after the error, the right return values are stored in place 2.

I don't understand, why that problem don't occurs, if we start the normal bot.lua ?

With SVN 128 I added a 'attach':Hope that's the right solution. At least I don't get the error anymore.

d003232 wrote:If I press the macro key manual after the error, the right return values are stored in place 2.

Yes, I also had that happen when I was running the latest revision.

No problems since I rolled back to the one you suggested, so I suggest looking at what areas of the code where changed from that version to the current.

Avaryan wrote:No problems since I rolled back to the one you suggested, so I suggest looking at what areas of the code where changed from that version to the current.

Sould be solved with the last SVN version 228.