There's an issue with Tsumi's engine caused by something related to the opening question script(because it only happens if the script fires).
I've tried several things and it seems like the engine is changed(maybe a variable issue) and force draws a textbox every two new scenes(I have no idea why it's so specific, lol), the textbox can't be disabled as if it's baked in the background.

The current version:
https://www.youtube.com/watch?v=SpQTJeiCtng

And after changing one scene draw to offset the order:
https://www.youtube.com/watch?v=0WSx9SBZpIA

I just changed this line:
https://github.com/07th-mod/tsumihoroboshi/blob/d1a6567febc2586dc3624d35ef139b928135a78e/Update/flow.txt#L23

with DrawScene( "07thlogo", 1000 );

EDIT by enumag:

To test it you need to delete global.dat in your tsumi save directory.

I think there is some sort of a problem with DisableWindow here.

Minagoroshi was updated following this tweet by Doddler https://twitter.com/The_Doddler/status/1169341927075934209

Debugging a Higurashi out of memory crash someone reported and learning in horror that my pool of layers never marks itself as initialized, so every time the game requests a new layer, it's also adding 32 additional layers to the pool that never get recycled.

It's not necessarily the first time the game has been updated.

Here's a zip with two folders containing a disassembly of the DLL that I got at release time followed by the one I just downloaded. Both of these are the MangaGamer versions. Minagoroshi Update 2019-09-04.zip (ignore that one of them has a weird .csproj filename)

The diff is below. We need to apply to our mod. It's possible that the steam version changed in other ways too, but I only have my MG copy to compare. Will have to make sure whatever additional changes might be on the steam version are propagated - especially the path separator convention we see updated here. The bug could also easily affect previous arcs, but if so we don't know whether the fix is being backported.

--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.Core.AssetManagement\AssetManager.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.Core.AssetManagement\AssetManager.cs
@@ -4,6 +4,7 @@
 using System.Collections.Generic;
 using System.ComponentModel;
 using System.IO;
+using System.Linq;
 using UnityEngine;
 
 namespace Assets.Scripts.Core.AssetManagement
@@ -181,6 +182,18 @@
 			{
 				return LoadTexture("no_data");
 			}
+		}
+
+		public string LoadTextDataString(string dataName)
+		{
+			string path = Path.Combine(Application.streamingAssetsPath, "Data");
+			return File.ReadAllText(Path.Combine(path, dataName));
+		}
+
+		public List<string> LoadTextDataLines(string dataName)
+		{
+			string path = Path.Combine(Application.streamingAssetsPath, "Data");
+			return File.ReadAllLines(Path.Combine(path, dataName)).ToList();
 		}
 
 		public Texture2D LoadTexture(string textureName)
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.Core.Audio\AudioLayerUnity.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.Core.Audio\AudioLayerUnity.cs
@@ -140,7 +140,11 @@
 			WWW audioLoader = new WWW("file:///" + path);
 			yield return audioLoader;
 			loadedName = filename;
-			audioClip = audioLoader.GetAudioClip(false);
+			audioClip = audioLoader.GetAudioClip(false, type == AudioType.BGM);
+			while (audioClip.loadState != AudioDataLoadState.Loaded)
+			{
+				yield return null;
+			}
 			isLoading = false;
 			isLoaded = true;
 			loadCoroutine = null;
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.Core.Scene\LayerPool.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.Core.Scene\LayerPool.cs
@@ -51,26 +51,19 @@
 		private void Initialize()
 		{
 			GameObject original = Resources.Load<GameObject>("Layer");
-			int num = 0;
-			while (true)
+			for (int i = 0; i < PoolSize; i++)
 			{
-				if (num < PoolSize)
+				GameObject gameObject = UnityEngine.Object.Instantiate(original);
+				if (gameObject == null)
 				{
-					GameObject gameObject = UnityEngine.Object.Instantiate(original);
-					if (gameObject == null)
-					{
-						break;
-					}
-					gameObject.transform.parent = base.transform;
-					gameObject.SetActive(false);
-					layerList.Push(gameObject);
-					layerObjList.Add(gameObject);
-					num++;
-					continue;
+					throw new Exception("Failed to instantiate Layer prefab!");
 				}
-				return;
+				gameObject.transform.parent = base.transform;
+				gameObject.SetActive(false);
+				layerList.Push(gameObject);
+				layerObjList.Add(gameObject);
 			}
-			throw new Exception("Failed to instantiate Layer prefab!");
+			isInitialized = true;
 		}
 	}
 }
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.Core.SteamWorks\Achievements.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.Core.SteamWorks\Achievements.cs
@@ -1,6 +1,5 @@
+using Assets.Scripts.Core.AssetManagement;
 using System.Collections.Generic;
-using System.IO;
-using System.Linq;
 using UnityEngine;
 
 namespace Assets.Scripts.Core.SteamWorks
