Config problems

[Nightshade-tools]

So I finally found out how to do the configs (after a lot of research) finding the keys in en_us.json language file of Minecraft.

My problem is that the mod doesn't seem to accept both a list of disabledPrefixes and a list of enabledPrefixes. But even when I go with only one of these lists, it appears that the filtering is still broken. For example: If I have a list of enabledPrefixes, I still get "narrator.position.screen" playing all the time - which you can hear from navigating the menus.

{
"chatEnabled": true,

"disabledPrefixes": [
"advancements.",
"commands.",
"debug.",
"effect.minecraft.",
"gui.narrate.",
"narration.button.usage.",
"narration.checkbox.usage.",
"narration.component_list.usage",
"narration.cycle_button.usage.",
"narrator.button.",
"narrator.screen.usage",
"narrator.loading",
"narrator.position.",
"narrator.screen.title",
"narrator.screen.usage",
"subtitles."
],

"enabledPrefixes": [
"addServer",
"attribute.name",
"biome.minecraft.",
"block.",
"book.",
"container.",
"createWorld.",
"menu.",
"options.",
"selectWorld.",
"sleep."
],

"enabledRegularExpressions": []
}

[Nightshade-tools]

Here is an even more basic test of the config:

{
"enabledPrefixes": [
"menu.",
"narrator.screen."
]
}

[casewalker]

Thanks for pointing this out! It looks like this is probably a real bug, I'll try to take a look at it in a few days.

[Nightshade-tools]

Thank you.
I don't know why this would happen but I noticed that JSON parsing errors are not narrated. If there is a problem - trailing comma where none should be fir instance - a silent error occurs: Narrator says config was reloaded but data was not actually retrieved.

Initially I thought it was some if-else logic failing - that you couldn't have both enabledPrefix and disabledPrefix but then case 2 posted above showed that is not the case. It must be that all narration gets silenced on some error.

Thanks for taking a look at this. I am trying to learn a foreign language by using the narrator and the built-in system narrator is simply too verbose and nonsensical.

[casewalker]

I think I see the problem.

When I first started this mod, I believe for every call to narrate, the text came directly from a single translation in some language file. Now, it looks like multiple translations can get chained together while calling narrate:

...
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: Stacktrace: net.minecraft.client.util.NarratorManager.narrate(NarratorManager.java)
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: Stacktrace: net.minecraft.client.gui.screen.Screen.narrateScreen(Screen.java:568)
...
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: text: Title Screen. Use mouse cursor or Tab button to select element
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: is it accepted? false
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: is it empty? false
[12:26:11] [Render thread/INFO] (Minecraft) [STDOUT]: is narrator active? true

Here, the text sent to narrate is "Title Screen. Use mouse cursor or Tab button to select element". Instead of seeing only one translation at a time, narrate is being called with a combination of two translations:

• "narrator.screen.title": "Title Screen", and
• "narrator.screen.usage": "Use mouse cursor or Tab button to select element",

So the way that I originally designed this mod, to match the exact text sent to the narrator, will no longer work.

One approach to try to fix it could be to check whether the text begins with an accepted narration, so perhaps "Title Screen..." followed by anything else would be accepted (if narrator.screen.title was an enabled prefix). This approach could get a lot of narration working again, but it is far from perfect:

1. It is possible that the "begins with" match might match other narrations which it was not supposed to match
2. Text that is embedded in a longer sentence which does not begin with an enabled prefix would not be narrated

And there could be more issues still. But I think this is the best approach I can think of for now, so I will try to work on that.

---

Also, thank you for pointing out that it was hard to figure out what prefixes existed and where to find them, I will add the en_us.json file to my mod and reference it in the README.

As well, I would like to clarify that "enabledPrefixes" and "disabledPrefixes" are designed to be configurable at the same time. The thought I had was, for example, if I wanted to enable all menu. prefixes except for one or two, maybe menu.singleplayer and menu.multiplayer, it is smaller and better to enable only menu. while also disabling menu.singleplayer and menu.multiplayer rather than having to list out and enable all 25 other menu.[...] prefixes.

But you do also make a point that an illegal configuration file should probably result in the narrator saying something about it, so I will also look into that.

