Malkierian

Second page bump. No one has anything?

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.java EntityAcidTNT.java RenderAcidTNTPrimed The weird thing is that all three are almost identical to their vanilla TNT equivalents, so... Also, I tried using RenderTNTPrimed as the renderer registered for EntityAcidTNTPrimed, and that still made the block disappear (which is the root problem for the primed rendering).

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 instead of all these instances. I initially moved away from the metadata block process because it seemed unnecessary anymore. Is having them be subitems on an ItemBlock the only option I have?

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.

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.

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 invalid.

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.

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 this was the result on the other side: When it should have done this: Please tell me this isn't intended behavior...

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' interactions with water to checkerboard (for example, when I have acid flow over water, it's supposed to turn the source blocks to clay. This interaction works for the first time a flow is calculated, but on the next one, the water source block gets deleted, causing the acid flow to go under the surface of the water, which then causes the next one down to be hardened, and then the next ones out from there horizontally get deleted, etc). Is this a problem with my liquid implementation that I can fix, or is this merely a known bug that cannot be remedied? I get the feeling that this is because of the instantaneous change that happens from a static block to a flowing block before it sees that the source that was turned to clay is a solid block, and my code (which only compares to Blocks.WATER) doesn't account for that change, and thus the water source interaction is allowed to happen, but I can't find out how to check for a flowing source block in 1.10.

You mean getting the block that a thrown item rests on?

The method you were using was outdated a long time ago when we stopped worrying about block IDs.

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.

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...

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.

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 somewhere.