Jump to content

Sangar

Members
  • Posts

    5
  • Joined

  • Last visited

Everything posted by Sangar

  1. - I've been using .equals() and that seems to work out without problems. == should usually work, too, since that's identity equality and there should only be one instance per item type (anyone correct me if I'm wrong on this). - Have a look at the static methods in Item and Block, e.g. Item.getItemFromBlock. - Yes, just put your .lang files in your assets/modid/lang folder and you're good. - Icon has been renamed to IIcon, IconRegister to IIconRegister, otherwise it's the same. Same with (I)Resource and (I)ResourceManager btw. - setupDeobfWorkspace should give you a good start, you'll at least get the sources again like that. Other than that transformers haven't changed much, I think, except for one method name change in the plugin interface. My transformer worked pretty much without changes, IIRC.
  2. Yeah. I overrode collisionRayTrace and synchronized it with setBlockBoundsBasedOnState in my block that I had the problem with. Haven't run into the issue since, but since it's a threading issue I'll keep an eye on it for it a bit longer... Some context: I have a block that "moves", interpolating its bounding box while in transit. I'll not get into the details, to keep this short, but I don't want raytraces that originate in that block to hit it. That check looks like so: override def collisionRayTrace(world: World, x: Int, y: Int, z: Int, origin: Vec3, direction: Vec3) = { // Set interpolated bounds for server/client. setBlockBoundsBasedOnState(world, x, y, z) // Get interpolated bounds, should be server/client, could be the other. val bounds = getCollisionBoundingBoxFromPool(world, x, y, z) if (bounds.isVecInside(origin)) null else super.collisionRayTrace(world, x, y, z, origin, direction) } Before synchronizing it sometimes incorrectly got hit, because the animation on the client was a bit behind the server (the movement gets triggered by a network packet). Sounds confusing? Yep. This was quite the pain to track down...
  3. I guess my question is this: is Block.setBlockBoundsBasedOnState meant to be sided (client/server only)? Because if it's not, then this method together with Minecraft's one-instance-per-block policy is a major design flaw when used in single player. Why? Because it usually sets the block instance's (min)|(max)[XYZ] fields. On the one block instance used by both server and client thread. Essentially what my problem boils down to is this: - Server thread calls block's setBlockBoundsBasedOnState , sets Block.minX , ... to whatever based on the server's world state. - Server does some other stuff / OS decides to pause the server thread. - Client thread calls setBlockBoundsBasedOnState and sets the bounds to something else, based on the client's world state. - Server thread continues doing stuff, does something based on the block bounds which are now the client's bounds, not the server bounds. Which leads to stuff breaking. Badly. What I'm doing, specifically, is using world.clip to check if a ray intersects some blocks with possibly dynamic bounds. Am I using setBlockBoundsBasedOnState wrong, or is this just how it is and I simply have to throw a bunch of synchronize s into my code?
  4. From what I understand indestructible blocks generally have a negative hardness, so that's one thing. Aside from that have a look at the net.minecraftforge.common.ForgeHooks class, in particular its canToolHarvestBlock/isToolEffective methods, those should help. You could pass the different tool tiers to check a block's level.
  5. I have the same problem, and no idea why this is happening. My workaround is to simply add a language section to my pack.mcmeta, which is quite possibly a bad idea, but it works: { "pack": { "pack_format": 1, "description": "OpenComputers" }, "language": { "en_US": { "name": "English", "region": "United States" } } } Edit: oops, sorry for the semi-necro, I found the topic via google and didn't check the date.
×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.