[1.12] Modelvariants for facing different directions won't show up [solved]

[ConfusedMerlin]

Good morning,

 

somehow I feel like some guys are already moaning ("oh no, not this dude again, he writes way to much..."), but I still hope for assistance in pinning down an error that does not feel like its all that hard to fix.

These who don't like much text may skip the next paragraph... 

 

So I went from registration of items and blocks over recipes straight to custom models with textures. And while this wasn't a cake walk, I somehow managed to bring a blockbench-json-model inside Minecraft, with all textures appearing. I got slowed down because the upper face of the block below that model was always not there, learned about isOpaqueCube and isFullCube (which are deprecated... is there a substitute available, or was that seriously used to "mark" internal functions?), and was thrown off course by facing the facing of blocks. Most examples from mod tutorials are not usable any more or just plain adventurous, but somewhere in this forum someone told somebody else to look at the vanilla way of doing this (the torch), which led me back on course. Still, after finding out that forgetting to assign reactions to directions will cause minecraft to crash with a confusing errormessage, I'm at a point that still manges to evade my abilities to solve modding problems.

 

So what's wrong? The turret I made for testing purposes refuses to use any of the blockstate-models (facing=up and so on) after I finally managed to have the facing I want appear when placing it at a given side of a block. That... sounds confusing. Thankfully, it prints the blockstate it want to use at the invalid disco-block. It looks like somewhere a wrong model-path got inserted, because its missing the "block/" inside the model resource location string. Hm, when reading the last sentences, I have to admit to be not able to grasp what's wrong on my own... so let pictures speak! In case you didn't spot it already, just scroll down a bit. 

 

As one can see, it prints a little text at the blocks. That' neat, because I was able to get the correct facing for each direction without having the model appear after all *cough* Still, the most important part is missing. When you look closely at the inventory-bar you might spot something with a big red dot on it (which is inside the characters right hand right now). Thats the block I want to appear there. Whats there is the itemblock which came from the block itself, what should indicate that my model still is valid (and even know where its textures are!). But the facing ones fail to do so. 

 

What now... ah, the blockstates! I tried with and without "block/", both didn't work. The path itself should be correct, because in the beginning there was just "normal" inside, which did contain the "block/" in front of the name. And the model showed up correctly. So I hope at least the "model" value can't be critical wrong after all.

Spoiler

{
  "variants": {
    "facing=up":    {"model": "ianusinchq:block/ianus_inc_turret" },
    "facing=east":  {"model": "ianusinchq:block/ianus_inc_turret", "y":"0","x":"90" },
    "facing=south": {"model": "ianusinchq:block/ianus_inc_turret","y":"90","x":"90" },
    "facing=west":  {"model": "ianusinchq:block/ianus_inc_turret","y":"180","x":"90" },
    "facing=north": {"model": "ianusinchq:block/ianus_inc_turret","y":"270","x":"90" },
    "facing=down":  {"model": "ianusinchq:block/ianus_inc_turret","y":"0","x":"180" }
  }
}

 

Okay, juuuust ignore the rotations there... that's something I need to figure out later, when all is on place. I bet everything will be flipped beyond good and evil, so... just don't mind (except if these are the guilty pieces for that problem).

 

What else could be of interest... ah, of course, the logs. Lets see... latest.log doesn't containt anything about ianus_inc_turret, fml-junk-earlystartup just contains the "loading" and "switching numbers" entries, and ... huh, even fml-client-latest just have one entry about recursing (which should be valid) and doesn't know anything about "facing" too. Okay, thats strange. And... seriously, even the console just contains what I did add to log (registering ianus_inc_turret) and don't know any "facing" too. Am I looking at the wrong destinations? Are the logs even up to date? Hm, yes, they are. 

 

All I can add is the class belonging to that block. While we are at it, my way of determining the correct facing is open for debate too. It feels a bit stupid to get the opposite facing of the opposite facing, but it yield the correct facing anyway. It may need something more sophisticated in future, but at the moment is seems to suffice. The getMetaFromState and its opposite method do feel kind of wrong too, but I took them from the torch from minecraft and added another case, because "down" is valid for my block. And... id didn't work before I modified it to contain "down" too. Then we do have the FACING variable, which is  strange too. Still, it does what I expect it to do. 

Spoiler

/**
 * Created by Seine Eiligkeit on 01.07.2017.
 */
public class IanusIncTurret extends CustomBlock {

