I make bedrock breakable for 750.0f but then the bedrock wasn't added to the stat list. I don't know how how to add it to the stat list.

Edited August 13, 20196 yr by Issac29

You can't.

There's a function that sets stats off, but as it defaults to on, there's no method that turns the value back on.

 

And given that bedrock can't be broken by any means that would ever trigger stats, there's no point.

Also because I made bedrock breakable but it takes a long time to break, there has to be a way.

 

Edit: the Hardness was negative one then at 450F.

Edited May 26, 20196 yr by Issac29
Forgot one

On 5/25/2019 at 10:30 PM, Draco18s said:

And given that bedrock can't be broken by any means that would ever trigger stats, there's no point.

Normally bedrock is unbreakable but the changed code allows to make bedrock breakable with some edited java code.

Like This:

Blocks.BEDROCK.setHardness(30.0F)

 

14 minutes ago, Issac29 said:

Normally bedrock is unbreakable but the changed code allows to make bedrock breakable with some edited java code.

Like This:

Blocks.BEDROCK.setHardness(30.0F)

 

Yes, I know you can do that. At least, in 1.12. That won't always be true (and in fact, in 1.13 you can't: hardness and resistance were made final).

 

What I'm saying is that this function is called on bedrock:

 

disableStats()

 

This sets enableStats to false. enableStats is a protected field. There is no enableStatsAgain() method to set it back to true.

So it's impossible. 

I think I said something about that.

On 5/25/2019 at 10:30 PM, Draco18s said:

You can't.

There's a function that sets stats off, but as it defaults to on, there's no method that turns the value back on.

You could use reflection, but I don't know if that would be sufficient.

Edited June 6, 20196 yr by Draco18s

3 hours ago, Draco18s said:

That won't always be true (and in fact, in 1.13 you can't: hardness and resistance were made final).

Access Transformers exist.

25 minutes ago, Draco18s said:

You could use reflection

Or Access Transformers

Access Transformers are not better than Reflection.

@Draco18s What is wrong with access transformers and how do I use a reflection?

 

@Cadiboo what is an access transformer anyways. 

12 minutes ago, Draco18s said:

Access Transformers are not better than Reflection.

In some cases they are. They are better when you have a private/protected/package private Field that you want to get/set or you have a private/protected/package private Class that you want to access. They are also when you have a private Method that you want to call (not override). They are also the only solution (aside from ASM) to definalise a Class/Field/Method.

In all other cases Reflection should be used

3 hours ago, Cadiboo said:

They are also the only solution (aside from ASM) to definalise a Class/Field/Method.

This is not entirely true.

https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection

In fact I am pretty sure I saw similar code in forge at some point.

Doing this is not a good idea though.

 

3 hours ago, Cadiboo said:

In some cases they are. They are better when you have a private/protected/package private Field that you want to get/set or you have a private/protected/package private Class that you want to access.

 

"In some cases they are better than reflection. That is in ALL of access cases."

There is nothing wrong with using reflection and you should prefer reflection to ATs in most cases IMO. Use ATs if your reflective operation is too expensive(eg. called multiple times a frame).

2 hours ago, V0idWa1k3r said:

This is not entirely true.

https://stackoverflow.com/questions/3301635/change-private-static-final-field-using-java-reflection

In fact I am pretty sure I saw similar code in forge at some point.

 Doing this is not a good idea though.

Java 9 removed the ability to definalise Fields with Reflection.

56 minutes ago, diesieben07 said:

The other applicable point is when you need to override a final (or private, although this is dangerous) method, which literally cannot be achieved using reflection at all.

Private instance methods cannot be overriden because the bytecode instructions in the class that uses it for them will still be INVOKE_SPECIAL rather than the INVOKE_VIRTUAL opcodes required for overriding to work. 

Yes, I glad it worked. I saw the removed apis and looks like https://www.oracle.com/technetwork/java/javase/9-removed-features-3745614.html does not say anything about reflection being removed.

I said that you can no longer definalise fields with Reflection (because of how it breaks the JVM) in Java 9. They definitely didn’t remove Reflection.

And by how definalize fields could be useful.

I use it on my mod to replace the fluid renderer (the field in BlockRendererDispatcher is final) to add smooth lighting and other stuff.

Well this topic is solved so thank you.