Script crashes game after restarting game

[Sigan]

So, I know I have the right location, and my code works fine. In this instance, it's just a code for infinite battery in the game Nimbatus. Very simple, I'll post it below. My problem is that every time I restart the game, I have to re-open dissect Mono, find the specific location, and rewrite the code. Else, when I restart the game and try to rerun the code, the game instantly crashes. Can someone help me, or point me to the forum post that has the answer, please? Thank you.

Code: Select all

{ Game   : Nimbatus.exe
  Version: 
  Date   : 2018-10-26
  Author : Sigan

  This script sets battery recharge rate to "9999"
}

define(address,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+b)
define(bytes,F3 0F 10 80 9C 01 00 00)

[ENABLE]
{$lua}
LaunchMonoDataCollector()
{$asm}
assert(address,bytes)
alloc(newmem,$1000,29C0001CF2B)
globalalloc(_Battery,4)
label(code)
label(return)

newmem:

code:
  mov [_Battery],rax
  mov [rax+19C],(float)9999 // offset for battery recharge rate is +19C
  movss xmm0,[rax+0000019C]
  jmp return

address:
  jmp newmem
  nop
  nop
  nop
return:

[DISABLE]

address:
  db bytes
  // movss xmm0,[rax+0000019C]
dealloc(_Battery)
dealloc(newmem)

{
// ORIGINAL CODE - INJECTION POINT: 29C0001CF2B

29C0001CF15: 00 00                          -  add [rax],al
29C0001CF17: 00 00                          -  add [rax],al
29C0001CF19: 00 00                          -  add [rax],al
29C0001CF1B: 00 00                          -  add [rax],al
29C0001CF1D: 00 00                          -  add [rax],al
29C0001CF1F: 00 48 83                       -  add [rax-7D],cl
29C0001CF22: EC                             -  in al,dx
29C0001CF23: 08 48 89                       -  or [rax-77],cl
29C0001CF26: 0C 24                          -  or al,24
29C0001CF28: 48 8B C1                       -  mov rax,rcx
// ---------- INJECTING HERE ----------
29C0001CF2B: F3 0F 10 80 9C 01 00 00        -  movss xmm0,[rax+0000019C]
// ---------- DONE INJECTING  ----------
29C0001CF33: F3 0F 5A C0                    -  cvtss2sd xmm0,xmm0
29C0001CF37: F2 0F 5A C0                    -  cvtsd2ss xmm0,xmm0
29C0001CF3B: 48 83 C4 08                    -  add rsp,08
29C0001CF3F: C3                             -  ret 
29C0001CF40: 01 04 01                       -  add [rcx+rax],eax
29C0001CF43: 00 04 02                       -  add [rdx+rax],al
29C0001CF46: 00 00                          -  add [rax],al
29C0001CF48: 00 00                          -  add [rax],al
29C0001CF4A: 00 00                          -  add [rax],al
29C0001CF4C: 00 00                          -  add [rax],al
}

[fantomas]

Hi

I think there is a better way to get inf battery

0198 - MaxEnergyAmount 25BEAF98 : 200
019C - RechargePerSecond 25BEAF9C : 10
01A0 - _wasFull 25BEAFA0 : 1
01A1 - _wasEmpty 25BEAFA1 : 0
01A4 - CurrentEnergyAmount 25BEAFA4 : 200

Also at the line 17, what 29C0001CF2B is meaning???

[Link]

[Sigan]

Globalalloc is just so I can call on that reference later in the table. Like, Pointer = _Battery+19C

29C0001CF2B is just some memory region that Cheat Engine put in there when I pressed, "Full Injection" in the templates. I don't know what that does. I'm assuming it's where Cheat Engine reserves the memory for my code when running the game, and I think that's my problem. I think it conflicts with something and always changes. I don't know how to make it dynamic and stable.

[Sigan]

This is what my current table looks like. I like using globalalloc for visuals when I'm wondering about what certain values might be while writing other codes.

These cheats work until I restart the game. When I restart the game, and then activate any of those codes, I'm hard crashed to the desktop with no hesitation as soon as the codes have the chance to be called on (i.e. when I'm not building the ship, but ready to fly it).

I'm thinking it's line 16, where it allocates memory and I'm allocating it to a hard value that is dynamic and causing a conflict. How do I make it a more dynamic value, and put it into a region of memory that isn't conflicting with my little piece of code?

