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.

One thing I noticed is that every time syncConfig is called, you're registering the mod instance as an event handler. You don't need to do that. You might also find it more convenient to put the configuration event change method in the configuration class. I just recently did something like what you did. Here is my solution: https://github.com/Himself12794/powersAPI/blob/develop/src/main/java/com/himself12794/powersapi/ModConfig.java Main mod class here: https://github.com/Himself12794/powersAPI/blob/develop/src/main/java/com/himself12794/powersapi/PowersAPI.java And I register it here: https://github.com/Himself12794/powersAPI/blob/develop/src/main/java/com/himself12794/powersapi/proxy/CommonProxy.java Hopefully that helps. If not, I can look at what you've done again much better once I get access to more than just a mobile device.

I do that sometimes for legacy reasons, or the fact that it's easier to make objects in a chain. Sometimes though, it's just a preference. Either way, it's no longer that way in the 1.8 update.

Your solution is the same as what I had originally come up with (except I didn't know x and y should be inverted). I don't understand why it doesn't seen to work, because it seems like it should work, but for some reason it is off. I am using the caster's look vector too, since the power entity is modeled after a throwable entity. I really need to redo the power entity. When I first made it, I knew nothing about coding and pretty much copy pasted it. Now I've learned so much, and probably should start scratch since I actually know how it works.

That still seems to offset it in a specific direction, regardless of the player's orientation. I did some digging through EntityThrowable , and came up with something similar to this: double offset = 0.65 * PowersEntity.get( throwerIn ).getSecondaryPower() == spell ? -1 : 1; posX -= (double) (MathHelper.cos( this.rotationYaw / 180.0F * (float) Math.PI ) * offset); posY -= 0.25; posZ -= (double) (MathHelper.sin( this.rotationYaw / 180.0F * (float) Math.PI ) * offset); I've already modified the above to test if it works for me. So far, it's the closest thing to what I'm trying to do. I'm going to look through the EntityArrow class and see if I can find a less generalized version, but I believe I'm on the right track. Edit: EntityArrow uses the exact same thing, so I guess I'm satisfied with this result. Mostly, I just don't want the flame particles to obstruct the entity's view. How it looks to others is purely aesthetics.

I have no problem getting its heading, I just use its normalized velocity vector. I don't want to change that vector, I just want to offset the location. Also, my projectile only fires every 2 ticks. I had it as a projectile because I really wanted it to behave like one, i.e. have a modifiable velocity. I actually do have an instant variant, it just doesn't have particles. I'll start looking through the constructors and see if I can determine the underlying logic.

I tried that, but the offset is static, it always moves them in a specified direction, regardless of the orientation of the player. Perhaps I need to take into account the pitch and yaw?

I have a a flamethrower I've created for my mod, and it works fine, the only problem is that when I use it, it's coming directly out of the player's face. I want to offset so that it appears to be emanating from the player's hand. I only want the the flame particles to be offset. Here's my code for generating flames particles: @Override public void onUpdate(EntityPower spell) { if (!spell.isInWater()) { World world = spell.worldObj; float distTraveled = getSpellVelocity() * spell.getTicksInAir(); if (distTraveled >= 5) { spell.setDead(); } boolean positionInvalid = false; awaylabel: for (float j = 0.0F; j < 1.0F; j += 0.05F) { for (int i = 0; i < 10; ++i) { BlockPos pos = new BlockPos( spell.prevPosX + (spell.motionX * j), spell.prevPosY + (spell.motionY * j), spell.prevPosZ + (spell.motionZ * j)); Vec3 motionVec = new Vec3(spell.motionX, spell.motionY, spell.motionZ); motionVec = motionVec.normalize(); if (UsefulMethods.getBlockAtPos(pos, world).getMaterial().isSolid()) { positionInvalid = true; break awaylabel; } world.spawnParticle(spell.castState < 4 ? EnumParticleTypes.FLAME : EnumParticleTypes.LAVA, spell.prevPosX + (spell.motionX * j) - world.rand.nextFloat() * 0.5F, spell.prevPosY + (spell.motionY * j) - world.rand.nextFloat() * 0.5F, spell.prevPosZ + (spell.motionZ * j) - world.rand.nextFloat() * 0.5F, 0, 0, 0); } } if (spell.getTicksInGround() > 0 || positionInvalid) spell.setDead(); } else spell.setDead(); } This is called every tick on my flamethrowing projectile. How can I offset this to the right (relatively), so that it appears to be coming from their hand? Any assistance is appreciated. For reference, the rest of my code can be found here: https://github.com/Himself12794/Heroes-Mod/blob/6edb401796e93d54cbbf6f0a1e90b0a1e4a8324e/src/main/java/com/himself12794/heroesmod/power/Flames.java

I was sure that item updates occurred on both Client and Server. Anyways, if you're trying to do what I think you're trying to do, you can always subscribe to LivingUpdateEvent and manually call the update. I found that IEEP doesn't always have the same values on client as server. (Maybe it does, and I'm just not using it correctly) But when my player first joins the world, I sync them once, and updates run on both sides.

I'll be honest here and say that I do not know who OP is. My idea was that you don't have to change classes around to add properties, but yeah, IEEP probably isn't applicable here. I'm new to it.

Try what I mentioned above. It works, trust me it does.