Also I have just realized that you said it was a multiplayer game. This can be an issue. This is where the discussion of server side vs client side comes up. If your lucky the ammo and enemy health address is client side and isn't dependent on the game servers. Most likely this is not the case. If they are server side unfortunately there isn't much you can do. I would look into packet editing if it is server side.
Sorry for double posting, but I just want to help on this matter. This isn't intended as rude by any stretch of the imagination as you're blatantly here trying to help, but can you think of a circumstance where the enemys health being sent to every game client would ever help the game designers? I'm not saying that they don't do it to stop hacking, but merely that it serves no purpose. Having everybody simultaneously receiving and editing enemys health bars would be a burden on the server. Imagine BF3 or whatever the latest is, with 64 players. Having my client constantly (as they could change at any fraction of a second) downloading everyones health bar, and then when I shoot having to dictate what effect my weapon would have on someones health bar then to send it out, would be massive overload for all the clients. If anything, things like this are exactly what the server is there for; to be the central hub of information for the clients. Wouldn't it be much more beneficial for the server to decide if someones health bar changes, then kind of shout across the network "Hey guys, player number 48's health has changed, everyone download that one".
However, still looking at the same logic, some things make sense for us to store. One of these isn't ammo, but more the reload trigger. Sure, they will sometimes store our ammo count for a variety of reasons, but do we really need the server to be sitting there telling us when we need to reload considering all a reload is from a games perspective is a pause and a graphical animation? They might, in the interest of hacking, but again that's just server burden.
For games to run smoothly, everyone basically needs to do as much as they can themselves and transmit as little as possible. They have to find a compromise, and usually common sense will dictate that.
and about no reload .. i need it to use witg RPG .. it have to reload every 1 shot
Another quick thing about game design here. Don't you think it's much more convenient to have one address for your current pool of ammo, and one reload trigger, rather than one for every weapon? Imagine CoD:MW2 (or whatever the latest is), where you can hold from a choice of like 30 weapons with varying mods... Do you think they programmed in a reload trigger for each one? Or would it make more sense if they had one reload trigger that is shared?
Let's say address 0x550000 is your ammo in your current pool. All what will happen is, dependant on different weapons there will be a command when switch weapon like this:
for an m16
mov [0x550000], 30
or for an RPG
mov [0x550000], 1
Obviously these won't tend to be hard numbers, but stored in the weapon structure we were talking about earlier.
Our firing sequence will then kind of go:
mov ecx, [0x550000]
cmp ecx, 0
If we nop the jump, it may not be enough as we still have 0 ammo in our weapon. However, if we nop the dec command, our ammo will never decrease and so never hit the reload_trigger jump.
My basic point here is, just because you want the non-reload hack on the RPG, doesn't mean you can't use another weapon to achieve it.
To point out to the more knowledgeable among you, I'm aware that the actual code would never be this simple, however I'm just using it to get the point across