This code keeps returning a zero, even if I'm inside a game playing when it should be returning a 01... I checked WinHack to look at the 645E54 offset, and the hex address shows 01 as it should. When I obtain the ReadProcess value, it's always blank. Is there a way I can get the hex address itself (01)? Or is there a better way to identify if the user is in a game?

The program emits a type mismatch error in regards to the Vala variable. When I change the variable to a long, the program executes fine, but the variable has nothing stored inside it (meaning it displays zero, even if SC's offset that I'm obtaining it from has 01 in it)...

Here's a screenshot of what I'm talking about:

*Screenshot removed due to issue being resolved*

Before you sink too much more time into this, I should point out that you'll have much finer grained control (and likely greater success) if you load directly into the Starcraft process, rather than trying to perform {Read,Write}ProcessMemory calls from outside.  Of course, Visual Basic is a horrible language [for injecting into other processes].

[quote author=Kp link=topic=11896.msg116555#msg116555 date=1119218595]
Before you sink too much more time into this, I should point out that you'll have much finer grained control (and likely greater success) if you load directly into the Starcraft process, rather than trying to perform {Read,Write}ProcessMemory calls from outside.  [/quote]

Care to explain?

The two values you're pointing to on that screenshot are the same. The display on the left shows the value of the byte, 0x01, and the display on the right shows its ASCII representation. Since 0x01 is a control character and not a printable character, the display shows nothing.

Most programs would show a dot or a square or something, but yours appears not to.

[quote author=Arta[vL] link=topic=11896.msg116559#msg116559 date=1119219895]
The two values you're pointing to on that screenshot are the same. The display on the left shows the value of the byte, 0x01, and the display on the right shows its ASCII representation. Since 0x01 is a control character and not a printable character, the display shows nothing.

Most programs would show a dot or a square or something, but yours appears not to.
[/quote]

Exactly, so how do I have my RPM determine if the state is 0x01 or 0x00?

[code]If Vara = Chr(&H1) Then[/code]

[quote author=rabbit link=topic=11896.msg116562#msg116562 date=1119221090]
[code]If Vara = Chr(&H1) Then[/code]
[/quote]

To do that, I had to change Vala to a string (Dim Vala as String). The code executed without a problem, but it returned with nothing. It said Unknown Status:. As in, blank string, there's nothing, not even a single byte of data in it... This is the code I have so far:

[code]   
    'Let's make sure the person is in a game.
   
    Dim Vala As String
   
    ReadProcessMemory pHandle, &H645E54, Vala, &H1, 0&
   
    'MsgBox Vala
    'Exit Sub
   
    If Vala = Chr$(&H1) Then
        MsgBox "Game Status: Active"
    ElseIf Vala = Chr$(&H0) Then
        MsgBox "Game Status: Inactive"
    Else
        MsgBox "Unknown status:" & Vala
    End If[/code]

By the way, thanks for helping thus far!

[quote author=Kyro link=topic=11896.msg116556#msg116556 date=1119218731][quote author=Kp link=topic=11896.msg116555#msg116555 date=1119218595]Before you sink too much more time into this, I should point out that you'll have much finer grained control (and likely greater success) if you load directly into the Starcraft process, rather than trying to perform {Read,Write}ProcessMemory calls from outside.  [/quote]Care to explain?[/quote]

Yours is one of the nicer request-for-clarifications I've received, so I don't intend this to be insulting, but: I thought I was quite clear.  On what do you want me to elaborate?

[quote author=Kp link=topic=11896.msg116566#msg116566 date=1119221576]
[quote author=Kyro link=topic=11896.msg116556#msg116556 date=1119218731][quote author=Kp link=topic=11896.msg116555#msg116555 date=1119218595]Before you sink too much more time into this, I should point out that you'll have much finer grained control (and likely greater success) if you load directly into the Starcraft process, rather than trying to perform {Read,Write}ProcessMemory calls from outside.  [/quote]Care to explain?[/quote]

Yours is one of the nicer request-for-clarifications I've received, so I don't intend this to be insulting, but: I thought I was quite clear.  On what do you want me to elaborate?
[/quote]

That's because I'm here to learn, not to offend. I can't learn if I annoy everyone who's trying to help by being dense. I was asking you elaborate on what you mean by loading directly into the Starcraft process, rather than performing memory calls from VB-- I'm not understanding what you mean by that, and how I'd do that...

This problem has been solved thanks to Dyndrilliac at BWHacks.com forums.

For the solution, feel free to read the thread:

http://www.bwhacks.com/forums/showthread.php?t=5023

Kp- I'm still interested in how I can handle this better, so I'm open to any suggestion you may have to make- I'm always looking for ways to improve!

[quote author=Kyro link=topic=11896.msg116567#msg116567 date=1119222408]I was asking you elaborate on what you mean by loading directly into the Starcraft process, rather than performing memory calls from VB-- I'm not understanding what you mean by that, and how I'd do that.[/quote]

Well, it'll be much easier to access Starcraft memory if you have code executing in the context of the Starcraft process.  As it is, your VB application sits outside the process and peeks/pokes using Windows API calls; I was suggesting to have your code execute as part of Starcraft, so that you can read/write its variables directly.  As for how to do that, look into SampleHDL.

Ahhh... C++... I don't have C++, and I don't know any C++... Bad, I know-- heh.

Get Minimalist GNU for Windows (free C compiler).

Yay, someone else who uses mingw!  I'm still working on injecting code and adding "functionality" to other programs, Kyro.  If you would like to work with me, I wouldn't mind.

Only one problem-- I know absolutely no C++ :-P I once took a class in programming in C++, but it's been over two years since- and I've forgotten everything I learned... So I'd be annoying the heck out of you due to my newbieness...  :P

Can't you just /whoami and check if you're in game :P

Normally, I'd just not reply to this question since it's obvious why-- but just in case it isn't obvious to others:

1. To ensure the code only executes while game is active. Otherwise either Starcraft or the program itself crashes when it attempts to write to memory (if button is accidentally pressed-- don't ask me- I've heard of people who 'accidentally' formatted their drive...). Call it a failsafe, if you will.

2. Because it's just easier to use an automatic failsafe, rather than a manual method.  :P

Also the state that /whois commands show is determined by a single packet sent by the client, and is in no way reliable.

[quote author=Kp link=topic=11896.msg116578#msg116578 date=1119226462]
[quote author=Kyro link=topic=11896.msg116567#msg116567 date=1119222408]I was asking you elaborate on what you mean by loading directly into the Starcraft process, rather than performing memory calls from VB-- I'm not understanding what you mean by that, and how I'd do that.[/quote]

Well, it'll be much easier to access Starcraft memory if you have code executing in the context of the Starcraft process.  As it is, your VB application sits outside the process and peeks/pokes using Windows API calls; I was suggesting to have your code execute as part of Starcraft, so that you can read/write its variables directly.  As for how to do that, look into SampleHDL.
[/quote]

About those HDL dlls, wasent there another program that loaded the HDL's for you?
I cant even remember the last time I seen one of these 8\


Edit: Found my answer, wasent the program I thought it was make no wonder I didnt remember it, it's pretty damn old lol.

My question was meant more of an obvious joke/easy way out :)