Everything posted by Draco18s
-
[SOLVED] Multi-layer block not working as intended
$10 says that your texture isn't transparent. I don't see anything wrong with your JSON model.
-
[1.8] What is the replacement for IItemRenderer?
You can also use ItemMeshDefinition and JSON models: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/industry/item/ItemCastingMold.java#L80
-
Block Transform doesnt work.
JSON transformations are only X and Y, it assumes that Z rotation is just a combination of X and Y (because North is basically the same as East)
-
[1.12] Okay, this recipe system is ridiculous
It's a registry name, name it whatever you want, just like you would a block or item.
-
How do recipes work in 1.12
Expected name at line 15 column 8 path The json is valid JSON but it's missing a required key entry
-
[1.12] Porting from 1.11.2 registry assistance needed
Also no. ModelLoader is correct.
-
[1.12.1][SOLVED] Is it possible to change the rotation point of a OBJ model?
Translate, rotate, translate back.
-
[1.10] [solved]Nullpointerexception when trying to Skin items. (I put it in preinit instead of init)
Loading a world happens waaaaaaaaay after item creation and registration. Your objection is wrong. Your renderer is broken because its happening BEFORE YOUR ITEMS EXIST.
-
Item-Repairing in Workbench
There's already a recipe for combining two identical (and damaged) items. I'd use that class as a basis for creating your own recipe.
-
How to properly disable item on client
You should always register the items. ALWAYS. If you don't want them to be available, don't create recipes for them.
-
Two Questions: CommonProxy Interface or Class? and Unlocalized and Registry Names
I actually utilized the class version structure to create my EasyRegistry implementation before we had the registry events. I'm not saying it was better, but the hierarchical nature of the common periodproxy being a class meant that item registration (GameRegist.register calls) were in a common location and client only aspects were in the client subclass. However, those methods were generic, they contained no references to outside objects (even the static methods only referenced the main mod class in order to get the proxy instance). All of my blocks and items were handled in the main mod class. Making that work with IStateMapper (and a few other things) was a hassle, but I managed it. Unlocalized name might change for subitems. Look at wool for example: each color had a different name, but the registration name is the same for all of them. Using getUnlocalizedName() for the regisrty name makes no sense. Mods should treat their items the same way.
-
[1.12] ItemStackHandler with two different filters
Use two ItemHandlers. Wrap one in this: https://github.com/Draco18s/ReasonableRealism/blob/master/src/main/java/com/draco18s/hardlib/api/internal/inventory/OutputItemStackHandler.java
-
[1.11.2] Ore Gen specific to the different stone variants
Well....a Block will never equal an IBlockState... Also, you shouldn't use getStateFromMeta, use getDefaultState().withProperty(...)
-
[1.11.2] One piece armor.
Nope! The fake-items method sounds pretty reasonable. When it's equipped, shove anything in the other slots to the player's inventory and then fill them with the "fake" items. When any of them are removed (either the fake item gets an "I am in the inventory" update or an "I am an entity item" update) destroy the fake ones and put the chest piece back into the user's inventory.
-
1.12 How to fix these GameRegistry.register
Name it whatever you flipping want.
-
[1.11.2] One piece armor.
You also have a "HJarmor" that should be lower case: GameRegistry.register(HalJordanArmor = new HalJordan("HJArmor", HJArmor, "HJ", EntityEquipmentSlot.CHEST)); This is backwards: this.setUnlocalizedName(unlocalizedName); this.setRegistryName(Main.MODID + ":" + unlocalizedName); You should use the registry name to set the unlocalized name: this.setRegistryName(unlocalizedName); //of course 'unlocalizedName' is a bad name for this parameter now this.setUnlocalizedName(this.getRegistryName()); This appears to be unused: public String textureName;
-
Using a TileEntitySpecialRenderer
He's referring to https://en.wikipedia.org/wiki/Generics_in_Java
-
[1.10.2] Creating NBT files and Writing to them
Thanks. Last time I messed with it was 1.7 and I am not sure where that code is any more. And its been made entirely obsolete since (the purpose it served got written morebetter by someone else).
-
[1.10.2] Creating NBT files and Writing to them
I poked around with this once a while back. There should be an NBTTools or NBTHelper (NBTCompressionTools?) class somewhere that deals with doing the actual File IO. You'd pretty much just need to invoke the methods in it and pass in the NBT and the file path.
-
[1.12] [SOLVED] Exception loading model for variant [model] for item [item]
Well, tecnically it did... The registry name is used as the file name... Changing one to match the other will fix it regardless of which one you changed.
-
[1.12] [SOLVED] Exception loading model for variant [model] for item [item]
Your file is named "strange_plank.json" not "strange plank.json"
-
[1.11.2] [SOLVED] OpenGL Render problems
Where are you doing this, then? Also, you're not binding a texture.
-
Iterating an AOE only effects specifc blocks? [1.11.2]
Character length only matters for Code Golf. That said, if you wanted to use a while loop, you can save characters: Instead of: int x = -aoe; ... { while(x != aoe) { x++; } x= -aoe; y++; } You can do: ... { int x = -aoe; while(x != aoe) { x++; } y++; } By declaring the value at the top of the loop you save having to reset it at the end.
-
Problem with item render (minecraft 1.12)
That's not the full error. There will be another Caused by: entry that tells you what actually went wrong. You also didn't post your updated code.
-
Iterating an AOE only effects specifc blocks? [1.11.2]
Ew. Ew ew ew. Ok, so, 1. for-loops are a Thing. As are negative variables. You don't need those 0s. for(int x = -aoe; x <= aoe; x++) { ... } Two: new BlockPos(x,y,z) (where you're checking to see if the block is stone) != new BlockPos(block.getX() +x, block.getY() +y, block.getZ() +z) (where you are removing the block) Three, BlockPos.getAllInBox(...) is a Thing.
IPS spam blocked by CleanTalk.