Automatic 'login' script

[ZZZZZ]

i'm probably missing some really obvious setting, but i'm stuck on launching a batch file through rombot. Basically I want to log in an alt, and if siege is active, it'll log in the rest. I have got everything figured out except for actually launching the batch file. I tried using this

Code: Select all

local path = getExecutionPath().."/Siege.bat";  os.execute("START "..path.."")

but instead of running as it usually does it tries to execute each line in Command Prompt, in the same manner it did when I was trying to use Task Scheduler without specifying its execution path, aka the "Start in" box as you (R5) stated.

Either that or how would I start separate MM windows/rom clients from another? I know you can use login(char,acc,link) but it only starts a new client, doesn't open a new MM window.

~~ I just solved it for now by going with my original solution to Task Scheduler

Code: Select all

START E:/micromacro/micromacro.exe "E:/micromacro/scripts/rom/login.lua"

[noobbotter]

I guess the easiest way to ask how to do what I need to ask is to explain what I'm doing and what I want to happen.

I typically run 2 bots at once. I use a separate batch file to launch both bots and set their windows appropriately. My scripts will each run through 2 accounts (for 4 accounts total). I have my client restart settings set to restart the client after every other character. After each one runs through and finishes the second character, when the clients restart they restart at the same normal position that ROM normally starts in instead of where the batch file puts the windows.

How can I make them restart the client and keep the windows where they were at when the batch file originally launched? I would imagine it would have to be somewhere in my waypoint file that initiates the client restart? But I don't know what command could set the window size and position or where to put it.

Here's my "loadnext" waypoint file minus the logging I have it doing:

Code: Select all

When_Finished = "charlist"
		-- "end" to end script, "relog" to log next character, "charlist" to log next in 'charlist'.
	
	CharList = {{
		{account=7 , chars=  {1,2,3,4,5,6,7,8}},
		{account=19 , chars= {1,2,3,4,5,6,7,8}},
	},{
		{account=12 , chars= {1,2,3,4,5,6,7,8}},
		{account=24 , chars= {1,2,3,4,5,6,7,8}},
	}}
	
	SetRestartClientSettings(2, "myrom")
	NextFileToLoad = "Elves/Puries/Daily" -- File to load after changing character.
	--====================--

	if When_Finished == "relog" then
		sendMacro("}LoginNextToon=true;a={")
		sendMacro("Logout();");
		waitForLoadingScreen();
		loadProfile()
		loadPaths(NextFileToLoad);
	elseif When_Finished == "charlist" then
		SetCharList(CharList)
		LoginNextChar()
		loadProfile()
		loadPaths(NextFileToLoad);
	elseif When_Finished == "end" then
			error("Ending script",2)
	else
		error("'When_Finished' option is invalid",0)
	end

[rock5]

You can use setWindowPos http://www.solarstrike.net/wiki/index.p ... wPos.28.29.

Something like

Code: Select all

setWindowPos(getWin(),0,0,400,300)

You would need to know what client it is though. Maybe choose based on the account, eg.

Code: Select all

local acc = getAcc()
if acc == 7 or acc == 19 then
    setWindowPos(getWin(),0,0,400,300)
else
    setWindowPos(getWin(),400,0,400,300)
end

This would have to be put after it changes character, probably just after that code you posted.

[noobbotter]

Awesome. I'll try adding that in and see how it does. Thanks.

[noobbotter]

Ok, that code works good to set the window size and position after logging in a different character.

