Draco18s

BiomeGenBase -> Biome (based on my having just looked it up for unrelated reasons)

Crafty.

It does, getSlots . ....How in the hell did I overlook that. I think that entirely depends on how the block handles its inventory. For example, if I have a block like the furnace which I want to have sided access I need to return a different capability depending on the side (or the possibility of inputting to the output slot exists). Ergo: inputSlot = new ItemStackHandler(1); outputSlot = new ItemStackHandler(1); How would I then go about returning both in the case of a null side?

You don't have to. Every ID is unique to the mod, and every mod has their own set of unqiue IDs that will NEVER clash.

Feels like a bit of an oversight that the ItemStackHandler class doesn't have a "how many slots do you have" method, especially considering that it throws a runtime exception if you try to access a slot outside its size. On top of that, there doesn't appear to be a suggested way for a block to tell its own TE to drop all of its contents without performing a cast from TileEntity to something else (either its own TE type or custom interface) as there's no ability to be certain (using generic code) to determine that "yes, I've accessed every ItemStackHandler capability the tile can provide." I mean, I'm fine creating my own helper interface that I apply to my TEs so I can just do this: public void breakBlock(World worldIn, BlockPos pos, IBlockState state) { TileEntity tileentity = worldIn.getTileEntity(pos); if (tileentity instanceof IInvenCapHelper) { ((IInvenCapHelper)tileentity).dropAllItems(worldIn, pos); } super.breakBlock(worldIn, pos, state); } And then manually looping through all the slots my TE knows it has for all of its ItemStackHandler instances: @Override public void dropAllItems(World worldIn, BlockPos pos) { ItemStack stack; //magic number `n` because ItemStackHandler does not have a .getSize() for(int i=0; i < n; i++) { stack = inputSlots.getStackInSlot(i); EntityItem entityIn; if(stack != null) { entityIn = new EntityItem(worldIn, pos.getX(), pos.getY(), pos.getZ(), stack); entityIn.setDefaultPickupDelay(); worldIn.spawnEntityInWorld(entityIn); } } //repeat for outputSlots and any other ItemStackHandler instances } Or am I missing something?

Thanks! Final question: I assume I could get a list of all entities in a specific radius using the EntityJoinWorldEvent and check if they are instance of xyz entity? If so, is it also possible to get their data, e.g lore? if(event.entity instanceof EntityItem) { ... } and entityItem.getEntityItem();//returns the itemstack, which you can then request lore from

And some info here discussing using blockstate json files to define item variants (rather than a bunch of single "variant" models vanilla uses).

To add to that: Adding parameters to a method doesn't make them get filled in by magic. The event object contains all the data you will ever get from that event (and guess what: LivingUpdateEvent contains an entity! The one getting the update!)

The head bobbing.

Likely not related, but You should be using ModelLoader.setCustomModelResourceLocation during the pre-initialization phase instead of using ItemModelMesher#register

The defines go outside all of the blocks in the gradle file, eg: buildscript { ... } apply plugin: 'forge' def apiVersion = "1" def majorVersion = "0" def minorVersion = "0" minecraft { ... }

You don't have an @Instance annotation over a field for your mod class. Your main mod file is likely not receiving the initialization events.

Oh yeah. <tt> is a great tag. Either one is probably fine. API for me just seems "more bigger" than their details there, though this is my first time seeing that. Don't sweat it too much. I'd actually do this: public static final String VERSION = "{@cubexVersion}"; public static final String ACCEPTED_VERSIONS = "{@mcVersion}"; // only if I wanted it to only work for the current version Which matches the gradle file: def cubexVersion = mcVersion+majorModVersion+"."+apiModVersion+"."+minorModVersion+"."+cubexPatchVersion //... replace "{@cubexVersion}:cubexVersion,"{@mcVersion}":mcVersion Just "@cubexVersion" is probably fine (as long as that matches the gradle replace command), but wrapping it in curly braces makes it very clear "this is an external variable."

No there's not because interpolation is handled by the client's motion values.

OHFUCKYES. <3 I've been trying to figure that out for months and never made the connection. Hopefully that'll also make the "could not run project, error in path variable {$project}" or whatever it says (which it does anytime the last thing I did before hitting "run" was "scroll the console," "examine an asset," "examine a vanilla source," "alt-tab" or pretty much anything other than clicking on one of my own java files/packages in the project explorer). Edit: Nope

I know. It was a problem of not being able to see every detail that I needed to see. And I'll do that at some point, but not right away.

