Draco18s

I thought that might be true when I posted, but I wasn't sure. 256 per mod was always "more than any mod will ever need." Even Mo'Creatures only adds fifty eight.

Cool, thanks Choonster. Shame the oredict isn't ready / populated when recipes get parsed or I could pass the oredict value straight to the constructor and skip over the getRecipeOutput and getCraftingResult overrides entirely.

HA! REPLICATED. Had it happen a minute ago and caught it before I posted (and with a post I didn't need to make because I forgot something dumb)

Pretty much. 256 entities per mod.

You have a couple of these: And then this: Plus, you haven't shown any code.

What you're asking for doesn't make any sense at all. The server doesn't know anything about textures. And if the server isn't Forge, then there's no Forge mod you can make that will affect anything on the server.

Think about this for a second: Distance traveled by rail, say. You want 2 different achievements, one at 1,000 blocks and one at 10,000. Which would you rather do: if(distance > 1000) { OneK.trigger(); } if(distance > 10000) { TenK.trigger(); } Where OneK and TenK are two separate classes: one that checks for the trigger "oneK" and the other checks for "tenK". Or: OneK.trigger(distance); TenK.trigger(distance); Where OneK and TenK are the same class with the value that they trigger at controlled by a resource-pack-modifiable JSON data value? (Now, 1K and 10K distance traveled probably shouldn't ever be modified from those values, they wouldn't make sense, but the idea that achievement trigger conditions are generic and resource-pack-modifiable in the general case has a pretty strong argument: afterall, the triggers on recipes work this way and I don't think you'd argue for chanting each recipe trigger to be a unique class). It's literally ten lines of code. 1, 2: the test 3, 4: the trigger 5, 6: the deserialization 7,8: the constructor 9: the class field 10: the place where you call trigger() (which you'd have to write anyway) And every single piece falls from the previous one. You edit the test to take a different parameter? Trigger throws an IDE red underline error on trigger. So you fix that. If you aren't reading any values from the JSON file, that's all you need (I have one like that). If you are reading a value from the JSON file, you start again in test(), checking against a non-existent field. That's an error, so you create the field and assign a value to it in the constructor. Now the deserialization has a red line, so you parse some values from the JSON object. 99% of what you do is either going to be a simple object (float, int, string, enum) or already done in an existing trigger (block, item). You add those lines, pass the values to the constructor....and you're done. You've touched literally 10 lines of code for a single configurable value. Each additional value only adds 3 lines (as the remainder touch lines that would be touched for a single value anyway).

