Jump to content

[1.10.2] Storing items in an enum VS Performence


SHsuperCM

Recommended Posts

Will adding items inside an enum and doing all things needed from there affect performence

while loading the game/being in the game?

I'm somewhat new to java and I dont know..

 

I'm asking this because I belive I made the simplest way of adding items and im not sure if its safe...

 

All you need is 1 line for an item and it's resources...

 

 

 

EDIT: IGNORE THIS VV  new below

public class ModItems{
    public static enum ModItemsEnum{
        TESTITEM("TestItem","this_is_test",0),
        ANOTHERTEST("UnLocalizedNameHere","registry_name_here",1),
        CanReallyBeAnything("IsThisGud","this_is_registry_name",0);




        private Item item;
        ModItemsEnum(Item INitem, String INunlocalizedName, String INregistryName, int INspecial){ //Special ItemClass
            this.item = INitem;
            this.item.setUnlocalizedName(INunlocalizedName);
            this.item.setRegistryName(INregistryName);
            if(INspecial == 0)
                this.item.setCreativeTab(Main.modCreativeTab);
        }

        ModItemsEnum(String INunlocalizedName, String INregistryName, int INspecial){ //Normal Classless Items
            this(new Item(),INunlocalizedName,INregistryName,INspecial);
        }

        public Item getItem(){
            return this.item;
        }
    }

    public static boolean registerItems(){
        try{
            for(ModItemsEnum item : ModItemsEnum.values()){
                GameRegistry.register(item.getItem());
            }
        }catch(Exception e){
            return false;
        }
        return true;
    }

    public static boolean registerRenders(){
        try {
            for (ModItemsEnum item : ModItemsEnum.values()) {
                ModelLoader.setCustomModelResourceLocation(item.getItem(), 0, new ModelResourceLocation(item.getItem().getRegistryName(), "inventory"));
            }
        }catch(Exception e){
            return false;    
        }
        return true;
    }
}

Doing stuff n' things

Link to comment
Share on other sites

EDIT:

 

Found a way to shrink it even more! Woop Woop!

 

public class ModItems{
    public static enum ModItemsEnum{
        TESTITEM("this_is_test",0),
        ThisIsUnlocalizedName("registry_name_here",0),
        CanReallyBeAnything("this_is_registry_name",0);




        private Item item;
        ModItemsEnum(Item INitem, String INregistryName, int INspecial){ //Special ItemClass
            this.item = INitem;
            this.item.setUnlocalizedName(this.name());
            this.item.setRegistryName(INregistryName);
            if(INspecial == 0)
                this.item.setCreativeTab(Main.modCreativeTab);
        }

        ModItemsEnum(String INregistryName, int INspecial){ //Normal Classless Items
            this(new Item(),INregistryName,INspecial);
        }

        public Item getItem(){
            return this.item;
        }
    }

    public static boolean registerItems(){
        try{
            for(ModItemsEnum item : ModItemsEnum.values()){
                GameRegistry.register(item.getItem());
            }
        }catch(Exception e){
            return false;
        }
        return true;
    }

    public static boolean registerRenders(){
        try {
            for (ModItemsEnum item : ModItemsEnum.values()) {
                ModelLoader.setCustomModelResourceLocation(item.getItem(), 0, new ModelResourceLocation(item.getItem().getRegistryName(), "inventory"));
            }
        }catch(Exception e){
            return false;
        }
        return true;
    }
}

Doing stuff n' things

Link to comment
Share on other sites

Creating items in static constructors is typically a bad thing to do.

Just setup your items normally in your init methods.

I figured that, but what actually it does? because I can just have items and register them any time I want,

and again I want to know what it really matters...

 

Is there some inside super wierd code that doesnt get applied to item instances when they are being themselves?

Doing stuff n' things

Link to comment
Share on other sites

You're not initalizing the items whenever you want, you're doing it whenever the class is referenced.

Which could be in placed you have no idea.

Such as when other mods re running and then FML is like "Where the hell are these items coming from!?" And it screws up the registry and things go to hell...

Its also a level of indirection magic that makes your code harder to understand.

Technically YES you could write things like this, but you shouldn't as it has a lot of downfalls.

I do Forge for free, however the servers to run it arn't free, so anything is appreciated.
Consider supporting the team on Patreon

