In Mineblocks, how do you handle unique properties such as the bounciness on Slime Blocks, the slipperiness of Ice Blocks and different block hitboxes (such as slopes)?

PeterGlassJar
Great question :D It's similar to the one I just answered before yours, about modding.
When block properties are general, such as name, color, material, and flammability, for example, they all fall under the blockData structure, which is a massive table of all blocks and items.
Let's take a pumpkin for example (hopefully this looks okay without code formatting):
blockData["pk"] = {
name: "Pumpkin",
identifier: "pumpkin",
tool: false,
mining: {WoodenAxe:25, StoneAxe:25...},
isWood: true,
pistonDrop: true,
flammable: true,
flamRate: 700,
shiftClickBlock: true,
placeable: true,
endermenCanChange: true,
color: "orange"
}
"pk" is the identifier I refer to in the code whenever I want to access the block data. I have a function (getBlockData(id, property)) that will retrieve the block's information easily and still handle any errors, in case a block doesn't exist or something.
But as you can see, each block can have a ton of properties, and it's super easy to add. I can set something to "stairBlock" or "halfBlock" and it will be treated like stairs or slabs for collision.
Now when the behavior of the block is unique, you'll often find it doesn't have a property. Slipperiness and bounciness haven't yet been converted to block data, for example. Currently the system just asks if the block underneath is an ice block, and if so, make the player (and mobs/items) slide.
There's a whole set of behaviors for each block that happen every frame. Or when you place it, break it, or shift-click it. These behaviors are currently scattered throughout the program, a lot of it being directly on a giant "block type" MovieClip which contains instances of all the blocks you see in the world. It's a mess, and everything will eventually be moved to the main code (that'll be in the two updates after 1.29, actually!).
:3

The answer hasn’t got any rewards yet.