 //   public static final PropertyDirection FACING = PropertyDirection.create("facing", EnumFacing.Plane.HORIZONTAL);
    public static final PropertyDirection FACING = PropertyDirection.create("facing", new Predicate<EnumFacing>()
    {
        public boolean apply(@Nullable EnumFacing p_apply_1_)
        {
            return true;
            //return p_apply_1_ != EnumFacing.DOWN;
        }
    });

    public IanusIncTurret(String name, float hardness, float resistance, int harvestLevel) {
        super(name, hardness, resistance);
        setHarvestLevel("pickaxe", harvestLevel);
        setCreativeTab(CreativeTabs.MISC);
        this.setDefaultState(blockState.getBaseState().withProperty(FACING,EnumFacing.UP));
    }

    @Override
    public boolean isOpaqueCube(IBlockState state) {
        return false;
    }

    @Override
    public boolean isFullCube(IBlockState state) {
        return false;
    }

    @Override
    public IBlockState getStateFromMeta(int meta)
    {
        IBlockState iblockstate = this.getDefaultState();

        switch (meta)
        {
            case 1:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.EAST);
                break;
            case 2:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.WEST);
                break;
            case 3:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.SOUTH);
                break;
            case 4:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.NORTH);
                break;
            case 5:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.DOWN);
                break;
            default:
                iblockstate = iblockstate.withProperty(FACING, EnumFacing.UP);
        }

        return iblockstate;
    }

    @Override
    public int getMetaFromState(IBlockState state)
    {
        int i = 0;

        switch ((EnumFacing)state.getValue(FACING))
        {
            case EAST:
                i = i | 1;
                break;
            case WEST:
                i = i | 2;
                break;
            case SOUTH:
                i = i | 3;
                break;
            case NORTH:
                i = i | 4;
                break;
            case DOWN:
                i = i | 5;
                break;
            case UP:
            default:
                i = i | 6;
        }

        return i;
    }


    @Override
    protected BlockStateContainer createBlockState() {
        return new BlockStateContainer(this, new IProperty[] {FACING});
    }

    @Override
    public IBlockState getStateForPlacement(World world, BlockPos pos, EnumFacing facing, float hitX, float hitY, float hitZ, int meta, EntityLivingBase placer, EnumHand hand) {
        //facing.getAxis();
        return this.getDefaultState().withProperty(FACING,facing.getOpposite().getOpposite());


    }

}

 

Whats else? The model did work well before I tried to apply facing, so I hope there is no space for errors in all the other spaces it appears in the code. No, for now I think all places that can influence the behaviour are covered. Inside the model.json there seems to be no reference to the facings.... there aren't any in minecrafts torch.json too, so I'll skip that for now (until someone yells at me and request these to look at)

 

So. Where does the wrong path slip in? Or isn'T there a wrong path after all? 

 

Confused Greetings, Merlin

 

Edited July 4, 2017 by ConfusedMerlin
solved

[Choonster]

1 minute ago, ConfusedMerlin said:

I got slowed down because the upper face of the block below that model was always not there, learned about isOpaqueCube and isFullCube (which are deprecated... is there a substitute available, or was that seriously used to "mark" internal functions?)

 

Most of the deprecated methods in the Block class are deprecated because they should be overridden, but not called. Call the equivalent methods in IBlockProperties (which IBlockState extends) instead.

 

Don't include block/ in the blockstates file's model locations, Minecraft automatically adds that. I explain how model locations are mapped to model files here.

 

I believe BlockTorch only does its sate/metadata conversions in that way to maintain compatibility with the original metadata values, which aren't the same as the facing indexes uses in other parts of the game. For your own block, use EnumFacing#getIndex and EnumFacing.getFront instead. See BlockObserver for a simple example of this.

 

To create a PropertyDirection that accepts all EnumFacing values, you can use the overload of PropertyDirection.create without a Predicate argument.

 

If you say that it doesn't work even without the block/ prefixes in the blockstates file, I'm not sure exactly what the problem is here.

 

