Assassin's Creed Odyssey v1.3.0/v1.5.1 +21 (table Update18.3)

[hummus]

Thanks for the update.
About the snake doing damage, I encountered it in Origins too but it's not that important they are really easy to kill in this game.

How to use this cheat table?

1. Install Cheat Engine
2. Double-click the .CT file in order to open it.
3. Click the PC icon in Cheat Engine in order to select the game process.
4. Keep the list.
5. Activate the trainer options by checking boxes or setting values from 0 to 1

[hans_meier]

Thanks for the update.
About the snake doing damage, I encountered it in Origins too but it's not that important they are really easy to kill in this game.

ingame spoiler

Spoiler

Wait for the temple of agamemnon :shrug:

[Sebubble]

I noticed game crashes while on the ship as well. Once when I entered open water and once while docking. If it's just the infinite stamina, I'll turn that off for now.

Edit ~ I just tried the same table and it crashed while I was running on the ground. I hadn't even been on the water. There must be something in there that's causing crashes but I don't know what it is. Perhaps both land and sea adrenaline cause crashes?
Also I downloaded the latest table and it doesn't seem to work. I click on 'enable' but it doesn't tick and nothing happens. Might be my fault!

Love the table btw and thanks for all your work!

[draw95]

I managed to change health and damage values, but I have a question.
Is it possible to save the values ​​that are permanently modified with cheat engine? Or will the values ​​become what they were when I start the game again?

Have you use pointer scan? there's a tutorial on youtube if you want to try to find the static address

[zeroqian]

Can I translate into Chinese and share it with Chinese players?

[jonasbeckman]

I noticed game crashes while on the ship as well. Once when I entered open water and once while docking. If it's just the infinite stamina, I'll turn that off for now.

Edit ~ I just tried the same table and it crashed while I was running on the ground. I hadn't even been on the water. There must be something in there that's causing crashes but I don't know what it is. Perhaps both land and sea adrenaline cause crashes?
Also I downloaded the latest table and it doesn't seem to work. I click on 'enable' but it doesn't tick and nothing happens. Might be my fault!

Love the table btw and thanks for all your work!

I did notice 8.2 periodically shut the game down when running around on land, going to see if toggling off infinite stamina helps and if it does then perhaps try and find what changed.

