Matryoshika

Thanks. As far as I can see, you mean that I should merely use the base quads, and merely "clamp" them together into one model, translating them by a*n*0.33 where a equals axii, and n equals iterations per side, and jump over iterations [5, 11, 13,14,15, 17 & 22] This brings up the issue with "find the model of the "original" block". I never mentioned this in the OP, but I wanted to add the functionality of allowing full configurability for this compression, allowing any block to be compressed. I keep to the preferred RegistryEvent, though most mods still use preInit for content-registration, so of course, there'll be nullpointers even if I used "after:*" in dependencies. As such, I believe this can be surpassed by defining a block in-game (when the server is up), get the blockstate, get textures from it, serialize it (to a file), then after the next restart, actually add the new compressed blocks to the game, and have the new block invoke the original blocks methods (for consistency). Anyone seeing any issues in doing it this way?

When he said "run with", he meant running gradlew build --stacktrace

So, I got a Menger Sponge iteration going for compressing blocks, in a project. With compression iteration; [n < 3], there's no issues at all. [n = 1] .obj file is 9.5KiB. [n = 2] .obj file is 60.5KiB large... So we're starting to see the obvious exponential growth in sizes here. However, with [n = 3], the size suddenly skyrockets to 1.3MiB big. That is, a tad too big for a model. To answer first "why not just make the model smaller": The model has to be split in 27 parts on all axii, as a "face" cannot have a texture, and a smaller hole inside of it. That hole has to be surrounded by equally large solid faces. Overall, the [n = 3] model has 19,584 faces, even with optimizations done. That is as small as I can get the model. Now, with that out of the way. As stated, I have this compression system. You put x blocks -> 1 new block. It's configurable, to allow for compression for blocks in other mods. Now, I've been copying a "main" model, and replacing names (of the file, and inside of it) to match the new block. I don't want to clog all resources, if if there's let's say 20+ [n = 3] blocks. Is there any way to go around the 1.3MiB models? Can I use the same model, but keep the correct texture for each block (which are specified in the accompanying .mtl) Would a custom OBJLoader work here? EG load the same model, but apply different texture to each? Or something akin to "camouflaged" blocks, like TGG's MBE example MBE04? Are there any other options? Or should I just stick with what I have??

I believe you can do this much like the Bow handles it's pulling animation (IItemPropertyGetter's & overrides in the model.json¹) There isn't much to it. Look at ItemBow's constructor, as well as the bow.json inside ForgeSrc/assets/minecraft/models/item ¹If you are using the .obj directly as your model, then you can use the ForgeBlockstate to transform the first-person, third-person & gui elements, per stage. I have an example of the BlockState transformation here.

http://mcpbot.bspk.rs/ If you don't want to use the IRC bot, you can download the mappings directly at the top of the screen (Data Exports).

1.7.10 & below are not supported in this forum any longer. Please update to at least 1.8.9, but preferably to 1.11.2. A moderator will likely lock this thread in the near future.

The class that implements these recipes, is it made in Scala? Because that's Scala casting, and I believe the objects has to be pure Java to work properly. JsonTweaker (Scala mod, is on GitHub) faces this issue, and solved it by invoking a custom Java method that took the ItemStack & object[] and returned the recipe.

Show your recipe code.

It would seem that the lastTickPos values have already been set to the current tick, when this executes. You can as mentioned try to keep track of players every ~5 ticks or so, in a Tick-Event, and store a custom lastPos in a Map<UUID, Double> collection where the Double is the square-root of (posX*posX+posY*posY+posZ*posZ), and then when the player hits something, get the square-root of the current position and get the difference. Though most optimal would be a custom Capability that would do this for you (and would let you skip the Map as Capabilities are per-player already) Also... what version of Minecraft are you coding for? Entities should have a worldObj field, not simply "world".

There may be work-arounds. If memory serves correctly, Tinkers' Construct has items (arrows, throwing knives & shurikens) that have stacksizes (or realistically faked) > 200

Please, if possible, show the code for each approach to this that you have tried so far.

entity.getDistance(entity.prevPosX, entity.prevPosY, entity.prevPosZ) returns a double value, which is how far the entity has traveled since the last tick. The higher that is, the further it traveled. If you want to get more than blocks/tick, you need to either do some messy work with TickEvents, or create a Capability that stores an entity's position every x ticks.

