Cheat Engine

[Dlve]

Well, I finally found the right address that controls the gauge phew. My biggest mistake was thinking that the gauge of my character and the computer's character were connected. That lead me to the address which controlled the display. One other mistake was thinking that the value remained the same at a certain point when it didn't.

Probably the best thing to do when searching for the right address for gauges is to always assume that it's never the same value again, meaning to always use "changed value". The value may not be the same at maximum the next time, the same thing when it's empty. The other thing is to look for changing values only when the gauge is moving, at least at first. Well that's my advice anyway.

By the way I was trying to make a script when address's value type was 8 byte, how can I use mov correctly for a case like this:

[Rydian]

For #2, that's one of the things I told you.

As far as moving 8-byte values I'm not sure exactly as I've never need to do it other than for doubles, in which case I use.

[Dlve]

[Rydian]

Double is just double-precision floating-point, which means more digits, but floats are inherently slightly inaccurate, so if you mean that the hex/int representation is different (but it still works fine), then it's nothing to be alarmed about as far as I know.

[Dlve]

[Dlve]

You know, somebody could at least tell me if it's not possible.

[++METHOS]

Assuming you have the correct address...

1. When writing a script, let CE build it for you. It will determine how many NOP's to use. If you do not use the correct amount, the game may be extremely buggy and/or crash.
2. Moving 8 byte values...there are several ways to do it. Did you try qword? You can mov esi into a custom address and manipulate it like you would a pointer address (and just set value type to 8 byte). You can also try 4 byte offsets, if there are multiple addresses:

[Dlve]

[++METHOS]

Activate script. Once script is activated, double click on the BASE ADDRESS entry and change it to a pointer. In the text box (for address), type in:

base

Change the offset to +254 and click okay.

Of course, this only works well if the instruction is being accessed several times per second. If it is, just make sure that the value type is set to 8 byte (should be, already). If so, set and/or freeze the value to whatever you want.

[Dlve]

Oh, you meant that way. I never thought of that because I thought it would work the same way as just freezing the address once I've found it. As a matter of fact it works the same way and I have to enable the script first and start serving before this works, so it is not a very efficient way. The instruction I'm using is being accessed several times but only when the gauge shows up. There is one instruction that accesses the address even when the gauge is not there but that one accesses hundreds of other addresses so I don't want to touch it.

Could you show me another way?

[++METHOS]

Have you tried manipulating multiple, 4 byte addresses to achieve the desired effect (see script above). Not sure why you received an error with qword (use hex). Alternatively, you can:

[Dlve]

I have completed the tutorial. The cmp part in the script I've given you is there for filtering purposes, so I have a basic understanding of filteing. Actually ++METHOS you are the one who taught me how to filter.

If there were like 10 maybe as much as 20 addresses then I might be able to filter them but when there are hundreds of them, it gets real tricky. Even if I could filter them, I would have to always write the value I want to use. The biggest problem I have just freezing the value, is that the gauge gets funky.

I haven't tried that multiple addresses advice because I understood that I would need more than one address. None of the instructions are accessing other addresses that are connected to the gauge.

Using qword with hex doesn't change a thing, I still get "code is not injectable". This happens when I try it with that push command as well.

I'm not using this instruction either since you told that the NOP count should not be messed with. I have a couple others that I need the 8 byte values for.

[++METHOS]

A couple of things...

1. Filtering out addresses is easy...even if there are hundreds of addresses; it just takes time.
2. If freezing the value doesn't work, or, doesn't always work as it should, then you may need to change your approach or find a different address, altogether.
3. You say you would always have to write the value...not sure what you mean. If freezing the value causes problems, have you tried just nop'ing the instruction that writes to your targeted address?
4. Regarding multiple addresses...you said that you needed to manipulate multiple addresses for the cheat to function properly. Even though the instruction may appear to only be accessing one address, those other addresses in that structure are being manipulated some how. For example, the targeted address is at offset +254, but if you manipulate that address (and) the address at offset +250 (or +258), then that same instruction can be used to access all addresses that pertain to your targeted value(s).
5. The code should be injectable...are you using CE 6.3?
6. Not sure what you're referring to about the NOP...you can still NOP the instruction without altering the NOP's necessary to maintain byte structure. By letting CE build the script for you, that is covered. So, to NOP the instruction for your targeted address, you would just do this (assuming this is the instruction that 'writes' to your address and not 'accesses' it):

[Dlve]

[++METHOS]