Right now I seem to be having an issue with the launch of the bot using the batch file. I don't know what changed but it wasn't setting the position or size. So I looked through this thread and found on that I think was version 4.(something)beta. When I tried that one, it resized the windows properly but was unable to click the account buttons (kept missing). I assume this is because I have the 65 button function and this is made for the one with more? or vice verse (can't remember which I have, but I only use 8 accounts total).

So after that, I went to the main page and downloaded the 3.5(?) version for 65 buttons. That one will log me in but it again does not resize the window (or the MM window), even though the window resizes properly when I use the SetWindowPos command.

Any ideas what's going wrong here?

[rock5]

I didn't include the 4.0 beta changes so it doesn't include the window resizing from the batch. I'll have to do an updated beta.

[rock5]

Ok, I confused myself for a second there because I thought you were talking about loginxml.

So I reread the posts. 4.0 beta is the version that resizes the windows. I didn't check but I assume I made it to work only with the 108 button version of loginxml. I don't support the 65 button version anymore. Why bother? If you want to use that feature you will have to update your loginxml to the latest version. I might look into adding support to the restart function to remember and then restore the window size.

[dx876234]

Hey, I'm using this to run a special client setup where client is linked in as 'bot' in scripts/rom directory.

When starting this by commandline with something like below it works nicely.

Code: Select all

micromacro.exe micromacro\scripts\rom\login.lua acc:1 char:1 client:bot path:myscript

But, if I print out the 'current_client_lnk_in_use' variable in the 'myscript' I get it as 'rom'.

So, after some tracing I figured out that login.lua loads the userfunctions_login.lua and in the 'login()' call the variable 'current_client_lnk_in_use' is set correctly. BUT, then bot.lua is called and loads the userfunctions_login.lua all over again which overwrites the 'current_client_lnk_in_use' variable.

This results in my normal client being started when the client auto restart limit is reached in 'userfunction_LoginNextChar' and everything failes due to different addon setup in the two client instances.

So, my small fix is to initialize the 'current_client_lnk_in_use' variable in userfunctions_login.lua as:

Code: Select all

-- Don't overwrite value set earlier in login process
if not current_client_lnk_in_use then
	current_client_lnk_in_use = "rom" -- Default client link name. It uses this link if no 'client' link is specified.
end

Best regards,
DX

P.S. Did the grid option ever make it out in beta?

[Desmond]

and did not understand why I do not know

[dx876234]

When starting a bot located in page 2 or higher of the login display, ie with account > 108, the userfunction_login.lua failes, ref s error message. As far as I can tell this is because the 'function clickLoginButton(account)' does not take into account that the account number can be bigger than 108.

Doing a simple mod operation does not really work as the correct page is not set in the accountlogin.lua, i.e. only accounts on page1 can be autologged.

And, since we cant run romscript in login window its not possible to switch page in userfunction_login.lua.

U mentioned u had a way to communicate with login window Rock, this would be a good place to start using it?

Best regards
DX

MicroMacro v1.04.167
SolarStrike Software
http://www.solarstrike.net
Opening login.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
-------------------------------------------------------------------------------

Rock5s 'login' script. Version 3.1

Starting client bot ...
Clicking account 217 ...
2015-02-07 17:46:32 - ...scripts/rom/userfunctions/loadsvn/userfunction_login.lu
a:180: attempt to index field '?' (a nil value)


Please enter the script name to run.
Type in 'exit' (without quotes) to exit.
Script>

[rock5]

Sorry but I still haven't had time to finish the new version. It's just that it's a big job to finish it and I have other things on my plate. So I can't split my focus.

[dx876234]

No problem, not my intention to nag

-dx

ps. if you could disclose how to communicate w. login display I could probably hack it up myself.

[rock5]

Sure. It's pretty much the same as RoMScript.

Write code to macro 1.
Press F9
fastLogin intercepts the F9 press, reads and runs the code in the macro and writes the results to macro 2.
The bot reads macro 2 for results.

The version I'm working on, that I don't have time to finish right now, is practically a whole rewrite of loginxml. I'm working on it in m rom4u folder. I doubt it's even startable at the moment.

But .... the version I have in my romeu folder is the version I was working on before I decided to do the rewrite. It seems to be working, has the code execution function and looks like it also has an auto generate characters option. I think it's working.

loginxml[3.71b1].7z

(22.52 KiB) Downloaded 160 times

If something doesn't work you could always just look at how I implemented the execution code and use that. As it is, I don't remember why I felt the need to do the rewrite so I don't know if there is something basically wrong with this version.

You would still need a function similar to RoMScript to use the new code. I pretty sure I wrote one. I can even see references to it. I called it loginScript. But I can't find it anywhere so it looks like I deleted it. I think it was basically a stripped down version of RoMScript that uses commandMacro of 1 and resultMacro of 2 and stripping out anything not relevant to login screens such as macro names and isInGame checks.

I hope you find this helpful.

[dx876234]

Thx a lot, Ill get on it

-dx

[dx876234]

So, I've brutally ripped out the macro communication from Rock's beta and inserted it into the current versions of login system and it works

The files attached is based on userfunction_login v. 3.5 http://solarstrike.net/phpBB3/viewtopic.php?f=27&t=4663 and fastlogin v. 3.7 http://solarstrike.net/phpBB3/viewtopic.php?f=27&t=1245

In the top of the userfunction you can select either traditional login process (mouse control) or macro based. Default is to use the macro based login.

With the macro based process the login does NOT grab the mouse.

To use, insert the accountlogin.lua and characterselect.lua into your Interface/LoginXML directory (remember to save accounts and put into new accountlogin), put the userfunction_lua in your userfunctions directory. Then the fastlogin code will work unmodified.

Thx to Rock for the the base code

-dx

[rock5]

So didn't the version I supplied work?

[dx876234]

Well, I'm planning to test it but I didn't want to much of a change in my prod environment

-dx

[leroy]

Im trying your version Dx but when i use the new/macro login it gives an error:

Code: Select all

Starting client rombot ...
Clicking account 27 ...
...romacro/scripts/rom/userfunctions/userfunction_login.lu
a:64: attempt to call global 'writeToMacro' (a nil value)

And it stops at the button screen.

When i copy the 'writeToMacro' function from macros.lua to the userfunction_login.lua file it gets to the char select screen and errors with:

Code: Select all

...romacro/scripts/rom/userfunctions/userfunction_login.lu
a:146: attempt to call global 'readMacro' (a nil value)

(line 146 is: local rawPart = readMacro(resultMacro)

When i copy the readMacro function to usefunction it works

So it seems (at least for me) the macros.lua file isnt loaded before the login proces.

I was using Rocks version with the window place/resize options, those options are lost now. And my added channel selection code too.
Now if only someone could combine all of this it would be awesome.

[rock5]

If it's like that maybe you could try including macro.lua at the top on userfunction_login.lua instead, using

Code: Select all

include("macros.lua");

or maybe it needs to be

Code: Select all

include("../macros.lua");

One day I'll finish my login updates. I'm happy to let dx876234 do updates but I've done massive changes that I'd hate to go to waste.

[dx876234]

Agreed w. Rock, mine was a quick-and-dirty proof of concept.

The main issue I'm struggling with is knowing when client is ready to receive macros after
starting it.

It turns out it initializes the login screen before loading the client lua files as well as
loading the 'specialwords', ie there is some machine dependent delay. A rest(20) does
the trick but is wasteful.

So, how to detect when client is ready to go?

-dx

PS. I discovered I forgot the bot/login.lua file, this include all the necessary files at start, sorry about that....