...but why? The entire benefit for using a 7z archive is to put both the 32bit and 64bit versions into a single archive, but the installer only needs a single version, so there's no reason for the version that the installer itself grabs to then be packaged in a 7z archive...or heck even be packaged in an archive at all.
And even if you want it to remain packaged in an archive for whatever reason, why does the installer need to unpack it by itself? Can't the user just to that themselves? I could understand wanting to automatically unpack it if the new version would then automatically run, but currently doesn't the user still need to manually run the newly-download version?
EDIT: And then there's the part where the entire existence of the 64bit installer is a bit questionable considering that the VN itself is 32bit...in which case one could argue that it'd make more sense to just leave everything as-is and just drop the 64bit installer altogether.
HELP WANTED - Contact me if you know the original source of this song:
~ "I have no idea what I'm doing, but at least I'm trying."
Uhhh, it kind of isn't seeing as the combined 7z archive is pretty much the same size and the individual archives currently, and most people as well as the installer itself are only going to ever be needing to download one version rather than both...
So in the end the bandwidth requirements aren't really any different for the normal end-user; the only time it would make a difference bandwidth wise is if you needed both versions anyway which is pretty much only for testing purposes and the like.
HELP WANTED - Contact me if you know the original source of this song:
...hey wait a minute, can the installer's built-in updater automatically run and extract self-extracting 7z archives and then subsequently automatically run the newly-extracted installer?
Original post
HELP WANTED - Contact me if you know the original source of this song:
I can't get it to support 7z format, but yes. Didn't you test that for me and even stated that it did in fact work? You don't remember going through a bunch of revisions and then I had one where I said I was a dumbass and didn't realize that an executable could move itself in windows and that that simplified things?
Also I just got it to support lzma so atleast can do zip with lzma compression. It comes out to 90Mb. Damn hidden imports had me baffled.
Last edited by TheUnknownIdentity; March 21st, 2019 at 07:01 PM.
~ "I have no idea what I'm doing, but at least I'm trying."
I discovered a regression in the readme's contents between the Feb.18 0.9.0 version and the Mar.19 0.9.1 version.
It's really minor and derpy, but it is still a regression nonetheless...
The file "supported_games.png" found in the Mar.19 0.9.1 version is the old pre-public version that existed in builds back in like January or so, but it was updated between then and the initial public Feb.18 0.9.0 version...and the Mar.19 0.9.1 version regressed back to the old pre-public version.
The most obvious difference is the file size - the updated Feb.18 0.9.0 version of "supported_games.png" is only 11KB while the older pre-public version is 23KB (there are other visual differences as well, but they may not be noticeable to the untrained eye).
I'm pretty sure I only said that 7zip supports self-extracting archives and didn't do any testing since I'd have no idea how to test that out with the installer's built-in update function (remember, I have no software dev skills!).
Also last I checked, 7zip's normal self-extracting archive does not support automatically running any extracted files...at least by default. It might be possible, but I've no idea how to go about doing such a thing.
And I recall one of you people being concerned about having people download EXE files? Technically you could cheat by giving it a 7z file extension instead and the likes of 7zip and WinRAR will still treat it like any old 7z archive.
Interestingly I can only get it down to 94MB with an LZMA-encoded ZIP...but whatever, personally I'd say 90MB is close enough.
HELP WANTED - Contact me if you know the original source of this song:
Last edited by TheUnknownIdentity; March 21st, 2019 at 07:17 PM. Reason: Maybe I misunderstood
~ "I have no idea what I'm doing, but at least I'm trying."
HELP WANTED - Contact me if you know the original source of this song:
Please. I would prefer to not have to redownload it. Also it appears there may have been a complete miscommunication that went unnoticed. Were you unaware that I was aiming to make the installer able to not only update the patches, but update itself and that is what the initial prompt on startup is for?
~ "I have no idea what I'm doing, but at least I'm trying."
Here: ****************************open?id=1EI...oypGQnB29CDiR2
Keep in mind that I'll likely delete it from the link above at some point in the future (I dunno, maybe anywhere between a few weeks to a couple months from now?).
EDIT: I'll keep it up until the next patch version actually releases so that I can confirm that this regression has been fixed.
I'm well aware of this considering that I had several criticisms about how you went about prompting the user when you had me test this stuff a few weeks back.
Last edited by NM64; August 19th, 2019 at 01:18 AM.
HELP WANTED - Contact me if you know the original source of this song:
When I was playing around with the UBW OPs for PS2 and Vita, I noticed there's a pretty distinct volume difference between the two.
I'll try to keep that in mind when we replace said OPs with higher quality versions in whatever future version that will be since volume balance and gain levels is actually a really easy thing to fix with AAC audio (which is pwhat we're using for the MP4 video files).
EDIT: Yeah, according to foobar2000 the audio in the PS2 UBW OP is 10dB louder than the audio in the Vita UBW OP.
I mean, technically it's such a quick and easy fix we could do it right here and now - it's so simple one of you non-audio experts could even do it:
1. open foobar2000
2. put all the according MP4 video files into its playlist
3. highlight all of the files in foobar2000's playlist
4. right click on the highlighted items in foobar2000's playlist
5. in the right-click menu that appeared, navigate to "ReplayGain" -> "Scan per-file track gain"
6. after it finishes processing and a new window appears, click the button "Update File Tags"
7. once again, right click on the highlighted items in foobar2000's playlist
8. this time, in the right-click menu, navigate to "ReplayGain" -> "Apply track ReplayGain to file content"
9. in the pop-up message box that appears, click the button "Understood, continue"
...and that's it! Repack your newly volume-corrected MP4s into the patch_op.xp3 file and call it a day.
EDIT 2: Still not easy enough? Here's a BPS rom-patch file for the existing newest patch_op.xp3 archive to apply the above-mentioned audio volume fix (I will likely delete this file anywhere from a few weeks to a couple months from now):
****************************open?id=15-...jo4IvakMD97Kr2
If you aren't familiar with BPS rom-patch files, they can be applied via a traditional offline program like Floating IPS or via a browser-based javascript app like Rom Patcher JS (select the original newest patch_op.xp3 for the "rom file", the CRC32 should be "71c67f65"; also note that all processing occurs locally so nothing gets uploaded anywhere).
Last edited by NM64; March 22nd, 2019 at 02:23 AM.
HELP WANTED - Contact me if you know the original source of this song:
Ah right, my disappearance was BEFORE I got good sound design lessons at film school.
After actually learning sound design I pretty much cringed every time I went back to any editing work I did beforehand because of how horrifically inconsistent my audio was. I once did a series of UBW anime character CM style videos for the FSN cast but now I'm like "christ how could I not notice such an obvious problem."
Rambling aside, aren't we going to do a bunch of touchup work on these videos anyway? We might as well just fix the mixing while we're doing that. It wouldn't be hard for me to do at all in any editor.
Memorable quotes
Originally Posted by Kinoko NasuOriginally Posted by UnlimitedBladeWorks
Okay so someone remind me, didn't we fix an issue where changing quality settings in the music menu was causing crashes? Because I seem to be running into one.
Memorable quotes
Originally Posted by Kinoko NasuOriginally Posted by UnlimitedBladeWorks
Well the main thing is that I'm not really quite ready to deal with that kind of heavier-duty stuff just yet, and the volume fix the for videos was so stupidly easy to do, hence why I went through and implemented a fix myself here and now.
...also it gave me an excuse to test out using BPS patch files for more drastic changes, and I'm pleased to see it only resulted in a 20MB file size (which is much better than the 700+MB size that all of the MP4 videos would take up in total).
I mean, if you want to do the video stuff purely on your own then that's fine, but just know that I don't think I'll be able to do much at all in the mean time.
...and from an OCD audiophile perspective, the way I did the volume fix was completely lossless.
HELP WANTED - Contact me if you know the original source of this song:
Ever thought about using xdelta3 as delta patch? Even Google Chrome uses the same standardized format for updates to the program.
Hey uh, I was doing some screenshot comparisons with very high resolution fullscreen and window sizes and I noticed that, even when set to "high" quality, any size or resolution greater than 1.00x results in the text being upscaled rather than being actually rendered at said resolution.
I thought it was established a couple years back or something that the text resolution would be completely resolution independent and would render separately from the rest of the art assets? (like would happen in most other more modern VNs, especially those made with newer versions of Ren'py)
EDIT: Oh boy, the rabbit hole goes even deeper than that - turns out everything is limited to a resolution of 960p, so if you actually put in an art asset that is 1080p and run the VN at 1080p or greater, the VN is actually downscaling the according art asset to 960p before then upscaling to 1080p or the like.
Worse yet, this even applies to "wide" mode as well which means it's actually 100% impossible to not have the background graphics be upscaled unless you're running in fullscreen with a resolution of 1280px wide or less (even a 0.80x window size still results in some upscaling in "wide" mode).
So I guess that completely rules out there being any benefit to making some of the CG images be 1600x1200 instead of 1280x960...
EDIT2: At least I can confirm that the OP videos are capable of actually rendering (and not just displaying) at 1080p natively.
kind of off-topic BPS vs xdelta3 stuff
Last edited by NM64; March 22nd, 2019 at 06:51 PM.
HELP WANTED - Contact me if you know the original source of this song:
The resolution setting is just software scaling of the whole window. It was ported from Mahoyo.
The quality setting actually changes the rendering resolution (before the scaling). Which is 960p for high quality. But we can always add super high quality option for 1200p. It's very easy as the code is not limited to any one resolution (internally, that is. I'm aware that it is currently locked but that's for safety reasons. I don't want big reports about why the game doesn't run on my IMAX screen).