Dark Prismarine slab shows as water even if it's not waterlogged

[Delvin4519]

A build with dark prismarine blocks and slabs shows as water in minutor even if there's no water visible or waterlog at the surface. Minutor seems to be rendering dark prismarine slabs as water for some unknown reason

[EtlamGit]

when looking into the Block definition file:

• prismarine_slab should be #699f8a
• dark_prismarine_slab should be #3f5ce4

so this is obviously wrong . . .

[EtlamGit]

#36604f would be the right color

[EtlamGit]

@Delvin4519 please force an definition update and report if it is fixed now.

[Delvin4519]

I can't seem to find a way to force a definition update. I've tried the settings option and clicking check for definition update, and reinstalling minutor and again trying to force a definition update in settings, but it still shows a block definition of 1.20 23w12a.

[JDHnz]

@Delvin4519 The definitions are downloaded to %appdata%\Local\seancode\Minutor (on the Windows version, at least). That folder can safely be deleted and Minutor will download a new version of the definitions the next time it starts up.

[Delvin4519]

I've done that now resetting/deleting the definitions folder location, and minutor is still re-downloading the old definitions file from 1.20 23w12a. So the fix doesn't show up yet.

[JDHnz]

Looking at the definitions source file, we can see that it is tagged with the version of 1.20.23w12a, which corresponds to the last Minecraft version where new blocks were added, so what you are seeing is likely correct. Have you tried opening the world file in your original message to see if the colours have been updated?

[EtlamGit]

Yes, my fault. I forgot to increment the version number.

[EtlamGit]

Should work now.

You can always download the latest definition and overwrite the local file in %appdata%\Local\seancode\Minutor with it.

[Delvin4519]

Seems though the hex code for the fixed file is incorrect, since there are 7 characters for the hex code so it results in an invalid color.

[EtlamGit]

Too fast changes increase the chance for errors ... next one is checked in.

[Delvin4519]

Closing this issue as resolved