TheMasterGabriel

Oh that's an interesting idea... So when I pass the world parameter through, pass through a WorldServer instance that I get via DimensionManager instead. Hmm. That may solve my tile entity interaction thing as well. I'll have to investigate that. I had realized that. My idea was to use ASM to discover (not alter) any fields that met the property requirements and add them to a list (assuming it wasn't on the list already), which I would then use in registering my block. The dimension idea might work better, however. Edit: Also, this needs to work in every dimension, so I presume I would need to create a 'dummy' dimension for every single registered dimension. I run into the loading order problem again there, though.

So I've run into another problem. It looks like I'm going to have to abandon the entire TE serialized block data in favor of generating blocks at runtime. The reason is because I cannot perfectly emulate other blocks within my own block class. Methods like Block#isPassable ruin that, as they accept World and BlockPos parameters instead of an IBlockState parameter. If I delegate that method from my block class to my copied block class, there is a chance of it crashing. For example, if my copied block is BlockSnow, running Block#isPassabe crashes the game as it first gets the current block state at the passed position (which would be my copied block), and then tries to read an IBlockState property off the blockstate, which of course fails because my block doesn't contain that property (which for snow is LEVEL). So as of now, there are really only three ways (two of which may or may not be possible) I can think of solving this problem: - Create a new Block singleton, which holds the copied IBlockState, for every single IBlockState entry within the BlockState map (and setting my block's default state to that blocks default state, and setting my block's IProperty list to that block's IProperty list to overcome the error I described above). Of course, the problem with this is that it depends on mod loading order. - Stick with one block instance and the TE thing, but give my block every single IProperty from every single registered block so that I don't run into the problem above (is this even possible?) - Someone dynamically change what IProperties my block holds depending on my copied block (which I save in an unlisted property). Are the properties listed in Block#createBlockState malleable, or are they registered once and that's it. (I suspect the latter, seeing that an IBlockState map exists). In all the cases, I somehow need my block to hold every single IProperty and IUnlistedProperty of either its copied block or every single block, so that I can make sure that every interaction/event that would happen to the copied block is duplicated in my new block. As always, if anyone has a better alternative, please tell me.

Just another question, would this be an instance where using a FastTESR is acceptable? I'm not really sure on where/how they are supposed to be used, so a link or something would be helpful for now/going forward.

Hmm, that might cause a problem. I'll see what I can do.

But will that work for rendering chests and shulker boxes, for example? Both of those blocks are ENTITYBLOCK_ANIMATED.

Yea, I've started to fear that. What I was thinking for the TileEntity thing was to, if I used pre-baked models, tell each subblock to provide the TileEntity that corresponds with its pre-defined copied block state. So that a copied chest, for example, would know that it was imitating a chest and provide and instance of TileEntityChest. This runs into problems when blocks check if Block at a certain block position is the same as itself rather than checking if the TileEntity at the position is an instance of its own tile entity, but that's the only real problem I can see with that system. In terms of imitating block's whose render type is not MODEL, any advice/is it possible?

Yes, but I'm trying to make the copied block function exactly like the actual block. Copied chests should look and work exactly like normal chests (to both vanilla and to other mods interacting with said blocks), and the same applies for furnaces, crafting tables, etc. I'm not sure that would be possible if I used my own TE to serialize the copied block data, as I said above. Also, I've run into problems with mimicking blocks that have an EnumBlockRenderType other than EnumBlockRenderType.MODEL, which is another problem I have to figure out.

Yea, that was another one of my first guesses, but I didn't want to use it because it doesn't guarantee the order in all cases, as you pointed out. If there is no other way however, then I suppose it will do. I may not get all the blocks, but at least I will get most of them.

Alright, then my original question stands. How do I affect mod loading order? I read somewhere that its sorted alphabetically, so ideally without having to name my mod 'zzzzzzzz'.

Hi, I currently trying to make a dynamic block that is mod-friendly. By this I mean my mod will generate tons of sub-blocks based on all the game's registered blocks (kind of like Forge/RedPower Microblocks, if I remember correctly). The fact that I want this to be mod-friendly brings up the question of mod loading order: Is there a way to force my mod to load after every other mod? This way, I can ensure that when I generate all the sub-blocks at runtime I account for every single added block, not just vanilla or the blocks added before my mod loads. (And by extension, what is the latest ModState I can register blocks in?) As a side note, the reason I am trying to dynamically register blocks is because I need the data to persist across sessions. I am basically trying to make a camo-like block (from TGG's tutorial here), but instead of getting its copied block from its surroundings, it needs to remember what block it was. My first thought was just to use a TESR and save stuff to NBT, but there could potentially be thousands of blocks in one area at a time (as someone could make an entire base out of this block), so I'm guessing that would cause massive amounts of lag (which is what happens with a mod like Carpenter's Blocks), even if I use a FastTESR. Further, I'm hoping that my camo block can copy blocks with tile entities, like furnaces and chest, and maintain the functionality of said blocks. I don't think that would be possible if I were to use a TE to save my block's data, as I wouldn't be able to use the TE's of those copied blocks. Also if anyone has a better method of doing this, or knows a better alternative, feel free to elaborate. - TMG

