MicroMacro and WINE

[kornflake]

Hi, I'm trying to use MicroMacro on WINE (for rom) and it kind of works, actually seems to work fine (to the point that the character moves, attacks, levels up etc.). The only problem I have is the system used to retrieve user input, which seems not to work at all. I used autostart for the botting part, but waypoint path creation actually *needs* user input so I'm not able to use the feature (which was the one I was most interested in). Also when I start the path creation script it lists all the actions you can achieve with at the beginning between brackets the shortcut to activate it but the brackets are empty e.g. "() - Set waypoint bla bla".

So wouldn't it be possible to convert MicroMacro to use standard input for retrieving user input? Or create a Win32 application with a minimal GUI? This really seems like the only obstacle for having WINE support.

[Administrator]

The only problem with GUIs is that they tend to be quite bulky (except fltk, which is ugly and didn't completely work the way I wanted it to when I tested it with MicroMacro). A plugin might be added to incorporate a GUI for the RoMbot, but it's not currently being worked on. Trying to get some stuff worked through with my ISP, then I might look at it.

[kornflake]

Yes I know that's why I initially suggested using simply standard input.
I can see that maybe the reason you use async keyboard access is to maintain some kind of parallel processing Lua side with co-routines considering Lua doesn't have good support for multi-threading. But I think a good compromise could be obtained by having the main thread just handle input/output and keeping Lua and all the rest on a secondary thread with some basic textual communication layer between the two to keep from having complicate data marshalling. It should be relatively "easy" to implement, although I understand the big problem could be to port all of the current code to a new system of this kind.
A dirty way of doing it could be to have the main thread just loop over feeding on user input, save this input in a buffer and then within "KeyboardDevice::keyPressed" just check this buffer instead of calling the GetKeyState API. The buffer could just be duplicated and passed to the secondary thread, to avoid any need for locking (would be small amount of data anyway).
Setting this as a command line argument would allow windows users to keep everything as it is. Do you think this system could work?

[Administrator]

I think I've tried that before. If I remember correctly, WINE has a problem with using those functions while the application still in console mode. Not sure why. I couldn't get it to work at all.

[kornflake]

What functions? You mean GetKeyState? It is then possible that WINE uses internally the message queue to register what keys are pressed per-process. This could also explain why when I run it through WINE I don't get any error or "fixme" regarding these APIs. Anyway what I suggested was exactly to avoid using these functions at all.

[kornflake]

Ok I found a bit of an ugly hack solution but it seems to work. This uses the ReadConsoleInput group of APIs to read console input events. So I had it working by simply modifying the keyboard engine source files and no other modification was needed. I'm attaching here the new code so other people can make use of this. If you decide to put this in the official release, it would probably be better to enclose the new code under a command line argument option thus disabling it by default for windows users.
Oh by the way, note that the function "KeyboardDevice::getKeyName" was passing &buf to the std string constructor but buf is already a char*, not sure how it worked so far, maybe I'm missing something?

[Administrator]

Ok, cool, I'll take a look at this when I get the time. If I remember correctly, GetKeyState() worked fine, but TranslateMessage() and similar functions caused some issues while rune in WINE when in console mode (even though it worked fine in Windows). It has been awhile since I've looked at it, so that information might be inaccurate.

[kornflake]

Ok, I've been trying it out and noticed how very often (almost on every step) it spits out a red error message saying something about the player getting stuck and attempting to unstuck it, then starts running in circle a couple times and jumps, but this happens in the middle of empty flat areas with no obstacles. Could this be caused by WINE or does it happen on windows as well? Any idea on what could be the reasons?

[Administrator]

I've never seen it myself, but others have said they have had this. It could be caused by any number of things. As long as it doesn't happen constantly, I wouldn't worry about it.

[kornflake]

Well the problem as I said is that it does happen very often, almost every time it tries to reach a new waypoint. Also, I tried it on native windows and it seems to work pretty well so it is probably caused by WINE. Do you have any idea about what could cause this? What is it that it checks to determine if the player is stuck?

[Administrator]

My guess is that it is because of input delay. If your character hasn't moved within some given amount of time, it assumes the character is stuck. Anything that causes the game client to not receive input/freeze/slow down/anything else is likely to trigger the unstuck code. It should be modified in rom/classes/player.lua in function CPlayer:moveTo().

[kornflake]

Yes I got to this code and saw the 3 seconds limit. It is possibly because of the slower execution of code due to WINE emulation, so I'm gonna try to raise this up to 7 seconds and see if I get any difference.

Update: Ok, it didn't help at all.

One thing I noticed is that the character keeps rotating on itself a lot (basically like keeping Q or E continuously pressed), while I remember on windows it correctly rotated only the sufficient amount to point in the direction of the next waypoint. Does this mean anything?

Update 2: from a quick look at the relevant code is seems like the condition of target-direction and facing-direction is always bigger than 65 degrees, which means either that is taking the wrong value for any of the directions or the math gets screwed up for some reason. I will investigate this further and see if it can be fixed.

[Administrator]

It could be that the key release events aren't being caught by the game correctly for whatever reason, resulting in it continuing to spin past an acceptable angle. I would try setting the QUICK_TURN option to 'true' to avoid the thing completely.

[kornflake]

I did already try that option with the same result unfortunately. What I can say is that positions seem to be correct (I used the waypoint file created under WINE in windows and it worked), so that means that angles are created fine as well (unless the math module passing through wine was damaged, which I doubt). So what is left is as you said key no being relesed correctly (so the angle is always screwed up).
One solution that comes to mind could be to, instead of sending a key_release, to just send another keypress that makes the character stop, although I'm not sure the game has one. For instance X makes the character sit but then I don't recall if it moves automatically once you press other keys, also that would look a bit suspicious, a char that always sits and move.
Do you know of any command that can do that i.e. simply stop the character?

[Administrator]

Do you know of any command that can do that i.e. simply stop the character?

Sending a press (not another hold) instead of a release should work.

[kornflake]

That didn't help (well maybe I should update it in more places to make it work). One thing I noticed though is that even on windows it did that type of going around in circles and if I'm not mistaken it had something to do with the fact that I moved the game's window (I just restarted MicroMacro in windows and it worked). Does that make sense? How is the window position/size used? Maybe WINE gets this information wrong somehow. Also, to be more precise, the action the character does (both in WINE and windows when I moved the window) was going around but not staying in the same place, so more like pressing W *and* E or something like that.

[Administrator]

The window position is only used when using mouse clicks (such as when harvesting), so it probably has nothing to do with the problem you are experiencing. When moving the window, though, the game will typically not update information properly (until released), which could cause it to think there is a problem.

[kornflake]

Ok I'll try investigate this issue in more depth when I have more time and will let you know.

[Administrator]

I've been working with this a bit, and I would like to formally ask your permission to use your function in MicroMacro. However, I did notice one small thing. You changed

Code: Select all

if( GetKeyState(key) >> 8 )

To:

Code: Select all

if( GetKeyState(key) )

Is there any reason for this? That shows whether the key is toggled on or not (rather than being pressed), so I'm not sure this is what you had intended.