Hey there,
is there a way to add footstep support for LittleTiles? Maybe some sort of hook for blocks to return the material?

Honestly I would have to load this mod up in a debugger to see how DS interacts with LT "blocks" before I can answer with any specifics about what needs to be done. It is quite unique in its approach.

As for Material type DS does make use of that figuring out an acoustic profile for a IBlockState. If it falls in line with one of the Vanilla materials DS uses a primitive map based on Material type to figure out what sounds to play. If for for some reason it doesn't understand the Material, like when a mod has a custom material, it falls back to play whatever the step sound is reported by its custom material.

EDIT: Additional comment. With the latest series of BETAs if you enable DS debug logging you can use a carrot on a stick as an inspection tool. A small popup will display above the cursor informing you how DS sees that block/entity configured.

I took a look at the challenge and I think code changes need to be made on the DS side of the house. These changes are related to some technical debt I keep deferring because there wasn't a need to address. I guess now there is. :) Also I need to provide a mechanism to not cache calculated acoustic profiles for certain block states because they may be dynamic, like in the case of LT block states.

As for LT there are two potential approaches for handling block sounds:

• Calculate the material type of the block based on the substrates used to construct the block. Not sure how you would go about deciding how to do this, but from a DS footstep perspective it would be interested in the "surface".
• Calculate the sound of the block and report via IBlockState::getSoundType (the state sensitive version). This would allow the block to have a material type separate from the sound it produces. Which sound is reported for the block should be based on the substrates involved similar to how material is determined in the first bullet.

EDIT: As an aside, footprint handling is also driven in part by the material type of the block. In the case of LT if a block is comprised of sand footprints would need to be generated. There is work on my side to make things work for LT blocks, but I think having both of the bullets implemented would help all round.

No need to hurry :D

BTW i finally managed to write the pr for the sound engine fix.

I noticed the PR - nice! Now we see how long it takes Mezz to scrub it. :D

Do you want to support this new interface on just 1.12.2, or would you rather it go all the way back to 1.10.2? I can take either approach - the DS code base is pretty much the same between the versions.

Ok, to be honest i have no idea how your mod works, but the changelog says you added extra support for c&b, which is a quite similar mod. So maybe it's already possible or i misunderstood something.

A block of LittleTiles contains smaller pieces of a block which are called 'tiles'. I guess the easiest solution would be to find the tile the player is walking over and use the sound type of it?

The C&B mod support was for acoustic profiles of blocks it adds, not anything specific to "tiles".

Thinking about the problem a bit it is similar to what I deal with in terms of facades. What DS does is query the facade block looking for the block that is being used to texturize the facade, and then uses that block to develop an acoustic profile. Those interfaces deal with BlockPos positions and facings so it does not map 100% to what I think we need here, but I do think we can do something similar. An interface can be defined where I can invoke a well known method to get the underlying IBlockState for a tile. What parameters I would need to pass in I am not sure, but it probably should be a Vec3d or something since something more granular than a BlockPos would be needed.

Have two ways in mind:

1. I will add an interface to LT which includes this method: Map<AxisAlignedBB, IBlockState> getBlockStateBoxes(IBlockAccess, BlockPos);
2. You create an interface which i can implement: IBlockState getStandingOnState(Entity entity, IBlockAccess, BlockPos).

I would prefer the second one, because it think it would be easier for both of us (already implemented some calculations to get the right tile).

Second one because it is much simpler from my perspective, but it should be something like a Vec3d instead of Entity. Reason is that the actual location of the footstrike is different than an Entities posXYZ. My logic takes into account things like distance from the vertical centerline as well as body rotation to figure where a footstrike occurs.

That's fine, too. So just let me know once you have created the interface.

OK - may be a little bit. Trying to get my mod to release with the current set of changes. As soon as that is done I will put in the interface as the first thing.

I could do it for all versions, but first of all I will try to merge this one.

@CreativeMD Curious - but could I do a raytrace into the block using a vector pointing downward into the block and get a raytrace result that contains the proper IBlockState?

Good! Simplifies things a bit.

Yes of course you could do that: https://github.com/CreativeMD/LittleTiles/blob/1.12/src/main/java/com/creativemd/littletiles/common/tileentity/TileEntityLittleTiles.java#L869

But i would rather recommend to use an AxisAlignedBB and expand the bottom part. Check for intersecting "tiles" and select the highest.

OK. I will try doing it that way before we go through the effort of doing a formal API. If I can get it to work with existing MC/Forge mechanics it means no work on your end and I could also support other "tiled" blocks out of the box.

