HanFox

Nearly 5 years old. It’s going to be off to school soon. Brings a tear to your eye.

I changed it to an mcpack... it looks correct to me. Me having to mess around trying to make a working mcpack when a dev could just unpack it to the resource_packs folder seems like a bit of a silly point for this issue to die on though.

Sure. I've attached an mcaddon which has the extended color palettes which work on Java and a custom 128x Dune armour (which is the one you can see in the screenshots).

@v-magwar How did you test the problem? Baring in mind my comment below it's unlikely testing with BDcraft packs will currently cause issues, but the problem within the context I outlined may not be fixed.

You would need to check with a resourcepack that is "ordered" correctly in the manifest (i.e. left-most selection being something like 16x, while the right-most is 256x or so) then apply the pack to a Realm and then get a mobile client which doesn't have enough system memory to load 256x to connect and see if it crashes, or chooses the correct resolution like offline.

Just to add proper technical context it's not that the game is choosing the highest or lowest (64x isn't the lowest in BDcraft packs, that's 32x), Realms is choosing whatever is the right-most selection if you go to Options > Packs > select the relevant pack > Cick the Cog icon.

The reason BDcraft packs changed from choosing 256x by default on Realms to 64x is we changed the rightmost selection to be 64x. This was specifically done to workaround the issue where mobile clients were likely to crash when connecting to a Realm which had a BDcraft pack loaded due to the game defaulting to 256x instead.

In single player the game looks at a client's available RAM (system memory) and choose the relevant pack resolutions when comparing that to the list in the manifest.json of the pack. However, for some bewildering reason Realms doesn't check a client's capabilities, it only selects the last selection.

Someone posted a possible workaround on the BDcraft forum back on 3rd December in regards to the lag issues. I have no idea if this works (no one else has confirmed it, and I don't have a Nvidia GPU to test it with), so I'll post it here for people to try (at your own risk!). If it does work it may give Mojang some technical aspect to explore.

Below is the quoted post text:

— FIXED!!!!
— At least for the Windows 10 edition that I am playing (From the Windows Store)*** The problem is that the game executable that shows up in Nvidia Control Panel is NOT the executable that the game runs when you launch it, so custom settings are NEVER applied to your game.

— The first step is finding the actual .exe the game uses to run off of on your computer
— 1. Start the game, and then open task manager
— 2. Find the currently running minecraft exe, right click and select open containing folder
— 3. find the minecraft executable inside this folder (should be Minecraft.Windows.exe) and copy its file path location
— 4. Open nvidia control panel and click Add under program settings tab
— 5. Click browse, and then paste the file path you copied into the top input field
— 6. Select the Minecraft.Windows.exe that shows up in this folder

— Now you can get on with editing the settings for the ACTUAL executable that cause the FPS drop. I noticed that minecraft was NOT using my 3080 to actually do 3d rendering for the game, which tells me that the game is bottlenecking the CPU for some stupid reason. In order to offload to the GPU, I changed the following settings;
— 1. Cuda GPUs - All
— 2. ***Low Latency Mode - Ultra (This prevents frame queing on the CPU, which allows the GPU to process them faster)
— 3. OpenGL Rendering GPU - Select your actual graphics card
— 4. Power Management Mode - Prefer max performance
— 5. Preferred Refresh rate - highest available
— 6. Virtual Reality pre-rendered frames - 1

— I went from 5-15 fps inside my house, to over 240 fps instantly. Zero lag spikes, and zero fps drops. Cheers, and I hope this works for you.

This affects MC1.15.1pre1.

Oh, it wasn't meant to be an insult, it was meant to show general frustration at a change that was undocumented and how the bug was closed with a sweeping statement as if that's okay. I'm sorry that you found it offensive.

However, I feel my questions are still relevant to the bug and it's a shame you ignored them just to give me a slap on the wrist.

Is there an official justification for the change? It would be great to also know why the changes are important. There are a lot of content creators out there which changes like this effect and things being done without clear reason are a bit of a slap in the face for them. If this isn't the correct place to get these answered directly by devs where is, or is some sort of an announcement forthcoming (such as a future Snapshot post on minecraft.net)?

So, is there any technical justification for why this change was made?

Does it make general entity management in game easier for Mojang?

Currently we're all just seeing it as someone doing it because they had nothing better to do.

Affects MC1.14.2.

Whilst I find it too fiddly to unenroll from the beta (and actually get back on stable – it'd be nice if beta and stable could be seperate for resourcepack makers 😉) I can say it seems fixed in 1.12 beta.

Maybe I wasn't clear with my previous comment, so I'll try and offer a more detailed explanation.

There are 2 horse/donkey models in Minecraft Bedrock: horse and horse2

horse is the old style detailed models with mouths, and extra bits for legs. horse2 is the newer more blocky, less detailed models.

Resourcepacks such as PureBDcraft, amongst others, are using an older pack version which allows the old horse models to be used.

What appears to be happening is the game just isn't pulling in all the parts of those models during initial resource loading, so the level loads and resources load, but for whatever reason it's missed parts of the saddle and the ears (and other bits).

When you save out of the world, and then reload the world the resources then load correctly. No amount of reinstalling is going to help, it's an issue across multiple devices which is obviously baked in to the code. Likely a bug created when the newer horse2 models were introduced.

The fix here is not to just tell resourcepack makers to use the newer pack version, mainly because no guidance from the people who process the submitted packs to marketplace have stated it's necessary (I work on PureBDcraft, so I know personally).

If the game is to keep both models, this issue needs fixing. Otherwise the devs/people who process packs need to update their guidance with, quite possibly, a deadline for packs to update to the horse2.

This issue really needs to be pushed upstream to someone who can actually make a decision about the future of the old horse models instead of being left as obviously buggy code.

This issue is still present in the 1.8 betas tested with PureBDcraft on Xbox and Windows 10.

On initial world load horses/donkeys lack their ears and saddles when the texturepack is using the horse models (as opposed to the newer horse2 models).

Saving the world, and reloading it will cause the models to render correctly (i.e. the ears and saddles will appear correctly).

It's such a mess and it didn't get fixed before final. How disappointing.

No, it's not a duplicate of that bug. This bug is about model texture UV and that bug is about entity shadows.

Done. Simple 5 element compass model to show the issue.

EDIT: Tidied up the issue to not refer to a HD resourcepack to avoid confusion.

So 17w16a/b seems to have fixed the arms of the Illagers, but Villagers and Witches are still broken.

Example of the arm messed up in PureBD Evoker Illager attached for clarity (and hopefully to poke a dev to fix it >.< )

This is still a problem in 1.10.2.

Please re-open the report and slap a dev in to action 😛

Still an issue in 16w03a