Could you create a Git repository of your mod (if you haven't already) and link it here? See my mod and its .gitignore file for an example of the repository structure and which files to include.

[ConfusedMerlin]

So...

 

I didn't expect creating a git repository and connect it with an already existing intelliJ project could be such a annoying task in Windows. Anyway, now its done. IanusInc on GitHub. Even the Licence file is in there again *sigh*

 

Anyway, I tried to apply some of your suggestions @Choonster, especially taking from the BlockObserver the Meta Methods and having the FACING Field created in  a less complex way. Good news first: it still works, even with the correct facing. Bad news: it didn't fix the facing model variants not appearing. 

The other suggestions will kept in mind until I'm better at knowing my way around with the forge API one day. 

 

All of this does have the smell of "stupid little typo" somehow. 

At least... the MINGW64 that came with windows git does contain a proper GREP (I hate searchstr or what its name in windows may be). And it did found the text on the not rendering models, which is located inside the blockstate file for that block.
Interesting, by the way, was, that the text on the disco-block didn't change to contain the "/block" I added for testing, so its source must be somewhere I'm totally not aware of. Where can I look for this other than the places I did inspect already?

 

But until this mystery has been solved, I will approach multiblocks and other APIs from a pretty distant direction... 

 

Greetings, Confused Merlin

[Choonster]

Please include the files required to build the mod in the repository: build.gradle, gradlew, gradlew.bat and the gradle directory.

[ConfusedMerlin]

Quote

Please include the files required to build the mod in the repository: build.gradle, gradlew, gradlew.bat and the gradle

Ah, yes, as you did show with your .gitignore. I guess I successful forget them to add to the repository when destroying my .gitignore file.

I did as requested; if you time allows, please have another look. 

 

EDiT: May I ask if you had any success in pinning down that error?

Edited July 3, 2017 by ConfusedMerlin
Hoping for news

[Choonster]

The logging of missing models was broken in Forge 1.12-14.21.0.2363 (commit dc043ac) and fixed in Forge 1.12-14.21.1.2390 (commit ede05a2).

 

After updating Forge, it was easy to identify the issues with the turret blockstates file:

• You were using strings instead of integers for the x and y rotations.
• The first variant was misspelled (facung=up rather than facing=up).
• The first variant has an invalid block/ prefix in its model location.

 

Some other issues I noticed:

• There's no item model for the turret in the repository.
• IanusIncHq uses Java's Logger instead of log4j's (which is what Minecraft uses).
• CustomBlock has a missing semicolon.
• The turret and small super condensator models extend minecraft:block/cube_all but override its elements and don't specify the all texture. They should extend minecraft:block/block instead, since it provides the standard display transformations without providing any elements.
• The other non-cube models don't extend any model and don't specify any display transformations, they should extend minecraft:block/block.

 

I've fixed these issues and pushed the changes to GitHub. You can view and/or merge the changes here.

Edited July 4, 2017 by Choonster

[ConfusedMerlin]

Oh... holy enderpearl, 

 

Dear Choonster, I'm very grateful that you not just got rid of the models rotating errors, but also found some other things that needed improvement. 

I have to admit that I pushed a version to git yesterday which was a "oh dear its this late already lets push everything in case my hdd won't wake up tomorrow"  commit - the missing ; might have been part of it. 

 

Anyway... IT WORKS. wuhu!

As expected, the rotation is... well, I need to rotate the rotation angels counterclockwise to have them align correctly. Something like this. 

 

So, thank you again. 

 

 

Regarding your comments -

• I removed the item model to be honest. And now I do see the error-messages from the console log... (no item). Hm... just until now I thought all blocks will create their item via the blockitem-class. Well... at least, I think " normal location exception" means that I should put a normal block-variant back inside again. 
• Java-Logger comes from work; when creating this LOGGER field I saw java.util and log4j and went into work-mode. 
• I need to ask what do you mean by talking about "display transformations".... might it the the shift of size and rotation that control how the item does look inside the inventory, the hand, or floating around being dropped? Thats something I came across already, but did't put much attention at it.

So again, thank you for you help. Now I'm off again, straight forward the next strange errors (one is already luring behind the horizon in the shape of multiblocks).

 

Have a nice day everyone 

 

 

[Choonster]

1 hour ago, ConfusedMerlin said:

• I removed the item model to be honest. And now I do see the error-messages from the console log... (no item). Hm... just until now I thought all blocks will create their item via the blockitem-class. Well... at least, I think " normal location exception" means that I should put a normal block-variant back inside again. 

 

Items load their models from either an item model file (the normal location) or a variant of a blockstates file (the blockstate location). You need to provide at least one model for every item.

 

1 hour ago, ConfusedMerlin said:

• I need to ask what do you mean by talking about "display transformations".... might it the the shift of size and rotation that control how the item does look inside the inventory, the hand, or floating around being dropped? Thats something I came across already, but did't put much attention at it.

 

That's correct. Display transformations are rotation, translation and scale operations applied to the model when it's rendered as an item in various contexts (e.g. left/right hand, GUI, item entity, etc.).

Edited July 4, 2017 by Choonster