attaching to game/programme question.

[lisa]

I figure I should post this question here as opposed to the topic I started for GF.

Question is to do with attaching to the game.

If I don't attach MM and I just click the game to give it focus then keyboard presses work fine.

Code: Select all

keyboardPress(key.VK_9)

It also does the keypresses in any window I click on though.

So I am trying to attach MM to the game and hopefully the keypresses are only done in the game.
I have been trying different things and they all seem to print that MM is attached to the game but the keypresses arn't done anymore even when I click the game and give it focus. It still recognizes when I do keypresses in game though.

Code: Select all

local windowList = findWindowList("Grand Fantasia", "DJO_CLASS");
print(windowList[1])
if( #windowList == 0 ) then
	print("You need to run GF first!")
end

function getWin()
	if( __WIN == nil ) then
  		__WIN = windowList[1]
	end

	return __WIN;
end	

attach(getWin())
print(getAttachedHwnd())

I did it like this to allow for choosing a window from mulitple games later. For now I just do with 1 game and windowList[1]

Anyway so it prints

Code: Select all

Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
-------------------------------------------------------
263534
263534

So I must be attached to the right window but it just isn't doing the keypresses to the window. I even opened up the chat interface and no characters were done.

So if game isn't attached then the keypresses are fine, if game is attached then it doesn't work.

I came across this while doing some searching.

Check the log to see if attach() failed. Try also running it in un-attached mode (but this requires the game window to be focused) to see if the key presses go through. Every game is programmed differently, and so it is impossible to write one function that works on everything. This game just seems to not use the normal input queue, and, instead, uses it's own. This prevents MicroMacro from jamming false key presses into the queue.

So I'll just assume for now I haven't actually done anything wrong and that in order for the keypresses to work when attached it may need to be recoded to suit this game.
Not huge a priority for me, I was hoping I just did something incorrect and was an easy fix lol
I'll try changing the key delay and see how that goes.

[Administrator]

And log.txt doesn't show it failed? Well, I'm guessing it doesn't, since the attached HWND should only be set if it succeeds.

Your code looks right to me, but try this just in case:

Code: Select all

attach( findWindow("Grand Fantasia") );

And see if that helps at all. Obviously you'd need to close any window with "Grand Fantasia" in it's title that isn't the one you want.

You can also try this:

Code: Select all

attach( foregroundWindow() );

And make sure you have the Grand Fantasia window on top when you start the script. This should help debug the issue, at least.

[lisa]

Yeah I had tried using

Code: Select all

attach( findWindow("Grand Fantasia") );

It was the same thing, it says it is attached but the keypresses don't go through.

Code: Select all

print(getAttachedHwnd())

is printing a number as opposed to 0, which I read in the MM manual meaning it is attached to something.
when I use

Code: Select all

print(windowList[1])
print(getAttachedHwnd())

it prints the same number for both, so I must have it attached to the game.

I'll try attach(foregroundWindow()); just incase it does something differently.

It just seems weird to me it does the keypresses in game if I don't attach and in focus but it doesn't do them if I do attach, even when game has focus.

I tried playing with the delays but no joy.

Log.txt doesn't mention anything about the attaching, so no errors.

Code: Select all

Fri Nov 11 01:42:46 2011 : Execution success

Fri Nov 11 01:43:12 2011 : Executing script 'createpath.lua'
----------------------------------------------------------------


Fri Nov 11 01:43:58 2011 : Execution success

Fri Nov 11 01:48:33 2011 : Executing script 'bot.lua'
----------------------------------------------------------------

Fri Nov 11 01:50:05 2011 : Execution success

[Administrator]

Well, the game could use a number of different inputs. That's why I recommend attaching to the foreground window. That will hopefully let you know whether it is finding the wrong input for that window or not. Winspector should also give you a list of possible inputs.

It could be that it is attaching, but then the game has some sort of protection that immediately detatches it, or it could just be blocking the input attachment while returning a false positive.

[lisa]

K I used foreground

Code: Select all

Fri Nov 11 12:13:26 2011 : Executing script 'bot.lua'
--------------------------------------------------------------------------


Fri Nov 11 12:14:17 2011 : Execution success

and MM printed the same numbers for the window and what it attached to.
984130
984130

I'll have a play with Winspector

[lisa]

Ok been doing some testing with WInspector, not sure if I am on the right track but here is what I have been doing.

I check messages for GF and filtered out everything except keydown, keyup and char.
just doing 1 simple keypress.

Code: Select all

keyboardPress(key.VK_8)

When attached to GF using foreground(well I assume it is still attached)
I get

Code: Select all

WM_KEYDOWN
Virtual Key: 0
WM_KEYDOWN
Virtual Key: Unknown key(56)

then same order for KEYUP

Now when I do same thing but not attached message says this

Code: Select all

WM_KEYDOWN
Virtual Key: Unknown key (255)
WM_KEYDOWN
Virtual key: Unknown key (56)

then reverse order for KEYUP

Ok so I look at

Code: Select all

-->
WM_GETTEXT
Text buffer pointer: 0x0012e900
Text buffer length: 255
<--
WM_GETTEXT
Text: Grand Fantasia
Text Length: 14

Same for both attached and not attached.
Longer I look at it the 14 is just the number of text in the actual name "Grand Fantasia" lmao

So to me the only difference is when attached it has a Virtual key: 0 instead of 255.

So I am guessing it returns 0 because there are no keys it recognises?
Not sure where to go from here, test if it is being detached somehow?

[lisa]

Maybe I did just do something wrong, no idea anymore.

Ok did more testing but of a different kind.

I had notepad++ as foreground as so it attached to it.
it wouldn't type any of the characters but if I pressed CTRL it would recognize the press. So when MM did tab while I had CTRL pressed it would bring up the choose tab option. Which is CTRL + TAB.

I did the same for normal Notepad and it did similar.

I made MM the foreground when starting and it set atteched to 0, I assume it checks for itself so it doesn't attach to itself. Anyway while it was 0 and I assume not attached to anything I click Notepad and all characters are done on screen, I do same for Notepad++ and again text is done. I click GF and it performs the tasks according to the keypresses.

So I am kind of at a loss, seems that keypresses are done when not attached but if I attach it to any programe the normal press isn't done UNLESS I am doing a keypress myself.

Tested this in game and different results, I moved a skill to me CTRL + 6 and then got MM to use 6 while I held down CTRL, it didn't do the skill.

[Administrator]

That seems really strange to me. I wouldn't worry about the keys 0 and 255; they shouldn't really do anything important and could just be caused by differences in how the input queue is being used.

I had notepad++ as foreground as so it attached to it.
it wouldn't type any of the characters but if I pressed CTRL it would recognize the press. So when MM did tab while I had CTRL pressed it would bring up the choose tab option. Which is CTRL + TAB.

I did the same for normal Notepad and it did similar.

This is caused by attaching to the wrong input. A window can have several different input areas. In notepad, you've got the menus, and you've got the text area. Try attaching to the window like this:

Code: Select all

attach(findWindow("Untitled - Notepad", "Edit"));

[lisa]

That attach for notepad worked perfectly.

Ok I think I am starting to understand, had a look at processor and found that Notepad has
ab| Edit
Which I assume ab| means for keys or characters and the name is Edit.

There wasn't anything for the game though, pic attached showing notepad and GF.

Any way to use the text buffer pointer?
I noticed it is the same each time/day I have been looking.
Well there are 2 but they are the same each day
0x0012e900
and
0x0012f220

220 when I click GF and 900 when I click another programme, so I guess gain focus and lose focus.

[Administrator]

It could just be checking to see if it is in the foreground before it'll accept input. I've seen that in a few games.

[lisa]

Something I found interesting today, I have been having issues with including files. It would always use my MicroMacro folder as the base folder.

It turned out that with a folder of just 2 characters was never being recognized. As soon as I made it 3 characters it worked fine and believe me I tried a lot of things before making folder name 3 characters.

Something to remember for if people have issues with making include() work.

Well for now I guess I will just go back to not attaching and making sure game is in foreground. I really don't know what else to look at for making it attach properly. Atleast it works fully in game if not attached and in focus.

[Administrator]

It turned out that with a folder of just 2 characters was never being recognized. As soon as I made it 3 characters it worked fine and believe me I tried a lot of things before making folder name 3 characters.

That sounds like a really weird bug. Can you provide any more information?

[lisa]

Micromacro/scripts/GF

include("settings.lua")
error would say there is no such file Micromacro/settings.lua

include("scripts/settings.lua")
error would say there is no such file Micromacro/scripts/settings.lua

include("scripts/GF/settings.lua")
error would say there is no such file Micromacro/settings.lua

So if there was a 2 character name for folder it would just go to the Micromacro as default folder and ignore anything else but the name of the file.

As soon as I changed folder name to GF1 it worked as it should.
include("settings.lua")

So maybe there is something in the include() function which is causing an error when folder has only 2 characters for a name. maybe it might be something in MM itself, I can't say for sure either way as I didn't try to determine the cause. I just changed folder name to have 3 characters.

[MiesterMan]

This is caused by attaching to the wrong input. A window can have several different input areas. In notepad, you've got the menus, and you've got the text area. Try attaching to the window like this:

Code: Select all

attach(findWindow("Untitled - Notepad", "Edit"));

I find this very interesting. Does this Winspector show all of these keyboard input possibilities? Is it like Spy++ or where can I find it?

[lisa]

The write up by the author said they didn't like parts of spy++ and so wrote their own, so I would say it is similar but also different.

http://www.softpedia.com/get/Security/S ... ctor.shtml

I used it on notepad++ and it showed around 8 ab| results, things like editing what to search for and such. So I would say it does usually show what it can find for inputs.

[Administrator]

Well, it seems like the short paths are working for me. Perhaps you were just using it wrong? include() goes by the current script execution path.

[lisa]

I did this by simply renaming the folder each time, so exact same files with just a folder name change.
ko
tp
tpo

Code: Select all

Script> ko/bot
Opening bot.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
----------------------------------------------------------------------------
12:7am - scripts\ko/bot.lua:1: cannot open C:/micromacro 609/addresses.lua: No such file or directory


Please enter the script name to run.
Type in 'exit' (without quotes) to exit.
Script> tp/bot
Opening bot.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
----------------------------------------------------------------------------
12:7am - scripts\tp/bot.lua:1: cannot open C:/micromacro 609/addresses.lua: No such file or directory


Please enter the script name to run.
Type in 'exit' (without quotes) to exit.
Script> tpo/bot
Opening bot.lua...
Starting script execution - Press CTRL+C to exit.
Press CTRL+L to cancel execution and load a new script.
----------------------------------------------------------------------------
Press the (End) key to stop/pause the script.
You can resume with the (Delete) key.
In Combat

works with 3 character folder name, doesn't work with 2.
using

Code: Select all

include("addresses.lua");
include("settings.lua");
include("functions.lua");

[lisa]

Different game, similar issue =(

If the game has focus then key presses are done without issue, if game isn't focus then the character doesn't move.

Posting just in case you had any thoughts as to getting past this issue since last time.

When MM does the key presses it does a 0 and then the actual key every time, not sure why.

Winspy messages says the same regardless of if game had focus and keypress was actually performed

I am just going to assume that the game is checking it has focus before allowing any key presses to be done =(

[Administrator]

I looked into it and I think that the VK 0 input could be caused by posting the modifier even when it isn't needed. It shouldn't have any real effect, but you might as well try. I've included a fixed copy of micromacro.exe.

So, if you attach to the game and keep it in the foreground, it accepts input? That is strange and does seem to indicate that the game is checking if it is in the foreground before attempting to accept input. That can somewhat easily be patched out.

[lisa]

Ok tested and it no longer does the 0 keypress anymore, so that is good.

Game still won't move unless it has focus though.

If it has focus it does keypresses just fine, same as GF, when it doesn't have focus it doesn't perform the action the keypress would do.

Tested with a text box open in game, so if any key presses were done then it should type in the text area, still nothing.

So winspy says the key presses are being done but if game doesn't have focus then it just doesn't actually do them.