cmp [symbol], 0 unexpected outcome. (0) != 0 ?

[satandidnowrong]

What am I not under standing?
Been on this for a few days.
Trashgpt is no help. Neither is whiterabbit.
I'm watching videos and doing my best.

Code

If I replace newmem with

newmem:
mov dx, [inf_items_quantity]

The symbol functions.
It seems to be that some how value 0 does not equal 0.
It must be a different kind of zero? I have tried using #0.

Also is there a better way to ret from a conditional jump?
Iirc ret and jmp return function differently.

Question is, why is the jump if equal to zero not jumping as 0 = 0?

This is the best I can get so far.
This seems to reverse the type being affected.

Code

EDIT:
WIP in last post

[Toga]

Hey there good thing you found this Cheat Engine section.

Since you are trying hard we have a look at it ( me with help from ).

I do have to replicate your attempt and see...
in the meantime, no offense meant but seeing your code you do need to learn a way lot more about injections.
ie.
alloc(newmem,64, x) is allocating memory to hold code and data.

so change it to a higher value ( although it goes in 1k parts )
but drop the allocating memory for the conditional branches ( not_ammo etc )

and try to invest about learning how an injection in Cheat Engine works
Also is there a better way to ret from a conditional jump?

in most cases you can't just "ret" from an injection
hence the "return" label

the "return" goes back to the point after the injection,
a "ret" will return from the function and in most cases it can crash the game.

for me to much to explain here.

so about your question why it ain't jumping when zero. i have to invest time later,
your 1st picture does show it's zero
but it doesn't show if the jump equal is executed or not ( which should be the case )

[satandidnowrong]

Thanks Toga.
I will make your time investment appreciated by reinvesting in this community.

In ignorance and lack of under standing and knowledge, 64 bytes for newmem holds enough room for the supplied code.
I would like the script to stay in the same memory area succeeding newmem.
When no alloc for conditionals, the aob is ruined (enabling and disabling the script destroys/overwrites some bytes in the game memory).
When "newmem: ret", item usage does not decrease (good outcome).
May be this should be adjusted to affect the math in stead of ret-ing.

I will race you for the solution!
If you are available to share your screen while debugging, I would be able to watch the process and learn.
Thanks for your intent and engagement.

EDIT:

WOOHOO! I got the quantity symbol and no decrease to work together using this!
Now I will seek to cmp inf_items_type! (Still need this part in conjunction)

Functioning quantity code:

[ENABLE]
//66 ?? ?? ?? C3 ?? 8B ?? ?? C1 ?? ?? A8 ?? 75 ?? 88
aobscanmodule(hkItems,$process,66xxxxxxxxxx8bxxxxc1xxxxa8xx75xx88) // should be unique
alloc(newmem,64,hkItems)
alloc(inf_items_quantity,2)

label(return)
label(hkItemsbkp)

registersymbol(hkItems)
registersymbol(hkItemsbkp)
registersymbol(inf_items_quantity)

newmem:
cmp word ptr [inf_items_quantity], 0
je retReturn
mov dx, [inf_items_quantity]
hkItemsbkp:
readmem(hkItems, 5)
jmp return
hkItems:
jmp newmem
retReturn:
ret
return:

[DISABLE]

hkItems:
readmem(hkItemsbkp, 5)

unregistersymbol(*)
dealloc(*)

EDIT:

I messed up a jne/je which is why the item type compare code was not as expected.
Now, when !(selected item type), !(decrease). This is not expected behaviour.
Still tinkering...

Almost functioning

[ENABLE]
//66 ?? ?? ?? C3 ?? 8B ?? ?? C1 ?? ?? A8 ?? 75 ?? 88
aobscanmodule(hkItems,$process,66xxxxxxxxxx8bxxxxc1xxxxa8xx75xx88) // should be unique
alloc(newmem,128,hkItems)
alloc(inf_items_type,2)
alloc(inf_items_quantity,2)

label(return)
label(hkItemsbkp)

registersymbol(hkItems)
registersymbol(hkItemsbkp)
registersymbol(inf_items_type)
registersymbol(inf_items_quantity)

newmem:
cmp byte ptr [inf_items_type], 1
je not_ammo
cmp byte ptr [inf_items_type], 2
je ammo
jmp quantity
not_ammo:
cmp [rcx+784],#2 //offset 2 is ammo
jne quantity
jmp return
ammo:
cmp [rcx+784],#2 //offset 2 is ammo
je quantity
jmp return
quantity:
cmp word ptr [inf_items_quantity], 0
je noDecrease
mov dx, [inf_items_quantity]
hkItemsbkp:
readmem(hkItems, 5)
jmp return
hkItems:
jmp newmem
noDecrease:
ret
return:

