I've got it worked to where I only need to know what the field deobfuscation is.
func_145775_I() = this.doBlockCollisions()
func_70106_y() = this.setDead()
As to what the following is I am not completely sure of that way, although when I built the mod with inGround it stayed the words inGround:
this.field_70123_F
If anyone knows the method lemme' know, here's what I've got and it doesn't build with the method name in java instead of it being readable English that way:
I don't know if you've noticed this but you have an impossible condition in the last "else if", which is checking if the same variable (isRemote) is both false and true:
else if (!this.worldObj.isRemote && this.worldObj.isRemote && this.ticksExisted >= 114)
If this was intended to disable code for testing it is better to add in a field named "DEBUG" or such so it is more obvious that it was intentionally disabled; for example, I have the following in a custom RNG class (the method "nextInt2" is only to be used when the parameter is a power of 2; also, since DebugHelper.DEBUG_RANDOM is a static final field the compiler will completely remove the line when it is set to false):
// Used when n is a power of 2 for greater speed and randomness (only uses as many uppermost
// bits as necessary; maximum value of n is 65536)
public int nextInt2(int n)
{
if (DebugHelper.DEBUG_RANDOM && (n & -n) != n) throw new IllegalArgumentException("n must be a power of 2; was " + n);
this.state = this.state * 2862933555777941757L + 3037000493L;
return (n * (int)(this.state >>> 48)) >>> 16;
}
While that is true the actual consideration is that of a wall being horizontal or verticle:
If the entity hits a block the blocks do collision proportionate to that said area.
If the entity is not remote (not close enough to be seen by the player by the relativity of the right or left hand or both) then the entity has been collided with horizontally.
If the entity is nearby or isn't nearby and it has existed for 114 ticks (which being four or five seconds) then destroy the entity.
Which what it does is keeps the entity from making block collisions if it persisted past the block somehow and went through past visibility.
If you summon several hundred explosives above the height limit it could possibly freeze or break your world as a possibility, so what it does is makes it so that can't happen that way.
The entity itself uses nbt tag data to calculate it's actual lifetime instead of how many ticks it has existed
So ticks existed theoretically on those terms are not recognized by the entity or the environment.
Although at the same time reminding the environment that if the entity has existed longer than 114 ticks in game while persisting past that can be destroyed if existed out of the limits of the game itself.
While that is true the actual consideration is that of a wall being horizontal or both verticle:
This can be achieved by finding the exact center of the nether with a fireball.
By creating an exact center by doing so can also break or freeze your world.
On the other hand if you are in favor of fireball nether portals will function normally in the world you are playing in or on.
Both having a similar functionality that the symbol used for the code faces in a given direction proportionate to how they are recognized as to the condition being true or false.
If this is to be achieved then the condition has to be met, otherwise the entity persists past it's logical occurence of having the logical equivalation of being recognized as having ticks proportionate to it's existence.
Something with ticks could function similar to a clock, while something with lifetime could be considered a bird.
The title explains everything, I have a built jar and I cannot build with these two functions not being deobfuscation.
I have these on an on impact method, although something happened to my source and had to rebuild.
Here is the code:
I was able to solve that !this.field_70170_p.field_72995_K = !this.worldObj.isRemote and this.field_70173_aa = this.ticksExisted.
I've got it worked to where I only need to know what the field deobfuscation is.
func_145775_I() = this.doBlockCollisions()
func_70106_y() = this.setDead()
As to what the following is I am not completely sure of that way, although when I built the mod with inGround it stayed the words inGround:
this.field_70123_F
If anyone knows the method lemme' know, here's what I've got and it doesn't build with the method name in java instead of it being readable English that way:
I don't know if you've noticed this but you have an impossible condition in the last "else if", which is checking if the same variable (isRemote) is both false and true:
If this was intended to disable code for testing it is better to add in a field named "DEBUG" or such so it is more obvious that it was intentionally disabled; for example, I have the following in a custom RNG class (the method "nextInt2" is only to be used when the parameter is a power of 2; also, since DebugHelper.DEBUG_RANDOM is a static final field the compiler will completely remove the line when it is set to false):
TheMasterCaver's First World - possibly the most caved-out world in Minecraft history - includes world download.
TheMasterCaver's World - my own version of Minecraft largely based on my views of how the game should have evolved since 1.6.4.
Why do I still play in 1.6.4?
While that is true the actual consideration is that of a wall being horizontal or verticle:
If the entity hits a block the blocks do collision proportionate to that said area.
If the entity is not remote (not close enough to be seen by the player by the relativity of the right or left hand or both) then the entity has been collided with horizontally.
If the entity is nearby or isn't nearby and it has existed for 114 ticks (which being four or five seconds) then destroy the entity.
Which what it does is keeps the entity from making block collisions if it persisted past the block somehow and went through past visibility.
If you summon several hundred explosives above the height limit it could possibly freeze or break your world as a possibility, so what it does is makes it so that can't happen that way.
The entity itself uses nbt tag data to calculate it's actual lifetime instead of how many ticks it has existed
So ticks existed theoretically on those terms are not recognized by the entity or the environment.
Although at the same time reminding the environment that if the entity has existed longer than 114 ticks in game while persisting past that can be destroyed if existed out of the limits of the game itself.
While that is true the actual consideration is that of a wall being horizontal or both verticle:
This can be achieved by finding the exact center of the nether with a fireball.
By creating an exact center by doing so can also break or freeze your world.
On the other hand if you are in favor of fireball nether portals will function normally in the world you are playing in or on.
Both having a similar functionality that the symbol used for the code faces in a given direction proportionate to how they are recognized as to the condition being true or false.
If this is to be achieved then the condition has to be met, otherwise the entity persists past it's logical occurence of having the logical equivalation of being recognized as having ticks proportionate to it's existence.
Something with ticks could function similar to a clock, while something with lifetime could be considered a bird.