Link to comment
Share on other sites

Actually just creating an Item instance is fine, it does not register it.

Just make sure you call GameRegistry.register in preInit only.

That's what I'm thinking about right now...

I'm just creating the items, and the registry happens only on preinit...

(a.k.a im calling

registerItems()

in preInit, and also calling

registerRenders()

in clientProxy's preInit)

So I dont actually think something would happen wrong...

Doing stuff n' things

Link to comment
Share on other sites

:D

 

I've managed to make it even smaller text/item ratio!

 

 

public class ModItems{
    public static enum ModItemsEnum{
        this_is_test(0)
        ,registry_name_here(0)
        ,this_is_also_the_unlocalized_name(0)
        
        
        ;


        private Item item;
        ModItemsEnum(Item INitem, int INspecial){ //Special ItemClass
            this.item = INitem;
            this.item.setUnlocalizedName(this.name());
            this.item.setRegistryName(this.name());
            if(INspecial == 0)
                this.item.setCreativeTab(Main.modCreativeTab);
        }

        ModItemsEnum(int INspecial){ //Normal Classless Items
            this(new Item(),INspecial);
        }

        public Item getItem(){
            return this.item;
        }
    }

    public static boolean registerItems(){
        try{
            for(ModItemsEnum item : ModItemsEnum.values()){
                GameRegistry.register(item.getItem());
            }
        }catch(Exception e){
            return false;
        }
        return true;
    }

    public static boolean registerRenders(){
        try {
            for (ModItemsEnum item : ModItemsEnum.values()) {
                ModelLoader.setCustomModelResourceLocation(item.getItem(), 0, new ModelResourceLocation(item.getItem().getRegistryName(), "inventory"));
            }
        }catch(Exception e){
            return false;
        }
        return true;
    }
}

 

Figured: why the H would I even need a diffrent string for the unlocalized name..

So its just the same!

 

Thought I'd share... Dont really have a reason...

Doing stuff n' things

Link to comment
Share on other sites

Shame it will still crash a dedicated server because it has client-side-only code in a common place.

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

ModelLoader

does not exist on the dedicated server.

 

Do you understand why the proxy system exists?

Apparently I'm a complete and utter jerk and come to this forum just like to make fun of people, be confrontational, and make your personal life miserable.  If you think this is the case, JUST REPORT ME.  Otherwise you're just going to get reported when you reply to my posts and point it out, because odds are, I was trying to be nice.

 

Exception: If you do not understand Java, I WILL NOT HELP YOU and your thread will get locked.

 

DO NOT PM ME WITH PROBLEMS. No help will be given.

Link to comment
Share on other sites

As long as registration methods are called in mod's preInit, I can't argue with the fact that it will work.

 

As to what I would comment here:

 

1. While ModelLoader is not @SideOnly, it actually is for client use only and I personally would place it in client only class (or client proxy) or at least call it from one (client proxy). :)

 

2. You already made up your mind, why keep asking? If it works, it works (doesn't mean it is any better than any other thing you could write and most certainly it isn't clearer this way).

 

3. This is probably the worst: :P

if(INspecial == 0)
                this.item.setCreativeTab(Main.modCreativeTab);

Just do ModItemsEnum.this_is_test.item.setSomeThing(stuff) from preInit.

 

4. Oh wait, it (above) isn't - From now on, instead of doing Items.ITEM, you will have to do Items.LONG_ENUM_NAME.getItem() in EVERY damn place in your code... great!

Aside from that - writing such systems for simple stuff is retarded - anything out of ordinary will still require writing few more lines of code. :P

 

My piece on this. 8)

1.7.10 is no longer supported by forge, you are on your own.

Link to comment
Share on other sites

1. While ModelLoader is not @SideOnly, it actually is for client use only and I personally would place it in client only class (or client proxy) or at least call it from one (client proxy). :)

I said it is only called from client proxy.

 

3. This is probably the worst: :P

if(INspecial == 0)
                this.item.setCreativeTab(Main.modCreativeTab);

Just do ModItemsEnum.this_is_test.item.setSomeThing(stuff) from preInit.

This is only called to make special types of items, I dont want to add 10 items and get them in a tab and I dont want to make 10 items