Why don't you look at how the debug overlay renders chunk outlines? You can probably adapt that code for your purposes. The border rendering is done in DebugRendererChunkBorder#render I believe. Edit: Actually, looking at your code it doesn't look like you are offsetting the render coordinates by the player's current position. When you want to render something in the world, you typically need to do so. In the TESR render method, glTranslate the three double parameters before rendering your chunk boundary.

You can serialize a BlockPos instance via BlockPos#toLong(). Save that returned long value to an NBT tag via setLong. To deserialize it, simply use BlockPos.fromLong.

Hi, I was just wondering if there is a better/more reliable way of determining if a player has edited a certain BlockPos in a specific dimension. Currently, the best way I can think of doing this is to create a new instance of WorldSavedData connected to World#getPerWorldStorage() (so its dimension-dependent) containing a list of BlockPos. That list would be updated by a method subscribed to the BlockEvent.PlaceEvent and BlockEvent.MultiPlaceEvent events. When I wanted to, I could pull that world storage instance for the world the player is in and check the list to see if a specific BlockPos has been edited (which for my purposes is only when a new block has been placed). The only problem with this that I see is if anything gets placed that doesn't invoke those two events, such as modded items and commands (like /setblock or /fill). Have I missed something, or does anyone know a better alternative/solution? Thanks - TMG

If you don't want it to replace the blocks surrounding your structure with air, remove the air blocks from your template. Also, you're just counting the air blocks that it detects at each y level you iterate over. Nothing happens if it detects a non-air block, whereas I suspect you want the counter to reset back to 0.

Mushroom islands are pretty rare, so if you manually scan each chunk it is probably going to take a while. I suggest looking at how MC generates the biome map to see if you can utilize the world seed to your advantage like TheSunCat suggested. Instead of manually scanning, you might be able to use the seed to determine exactly which chunk would be a mushroom island. That way you would only need to check once (probably). Another issue you may be facing is how you are checking if a certain chunk is/isn't a mushroom island. I'm not at my IDE to check right now, but I'm fairly certain all (or basically all) the methods in World and Chunk that request the biome type load the chunk you are checking. That means that for each position you are checking, the game is generating and decorating the chunk that position is in, which is a huge waste of time and resources. (and probably causes that huge delay you notice when loading the world). Instead, look at BiomeProvider as Lhykos suggested. There is a specific method, not sure what it is called, that can really quickly find a biome in a certain area as it just searches through an array of integers.

