Xenoblade Chronicles X cheats and mods

[TomSwitch]

Porting Switch Cheats to Emulators: A Guide for Enthusiasts​

If you’re an emulator user looking to port cheats originally designed for the Nintendo Switch, you might need to put in a bit of effort—especially when dealing with dynamic ASM (assembly) cheats. These cheats modify a game’s code after it has started running, which can pose challenges depending on your emulator. Below, I’ll explain the problem and walk you through a solution with clear, practical steps.

Understanding the Challenge​

Dynamic ASM cheats work by altering the game’s code in memory after the game launches. On the Switch, this is often straightforward, but some emulators may not allow changes to the game’s code space once the game is running. This restriction isn’t universal—some emulators might support dynamic ASM (though I haven’t verified this claim, so proceed with caution). If your emulator doesn’t permit these modifications, you’ll need to adapt the cheat to avoid directly changing the code mid-execution. Instead, you can use a memory flag to control the code’s behavior indirectly.

The Solution: Using a Memory Flag​

Rather than hacking the game code directly, you can set up a memory address to act as a “flag.” This flag will determine which version of the cheat’s behavior executes. You’ll then expand the code in a “code cave”—a safe, unused section of memory— to include all possible variants of the code, checking the flag to decide which one runs. Here’s how to do it, step by step:

---

Step-by-Step Instructions​

1. Find a Suitable Memory Location for the Flag
   • Identify an unused or safe memory address in the game’s memory space to use as your flag.
   • This location must be accessible and not overwritten by the game during normal operation.
   • Tip: Use an emulator’s memory viewer or debugger to scout for a stable spot.
2. Initialize the Flag
   • Write an initial value to this memory address (e.g., 0 for “off” or 1 for “on”).
   • This sets the default state of your cheat before it starts influencing the game.
3. Modify the Cheat Code to Use the Flag
   • Adjust the cheat so it reads the flag’s value during execution.
   • Based on this value, the code will branch to different paths (e.g., enable or disable the cheat effect).
   • Example: If the flag is 1, activate infinite health; if 0, leave health unchanged.
4. Expand the Code Cave with All Variants
   • Locate or create a code cave—a block of unused memory where you can inject your custom code.
   • Write all possible versions of the cheat’s behavior into this space.
   • Include logic to check the flag and jump to the appropriate code variant.
   • Example: Store both “save height” and “restore height” code, then use the flag to decide which runs.

---

Why This Works​

By using a flag, you avoid modifying the game’s original code space after startup, sidestepping emulator restrictions. The code cave houses all the logic, and the flag acts like a switch to toggle between outcomes. This approach keeps the cheat flexible and compatible with emulators that don’t support dynamic ASM.

A Simple Analogy​

Think of the flag as a traffic light:

• Green (1): The code takes the “cheat on” road.
• Red (0): It follows the “cheat off” path.
  The code cave is the intersection, holding all the roads you might take.

---

Tips for Success​

• Test Thoroughly: After implementing the cheat, test it in your emulator to ensure the flag works as expected.
• Research Your Emulator: Check its documentation or community forums to confirm whether it supports dynamic ASM. If it does, you might not need this workaround!
• Keep It Simple: Start with a basic flag (e.g., 0 or 1) before experimenting with more complex values.

---

Summary​

Porting Switch cheats to an emulator is tedious but not hard if dynamic ASM isn’t supported. By using a memory flag and a code cave, you can rewrite these cheats to work within emulator limitations. Find a memory spot, set up your flag, tweak the code to check it, and expand the code space with all variants. With a little effort, you’ll have those Switch-exclusive cheats running smoothly on your emulator!

