Himself12794

By custom new dimension, do you mean one that has no biomes, nothing generated?

The look vector for an entity is not a position in the world. It's just an angle, basically. You're treating it as a position. (Look vector values are only between -1 and 1). To find the position you are looking at, you can a function found here: http://jabelarminecraft.blogspot.com/p/minecraft-modding-extending-reach-of.html That function only works client side, so a universal version is like so: The parameter dist is the max distance to check for a position. The moving object position returned is where you want to spawn the explosion.

I found that creating a custom dimension is surprisingly easy. Just doing this: public void registerDimensionId() { if (!this.registeredDimension) { // Your dimension id might already be taken by another mod, so this helps avoid conflicts customDimensionId = DimensionManager.getNextFreeDimId(); DimensionManager.registerDimension(customDimensionId, 1); } } Appears to work. That's just registering the dimension with the Hell provider. Then, on ore generation, just check for the dimension id of your dimension. Creating a world provider is a bit more involved, but not necessary if you just a dimension with different ore generation.

I would think that doing it once per explosion then storing it would be faster, since you're only doing it once. You could try both ways, test performance, and if there is no noticeable difference, you could do what you are most comfortable with. For me though, unless the speed benefits contrast in a large manner, I tend to go for whatever I come up with first that works.

Yeah that's just something I threw together quickly as a proof of concept. I didn't bother making it scalable or compatible with custom blocks since you already had. It got me thinking, though. Perhaps for each IHealable, you can require a priority. Then, use that priority to determine removal and replace order. Just a thought, though.

So, I was working on a solution and I came up with this something like this. I'm not sure how you are storing blocks to be removed, but I used a Map<BlockPos, IBlockState>, and an additional map for tile entities. To remove blocks, something like this worked for me: Might not be the most efficient way, but it seems to work. For replacing the blocks, it was similar, but just a bit more complicated. Assuming the blocks are stored in a map like above, replacing them like this should work. If you iterate over the list 'ordered', and then iterate over each map and replace accordingly, you shouldn't have too many problems. Only thing is that doing it like so seems to screw over doors and beds, but it seems you already have a workaround for that. Again, this probably is terribly inefficient, and ugly, but it seemed to work.

Yeah, I've learned the hard way Minecraft isn't thread safe, that's why I was so curious about how you accomplished that.

Now I'm curious. How exactly did you do that in the video? I'm assuming you get affected block positions from explosion event, but how did you get them to slowly regenerate, instead of all at once? Did you start a new thread for that?

The math helper cosine and sine functions values are already calculated and stored in an array. It has roughly 65,000 values calculated. That makes it a bit faster than native calculation and the values are more reliable, I believe. This is just based off my analysis of the MathHelper class . The values are from 0 to pi / 2, with increments of roughly 65,000.

If my vector math is correct, it should be this: double pitch = -Math.asin(vec3.yCoord) * (180 / Math.PI); Edit: A faster way to calculate rotational head yaw. double rotationYawHead = -Math.atan2(vec3.xCoord, vec3.zCoord) * 180.0F / (float)Math.PI; Since you are getting this from the look vector, the yaw is for the head, not the body, which differs slightly. Another Edit: After looking at it again, the above concerning the yaw appears to be only mostly correct. It gets the correct base value, but it seems random how many times 360 must be added or subtracted. That shouldn't make a difference, I think, since if you rotate 360 degrees you are back where you started from. I could be wrong though.

Probably what's happening is you are removing the supporting block before the redstone dust and torches. Then it drops as an item before you removed the actual block. I'm not sure what all the flags represent, but I'm sure one of the flags must allow you to remove the block without updating the surrounding blocks. If not, perhaps you should try removing all the blocks that require a support, then those that don't.

Have you tried using world.setBlockToAir? That might stop some of the randomness.

Ah yes, thank you. Adding that task to the .travis.yml does allow the build to successfully pass. Thanks! I'll keep an eye FG just in case that is no longer required.

For my mod, I have it setup through GitHub to automatically build using CI Travis. Before, I was using Forge 1443, and it was working fine, but now that I've updated to 1514. I can't get it to build. It goes through the build as it should, but when it reaches the deobfMcMCP task, it exits with the exception "Your access transformers be broke!" Here's my build.gradle, it only has minimal tweaks: https://github.com/Himself12794/Heroes-Mod/blob/d058717d687b06c1f4925c48db55a9ad14470f59/build.gradle Here's the full log: It builds fine locally, so perhaps it doesn't have to do with Forge? Either way, any assistance is appreciated.

Found it. In your config mod gui, here: https://github.com/xJon/Jons-Useless-Mod/blob/master/src/main/java/xjon/jum/client/gui/UselessConfigGui.java#L17 You are registering the gui with your mod name, not your mod id. That's why the event isn't triggering. I tested it and used the mod id instead of mod name, and I was able to get it to work.