Posts by Speiger

Ok from what i see its maybe a double hand issue. Try Sneak Clicing that prevents the ejection of the Terraformer...
Defently a bug...

The normal senario is that the Fences are stacked... So the more you use the laggier it will be and the curve with the Exp System goes way higher then the old way is ever going.... (Its still 5 * (2 or 3) times more checking)
On Top of that you have the Magnetizer still ticking. Making every tick almost the same amount of lag as it would do with the fence checking... And since the original system was delayed the amount of lag is actually less then the the current... (Simply dissable ticks in the magnetizer of IC2 Exp and yes then it is true or decrease the trickrate to 1/20 and then it would less laggy. But else no its way laggier in that use...)
Em yeah.... Makes so much snese...

Either 1.7.10 or latest anything else will properbly loose support rathr quickly.

Quote from Player

Ignore getUnlocalizedName(). It has been added by someone else mistakenly and isn't being used anywhere. I'll change getName to getId and getDisplayName to getUnlocalizedName. With getName it wouldn't be advisable to use getUnlocalizedName since that strongly implies getName was the localized one.

Well i think you should keep getDisplayName and just use I18n.translateToLocale() inside of it and mark it as "Its the same as ItemStack.getDisplayName" that would be the best result.... So you do not need to add new stuff...

Edit: Thanks for fixing that. But also why did you change what Estebes did already right?
Estebes version:

public String getUnlocalizedName()
  {
    return "crop." + getName() + ".name";
  }

Players Version:

public String getUnlocalizedName()
  {
    return getId();
  }

Estebes did implement that function already right... Could you one time orient yourself on the Original MC source instead of doing your own thing?

Here is how it should look like:
Speigers Edition:

public String getDisplayName() 
	{
		return I18n.translateToLocal(getUnlocalizedName());
	}




	public String getUnlocalizedName() 
       {
		return "crop." + getName() + ".name";
	}

Just copy that change getName to getId() and everything would be fine...

Also one feature request on the other side...
Could you allow mulitlayered textures on crops (public List<ResourceLocation> getModelLocation(int cropstage))

Quote from Player

I already explained that and why IBlockState and its serialized form are not mirroring each other. They are usually the same, but that's not mandatory - even less with my plans to serialize some unlisted properties. They aren't even the same on the client due to incomplete serialization coverage from unlisted properties. Investigate how block states with Forge's additions work in depth before claiming obviously incorrect facts.

Also Just to point that out. Forge IUnlistedProperties you should only use if you would else do a BlockStateOverflow (Meaning You have more then 1k BlockStates) but even then you should not use it at all... IUnlistedProperty is good in its idea but very bad solved,
It gets deleted when placed into the world and some functions do not call getExtendetState at all and you run into issues with accessing data of that kind. A Global Variable keeps the last accessed data and prevents NullPointExceptions...
And even then it would be better to remove the String variant and provide a tool that converts BlockStates to Strings & back and if a BlockState has unlistedProperties it should not be used at all...
Also just one little thing that make me think: Why did you do this thing...
When you extract a Texture out of the Block you are extracting the position of that vertex data...
I would understand if you use that for checking if the texture used is a full block texture but nope you are just coping the position to remap them...
And here is my question: Why are you doing that, since it has to be given that the Texture used has to be a full block texture because foam can not be a differend sized cube then a full cube...
Or do i missunderstand there something?

Also one thing you should support 2 BlockStates in your Retexture Event not just one, because there is now a model state & renderState, they can be the same but do not have to be the same... (And renderState should be always checkt)

Its so sad that the team ignores it and then deletes this entry.... (reposted)

It checkt every 20 Ticks if the blocks are charged if not it recharges them. If the Magnetizer was empty it did not check at all.
And comparing both to each other. When a people grab on to these things its first: Checking more blocks at once (simply 2-3 Blocks iterating through all Iron Fences + 4 Horizontal Coliding blocks each tick times the entities) The amount of lag thats added by the old way is yeah constant but does not get more then it is before... The other side gets a lot more then it was before...

Simply: Yeah when nobody uses it at all then doing it the Exp way is better. But iron Fences are fences and when you use them for decoration its actually causes lag when player walks just nearby them....

So yeah... I think the way you are doing is more laggy. Unless you prevent the placing of them unless they are connected to a magnetizer...
But even then the impact change on the use is drasticly higher then the original thing...

But ic2exp went only that route because they run out of blockstates because it would need 16 * 2 * 2 * 2 * 2 (256 BlockStates)