[DISABLE]

hkItems:
readmem(hkItemsbkp, 5)

unregistersymbol(*)
dealloc(*)

EDIT:

I ran a small debug check where I commented out ret in noDecrease, and the items are still not decreasing l o f l.
That ret should have been the cause of items not decreasing. I am still tinkering. Don't know what's going on yet..
Taking a detour for now. Here's current table. We're looking at "Auto Assemble script" above "No Item Usage Decrease" and "Inf Items".
.

[Toga]

your scripts looking way better.
I am only occasionally active here
same for sharing screens.

so be patient.

ps. best to remove that whole table attachment ( not the right place here )

[satandidnowrong]

I DID IT. IT IS DONE. DONE IT IS. REEE.

FUNCTIONING CODE

Code: Select all

[ENABLE]
//66 ?? ?? ?? C3 ?? 8B ?? ?? C1 ?? ?? A8 ?? 75 ?? 88
aobscanmodule(hkItems,$process,66xxxxxxxxxx8bxxxxc1xxxxa8xx75xx88) // should be unique
alloc(newmem,128,hkItems)
alloc(inf_items_type,2)
alloc(inf_items_quantity,2)

label(return)
label(hkItemsbkp)

registersymbol(hkItems)
registersymbol(hkItemsbkp)
registersymbol(inf_items_type)
registersymbol(inf_items_quantity)

newmem:
  cmp byte ptr [inf_items_type], 1
  je not_ammo
  cmp byte ptr [inf_items_type], 2
  je ammo
  jmp quantity
not_ammo:
  cmp [rcx+784],#2 //offset 2 is ammo
  jne quantity
  jmp hkItemsbkp
ammo:
  cmp [rcx+784],#2 //offset 2 is ammo
  je quantity
  jmp hkItemsbkp
quantity:
  cmp word ptr [inf_items_quantity], 0
  je noDecrease
  mov dx, [inf_items_quantity]
hkItemsbkp:
  readmem(hkItems, 5)
  jmp return
hkItems:
  jmp newmem
noDecrease:
  ret
return:

[DISABLE]

hkItems:
  readmem(hkItemsbkp, 5)

unregistersymbol(*)
dealloc(*)

Table

Now that it is done- is there a better logic for this code?
I don't like the cmp to ammo/not-ammo. Seems ignorant.?d

[Toga]

Hey nice going!

Certainly not to lecture you but you asked:



( got a little input from Messy, and we didn't tested it )

code

Code: Select all

  
newmem:
// moved this to the top because if its set to "no decrease" 
// there's no need for the rest of the code to execute
  cmp word ptr [inf_items_quantity], 0
  jne @f
  ret		// no decrease
                // ret is ONLY possible here because it's a small function 
                // without the use of the stack
  		//  otherwise the game will crash.. just use current quantity:
  		//	mov  dx, [rcx+4]      // [rcx+4] = current quantity
  		//      jmp  SHORT hkItemsbkp
@@:
  cmp byte ptr [inf_items_type], 1
  jne @F	// check for ammo
// not_ammo
  cmp [rcx+784],#2 //offset 2 is ammo
  jne quantity
  jmp hkItemsbkp
@@:
  cmp byte ptr [inf_items_type], 2
  jne quantity

// ammo
  cmp [rcx+784],#2 //offset 2 is ammo
  jne  hkItemsbkp

quantity:
  mov dx, [inf_items_quantity]

hkItemsbkp:
  readmem(hkItems, 5)
  jmp return

hkItems:
  jmp newmem

//noDecrease:
//  ret

return:

[DISABLE]

hkItems:
  readmem(hkItemsbkp, 5)

unregistersymbol(*)
dealloc(*)

-edit- i missed something.. change this also

Code: Select all

// ammo
// 2024-02-08 adjusted to SunBeam's advice
  cmp  BYTE PTR [rcx+784],#2 //offset 2 is ammo
  jne  hkItemsbkp

quantity:
  mov dx, [inf_items_quantity]

[SunBeam]

As a measure of good practice, always explicitly include the data type in the instruction you're implementing. "cmp [rcx+784],x" will always do a DWORD compare. That's how it's coded into CE's ASM. So do "cmp [byte,word,dword,qword] ptr [rcx+784],x" to fix it.