A part of the IC2 CropAPI is broken and nobody in the team cares...

  • 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:

    Code
    1. 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:


    Code
    1. public String getDisplayName()
    2. {
    3. return getName();
    4. }


    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:


    Code
    1. public String getDisplayName()
    2. {
    3. return I18n.translateToLocal(getUnlocalizedName());
    4. }


    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...

  • Pulled straight for the API:


    It's working as the documentation says it should. If you have an issue with that you can make a suggestion but otherwise it's not wrong.

    145 Mods isn't too many. 9 types of copper and 8 types of tin aren't too many. 3 types of coffee though?

    I know that you believe that you understood what you think I said, but I am not sure you realise that what you read was not what I meant.


    ---- Minecraft Crash Report ----
    // I just don't know what went wrong :(


    I see this too much.

  • 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...

  • Its simple, Translation Keys are "getUnlocalisedName" while displayed Names, including optional Color Coding, are "getDisplayName". This is how it is supposed to work for Items and Blocks. But IC2 confuses people by using wrong namings for its Functions.


    I already had to fix language Issues due to wrong return values for getUnlocalisedName and getDisplayName ages ago, so its no wonder Player probably derped up that one again. Can't you just fix it or at least give a less confusing desription on the Function for 1.8+ and stuff? I know the API is in the works so this should be fixed now, before its too late.

  • No, this works exactly as designed. The Javadoc is IMO precise enough, you are just confusing it with MCP's poor naming scheme.


    getName() and getOwner() uniquely identify the crop for persistence, items etc. and are not exposed to the 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.

  • 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:



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

    The post was edited 1 time, last by Speiger ().



  • that makes no sense player. Because thats whats getUnlocalizedName is for and the CropAPI has already a getUnlocalizedName.

    This ^


    Seriously, Speiger is right about that.

    • getUnlocalisedName returns a String that can be used properly as a Key for Translation.
    • getDisplayName is what actually translates getUnlocalisedName for you. Its just a Function whiches entire purpose is calling I18n.translateToLocale() on getUnlocalisedName, nothing else.
    • getName is the Function which should be used if you want to store the Crop as String for synchronization and saving or for similar purposes.

    I still remember how you freaked out when I fixed that localisation prefix thingy inside the Item and Block Classes, back then when I was still doing stuff for ic2. Why are you so reluctant to actually fix obvious Bugs?

  • 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.


    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.

  • 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:

    Code
    1. public String getUnlocalizedName()
    2. {
    3. return "crop." + getName() + ".name";
    4. }



    Players Version:

    Code
    1. public String getUnlocalizedName()
    2. {
    3. return getId();
    4. }


    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:


    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))



    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)

    The post was edited 2 times, last by Speiger ().

  • So player merged a fix in his eyes but still did not fix anything.... Actually he did break the default get UnlocalizedName function... Could anyone else in the team please take care of that because player is not able to do these kind of things...