Fate/Stay Night [Realta Nua] - Ultimate Edition (thread discontinued, see OP for new thread)

[NM64]

Little tidbit… The filesizes of the WebP files in the mobile version appeared to have increased (1.0GB -> 1.4GB) between v2.0.2 and v2.1.5, and there are 1080p vita OPs encoded in Ogg Theora…

Reverse engineering is ongoing

Just remember that increased resolution may not necessarily result in better quality, especially if the WebP and/or OPs were simply upscaled (which we know they already did for some of the existing WebP CG images, whereby waifu2x-ing the original 800x600 CG resulted in much better quality)

This is similarly why the waifu2x vita-ripped OPs looked way better than the mobile-ripped OPs despite the latter being natively higher resolution - because the bitrate was just way too low for a given codec.

I didn't tag the beta release, and I don't plan to maintain multiple branches. So just wait.
You can join our discord server for updates :P

...I guess I can repack the beta with major bug fixes. Is there a list anywhere?

I think this is all of them. Hopefully I didn't miss any:
(There may be some redundancy.)

I also reported via PM how my custom-made looping background music for the last episode epilogue didn't actually loop when "disable forced auto-read" was checked...but now that I'm thinking about it, that may have just been in the previous non-public v1.0 beta and not in the actual public v1.0 beta. I'm re-checking that now. EDIT: Yup, not an issue in the existing public v1.0 beta, so nevermind regarding that specific bug.

However, what is still an issue is that, if you have "disable forced auto-read" checked and make a save sometime in the middle of last episode's epilogue (such as when Saber first shows up on-screen) when the music is still playing, quit to the title screen, and then load that aforementioned save, there will be no music playing.



There's a handful of open issue reports I had submitted on the previous bitbucket repo that were then imported over to the current repo, such as how "wide (auto)" is buggy for ratios taller than 4:3 and ratios wider than 16:9.

There are also a few closed issue reports on the same current repo, such as renaming "wide (auto)" to something else that conveys its function better, or how there's general bugginess if you try changing quality or aspect ratio when viewing a "skip this scene", or how h-scene save slot thumbnails were not being censored when "Censor H content" is selected.

[Kariya]

In the final fight of HF, when Shirou last stand against Kotomine, the part of Light and Darkness it sounds is not the correct one, (After "Get lost" and Shirou scream) any solution?

[Quibi]

It's a special mix played in that fight added in RN mobile.
You can use Patch->Music Content->Classic for the original track.

Anyway, all of those issues have been solved. I think it's possible to release an update for patch.xp3... lemme see...

[Alyinghood]

FSN, FHA, and WoH all share the same base code, so whatever gets implemented will be available for all three games.
I think the current codebase should be ready for release. I can fix issues relatively quickly whenever they arise, and release new patches…

[Kariya]

It's a special mix played in that fight added in RN mobile.
You can use Patch->Music Content->Classic for the original track.

Anyway, all of those issues have been solved. I think it's possible to release an update for patch.xp3... lemme see...

Thanks for the help, but I don't see Music Content in Patch.

[Nikki]

Anyway, all of those issues have been solved. I think it's possible to release an update for patch.xp3... lemme see...

Please do, it would make the 1.0 beta the most bugfree build to date. While I'm sure the current codebase has a lot more content and features, there's no doubt going to be a lot of new bugs as well. It'll be good to have this as a fallback at the very least, as well as something to share with friends who aren't patient or savvy enough to work around potential issues just to enjoy some extra enhancements.

[NM64]

Considering the last official version was v0.9.1, is there a reason we can't just make this bugfixed 1.0 beta a new official version, such as something like v0.9.5?

And then if any subsequent hotfixes are needed (like how v0.9.1 was a hotfix for v0.9.0), then release a v0.9.6, v0.9.7, etc. etc. as needed.

[Nikki]

Considering the last official version was v0.9.1, is there a reason we can't just make this bugfixed 1.0 beta a new official version, such as something like v0.9.5?

That would be nice.

[N0Mi0]

>Last few pages

Either I am a tad bit too drank and sleepy, but why would you ever use YUV instead of RGB in the first place? Saving size is nonsensical in this day and age, especially so for a few gigs VN. Sounds like employing features for the sake of features to me. The release is perfect, aside from bugs, as it is already.

[Alyinghood]

>Last few pages

Either I am a tad bit too drank and sleepy, but why would you ever use YUV instead of RGB in the first place? Saving size is nonsensical in this day and age, especially so for a few gigs VN. Sounds like employing features for the sake of features to me. The release is perfect, aside from bugs, as it is already.

YUV and RGB both take the same size when each channel is the same size, so there is no saved space. There is no plan to add the feature.

[NM64]

why would you ever use YUV instead of RGB in the first place?

The lossy WebP images that we use are taken directly from from the mobile version of Realta Nua, and in that they used lossy WebP which uses YUV with 4:2:0 chroma subsampling (something that can only be done with YUV) to farther reduce the file size.

