Only the codes are written, nothing else. It would confuse the code handler.OKI've already forked your tcpgecko, gonna start working on it now
--------------------- MERGED ---------------------------
So you know to convert codes to ascii and then put it into the .gctu file? With no newlines, spaces or anything? I'm guessing spaces and newlines aren't written to 0x10015000, because that would be a waste of RAM?
So if you put "D0000000 DEADCAFE" into your program, it will convert it to "Ð...Þ.Êþ" then put that into the .gctu file? Then when my code writes it to 0x10015000 "D0000000DEADCAFE" will appear in memory.
Yeah, also this is the Wii U menu. Let's do it without the dash then.Wait, what game is that? Doesn't OSGetTitleID() return values without dashes?
#include <inttypes.h>
#include <string.h>
...
uint64_t titleIDNum = OSGetTitleID();
char titleID[17];
sprintf(titleID, "%" PRIu64, titleIDNum);
char fileName[24];
strncat(fileName, titleID, 16);
strncat(fileName, ".gctu", 5);
Write the full code and you helped with it. The GCTU generation is fully done.Nvm, tested and worked
You didn't even test because it's clearly wrong in many ways. The code list address is different and you didn't use the right function for loading from the SD card...OK guys, I finished the tcpgecko installer code! I have sent a pull request.
Nope, RIP. More luck next time buddy. Still thanks for trying. It wasn't too bad. I implemented the code now but it's untested.The cheat table doesn't begin at 0x10015000?
#define EXTENSION_SIZE 6
#define SD_FILE_PATH_HEADER_LENGTH 10
#define TITLE_ID_LEADING_ZEROS 3
#define TITLE_ID_LENGTH 16
#define CODES_FILE_PATH_SIZE (SD_FILE_PATH_HEADER_LENGTH + TITLE_ID_LENGTH + EXTENSION_SIZE)
void applyCheatCodes() {
unsigned char filePath[CODES_FILE_PATH_SIZE];
memset(filePath, '0', sizeof(filePath));
memcpy(filePath, "sd:/codes/", SD_FILE_PATH_HEADER_LENGTH); // File path header
u64 titleID = OSGetTitleID();
char asciiTitleID[TITLE_ID_LENGTH];
snprintf(asciiTitleID, TITLE_ID_LENGTH, "%llX", titleID);
memcpy(filePath + SD_FILE_PATH_HEADER_LENGTH + TITLE_ID_LEADING_ZEROS, asciiTitleID, TITLE_ID_LENGTH); // Title ID
memcpy(filePath + SD_FILE_PATH_HEADER_LENGTH + TITLE_ID_LENGTH, ".gctu", EXTENSION_SIZE); // Extension
filePath[CODES_FILE_PATH_SIZE - 1] = '\0'; // Null-terminated
unsigned char *codes = NULL;
unsigned int codesSize = 0;
int result = LoadFileToMem((const char *) filePath, &codes, &codesSize);
if (result < 0) {
// Error, we won't write any codes
return;
}
kernelCopyData((unsigned char *) 0x01133000, codes, codesSize);
}
yes you are young, but that doesn't mean you don't have to be so good, if you keep trying from where you are now, you will be fantastic when you are 18!Bit embarrasing, I've got to say. Well, thanks for the encouragement, probably not even old enough to understand computing like you.
I'm just more familiar with C. That's the only reason since performance doesn't even matter.@BullyWiiPlaza i'm curious why you are using memcpy/c char arrays, when the project is in c++ and you could use std::string which is more readable and easier to use?
is it something about performance? some preference? not a criticism at all, i want to know so I can learn a little![]()
#define FS_STATUS_END (FS_STATUS_ERROR_BASE-2) /* Indicates end of file / directory entry */
FS_STATUS_END There are no more available mount sources.