[TimFun13]

So, I know I have the right location, and my code works fine. In this instance, it's just a code for infinite battery in the game Nimbatus. Very simple, I'll post it below. My problem is that every time I restart the game, I have to re-open dissect Mono, find the specific location, and rewrite the code. Else, when I restart the game and try to rerun the code, the game instantly crashes. Can someone help me, or point me to the forum post that has the answer, please? Thank you.

Code: Select all

{ Game   : Nimbatus.exe
  Version: 
  Date   : 2018-10-26
  Author : Sigan

  This script sets battery recharge rate to "9999"
}

define(address,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+b)
define(bytes,F3 0F 10 80 9C 01 00 00)

[ENABLE]
{$lua}
LaunchMonoDataCollector()
{$asm}
assert(address,bytes)
alloc(newmem,$1000,29C0001CF2B)
globalalloc(_Battery,4)
label(code)
label(return)

newmem:

code:
  mov [_Battery],rax
  mov [rax+19C],(float)9999 // offset for battery recharge rate is +19C
  movss xmm0,[rax+0000019C]
  jmp return

address:
  jmp newmem
  nop
  nop
  nop
return:

[DISABLE]

address:
  db bytes
  // movss xmm0,[rax+0000019C]
dealloc(_Battery)
dealloc(newmem)

{
// ORIGINAL CODE - INJECTION POINT: 29C0001CF2B

29C0001CF15: 00 00                          -  add [rax],al
29C0001CF17: 00 00                          -  add [rax],al
29C0001CF19: 00 00                          -  add [rax],al
29C0001CF1B: 00 00                          -  add [rax],al
29C0001CF1D: 00 00                          -  add [rax],al
29C0001CF1F: 00 48 83                       -  add [rax-7D],cl
29C0001CF22: EC                             -  in al,dx
29C0001CF23: 08 48 89                       -  or [rax-77],cl
29C0001CF26: 0C 24                          -  or al,24
29C0001CF28: 48 8B C1                       -  mov rax,rcx
// ---------- INJECTING HERE ----------
29C0001CF2B: F3 0F 10 80 9C 01 00 00        -  movss xmm0,[rax+0000019C]
// ---------- DONE INJECTING  ----------
29C0001CF33: F3 0F 5A C0                    -  cvtss2sd xmm0,xmm0
29C0001CF37: F2 0F 5A C0                    -  cvtsd2ss xmm0,xmm0
29C0001CF3B: 48 83 C4 08                    -  add rsp,08
29C0001CF3F: C3                             -  ret 
29C0001CF40: 01 04 01                       -  add [rcx+rax],eax
29C0001CF43: 00 04 02                       -  add [rdx+rax],al
29C0001CF46: 00 00                          -  add [rax],al
29C0001CF48: 00 00                          -  add [rax],al
29C0001CF4A: 00 00                          -  add [rax],al
29C0001CF4C: 00 00                          -  add [rax],al
}

Added some notes to the script, look it over then give it a try; let me know if you have any other questions.

Code: Select all

{ Game   : Nimbatus.exe
  Version: 
  Date   : 2018-10-26
  Author : Sigan

  This script sets battery recharge rate to "9999"
}

define(address,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+b)
define(bytes,F3 0F 10 80 9C 01 00 00)

[ENABLE]
{$lua}
if syntaxcheck then return end
if process and readInteger(process) ~= 0 then
    mono_initialize()
    LaunchMonoDataCollector()
else
    local msg = 'No process detected.'
    print(msg)
    error(msg)
end
{$asm}
assert(address,bytes)
alloc(newmem,$1000,address) //// use the address or AOB symbol as the "allocate near address".
label(code)
label(return)
label(_Battery) //// No need to allocate more memory, we can just stick it in the "newmem".
registerSymbol(_Battery) //// registering the symbol will make it accessible elsewhere.

newmem:

code:
  mov [_Battery],rax
  mov [rax+19C],(float)9999 // offset for battery recharge rate is +19C
  movss xmm0,[rax+0000019C]
  jmp return
  align 10 //// Not required, but looks better and it's setup for any "aligned" instructions.
  _Battery: //// No need to allocate more memory, just stick it in the "newmem".
    dd 0