But there is still the need for an interface, so i can return the matching results.

Maybe I don't understand the method, but doesn't addCollisionBoxToList() do that already? I pass a slightly expanded entity BB and a list object that you could add collision boxes that intersect with the player BB? I would then have to sift through the resulting BB list finding the best candidate for the step.

Yes, but the BB contains no information about the blockstate.

Ah! Right. I need more coffee. :)

I added a method for you to the interface ILittleTileTE. It returns the blockstate beneath the given BB.

I assume you have separate boxes for right and left foot. If so, there is a special case where only one foot touches the ground:

Realistic checks for actual collision vertical wise, while the other one searches for the highest tile. I don't know which solution you prefer. Please keep in mind that it might return null.

The actual implementation: https://github.com/CreativeMD/LittleTiles/blob/1.12/src/main/java/com/creativemd/littletiles/common/tileentity/TileEntityLittleTiles.java#L1071

I can work with that. The logic in the step generator does similar things related to the left foot scenario. And I have a recollection of needing both realistic true/false scenarios depending on what is being checked.

BTW, how does LT handle tiling fences and collision boxes? Those things have a 1.5 block (or so) collision box but render 1 block high.

You can only cut ordinary blocks (no chests, fences, stairs or any other cutsom blocks).

As I added support for chisel connected textures, I didn't want it to be strict, but always show the connected texture even if the connecting block is not located at the side. In order to do so I need to know which block is asking for the connection, so I asked the author of chisel to implement a new method for their IFacade interface. Of course this doesn't work in your case, because it just checks whether the connecting block is inside the tileentity or not.

OK. With my fixes DS will use the ILittieTile interface over the IFacade so everything should be good.

Pushed a BETA of v3.5 to CurseForge. Note that the new version has a library dependency on OreLib (another library mod I made). Make sure you read the release notes prior to upgrade.

It could be mine. Need to get it into a debugger. How thin can those layers get - 1/16th of a block height?

Nice! I will test it right now :D

Unfortunately I found an issue. This occurs if the tile the player is standing on is thin: https://youtu.be/FVZOCidCxK0

I don't know if this is caused by my code. Do you have an idea?

@CreativeMD Took a look at it and I am not sure where the issue may be. Here is where I build up the AABB and then call into your TE. It could be that I am building the bounding box incorrectly.

Okay I did some debugging. The player position is at y=5, the box the tileentity gets from your mod is: box[-1142.7368274487358, 4.9, 398.34219768455085 -> -1142.2368274487358, 4.9, 398.84219768455085] .
I don't know if that is intentional, but I thought the box was supposed to be at the players feet. Meaning y would be something like 5 to 5.125. The vector you use for the anchor point is below the feet. So you can either make one of the anchors go up by 0.1, or fix the vector itself (no idea what this vector is about anyway). I can also change calculations on my end if you want to. Just let me know what you think.

I can make the tweaks at my end. As for why it's 4.9 the footstrike calculation subtracts .1 from the player location in order to probe downward. For the case of LittleTiles I need to offset it back and extend a little bit as you point out. And I also need to make some tweaks to the size of the BB because +/- 0.25 is too large.

Nice when will it be released?

In a couple days. I try to avoid making too many releases over a short time. For a single player its not too bad, but for someone that is trying to maintain a pack update fatigue sets in.

@CreativeMD Working on this for my v3.5 release and noticed something in your getFacade() method of BlockTile. It essentially returns back the BlockTile state. I think it should return the IBlockState of the underlying block. For example, I used the hammer on a jungle wood block. Using a hammer on it converts it to a BlockTile. I would expect, though, that getFacade() would return a jungle block since that is the "underlying block".

Those two methods are implemented for chisel connected texture compatibility. The first one essentially does nothing, the second one checks whether the block which asks for connection is inside the block (source).

I added a method to the ILittleTileTE interface for you some time ago (source), which is implemented in the tileentity (source). You should use that one instead. It is also explained above.

Right. But "out of the box" DS supports the Chisel CTM facade support. IIRC there was some discussion as to why it didn't work at a basic level whereas the facade support worked with other mods. :)

EDIT: As an FYI I have things working with the ILittleTileTE interface. All is good. Turns out that this exercise also allowed me to get support for Forge Multipart as well. I had to restructure the internal workings of figuring the footstrike from being block based to point of impact base. Now all I have to do is figure out how to get the elevation of the footprints correct and I will be done. :)