A lot of people were looking forward to the TCP Gecko plugin for the Wii U Plugin System.
So far I didn't start working on it (neither did anyone else) but I'm going to write down a few of my plans below:
What about JGecko U and other existing TCP Gecko tools?
JGecko U will continue to work almost exactly the same since the server commands should be kept (minus a couple redundant ones which may get deleted). Other tools may need to be modified if they are using commands which got removed. This is to clean up the plugin from unnecessary junk such as writing memory using byte, short, int or other special sized data types. Just writing a byte array is all what is necessary to support. The client code can then decide to implement those data type wrappers or not. Also, the addresses would all be shifted anyway so existing tools once more wouldn't even work without being fixed for that particular purpose.
A video showcasing the progress
That's all for now. Any questions, ideas or planned contributions?
So far I didn't start working on it (neither did anyone else) but I'm going to write down a few of my plans below:
- Implement a multi-threaded server for handling multiple TCP connections at once (for instance like described here). This will allow you to connect multiple cheat tools at once and it would make the server more stable and won't force you to restart your Wii U or the TCP Gecko if it corrupts or gets stuck as before.
- Implement the code handler in C/C++ instead of assembly to make it more maintainable for improvements and changes (I already made a functional Windows C code handler here).
- Since allocating memory on the heap in the homebrew app code shifts most cheat code addresses, this problem has to be addressed: We need to read the segment information to find the base address of each segment and then create cheats using the start address plus an offset to be shift resistant (Read more about the memory layout of C programs). Here is a write-up by Maschell about this "cheat codes problem". Making the change would mean that all of most codes have to be re-created or ported over to relative addressing. Code creators need to learn how to make cheats using relative addressing then but it's pretty simple once a respective utility is implemented (in e.g. JGecko U) so it's just a matter of a few clicks from the absolute address.
- By default when making the TCP Gecko a plugin, this will enable you to use multiple homebrew apps at once such as the other already created plugins which is really nice to have available at the same time. This is one of the main things people wanted.
- Reading memory has been slow (about 15 minutes to dump the entire MEM2 range) so with the plugin we might be able to use zlib for compression and 3 threads to accomplish a speedup (3 threads because the Wii U has 3 cores without hyperthreading I believe). Sending data cannot be parallelized but compression.
What about JGecko U and other existing TCP Gecko tools?
JGecko U will continue to work almost exactly the same since the server commands should be kept (minus a couple redundant ones which may get deleted). Other tools may need to be modified if they are using commands which got removed. This is to clean up the plugin from unnecessary junk such as writing memory using byte, short, int or other special sized data types. Just writing a byte array is all what is necessary to support. The client code can then decide to implement those data type wrappers or not. Also, the addresses would all be shifted anyway so existing tools once more wouldn't even work without being fixed for that particular purpose.
A video showcasing the progress
That's all for now. Any questions, ideas or planned contributions?
Last edited by BullyWiiPlaza,
