# Future of Cheats on the Wii U

# TCP Gecko
- _Very_ old code base.
- Maybe needs a fresh start?
- Shares some functions with [DiiBugger](https://github.com/Maschell/DiiBuggerWUPS), no need to implement it twice.
- Has multiple usages which could also be split up into multiple plugins
- Find cheats
- Apply cheats
- ...
- Everything filesystem-related could be replaced by using a ftpiiu plugin.

# The problem of the shifting memory.
The position of the (part of the) heap that a game is using might shift depending on the plugins that will be loaded together with a Cheating-Apply-Plugin.
**In the following the term "heap address" is refered to the position of the portion of the heap that a game is using.**
Currently most of the existing cheats are using **absolute** addresses which point into the heap. These cheats would all break when heap shifts.

## Possible solutions

To solve this problem there are some possible solutions:

### 1. Just keep old code and re-calculate the addresses on the fly
When you know the expected and new heap-address, you could modify the exiting code on the fly to make it compatible to heap shifts.
This is probably a really bad idea because you somehow have to tell the CheatEngine these addresses.
All newly created cheats would also have to use the old-faulty addresses, just to be fixed by the cheat engine afterwars. Not a great idea.

### 2. Modify existing codes to use addresses relative to the heap address.
Roughly the same as the first possible solution, but instead of calculating the addresses on the fly, you would have to caclulate it beforehand.
Pros:
- new cheats could directly use the relative addresses
- The cheat engine don't need to recalculate everything

Cons:
- It might be ugly to get the right position on the heap. (maybe even alignment could be a problem).
- old cheats don't work anymore without porting.

### 3. Use pointers from within the loaded .rpx
The position of the .rpx can recieved easly. Everything useful on the heap needs to be addressable through pointers from within the .rpx (.data section?), otherwise it's from a memory leak.
This means every cheat would need to be rewritten to use pointer from within the .rpx.
(Could be done by limiting the pointer search to the region of the .rpx?)

Pros:
- Cheats would be independent from the heap-position. (=> independent from the running FW)

Cons:
- Cheats would need to be rewritten to always use pointers from the .rpx (and not directly pointers to the heap)
- => Every cheat would need to use pointers.

### Shited memory Conclusion
The cleanest solution would be probably solution #3, but this require effort to create new tools to port and create cheats.

## Rewriting the code handler?
The existing code handler probably needs to rewritten. Currently it's written directly in assembler, but this may be also done in C?