Matryoshika

I believe Packet250CustomPayload has become CPacketCustomPayload & SpacketCustomPayload, for use from Client & Server respectively

I would recommend TheGreyGhost's Minecraft By Example MBE04. Though he uses IPerspectiveAwareModel (Which extends IBakedModel). However, don't do anything with the ModelBakeEvent. Just create an ICustomModelLoader, have it accept the resourcelocation(s) for these models, point those resourcelocation(s) to a custom IModel that immediately points to the IBakedModel. I do this in my ongoing project Echo, but it's quite messy right now and I haven't uploaded the latest changes yet. You can take a look, but wait a few hours for me to upload the current stuff, as most things get shoved around a bit, or right out removed.

No player, will likely ever going to have more than 10% of your models loaded in memory at any given time. If they have more than that, they goddamned tried their best to soak up their own memory. Yes, framerates may stutter, but most of the time, no-one will notice. I create baked models on the fly to create Menger fractals, and only notice anything at iteration 4, or loop number 20⁴ as that amounts up to. It all depends on how efficient you are when it comes to "creating" the models.

I'd recommend serializing the HashMap to JSON (String) through Gson Gson::toJson returns a JSON string representation of the provided object. Gson::fromJson returns a new instance of the provided class, using the provided JSON string. If you have null values in your map, and want to keep them (for whatever reason) you need to use GsonBuilder with serializeNull (or whatever it is called, not at my PC right now) chained. Gson skips null values by default.

Do you really need all of them to be baked at once? Why not have a custom IBakedModel render the block. If the wanted model is cached (stored already) then simply return the BakedQuad's for that. If not, create the wanted model, cache the BakedQuads, and return the BakedQuads for the model from the cache. This way, only the "needed" models are in memory (which should only be a shadow of what you got now), and if they are not, it creates them from scratch, AS they are needed. This should shave off a significant amount of RAM requirement.

One question: Is this for your own ores, or for vanilla/other modded ores? If the latter: If you want to influence other's ores, look at the GenerateMinable event. It passes the WorldGenerator, which you can cast to WorldGenMinable, and get the state, number and predicate from.

Post the fml-client-latest.log (preferably to pastebin.com, or similar webpage) The log exists inside <project-folder>/run/logs.

Either we are in a paradox, or one of your statements are incorrect. I do not believe anyone here will simply make a mod for you, at least not for free. I believe Diesieben07 has stated a few times that he charges an hourly salary of 50$. The other's, I'm not sure about. This place is a forum to learn how to do things, or ask for help. Requesting someone do everything, isn't asking for help, it's asking them to do everything. However, I can tell you key points of interest: 1) Use either a Tickhandler, or subscribe to the LivingUpdateEvent 2) set sneaking with Entity::setSneaking(bool) 3) Key-presses (like pressing F12) only happen Client-Side, so you might be required to use packets to send the updated sneaking to the server ("so that the trees know that you are sneaking")

Alright, I've implemented everything, yet I have come face to face with another issue. The method getQuads() in BakedMengerOneModel is never called, it seems. The FMLLog calls are never invoked, after checking console as well as the client-logs. However, the getParticleTexture() does return the correct TextureAtlasSprite, so the BakedMengerOneModel is getting called to render it. The model is completely invisible. I have tried both using the ModelBake event, and registering a custom ICustomModelLoader (that calls an IModel calling BakedMengerOneModel), with equal results I'm a bloody idiot. It renders fine now, with a BakedModel through an ICustomModelLoader.

Don't think that that is proper Java syntax there Just call NonNullList.create().

Oh, I thought I was doing that. And yes, you told me to use an IBakedModel, but how the hell would I be able to provide the data (IBlockState & byte) that exists in the Tile, to the model? The data is only stored in the Tile & ItemStack. An ICustomModelLoader only provides a ResourceLocation. Issue is in the "find model" part of your statement. That is why I am using a FastTESR, not a basic TESR. The byte data could be omitted, if I register a new block per tier, but the original IBlockState of the block that these are to compress, still needs to be gained from the Tile to determine the model to be used. If you can help me do that, then I will happily scrap the damned TESR rendering.

BlockBeef.json != blockbeef.json Resources must be lower-case in 1.11

So, I've finally gotten models to work. In a normal TESR, the IBakedModel rendered fine using Minecraft::renderModel, but getting the BakedQuads and adding them to the VertexBuffer in a FastTESR, doesn't really render nicely... Anyone know why this is? Why is the top face rendering with alpha? Any way to render the BakedQuads without the vanilla StandardItemLightning turning the models darker than they should be? Code can be found here.

