TheGreyGhost

Howdy Could you pls put your Blender model and your mod into GitHub? I will take a look in the next couple of days if you like. -TGG

Howdy You might find these working "tutorial" examples of NBT useful Items: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe11_item_variants https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe12_item_nbt_animate TileEntity: https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe20_tileentity_data -TGG

Howdy Here's a working example of voxelshape https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe02_block_partial and a link with background info https://greyminecraftcoder.blogspot.com/2020/02/block-shapes-voxelshapes-1144.html -TGG

Hi Probably - some of your face normals are pointing the wrong way. Use blender to automatically recalculate them so that your faces are pointing outwards, not inwards. Cheers TGG

Howdy I'm not sure about the vanilla way of doing things, but it's pretty straightforward to make a custom particle renderer and then render whatever texture and colour you want. Eg see here for a working example https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe50_particle -TGG

Random thought, I have no idea if this is relevant or helpful: public interface IForgeDimension { default Dimension getDimension() { return (Dimension) this; } World getWorld(); /** * Called from {@link World#initCapabilities()}, to gather capabilities for this * world. It's safe to access world here since this is called after world is * registered. * * On server, called directly after mapStorage and world data such as Scoreboard * and VillageCollection are initialized. On client, called when world is * constructed, just before world load event is called. Note that this method is * always called before the world load event. * * @return initial holder for capabilities on the world */ default net.minecraftforge.common.capabilities.ICapabilityProvider initCapabilities() { return null; } But apart from that- Are you sure that you are loading/saving your capability to NBT correctly? Eg for ItemStacks which have an attached capability, they are also created fresh each time (initCapability is called at every ItemStack construction) but the capability is immediately loaded from NBT. Perhaps your capability is not doing that correctly. Eg look at CapabilityItemHandler and serializeNBT(), WorldCapabilityData -TGG

Howdy I had a look and your mod is completely broken. I'm currently working on an example mod for projectiles. I'll paste your shuriken model into that and upload it so you at least have a working starting point to get you going. -TGG

Howdy Have you looked at ProjectileHelper::rayTraceEntities? You should be able to adapt the code in there to do what you want. 50 blocks is a very long way,though. It might be more efficient to use a different algorithm which filters entities manually, i.e. for each entity in world { vec3d entityPosition = entity - origin check if position is in the correct octant (x +ve or -ve, y +ve or -ve, z + or -ve etc) if so { vec3d distanceFromEntityToRay = cross product (position, ray) / norm (ray) if distanceFromEntityToRay < 5 then include in detailed raytrace otherwise exclude } } you'll need to know a bit of vector math to do that... -TGG

Howdy That repo won't compile * no build.gradle * main class does nothing * assets directory doesn't match mod source directory -TGG

Howdy Please see private message Cheers TGG

Hi Does your CapuchinBrownEntity extend the vanilla Entity? If you think it does, show your CapuchinBrownEntity class? -TGG

Howdy The problem is here; you mixed up short (2 bytes long) and float(4 bytes long) so your UV was overwriting dud values into the baked skylight+blocklight. private void putVertex(BakedQuadBuilder builder, Vec3d normal, double x, double y, double z, float u, float v, TextureAtlasSprite sprite, float r, float g, float b) { //ImmutableList<VertexFormatElement> elements = builder.getVertexFormat().getElements().asList(); ImmutableList<VertexFormatElement> elements = SLAB_BLOCK.getElements().asList(); for (int j = 0 ; j < elements.size() ; j++) { VertexFormatElement e = elements.get(j); switch (e.getUsage()) { case POSITION: builder.put(j, (float) x, (float) y, (float) z, 1.0f); break; case COLOR: builder.put(j, r, g, b, 1.0f); break; case UV: switch (e.getIndex()) { case 0: float iu = sprite.getInterpolatedU(u); float iv = sprite.getInterpolatedV(v); builder.put(j, iu, iv); break; case 2: builder.put(j, (short)0, (short)0); // error is here break; default: builder.put(j); break; } break; case NORMAL: builder.put(j, (float) normal.x, (float) normal.y, (float) normal.z); break; default: builder.put(j); break; } } builder.setApplyDiffuseLighting(true); } Due to non-defensive coding assumptions in IForgeVertexBuilder, it was taking your incorrect slBaked value (2047 instead of 0), overwriting the skylight (15), leaving a packed texture coordinate with zeros in the least significant bits, i.e. effectively 0 skylight = dark. default int applyBakedLighting(int lightmapCoord, ByteBuffer data) { int bl = LightTexture.getLightBlock(lightmapCoord); int sl = LightTexture.getLightSky(lightmapCoord); int offset = LightUtil.getLightOffset(0) * 4; // int offset for vertex 0 * 4 bytes per int int blBaked = Short.toUnsignedInt(data.getShort(offset)) >> 4; int slBaked = Short.toUnsignedInt(data.getShort(offset + 2)) >> 4; bl = Math.max(bl, blBaked); sl = Math.max(sl, slBaked); return LightTexture.packLight(bl, sl); } It works fine now... -TGG

Howdy I'm assuming that you don't want to add your custom fluid to the vanilla "water" Tag, then? (i.e. like this https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe35_recipes) If not - I don't think there is an easy way, no. I don't have experience with this recently but the two key words that might be worth searching for are "coremod" and "asm" They will let you overwrite parts of the vanilla Entity::handleWaterMovement code. It's a bit arcane and can be rather brittle but might be your only choice. Cheers TGG

Howdy I think capability is great for items, entities, etc where 1) you're attaching the same general capability to a variety of different object types or a variety of different capabilities that you're adding to multiple objects ("composition" instead of inheritance/interfaces); or 2) you want vanilla or other mods to be able to interact with your objects in a general way; or 3) you want to attach information to vanilla objects For example - the capability to store items CapabilityItemHandler.ITEM_HANDLER_CAPABILITY is very useful because other mods and vanilla objects can automatically interact with your object to add or remove items. You don't need to tell them anything except that your object provides the capability interface. Or if you wanted to model a radioactive wasteland you could attach a RadiationSickness capability to each entity, including vanilla, to store the amount of radiation damage that has been suffered by each entity. In contrast, if you're just storing information (in your item) that's of no particular interest to other items, blocks, or entities, then you're probably better off with just "private" NBT information. -TGG If you're interested in general information on the pros and cons of this coding technique, these links might be interesting https://www.baeldung.com/java-decorator-pattern https://www.geeksforgeeks.org/decorator-pattern/?ref=lbp