The thing with AVIF is that it's a format derived from the AV1 video codec, and YUV is used in 99.99999% of all digitally recorded video, so the AVIF format doesn't even support the RGB color space even in lossless. This is where I was saying that turning 8bit RGB into 10bit YUV, while not mathematically lossless, is most certainly going to be perceptually lossless to the human eye.

[XerBlade]

>Last few pages

Either I am a tad bit too drank and sleepy, but why would you ever use YUV instead of RGB in the first place? Saving size is nonsensical in this day and age, especially so for a few gigs VN. Sounds like employing features for the sake of features to me. The release is perfect, aside from bugs, as it is already.

The rest of that comment aside... "Saving size is nonsensical in this day and age"

That is quite possibly the most untrue statement in the history of CS untruths.

If anything, it is far more important now than it has ever been. Any programmer who says otherwise either has been living under a rock for their entire life and never had to pay any attention to the real world, or is a complete amateur who has a severe case of an entitled viewpoint of the world (wherein they believe they are the world, and note I have met people who fit that description to a 't').

- - - Updated - - -

BTW, for just one aspect of why that is the case: More and more people are going online by the day. And as that happens, the average device storage levels and network speeds are actually going down, not up. This usually isn't an issue for your typical whiners about first-world problems in the decent neighborhoods in large cities in Europe and the US, but it's a major issue literally everywhere else. And by the way, even ignoring the huge English-speaking fanbase that exists in India (seriously, just to give an example from first-hand experience, I get nearly as many users accessing the Fate walkthroughs on my website from India as from the US), nearly all of rural America doesn't even have access to broadband internet. And that's by the "official" definition of "broadband," which is actually still really slow.

[NM64]

nearly all of rural America doesn't even have access to broadband internet. And that's by the "official" definition of "broadband," which is actually still really slow.

That's me, but even then I don't think the sub-2GB file size is an issue for such locations. I had 1.5Mbps (~150KB/s) from mid 2000s until somewhere around 2009, and then had 3Mbps (~350KB/s) until about 18 months ago when we got bumped up to 10Mbps (~1MB/s)...though they had to do something fancy whereby the split the connection across two phone lines because we live too far away to get a solid connection over one line.

Oh yeah, this is DSL if you couldn't tell.

[Nikki]

Anyway, all of those issues have been solved. I think it's possible to release an update for patch.xp3... lemme see...

Is this still happening, or has this been dropped in favor of something else?

[NM64]

Return of the full PM inbox:

• Quibi has exceeded their stored private messages quota and cannot accept further messages until they clear some space.

Basically I just wanted to reply saying, if I'm to submit a bug report on the issue tracker, then what version should I call it? I mean, if we keep calling everything "1.0 beta" then confusion is abound to occur.

Is this still happening, or has this been dropped in favor of something else?

AFAICT It's still happening, Quibi has been sending me test patch.xp3 files to make sure they actually work (the first attempt wouldn't even launch because uyjulian changed the format, and the second attempt was only sent to me yesterday).

[Nikki]

I think you should call it 1.1 and then the major release that julian is working on should be 2.0. Considering how many features it has, I think it's worthy of such a big version bump.

[Alyinghood]

I think you should call it 1.1 and then the major release that julian is working on should be 2.0. Considering how many features it has, I think it's worthy of such a big version bump.

There's not really that much new features in the current codebase relating to this game. Most of it is just code refactoring and cleanup (to reduce possible errors, increase performance, assist in automated testing, and changes related to the multi-platform port).

I am not going to do any major refactoring for this month so that the new release can be done.

Basically I just wanted to reply saying, if I'm to submit a bug report on the issue tracker, then what version should I call it? I mean, if we keep calling everything "1.0 beta" then confusion is abound to occur.

For now, just put the sha256 hash and creation date (or any other date if you didn't extract it from the archive) of the "patch.xp3" on the issue tracker.

I plan to include commit, date, and build machine information in the log later…

[Nikki]

Alright, well, 1.1 and then 1.2 then, would be my suggestion.

[NM64]

For now, just put the sha256 hash

Does it have to be sha256? I mean at least for this one time I did retrieve the sha256 hash via a not-so-straightforward method involving my my Linux-running media server, but the Windows-compatible hash shell extension I use on my desktop PC "only" has crc32, md4, md5, and sha1.

and creation date

The archive Quibi sent me that contained the patch.xp3 file has an (improperly-formatted) date right in the filename - will that work?

And by improperly formatted I mean YYYY-DD-MM, and no that is not a typo unless it's a file from the future and this year has 14 months in it (the date it referred to was 2020-09-14 but it listed it as 2020-14-09).

[Nikki]

Does it have to be sha256? I mean at least for this one time I did retrieve the sha256 hash via a not-so-straightforward method involving my my Linux-running media server, but the Windows-compatible hash shell extension I use on my desktop PC "only" has crc32, md4, md5, and sha1.

7-Zip adds a CRC SHA context menu option that has SHA-256.