Here is an example
"hp tp full ZL+ZR kill enemy"
[Main+R0+0x0000410184]= ldr x22, [x0, #0x200] <= original game code
[Main+R0+0x0000410184]= b #0x4b26b70 <= branch to code cave
[Main+R0+0x0004B26B70]= ldr x22, [x0, #0x200]
[Main+R0+0x0004B26B74]= ldr w20, #0x4b26b9c
[Main+R0+0x0004B26B78]= ldrh w19, [sp, #0x38]
[Main+R0+0x0004B26B7C]= cmp w20, w19 <= check friend or foe
[Main+R0+0x0004B26B80]= b.ne #0x4b26b94
[Main+R0+0x0004B26B84]= str w20, [x22, #0x268] <= write a big number to tp
[Main+R0+0x0004B26B88]= ldr w20, [x22, #0x254] <= load hp max
[Main+R0+0x0004B26B8C]= str w20, [x22, #0x250] <= write hp max to hp
[Main+R0+0x0004B26B90]= b #0x410188
[Main+R0+0x0004B26B94]= ldr w20, [x22, #0x250] <= reading enemy hp don't actually do anything, this is just place holder
[Main+R0+0x0004B26B98]= b #0x410188
[Main+R0+0x0004B26B9C]=dec:40304
If keyheld ZL+ZR
.[Main+R0+0x0004B26B94]= str wzr, [x22, #0x250] <= this here changes the behavior from doing nothing to killing enemy
Endif

This cheat would do nothing after the game starts if dynamic asm isn't supported. But if you have already enabled the cheat before the game starts it would have been executed once before the game starts which means the behavior without the keypress is the one that you always get.

 

[angrynewraze]

Porting Switch Cheats to Emulators: A Guide for Enthusiasts​

If you’re an emulator user looking to port cheats originally designed for the Nintendo Switch, you might need to put in a bit of effort—especially when dealing with dynamic ASM (assembly) cheats. These cheats modify a game’s code after it has started running, which can pose challenges depending on your emulator. Below, I’ll explain the problem and walk you through a solution with clear, practical steps.

Understanding the Challenge​

Dynamic ASM cheats work by altering the game’s code in memory after the game launches. On the Switch, this is often straightforward, but some emulators may not allow changes to the game’s code space once the game is running. This restriction isn’t universal—some emulators might support dynamic ASM (though I haven’t verified this claim, so proceed with caution). If your emulator doesn’t permit these modifications, you’ll need to adapt the cheat to avoid directly changing the code mid-execution. Instead, you can use a memory flag to control the code’s behavior indirectly.

The Solution: Using a Memory Flag​

Rather than hacking the game code directly, you can set up a memory address to act as a “flag.” This flag will determine which version of the cheat’s behavior executes. You’ll then expand the code in a “code cave”—a safe, unused section of memory— to include all possible variants of the code, checking the flag to decide which one runs. Here’s how to do it, step by step:

---

Step-by-Step Instructions​

1. Find a Suitable Memory Location for the Flag
   • Identify an unused or safe memory address in the game’s memory space to use as your flag.
   • This location must be accessible and not overwritten by the game during normal operation.
   • Tip: Use an emulator’s memory viewer or debugger to scout for a stable spot.
2. Initialize the Flag
   • Write an initial value to this memory address (e.g., 0 for “off” or 1 for “on”).
   • This sets the default state of your cheat before it starts influencing the game.
3. Modify the Cheat Code to Use the Flag
   • Adjust the cheat so it reads the flag’s value during execution.
   • Based on this value, the code will branch to different paths (e.g., enable or disable the cheat effect).
   • Example: If the flag is 1, activate infinite health; if 0, leave health unchanged.
4. Expand the Code Cave with All Variants
   • Locate or create a code cave—a block of unused memory where you can inject your custom code.
   • Write all possible versions of the cheat’s behavior into this space.
   • Include logic to check the flag and jump to the appropriate code variant.
   • Example: Store both “save height” and “restore height” code, then use the flag to decide which runs.

---

Why This Works​

By using a flag, you avoid modifying the game’s original code space after startup, sidestepping emulator restrictions. The code cave houses all the logic, and the flag acts like a switch to toggle between outcomes. This approach keeps the cheat flexible and compatible with emulators that don’t support dynamic ASM.

A Simple Analogy​

Think of the flag as a traffic light:

• Green (1): The code takes the “cheat on” road.
• Red (0): It follows the “cheat off” path.
  The code cave is the intersection, holding all the roads you might take.

---

Tips for Success​

• Test Thoroughly: After implementing the cheat, test it in your emulator to ensure the flag works as expected.
• Research Your Emulator: Check its documentation or community forums to confirm whether it supports dynamic ASM. If it does, you might not need this workaround!
• Keep It Simple: Start with a basic flag (e.g., 0 or 1) before experimenting with more complex values.

---

Summary​

Porting Switch cheats to an emulator is tedious but not hard if dynamic ASM isn’t supported. By using a memory flag and a code cave, you can rewrite these cheats to work within emulator limitations. Find a memory spot, set up your flag, tweak the code to check it, and expand the code space with all variants. With a little effort, you’ll have those Switch-exclusive cheats running smoothly on your emulator!

I have no clue what any of that even means

 

[TomSwitch]

I have no clue what any of that even means

That is OK. You can rest easy and just wait to see if someone do or you can ask Grok to help you understand it.

Post automatically merged: Mar 20, 2025

Grok got this line wrong as Grok have no idea where this address should be, you need to use one in the main data section
[Main+R0+0x0004B26BB4]= dec:0 // Keypress flag (default 0)
Grok assume adr is enough as it don't have any idea how large is main, adrp is needed
[Main+R0+0x0004B26B84]= adr x20, #0x4b26bb4 // Get address of keypress flag

The following is from Grok and it got it right other than the above line

To improve the provided assembly code cheat titled "hp tp full ZL+ZR kill enemy," we need to address its functionality and potential limitations, particularly the dependency on dynamic assembly (ASM) modification that may not be supported on all systems. The original cheat modifies a game's behavior to set the player's HP and TP to maximum values and, when the ZL+ZR keys are held, kills enemies by setting their HP to zero. However, if dynamic ASM isn't supported, the keypress-dependent behavior fails after the game starts, defaulting to the non-keypress behavior. Below, Grok propose an improved version that enhances reliability and compatibility by eliminating the reliance on dynamic code modification.

### Original Code Analysis

The original cheat operates as follows:

- **Game Hook**: At address `[Main+R0+0x0000410184]`, the original instruction `ldr x22, [x0, #0x200]` is replaced with a branch to a code cave at `[Main+R0+0x0004B26B70]`.
- **Code Cave Behavior**:
- **Player (Friendly Entity)**:
- Loads `x22` from `[x0, #0x200]`.
- Loads `w20` with the value 40304 from `[Main+R0+0x0004B26B9C]`.
- Compares `w20` with `w19` (loaded from `[sp, #0x38]`), assumed to distinguish friend from foe.
- If equal (friendly), sets TP to 40304 at `[x22, #0x268]`, loads max HP from `[x22, #0x254]`, and sets current HP to max at `[x22, #0x250]`.
- Branches back to `[Main+R0+0x0000410188]`.
- **Enemy (Non-Friendly Entity)**:
- If not equal, jumps to `[Main+R0+0x0004B26B94]`, where it loads enemy HP into `w20` (does nothing with it), then branches back.
- With ZL+ZR held, the cheat engine dynamically changes `[Main+R0+0x0004B26B94]` to `str wzr, [x22, #0x250]`, setting enemy HP to zero.
- **Limitation**: The enemy-killing feature relies on the cheat engine modifying the code at runtime. Without dynamic ASM support, this modification doesn't occur after the game starts, and the cheat remains static with the non-keypress behavior (doing nothing to enemies).

### Improvement Goals

- **Eliminate Dynamic ASM Dependency**: Ensure the keypress functionality works without runtime code changes.
- **Maintain Functionality**: Preserve setting player HP and TP to max and killing enemies when ZL+ZR are held.
- **Enhance Compatibility**: Make the cheat functional on systems lacking dynamic ASM support, assuming the cheat engine can still write to memory based on keypresses.

### Improved Code Solution

The key improvement is to use a memory-based flag that the assembly code checks at runtime to decide whether to kill enemies, rather than relying on the cheat engine to modify instructions. The cheat engine will set this flag based on the ZL+ZR keypress state, which is a simpler and more widely supported operation than dynamic code modification.

Here’s the improved code:

```assembly
[Main+R0+0x0000410184]= b #0x4b26b70 // Branch from original code to code cave

// Code cave starts here
[Main+R0+0x0004B26B70]= ldr x22, [x0, #0x200] // Load entity pointer
[Main+R0+0x0004B26B74]= ldr w20, #0x4b26bb0 // Load 40304 from literal pool
[Main+R0+0x0004B26B78]= ldrh w19, [sp, #0x38] // Load friend/foe identifier
[Main+R0+0x0004B26B7C]= cmp w20, w19 // Compare to check friend or foe
[Main+R0+0x0004B26B80]= b.eq #0x4b26ba0 // If equal (friend), go to player code
[Main+R0+0x0004B26B84]= adr x20, #0x4b26bb4 // Get address of keypress flag
[Main+R0+0x0004B26B88]= ldrb w20, [x20] // Load flag value (0 or 1)
[Main+R0+0x0004B26B8C]= cmp w20, #1 // Check if flag is 1 (ZL+ZR held)
[Main+R0+0x0004B26B90]= b.ne #0x4b26b9c // If not 1, skip to do nothing
[Main+R0+0x0004B26B94]= str wzr, [x22, #0x250] // Set enemy HP to zero
[Main+R0+0x0004B26B98]= b #0x410188 // Return to game code
[Main+R0+0x0004B26B9C]= b #0x410188 // Do nothing, return to game code

// Player code
[Main+R0+0x0004B26BA0]= str w20, [x22, #0x268] // Set TP to 40304
[Main+R0+0x0004B26BA4]= ldr w20, [x22, #0x254] // Load max HP
[Main+R0+0x0004B26BA8]= str w20, [x22, #0x250] // Set current HP to max
[Main+R0+0x0004B26BAC]= b #0x410188 // Return to game code

// Literal pool and flag
[Main+R0+0x0004B26BB0]= dec:40304 // Literal value for TP
[Main+R0+0x0004B26BB4]= dec:0 // Keypress flag (default 0)
```

**Cheat Engine Configuration**:
- Set `[Main+R0+0x0004B26BB4]` to `1` when ZL+ZR are held.
- Set `[Main+R0+0x0004B26BB4]` to `0` when ZL+ZR are not held.

### How It Works

- **Player Path**:
- If `w20` (40304) equals `w19`, the entity is friendly (likely the player).
- Branches to `[Main+R0+0x0004B26BA0]`, sets TP to 40304, and HP to its maximum value, then returns to the game.

- **Enemy Path**:
- If `w20` does not equal `w19`, the entity is an enemy.
- Loads a flag byte from `[Main+R0+0x0004B26BB4]` into `w20`.
- If the flag is `1` (ZL+ZR held), sets enemy HP to zero at `[x22, #0x250]`.
- If the flag is `0`, skips the HP modification and returns to the game.

- **Flag Management**:
- The cheat engine updates the flag at `[Main+R0+0x0004B26BB4]` based on keypress state, a memory write operation that is typically supported even without dynamic ASM.

### Key Improvements

1. **No Dynamic ASM Required**:
- The code checks a memory flag instead of relying on runtime instruction changes, making it compatible with systems that don’t support dynamic ASM modification.

2. **Robustness**:
- As long as the cheat engine can write to memory based on keypresses (a common feature), the enemy-killing functionality works dynamically at runtime.

3. **Code Organization**:
- Player code is moved to `[Main+R0+0x0004B26BA0]` to accommodate the enemy flag check, ensuring a clean flow without overwriting instructions.

4. **Register Usage**:
- Reuses `w20` after the initial comparison, as its value (40304) is preserved for the player path and repurposed safely in the enemy path, minimizing register conflicts. (Assumes `x20`/`w20` is not needed by the game code post-branch.)

### Notes

- **Address Assumptions**: The literal pool (`40304`) and flag byte are placed at `[Main+R0+0x0004B26BB0]` and `[Main+R0+0x0004B26BB4]`, respectively, assuming the code cave has space up to at least `0x4b26bb4`. Adjust these addresses if the code cave size or alignment differs.
- **Instruction Syntax**: The cheat uses a format like `ldr w20, #address` to load from a literal pool, consistent with the original. In standard ARM64 assembly, this might be `ldr w20, [pc, #offset]`, but the provided syntax is retained for compatibility.
- **Register Safety**: If `x20`/`w20` is used elsewhere in the game’s context, consider saving and restoring it or using an alternative register (e.g., `x21`/`w21`), though this version assumes it’s safe here.

### Conclusion

This improved version maintains the original cheat’s intent—maximizing player HP and TP, and optionally killing enemies with ZL+ZR—while removing the dependency on dynamic ASM. By leveraging a memory flag controlled by the cheat engine, it ensures broader compatibility and reliable runtime behavior, making it a more robust solution for game modification.

 

[Yuniheim]

About the treasure chest quality cheats that were shared here... it wasn't made clear for me (or perhaps I missed because it was a bit confusing) but does it behave like a forced gold quality or something similar to the one avaliable at XBX of wii U?

because if yes, it would make certain sidequests impossible to complete as some quest items come from silver chests, the wii u code had two codes to force a chest quality or to disable the "forced" part of the code since it would softlock you in quests if you forced the quality (iirc the main quest involving telethia has a story item that only drops on silver chests)
if this wasn't addressed yet now it would be a good oportunity to do so

picture from cemu just for reference of what I'm talking about

 

[Mokuu]

I like fps mods because they are pretty good, this lossless scaling program is bad, no change at all from original other than it was worse and trust me their 144fps was garbage.

rick i'm sorry but are you a bit dense perhaps? why are you trying to get 144fps from a 30fps base.. please man, do some research before mouthing off like that, honestly dude..

 

[TomSwitch]

rick i'm sorry but are you a bit dense perhaps? why are you trying to get 144fps from a 30fps base.. please man, do some research before mouthing off like that, honestly dude..

Dude got a 144FPS display and would die inside if the game doesn’t hit it. Dude is just a regular guy who loves his display.

 

[retnuh730]

rick i'm sorry but are you a bit dense perhaps? why are you trying to get 144fps from a 30fps base.. please man, do some research before mouthing off like that, honestly dude..

When FFVII Rebirth came to PC a couple months back everyone made a big deal about a steam deck framegen mod for it that “gave 60fps”. Turns out when you had it running the frames themselves never got over 30, but the counter did. None of the frame gen hype heads even noticed that the game still ran at 30. They only cared about the number going up.

 

[TomSwitch]

When FFVII Rebirth came to PC a couple months back everyone made a big deal about a steam deck framegen mod for it that “gave 60fps”. Turns out when you had it running the frames themselves never got over 30, but the counter did. None of the frame gen hype heads even noticed that the game still ran at 30. They only cared about the number going up.

Dude got to feel good and there is no better way than to be told to feel good.

It's also nice to believe you now get more gold chest with the get more gold chest cheat.

 

[angrynewraze]

rick i'm sorry but are you a bit dense perhaps? why are you trying to get 144fps from a 30fps base.. please man, do some research before mouthing off like that, honestly dude..

I also want both a 120FPS and a 144FPS cheat

 

[Mokuu]

Dude got a 144FPS display and would die inside if the game doesn’t hit it. Dude is just a regular guy who loves his display.

okay you made it sound kinda cute actually.. ;'<
but the reality of it is probably a bit more, bonk to the head if you get what im sayin'.
also, wicked tutorial for converting cheats a few posts back!! some people (not me) are gonna cook up some good stuff with that, so tyty for the contributions man <3

Post automatically merged: Mar 20, 2025

I also want both a 120FPS and a 144FPS cheat

as would I, but even just a 60fps cheat would work fine.. as lossless would work wonders with even just that. trying to framegen below 60 base is pretty scuffed but i've been going from 30>60 with it in this game and it's an improvement at least ;o

Post automatically merged: Mar 20, 2025

When FFVII Rebirth came to PC a couple months back everyone made a big deal about a steam deck framegen mod for it that “gave 60fps”. Turns out when you had it running the frames themselves never got over 30, but the counter did. None of the frame gen hype heads even noticed that the game still ran at 30. They only cared about the number going up.

that is insane.. ahahah bless themm

 

[asmoranomar]

I have no clue what any of that even means

Generally, toggle cheats on the switch in emulators can't be toggled because codes change the game's assembly. Since emulators aren't running on the original hardware, the game has to be translated to work on the new hardware. In doing so, it makes toggle-type codes difficult to work with, because you'd have to keep re-translating the code.

Basically the idea is to make the code always-on.

It should be noted, using something like cheat engine could make toggle-type codes, but it's difficult for modern emulators because they use a lot of just-in-time compilation. It would also only be restricted to one emulator (and possibly version). The idea is your actually toggling the translated code rather than the original.

As a kind of similar analogy, if you take the 'always pick up collectables' cheat I modified to work for Ryujinx use as an example, I moved the cheat out of the master codes and into the cheat itself. I've had confirmation it works on the switch too. Even tho it's not a toggle (by button press, afaik), the idea is the same. The code is removed from the limitations and turned into an 'always-on' state.

 

[angrynewraze]

Generally, toggle cheats on the switch in emulators can't be toggled because codes change the game's assembly. Since emulators aren't running on the original hardware, the game has to be translated to work on the new hardware. In doing so, it makes toggle-type codes difficult to work with, because you'd have to keep re-translating the code.

Basically the idea is to make the code always-on.

It should be noted, using something like cheat engine could make toggle-type codes, but it's difficult for modern emulators because they use a lot of just-in-time compilation. It would also only be restricted to one emulator (and possibly version). The idea is your actually toggling the translated code rather than the original.

As a kind of similar analogy, if you take the 'always pick up collectables' cheat I modified to work for Ryujinx use as an example, I moved the cheat out of the master codes and into the cheat itself. I've had confirmation it works on the switch too. Even tho it's not a toggle (by button press, afaik), the idea is the same. The code is removed from the limitations and turned into an 'always-on' state.

now that I understood. and that is very interesting as well. So if I'm understanding this correctly and feel free to correct me if I'm not understanding correctly. But the reason the cheat has to be in always on state for the emulators is bc the emulators run the game in ram and that's why it's always changing correct? vs the console runs the game off it's ssd type storage and that's why the game code isn't always changing hence why there could be toggle cheats on the console is that correct?

 

[asmoranomar]

now that I understood. and that is very interesting as well. So if I'm understanding this correctly and feel free to correct me if I'm not understanding correctly. But the reason the cheat has to be in always on state for the emulators is bc the emulators run the game in ram and that's why it's always changing correct vs the console runs the game off it's ssd type storage and that's why the game code isn't always changing hence why there could be toggle cheats on the console is that correct?

not quite. the switch is an entirely different CPU architecture. Assembly is the language that tells the CPU what to do. It's like writing a book (the game) in one language, translating it to another, and then watching the original book get updates. You CAN re-translate the book, but god is it a pain in the ass when it happens every few seconds.

Edit: In this context, we just decide to 'change the book' once and leave it be. You can't turn the cheat off, but in actuality there's few codes that NEED to be toggled.

An example of a NEEDED toggle might be moon jump. A toggle that might be convenient might be an instant resource, but only on your turn (or something) so your opponent doesn't get that resource. It's easy (and shorter) to make a toggle, harder to make code that detects the player vs the opponent. But in the case of emulators, you'd have to take the harder route.

 

[angrynewraze]

not quite. the switch is an entirely different CPU architecture. Assembly is the language that tells the CPU what to do. It's like writing a book in one language, translating it to another, and then watching the original book get updates. You CAN re-translate the book, but god is it a pain in the ass when it happens every few seconds.

Oh ok. Now I get it. And yeah it would be a pain in the ass to constantly have to write a new cheat every few seconds when the codes change. The only thing that could possibly keep up with that day and night and day in and day out would be a robot bc those wouldn't need to sleep ever.

 

[C_H_E_W]

If you could somehow share your CT file, I'd also work on getting a switch code working.

I'm actually close to finishing it, I have the actual pointer (they all share the same pointer) and have verified it mapping correctly. I just need to finish the actual code itself.

i'd say if anyone wants a "Breast Slider" it'd be better to wait for a Save Editor if anything as the Value is still very much used for every NPC in the game that uses the game's Armor. pretty sure at least. unless the slider is just commented out in the code lol.

that or figure out where it is in the Saved Character File Save and hex edit it your self.

This is actually incorrect. In figuring this out, every single one of a character's statistics is basically loaded into memory sequentially, so you'd need to be intentionally going out of your way to change an Party Member's stats over your own.

 

[SoggyWafflz]

I'm actually close to finishing it, I have the actual pointer (they all share the same pointer) and have verified it mapping correctly. I just need to finish the actual code itself.

bless you, everything points to it being likely that these changes will also apply online and I can't wait to test that tomorrow

 

[joekree]

anyone working on a 21:9 mod?

 

[C_H_E_W]

bless you, everything points to it being likely that these changes will also apply online and I can't wait to test that tomorrow

Its actually really funny, as far as I can tell the way you can control a ridiculous number of things off this one pointer, like I mean every single inventory slot, stats about every single party member (and seemingly every Human NPC that uses their framework), every (customizable) aspect of the player character, your level/class/rank experience and BP/Affinity, the same stats for party members, your Equipment and Skell data, any Upgrades or Augments your Equipment/Skells have, your Funds/Miranium/Tickets, Map nodes, progression flags, and a whole load of other stuff. This isn't new either, the Wii U version worked the exact same way, literally just hundreds of thousands of variables mapped sequentially, which honestly should make finding stuff WAY easier since it means we can just use old tools from the original game (XCXGecko) to find a ridiculous number of values. I managed to get a fully functional pointer Funds, Miranium, Tickets, and Player BP this way, for example. As far as i can tell, these are the main places the game reads and writes data to from game/save files (which you can also parse from the ludicrous number of game file names being called directly before this section of RAM), so just by using that older information as a reference, we actually should be able to break the game wide open in that regard really easily.

 

[SoggyWafflz]

Its actually really funny, as far as I can tell the way you can control a ridiculous number of things off this one pointer, like I mean every single inventory slot, stats about every single party member (and seemingly every Human NPC that uses their framework), every (customizable) aspect of the player character, your level/class/rank experience and BP/Affinity, the same stats for party members, your Equipment and Skell data, any Upgrades or Augments your Equipment/Skells have, your Funds/Miranium/Tickets, Map nodes, progression flags, and a whole load of other stuff. This isn't new either, the Wii U version worked the exact same way, literally just hundreds of thousands of variables mapped sequentially, which honestly should make finding stuff WAY easier since it means we can just use old tools from the original game (XCXGecko) to find a ridiculous number of values. I managed to get a fully functional pointer Funds, Miranium, Tickets, and Player BP this way, for example. As far as i can tell, these are the main places the game reads and writes data to from game/save files (which you can also parse from the ludicrous number of game file names being called directly before this section of RAM), so just by using that older information as a reference, we actually should be able to break the game wide open in that regard really easily.

hell yeah, it's not hurting anybody so why obfuscate the shit out of everything?

 

[C_H_E_W]

hell yeah, it's not hurting anybody so why obfuscate the shit out of everything?

Yeah, like here's a handful of codes I just finished while testing that mark the Player's Funds, Miranium, Personal BP, and Material Tickets, no weird behaviors or anything even if you go past the Miranium/Ticket cap, all using the exact same pointer as the chest values (which have a MUCH lower offset). This worked for me on both Ryujinx and Switch, so hopefully they work on other emulators and people's own hardware as well

[BP Test]​

580F0000 01DD0408​

780F0000 000006A4​

640F0000 00000000 000003E7​

​

[Funds Test]​

580F0000 01DD0408​

780F0000 0001B5CC​

640F0000 00000000 3B9AC9FF​

​

[Miranium Test]​

580F0000 01DD0408​

780F0000 0001B5D0​

640F0000 00000000 000F423F​

​

[Ticket Test]​

580F0000 01DD0408​

780F0000 0001B5D4​

640F0000 00000000 0000270F​

Obviously we already have cheat codes for these things, this is just a demonstration of what I mean while I finish the Chest Codes.