the mod authors DON'T SET THE ID FOR THEIR BLOCKS anymore, the only thing that does conflict now is code and how the mod edits the enviorment or dimension ids which are usually set in the configs
The ids are set to the blocks when the game is loaded, the mod and forge dont set the id's it just randomly given to the mod by forge upon load
theres no order to it, otherwise different saves would be swappable because they would have the same id's, its random
If they empties out the insides of blocks and items, mods would be about 50+% less laggy. All you see is the outside of blocks and such.
They way i understand ids to work is as such Forge detects mod a has x items Forge assigns a random grouping or ids to mod a Forge detects mod b has x+1 items Forge assigns a different grouping of items to mod b..
Just make a decocraft pack, so the Laggy spawns can spread to the rest of the world - Plus MYM originals dont last very long unless it has appropriate advertising
Here's how the standard item-id's work in forge, using my own code as an example: In Main/Common Proxy Code: @EventHandler public void preInit(FMLPreInitializationEvent event){ saligia_Items.registerItems(); } In the main-item class Code: public static void registerItems() { ItemList.add(SinDagger = new ItemSinDagger(Soul).setCreativeTab(saligia.MatryoshikaTab)); for(Item Item:ItemList){ GameRegistry.registerItem(Item, Item.getUnlocalizedName()); } Nowhere do I use anything to set the actual item-id when registering, but as said, this is the standardized registration of items. Blocks follow the exact same concept. Forge injects the new items/blocks into minecraft one by one, following alphabetical order. Thus, mods starting with letters in the farther end of the alphabet usually get higher id's. However, if you want to give out a huge middle-finger to all other mods, you can indeed force the item-id's for an item or block. The standardized method I showed you will however work around that id, and continue past it. The only issue crops up when Mod A + Mod B both force the same id for their items. However, doing things like this is heavily frowned upon, and is really only done by those who really dont want their mod to work along with other mods (<cough>Followers of the Better than wolves ideology</cough>) Oh, and actually, Forge does NOT need mod-authors permission to edit source-code or specialize forge code to walk around issues in a mod Mojang owns all minecraft code. Anything related to minecraft code, like the Forge API & mods, are dependent on mojang's code, which means mojang has absolute rule over all mods. If they wanted to, they could literally integrate a mod into vanilla, and sell it as their own, as the mod is as said, based on their code. This follows up for Forge. Any mod made using the Forge API, Forge automatically has permission to edit as they like, as it is based on their API, their code to ASM-inject new things into Vanilla Minecraft. Hierarchy is thus as followed: Mojang > Forge > Mod-Author > Anyone else. Forge however does not really showcase this power, and instead expect mod-authors to follow simple guidelines to assure that compatibility exists.
actually, was looking back, looks like you're wrong shown right here GitHub - MinecraftForge/MinecraftForge: Modifications to the Minecraft base files to assist in compatibility between mods. that it's open source, and therefore they retain no rights to the actual source code other than any deverations must also be open source
Don't pick on him. The unit earned amount of hate that man gets is overwhelming. He feels that you should not change something he made. Just because he knows how to stop people from messing with his code does not make him wrong. Haters going to hate. These are called configuration, not changing the code. Slight difference.
I chose reika because i knew the outcome was incessent RAGE, i know why he doesn't like it, i didn't need to know that