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

Malkierian

Members
  • Content Count

    42
  • Joined

  • Last visited

Community Reputation

0 Neutral

About Malkierian

  • Rank
    Tree Puncher

Converted

  • Gender
    Undisclosed
  • Personal Text
    I am new!
  1. So I have a custom TNT-type block, Acid TNT, that I have implemented, and the block and entity are working just fine (I can activate it, the explosion is run, etc), however the rendering for EntityAcidTNTPrimed is non-existent. I have another entity being rendered properly in the mod, so I know my registration process isn't at fault. I tried decompiling another mod, TNT Mod, to have a look at their code, but I couldn't see anything different between their process and mine. I really can't figure it out. Here is the relevant code. Registration (called from preInit()) BlockAcidTNT
  2. So I have my code set up such that (following diesieben07's tutorial here) I have the ordering list setup, and it works just fine, but I have to use individual Item references in order to get all of my blocks in the ordering list. My question is, since a good number of them are instances of just a few classes, is it possible to send a reference to the class into the sorter instead of having to list every one by itself? For example: All of those glowcloths listed first. It would cut down my code by 7 references if I could just use the BlockGlowCloth class as the sorting element in
  3. Was this a change in 1.11? Because that's not true in 1.10. Just want to know for when I update my mod to 1.11.
  4. Little bit more information, if I set the viscosity of my caustic fluid to a certain level, then the interactions manage to keep up (with how I've set flowInto et al), but below that level, it's like the block change events can't keep up with the speed of the fluid, and it still flows into the water sources. Now THAT sounds like a bug in Forge, I may just have to work around it and not have super fast liquids.
  5. Alright, so I changed canFlowInto and even displaceIfPossible to only return true when the block it's flowing into is air or replaceable (check by Material::isReplaceable()), and I still get the checkerboard problem, but at the very least I don't get that constant back and forth shown in the first gif/video. I didn't see any reason to override flowIntoBlock, since it only used displaceIfPossible anyway. Also, Block::getMapColor() is deprecated in 1.10, meaning it's likely to be removed soon, so your point about using that instead of MaterialLiquid to customize map colors seems
  6. Well, they're not water, so I wouldn't want them to be handled in that way. What other reasons would you use MaterialLiquid than to make it something other than water? I'm not trying to be belligerent or anything, I honestly want to know. Why would you want to set a fluid's material to water when it isn't water? Or, what other way is there to handle that without making its material water? But thanks for the information about canFlowInto and flowIntoBlock, I'll look into those.
  7. So I guess people need more information, so here's a video (gif) showing what I'm talking about: This happens even if I don't have my own custom class and just use BlockFluidClassic for my fluids, so there's no custom code to worry about interfering. They are all of MaterialLiquid with varying map colors. But, even if I completely disable my custom blocks' onNeghborChange methods by not calling the superclass's method, it still does it, so it must be in water's code. And it doesn't check my liquid's stuff first, so it ends up doing this, if I have my interactions enabled: And
  8. So, most parts of my liquids are working properly now, thanks to my other thread, but that thread is long gone now, so no necro here. Anyway, my new problem is that when I place my custom liquid (which is made with MaterialLiquid), when it flows into a water source block, it deletes it. This is default behavior, I commented out all references to onBlockAdded or onNeighborChanged. It must be behavior in the water block itself, which means I can't change it by normal means. This throws all of my intended interactions for a loop (when I have them enabled), causing any of my fluids'
  9. You mean getting the block that a thrown item rests on?
  10. The method you were using was outdated a long time ago when we stopped worrying about block IDs.
  11. Which version of MC are you modding for? At the very least, 1.10 and above (and probably 1.9, as well), would require you do something like this: Block blockClicked = world.getBlockState(new BlockPos(x, y, z)).getBlock(); EDIT: On top of that, I would think that any method in Item that would give you the block clicked would give you the Block, or at least a BlockPos, not xyz coordinates.
  12. Yes! That's it! Most excellent. The only thing left for me to figure out is how to prevent the default water-colored splash and make splash particles of my fluid's colors...
  13. Yes, that almost could do it, except that there's no way to change how the water texture is rendered. I managed to cancel the event for rendering the water overlay, but I can't seem to get it to use my own fluid blocks to overlay. Even posting a new event with the OverlayType.BLOCK, with one of my other blocks, it still only cancels. It doesn't do another overlay. And there's no way to change the block used in the same event that was fired. And since I can't follow the code in the normal way, I don't know how to find out how it processes the overlay events to make my fluids compatible.
  14. As far as I can tell, RenderGameOverlayEvent doesn't have anything on the color an overlay has from being in a liquid. If I'm looking at it wrong, then I need better documentation. Thankfully, though, Block::isEntityInsideMaterial did most of what I was wanting (as far as interacting with the liquid, being pushed by flow, swimming instead of jumping, etc). It's unfortunate that going under the surface of the liquid can only turn the screen bluish for now, but it's not like I haven't been dealing with that since I started handling the mod anyway. Hopefully SOMETHING will crop up
×
×
  • Create New...

Important Information

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