There's a lot of differences in the 8.1 and 8.2 tables though a early change seems to be directly related to adrenaline although my own skill with Cheat Engine is pretty terrible.
(I'm just going through the two with Notepad++ at the moment and comparing any differences I find.)

Though I do get the periodic shut-down crashes with 8.1 too even if it's not as immediate so I am also wondering if it's a game issue more than anything else and it's just going to need a few patches.

[Cielos]

about the crashes.
I'll have a look next time I play the game to see if there're some typo with the scripts. I personally have no crash whatsoever with all the options on, so it's difficult for me to locate the problem you guys are having. the most details one is hans_meier's report, but I still can't recreate the crash they mentioned.

that said, have a look at this post:

I'm not sure a lot of others have had the same issue and its probably software or hardware related, but for me the game often completely froze when I attached Cheat Engine to it and had loaded the table. This mainly occurred directly after returning to the game and sometimes just a little later, but always within a minute.
I finally got around this by putting the game in borderless windowed mode.
[...]

so, if you're playing in "Fullscreen", try changing to "Borderless" to see if the crash persist.
hope that helps~

ALSO:
one thing worth noting, that if you have any pointers (entries in RED) found on my table FREEZE when you play the game, try not to do that to see if the crash stop.
i.e., leave the box in front of a RED entry empty.

ok, that's it for now.
remember if you have a bug report, try to make it as details as possible.
good luck~

[SunBeam]

Ah, yes. That pointer you have in the table in red changes values. For example, if you enter map and are far away from the Adrestia (say, mid-map) points to a certain base; once you get close to the ship, pointer changes. So I don't know if keeping the script using this pointer on may crash your ass in transitions. A suggestion would be to use testing for NULLs. I kinda got used to do this, even when I know for certain they can't be NULL Just put a "test r64,r64/je (if NULL)" where due

[Cielos]

Ah, yes. That pointer you have in the table in red changes values. For example, if you enter map and are far away from the Adrestia (say, mid-map) points to a certain base; once you get close to the ship, pointer changes. So I don't know if keeping the script using this pointer on may crash your ass in transitions. A suggestion would be to use testing for NULLs. I kinda got used to do this, even when I know for certain they can't be NULL Just put a "test r64,r64/je (if NULL)" where due

- test reg,reg can prevent some errors inside the script, but doesn't helps when you freeze a pointer fetched by the script.
e.g.
1. the script fetch a pointer of health, 0x14832000 and saved it to "pHealth" when the game reads it in-game.
2. you fast travel, the game relocate the health from 0x14832000 to 0x12800000.
3. the game reaches where the health fetching script hook to and change the pointer to 0x12800000.

if you freeze the pointer, errors could happenes between 2. and 3. i.e.:
CE is still freezeing the value of 0x14832000 when the game has change the health address to 0x12800000, it's using 0x14832000 for some other purpose already, and the game hasn't reach the hook that would update the address from 0x14832000 to 0x12800000 yet.

now, add null testing here doesn't do much, as the freezing process is done by CE, not the script.

- if if happens inside the script:
test null can prevent most error, but both the ship health script and ship stamina script doesn't deal with the "pointer fetched by the script" directly, instead it just use them for compare. if the pointer doesn't match, the script would just skip the manipulation.
so, even if the pointer is null after fast-travel on loading, at most it would just fail the compare and jump back to the game codes, as the script won't try to read the value of the address the pointer point to, thus nothing should happens even if the address is not a proper pointer.
using the examples above:
let say the game reaches the inf health script between 2. and 3., the script would try to compare with the value 0x14832000 or 0x12800000, not the address pointed to by 0x14832000 or 0x12800000. so, even if it's 0x0, the script will not read from this null pointer.

- using test null is not the most secure method to ensure a proper pointer. more than once I have to use isbadreadptr to make sure I'm dealing with the right address. because even if it's not null, it still doesn't mean it's a proper address...

- now, my thought about the crash, could be that there are some typos that mess up the jumping back from the script to the game code, or the game has some jmp that would jump to the exact place where my injection code uses, but I fail to recognise. ....that's the downside for relying CE to locate a code cave and prepare the jmp in 14 bytes manually. using a static code cave is a better idea in this sense.

anyway, I still haven't check the codes yet. maybe it's just the game problem (e.g., the alt-tab out of fullscreen.)... again, I'll have a look next time I play the game...

[jonasbeckman]

For attaching the table to the game process I usually do that in the main menu, from my understanding of the earlier posts on the subject it tends to stall a bit if done in-game after loading a save possibly related to memory allocation and the game using a ton of resources. (Pretty hefty CPU overhead too from what I'm reading although newer hardware probably handles this much better or at least faster.)

Doing it that way takes a few seconds, attaching the table and activating the initial script once the game has loaded can take a minute where it might seem that Cheat Engine is stalling but it's working and will eventually activate and then the other options will work just fine.

I am also on the Steam version but if the script (EDIT: Well, the game code I guess more than the scripts.) varied significantly then I don't believe the options would have activated at all so that is unlikely to be a concern and there are various crash reports on the Steam and Ubisoft forums so I'm thinking it's mostly just in need a update to maybe fix up the stability a bit. If it was easier to replicate instead of having it being random that would make it easier to test but title update 1.03 should be coming along pretty well by now and is likely going to be released soon although some of the newer bug reports are unlikely to have made it into it's cycle of fixes and what they are focusing on with this patch.


EDIT: Well nothing new I suppose, a more reliable way to replicate the crashes would be needed and I have to do some more testing with and without the table activate to see how it goes. Even if it might be possible that some option can affect stability if it's still prone to shutting down even if the table isn't even active then that's pretty much a confirmation that the game itself is acting up.
(Or the current area I'm at maybe, trial and error I suppose. Trying to figure out some of what is going on but it's probably not going to amount to much although it might be possible to get it a bit more stable.)

[Cielos]

@all
turns out there ARE some bad edits on 2 scripts, that could crash the game randomly. so:

Update8.3
- updated enable and instant abilities cooldown. fix a bad edit on eash of these 2 scripts that could crash the game. specifically, removing 2 "returnhere" labels, 2 "jmp to returnhere", which are both not supposed to be there. the table should be stable now.

re-download if you've been experience crashes/freezes with the table~

still, it's advised NOT to freeze any pointers. they are supposed to be for value editing, not value freezing.

[Timone]

Think it'll ever be possible to add the ability to edit gear? Change the stat bonuses/appearances on armor pieces for instance.

[SunBeam]

- test reg,reg can prevent some errors inside the script, but doesn't helps when you freeze a pointer fetched by the script.
e.g.
1. the script fetch a pointer of health, 0x14832000 and saved it to "pHealth" when the game reads it in-game.
2. you fast travel, the game relocate the health from 0x14832000 to 0x12800000.
3. the game reaches where the health fetching script hook to and change the pointer to 0x12800000.

I'd stop at #2 and figure out where to hook for catching the change in transitions. Another way: find a spot you know changes when transitioning (I have that stuff in Black Flag already implemented in the handler), query it, if X -> run loop: in loop: if Y, end loop -> refresh ptr Then, depending how you have your set-up, you could check the on/off flags for the options and re-turn on/off the options

[Cielos]

@Timone
it's always possible. the question is, will anyone do it (staring at the sun below yours...).
I may make some simple edit later when I'm bored (like the one I made for Origins). but if you want a sophisticated one, you should keep an eye on SubBeam.

@SunBeam
if I need to manipulate the pointer directly, your first approach is certainly the correct way.
creating multiple loops to handle the pointer check... seems a bit excessive though, but when the table is mainly working with pointer manipulation, and the pointer integrity is utmost important, this looping approach seems a better one than the first one.

my table, on the other hand, tend to rely on scripts themselves to "execute" functions instead of listing the pointers out to edit/freeze, so that I don't need to tab out to table all the time.
setting up loops to ensure the pointers I won't use 90% of the time would stay correct in loading screen/during fast travel...

as I'm typing, I remember I once added some loop to your ACUnity table to call the set-up functions again automatically after a game load or fast travel render them useless... and it crashes me everytime . in the end I fall back to hot-keys activation everytime it got reset, but adding a loop to ensure I won't accidentally turn the function off again by double tap.

oooooooooook. enough typing. back to game....

[SunBeam]

Well, I can tell you that:

- there's an object called WhiteRoomManager available in all AC games
- this structure contains a flip byte that works like this: -1 when you're in-game; 0 when you're in transitions
- then there's another structure (forgot the name of it) with a similar bool that gets multiple states, based on what the game engine is doing (1,2,3,4 etc.)

Both of them can be reached via static pointers (mov rax,[addr]) So no biggie getting them

By combining the two in a thread with a loop (as I mentioned), you get what I said It's not excessive, it's pretty straight-forward. Especially in Unity or Syndicate, where you can't hook memory (due to VMProtect-ed integrity checks).

Here's my example from Black Flag (this one doesn't have integrity checks; but I wanted to make use of just what I'm collecting, no hooks )

Code: Select all

CheatHandlerThread:
mov eax,[AC4BFSP.exe+26BDE7C]
cmp [eax+144],-1 // make sure we're in-game when enabling the script
je short @f
  push C8
  call kernel32.Sleep
  jmp short CheatHandlerThread
@@:
call GetDebugMenuPointer // get the context pointer for the Debug Menu
call FetchPointers       // fetch various pointers you can use in your attempts :)
CheatHandlerThread_loop:
  push A
  call kernel32.Sleep
  cmp [CheatHandlerOff],1
  jne short @f
    mov [CheatHandlerOff],2
    ret
  @@:
  mov eax,[AC4BFSP.exe+26BDE7C]
  cmp [eax+144],3 // if world->main menu->world
  je short CheckAndReinitialize
    cmp [eax+144],2 // if world->reload->world
    je short CheckAndReinitialize
      jmp short CheatHandlerThread_loop
  CheckAndReinitialize:
  mov eax,[AC4BFSP.exe+26BDE7C]
  cmp [eax+144],-1 // check if we're back in-game
  je short @f
    push C8
    call kernel32.Sleep
    jmp short CheckAndReinitialize
  @@:
  call GetDebugMenuPointer
  call FetchPointers
  cmp byte ptr [bVanish],1    // check if option is active
  jne short @f                // if OFF, check next
    call TogglePlayerVanish   // if ON, re-enable
  @@:
  cmp byte ptr [bGod],1
  jne short @f
    call GodMode
  @@:
  cmp byte ptr [bInvisible],1
  jne short @f
    call Invisible
  @@:
  cmp byte ptr [bNavalInvisible],1
  jne short @f
    call NavalInvisible
  @@:
  cmp byte ptr [bInfiniteBreath],1
  jne short @f
    call InfiniteBreathMode
  @@:
  jmp CheatHandlerThread_loop

Find it here: xen/threads/assassins-creed-black-flag. ... post-47678 (phpBB version is not available, it seems).

BR,
Sun