MicroMacro x64

[beanybabe]

Micromacro x64 bit

This is mm version 2 x64 and rom bot is not compatible.

http://www.solarstrike.net/project/micromacro

[beanybabe]

I gave this a try and there seems to be a difference in how it sees the home folder.

I created a folder structure like this:
C:\micromacro.x64\scripts\rom

I edited the rombot start to be like this

Code: Select all

@echo off
START ../../MM2-64.exe "%~dp0/bot.lua"

This error appears.

MicroMacro v1.9.23 64-bit version with Open CV extension
SolarStrike Software http://www.solarstrike.net
cannot open config.lua: No such file or directory
Failed loading config file. Err code: 10 (File error)
Press any key to continue . . .





On the 32 bit version when run get a error but the bot still works
This is my 32 path C:\micromacro\scripts\rom

MicroMacro v1.04.174
SolarStrike Software
http://www.solarstrike.net
Opening bot.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
-------------------------------------------------------------------------------
Installing userfunctions. wrong dir

We read the hotkey settings from your bindings.txt file C:\Users\knarf\My Docume
... and so on

I have always wondered why message "wrong dir" appears while it still runs.

[BlubBlab]

Ups yeah that version don't like directory changes I will look into it.

EDIT: When I'm not looking wrong you compare MM1 32-bit and MM2 64-bit

I took a look into the code MM2 will simply try to load from the directory it "thinks it is" in and when MM2 don't found config.lua it stops.
I suspect you can reproduce the error with MM2 -32 bit from admin.

I'm not an expert in this perhaps you can stop the problem by setting up the enviorment for the exe.

EDIT2: Otherwise copy simply config.lua into the directory where your batch file is.

[Administrator]

RoM bot will not run on MicroMacro 2 (currently 1.9 while in development) as the entire architecture has changed.

As for the directory issue, I think that's because it isn't setting the working directory before trying to load files. You could get around this temporarily by using the "cd" command to change to the directory before launching the executable.

[beanybabe]

ok It did not say micromacro 2-x64 so I thought you had made a 64bit of mm1 you might add a version or make a different name for new one.

[BlubBlab]

They have different names and different version numbers but I think the 2.x is for the final version when everything we need is part of the MM and tested. I agree that the only confusing part I also shut see how I get a slightly different version number because the MM I built had some extra features.

[Administrator]

I've fixed the error with it not loading the config file when running from outside the MicroMacro directory, but I'm not entirely sure what I should set as the default path.
I think most people would be familiar with just using MicroMacro's path automatically, ie:

Code: Select all

START C:/somedirectory/micromacro/micromacro.exe myscript.lua

However, the "normal" (standard) behavior is that it should use whichever directory the command was called from, so if you called it from C:/, it should attempt to load the script from C:/.

What do you guys think?

[BlubBlab]

You mean because the script directory behave differently than the search of config.lua?
Yeah you can unplug-it. He/she doesn't came behind the config.lua problem but in my test I must say scripts/logs doesn't behave differently from config.lua at least in my tests and doing the opposite finding where you .exe lies.

I didn't found anything about on top of that in windows conventions it is the caller who has to make sure that the runtime environment is setup correctly.

[Administrator]

Well, the config and log files should always be relative to the executable (micromacro.exe). I just wasn't sure how to handle the scripts. It is standard that you do not change the CWD when executing a program through the CLI, so if you ran this command:

Code: Select all

C:/micromacro/micromacro.exe myscript.lua

It would attempt to run myscript.lua from whichever folder you called the command from. So, for example, I've got this batch file in D:/

Code: Select all

START D:\sync\micromacro2\micromacro.exe D:\sync\micromacro2\scripts\test4.lua

Alternatively, you could do this:

Code: Select all

cd D:\sync\micromacro2 && micromacro.exe scripts/test4.lua

Which would change directory to the location of micromacro.exe and attempt to load the script as a relative offset from there.

[rock5]

Or

Code: Select all

cd D:\sync\micromacro2\scripts
D:\sync\micromacro2\micromacro.exe test4.lua

Makes sense.

[BlubBlab]

The only problem I see is when I run

Code: Select all

C:/micromacro/micromacro.exe myscript.lua

I could mean that I want to run:

Code: Select all

C:/micromacro/micromacro.exe scripts/myscript.lua

Basically when you run without absolute path and you don't find it take a look if there is a "scripts" directory in the current CWD an try there to find it.

[Administrator]

It's not so much that you have to specify the full path, but more that the path is relative to where you are calling the command from. If you are already in the MicroMacro directory, running scripts/<script> would be fine. If you are running a batch file from inside the script's directory, you could just launch the script without any path. This is consistent with pretty much every command-line driven software.