//// Injection point
address:
  jmp newmem
  nop
  nop
  nop
return:

[DISABLE]
//// Injection point
address:
  db bytes
  // movss xmm0,[rax+0000019C]
//dealloc(_Battery) //// "dealloc" dosen't work with "globalAlloc", it won't deallocate the memory.
unregisterSymbol(_Battery)
dealloc(newmem)

{
// ORIGINAL CODE - INJECTION POINT: 29C0001CF2B

29C0001CF15: 00 00                          -  add [rax],al
29C0001CF17: 00 00                          -  add [rax],al
29C0001CF19: 00 00                          -  add [rax],al
29C0001CF1B: 00 00                          -  add [rax],al
29C0001CF1D: 00 00                          -  add [rax],al
29C0001CF1F: 00 48 83                       -  add [rax-7D],cl
29C0001CF22: EC                             -  in al,dx
29C0001CF23: 08 48 89                       -  or [rax-77],cl
29C0001CF26: 0C 24                          -  or al,24
29C0001CF28: 48 8B C1                       -  mov rax,rcx
// ---------- INJECTING HERE ----------
29C0001CF2B: F3 0F 10 80 9C 01 00 00        -  movss xmm0,[rax+0000019C]
// ---------- DONE INJECTING  ----------
29C0001CF33: F3 0F 5A C0                    -  cvtss2sd xmm0,xmm0
29C0001CF37: F2 0F 5A C0                    -  cvtsd2ss xmm0,xmm0
29C0001CF3B: 48 83 C4 08                    -  add rsp,08
29C0001CF3F: C3                             -  ret 
29C0001CF40: 01 04 01                       -  add [rcx+rax],eax
29C0001CF43: 00 04 02                       -  add [rdx+rax],al
29C0001CF46: 00 00                          -  add [rax],al
29C0001CF48: 00 00                          -  add [rax],al
29C0001CF4A: 00 00                          -  add [rax],al
29C0001CF4C: 00 00                          -  add [rax],al
}

You can also try the "AOB template".
And here is a wiki post on the Mono features.
[Link]

EDIT:
Then I'd edit the other scripts, I think the reason for the crashes is the "allocare near address"; just change those to the "address/AOB symbol" so you can keep using 5 byte jumps, or setup the code to use 14 byte jumps.

[Sigan]

Hey!! Thank you very much for that explanation I understand all that, and appreciate your help! Have a great day!

[Sigan]

I changed the allocate near address to be the mono address and, so long as mono is enabled, it seems to be working fine.

[TimFun13]

I changed the allocate near address to be the mono address and, so long as mono is enabled, it seems to be working fine.

I wasn't thinking about it, but if you register a symbol for the injection point this can setup the script to better enable the mono features itself.

Code: Select all

{ Game   : Nimbatus.exe
  Version: 
  Date   : 2018-10-26
  Author : Sigan

  This script sets battery recharge rate to "9999"
}
define(bytes,F3 0F 10 80 9C 01 00 00)

[ENABLE]
{$lua}
if syntaxcheck then return end
if process and readInteger(process) ~= 0 then
    mono_initialize()
    LaunchMonoDataCollector()
else
    local msg = 'No process detected.'
    print(msg)
    error(msg)
end
{$asm}
define(addrBatteryINJ,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+b)
assert(addrBatteryINJ,bytes)
registerSymbol(addrBatteryINJ) //// So define a symbol then register it to the user symbol's list.

alloc(newmem,$1000,addrBatteryINJ) //// use the address or AOB symbol as the "allocate near address".
label(code)
label(return)
label(_Battery) //// No need to allocate more memory, we can just stick it in the "newmem".
registerSymbol(_Battery) //// registering the symbol will make it accessible elsewhere.

newmem:

code:
  mov [_Battery],rax
  mov [rax+19C],(float)9999 // offset for battery recharge rate is +19C
  movss xmm0,[rax+0000019C]
  jmp return
  align 10 //// Not required, but looks better and it's setup for any "aligned" instructions.
  _Battery: //// No need to allocate more memory, just stick it in the "newmem".
    dd 0

//// Injection point
addrBatteryINJ:
  jmp newmem
  nop
  nop
  nop
return:

[DISABLE]
//// Injection point
addrBatteryINJ:
  db bytes
  // movss xmm0,[rax+0000019C]