(You can pass null as a facing, by the way. That's what @Nullable means. null is typically used to represent an "internal" or "self" access.) Did you ever have the inventory size as being only 1? Because if you did, and you saved that world, and you're reloading that world, the deserialization process is reading an inventory of size 1 and overriding your new with size 5.

I used to register some recipes that take an input supplied by my mod (the item always exists) and make the output the first item of a named type pulled from the ore dictionary. These recipes are TinyDust -> LargeDust conversions and I only bothered supplying large dusts for ores that their own mods did not supply a large dust for (e.g. IC2 supplies tin and copper, so my mod didn't need to). Now that 1.12 has rolled around with its JSON recipes, how can I replicate this feature?

You can do more complicated things as well, the magic happens inside the trigger() and test() functions. Basically just make the test function check against whatever values you want to pass when you call the trigger in the code. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L83-L85 It'll throw errors, of course, all you have to do is work backwards to fix it. test() is called from trigger(), so fix that next: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L116-L120 Now your trigger call happens wherever you want to trigger the event from, just have to pass in the appropriate values. If you want to let the json control some values, then head to the instance internal class, declare the class properties to hold them (and which you may already have in your test() method!) https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L74-L75 And then head over to deserialize: https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L69 Lastly, you need to pass the deserialized values to the instance constructor. https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/BreakBlockTrigger.java#L76-L117 And save them to the fields you created https://github.com/Draco18s/ReasonableRealism/blob/1.12.1/src/main/java/com/draco18s/hardlib/api/advancement/DistanceTraveledTrigger.java#L78-L80 Add whatever's needed. I used an enum and used a string->enum parse already built into Java. If you want blocks/blockstates or items, look at the existing vanilla classes that use those and just copy-paste the deserialization bits over. Other types should be pretty easy.

Well, one point of using BlockLeaves as a base is that it already has a DECAYABLE and CHECK_DECAY properties. You don't need to recreate them. (Seriously, look at BlockLeavesNew: it doesn't have a DECAYABLE or CHECK_DECAY declaration) Does your log block override canSustainLeaves()? Also, be sure to generate a new world. Your existing leaves aren't going to load from disk properly.

The two functions need to mirror each other. Otherwise you'll put down green wool, save the game, load the game, and have pink wool. Here's vanilla's BlockNewLeaves: public int getMetaFromState(IBlockState state) { int i = 0; i = i | ((BlockPlanks.EnumType)state.getValue(VARIANT)).getMetadata() - 4; //you don't need this and that's fine if (!((Boolean)state.getValue(DECAYABLE)).booleanValue()) { i |= 4; //yours says i = 0 } if (((Boolean)state.getValue(CHECK_DECAY)).booleanValue()) { i |= 8; //yours says i |= 4 } return i; } Also, there's literally no reason not to extend BlockLeaves and let it do most of the work.

int i = 0 ; if (!state.getValue(DECAYABLE).booleanValue()) { i = 0; } i will never be 1, DECAYABLE is not encoded in metadata. if (state.getValue(CHECK_DECAY).booleanValue()) { i |= 0x4; } DECAYABLE, (meta & 0x4) == 0 Here you check bit 4 (where you encoded CHECK_DECAY) and if that bit is 0, you set DECAYABLE to true. CHECK_DECAY, (meta & 0x8) > 0 Here you check bit 8 (which is never set) and if set, set CHECK_DECAY to true.

You do not appear to have getMetaFromState or getStateFromMeta methods.

check_decay=false,decayable=true does not equal: check_decay=false, decayable=true

Show the error.

Ok, why is this: https://github.com/Blitex/moreplayermodels/tree/master/src/main/java/net/minecraft/client/renderer/entity Inside the net.minecraft package? Much less inside client entity rendering? Then you have a chunk in GlactiCraft https://github.com/Blitex/moreplayermodels/tree/master/src/main/java/micdoodle8/mods/galacticraft/api/client/tabs And you've duplicated all of MorePlayerModels (pretty sure you shouldn't be doing this) https://github.com/Blitex/moreplayermodels/tree/master/src/main/java/noppes/mpm I'm not sure where the heck your code actually is.

For blocks, you need a custom IPerspectiveAwareModel and IStateMapper. Check out GrayGhost's Camouflage block https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe04_block_dynamic_block_model1

Show what you've tried.

Jesus mother frakking Christ. You need to add that function to your class and tell the game about your state objects.

Nope. https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/ores/block/BlockAxel.java#L60-L63

Also, CHECK_DECAY and DECAYABLE already exist in BlockLeaves. Rather than create a new property with the same name and same allowed values, just use the one that already exists. (It's a compatibility thing: if some other mod wants to manipulate with states of your block, but your block doesn't have the desired property (because you created a new one), they can't fiddle with it).

(Because white is black and black is white; no really, the metadata sequences are in reverse order...)

You need to call ModelLoader.setCustomModelResourceLocation() for it. I don't know how these work: https://github.com/linkisheroic/rosetteMod/blob/master/main/java/com/natura/rosette/block/RosetteBlocks.java#L105 registerItemModel() doesn't exist in your code and it's not vanilla/forge.

Regeneration specifically requires certain "time remaining" ticks to be hit in order to produce any healing factor. Reapplying the potion every tick is the wrong way to do this. Instead, apply the potion effect for a 1 second duration, then check to see if the player has the potion effect, if they do not, reapply it.