forestry wood doesn't has a hardness set? about forestrymc

[AEnterprise]

will somebody look intro it? i was unable to prevent it with a null check as it already errors when asking for the hardness

[SandGrainOne]

Could this be caused by the log taking damage from the tool and thus changing the damage value that is used to determine what type of log it is?

How is Meta values separated from damage on the block during mining? Is mining damage a value we can get in addition to meta/damage?

Edit:
nvm, nuub questions :)

[SandGrainOne]

All Forestry Wood have a Hardness. The issue here is that Forestry fails to identify the type of Wood because there is no given world object. The world variable is null.

I can't find any other reason for why this could fail like this.

This is one of those things I don't understand. How can the world variable be null? Is there a common cause?

Lastly I'd like to know if we should change the code to check for missing arguments. Should the code fail like now or should we return the default hardness.

[AEnterprise]

in cases like this i think it is best to return the default hardness. If it heapens with my custom tools, i'm sure it heapens with others as well

[mezz]

Tried to reproduce, couldn't get the tool to break anything at all, even vanilla trees.
Tried spawning a kinetic multitool with NEI, added a sawblade with integration table, and gave it a filled kinetic capsule. Nothing...

latest forestry
Eureka 1.2
Buildcraft 6.0.18
Buildcraft-Additions 1.6.4

[AEnterprise]

what do you mean could not get it to break anything? where you in creative?

[mezz]

Thanks, I was in creative because the tool would break from lack of knowledge in regular mode.
I was able to reproduce the crash now, we get a null world object. (confirmed)
We can't determine the type of wood without the world object.
I'll look more into it.

[mezz]

Your code has world=null, x=y=z=0 when getDigSpeed is called. It seems to expect ItemPoweredBase onBlockStartBreak to be called first (which sets the world and position), but that's not what happens.

player is also null in getDigSpeed, so you call readBateries(stack, player) with a null player, even before calling anything related to Forestry.

This is definitely a bug on your side.
One solution could be to move the energy check to onBlockStartBreak and return true if there's not enough energy.

I'll wait for your response before closing this in case I missed something again. I hope I was able to help.

[AEnterprise]

my code indeed asumes that that function is called (as it should be called when you start breakings something) The odd thing is that all of this works for non-forestry wood (works fine with BoP as far as i know)

moving the energy check still won't solve it as the world and x,y, z values will still be incorrect (or null)

[mezz]

onBlockStartBreak is called after you've been hitting the block for a while, when it's full of cracks and about to break. getDigSpeed will always be called first.

Vanilla doesn't use the world, x, y, or z, it just returns a hardness value for that block. Forestry has different woods depending on the meta value so it needs that information to be valid in order to determine what kind of wood it is.

[AEnterprise]

you where right, all fixed now, thanks
AEnterprise/Buildcraft-Additions@553b65a