Missing .vcxproj prevents building project.

[J-D-K]

I’m interested in contributing some improvements to the project, particularly optimizations and code cleanup, but I’m currently blocked because the .vcxproj is missing.

Without it, I can’t build or test any changes on Windows.

Could you either provide the missing project file or suggest the recommended way to build this project?

[J-D-K]

I’m still having trouble building the project as-is because crctable.out and crctables are missing.

I was able to bypass the .vcxproj issue with CMake, but the project still won’t compile without these files.

[NoharOSP]

No problem. I can have the necessary files uploaded at some point today.

EDIT: I have uploaded the vcxproj files to the source directory. Let me know if you can build the patcher now.

[J-D-K]

I can't. I'm still missing crctable.out and I assume crctables. I'm trying to create a CMakeLists.txt file for me to build with instead. It would actually allow anyone to build this without needing full-blown VS installed. They would just need build tools and CMake.

I re-implemented your romFinder class as a small start. You can see it here and here. I saw no real guidelines for style in the project, so I'm not sure if I should continue or not? My basic tests show it runs in about 1/10th the time of the original, but without being able to build and see if there's any unintended consequences somewhere else, I'm hesitant to pull request or continue.

[NoharOSP]

Unfortunately, I have no crctable files in my project. If you are getting an exact error message, you don't mind if I see it?

You are doing me a massive favour by the way. I've wanted to increase the patcher's portability for a while, but I've been caught up with other jobs regarding the project. I'm happy to assist you in any way I can.

[J-D-K]

https://github.com/NoharOSP/Perfect_Works_Build/blob/bb0d879dbba23177fcb68abfc3cbbcefe44ec8a4/source/isoManager.cpp#L3

Right here you include two files related to CRC tables that are absent from the project files. At least, I don't see them.

I'd have to take a look at the project as a whole first. I love Xenogears, but I do have my own stuff to take care of. Just hearing there was a patch to speed up the text speed alone got my attention pretty quick. If you really want to make it cross platform and portable, I can start looking into it. There are alternatives to just Win32 GUI that would allow it to compile with GCC for anything, basically.

Reach out if you want to. We don't need to keep doing this through git issues.

[NoharOSP]

It turns out that this is a completely unused file. It was for an attempt to replicate xenoiso's code which hasn't progressed so far. The most recent commit should tell you what files you need to remove. If there are still issues after you've removed them, let me know.

[J-D-K]

I reconstructed the UI using QT6 instead of Win32API (there's no real functionality implemented yet). If one of your goals is portability, this will make it possible to build for Windows, Linux, and possibly Mac too. It also uncouples it from being tied down to VS and MFC.

I did use a lot of (mostly) modern C++. I'm not sure how up to date you are on it. I don't wanna dump something on you you're not going to be able to handle if I'm not around. I have a branch called cross-platform in my fork if you want to take a look. I was going to use your code as reference for what to do and re-implement it around QT6 just for the challenge and experience.

[NoharOSP]

I'll give this a proper look throughout the week. As I'm self-taught with C++, I'm sure that I can adapt around anything I'm unfamiliar with, though I will say if I feel it's beyond my skill level.

Did the fix I suggested with the unused files resolve your issue at all?

[J-D-K]

Sorry for not getting back to you sooner. After re-constructing the UI in QT and looking into a few other things, I have some concerns and decided to delete my fork for the time being. I maintain some other applications, a few of which are used and depended on by many people, and I don't want to take any risks with them and my account (DMCA).

My concerns are as follows:

1. Your repo contains assets and data from the game. This is extremely risky, even if some files are modified. As-is, Square-Enix would face no challenges when issuing a DMCA strike and taking it all down. They've done so in the past with Chrono-related fan projects and a fan translation of the PSP version of FF Type-0 from my research.

   • I analyzed the disc sector by sector and identified the file table structure, then implemented my own parser in C (even if it needs some cleanup):
     • Disc One Matches
     • Disc Two Matches
   • My implementation differs slightly from the tool used in the repo, as mine preserves the table structure with directories and subnaming (I could be wrong here). Using my tools alongside the repo contents, you can see patterns and correlations with how the data is stored on the disc.

2. Don't take this the wrong way, but with the code in its current state, I was having a very difficult time following and translating it all into something that worked with QT. Especially the patch script building process. I'm a self taught C/C++ programmer too, but I foresee the GUI becoming difficult to maintain and extend in the future.

So ideally, to keep this away from danger, the following would need to happen:

1. The user’s disc image should be used to extract the game’s data at runtime, rather than including it in the repo and releases.
2. Modifications and patch instructions should be stored separately instead of manually hardcoding some of them. Some of them, this does make sense.
3. The GUI would need to be rewritten from the ground up around this.

Another point is that including the game’s data and binaries in the repo has significantly increased its size. Once committed, these binaries are almost permanently included in the repository history. Because of the included data, I don’t feel comfortable cloning or working on the project as-is. I would have no problem reworking it, but to do so safely I would need to start from the ground up, given the repo’s history.

[NoharOSP]

Hello. Thanks for the detailed response. Here are my thoughts:

• Your insight into the risks associated with the project is quite humbling and I feel I have perhaps become careless since the early days of joining. I am hoping that, in the future, the whole process can be done by the patcher. There have already been pushes towards this with how experience and gold are applied as well as battle flashes, though it would be ideal if the game's files weren't so readily available. For the time being, do you think it would be less risky if the files were available in a build's 7z but not the repo?
• Trying your QT version for myself, I am definitely open to migrating away from WinAPI. Even right now, it is starting to become difficult to maintain. Admittedly, it is a product of when I was starting out with C++ and I would not have picked it knowing what I do now.
• Tools are available to extract the game's files which I could probably reverse engineer in C++ fairly short-term.
• Forgive my misunderstanding, but what are you referring to with modifications and patch instructions? No doubt I'm missing something obvious here.

Depending on what is involved with minimising risks, I am more than happy to help you with this. One last thing, for running the patcher outside of Windows, there is still the matter of the supporting tools used with the patcher. While xdelta can be on other operating systems, and xenocomp along with xenoiso have source code which could potentially be applied, the FMV tools may require Wine in order for them to work outside of Windows according to their developer.

EDIT: I've sent a friend request to you on Discord. It will probably be better if we continue the conversation there.