It takes advantage of the fact that you cannot attack an entity without facing it directly. The attacker's rotation isn't actually considered when calculating how the entity should be moved, just the X and Z coordinates. This is why it is probably helpful to you if you want the surrounding entities to be knocked back as if they were being hit head-on. (I think this is what you want, correct me if I'm wrong). Also, perhaps Leomelonseeds wasn't entirely wrong in his presumption, as the shield knockback code reads: protected void blockUsingShield(EntityLivingBase p_190629_1_) { p_190629_1_.knockBack(this, 0.5F, this.posX - p_190629_1_.posX, this.posZ - p_190629_1_.posZ); }

I searched through the code a bit. Have you tried implementing the method vanilla uses to knockback an entity when it is hit? You can find the code in EntityLivingBase on lines 1057-1066. (I have no idea if line numbers correspond, they probably don't). It's in this method: public boolean attackEntityFrom(DamageSource source, float amount)

It might not be, I'm just using intuition. I would check, but I'm not at my IDE right now.

I think it's the x component and y component of the vector as a whole. You can calculate each with trigonometry. You already have the magnitude of the vector (you set it to 4), so you can calculate the x and y ratios with (4*cos(angle)) and (4*sin(angle)) respectively. The angle would typically be bound between 0 and 360, but I think Minecraft interprets angles as being from -180 to 180, so you can clamp it via this method in MathHelper (I think this is the method, I can't check right now): public static int clampAngle(int angle) From a physics standpoint, this makes sense. I'm not sure that it corresponds to Minecraft though. Also worth mentioning that Math.cos and Math.sin accept the angle in radians. So first clamp it via the method above, then convert it to radians with Math.toRadians. Then use that angle in your calculations.

How would I go about doing that then? The MapGen fields in the chunk provider are private, so I can't access them through the World object.

When rendering the world, entities and basically everything, Minecraft uses a thing called a Frustum, which is basically just the camera. The Frustum helps the game determine whether or not it should bother rendering stuff because it can, given an AABB or set of coords, determine if they are within the render scope of the viewing entity (player in most cases). TileEntities use this to check whether or not they should be rendered. You may be able to use it to your advantage if you need to check if a certain block is visible to the player. I haven't really played around with Frustums and the render engine much, but try something like this where you are calling your code (and if I'm wrong hopefully someone with more experience can correct me, or destroy me, both tend to happen from time to time): - Create a new instance of Frustum - Set its position to the position of the player (see lines 1268-1273 of net.minecraft.client.renderer.EntityRenderer) - Check if your block visible with this method inside Frustum: public boolean isBoundingBoxInFrustum(AxisAlignedBB p_78546_1_) where the passed parameter is the offset AABB of the specific block you are looking for. I think for your case you can construct one via: public AxisAlignedBB(BlockPos pos) This does require you to know the BlockPos of your block when determining if it is within view of the player, but it looks like you already know that seeing you tried your ray trace method. Of course, this entire method is speculation on my part. I'm not sure how the performance differs, or if this is even a remotely good way of doing this. EDIT: Never mind, I just tested it and I don't think it works. It only seems to care if the player is not directly looking at it, ignoring blocks placed between it and the player. Your ray trace method might be the best option after all. Looking at how vanilla mobs determine if entities are within their view, it looks like they raytrace as well. See World.rayTraceBlocks: public RayTraceResult rayTraceBlocks(Vec3d vec31, Vec3d vec32, boolean stopOnLiquid, boolean ignoreBlockWithoutBoundingBox, boolean returnLastUncollidableBlock) SECOND EDIT: Also for reliability, you might have to take into account the player's FOV, which is client-side. Not sure if rayTraceBlocks takes that into account, but I doubt it. Also, you might be able to adapt qCraft's block observation code, which you can see here. I think it uses ray tracing as well, however.

In a future update? Will that be easily accessible, say whenever a Chunk in generated, so I could theoretically make a mod as I described above?

Forge usually doesn't want to alter vanilla behavior, so it's probably a bug.

That would certainly work for vanilla, I think, but how would I account for modded structures? If a mod decides to spawn an aboveground temple with a throne made of gold blocks, it might flag it as an Ocean Monument when it's obviously not. I suppose I could check the biome, but that wouldn't work if that mod decides to spawn that temple structure in ocean biomes as well.

What method did you try for checking if each block is within the player's view?