Well, that being the case, why don't you just give the entity the Slowness potion effect? I believe I used something extreme like 20 or so, for the amplifier parameter in PotionEffect(potion, int, int), in an older project I had back for 1.7. (You'd have to either A) continuously apply a very short duration to each entity, or B) a very long one, and then remove it once the entity leaves/is removed from the area )

No, they are not. There are majour issues with at least 10 of the 15 tutorials; Most stemming from becoming obsolete in newer versions. All item/block related tutorials have become completely obsolete. Minecraft::register usage, nothing about RegistryNames, substringing unlocalizedName, nothing about RegistryEvents, hell, his tutorials use GameRegistry#registerItem!

I have a Tile-Entity that does something very similar. However, it stops hostiles in a large-ish area (8 block radius) It also handles logic to allow mobs to get hurt, or even killed when frozen. (Normally, entities get a small invulnerability time after getting hurt, which when the event is stopped, never passes) The logic is based on checking if the mobs is near known blocks that have this tile, instead of checking each block around the entity for blocks that have this tile (important distinction there) You have to stop the mob from updating, not merely setting speed to 0. Skeletons will still shoot arrows, creepers will still explode etc otherwise. You can view the event here, and the "registry" of placed blocks here.

Do not use this. Unlocalized names have nothing to do with unique identifiers, and are more prone to change over time. Use item#getRegistryname instead. It formats modid:name for you, so that is all you need. Minecraft::register is also very hard to use. The only reason Vanilla rendering works, is because of the extensive knowledge of the system, that the workers of Mojang have. ModelLoader is the Forge-alternative, which has had some "fool-proofing" done. With ModelLoader, register your items/blocks in preInit, or better yet, during the ModelRegistryEvent

"foundationsmod/items/itemNeedle" 1) Domains are followed by a colon, so it should be "foundationsmod:items/itemNeedle" 2) Resources should not have any capitalizations. This is enforced in 1.11, and has been heavily urged since before 1.7. If following the naming conventions, the file should be called "item_needle" instead

Are you sure that you downloaded the jar from the official webpage? If not, could be somebody just renaming the 1.7 version to match 1.11, to troll. Try deleting the mods folder again, but try and use the second-latest file.

What is the name of this "latest" optifine.jar, that you are using? The latest I could find at the official webpage is OptiFine_1.11.2_HD_U_B7.jar No. It exists, and it is loaded.

The network I'm part of, makes use of TickProfiler, a Forge mod that lists resource-hogging Tile-Entities and Entities, per time/tick average, per tps%¹ they are draining, per chunk² and per type³ ¹Take this with a bit of salt. If something states it is causing 50% of the drain, it may very well be a big drain, but the profile cannot see everything, yet tries to stretch what it can see to how much is drained. ²allows you to see the chunks with highest activity, most of the time player-bases centered in a single chunk, for example ³Shows the tile-entities and entities that collectively stand for the most drain. Take this with a bit of salt as well, as it does not take into account -how many- of said type there are. While this may not solve your issue, it should enable you to find the largest TPS-drains on your server.

I have an on-going project where I use a standard .obj model and have the code create copies of the .obj, .mtl and a .png for particles etc, which includes editing each individual block's colour. This might be well over-the-top depending on how you want to render this model. Is the colour permanent? I mean, it does not change? If so, you would likely only ever need to create a class that implements IBlockColor, override colorMultiplier, and register the class with the wanted block using Minecraft::getBlockColors(). I do this for Items here. Do note that it wants an integer. either convert your rgb values to one, or create a java.awt.Color with these values, and call getRGB(). (Note, you can also use the constant colours like Color#GREEN etc)

Similar threads, which should give you some pointers

Getting a BakedModel object Rendering BakedModel

To render .Obj models: Call OBJLoader.INSTANCE.addDomain(modid) before you register your models, either in preInit or preferably in the ModelRegistryEvent. After that, you can create your blockstate/model json as normal, but remember to point the variant to modid:somename.obj The .mtl file also has to be in the same folder as the .obj, and share the same name (supermodel.obj & supermodel.mtl, for example)

The major thing between 1.10 & 1.11 is that ItemStacks can no longer be null in 1.11. This means that whenever you call ItemStack.EMPTY in your 1.11 code, you need to switch to null-checking & setting in 1.10. The 1.10<->1.11 compatability is almost exclusively for those that use the CompatLayer API, made by McJty. Because of the nature, this means a hard dependency.