Jump to content
Search In
  • More options...
Find results that contain...
Find results in...

the_infamous_1

Members
  • Posts

    35
  • Joined

  • Last visited

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

the_infamous_1's Achievements

Tree Puncher

Tree Puncher (2/8)

1

Reputation

  1. Now I've run into this crazy bug. If I make the entity's width small, and then try to grow it on the axis that is larger, then the world gets corrupted somehow as mobs cannot move / start floating on collision and leaves decay rapidly. If I make it big, and instead shrink it on the axis that is smaller, then it's ok. The small-then-grow approach makes the suffocation hitbox correct, while the large-then-shrink approach makes it not.
  2. The thing is, I need the entity width to be a large number so that the entity is wide enough on the X-axis, but it needs to be drastically thinner on the Z-axis (I'm talking 6.0F wide on X, 1.0F wide on Z). Entity width is used for both the X-axis width and Z-axis width, so it's not like I can make them separate. This is why I have to override getBoundingBox and shrink the bounding box along the Z-axis. I will look into eye height, though, thanks for that tip.
  3. For clarification, when I am talking about the hitboxes and their colors, I mean the ones that show up after pressing F3+B in-game. I have a mob that is drastically wider on the X-axis than it is on the Z-axis, so I've been overriding Entity#getBoundingBox to return one that is shrunk on the z-axis, which does work for the general hitbox of the mob (the one with a white outline). However, the suffocation hitbox (the thin red hitbox that determines if a mob should be suffocating from being inside a block) still uses the same X/Z dimensions. I can't seem to find a method to override in Entity/LivingEntity that allows me to change the suffocation hitbox, if there even is one. As a work-around, I've overridden LivingEntity#isEntityInsideOpaqueBlock but of course the displayed suffocation hitbox is still the same.
  4. That's correct. I do try to check to see if the mob was already armed by the vanilla onInitialSpawn function and then re-arm them, but I don't know if that's actually working because I can still get mobs spawning in with vanilla equipment. I imagine I can just run an additional check to see if the mob currently has vanilla armor/weapons, and then run them through the re-arming process an additional time, but that seems wasteful.
  5. Okay, found a workaround! (I think) public DifficultyInstance getDifficultyAtPosition(World world, BlockPos pos) { long inhabitedTime = 0L; float moonPhaseFactor = 0.0F; //HardSteel.logger.info("Inhabited Time is " + inhabitedTime); //HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); if (world.isBlockLoaded(pos)) { //HardSteel.logger.info("Inside isBlockLoaded check"); moonPhaseFactor = world.getCurrentMoonPhaseFactor(); //HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); // world.getChunkAt(pos) // returns this.getChunk(pos.getX() >> 4, pos.getZ() >> 4); // which means it gets the chunk at (X / 2^4), (Z / 2^4) if(world.getChunkProvider().chunkExists(pos.getX() >> 4, pos.getZ() >> 4)){ HardSteel.logger.info("Chunk Exists"); Chunk chunk = world.getChunkAt(pos); inhabitedTime = chunk.getInhabitedTime(); //HardSteel.logger.info("Inhabited Time is " + inhabitedTime); } } //HardSteel.logger.info("Done with isBlockLoaded check"); //HardSteel.logger.info("Inhabited Time is " + inhabitedTime); //HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); return new DifficultyInstance(world.getDifficulty(), world.getDayTime(), inhabitedTime, moonPhaseFactor); } As long as I check for the chunk actually existing at the position before I try to get it, everything works fine and I don't get caught in that infinite loop I would get caught in previously.
  6. Alright. I assume this is the case for 1.15.2 as well?
  7. Finally got my Github to work, here's my capability stuff: https://github.com/Thelnfamous1/HardSteel/tree/master/src/main/java/com/infamous/hard_steel/capabilities https://github.com/Thelnfamous1/HardSteel/tree/master/src/main/java/com/infamous/hard_steel/events Note that I committed this with LivingSpawnEvent.SpecialSpawn instead of EntityJoinWorldEvent.
  8. I created a new world just now using LivingSpawnEvent.SpecialSpawn handling instead of EntityJoinWorldEvent. I went into the Nether, and every single Zombie Pigman and Wither Skeleton spawned with the vanilla swords instead of modded ones. The only time they ever spawn with modded swords are when they are spawned with a spawn egg and when they teleport to the Overworld via Nether Portal. Overworld mobs do spawn naturally with modded stuff.
  9. I want to (re-)arm mobs with my modded armors and weapons instead of vanilla armors and weapons. I'm attempting to achieve this by recreating almost exactly how vanilla arms mobs, by using difficulty instances. I can do this just fine by using LivingEntitySpawn.SpecialSpawn (which also works for old worlds), but then I cannot get the Nether mobs (zombie pigmen and wither skeleton) to naturally spawn with modded stuff, so I am forced to use EntityJoinWorldEvent instead.
  10. I've been having issues with trying to get the DifficultyInstance in the event's position in the world during EntityJoinWorldEvent. I've recreated the method getDifficultyForLocation below and started debugging it by using it my event handler instead of the original method: public DifficultyInstance getDifficultyAtPosition(World world, BlockPos pos) { long inhabitedTime = 0L; float moonPhaseFactor = 0.0F; HardSteel.logger.info("Inhabited Time is " + inhabitedTime); HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); if (world.isBlockLoaded(pos)) { HardSteel.logger.info("Inside isBlockLoaded check"); moonPhaseFactor = world.getCurrentMoonPhaseFactor(); HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); // world.getChunkAt(pos) // returns this.getChunk(pos.getX() >> 4, pos.getZ() >> 4); // which means it gets the chunk at (X / 2^4), (Z / 2^4) Chunk chunk = world.getChunkAt(pos); inhabitedTime = chunk.getInhabitedTime(); HardSteel.logger.info("Inhabited Time is " + inhabitedTime); } HardSteel.logger.info("Done with isBlockLoaded check"); HardSteel.logger.info("Inhabited Time is " + inhabitedTime); HardSteel.logger.info("Current Moon Phase Factor is " + moonPhaseFactor); return new DifficultyInstance(world.getDifficulty(), world.getDayTime(), inhabitedTime, moonPhaseFactor); } I notice that when opening an old world - meaning, a world that was created before I started ever handling EntityJoinWorldEvent - I can't get past "Chunk chunk = world.getChunkAt(pos)" during world load, causing the world loading process to never finish even though it says "100%" on the screen. Is there a work around I can use, or someway I can account for not being able to get the chunk? I do notice that isBlockLoaded is a deprecated method, but I don't know how to replace it if it's necessary.
  11. So what I've noticed is that if you spawn too many mobs in a rapid succession (like I usually do during testing) and then save/quit/reload, most of them won't have their capabilities preserved. If their spawning is done normally or slowly, then it will work as expected.
  12. Okay, I shifted setting the "isReArmed" capability to true into the if (World.isBlockLoaded(entity.getPosition) statements during MobEquipEvent (it was outside before). I also add a logger to detect if "isReArmed" is ever set to true before those if statements and it turns out, they are, so I am successfully setting the isReArmed capability of a mob to true. In-game, sometimes entities have their armor and weapons preserved when exiting and reloading, but sometimes they don't. Something about saving and quitting too quickly after a mob has spawned causes it to not get its capability saved to disk I imagine. Here's the updated MobEquipEvent class: https://pastebin.com/w9Z9ArWK
  13. Have technical issues with Github at the moment, sorry. ReArmerStorage: https://pastebin.com/379GBsq7 ReArmer: https://pastebin.com/yNQ9Wz0g IReArmer: https://pastebin.com/fu5HJFrA
  14. Great. Bad news, however. Mobs are still re-arming themselves when reloading into a world. Do I need to make sure in AttachCapability that a mob doesn't already have a capability? It seems like when I set a mob's isReArmed capability to true, either it doesn't actually save or each mob keeps getting a new capability with a default value of false.
×
×
  • Create New...

Important Information

By using this site, you agree to our Privacy Policy.