Howdy If you want people to be able to add variations of a Block or Item using a configuration file, so that you can let the artists create assets without having to modify code, then you might be able to get close to what you want by using BlockStates for Blocks or NBT for items. It's more complicated than just coding all the blocks or items individually, so I wouldn't do it without a good reason. If the differences between your blocks are largely cosmetic, or are based on a few different types of behaviour that can be combined in different ways, then you could (eg) just register a single block, but reserve 256 blockstates for your block. You then read in the configuration file and assign blockstates accordingly. Your single block then alters its behaviour and appearance based on the blockstate, to match the configuration file settings. A similar approach is possible with Items and NBT storage. The purists don't tend to like this approach but it can be very useful for letting non-programmers work on assets / artwork and change the game behaviour rapidly without having to manipulate code. It also lets many people work on the same blocks & items without clashing all the time due to code merge problems. I have done this before with Entities (breeds of dragon) which had a large number of configurable parameters to modify their appearance and behaviour (such as size, health, colour, textures, agressiveness, type of breath weapon, etc) and it worked very well. Adding a new breed of dragon involved adding an extra configuration file for that breed, no code modification at all. Apart from making adjustments much easier, it also made the code very much simpler and a lot less brittle. -TGG

Howdy I'd suggest you make your own EntityRenderer for your projectile. The renderer can check whether the player is in first person view, and if so, make sure that the entity is at least a given minimum distance away from the player's head before rendering it. Third person view (0, 1, 2) is accessible from GameSettings and ActiveRenderInfo (minecraft->gameRenderer->activerenderinfo) -TGG

Hi Please check that it's fully up to date and compiles, then let me know... Cheers TGG

Howdy You might find this working example of nbt storage in items useful https://github.com/TheGreyGhost/MinecraftByExample see mbe12 You could use capabilities, but that is probably unnecessarily complicated for what you want to do, by the sound of it -TGG

Hi It's become a lot harder to do that now that Minecraft uses render buffers to collate vertices and then renders them all at once. I'd suggest that you use a dynamic texture instead (cached) and perform the blending calculations yourself. There are a couple of posts on this forum about that in the last couple of months. Jayzx post about textures for entities (wolves, I think) and another thread about putting banner textures onto elytra cloaks. Cheers TGG

Howdy As per the earlier posts I'd suggest you just use a HashMap without a builder. Longer term I think it would be a good idea to have your stripping information as a loot table (or possibly a custom recipe type if the loot table becomes unwieldy) so that it can be customised by folks in data packs, no coding required. -TGG

Howdy Some info on voxelshapes FYI https://greyminecraftcoder.blogspot.com/2020/02/block-shapes-voxelshapes-1144.html https://github.com/TheGreyGhost/MinecraftByExample/tree/master/src/main/java/minecraftbyexample/mbe02_block_partial -TGG

Howdy Some more info on voxelshapes https://greyminecraftcoder.blogspot.com/2020/02/block-shapes-voxelshapes-1144.html -TGG

Howdy The code is from this example project https://github.com/TheGreyGhost/MinecraftByExample (mbe04 AltimeterBakedModel) The definition for the vertex format of BLOCK is public static final VertexFormat BLOCK = new VertexFormat(ImmutableList.<VertexFormatElement>builder() .add(POSITION_3F) //[x,y,z] .add(COLOR_4UB) // colour info .add(TEX_2F) // texture .add(TEX_2SB) // lighting (blocklight + skylight) .add(NORMAL_3B) // normal .add(PADDING_1B).build()); but you're right, the lighting is often not used / is added during rendering. If you put your code into a github I'll have a look in the next day or so to figure it out. I think it's almost certainly a block setting or voxelshape problem that's causing the lightmap to be wrong, it won't take me long to confirm it. Cheers TGG

Ah ok, now I understand what you mean. That's nothing to do with the vertex normals information, it's because of back face culling. Each quad has a direction - a front face and a back face. Usually, the back face is not drawn. The direction that the face is pointing is determined by the order of the vertices. If you are looking at the front of the face, the four vertices should be in anti-clockwise order. So if the face is pointing the wrong way, you just need to reverse the order of your vertices. For example: your left-right draws in the order of maxY, minZ maxY, maxZ minY, maxZ minY, minZ which is clockwise https://3.bp.blogspot.com/-Lh9ked7q9Lg/UejFhn9OfbI/AAAAAAAAAAY/oYem6d_fSk8/s1600/MinecraftCoordinateSystem.png Instead, add the vertices in the opposite order, i.e. minY, minZ minY, maxZ maxY, maxZ maxY, minZ -TGG

Is your github up to date? If so, I'll have a look in the next day or so -TGG