@@ -11,7 +10,7 @@
 
 		public static void Load()
 		{
-			List<string> list = File.ReadAllLines(Path.Combine(Application.streamingAssetsPath, "Data\\achievements.txt")).ToList();
+			List<string> list = AssetManager.Instance.LoadTextDataLines("achievements.txt");
 			Debug.Log("Loading achievements.");
 			achievements = new Achievement_t[list.Count];
 			for (int i = 0; i < list.Count; i++)
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.Core.SteamWorks\SteamManager.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.Core.SteamWorks\SteamManager.cs
@@ -42,7 +42,7 @@
 			}
 			try
 			{
-				string path = Path.Combine(Application.streamingAssetsPath, "Data\\steamId.txt");
+				string path = Path.Combine(Application.streamingAssetsPath, "Data/steamId.txt");
 				if (!File.Exists(path))
 				{
 					Debug.Log("App id file missing, disabling steam integration.");
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.UI.Menu\MenuUIButton.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.UI.Menu\MenuUIButton.cs
@@ -52,7 +52,7 @@
 						gameSystem.SceneController.HideFace(0f);
 						gameSystem.SceneController.HideAllLayers(0f);
 						gameSystem.SceneController.HideFilmEffector(0f, false);
-						gameSystem.SceneController.FragmentController.StopFragment(100f);
+						gameSystem.SceneController.FragmentController.StopFragment(1f);
 						gameSystem.MainUIController.HideMessageBox();
 						gameSystem.ExecuteActions();
 						BurikoScriptSystem.Instance.JumpToScript("flow");
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.UI.Tips\TipsData.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.UI.Tips\TipsData.cs
@@ -1,7 +1,7 @@
+using Assets.Scripts.Core.AssetManagement;
 using Assets.Scripts.Core.Buriko;
 using Newtonsoft.Json;
 using System.Collections.Generic;
-using System.IO;
 using UnityEngine;
 
 namespace Assets.Scripts.UI.Tips
@@ -16,7 +16,7 @@
 			BurikoMemory instance = BurikoMemory.Instance;
 			if (Tips.Count == 0)
 			{
-				string value = File.ReadAllText(Path.Combine(Application.streamingAssetsPath, "Data\\tips.txt"));
+				string value = AssetManager.Instance.LoadTextDataString("tips.txt");
 				Tips = JsonConvert.DeserializeObject<List<TipsDataEntry>>(value);
 			}
 			if (global)
--- G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\first\Assets.Scripts.UI.Tips\TipsManager.cs
+++ G:\07th-mod\Misc\Minagoroshi Update 2019-09-04\latest\Assets.Scripts.UI.Tips\TipsManager.cs
@@ -26,6 +26,8 @@
 		public List<TipsEntry> TipsEntries;
 
 		public bool isActive = true;
+
+		public bool hasTips;
 
 		private int page;
 
@@ -58,7 +60,14 @@
 
 		public void ClearTitle()
 		{
-			tipsTitleText.text = string.Empty;
+			if (hasTips)
+			{
+				tipsTitleText.text = string.Empty;
+			}
+			else
+			{
+				tipsTitleText.text = ((!GameSystem.Instance.UseEnglishText) ? "入手ＴＩＰＳはありません" : "No new tips available.");
+			}
 		}
 
 		public void UpdatePage()
@@ -90,10 +99,12 @@
 				{
 					TipsEntries[i].gameObject.SetActive(true);
 					TipsEntries[i].Init(tipsData.Tips[num], this);
+					hasTips = true;
 				}
 				if (num < tipsData.TipsAvailable)
 				{
 					TipsEntries[i].gameObject.SetActive(true);
+					hasTips = true;
 				}
 			}
 			UpdatePage();
@@ -123,6 +134,10 @@
 			}
 			page = 0;
 			numPages = Mathf.CeilToInt((float)tipsData.TipsAvailable / 8f) - 1;