unregisterSymbol(addrBatteryINJ)
//dealloc(_Battery) //// "dealloc" dosen't work with "globalAlloc", it won't deallocate the memory.
unregisterSymbol(_Battery)
dealloc(newmem)

{
// ORIGINAL CODE - INJECTION POINT: 29C0001CF2B

29C0001CF15: 00 00                          -  add [rax],al
29C0001CF17: 00 00                          -  add [rax],al
29C0001CF19: 00 00                          -  add [rax],al
29C0001CF1B: 00 00                          -  add [rax],al
29C0001CF1D: 00 00                          -  add [rax],al
29C0001CF1F: 00 48 83                       -  add [rax-7D],cl
29C0001CF22: EC                             -  in al,dx
29C0001CF23: 08 48 89                       -  or [rax-77],cl
29C0001CF26: 0C 24                          -  or al,24
29C0001CF28: 48 8B C1                       -  mov rax,rcx
// ---------- INJECTING HERE ----------
29C0001CF2B: F3 0F 10 80 9C 01 00 00        -  movss xmm0,[rax+0000019C]
// ---------- DONE INJECTING  ----------
29C0001CF33: F3 0F 5A C0                    -  cvtss2sd xmm0,xmm0
29C0001CF37: F2 0F 5A C0                    -  cvtsd2ss xmm0,xmm0
29C0001CF3B: 48 83 C4 08                    -  add rsp,08
29C0001CF3F: C3                             -  ret 
29C0001CF40: 01 04 01                       -  add [rcx+rax],eax
29C0001CF43: 00 04 02                       -  add [rdx+rax],al
29C0001CF46: 00 00                          -  add [rax],al
29C0001CF48: 00 00                          -  add [rax],al
29C0001CF4A: 00 00                          -  add [rax],al
29C0001CF4C: 00 00                          -  add [rax],al
}

EDIT:
And setup like this, it's easily changed to use and AOB scan instead of an address; but with mono using an address should work fine.
Just make sure any registered symbols are unique.

[Sigan]

And, you're thinking that I might want to revert to an AOB scan should the address change. Say, in future updates or whatever?

I prefer mono addresses since they're immediate, but if that's what you're suggesting here then that does make it cleaner and easier to simply change one line and have it affect everything else in the code.

Edit: By the way, you're absolutely right that, in this code, there is no reason to globalalloc anything. However..... Typically when I write these codes, I do it like this:

Code: Select all

 
 mov [_Battery],rax
  cmp [setCharge],1
  jne @f
  mov [rax+19C],(float)9999
@@:
  movss xmm0,[rax+0000019C]
  jmp return
  

I was very confused as to why my other script to enable infinite battery charge wasn't working:

Code: Select all

[ENABLE]
setCharge:
  dd 1

[DISABLE]
setCharge:
  dd 0

I typically do this if there is multiple things that I want to be able to toggle on and off in a given section, while still running the script in the background for a different feature. I did this in my Feed and Grow Fish table, and I like doing it this way.

viewtopic.php?t=7385

[Bloodybone]

And, you're thinking that I might want to revert to an AOB scan should the address change. Say, in future updates or whatever?

I prefer mono addresses since they're immediate, but if that's what you're suggesting here then that does make it cleaner and easier to simply change one line and have it affect everything else in the code.

You can also use [Link] to make the AOB scan way faster lets say the address as in your case is "Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+b" you could do something like this:

Code: Select all

aobscanregion(addrBatteryINJ,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond,Assets.Nimbatus.Scripts.WorldObjects.Items.DroneParts.Batteries:Battery:GetRechargePerSecond+100,F3 0F 10 80 9C 01 00 00)

[Sigan]

Is that supposed to say "aobCANregion" or "aobSCANregion" in your code?

Either way, I'm noting this down because I didn't know I could do that. Thank you

[Bloodybone]

Is that supposed to say "aobCANregion" or "aobSCANregion" in your code?

Either way, I'm noting this down because I didn't know I could do that. Thank you

I meant "aobSCANregion"

[Sigan]

Here's my table. If there's anything that can be simplified, I'm ready to learn. On the other hand, just in its current format, I think it's clear what I was going for. The latest version may have different offsets, but I doubt it. I haven't bothered downloading the update yet.