Yeah it makes partly more sense... But the way it is solved is not really server friendly & you can no longer make charge based systems... (Like charging for a short time and then you can only go up once a ladder)
(And the none serverfriendly system is because you make 4x more block checks per tick (times the player) and if a lot of players do that at once you can get a drag only from that (because its using the entity ticktime)

Quote from Chocohead

The iron fence tower goes next to a magnetiser, so that the side with the 2 white rectangles (which is where the fence should connect to but doesn't :|) is facing it.

Yeah thats true. But you have to know this change too:
Magnetizer no longer charges the Blocks so you have to constantly power the Magnetizer so you can move up...
(Before it was you charge the iron fences and then you were able to move up even if the Magnetizer was empty)

ask and i can may answer it...

Well its easy to calculate the EnergyLoss. You simply start with 0.1 From the beginning and add per wire the loss of it on top...
Also the Values you say are partly only right... Because the Loss Values actually change between insulation. (Thats why i added in IC2 Classic a way to show the loss)
And if the loss is higher then the energy thats getting sended then it stops.
In the solar panel you are partly missinformed. Yes it produces 1EU per tick but it has a 2EU EnergyBuffer so you actually can go 2x the distance. But you get only half the time the energy because it needs 2 Ticks to generate 2EU
(Note: In 1.9.4 in classic there will be a way to show the energy flow + Loss Information of each indiviual part + total loss at that position)

Quote from Player

getDisplayName() is the user visible name, before localization of course. A pre-translated getDisplayName makes hardly any sense, it prevents the server from querying it, which contradicts the "dumb client" model MC is increasingly adapting. If formatting capabilities are desired, we can consider making it return ITextComponent instead of String.

that makes no sense player. Because thats whats getUnlocalizedName is for and the CropAPI has already a getUnlocalizedName.
Just to point that out...

Edit: Simply delete the function or return the name that has to be shown on the game display. That means you use the function and do not have to use I18n.translateToLocale() or anything else!

Its at the same stupiditylevel as the Retexture Event that is doing something like this:

public class ExampleEvent extends Event




public ItemStack stack;
public Item item;
public int metadata;
public int damage;
public NBTTagCompound nbt;




        public ExampleEvent(ItemStack par1, Item par2, int par3, int par4, NBTTagCompound par5)
        {
                stack = par1;
                item = par2;
                metadata = par3;
                damage = parr4;
                nbt = par5;
         }
}

And yes i am referencing the BlockState & its String variant....
(Simply providing the blockstate & the same blockstate as string)

That part of the api you took out from 1.7.10
The backwards compatiblity part is until 1.7.10 ends.
Also just to point that out: getDisplayName != getName(in other words: getRegistryName)
Its the actualy name you display...
And thats what all people think when they see this function name...

Since a long time IC2 Exp has a bug in his API which i am trying to point out and getting fixed (telling them that and trying to tell them to fix it and how)

And always i run into the same thing: Nobody cares..
And then i am getting bug reports like these:
https://github.com/TinyModularThings/IC2-Nei-Plugin/issues/4
Which is happening only with IC2 Exp. Not with addons not with IC2Classic and not with other mods that add Crops (GregTech as example)

What is the bug i am talking about:

Its this function:

public String getDisplayName()

When you see this function what do you think will it do?
My first thaught its the name which you see ingame and i am returning that name in IC2 Classic. (Same as every addon i know of)
But as soon we look at IC2 Exp its returning the Registry ID instead of the LocalizedName
(getName() is used when you inject it to the registry)

Reference:

public String getDisplayName()
  {
    return getName();
  }

Now whenever bugs show up like this is showed you its not because GregTech or IC2 Classic or the Nei CropPlugins fault. Its IC2 Exps fault because first: They do not name the function properly & the only do this wrong returning...

Here is how it should have to look like:

public String getDisplayName() 
	{
		return I18n.translateToLocal(getUnlocalizedName());
	}

What bugs could show up?
-Sotring Issues when you add a Sorting by Name feature
-Using that function to get its name
-Anything that asks for the displayName to use it for comparing with something.

This is my bugreport to IC2 Exp and i am telling & yelling at them since a long time (months) that they should fix it and nobody cares...

I have seen Rorax using it already on the 1.10 Forgecraft server.... So i assume yes...

i know its fixed but with a normal config file you should be able to delete simpy the corrupted line and just let it recreate it with the next game start.

Not only that. But it would scrap the idea of a EnergyNet that simply takes all this work away. In fact with that system the energynet would be way laggier then any TE-EnderIO system (Yeah i checkt their systems because of improvements in the IC2C Energynet)

Also Aroma no to make that happen you do not need to change much... Actually...
To be fair Aroma already implemented everything that is needed for that in the EnergyNet API and to make that change work in the EnergyNet itself it needs a coupe small little changes in 1 and the same spot.

To Explain that to aroma:
You simply add a Extra Parameter that contains the circuit break (like the Energy Component) to a machine and that controls the registration at the EnergyNet. When the machine would explode and it would have that component installed & activated it would use your explosionPreventation API to prevent the explosion. While that it would not get set to air but get thrown out of the energynet...
And when the player fixes the circuit break it just readds it to the energynet...

So yeah it would be implemented very easy and quick (And i do not like that API addition so i do not support it...)

Edit: I am not helping right?

You are using a 1.7.10 version for 1.10. Thats why. Download the 1.10 version

Fixed. Update comes out next week. (Still waiting for some other people to validate that everything is fine)

Already answered in the pm he sended me.

Lol never through you would test GT with IC2Classic...

Ok first thanks to the bugreport. I take care of that in the next couple minutes but the fix release takes a couple days. (You know why)

Quote from GregoriusT

Bug Report, you call injectEnergy with wrong Parameters. It has 3 Parameters: Side, Energy, Voltage. In your Version "Voltage" is wrong, you confuse Voltage with Tier, what makes it impossible for your Enet to power GT Machines, as GT Machines assume a Voltage that is larger than a 8 Volt Battery.

I through the voltage is defined by the tier and not by the injected amount of energy (or the amount that it tries to inject) well at least its only 1 Liner fix where i have to convert the voltage to a tier.
(For example: its sending you 5 EU but has tier 2 (128EU)) (Because IC2 Classic does not inject blindly power.. (its asking before its injecting))

Edit (even if it is not edited). Fixed. Thanks