ConfusedMerlin

Good evening, I assume any moment the guys with the real knowledge will show up, but until then I want to ask you why there is a closing bracket See it? Right in front of the png. I do not know if this is an copypaste-error, but you might have a look aaaat... *thinking* the models json or the blockstates json. Well, I'm not very long in this business as one might suspect, but you should figure out whats up with the bracket anway. Now good error hunting.

Gooood Evening, It was kind of an odyssey sometimes, but I got that multiblock-stuff done. Part of. I removed the bigger-than-1 bounding boxes and (damn it, why didn't I got the idea to look there by myself in the first place? ) tried to recreate what happens inside ItemDoor's methods. It's not as fool-proof as the vanilla methods, but it does provice the actual model and the invisible multiblock to claim the space above. Yeah, another picture Well, it isn't as transparent as it will be one day, but I think switching the texture once all fits will be the most minor task on my list. Oh, I do wonder one thing - if its so important to keep the collision boxes this small, wouldn't it be useful to have forge throw one of its "this is bug, contact the author" messages if one of these appears? After all, there are sure others out there who will went the same way as I did because they are unaware of the problems the big collision box does create.... And I think one of the more important lessons learned was that the minecraft world as forge does see it does not consists of blocks, but of positions with IBlockStates that get a given state out of the registered blocks list. By the way, I was about to start yelling at the general direction of my PC because I didn't found the way of choice to get a block not available during the onItemUse Call (like my multiblock), but after trying adventurous ways of getting it from several registries (don't... ask, seriously), I had a bright moment and found a static Method inside Block.class (Block.getBlockFromName) that will provide the Block I want if I offer it the "modid:blockname" String. *sigh* Is this the recommend way to do this? Some other things restrain putting the "solved" Tag to my topic. I do wonder where I should keep the information about the quite important question "what locations in that world do belong to what multiblock-structure"? I do have a small container class ready for use, but right now I didn't found the place where it should belong to. That class is just an ArrayList with all positions that belong to the multiblock - plan is to have the IBlockState at a given location holding a reference to that Container, which will use its destroy method to turn all its other mutliblocks to Air if one of the multiblock-blocks get destroyed somehow. Or to put it more simple: When I leftklick the bottom of the rocket, the transparent "multiblock" still remains, and via versa. I'm aware that I have to connect the two places to destroy the other one by myself, but I wonder what would be a good location (class-wise) to store the informations. Vanilla Beds and Doors just get their location, their rotation and their part (upper and lower or head and foot) and figure out where the other one should be (which works usually). I hope I can store all the mutliblocks belonging to one structure somewhere... which will be incredible handy if I once tackle huge multi block structures. Curious Greetings, Confused Merlin

Lets see....I tried getting the AABB from the block class using the constructor (same error as before), and tried to designate it manually inside the tileentity class (same error) aaaand... using the way it had been done inside the waystone mod (return new AxisAlignedBB(pos.getX(), pos.getY(), pos.getZ(), pos.getX() + 1, pos.getY() + 2, pos.getZ() + 1);) Same effect sadly The upper half can be covered with blocks put sideways to walls; the bounding box still does look the same as before, but I guess there isn't anything that should change after all. By the way, I cannot interact with the upper half, expect for walking over it in a correct manner.

Good evening, as you might know, I've prepared some pictures again. Okay, its just the first picture, because I found something inside my own blocks that does help to visualize the problem in better way than the vanilla block I had in mind.That cyan block comes close to to beeing batsh!t crazy stuffed with (unnecessary) settings, but he is great for visualization. Also note that its bounding box is a tight bit smaller than these of usual blocks, but it does disappear inside the... objects bounding box, while still covering its upper half. So, what do we see there? Its... a rocket. Yes, I know, I must put a label on it because it does look rather stupid, but its surprisingly hard to do the low-poly modelling needed for minecraft; the first draft had maybe more vertices than the visible world in my game, but... another topic for another day. But, as on might have observed by now, something is wrong with it. This rocket-like thing does originate from Blender, so its a 3d model exported as an .obj file (with its .mtl file too) and except for some less visual pleasing edges everything is alright with its appearance. But it does have a problem: it takes double the height of a usual block. To enable it doing some more interesting stuff later on I had to make a Tile-Entity out of it, and while its still unhappy with the missing pieces of code needed to save its current state, minecraft seems to be rather happy with it. (forge less....). Oh, if this is of any importance, I used the hasTileEntity() and createTileEntity() functions as advised somewhere in this forum instead of the old methods you might find in older threads about this topic. It... seems to work well this way. But (!) by accident I had once a piece of building material attached to a block which was located next to the upperhalf... and it did cover the upper half completely. First I was like "oh dumb me I need to adjest the bounding box", so I went out and adjusted the AABB to fit the dimensions of that rocket. That fixed the player walking though the upper half, but not being able to place blocks that will cover up the upper half. I asked the internet for help, which replied "use multiple blocks" and "take an example for this looking at the vanilla bed and door". That did sound promising, but I soon realized two things: I'm not able to spot the piece of code who does handle the placement of the second part after all. Everything they do in their examples and vanilla code is done with json Models. Even the tile entity parent they used in their json model files seems to be unavailable for me. So... I started wondering and asked myself "how do mods like immersive engineering do this?". I remembered another mod... Waystones.... which does use objects of a (kind of) similar shape (you guessed it - its waystone). And it does have a github and is pretty small, so it wasn't as confusing as other sources. It took some time, but I thought I found the piece of code responsible for handling the double block creation (the "onBlockPlacedBy" Method). So I tried to recreate what was done in the Waystone-Mod, but ended up with... well... the second picture. It does have its charm, because it does look like a proper multi stage rocket, but after all this is supposed to be a solid booster science package delivery vessel (or a "sounding rocket", if you are interested in that kind of stuff). So the second half isn't needed. The guy who does provide waystones source did left out his models (or I didn't find them), so I could not take a peek to find out what his model(s) are made of, but after I didn't find a .obj in the pathes names, I think he is using .json too. So this approach wasn't as successful as I did hope for. *sigh* I do hope that I don't need to create .obj models which have been separated into block sized chunks to have them appear in the game correctly. You know, there is a... quite big multi block structure awaiting further success in modding, which would be a giant pain to cut in parts. I do hope there is another way to get this done. So, to condense my writing to a proper question: What needs to be done to have this two block high obj model appear correcty when placed? If I might put in a guess, I think it will boil down to have all the area which isn't the place the tile entity was put to ground in the beginning get covered with invisible dummy blocks. If that's the way it needs to be done, then whats the proper way to represent this inside the code? Please do not just point out to Bed and Door, because I already failed to find the place in the code where this happens. Its all about foot and head halves or upper and lover halves and how they interact, but where by all enderpearls does the creation happen? confused Greetings, Confused Merlin

Hi there, EDiT: So, I have to pull back my "having probably the same problem" reply, because I found what was wrong at my side: î Thats right. As some might have noticed, my mod may end up with something that starts with "ianus". And while being sad that nothing worked at my side, I noticed that the blockfile.json for that .obj I created was oddly out of sorting, at the very bottom of its folder, while it should have been somewhere in the middle. Turns out, I somehow hit the stargate-key at my keyboard when writing the blockstates filename, so instead of i I got an î .... now try to spot this with monitors keep on growing and growing. Anyway, one thing from my original post remains: Regarding the "no error log", I had a similiar experience, but than one of the veterans from forge pointed out that I do use a forge version where the model problem log output was broken. At the moment my forge is... 2402. You may try updating, if you haven't, to get some more error output. Now... hoping for helping hands too, Confused Merlin

Good evening, it's me again. This time I have something... well, its a bit stupid I think. The testing environment: Okay. Again, there is a picture to look at. That red cross is made out of custom blocks, which are no full blocks (as one might have expected; this isn't a texture trick). Their aabb has been resized to fit their visual appearance, aaand... north is up. Oh, these blocks are non solid, so you can walk through. The target situation: Every entity that collides with the block should be pushed back (force may vary) in the general direction it came from, or better: at a rough 90° angle from the surface it touches. The experiment: I found onEntityCollidedWithBlock() and started fooling around with whats possible with this function. And somehow it condensed towards some kind of repulsing block; like the slime, which you can use for high-jumping. But from all sides. So I could not reuse the onLand() Method, or what its name was, but instead went to look to get this done using onEntityCollidedWithBlock(). I tried out a lot of things; firstly I misunderstood what the vector methods where for. When hearing "vector" I think of some kind of movement, but after I teleported myself around to crazy extends, I realized that it might not be the movement-redirection I was looking for. Than I found the motionXYZ fields, and the moveRelative() method. Last one was foolproof to use, but when I looked sideway and tried to apply negative forward momentum, my player got accelerated alonside the "wall" of repulsing blocks. I used this to send Zombies to the moon, by digging a 3x3 hole with walls out of repulsor blocks and let 1x1 free in the middle, used an egg at the first block and... wheeeeeeeeeeee. Ehem, back to topic. After "moveRelative() didn't yield the result I hoped for I went back to the three motion-fields. Because I still suck working with the blocks facing-stuff, Went for something else and got the coordinates of the block and the entity colliding with it, looked for the difference (block - entity) and got usually a value of 1 or -1 for x, y or z. After finding out, that you move with negative preposition when going towards the smaller coordinate value and via versa, I just added entityIn.setVelocity((holoX-entiX)*-1,(holoY-entiY)*-1,(holoZ-entiZ)*-1) Here is that method - the super-call seems not to have any influence to the success or fail @Override public void onEntityCollidedWithBlock(World worldIn, BlockPos pos, IBlockState state, Entity entityIn) { double inputX= Math.round(entityIn.motionX*100)/100; double inputY= Math.round(entityIn.motionY*100)/100; double inputZ= Math.round(entityIn.motionZ*100)/100; double entiX = entityIn.getPosition().getX(); double entiY = entityIn.getPosition().getY(); double entiZ = entityIn.getPosition().getZ(); double holoX = pos.getX(); double holoY = pos.getY(); double holoZ = pos.getZ(); double outputX=(holoX-entiX)*-1; double outputY=(holoY-entiY)*-1; double outputZ=(holoZ-entiZ)*-1; try { worldIn.getPlayerEntityByName(entityIn.getName()).sendMessage(new TextComponentString("holo: x: " + holoX +", y: " + holoY + ", z: "+ holoZ + ";")); worldIn.getPlayerEntityByName(entityIn.getName()).sendMessage(new TextComponentString("enti: x: " + entiX +", y: " + entiY + ", z: "+ entiZ + ";")); worldIn.getPlayerEntityByName(entityIn.getName()).sendMessage(new TextComponentString("dif: x: " + (holoX-entiX) +", y: " + (holoY-entiY) + ", z: "+ (holoZ-entiZ) + ";")); worldIn.getPlayerEntityByName(entityIn.getName()).sendMessage(new TextComponentString("input vel: x: " + inputX +", y: " + inputY + ", z: "+ inputZ + ";")); worldIn.getPlayerEntityByName(entityIn.getName()).sendMessage(new TextComponentString("output vel: x: " + outputX +", y: " + outputY + ", z: "+ outputZ + ";")); entityIn.setVelocity((holoX-entiX)*-2,(holoY-entiY)*-2,(holoZ-entiZ)*-2); }catch(Exception e){ //just keep on going in case something is going insane } super.onEntityCollidedWithBlock(worldIn, pos, state, entityIn); } The problem: Okay. That should do the trick, I think. Lets say, in theory that seems to work. In "reality" (or in game) something unexpected does happen: when touching the blocks from north or west (moving to south or east), I just clip though the blocks (that looks kind of strange), while the "debugging output" to the chat-console tells me, that the "new" motionXYZ should be the correct value. Even more strange, when comming from south to north, from east to west, from up to down (and from down to up... combine both for a grand shaking) the redirection works perfectly. It will keep drops jumpuing until they despawn, or the player jumping until you went off. But these two directions (north->south and west->east) wont work. The best that happens is, that I slowly... warp through the blocks, just to get slinged away at the other side. So... I know this is far from being productive work in any form, but I'm afraid that I need to use velocity and vector handling later to a greater extent, so it cannot hurt to know what one can do wrong or understand wrongly. Greetings, Merlin

Oh... holy enderpearl, Dear Choonster, I'm very grateful that you not just got rid of the models rotating errors, but also found some other things that needed improvement. I have to admit that I pushed a version to git yesterday which was a "oh dear its this late already lets push everything in case my hdd won't wake up tomorrow" commit - the missing ; might have been part of it. Anyway... IT WORKS. wuhu! As expected, the rotation is... well, I need to rotate the rotation angels counterclockwise to have them align correctly. Something like this. So, thank you again. Regarding your comments - I removed the item model to be honest. And now I do see the error-messages from the console log... (no item). Hm... just until now I thought all blocks will create their item via the blockitem-class. Well... at least, I think " normal location exception" means that I should put a normal block-variant back inside again. Java-Logger comes from work; when creating this LOGGER field I saw java.util and log4j and went into work-mode. I need to ask what do you mean by talking about "display transformations".... might it the the shift of size and rotation that control how the item does look inside the inventory, the hand, or floating around being dropped? Thats something I came across already, but did't put much attention at it. So again, thank you for you help. Now I'm off again, straight forward the next strange errors (one is already luring behind the horizon in the shape of multiblocks). Have a nice day everyone

Ah, yes, as you did show with your .gitignore. I guess I successful forget them to add to the repository when destroying my .gitignore file. I did as requested; if you time allows, please have another look. EDiT: May I ask if you had any success in pinning down that error?

So... I didn't expect creating a git repository and connect it with an already existing intelliJ project could be such a annoying task in Windows. Anyway, now its done. IanusInc on GitHub. Even the Licence file is in there again *sigh* Anyway, I tried to apply some of your suggestions @Choonster, especially taking from the BlockObserver the Meta Methods and having the FACING Field created in a less complex way. Good news first: it still works, even with the correct facing. Bad news: it didn't fix the facing model variants not appearing. The other suggestions will kept in mind until I'm better at knowing my way around with the forge API one day. All of this does have the smell of "stupid little typo" somehow. At least... the MINGW64 that came with windows git does contain a proper GREP (I hate searchstr or what its name in windows may be). And it did found the text on the not rendering models, which is located inside the blockstate file for that block. Interesting, by the way, was, that the text on the disco-block didn't change to contain the "/block" I added for testing, so its source must be somewhere I'm totally not aware of. Where can I look for this other than the places I did inspect already? But until this mystery has been solved, I will approach multiblocks and other APIs from a pretty distant direction... Greetings, Confused Merlin

Good morning, somehow I feel like some guys are already moaning ("oh no, not this dude again, he writes way to much..."), but I still hope for assistance in pinning down an error that does not feel like its all that hard to fix. These who don't like much text may skip the next paragraph... So I went from registration of items and blocks over recipes straight to custom models with textures. And while this wasn't a cake walk, I somehow managed to bring a blockbench-json-model inside Minecraft, with all textures appearing. I got slowed down because the upper face of the block below that model was always not there, learned about isOpaqueCube and isFullCube (which are deprecated... is there a substitute available, or was that seriously used to "mark" internal functions?), and was thrown off course by facing the facing of blocks. Most examples from mod tutorials are not usable any more or just plain adventurous, but somewhere in this forum someone told somebody else to look at the vanilla way of doing this (the torch), which led me back on course. Still, after finding out that forgetting to assign reactions to directions will cause minecraft to crash with a confusing errormessage, I'm at a point that still manges to evade my abilities to solve modding problems. So what's wrong? The turret I made for testing purposes refuses to use any of the blockstate-models (facing=up and so on) after I finally managed to have the facing I want appear when placing it at a given side of a block. That... sounds confusing. Thankfully, it prints the blockstate it want to use at the invalid disco-block. It looks like somewhere a wrong model-path got inserted, because its missing the "block/" inside the model resource location string. Hm, when reading the last sentences, I have to admit to be not able to grasp what's wrong on my own... so let pictures speak! In case you didn't spot it already, just scroll down a bit. As one can see, it prints a little text at the blocks. That' neat, because I was able to get the correct facing for each direction without having the model appear after all *cough* Still, the most important part is missing. When you look closely at the inventory-bar you might spot something with a big red dot on it (which is inside the characters right hand right now). Thats the block I want to appear there. Whats there is the itemblock which came from the block itself, what should indicate that my model still is valid (and even know where its textures are!). But the facing ones fail to do so. What now... ah, the blockstates! I tried with and without "block/", both didn't work. The path itself should be correct, because in the beginning there was just "normal" inside, which did contain the "block/" in front of the name. And the model showed up correctly. So I hope at least the "model" value can't be critical wrong after all. Okay, juuuust ignore the rotations there... that's something I need to figure out later, when all is on place. I bet everything will be flipped beyond good and evil, so... just don't mind (except if these are the guilty pieces for that problem). What else could be of interest... ah, of course, the logs. Lets see... latest.log doesn't containt anything about ianus_inc_turret, fml-junk-earlystartup just contains the "loading" and "switching numbers" entries, and ... huh, even fml-client-latest just have one entry about recursing (which should be valid) and doesn't know anything about "facing" too. Okay, thats strange. And... seriously, even the console just contains what I did add to log (registering ianus_inc_turret) and don't know any "facing" too. Am I looking at the wrong destinations? Are the logs even up to date? Hm, yes, they are. All I can add is the class belonging to that block. While we are at it, my way of determining the correct facing is open for debate too. It feels a bit stupid to get the opposite facing of the opposite facing, but it yield the correct facing anyway. It may need something more sophisticated in future, but at the moment is seems to suffice. The getMetaFromState and its opposite method do feel kind of wrong too, but I took them from the torch from minecraft and added another case, because "down" is valid for my block. And... id didn't work before I modified it to contain "down" too. Then we do have the FACING variable, which is strange too. Still, it does what I expect it to do. Whats else? The model did work well before I tried to apply facing, so I hope there is no space for errors in all the other spaces it appears in the code. No, for now I think all places that can influence the behaviour are covered. Inside the model.json there seems to be no reference to the facings.... there aren't any in minecrafts torch.json too, so I'll skip that for now (until someone yells at me and request these to look at) So. Where does the wrong path slip in? Or isn'T there a wrong path after all? Confused Greetings, Merlin

Oh, someone found the cure for that error already? Ehm... and where does it need to go to? *thinking* ... Oh, like this: observe the changes I made below minecraft:sand Still, what does this do to make the error message I found in one of my logs go away completely? Anyway, thanks for finding a solution, Greetings, Confused Merlin

Hi there, I was on the outlook for beginners information about "how to add a recipe" and started worrying about not finding beginner-friendly information about itemStacks and shapeless registries, when passing by this topic. And I can confirm the error you are observing. The idea just to add a recipe.json in a designated folder and having all the magic done by forge did sound fabulous. So I copied your json file from the very first post, removed the comma-errors (why do you have an array containing the minecraft-stone?) and replaced all with stuff from my mod. And it worked perfectly. That is what it does look alike. More or less the same as you did, but with mod-exclusive items only. Than I added another part into it (attention, in relation to the attached picture, it was minecraft:stone what was there at the moment of screenshot) But this didn't work after all. As you might see I added two pictures from both recipes..... and I think I might need some online space to share pictures, because having them fully expanded at the end of my posts might be irritating to some. Next I was like "maybe its not called "stone" any more, which made me seek out one of the jars and... moron I am I looked inside the 1.11.2.jar. Waitaminute... no, its the same in 1.12.jar: there is a stone.json as a block and an item too, so that should not be the error. Next step was replacing stone with somethig else... like sand. My crafting table is situated at a beach (and it was the only blockItem I could identify shortly). With the same result: does not work. And then I went to the logfiles. latestLog doesn't know any recipe. fml-junk does know one of the recipes: the one that contains just the mod items fml-client-latest finally offered some insight, aaaand... I'll be so bold to assume, that this may be something that comes from forge itself, isn't it? Have a look: Well... I cannot say if the number (tutorial_recipe2) is legal... okay, renamed it to "tutorial_stuff.json" and... no, same error. It didn't recognize the minecraft:sand item (or stone)... so aren't they available at the moment of parsing, or do we use a wrong naming scheme for them? EDIT: I thing I rember some post with a link inside where the chief developers told that there where some changes made in 1.12 which aren't included into forge at the moment, and all we could do was being patient. Is this error about this, or is it something else? Greetings, ConfusedMerlin

Good Evening, the last time to...night. Thank both of you for pointing out whats wrong with my texturing. It was the "all" that was missing; I'm sure I overlooked this in the tutorial I had the instructions from. Oh,And @Jay Avery, ianusinchq is the correct name I changed it in the grand classes post because I was wondering what a troubled junior mod maker may think if he reads this. Maybe something like "what is that ianus thing?" and "do I need this too?" When its "modclass" chances seem to be higher the one realize "oh, so thats the point where I put my mods name into!" Now... I think this has been resolved. Should I change the Title to (solved) or something like this? Or is there anything anyone might want to add? (can I change the title anyway?) Now have a nice day / night and see u the next time I get confused. Greetings, (not so) ConfusedMerlin EDiT: and here we go - purple blocks, but this time in a less disco-ish look

Good Evening again, well, I'm happy to provide some unexpected happiness. But lets keep on going with the disco-cube. Iiiiiii... just needed to find out where there are any logs after all, and I found quite a lot inside the projects "run" folder. But these are quite a big number of lines, so instead of quoting and code-tagging them, I will try to attach them all. Oh, I didn't find the log-file that represents the log from the IDEs console somehow... so I pasted in a .txt which may not have the proper name (look for run.txt) And my mods stupid name (ianusinchq) came in pretty handy, because I could easily search for it. Or just "ianus". If I ever make it all the way to a usable mod I might explain why I did choose the two faced One (with a company type extension) as a mod name. Aaaaaand here we have the most interesting part extracted (from the fml-junk-earlystarup.log) Parts between common minecraft stuff, to be precise. Item mismatch doesn't sound this good... but tell me, did he just swap the numbers of both findings, so the mismatch became mismatched again, or do I interpret this in a wrong manner? Or why was it necessary to switch the numbers of the ItemBlock and the CustomIngot? Hm.... all other logs there seems to tell nothing extraordinary. Expect for latest.log maybe, which says this quite a few times: I do remember having seen "cube_all" somewhere shortly, and this is where we come to the three json files. Lets start off with blockstates/tutorial_ore Next one, models/block/tutorial_ore (ah, this is where the cube_all came from) Last but not least, the models/item/tutorial_ore huh, I thought it was more inside the last time I looked into, but... no, seems to be complete. But I missed it when posting the last post (because I thought it was the same as the one in block/tutorial_ore) And is is missing a S behind block? It does. Does it need it? *thinking* ... ... ... What? No, I certainly didn't insert it and run minecraft just to see if it works. ... okay, yes, I did. And it didn't work. Because "parent" points to the tutorial_ore inside my models/block folder, I think (so the missing s is needed). But now, after reviewing all that belongs to this topic, I'm still out of ideas about the "why". Well, the purple-black texture does look kind of nice, but is not what I had in mind for that ore block. ... Okay, the actual texture is kind of purple too, but not like this! AfterPeviewPreSubmitEdit(): When reviewing the post with the page preview (to get rid of the most embarrassing typos) I noticed that the blockstates are missing any... folder-directory-prefix-whatever-this-is-called, and repeated the "thinking" I did before (added block/ in front of the tutorial_ore, than realized that this may point to the texture for the "normal" state, when no one tries to pickaxe it, and repeated it with blocks/, but...). With the same result: Thinking does not fix texture-missing errors apparently; its still in its disco state. And I think I'm going to create a disco ball with music as the first real think, somehow. Greetings, Merlin latest.log fml-junk-earlystartup.log fml-client-latest.log run.txt

Hallo again. Well... a, let pictures speak. See attachment. Still... some things still are not finished yet. First - and most obvious - does the tutorial_ore lack its texture. I crawled through all spaces, where I could have placed a typo, but until now didn't find one. There is a dedicated texture available which is referred to in its very own model json. Buuut... Somehow I'm afraid I'm looking at the wrong destination. I wonder If I do need to the "ModelLoader.setCustomModelResourceLocation" I did for item for blocks too, but after there isn't a method that accepts block in that general direction I think something other might be necessary. Looking for this topic in the Docs didn't yield a result, but looking inside the example file there is this piece of code "GameRegistry.registerTileEntity(TileSimpleTank.class, "simpletank");" Is that what needs to be done to get this piece of tutorial_ore get its texture? Another thing I observed is the Block{null} I receive when creating my tutorial_ore in the first place. It... should be kind of okay, because after this it gets registered and its ItemBlock extracted, but I wonder if this is correct. When the registration passes by the tuturial_ingot, it got a "proper" number, like {3521} or something like this. I do know that counting with computers usually include starting off with zero, but {null} isn't {0} as far as I can tell. So is that an error (caused by me?), or something not worth thinking about any more? So. In case you are wondering what my classes do look alike now... okay, I'm afraid I might bore most of you guys, but in case someone with equal confusion passes by looking for a hint, I would like to offer my classes. And you can point out what I did wrong, if you like this more. By the way, yesterday I went amok reading and watching almost every tutorial I could my hands get on, but most of them seem to be unaware of the event registration process, getting pointed at by their watchers. Oh, and I came by the ForgeRegistries.BLOCK.register() function, which I tried to adapt, but that didn't work in my case. But it went pretty well in the setup the Tutor used for some reason. When I placed loggers everywhere to find out what happens at what point in execution, I noticed that his way of registering happened during the init() phase (which shouldn't work, shouldn't it?). For some reason after not coming to a success with his method, I went to bed and woke up with an idea for what's next. First... the Mod-class, stripped off the imports (which happen almost complete automatic this days): Oh, I replaced all my Mod-names with modClass in all parts comming, because the name I actually use is plain stupid... The Reference Class just contains Strings, as its used by next to every tutorial maker out there. And I DID edit the mcmod.info file as requested by the Docs! I tried to place the EventSubscriber Methods in there first, but they didn't get triggered. Which was a bit discouraging first, but than I remembered the statement, that this have to happen even before the preInit and could be accomplished by annotate a whole class with that bus-thing. So this came into existence. And its true, that this happens before the preInit is called. In here there is no logging, but the methods called in here do log again, and when they apperead in front of the preinit() call I had the feeling that things might turn out in a good way. Just to be curious, does all the SubscribeEvent annoted methods get passed all occurring RegistryEvents that appear, or how does this work in detail? So next the BlockInit. Thats where I tired to place this RenderModel Thing, but it didn't work. But when I pass the BlockItem over to ItemInit, it will get its RenderModel Thing done. But... well, something is missing. It might be not the most efficient way to do this maybe, but it does not crash and yield some kind of result... Another thing I'm afraid I may do wrong is the transmission of the ItemBlock over to InitItem. As you will see in the next code part, there I get the modItem and stuff it to all the other items (yet to come). Oh, and this is the place where I did meet the "Block{null}"; when the Breakpoint at ItemInit.addItemBlockToItems triggered, I hovered over "tutorial_ore" and got this reading. I will add "CustomOre" later, first the InitItem.java Here we go: So in here all my Items will be put to place, plus evers ItemBlock coming over from BlockInit. I avoided the Minecraft.getMinecraft.andsoon.ModelMesher Thing as requested. Still, most tutorial guys still love to use it. ModelLoader came from the example file I think....Anyway; as explained here somewhere, I didn't need to do something by myself to have the items registered after the blocks. All that follow are done in a alphabetical order? No, arbitrary... do I need to watch out for decencies in there? Okay. We neeeed.... the Item and Block Classes. Item is straight forward, while block... is... huh... that's remaining from one of the later tutorials. I dunno, if I keep it this way, or if I need to adjust this. Well, at the moment its suspicious for making the tutorial_ore Block missing its texture. Oh, I had a moment of panic, when the block didn't appear after all, but all I was missing was the CreativeTabs Method call. So no default placement, hm? Okay... I think that are all classes that were necessary to get this stuff into the game. Oh, proxies are missing, but they are plain and empty at the moment, not really distinguishable from these you find in nearly every tutorial out there (expect that one gut who had a CommonProxy, ClientProxy AND a own ServerProxy, where all the others work without the ServerProxy) Hm. The folders with the textures and json files may be of interest. Look at this: I feel like I missed one... ayway. You might spot the tutorial_ore inside item(s) folder, which is because I thought that the texture for the block might come from its BlockItem (which would get a reference to Items texture folder due to being registered alongside the normal Items) So... I'm not certain how to proceed now. Of course I would be happy having the correct texture appearing at the block, but after this... Oh, I still do not know what to do with the @ObjectHolder to be honest. That might come next. Or using recipes. Are there other things, that did change in a way from pre 1.12 forge to now that old tutorials are not usable any more? Something one would come across inevitable? So, thank you for inputting knowledge in my general direction. Still, I'm afraid I was so confused after all, that I closed in to enlightenment from the other direction and didn't accomplish this by using the resources available at the moment. But I'm a bad explainer too, especially if I have to use english (as my second language). I wonder if the stuff I provided could be of any help after all, but this topic of mine is to confusing to be feasible for anything but being forgotten in the deeps of this forum. So. I look forward to getting my block colourized properly. Until then have a nice day. And last, but not least, my motivational picture of the day: