Please check any boxes that apply to you and your issue

• I use a translator application to post this issue.

• This is a crash. Please upload, Pastebin, Gist or copypaste the whole crash report along with this issue.

• This is a mod incompatibility. If I do this in vanilla Forge with only Et Futurum Requiem installed, it works normally.

Version number of Et-Futurum-Requiem (IMPORTANT)

2.4.6

Describe the issue (IMPORTANT)

The sound disappears of opening a door, gate, trapdoor, as well as the sound of a pressure wooden plate in the presence of EFR. Removing EFR restores all sounds.

Mod list (OPTIONAL)

Additional Context (OPTIONAL)

Хорошо, проблема, вероятно, связана с взломом Java 1.8.0_51 MCLib для SSL-сертификатов, я забыл об этом. Если другой мод подключается к Интернету до того, как это сделает MCLib, на Java 1.8.0_51 звуки AssetDirector перестанут воспроизводиться. Что произойдет, если вы запустите инстанс ТОЛЬКО с Et Futurum Requiem? Если это загружает звуки, добавление всех других модов обратно должно работать. В этом случае MCLib уже устранил проблему, и это исправление будет поставляться с EFR 2.5.0.

If I have only EFR installed, then the problem also remains. Also, installing versions 1.18 and 1.20.1 did not help

It could be the asset downloading thing not having had time to run, or the connection being blocked.

Please provide your logs, and a mod list.

A temporary solution you can try for the time being is download and install 1.20.1 to get the needed assets downloaded, but still do provide logs and a mod list so I can try to actually figure out what's going on.

Just so you know, I have the same Issue, because I cant let my launcher be online or else it will log me out of my nonexistent Microsoft Account. Why is there no fallback to the original sounds by copypasting the old sounds to their new locations, instead of effectively just deleting all sound by pointing at an empty directory?

My latest.log is full of things like:

[21:56:26] [Client thread/WARN]: Unable to play unknown soundEvent: minecraft_1.20:block.chest.close

And my FML Log contains this part:

[19:26:53] [Client thread/TRACE] [AssetDirector/]: Fetching assets of etfuturum
[19:26:53] [Client thread/TRACE] [AssetDirector/]: Downloading JSON at https://launchermeta.mojang.com/mc/game/version_manifest.json
[19:26:53] [Client thread/ERROR] [AssetDirector/]: Failed to download JSON at https://launchermeta.mojang.com/mc/game/version_manifest.json
[19:26:53] [Client thread/ERROR] [AssetDirector/]: Failed to fetch assets of etfuturum
[19:26:53] [Client thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:749]: java.net.ConnectException: Connection refused (Connection refused)
[19:26:53] [Client thread/INFO] [STDERR/]: [java.lang.Throwable$WrappedPrintStream:println:749]: at java.net.PlainSocketImpl.socketConnect(Native Method)

If you have already downloaded and installed 1.20 then EFR will use the assets already downloaded. It does not attempt to download them again unless you have a weird symlink like before.

It uses the assets in the default folder, it does not download them to a new location.

It should not matter if your launcher is offline, the game should still have access to the internet right?

Thing is the Assets and the Launcher Stuff are both on a mojang domain. ;)

And the Issue happened when i updated the selfcompiled EFR a few months ago. I can try to quickly change my pihole rules after launching MC to see if that fixed the downloading, but the Issue of there needing to be some sort of backup still persists. ;)

The only way to do a "backup" would be to going back to including assets in the jar iirc, which was absolutely unacceptable and I will not go back to doing that under any circumstances.

If the assets are on your computer, in the correct location, and somehow are not being used then you should create an issue in @makamys MCLib repository, as I have limited knowledge as to how AssetDirector actually works. If it happened after an update, something may have broken but AssetDirector is handled by MCLib. makamys appears to be taking a little hiatus at the moment hoever.

If you have some way of getting the launcher to download the assets, you should use it as a temporary stand-in to get the assets you need, unless that doesn't work for some reason. makamys appears to be taking a little hiatus at the moment hoever. The update could have also changed the base asset version (Around a few months ago I changed the asset version to 1.19.3, then again to 1.20 recently) so the game would need to fetch new .jsons for that version.

Again, the game SHOULD work without needing an internet connection if you have the assets; as I said, MCLib... should be checking the default locations, it does not download assets in a different location. It uses the same location as vanilla versions.

Anyway why would the domain matter? Are you blocking the domain or something?

I was not talking about including assets I meant "not erasing already existing vanilla assets", because things like "chest close" did exist in 1.7.10 and are silenced by EFR if the NEW assets dont exist. ;)

But yeah i messed around with unblocking mojang.com and minecraft.net after launching MC and it works now.

Just remember this other person who posted this Issue had the same problems I had, and it might be related to countrywide censorship instead of manually blocking domains, which is also a serious Issue.