NBT syncing has been fixed. Had to override TileEntity::getUpdateTag & TileEntity::handleUpdateTag as well.

Ah, sorry, outdated code. GitHub has been updated now.

Yeah, missed a null check there, but that should have given me a nullpointerexception, no? Not a stackoverflow. I was storing the data inside TileEntity::getTileData(), as seen here. As such, the wanted data should have been accessible from that NBTTagCompound. I am now, no longer using TileEntity::getTileData(), but storing the NBT data in the proper fashion. After the switch, I have not gotten another suspension. However, even when overriding TileEntity::getUpdatePacket() & TileEntity::onDataPacket(), the state field always returns null on the client, after re-launching. I've even tried using custom Packets to forcefully update the client Tile with the Server Tile's state, yet nothing seems to stick. To note, the state is required immediately on the client, as the state is required to render the proper model. One thing I've noticed, is that TileEntity::getUpdatePacket() is only invoked when the Tile is placed, not when the Tile is rebuilt from NBT. Doesn't that defy the purpose of syncing Server->Client with TileEntity::getUpdatePacket() & TileEntity::onDataPacket() though?

Further investigation: Issue is a StackOverflow error, in the mentioned AnvilChunkLoader#writeNextIO(). I have traced it down to only the getPickBlock() method now. Is there an issue with using TileEntity#getTileData()? I am literally only copying tags from that to the ItemStack that was gained from super.getPickBlock().

For me (on Linux) gradle stores JEI in /home/user/.gradle/caches/modules-2/files-2.1/mezz.jei.

Alright, I'm a bit stumped on this. Except for some IBlockState<->NBT handling, I'm not doing anything that I haven't done before, without issues. To clarify the issue: Minecraft suspends (freezes completely) whenever I do either of 2 things in my project: Using the ItemCompressionWand on a proper Multiblock structure, And when getPickBlock is called in CompressedBlock, when a Creative player scroll-wheel-clicks on a block, that was previously placed by the mentioned ItemCompressionWand. The suspension happens in AnvilChunkLoader#writeNextIO(), Line 242 (the finally block) Except for a pure java crash, that only happened once, there are no crashlogs. Latest log Latest Client log I am using Forge 1.10.2-12.18.2.2123

It generates, because during worldgen, the code creates a new MCAWGenerator at the suitable location. Move your counter out of that class, and put it somewhere that can be easily accessed, like your main class, for example.

Unsure if this class exists in 1.9.4, but NBTUtil#func_190008_d takes an NBTTagCompound (which has an IBlockState serialized within it) and returns the proper IBlockState. You can see how vanilla MC makes use of this in Template#read.

"I need something to hold 5-7 books" "The smallest room we have is a 2.56m² room, but I'm going to provide you a 42949672m² room"1 *places books* echo...cho...ho...o... ¹Yes, I am aware that the difference is not that severe, memory wise. More like 8 vs 32, but it all boils down to me not wanting to soak up space, no matter how insignificant it is in the large span.

I never stated I wanted to add compressed blocks for each and every block there is, merely support the option of adding new compressed blocks, based on other. I know some pack-maker's are painfully diligent, but I do not see anyone adding 100+ of these blocks. I am aware of TileEntity no longer ticking off of the bat in 1.8+, but my... disdain for them, stems more from the rendering perspectives of TESR's, than the actual usage of TileEntities. I believed you were advising me to use TE's merely for rendering, which I now stand corrected in. No, I do not store anything more than the tier, as I place each new block, in a custom registry. I merely stated that storing data can be done in the block, not that I am doing so for every little tidbit, though I cannot fault you on that. I do believe I need to work on making myself more clear in these matters.

Thanks, but you are jumping the gun a bit there at least. I am talking about a mere block, that is based on another, and is nothing more than storage (Think ExtraUtilities compressed blocks, for example). I never stated, nor implied that I was using a TileEntity in conjunction with these blocks, and I do not feel inclined to do so, unless I am forced to do so, due to rendering issues etc. Storing data (original block|blockstate etc) can be done in the block, here, as the data is not meant to ever be changed. Thanks for the rendering pointers though.

Incorrect. ResourceLocation splits the 2 parameters into domain & path. Manually adding a colon is never necessary unless you use the single parameter constructor, which calls ResourceLocation#splitObjectName, and places each part into the mentioned domain & path. The way you showed, with an added colon in the path, will become "domain::path".