Pheenixm

Can you explain what you meant about this? I'm trying to do something similar, and it would be very nice to understand what you exactly mean

I've probably spent 4 hours working on this issue to get it resolved, and there is NO documentation of it available. So, I figured I'd create this topic to link to the issue I submitted to ForgeGradle. It doesn't look like this is going to get a fix anytime in the future, but at the very least, hopefully this topic will help other people avoid the same problem. Solution to the problem may be found here: https://github.com/MinecraftForge/ForgeGradle/issues/519#issuecomment-423849322

Looks like you're the not the first person to have trouble with 3DSMax. I'd switch to blender while I was still early on, it actually works. That said, try removing all 's' references you can find; it probably won't do anything, but it's worth a shot. Finally, I'd try reimporting your model, because I've thought about it further; your texture is DEFINITELY loading, otherwise, you'd have the purple and black checkers that Forge applies by default to missing texture objects. Try changing your texture files (appletop) to neon yellow, then see if the render of the block in-game changes at all. If it does, you're likely dealing with UV errors, and again, I'd recommend you just go learn blender.

I didn't mean copy my code exactly. That code is specific to my block, not yours. If you don't understand the fields in blockstate.json files, I suggest you go learn them independently. What you need to know is that you have to have the custom tag, because flip-v has to be specified as true, and ALL of your model references need to end in .obj when you're referring to .obj files.

You don't need this ModelLoader.setCustomModelResourceLocation(Item.getItemFromBlock(block),0, new ModelResourceLocation(new ResourceLocation(block.getRegistryName().getResourceDomain(), block.getRegistryName().getResourcePath().concat(".obj")),"inventory")) Use a blockstate.json file, like I do here https://bitbucket.org/Pheenixm/explosivesplus/src/master/Explosives%2B/src/main/resources/assets/explosivesplus/blockstates/concrete.json

Show me your blockstate.json for the block. I don't know what those values are, most of the values in mtl's are essentially unnecessary, beyond the most basic map_Kd or map_Ka calls. For instance, look at Immersive Engineering. Also, a picture of your folder structure would be ideal. What rendering software are you using?

Oh, definitely. I've been using invisible blocks with large .obj models in my multiblock setup, and it has been a pain to get the frustrum culling to stop. I'm having to use @Override public boolean isGlobalRenderer(TileEntitySilo tile) { return true; } in my TESR just to ward off the frustrum culling issues. Fortunately, I don't expect a lot of my multiblocks to ever be built (350 block composition), so it shouldn't be too much of a problem.

You should stick with HashMap<Key,Value>. It allows for .contains() queries in O(1) time as opposed to ArrayList, which is O(n). At the very least, use HashSet<Key>, that also allows for O(1) time. If I were you, I'd look into A* search. You want the shortest distance, it's optimal. That all said, it sounds like what you need is something similar to the way I'm doing multiblocks. This may prove somewhat useful to you, particularly the checkNeighbors() method, which is called whenever a block is placed. It basically checks each neighbor to see if they are an instance of the network type, and if they are, it joins the network; otherwise, it forms a new network. Ought to have a lot of cross-over application with your aims. I'm gonna warn you right now, the code for this is still fairly buggy on edge-cases. When a network is split in half and the blocks on one half have to re-resolve the master node, that just gets ugly. You can make yours simpler by implementing a true master/slave architecture in your blocks, rather than the virtual master/slave architecture I decided to implement for the challenge of it.

Nope. Here's a few links to get you started https://mcforge.readthedocs.io/en/latest/config/annotations/ https://github.com/TheGreyGhost/MinecraftByExample/blob/master/src/main/java/minecraftbyexample/mbe70_configuration/Notes.txt

Think you're wrong on 2. Obj files can be as large as you want them to be; you'll run into some errors with frustrum though.

Your texture is in the wrong place. Here's an example of one of my mtl files # Blender MTL File: 'engine.blend' # Material Count: 14 newmtl Material Ns 96.078431 Ka 1.000000 1.000000 1.000000 Kd 0.640000 0.640000 0.640000 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 map_Kd explosivesplus:items/engine_tank newmtl Material.001 Ns 96.078431 Ka 1.000000 1.000000 1.000000 Kd 0.640000 0.640000 0.640000 Ks 0.500000 0.500000 0.500000 Ke 0.000000 0.000000 0.000000 Ni 1.000000 d 1.000000 illum 2 map_Kd explosivesplus:items/engine_nozzle You'll note I don't specify the "textures" folder at all; that's automatic. My textures are in assets/explosivesplus/textures/items. But the "texture" line is just implied Also, you can just load the model in your blockstates file. "model": "explosivesplus:silo.obj", You'll also want to put @SubscribeEvent public static void registerModels(ModelRegistryEvent event) { OBJLoader.INSTANCE.addDomain(ExplosivesPlus.MOD_ID); } somewhere in your ClientProxy file.

You could do this fairly easily with a DFS search algorithm. Don't need something as advanced as Dijkstra's for this

Yeah, 1.13. If you want variations based on something like color, take a look at the way that BlockShulkerBox handles its constructor. You can use that sort of thing to do registry like so new BlockVariant(EnumColor.color).setRegistryName(registryName) new BlockVariant(EnumColor.color2).setRegistryName(registryName2) And thereby reuse the same class file while creating different blocks from it, with different blockState.json files for each one

You really shouldn't be using metadata for creating subblocks, that entire practice is being obviated in 1.3. Just register each block individually, with its own registry name. You'll be happy when 1.3 shows up and breaks everything.

I've been updating my old mod lately, and I just finished work on a chunk injection system you may find interesting. Rarely, it'll cause a crash due to strange ticking issues, but if you wanted to play around with the code, I'd be happy to share it with you, especially if you have any ideas on how to fix the crashes that occur if you try to process anything north of 500 chunks at a time. Premise is copying a chunk's data with reflection in separate threads, making whatever changes you want in a multithreaded system, then re-injecting them back into the chunk map with entity tick events such that it's completely thread safe. You could theoretically use that to replace blocks on demand. https://bitbucket.org/Pheenixm/explosivesplus/src/master/Explosives%2B/src/main/java/com/pheenixm/explosivesplus/common/chunker/