+			if (numPages < 0)
+			{
+				numPages = 0;
+			}
 			if (numPages >= ReturnPage)
 			{
 				page = ReturnPage;

Report from player. Right click is supposed to just close the history window.

are replayed lines supposed to be repeated at closing the textlog? sometimes it doesn't appear, but when it does, reopening and closing the textlog again also causes it to repeat. not the case when the line is scrolled up and out of sight. is this a feature?
it will also play if you close the log pointing at a line, which isn't as bad as the former
for that last case are you clicking the close button still or are you pressing escape with your mouse over a previous line
the second? I right click
the first doesn't require highlighting anything
nevermind, both cases were the right click

From @TellowKrinkle

Ahh yeah the onClick probably doesn't differentiate between what type of click it was

@IdealPersona @TellowKrinkle Could you guys add a new flag for me? Something like GVideoOpening (of course change it if you have some standard naming for our custom flags). It will have an integer value, default should be 0. I'll need it in all chapters including console arcs. It'll be used to control when to play the console opening (normally in the story, on launch if the player already reached it in the story or not at all if they opted out).

I noticed the mod dll references SE files in the switchsound folder, which is included only in the Console arcs version of our mod:

• 0.ogg
• 1.ogg
• 2.ogg
• 3.ogg
• 4.ogg
• 5.ogg
• enable.ogg,
• disable.ogg

These files are not included in the other versions of the game, so these SE never play.

I then included the files, but they are too quiet.

Foobar's replaygain burn in feature could be used to fix the files (or any other program which can normalize the levels)

Todo:

• normalize the levels of the files in the switchsound folder. I don't think they should be normalized to 0db, perhaps -6dB
• include the switchsound folder in all our releases
• include a sample voice file so you can test the voice playback level when voice volume is adjusted. Perhaps StreamingAssets\voice\voice_test.ogg
• optional: include a fallback so if the files are missing, it just plays the default click sound. but I guess if the sound doesn't play it's no big deal.

@DoctorDiablo here is the new DLL for Console with the "lipsync without spectrum file" feature for you to try out (for you to test while you're working on the next release):
Assembly-CSharp Console 2021-08-14 eb4e7df05f34a5ca3f840ff52ab9a759519dc4c7.zip

You can read the "Developer Info - Computed Lipsync" section below if you want to mess with the lipsync settings, but otherwise
you don't need to read anything below - I'm just recording for later use when I write the changelog.

Bug Fixes

• Fix a crash if you toggle any art style options too many times (~10? times) without advancing the text

  • See #54

• Original/Ryukishi mode fixes

  • Fix sprite positions not matching original game when there are 3 sprites on the screen at once.
    • Our base mod has spaced out some sprites to better fit the widescreen aspect ratio in some cases. This fix attempts to put them back to their original position when you are using 4:3 Original backgrounds.
  • Fix portrait (zoomed in sprite) images not being cropped when using 4:3 mode (you would need to use Console sprites with OG backgrounds)
  • Fix lipsync not working when using Console sprites with 4:3 Original backgrounds

Mod Menu Updates

• Fixes issues raised in: #61
• Added tabs for Gameplay, Graphics, Audio, and Troubleshooting to separate options
• Graphics presets are now "Console/Mangagamer/Original" instead of "ADV/NVL/Ryukishi"
• Made sprite/background/text window options less confusing by making the following options independent of each other:
  • Sprite style (used to be changed when changing the "art set")
  • Background style (used to be changed via an override, and would reset when "art set" changed)
  • Background stretching (used to be part of the background selection)
  • Text window appearance (used to depend on the graphics preset)
• Dedicated "Custom" graphics preset
  • Custom preset is no longer indicated by a asterisk (*) next to a default preset - instead it appears as its own preset
  • This preset is activated when you modify any of the default presets (or just click "Custom")
  • The values in the "Custom" preset are saved, even if you activate one of the default presets. This allows you to switch between your custom preset and any of the default presets to see how it looks

Old Menu

New Menu

Developer Info - Computed Lipsync

See #62 for some background on this feature

In the past, lipsync relied on .spectrum files, which the game would use to determine the mouth animation for each .ogg file.

The new computed lipsync method instead computes this on-the-fly, roughly as follows:

• While the voice file is playing:
  • Check how far the current .ogg file has played
  • Get 50ms worth of audio data at the current play time
  • Get the maximum loudness (roughly) in that 50ms
    • If louder than the Expression 2 threshold, display Expression 2 (default thresh is 70% loudness)
    • If louder than the Expression 1 threshold, display Expression 1 (default threhs is 30% loudness)
    • Otherwise, display Expression 0
  • Delay 50ms before the next loop
• When the voice file finishes, display Expression 0 (mouth closed)

This might be slightly different from the old method as:

• The old method didn't synchronize with the voice file (it just read one expression from the .spectrum file every .66ms)
• The old method might have used a different way to compute which epxression to display at any time

By default, computed lipsync only activates if there is no .spectrum file found, however there is a way to change this behaviour (see below).

Computed Lipsync Options

I've added some options both in the menu and as script commands which control the computed lipsync.

NOTE: The in-menu options are not saved when the game is closed. But you can use the script command to always use the same value on every startup.

Options in the Developer Tools section

• Force Computed Lipsync: When computed lipsync is used as a fallback, it always checks for the presence of a .spectrum file. If we decided to remove the .spectrum files, we should remove this check so we don't have an extra disk access every time an audio file plays. To do this, we can set Force Computed Lipsync to True.

  • By default, "Force Computed Lipsync" (it's only used as a fallback, not all the time)

• Lip sync thresholds: These are the volume levels above which expression 1 and expression 2 are displayed (specified as a floating point number between 0 and 1).

  • The default value for Expression 1 is .3 (that is, loudness > .3 but < .7 will display as expression 1)
    • loudness <= .3 will display as expression 0
  • The default value for Expression 2 is .7 (that is, loudness > .7 will display as expression 2)

Script Commands

There is a script command you can use to set the above values - please place it in the init.txt file:

ModGenericCall("LipSyncSettings", ".3, .7, true");

The above command would set the Expression 1 threshold to .3, Expression 2 threshold to .7, and set "Force Computed Lipsync" to true.

Here is the new DLL for Console:
Assembly-CSharp Console 2021-08-14 eb4e7df05f34a5ca3f840ff52ab9a759519dc4c7.zip

We had this report on tatarigoroshi on discord:

The problem: I've been playing Tatarigoroshi after downloading the mod, but sometimes when opening the text log, it freezes and does not let me close it or scroll. The only thing it let me do was open the menu, but then even clicking "exit scenario" didn't actually close it, just removed the characters and kept the log in place. It's happened twice and has to restart the game to get rid of it. Idk if anyone's also had this problem.

Reproduction Instructions: Not sure, it seemed to happen randomly when opening the text log

Mod/Game history: I installed the game about a year ago. I downloaded the mod for ch3 specifically, two weeks ago. No updates or anything that I know of.

The game: Tatarigoroshi

The mod variant: Full

I bought the game at: Steam

My operating system is: Windows

I installed the base game: Last year

I installed the mod: Using the installer

Mod Download and Install Date: Downloaded two weeks ago (march 3rd)

Mod Options: Everything updated, using remake sprites.

State anything "special" about your computer's setup: PC, nothing particular.

What you have already done to fix the problem: Only closing and reopening the game worked.

State if anything has changed recently: Not yet.

me: have you only encountered this issue on tatarigoroshi? or other chapters as well?

Just Tatarigoroshi. I’ve only tried playing it twice and it happened both times.

It bothers me a bit that the voices volume can only be changed by hotkeys and not directly in the game menu. After some discussion with @ItaloKnox this is what we'd like to do:

We should repurpose one of the less needed bars for this. In our case we could drop the "auto mode message speed" and simply use the normal message speed instead in the game.

It would also be nice if we could change the order of the bars like this:

• textbox opacity
• voices volume
• music volume
• sound effects volume
• message speed
• auto mode advance speed

Changing the labels is relatibely easy. We will just change the labels in photoshop and recompile the UIs. The complicated part is to make the DLL work this way.

For some reason the game includes the mapping of variable name to number in its save format. This means that if we add new flags (like LConsoleArc which was causing issues for me), they'll break old save files since the old save files will update the mapping dictionary to not have those flags

Does anyone know of any reason this would be useful? If not, we should ignore it when we load saves so that our old save compatibility is at least slightly better.

A user reported that they did not get the Detective achievement in Tatari.

Here's their global.dat for debugging: https://cdn.discordapp.com/attachments/471379035113652254/602905414509658142/global.dat

I also did not get this in Tatari, nor did I in Himatsubushi. Waiting to hear back from that player's results when they finish that arc.

I tested the new history view in Tsumi to see if everything works fine and found a little bug. It is impossible to click a line that is at the top of the screen. Not one specific line, simply any that you scroll into that position. When you scroll the line lower it works just fine.

EDIT: At first I was unable to reproduce this in Onikakushi but now I did so this affects all chapters. It seems that the line at the top isn't non-clickable always, just most of the time. I did encounter cases when it was clickable both in Oni and in Tsumi but it seemed rare and I could not figure out any pattern.

In Meakashi, Minagoroshi and console arcs we need to have partially transparent sprites in some cases. Based on the discussion on Discord it seems the engine has the ability to do that and the commands even have such API but the transparency is not preserved when lipsyncing.

Check the current state to find out which commands provide this and how and make it work with lipsync too.

It looks like some backgrounds still show as PS3 even in OG mode. I'm pretty sure I'm just missing assets for them, but the fading effects could also be a DLL issue.

Episode 4, Chapter 2, pan shot

Episode 4, Chapter 4, fading to red

Episode 4, Chapter 4, fading to greyscale

It might be possible to implement lipsync without using our current method of spectrum files:

Advantages of not using spectrum files:

1. Reduce the number of files on disk - currently there is one spectrum file per each voice file
2. No need to regenerate spectrum files if new voice files are added
3. Since we don't have access to the tool which was used to generate the spectrum files, we'd need to re-write it again (not sure if this has been done already), although it shouldn't be that complicated
4. Can adjust parameters on-the-fly (sensitivity etc) which would allow for easier tweaking

See this unity question for info on doing this..

edit: I did a quick test, and you can get the audio data - I did a quick test which prints every 1000th sample of channel 0, when inserted into the WaitForLoad() function in AudioLaterUnity.cs:

if(audioClip == null)
{
    Debug.Log($"Audio {filename}: audioClip is null!");
}
else
{
    Debug.Log($"Audio {filename}: audioClip is not null! Samples: {audioClip.samples} Channels: {audioClip.channels}");
    float[] samples = new float[audioClip.samples * audioClip.channels];
    audioClip.GetData(samples, 0);
    
    System.Text.StringBuilder sb = new System.Text.StringBuilder();
    sb.Append("[");
    for (int sample = 0; sample < 100*1000; sample += 1000)
    {
        int stride = audioClip.channels;
        int index = sample * stride;
        if (index > samples.Length)
        {
            break;
        }

        sb.Append($", {samples[index]}");
    }
    sb.Append("]");

    Debug.Log($"Audio {filename}: Every 1000 samples (tot 100 samples) CH1: {sb}");
}

Switching between art styles doesn't work well because the sprites have different aspect ratio.

For instance if I start the game with ryukishi sprites like this:

and then switch to PS3 sprites it turns out like this:

Similarily if I start with PS3 sprites then OG sprites are way too large.

(Possibly some other useful flags we added as well.)

We had a reported issue where after a user updated from the old DLL to the new DLL and used OG mode, this specific sprite became transparent when displayed (and stretched the first time). Other characters/sprites displayed OK.:

I told the user to save, close the game, and reload the game, which seems to have fixed it:

Here is the user's save files:
higurashi02(1).zip

I did notice this kind of issue while I was developing OG mode/the experimental DLL, but it usually only happened when you switched into OG mode. I think the issue didn't persist through a restart.

This is one of those "I hope it's nothing but I'm recording it just in case it comes up again" type issues.

tips.json apparently doesn't work for mid-chapter tips menu.

Right now the F10 key to show the mod flags only works in some places but doesn't work on main menu, config screen etc. Would it be possible to fix it so that it works everywhere? In some cases people can get stuck with this overlay on without an ability to hide it.

If someone exits the game with the F10 menu on, it will still be there when they next launch the game, before they even load their save. This is especially rough because the keybinding to handle it is only included in StateNormal once they get in game. The logic for the menu displaying is pivoted on the global flag GFlagMonitor.

2 good ways to solve this:

• In every game's init.txt set GFlagMonitor = 0, or
• Since this shouldn't really persist anyway, make it a local flag

Optional additonal step in the second case:
Rename GFlagMonitor to LFlagMonitor, per the naming convention.

Optional additional step in either case:
Let the f10 menu work in game before you load a save

So, while doing a sprite lockdown to PS3 for the console arcs (07th-mod/higurashi-console-arcs#39) I found a reliable way to safely initialize the art style, so per @DoctorDiablo 's suggestion we can actually integrate this into the main arcs. The issue is that there are separate states in the game code and in the scripts that need to be kept in sync, so setting the art style flag in the scripts never cut it (or might even be dangerous).

EDIT: the below explanation turned out to be slightly wrong, so it is not totally pertinent now.

The game on launch will load global flags from global.dat, or - in the case of a first-time launch - initialize globals with defaults. In either case, right after doing that, the game syncs in internal state with those flags, including that art style. So it turns out we can just change the value in this line

But the catch comes because this flag - unlike many others that we've added - already exists in the vanilla game. This mechanism only works if it's the first time the user has installed and they never ran the vanilla game before the mod, which is probably a toss-up. An alternative would be to insert a hook around here based on some global flag that detects that it's the first time initializing the mod. We could introduce something new for this, but there's a good chance we can use GMOD_SETTING_LOADER, which determines the first-time initialization in init.txt. When these variables are initialized, the init script should not yet have executed, so we can branch that off of detecting that flag = 0. Maybe also worth incorporating that change in the referenced line above for consistency, but it should prove redundant.

The flag was removed in 9fece20 but is still used here causing this error:

Exception: Unable to get flag with the name LArc, flag not found.
  at Assets.Scripts.Core.Buriko.BurikoMemory.GetFlag (System.String flagname) [0x00000] in <filename unknown>:0 

  at MOD.Scripts.UI.Tips.MODTipsController.get_Tips () [0x00000] in <filename unknown>:0 

  at Assets.Scripts.UI.Extra.ExtraButton.Awake () [0x00000] in <filename unknown>:0 
UnityEngine.Object:Internal_CloneSingle(Object)
UnityEngine.Object:Instantiate(GameObject)
Assets.Scripts.Core.State.StateExtraScreen:.ctor()
Assets.Scripts.Core.Buriko.BurikoScriptFile:OperationViewExtras()
Assets.Scripts.Core.Buriko.BurikoScriptFile:ExecuteOperation(BurikoOperations)
Assets.Scripts.Core.Buriko.BurikoScriptFile:CommandOperation()
Assets.Scripts.Core.Buriko.BurikoScriptFile:Next()
Assets.Scripts.Core.Buriko.BurikoScriptSystem:Advance()
Assets.Scripts.Core.GameSystem:Update()
 

This is a long-standing bug that we've been aware of ever since Tsumihoroboshi was released last year - however, I have had nearly no success replicating the bug but I have some ideas now and I figured it's good to document this as well.

The bug: Sprites will stick to the screen, even persisting through a quit to the main menu. Someone has to reload the game and - possibly, not sure - use chapter jump instead of reloading their save to get around the issue. According to one user's report too, when attempting to switch sprite sets after this, that gets broken too, like characters get swapped.
Arcs affected: At least Meakashi and onward
conditions: not well known, but people report clicking through the text fast, some even using CTRL to skip.

I was able to replicate this once. One characters stuck to the screen, but the game uses 2 different scenes to facilitate screen transitions; the sprite would get stuck to only one scene. Haven't been able to replicate since then. I disabled some checks in the lipsync code for whether the animation was still active and was able to reproduce this behavior much more easily.

There is a known possible race condition in the lipsync implementation where at the point when an animation is in progress but the user clicks forward in the text, the game state is updated to cancel that animation, but the code will still try to return that character's expression to their mouth closed if it's currently open. The lipsync code is running on a coroutine and the race condition is that the game can continue executing other code once the user clicks forward in the text. But if this is indeed a lipsync related problem, then it's surprising we have never had any reports about this issue in the question arcs. Further clouding the issue is that almost all our players use lipsync, which might be signaling us in the wrong direction, but the fact that disabling other lipsync-related guards allowed me to more freely reproduce the issue makes it pretty likely.

Theory: The scene transitions may be critical here. If a character has some spoken line, and the player cuts it off early, and the next line in the script is to transition the background, then it may cause the closed-mouth sprite to be drawn onto the other scene.

Possible solution: Whether that's correct or not, a great step would be to eliminate that race condition. However, the game engine seems to have only fixed-length-of-time wait objects with different labels. We can add a WaitForLipsync wait type, and set the wait time to be the same as the corresponding voice time, possibly with a safety buffer, but that still isn't very clean. We may be able to instead add a more general WaitForCoroutine wait type, which will only clear when that coroutine actually terminates.

Still unclear on why this only seems to happen in Kai, though there were plenty of changes going into Meakashi, so it's not entirely surprising.

Sometimes the UI mod gets broken after a new release from MG. It would be nice if we could detect this based on the unify version of the game and the UI file - the game does have both of these numbers because they can be found in the log file after such error.

When we detect different unity version we should instead load the vanilla UI which was renamed to .backup when installing the mod. Also we should print some message to the screen or into a popup to let the user know what happened and that they should report the issue to us on GitHub or Discord.

Currently the graphics options in the mod menu (added by me) is pretty confusing/hard to use (the "presets" are reasonable, but the "advanced options" are very confusing).

@fallenguru has suggested the following:

Re. UI suggestions for the new settings ...

• move the reset buttons to some sort of developer/debugging "don't touch unless instructed" area
• have sane presets, e.g. MangaGamer, Console, Original, [whatever else makes sense] [done]
• have switching presets switch all the individual options below, think of advanced graphics settings in AAA 3D games: text: NVL|ADV; sprites: MG, Console, R07; BGs: Console, Original; Audio: MG, Original; Censorship level, ... [no "default" buttons, the default for a preset gets selected/highlighted when you switch to that preset; no linked options, like "art style" switching both sprites and BG, either]
• if the user changes any of these individual options, the preset indicator switches to "custom", in effect an extra preset
• have a hotkey that cycles between the presets [done], including the "custom" one. That way, if I want to check out how a particular scene looked/sounded like in the different versions, I can quickly cycle through them, and get back to my usual settings as well

It's just an idea, but considering it'd make the F10 screen more similar to the advanced graphics setup screens people already know, I think it might work.

Also - reminder to myself to first do a mock-up of how it would look like, then get someone to have a look at it to see it seems reasonable.

Task List:

• move the reset buttons to some sort of developer/debugging "don't touch unless instructed" area
  • moved to troubleshooting page, and also added a warning on that page
• have sane presets, e.g. MangaGamer, Console, Original, [whatever else makes sense]
• have switching presets switch all the individual options below, think of advanced graphics settings in AAA 3D games: text: NVL|ADV; sprites: MG, Console, R07; BGs: Console, Original; Audio: MG, Original; Censorship level, ... [no "default" buttons, the default for a preset gets selected/highlighted when you switch to that preset; no linked options, like "art style" switching both sprites and BG, either]
• if the user changes any of these individual options, the preset indicator switches to "custom", in effect an extra preset
• have a hotkey that cycles between the presets [done], including the "custom" one. That way, if I want to check out how a particular scene looked/sounded like in the different versions, I can quickly cycle through them, and get back to my usual settings as well
  • This one is difficult, because we directly use the global flags throughout the code for our settings. I think this is doable if all graphics references to flags were replaced with a in-between, which switches between the graphics presets vs actually using the saved flags. I'm not sure if it's worth implementing this considering the effort though, I'll try this one last.
  • If implemented just for the session (eg forget custom settings if custom settings not selected when you close the game), it is reasonably easy to implement though.
• In the mod menu description for Italo's OST remake, state that it doesn't come installed with the mod by default, and that you need to install it via the installer or manually.
• Add different tabs for each set of options (eg Gameplay, Graphics, Audio, Troubleshooting)
• Organize lip sync into a proper section (currently it's kinda on its own)

Our mod has always had these 1-2 pixel borders on the left and right hand sides of the screen. Normally it's hard to see because it's black, but in certain cases, like a black image which is meant to cover a CG, it can result in the CG showing where the borders would be. Users usually report this happening on Onikakushi as it's the first time they see the graphical glitch.

The unmodded game does not have this issue.

@TellowKrinkle suggested it was a rounding issue, I'll look into that first when I (eventually) have a look at the issue:

Probably a rounding issue somewhere
I bet we (int) things, and with floating point error it might go over or under the target, causing - 1 pixel vs not - 1 pixel
Try setting the aspect ratio to 0.65251 or something and see if that fixes it

modded:

unmodded:

This would be a nice feature, as long as it doesn't cause too many problems. Even just being able to type in the resolution you want would be great. Making the window resizable would also help, but I googled this and not sure if there is an easy way to change this in the .DLL (it's normally a tickbox in the Unity editor).

We recently had the report below, which prompted me to think about this. I think what they said is technically not true - for all chapters we now have the 1280x720 button as the minimum settable resolution, but if you have never clicked on that button, your resolution will actually be 854x480 (16:9 version of 640x480) as you've inherited it from the base game.

The problem: The application window is too big, only for Arcs 1, 2, and 6. I get that the "standard" resolution shown is 1280 x 720 (my screen is 1280 x 800), but it gets covered by the dock, and the other arcs don't have this issue (smaller window size)

Reproduction Instructions: Launch the game

The game: Higurashi Ch.1, Ch.2, and Ch.6

The mod variant: Full

I bought the game at: GOG

My operating system is: macOS 10.11.6

I installed the base game: Last Week

I installed the mod: Using the Installer

Mod Download and Install Date: Downloaded and installed yesterday

State anything "special" about your computer's setup: It's pretty old; a 2008 MacBook

What you have already done to fix the problem: Tried re-installing the mod for all three of these arcs, but the large window size persists

MOD-INSTALLER-LOG-2020-11-01_08-19-25.zip

One issue we get is that users load saves from the unmodded game, which don't work on the modded game.

If there is some way to differentiate between modded and unmodded saves, we could show a warning before the user loads the save that the save won't work properly.

Even if the save has no identifying information, if the save's date modified is older than the mod's install version tracking file's creation date (installedVersionData.json), then it's probably an old save.

We don't need to worry about the save file repeatedly having the warning pop-up, as users will either create a new save, or overwrite their old one, which should cause the date modified to become newer and no longer cause the warning (assuming their save loads correctly).

I realize that we have a warning in the installer about old saves, this issue still happens from time to time. Would be better to prevent it from happening altogether.

Using the master DLL for Oni I put this tips.json into C:\Program Files (x86)\Steam\steamapps\common\Higurashi When They Cry\HigurashiEp01_Data.

It doesn't work:

By the way the json is not valid - according to specs json should only have string keys, not int. I made it as int because it's how it's done in console arcs tips.json.

Also someone please explain to me what these numbers mean and what numbers I'm supposed to use in the main chapters.

Recently a user reported that when they start the game using a GNOME desktop (default for Ubuntu), they would get a window with infinite height, and the game wouldn't startup (black screen)

Working configurations:

• XFCE
• bspwm (on Artix linux)
• Ubuntu 20.04 (I assume GNOME)

Not working configurations:

• Ubuntu 19.10; GNOME 3.34.x, x in [0..3], depending on component; proprietary nVidia drivers version 440; Steam beta.
• Ubuntu 18.04 (I assume GNOME)

I only tested Ubuntu using XFCE because GNOME had the same problem reported where the window would be infinitely tall and the game wouldn't startup.

The big problem with the GNOME problem is that it will remain, even if you uninstall the game, presumably because the messed up config file is in your ~.config/unity/... folder which never gets cleared unless you go and delete it

So even if the end user re-installs the un-modded game, it will still be stuck like that on GNOME. This may make it seem like it's not our mod causing the issue, when (I'm....pretty sure?) it is (see end of the discussion on discord below).

GNOME is the default desktop environment for Ubuntu, which I assume will make up many of our linux users.

I'm raising this in the higurashi-patch-compiler section because afaik the writing to the config file is done in the modified .dll. But the actual 'solution' could be just a fix in the installer, the .dll might not need to be modified.

Here was the discussion on discord (names omitted and edit for clarity):

----------------------------
Never had mono throw issue with my previous errors
BTW did you read how I got higurashi working nativly on gnome?
----------------------------
Install xfce?
----------------------------
You had to force it in fullscreen iirc
----------------------------
Launch the game in full screen mode
and mark the config read only
----------------------------
because after the game quits it sets the screenmanager to be windowed again.
----------------------------
That is strange, there's a fullscreen option in the settings
----------------------------
there's 2
<unity_prefs version_major="1" version_minor="1">
1
768
1365
0
1080
1920
768
1
1365
</unity_prefs>
screenmanager gets set to 0 after reboot causes the game to first start in window and then swaps to full
however as you progress to later chapters that also becomes a problem
----------------------------
I think the game has issue with gtk 3 in windowed mode
----------------------------
One of these is a Unity setting (the screenmanager thing), the other one is something MG added but what the hell for?
:thonk:
----------------------------
the height of the window always goes infinite beyond chapter 3
I've seen the config height being set to negative numbers or really high numbers
If I swap to windowed mode right now the game would crash my gnome-shell
oh and the same happens in openbox
that's another desktop
----------------------------
Not just that
if you use proton
the same thing happens
----------------------------
One would assume that this would be the testing configruation, especially since Steam only officially supports Ubuntu
----------------------------
As you know I have used both.

Then later by @TellowKrinkle :
----------------------------
Ugh the reason the full screen works like that was to work around a separate issue involving the game not choosing the right aspect ratio if it started in full screen on my Linux boot
So I made it so the game modifies the unity config on exit so it starts not full screen, then fullscreens itself once the game starts.

Matsuribayashi updated recently. Italo reported "changes seem to be in the assembly dll, globalgamemanagers and resources.assets"

We should check what changes were made to the DLL in this update, following the instructions here: https://github.com/07th-mod/higurashi-assembly#decompilation

Here's the Steam Assembly-CSharp DLL

Aside from CG and CGAlt directories there will also be an OG directory. The key that swaps between graphics should cycle between all three modes now (if the OG directory exists - it won't for console arcs). Also this directory should behave the same as CG as in there will be no fallback if a file does not exist in OG. Some characters won't have sprites in the OG directory, we need to make sure that the drawing functions will simply do nothing and not crash the game in such case.

I think that was a bug we fixed at some point, but it's back apparently.
Textbox opacity is forcefully synced to message speed in settings, which means changing message speed will change textbox opacity as well.
Changing the opacity setting doesn't work since it's the message speed that matters.

The current game resolutions available through the config screen are quite small considering we're using HD graphics. In my opinion we should change the options available there to some bigger sizes. Italo suggested these (I agree):

• 1280x720
• 1920x1080
• 2560x1440

I can change the UI text easily when the DLLs are updated.

Disclaimer: I haven't tested this on the stock game, so it could be some other of my changes which causes this to happen. Also, it's not possible? for this to happen on the base game, but it is more of a "annoying for developers" thing.

Currently, before we switch window filters (the background for the textbox), we call ReleaseTextures(); just before it:

When testing my own code, I found that if you call this twice with "windo_filter" as the image, it can result in this happening.

It only happens with "windo_filter" in particular, because there is a hardcoded cache for that particular image in:

However, if you remove the ReleaseTextures();, then the problem goes away.

I'm guessing that if you call releaseTextures on windo_filter, it doesn't invalidate (it doesn't set windo_filter to null), and when the game tries to use that texture, it ends up using some random texture instead.

I could either fix this by disabling the caching (currently you're not caching the ADV/NVLADV textures), or adding an extra condition check which disables the cache. Edit: If I just use a third type and switch ADV->NVL->OG->ADV... then the problem goes away so I guess it's not really an issue for now.

I don't think this is related to #45 even though it looks similar, because the sprite appears slightly transparent (it draws it with the window opacity).

I decided to make just one issue listing all issues with the OG artset mode, so I can see them all in one place. Here are the current issues I need to chase up:

TODO

• Add og sprites/backgrounds to hou plus (perhaps try the method below?)
• Consider porting background/sprites directly from OG scripts?

From a user on discord.

recently I replayed Onikakushi unmodded on steam and for example keichi eating mochi happens not in the kitchen, but in his living room which is huge. You get a completely different feel and mood for the situation. You feel how big the keichi mansion is and how unsettling it is to be there alone. You also afterwards in the GOU anime recognise that same living room from the og.
locations that I didnt understand why are there in GOU appeared in unmodded steam version
And were beautiful to look at
having 3 different angles of keichi's room feels even more as if you're in his shoes. Its incredible
Basically significantly more immersive if there are more og backgrounds

• Complete hou sprite update, which should also fix the eye cut-in issue: 07th-mod/higurashi-rei#14

Known Issues

• 07th-mod/matsuribayashi#46
• 07th-mod/minagoroshi#38
• 07th-mod/higurashi-rei#10
• 07th-mod/watanagashi#114
• When the "negative/color inversion" effect is applied, the black letterboxing to make it 4:3 turns white
• Tips/Preview thumbnails use the new console art instead of the old/ryukishi art (I think they're baked into the sharedassets0.assets file)
• Offset choice buttons, see #65 (comment)
  • A fix for this has been created, but not yet merged into mod branch, see 31996c0
• Transparent/stretched sprite issue [Spoiler] [Experimental DLL + OG Mode ] [low prirority] (this issue was only ever reported once)
• Unnecessary file accesses when OG mode is enabled
• Switching from console to original when zoom effect is active may cause issues - note: this might be fixed on the latest DLL, since a bug on Matsuribayashi was fixed on the latest DLL which happens when you change to OG mode.

Chapter specific issues:

• Tsumihoroboshi issues Fixed
• Meakashi issues Fixed
• Wrong title image for Minagoroshi/Matsuribayashi
• Stretched mangagamer logo in some chapters

General Notes / Oddities with OG mode

• sprites and backgrounds may not always match the OG game / voice only patch. You probably want the voice-only patch if you want it to match exactly
• To avoid having to remake all the text assets, any text assets (images which are just text on black background) which are in 16:9 will remain 16:9, even in 4:3 mode

If there are too many hotkeys, at least consider adding a button on the F10 UI

if you guys are going to mess with the dll, please try creating a hotkey for enabling and disabling the OP videos
lots of people seem to disable it and want it back again, there's no way to enable it without resetting your settings

edit: implemented, will be committed soon

Currently, the Higurashi mod does not force the Steam version of the game to run through Steam, effectively breaking integration with Steam if the game is not ran from inside the Steam UI. We have a way in the installer to check whether the game is the Steam version or not. This code should be either ported to C# and added as a conditional check to the Steam API calls, or the installer should assist the game with Steam detection (e.g. by creating a file that informs the game whether or not this is the Steam version of the game).

The vanilla version of Minagoroshi comes with a nice new feature of showing the scripts compilation progress on startup instead od just a blackscreen like the previous chapters.

Try to backport that into the previous chapters.

@IdealPersona @TellowKrinkle @voodoochiledev

Add some feedback so users know if they've accidentally changed an option. A toast-style notification (eg if you press P, it might say something like "Sprites: OG" for a couple seconds, then disappear).

It would be nice if toggles had some kind of onscreen notification. People have accidentally clicked buttons and gotten confused before

edit: implemented, will be committed soon

Memory is used up each time you change graphics presets (via menu or hotkey), which is only freed once you click to advance to the next line. Therefore, you can exhaust your memory if you repeatedly change presets without advancing to the next line, which crashes the game. You can observe the memory usage go up in Task Manager.

Effectively, if you repeatedly press 'P', you'll hard crash the game.

It's quite hard to do this in most cases since you need to press the key a whole bunch of times to exhaust your memory, and the moment that you advance to the next line, all the memory is cleaned up.

I would imagine the solution is to just force a cleanup each time the artset changes.

We could also just not fix it since it's relatively hard to create this crash, and if you never touch the settings then it should never happen.

cc @TellowKrinkle
cc @orian34 in case you have found any related issues.

A number of modded features were designed without individual game save files in mind. For example, I created a little mod for myself recently to play back the most recent voice, storing it in memory, but after a quick load the last voice isn't remembered. We had to add state for lip sync and sprite switching etc. but I don't believe any of it is persisted besides the flags, so there may be unexpected behavior when someone boots up the game again and loads a save file in the middle of a scene. I have a feeling this is related to the issue of people seeing double sprites. Let's investigate this.

(Btw, global flags are persisted automatically without respect to save files, so that's separate.)

In Hima and newer chapters the value is retrieved with LoadValueFromLocalWork(SelectResult), for example here.

In Oni it causes this error in the log:

Exception: &opening.mg (5): ReadVariable: Operation LoadValueFromLocalWork Parameter 1 could not be read. Generated exception: System.Exception: Unable to get flag with the name SelectResult, flag not found.

It seems you need to add a flag called SelectResult or something. Also make sure the Select value is actually stored there.

The resolution options were changed in #37. However, the game's default resolution after the mod install no longer matches any of the resolutions in that list. The default resolution should now be 1280x720, to match the change.

MG changed stuff with tips in minagoroshi causing some things to be changed on our end, but it popped up an edge case that was pretty ugly. We fixed the edge case on minagoroshi (7ceaa8b), but it would be good to reconcile a single tips data implementation to all arcs, which this refactored implementation should be able to cover.

The buttons don't actually let you save. It doesn't make sense to let them save, either (that's what the normal save slots are for, if you already made it to this screen). The save buttons should be removed and phrasing should be changed to "Load quick save file XX" or something similar.

To my understanding, the game engine does not preload textures or audio. This means that every time a sprite is displayed, or a sound is played, the file is loaded from disk.

This is hidden in some cases, as:

• I think the OS provides some caching of file accesses anyway
• the loading is done on a different thread so you don't directly see the fps drop, but if you're on a HDD which hasn't yet spun up (or is taking a while), the game will definitely freeze until it's loaded the sprites/audio needed to continue.

In the past, someone's added some debug logging which records how long it takes to load audio files and images. You can enable this logging by showing the flag menu by pressing SHIFT-F10 (which toggles LFlagMonitor), then checking the output_log.txt. I think the game loads the audio on a different thread from the sprites, so the total time is not the sum, but the max of the texture load time and the audio load time.

The worst case is when lipsync is enabled, as it has to load 3 sprites, one for each mouth position, plus the voice file to be played. Here is an example from the log (cleaned up):

Loaded portrait/rim_komaru_0 in 102ms
Applied filter to portrait/rim_komaru_0 in 36ms
Loaded portrait/rim_komaru_1 in 103ms
Applied filter to portrait/rim_komaru_1 in 39ms
Loaded portrait/rim_komaru_2 in 105ms
Applied filter to portrait/rim_komaru_2 in 37ms
Loaded audio ps3/s05/27/100500036.ogg in 468 ms

EDIT: due to some changes I made to the DLL, I think the last .ogg file timing wouldn't have been correct - it would have been the sum of loading all the lipsync textures + the voice file. I've just crossed it out for now

(the filter is not a disk access - we apply tints and other effects at runtime to avoid needing to pre-generate all combinations of sprite + filter)

It would take at least 468ms before the game can begin to play the audio/do lipsync. I think the game doesn't begin displaying text (like animate the text being drawn across the screen) until the audio is loaded (but I'm not sure). I'm not sure why the .ogg file takes so long to load in this case.

While the issue isn't that bad for most users, even on a HDD, but having the game hitch randomly is quite annoying. Other programs running or Windows Update could also cause the game to lag, if they were using all the disk I/O.

If you're on an SSD, I don't think this would be an issue for most users.

In terms of user feedback, we occasionally get reports of this, but it's rare all things considered (I would expect to get more reports than we do).

I probably won't actually do it, but preloading textures/audio before reaching them would fix the issue. You would need to pre-parse the scripts, check for any file paths, and load them in advance to do this.

We already tell users to install the game on an SSD instead of a HDD if possible on our FAQ.

Edit: I've been playing some other games installed on my computer's HDD, and they also hitch when playing. I was under the impression that most games preload to hide these sorts of problems, but perhaps it's not as common as I thought.

We received a report on Discord from cureClover that video opening did not play properly in Onikakushi. Audio was playing but the screen was black.

OS: Win 10
Platform: GOG
Patch was installed using installer.
output_log: https://cdn.discordapp.com/attachments/392489108875771906/563069098326753303/output_log.txt

I tried to look for something relevant in the log file and the only thing I found was this:

[AVProVideo] Using playback path: MF-MediaEngine-Hardware ([email protected])

Any ideas what could be the problem? If not can we log more information about the method used to play the video to determine possible causes?

Platform: Windows 10 x64
Using 2 monitors, main one is WQHD (that's where Higurashi opens) the other is FullHD.

Orian had the same problem, I think he is on windows too but I'm not sure about his monitors.

@TellowKrinkle I'm guessing you broke it somehow when trying to fix the other resolution-related bugs.

There are discrepancies between arcs causing an offset for the choice selection.
Here are samples:

• Oni
  
• Hima
  
• Mina
  

Goal is to uniformize them