Ah, I see. I don't remove the old sounds, it just fails to play the new ones, the old files do not get deleted. The game does not attempt to play the old sound. Somehow detecting if the asset download failed and turning off the config options relating to sounds would be a bit problematic. Then we have another issue... If the sounds are already there the game can use them even if the download would fail, so we'd need to check that too. It'd be an unnecessary and possibly fragile web of checks and it would create a silent failure; I would much rather find out why the failure occured and pursue a fix, if we add that kind of fallback I won't get the reports needed to do that. Well also many new sounds are not just blocks and items so some random features may be silenced too... Hm... Yeah this means I can't do a fallback even if I wanted to since some features would clearly be missing audio.

As for country censorship... Well, I can't really do anything about that... maybe people use patched launchers but they can't affect the mod. Perhaps I should add info to the logs suggesting the user download the version the assets are from to fix it, since then the assets would be fethed that way.

Makamys also added a way to change the domain using program args but I don't remember the specifics behind that.

That being said, I believe this can be closed because a fallback is not something I will add, and domain/fetching issues are on MCLib's end.

Пожалуйста, предоставьте ваши журналы и список модов.

Временное решение, которое вы можете попробовать на данный момент, это загрузить и установить 1.20.1, чтобы загрузить необходимые ресурсы, но все же предоставьте журналы и список модов, чтобы я мог попытаться выяснить, что происходит.

2023-07-24-2.log

Пожалуйста, предоставьте ваши журналы и список модов.

Временное решение, которое вы можете попробовать на данный момент, это загрузить и установить 1.20.1, чтобы загрузить необходимые ресурсы, но все же предоставьте журналы и список модов, чтобы я мог попытаться выяснить, что происходит.

Installing version 1.20.1 did not solve the problem

Я не говорил о включении активов, я имел в виду «не стирать уже существующие ванильные активы», потому что такие вещи, как «закрытие сундука», существовали в 1.7.10 и отключались EFR, если НОВЫЕ активы не существуют. ;)

Но да, я возился с разблокировкой mojang.com и minecraft.net после запуска MC, и теперь это работает.

Просто помните, что у этого другого человека, опубликовавшего эту проблему, были те же проблемы, что и у меня, и это могло быть связано с общенациональной цензурой, а не с ручной блокировкой доменов, что также является серьезной проблемой.

Can you tell us more, please, how you solved this problem?

Try Version 1.18 because that is the name of a folder in my versions directory that popped up because of et futurum, I guess @Roadhog360 forgot to rename things there. Lets hope I wont have to redownload it AGAIN when he decides to name it 1.20 XD

Try Version 1.18 because that is the name of a folder in my versions directory that popped up because of et futurum, I guess @Roadhog360 forgot to rename things there. Lets hope I wont have to redownload it AGAIN when he decides to name it 1.20 XD

I said 1.20, not 1.18. if you do 1.18 some stuff will be missing, you need 1.20. That's the version I am currently requesting assets from, what makes you think I forgot to rename something?

You said 1.20 BUT YOUR FOLDER IS NAMED 1.18!!! And this person did TRY 1.20 and it DIDN'T work

What do you mean "my folder"??? And if they tried 1.20 then MCLib is still failing in some other way, the issue should be moved

The folder that Et Futurum Requiem downloads the stuff to, because it DID create a 1.18 folder in my versions directory. There is nothing 1.20 in there at all.

As in there is a 1.18.json that it downloads. Which clearly isnt 1.20 or 1.20.1

That's probably from past downloads. Mojang did something a little wonky with the latest version names. The indexes is not named 1.20.json, it's named... 3.json... for some reason. The folder might be the same way

._.

There is no longer any requests for 1.18, it creating a folder of that name should not be possible, I changed the variable to request assets from 1.20, so on a fresh instance that's what it should request. I'm not requesting 1.18 assets so it's not creating that anymore

Well you must have done that after this Issue was created, because that 1.18 json file was downloaded VERY fresh, because my .minecraft folder corrupted in the inbetween time (launcher decided to attempt downloading some cpw files and the internet went out at THAT exact moment, corrupting the install...).

I have made no changes to asset downloading since this issue was created, in fact the last changes to asset downloading was several weeks ago, and I did not change the version requested from.

A big mistake I made after thinking, I believe 2.4.6 still does use 1.18, iirc. So in asset_director/assets/indexes, if 2.json is not present, as well as no 1.19.json, if it's only 1.18.json then I indeed have messed up suggesting I use 1.20 in the current release. Sorry about that. I... think the switch was made in a build after 2.4.6's release, hence our potential disconnect. Downloading the latest version has always worked but Mojang has twieaked the way this works slightly a few times (for example stopping to name the json files after the versions and naming them shit like 2, 3, 5) so maybe the user actually does need to get 1.18, to get the correct sound events from the sounds.json.