and not get them in a tab, This is an automatic way to do special things to items using the enum constructor

 

4. Oh wait, it (above) isn't - From now on, instead of doing Items.ITEM, you will have to do Items.LONG_ENUM_NAME.getItem() in EVERY damn place in your code... great!

Aside from that - writing such systems for simple stuff is retarded - anything out of ordinary will still require writing few more lines of code. :P

Calling for an item using its registry name and adding a

getItem()

really isnt that bad for the nothing you do to add the item..

it wont change much at all...

 

 

 

2. You already made up your mind, why keep asking? If it works, it works (doesn't mean it is any better than any other thing you could write and most certainly it isn't clearer this way).

 

You're right!

 

LOCKED

Doing stuff n' things

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.

Announcements



  • Recently Browsing

    • No registered users viewing this page.
  • Posts

    • They were already updated, and just to double check I even did a cleanup and fresh update from that same page. I'm quite sure drivers are not the problem here. 
    • i tried downloading the drivers but it says no AMD graphics hardware has been detected    
    • Update your AMD/ATI drivers - get the drivers from their website - do not update via system  
    • As the title says i keep on crashing on forge 1.20.1 even without any mods downloaded, i have the latest drivers (nvidia) and vanilla minecraft works perfectly fine for me logs: https://pastebin.com/5UR01yG9
    • Hello everyone, I'm making this post to seek help for my modded block, It's a special block called FrozenBlock supposed to take the place of an old block, then after a set amount of ticks, it's supposed to revert its Block State, Entity, data... to the old block like this :  The problem I have is that the system breaks when handling multi blocks (I tried some fix but none of them worked) :  The bug I have identified is that the function "setOldBlockFields" in the item's "setFrozenBlock" function gets called once for the 1st block of multiblock getting frozen (as it should), but gets called a second time BEFORE creating the first FrozenBlock with the data of the 1st block, hence giving the same data to the two FrozenBlock :   Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=head] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@73681674 BlockEntityData : id:"minecraft:bed",x:3,y:-60,z:-6} Old Block Fields set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=3, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} Frozen Block Entity set BlockState : Block{minecraft:black_bed}[facing=east,occupied=false,part=foot] BlockPos{x=2, y=-60, z=-6} BlockEntity : net.minecraft.world.level.block.entity.BedBlockEntity@6d1aa3da BlockEntityData : {id:"minecraft:bed",x:2,y:-60,z:-6} here is the code inside my custom "freeze" item :    @Override     public @NotNull InteractionResult useOn(@NotNull UseOnContext pContext) {         if (!pContext.getLevel().isClientSide() && pContext.getHand() == InteractionHand.MAIN_HAND) {             BlockPos blockPos = pContext.getClickedPos();             BlockPos secondBlockPos = getMultiblockPos(blockPos, pContext.getLevel().getBlockState(blockPos));             if (secondBlockPos != null) {                 createFrozenBlock(pContext, secondBlockPos);             }             createFrozenBlock(pContext, blockPos);             return InteractionResult.SUCCESS;         }         return super.useOn(pContext);     }     public static void createFrozenBlock(UseOnContext pContext, BlockPos blockPos) {         BlockState oldState = pContext.getLevel().getBlockState(blockPos);         BlockEntity oldBlockEntity = oldState.hasBlockEntity() ? pContext.getLevel().getBlockEntity(blockPos) : null;         CompoundTag oldBlockEntityData = oldState.hasBlockEntity() ? oldBlockEntity.serializeNBT() : null;         if (oldBlockEntity != null) {             pContext.getLevel().removeBlockEntity(blockPos);         }         BlockState FrozenBlock = setFrozenBlock(oldState, oldBlockEntity, oldBlockEntityData);         pContext.getLevel().setBlockAndUpdate(blockPos, FrozenBlock);     }     public static BlockState setFrozenBlock(BlockState blockState, @Nullable BlockEntity blockEntity, @Nullable CompoundTag blockEntityData) {         BlockState FrozenBlock = BlockRegister.FROZEN_BLOCK.get().defaultBlockState();         ((FrozenBlock) FrozenBlock.getBlock()).setOldBlockFields(blockState, blockEntity, blockEntityData);         return FrozenBlock;     }  
  • Topics

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.