Player position is determined by the server. Player motion is determined by the client (and sent to the server which the server then uses to update the player's position). So if you want to use .setPositionAndUpdate you have to do it on the server.

my rundir is "eclipse", yes. I don't know what it looks like for other environements (IntelliJ, etc) Ok, so. The only thing I'd change is drop the mcVersion from your cubexVersion string. That can just be on the jarfile, your mod's version number shouldn't need to be prefixed with that (but it's not hurting anything). I'd probably also swap "major version" and "api version." Your API should be changing less often than the mod itself and you ABSOLUTELY want the api version change to trigger a mod version change.* As for what the replace command does: the paramers passed are comma separated key:value pairs where your entire codebase is searched for the "key" and replaced (before compiling occurs) with the "value." That's why in the code you use a semi-unique string for anything you want to replace. Hence the {@} characters. (Replacing something like "version" would nab string versionNum = ... and make that not compile...on account of now reading String 1.9.4-0.0.1.0Num = ... ). That's just the code tag. I didn't do anything. *You can also do a replacement on your dependency's version numbers! My numbering system ended up being crap, but it made sense when I started ("number-of-times-released (major)"-"internal (major)"-"minor" and regretted it as soon as I had to fix a bug in the API). So you could have an "{@version:api}" string in your "required:after" dependency notation in your @mod and let gradle automatically fill that in when your API changes. Assuming you treat your API like a separate mod (which you should be, so other modders don't need your whole mod in their workspace to integrate with your API).

A lot of things Ok, that came down to realizing that you had a custom model defined in an odd spot that I didn't notice right away. It looked so much like something else that. Urg. So many things can go wrong with this new system, especially when trying to avoid asset bloat (seriously, vanilla has sixty four models for the clock). And half of them don't even generate errors.* Makes me feel like this json model system is built out of magic strings. Which it kind of is, the problem is that it's not well documented so setting up something is either: do it the painful vanilla way or try to examine the code that parses the json files (I tried and couldn't even locate an entry point that I could follow). That whole "abstractions at their core are lies" thing. [me=Draco18s]archives the project in this state so if he ever needs to do this again, he has it.[/me] *This is probably an exaggeration, but the number of times I've gotten purple squares or outright invisible models without a single logged error is about as many times as I've had errors.

Yeah, like I said, I'm not sure what I've done wrong either, only that no errors are logged. I'll digest your code here in a bit. One of the differences is that my enum list isn't going to be used in its entirety: I've got several ore types to deal with, but any given item won't necessarily be valid for all the ore types, e.g. metal nuggets. I don't need to create a Gold Nugget variant item model because that item is already supplied by vanilla. That was why I was using item.getSubItems() rather than enum.values; I want to maintain metavalues across several items. Anyway, thanks for the continued help. Eventually I'll understand how the vanilla systems work well enough to rapidly prototype items like I used to.

It's super easy. I have this in my gradle build file: minecraft { version = "1.7.10-10.13.2.1291" runDir = "eclipse" assetDir = "eclipse/assets" replace "{@version:lib}":libVersion,"{@version:ore}":oresVersion,"{@version:haz}":hazardsVersion,"{@version:wld}":wildlifeVersion,"{@version:ind}":industryVersion,"required-after:HardLib""required-after:HardLib@["+releaseVersion+"."+majorVersion+",]"),"/*{uncomment}":"","{uncomment}*/":"" } That last, monster, of a line is a list of a->b replacements. The variables are set up like so: def releaseVersion = "15" def majorVersion = "26" def minorVersion = "1" //bugpatch or testing versions def libVersion = "a" def oresVersion = "b" def hazardsVersion = "a" def wildlifeVersion = "b" def industryVersion = "a" def prePend = "1.7.10-" def packageVersion = releaseVersion+"."+majorVersion+"."+minorVersion+libVersion+oresVersion+hazardsVersion+wildlifeVersion+industryVersion libVersion = releaseVersion+"."+majorVersion+"."+minorVersion+libVersion oresVersion = releaseVersion+"."+majorVersion+"."+minorVersion+oresVersion hazardsVersion = releaseVersion+"."+majorVersion+"."+minorVersion+hazardsVersion wildlifeVersion = releaseVersion+"."+majorVersion+"."+minorVersion+wildlifeVersion industryVersion = releaseVersion+"."+majorVersion+"."+minorVersion+industryVersion (It is outside of all blocks). I've got effectively six mods in the same environment, but they're all closely related so I like to test them side by side. The last replacement is for a chunk of code that I can compile, but not run in Eclipse because Reika doesn't supply deobf versions of any of his stuff. It was easier to just say "fuck it" and only have the code for release (which now doesn't work anyway, because Reika doesn't realize that APIs are supposed to be a contract saying that they won't suddenly change and cause crashes, not that what I wanted to do in the first place worked anyway because his API was using reflection to access his own methods and was Doing it Wrong).

The reason it is in two places is so that repositories (like Curse) can identify the mod version without having to decompile the java classes. If you want to change it in one place, use gradle's replace feature to do it for you.

I was looking at ItemDye and it forwards everything to a bunch of models. But yeah, I have an enum and the ordinal of each one would be the metadata involved, but I couldn't get things pointed at a block state file in a way that the game liked. I had things going down the same path as the metadata block, but I either got purple squares and no errors or invisible items (the textures in use at the time were vanilla items). It was basically ignoring the "variants" section in the json file, as far as I could tell (as I had one or two matching the variants generated by the code below, but I wasn't getting "could not find variant in file" errors unless the json file itself didn't exist). Anyway, this is the code I have: public void RegisterItemWithVariants(Item item, String registryname, IMetaLookup variant) { super.RegisterItemWithVariants(item, registryname, variant); List<ItemStack> list = new ArrayList<ItemStack>(); item.getSubItems(item, CreativeTabs.SEARCH, list); for(ItemStack stack : list) { registerItemModelForMeta(item, stack.getMetadata(), variant.getName()+"="+variant.getByOrdinal(stack.getMetadata()).name()); } } Where registerItemModelForMeta is that same function being used by the blocks that you had in your code and IMetaLookup is just an interface wrapper around the enum I'm using so I can convert it back into the variant strings similar to the block's "getPropertyString()" call (I pass in MyEnum.ARBITRARY_VALUE and it's just used to access the lookup methods). (JSON file at the moment is set up with predicate overrides, not variants, so not including it). Is the problem the fact that for the item it's looking at "modid:models/item" for the json file (due to item.getRegistryName() and I really need to point it at "modid:blockstates"? TL;DR: I'm basically scratching my head because I'm getting no feedback when something doesn't work.

Makes sense.

This is how I have my build file set up: (Tweaked your paste to match how mine looks) dependencies { compile files('industrialcraft-2-2.2.765-experimental-api.jar') compile files('Uncomplication-1.7.10-0.1.2.1.b71-deobf.jar') compile files('Aroma1997Core-1.7.10-1.0.2.16.jar') }