[1.16.5] make mi costume Glass block/panel transparent

[perromercenary00]

i just refactoring the question from the iron bars block 
i have create a basic full block of glass and an slab
the issue is than this block is not transparent it loads glass texture but its dull gray you cannot see through  as whit the vanilla glass block 
 

 

im creating the block using the tutorials from Kaupenjoe

https://www.youtube.com/playlist?list=PLKGarocXCE1EMxeBvqsOWZVkYD_Vd_uwW
 

	    public static final RegistryObject<Block> GLASS_BLOCK = registerBlock( "glass_block", 
            () -> new Block( AbstractBlock.Properties.of(Material.GLASS).strength(0.3F).sound(SoundType.GLASS).noOcclusion()));
	

the block is made using the vanilas block class 


in the old versions to make block transparent you have to add to the block code this function 

	    @Override
    public boolean isOpaqueCube(IBlockState state) {
        return false;
    }

something like this is missing or the system has totally change 
someone says than 
ItemBlockRenderTypes.setRenderLayer(YOUR_BLOCK, RenderType.cutoutMipped());

but i dont have friking idea where that piece of code would go 

 

 

 

 

 

 

 

 

 

 

 

 

Edited June 27, 2022 by perromercenary00

[warjort]

> but i dont have friking idea where that piece of code would go 

As I said on the other thread, it goes in your client setup code.

See doClientStuff() in the example mod

https://github.com/MinecraftForge/MinecraftForge/blob/1.16.x/mdk/src/main/java/com/example/examplemod/ExampleMod.java

Edited June 27, 2022 by warjort

[Luis_ST]

12 hours ago, perromercenary00 said:

ItemBlockRenderTypes.setRenderLayer(YOUR_BLOCK, RenderType.cutoutMipped());

call this in FMLClientSetupEvent inside of enqueueWork

Edited June 28, 2022 by Luis_ST

[Luis_ST]

When is enqueueWork necessary?
i know it's a way to move actions which are not thread safe to the main thread, but why is it sometimes required and sometime not, since the most vanilla stuff is not thread safe??
is there a rule for it?

And what happened in the worst case if enqueueWork necessary but is not used?
and the opposite worst case if enqueueWork is not necessary but it is used?

Edited June 28, 2022 by Luis_ST

[warjort]

As I understand it, it is used to run setup tasks in parallel (including with other mods in the same loader stage) if you have something that takes a long time.

Using it for simple tasks like that simple rendertype registration likely takes more work in terms of the overhead of scheduling the tasks on different threads?

And like you say, it could cause problems if the code being called is not threadsafe.

setRenderLayer() is a synchronized method added by forge so it wouldn't cause an issue for that.

[Luis_ST]

3 hours ago, Luis_ST said:

And what happened in the worst case if enqueueWork necessary but is not used?
and the opposite worst case if enqueueWork is not necessary but it is used?

What about that?

[warjort]

So the opposite of what I said. 🙂 

I wonder how many other modders don't realise code executed directly in the setup event is potentially not threadsafe? It kind of breaks "the principle of least surprise".

The only mention in the javadoc is a throw away "This is a parallel dispatch event".  You might not appreciate what it is telling you since it just looks like a redundant restatement of the parent class. The ParallelDispatchEvent has no javadoc itself explaining how it works. 

I'd always assumed ParallelDispatchEvent was an "executor" for parallel work, given the methods look like they say they "queue work on a parallel dispatcher", hence my misunderstanding above.

-- End Rant --

Edited June 28, 2022 by warjort