[casewalker]

Please check if this is fixed for you in the newest release file:
https://www.curseforge.com/minecraft/mc-mods/narrator-configs-mod/files/4014290

[Nightshade-tools]

Hello,

I tried the latest build using the below two config files to compare things. In the first case, hovering menu buttons does not trigger the narrator. However in the second case, it does.

{
"chatEnabled": true,

"enabledPrefixes": [
"death.",
"sleep."
],

"enabledRegularExpressions": [
"^\d+, \d+, \d+$"
]
}

SECOND CONFIG BELOW ### DONT COPY THIS LINE

{
"chatEnabled": true,

"enabledPrefixes": [
"attribute.",
"biome.minecraft.",
"block.",
"book.",
"death.",
"sleep."
],

"enabledRegularExpressions": [
"^\d+, \d+, \d+$"
]
}

[Nightshade-tools]

Thank you for trying things out and explaining what goes on behind the scenes. I don't know Java myself (but I'm a seasoned Python developer).

From what you describe I think I see the problem and/or why I get confused.
I have made these assumption and observations trying to work with this mod:

The language files (example: en_us.json) is a JSON-formatted file in the style of CSV. The data structure looks like a map/dictionary with key/value pairs where the first string is the key and the second is the value.

Adding something like "advancements." to the "enabledPrefixes" lead me to believe that:
"All keys that start with that string - advancements. - will be filtered when the mod is doing a lookup for the narration".

Now in your last comment it appears to me that you are instead filtering things by value and not by key. If this is a mistake or a limitation in Minecraft and mods in general, I can't tell - you have more insight into that than I do.
However, as one dev to another I would say that this logic is prone to many errors: Keys in a map/dict are unique while Values are not. All sorts of problems may rise from trying to filter data by looking at the values instead of the keys.

There is another problem here and that is localization:
The main reason I found this mod and wanted to try and make it work is because I want to be able to play Minecraft in order to learn a new language. A user can install a foreign narrator in their OS - like say, Chinese (Mandarin) and then toggle on Chinese subtitles. Then using mods like this to filter away garbage narration, the player can hear Chinese while playing.

If it is possible to refactor the code so that the configs work on Keys rather than Values than the above would be possible. The language files still use english for the Keys, so if the logic in the code filter using that instead of Values then the user could set any language and play using that - narration would work regardless.

[casewalker]

Thank you for your thoughts and input.

When I started this mod, I had the same idea - it should theoretically be easy to just match the text-keys and then control what gets narrated with high precision and accuracy. I then discovered that the Narrator inside of Minecraft only receives strings, all other information (keys included) is gone by the time the Narrator is called. When I realized this, I switched my approach and started converting the text-values into regular expressions, and then live-checking all text received in the Narrator.

This completely agree that this approach is sub-optimal in a lot of ways, but it has the advantage of only needing to modify one place inside of the Minecraft code rather than having to override behavior in a variety of different places, hot-swapping a lot more game-code and having to review and update more code on each release. This was also my first time looking into writing Minecraft mods, so I wanted to make sure I kept a small-footprint and had something decent enough that worked.

Now that I am more familiar and comfortable with modding, I could try to see about the larger-footprint approach, trying to go to where the keys still exist in the calling-code and then writing my filtering logic there, but that would take a significant rewrite and is not feasible in the short term. I would like this mod to be as useful as possible though, so I will definitely be thinking about trying that approach soon.

[Nightshade-tools]

Alright, I understand.
I believe that such a refactor would make the mod much more usable. Maybe you could team up with shoaib_k on Accessability Plus Extended? This kind of narration filter could potentially be very powerful (and helpful) for both people with disabilities and people looking to just learn a new language such as myself. As far as I can tell this functionality does not exist in that mod at all.

The vision I had before I started looking around at mods was to have subtitles and narration in a foreign language - but filter away useless stuff like "Press Left click or Tab button to chose element". I also envisioned narration of the inventory, hot bar, etc so that when you select your sword/pickaxe on key X, the narrator would speak out this word in the foregn language (and you see it spelled out as well). I think a lot of people would find it fun if they could play Minecraft AND learn a new language at the same time.