salvestrom

so here's the last big update i need to make for myMod. #AlmostDone. As far as I can tell, only the Item class for my weapon will carry forward from 1.7.10, so I'm basically looking for a rundown of what I'll need now instead.

I was using Items.written_book as an icon for some achievements during 1.7.10. in 1.9.4 doing so puts up a missing texture icon. item.enchanted_book, item.book and item.writable all can be used correctly. go figure. sounds like a lost cause, to me.

thanks for the help thus far. your above post is taking me into pretty deep waters from my point of view, though. although it would be really great to allow the books to be translated into different languages, i'm trying to stay focused on getting my mod updated to 1.9.4+. i'm going to give the custom lootfunction a shot first. With this in mind, how do i get the game to use my custom function class? i found these in forgehooks: public static LootEntry deserializeJsonLootEntry(String type, JsonObject json, int weight, int quality, LootCondition[] conditions){ return null; } public static String getLootEntryType(LootEntry entry){ return null; } //Companion to above function the former is called in LootEntry#deserialise, the latter in lootEntry#serialise

ok, let me see if ive got the logic clear here. i create a custom lootfunction. the function needs to be able to distinguish which book is being specified. then, in the lootFunction#apply i can call the nbt for that book and apply it to the passed in stack before returning it. the nbt will still actually be set in the bookScale.class? i wonder. what if i set the method apply to create a new itemstack right there depending on the getMetadata of the passed in stack and return that? eg. if(stack.getMetadata() = 367) return new bookScale.eastScale;??

sorry, what i meant was a custom type. the issue lies in the type being an item. calling getItem on bookScale will not return any of the actual books. adding the nbt directly in the loot table seems overboard as a solution, is all. its about 30+ pages across 4 books and multiple loot tables. if i need to change anything in any book, all those files need to be altered. i know loot tables can be nested, but that doesn't replicate simply adding an item to an existing loot table - if the nested table has multiple rolls it will do all those rolls, each time it gets selected. hmm. as i type, i think i know a way around that. so anyway, yeah. custom type? also, if i set the nbt in the loot table, id still need the nbt in the bookScale.class for the creative tab.

can i create a custom function that accepts an itemstack?

changing the field to bookScale throws up a null pointer at the setItemDamage line.

I've had the field for the subitems set every which way over the course of the orginial mods development. i dont recall if using the bookscale instance actually works. ill try it. in the mean time, regarding the nbt function for loot tables, are you talking about creating a custom loot tag?

I may have finally run aground with the way my pre-written books are added. The loot table entry below only produces an item for the bookScale class (also below). the itemstacks have no unlocalised name so I cant reference them directly as a string. elsewhere in the code, I can reference the subitems, via "bookScale.eastScale" or "bookScale.eastScale.getMetadata()" which is how I was doing it when loot tables were handled directly in code. is there a way to add items to loot tables in the code still? The book in the loot table: The book class (chopped down to remove all page data):

its as if the rotation is being applied, but the texture doesnt know how to apply to the "angled" surface and stays at right angles. this suggests i'm missing something related to textures but i cant find any indication that changes are required in the block model file and none of the syntax variations ive tried have worked.

"rotation=1": { "model": "thejungle:ancientSkull", "transform": {"rotation": {"y": -22.5}}}, the above rotates and grows/shrinks the textures, depending on the block face, which is weird as well as unhelpful. i've tried leaving out the transform tag and/or using post-rotation instead of rotation, but that accomplishes nothing. there are no errors in the json, or in the console. textures are currently being handled in the model file.

This, at least, doesn't work, as the Forge class also makes the call to ModelRotation which is where the 90 increments are hard coded. is there a tag i should be using instead of "y" ? i was unable to match the syntax used in the documentation. eg " "rotation": { 0: { stuff here "produced an error.

updating from 1.7.10 to 1.9.4, i had/have 4 blocks with 16 point rotational placement, like skulls, banners etc.. advised to move away from tesr's for such things I encountered some challenges. the first is that blockstate jsons only recognise angles in multiples of 90. In order to get to 16, i had to create 4 block model files in which the skull element would be given an additional rotation, which is limited to being 22.5, 45, 0, -22.5, and 45. So, my 16 rotation variants are grouped into 4s, each group specifying rotations of 0, 90, 180 and 270 for 4 different models, that apply element rotations of 22.5, 0, -22.5 and 45. It isn't surprising that skulls are still handled by tesrs in vanilla. Is there another option. Will an obj model avoid both the tesr and the json?

dont worry, you'll soon chew through those errors. i had 4600, and that was just the ones elipse could display. take a look at the renderDragon file, specifically the method for renderCrystalBeam. this contains the new way to setup the tesselator as well as show you how addVertexWithUV was replaced.