Now if makamys comes back he can correct me if I am wrong, but how MCLib works is that before downloading it checks the vanilla locations, and here's where I may have made a mistake in my previous suggestions to download 1.20. While the asset check would likely pass because all of the needed assets are in 1.20 and have the same hash, the issue... might have been the sounds.json. This actually makes sense now, if you download 1.20, since their sounds changed the sounds.json hash downloaded would be different from 1.18's. MCLib needs that file so it can know what sound events to create, since practically every version changes sounds in some way, even if the sounds themselves are the same, we need that sounds.json to get the sound events. This could be why 1.20 isn't working. If the game has working audio after installing 1.18 instead of 1.20 then that pretty much settles it. The game could be failing to find the 1.18 sounds.json (and it doesn't want the 1.20 sounds.json because it could be different and it doesn't know it's there because different hash anyways; it looks for the downloads based on their hashed name) and fails to find it, so then it attempts to fetch it from the internet which as we know above, is also failing.

So, I didn't remember the info I checked so I fact-checked by hopping on my PC really quick. MCAssetVer = "minecraft_1.20", but it seems 1.20 uses the same assets as 1.19.3 because in AD's folders the freshest json it downloads is 1.19.3.json. So even if you were using a beta build none of the downloaded assets would be called 1.20, they'd be called 2, or 1.19.3. But this is just thinking out lout because iirc 2.4.6 wants 1.18. Apologies for my ignorance on this subject Greg, it appears I did fuck up a little when analyzing this issue. While this is still possibly an MCLib issue I did forget a few huge details

As for the user, sorry for requesting you to download yet another vanilla version, but what happens when you attempt to install Minecraft 1.18 on your computer? New comment, idk wtf is going on any more If downloading 1.19.3 doesn't work I give up

Ok I just checked the previous versions to be sure and I've been using 1.19.3 assets 2.4.4... hm... if MCLib is only showing 1.18 this can be a huge problem. I could not have forgotten to rename the version assets because you can see the download requests in EtFuturum.java. These all use one variable from Reference.java, and it's the same variable, all through the code, so when I change it there it's changed everywhere. The asset fetching is automatic, I don't specify where the assets go, I just tell it to fetch something from a version and it does the rest for me.

So... why on Earth is it only downloading up to 1.18 for you, with no sign of 1.19.3 or 2.json? The last time Reference.java was changed in an update was 07ee77e which is 2.4.4... At this point I think only makamys is able to answer the rest of these questions. Welp

Попробуйте версию 1.18, потому что это имя папки в каталоге моих версий, которое появилось из-за et futurum, я думаю @Roadhog360забыл переименовать вещи там. Будем надеяться, что мне не придется перекачивать его СНОВА, когда он решит назвать его 1.20 XD

Unfortunately, installing 1.18.2 did not solve the problem. Maybe my launcher is to blame, in the settings of which there is a creation of separate folders for each version?

Not 1.18.2, i literally mean 1.18 there without the 2.

Not 1.18.2, i literally mean 1.18 there without the 2.

That didn't solve the problem either

Ok the issue is likely with MCLib's Java 1.8.0_51 hack for SSL certificates, I forgot about this. If another mod connects to the internet before MCLib does, on Java 1.8.0_51 then AssetDirector's sounds will fail.
What happens if you run an instance with ONLY Et Futurum Requiem? If that downloads sounds, adding all other mods back should work.
In that case, MCLib already fixed the issue and this fix will ship with EFR 2.5.0

Just tried to fight that issue myself, and I'm using MultiMC, so I guess it could be same issue with other third-party launchers.
For me it got fixed when I copied "assets" and "versions" from vanilla minecraft folder (after downloading 1.20 and 1.20.1 just in case) to my "MultiMC\assets\asset_director" folder. So if any of you who encounter the issue with missing sounds and use non-vanilla launcher - try to copy these folders to your launcher's preferences (it will show in the logs like that in my case under "Using directory")

[15:22:26] [Client thread/DEBUG] [AssetDirector/]: Couldn't read launcher_profiles.json. Assuming official launcher is not used.
[15:22:26] [Client thread/INFO] [AssetDirector/]: Using directory D:\Minecraft\MultiMC\assets\asset_director
[15:22:26] [Client thread/TRACE] [AssetDirector/]: Fetching assets of etfuturum
[15:22:26] [Client thread/TRACE] [AssetDirector/]: Downloading JSON at https://launchermeta.mojang.com/mc/game/version_manifest.json
[15:22:26] [Client thread/ERROR] [AssetDirector/]: Failed to download JSON at https://launchermeta.mojang.com/mc/game/version_manifest.json
[15:22:26] [Client thread/ERROR] [AssetDirector/]: Failed to fetch assets of etfuturum