So a funny thing happened on the way to the forums... While compiling the information you asked for I saw I had made a mistake during my prior attempt to create individual renders for the books: i was passing the meta as 0, not the set item damage. doing so, and tweaking the item passed resolved the issue. /hug disen here's what you asked for, anyway: the corrected renders: registerRenderWithMeta("east_scale", bookScale.eastScale.getMetadata(), bookScale.eastScale.getItem()); registerRenderWithMeta("west_scale", bookScale.westScale.getMetadata(), bookScale.westScale.getItem()); registerRenderWithMeta("north_scale", bookScale.northScale.getMetadata(), bookScale.northScale.getItem()); registerRenderWithMeta("south_scale", bookScale.southScale.getMetadata(), bookScale.southScale.getItem()); public static void registerRenderWithMeta(String string, int i, Item item) { ModelLoader.setCustomModelResourceLocation(item, i, new ModelResourceLocation(References.MODID + ":" + string, "inventory")); }

nb: there are 4 books total, with over 30 pages between them. this is just the first page of two. to show how it all is setup. The only actual issue i have with the code is I can't get them textured ingame. under 1.7.10 the sub items simply took the appearance of the written_books without my needing to do anything. My attempt to register separate renders for them did nothing. (i think because the renderer needs an item, which is just a written book, so im effectively registering a render for the vanilla item, not my prewritten book) I found this code over 18 months ago and have never been entirely happy with it even though it worked fine, barring one oddity only encountered if taking books from the creative inventory after acquiring a book in a normal way, which was wierd, but non-game breaking and rare. In any case, swapping it for an enumerator seemed like a good idea at this point. this went fine, allowing textures to apply, but I've no idea how to apply the nbt data to the variants which arent itemstacks. I'm fine with whichevers best or easiest to resolve.

i had a similar issue with tile entity rotations not being saved and the block just pointing north on load. i made some changes based on an example i was able to find. primarily adding a getter and setter, rather than calling the variable directly and checking if the tagcompound.hasKey before setting it in the readfromnbt. I don't know why either would make a difference, but one of them, at least, solved the issue.

i agree that techne is/was hell on earth for building an entity model. when it came time to export due to the apparent bugginess of the inbuilt child model stuff, it was preferable to set childs post-export which was quite the fiddly task. but it got the job done and was definitely off minecraft. i found a post that said toolbox2.0 can import techne and export obj. others may find this useful while transitioning.

as far as i can tell techne is specific to java. im not sure about the turbo option. i've stuck to basing models on blocks so far. the mc wiki has a good list of model makers, but do you know of any that will load a techne model, which i could then export?

yeah, im okay with the door functionality for something like the book. the small skull and altar can be converted easily to json, i think. the remaining tesrs ill look into recreating with an obj. wavefront seems to have come up alot. ive been considering animating the altar, having it bob about, but i'd rather finish the conversion to 1.9.4 first.

I still require the information asked for in the op, regardless of whether any of these blocks should stay as tesr.

From this image, I'm only attempting to update the dinosaur skull; the others are awaiting the outcome of this conversation. I realise that the alter block, particularly, can be easily converted to json, since its just a 14x14 block hovering off the ground, with no attached meta (i had half a plan to make it a furnace type block but that wasn't essential to the mod). The brazier is a complex model with a lit and unlit state that's still handled in the 1.7.10 fashion. The other tesrs have 16 rotation points, but no animation and dont change once placed. none of these are particular common in the mod - the tyrant skull will only naturally exist once per game world.

I've got two issues here. Today I read the below link, written for 1.8. It eventually states that Forge provides no means to use tesrs as their own item blocks. Is this correct still as of 1.9.4? I'm assuming then, that I need to do something like a door, where the itemblock is a 2d texture. http://bedrockminer.jimdo.com/modding-tutorials/advanced-modding/tile-entity-special-renderer/ my other issue is the game is throwing up model loader exceptions trying to find the non-existant blockstate files, which is handled by the tileEntityRenderer. i've used a custom state mapper before, but have no idea how to set it to ignore the whole lot. ive also been looking into the "builtin" method used to register all the vanilla games tesrs in the BlockModelShape class, but nothing i tried had any affect.

EDIT: having dwelt on the below, i have to ask if you're sure about the registryname in this instance. the slab variants dont have registry names. in anycase at this point the game just wants the name of the blockstate file. calling the registry name is highly convenient, but not essential. the blockstate file doesnt have to have the registry name, the two simply have to match. EDIT: there are two seperate render calls one for each slab variant. its the passed in block that doesnt change. the code was largely created by scouring the vanilla stuff, which uses a string. i say this merely by way of explaining it. i had looked at it after making the changes you suggested above and thought that it seemed identical to the registry name. but theres a snag here. changing the string to block.getregistryname, while not throwing up errors, gives both slabs the same texture in inventory and as an entity item. this is particularly odd as the passed in string does not change, the line in the post above is called only once.

ta. problem solved. the original call was in the init event: the itemmeshers would crash the game if put in preinit. moot now, since i switched t the model loaders which have to be put in preinit. one thing to note, the string below had to have the modid added to completely cure the problem. public static void registerSlabRender(String string, int i, Block block) { //ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block), i, new ModelResourceLocation("thejungle:" + string, "inventory")); }