(Code] Trying to make block with bounce on all sides of block.

Not sure if there's an easy way to do this, but I can think of some weird work arounds. I did something similar to this to make a block that launches entities away from it when triggered.

What if you make a procedure that first either checks if a n entity is colliding with your block, (you'd have to make the bounding box a pixel smaller on all sides so that this would work), or if there's a player in 1.05 meter cube around your block. (Using the 'if entity exists in square cube size...' function, or possible as an entity iterator to better handle multiple entities at once. 

Just make sure the check is centered at the block's middle, not its corners- all the 'check in box' functions go from the middle instead of the bottom north-west corner, so you need to add + 0.5 meters to all coordinates involving them to center it properly. Also be careful using the 'nearest entity' function, as this will very easily crash the game if it for some reason doesn't return anything in its radius. An entity iterator is probably the better option.

You should just be able to reverse each of the target entity's velocity values in an 'attempt to override motion vector' function, multiplying the x y and z velocities by negative one. If you want to be more precise, you could use trig functions to get the exact vector, possibly also taking into account the direction the entity is moving relative to the face they collide with. (Otherwise, jumping downwards onto the block while moving forwards will bounce the entity backwards and upwards, instead of maintaining the forwards momentum), but this is substantially more complicated.

Here's a basic example of how I achieved this effect, though keep in mind this is just for the X and Z axes- SY, (the amount of momentum to add in the Y axis), is set to a constant 0.3. This procedure is triggered by an invisible entity that launches everything in a 9 block radius backwards, meaning it runs every game tick, so your use case, (a single game tick), would need much higher values.

Entities in minecraft have X, Y, and Z momentum, that determine how much they move each tick, and in what direction. These are vectors- meaning if you're moving east you have positive x momentum, if you're moving west you have negative x momentum, falling means negative y momentum, jumping means positive... and so on and so forth. You don't want pathfinding, because pathfinding, (or just pressing keys to move your character), is just telling the game how much momentum you're trying to add. Walking adds momentum to the player, but it's influenced by surface friction, whether or not the player is swimming/on solid ground, etc. The 'Override Motion Vector' will instantly change the player's momentum to your desired values. (In this case, because it adds to the entity's existing momentum, it gradually overrides the player's existing momentum instead of all at once- if they're going really fast in one direction, it'll take a bit before the procedure fully zeroes out and then overrides their momentum.)

Your procedure may only work on players because your entity iterator is using 'event/target entity,' or has an unessasary check that's leaving out other entities. If you want it to only work on one type of entity, you could nest the stuff inside the entity iterator in a 'if entity is subtype of (whatever entity type you want),' which could be exclusively players, exclusively living entities, (not items or projectiles), etc. If you want it to work on everything, do not include such a check, and make sure all of the 'event/target entity' blocks are replaced with 'entity iterator,' (which is similar, but will trigger for all entities within the block's radius.) In this specific example, the 'event/target entity' refers to the entity doing the pushing, not the one being pushed.

The math here is kind of unpleasant, and I had to watch more Khan academy than I'm comfortably admitting to remember trig functions. The basic idea is that we don't know the exact distance the player is from the center of the outwards push, but we know the difference between the x position of the player, and the x position of the ce=nter; and the same for the z and y axes.  So: 

• We get the difference by subtracting the player and the center's x and z positions
• We then take the absolute values of these. (Otherwise, if the player's position is less than the center's, subttracting them would give a negative number, which would cause problems.)
• Then we use atan, (a weird magical trig function), to get 'theta,' the angle of a right triangle formed by these two distances. (The x and z differences between the entity and the center of the push.)  This requires that we first divide the two sides. I don't actually know why.
• Once we know the angle and the length of both sides, we have all we need to caclulate the actual force of the push, (The length of the diagonal side of the triangle), and the direction, (whether the side is going positive or negative in the x and z axis). 
• To find the x momentum to add to the player, we use 'sine,' (another magical trig function), on the angle theta, then we multiply it by the magnitude. (How powerful we want the push to be- in this case very small, because this procedure adds more momentum for every tick the player is within range.) we set a local variable, 'sx,' to this value.
• Then we do the same for the z axis.
• And finally, (there is a better way to do this, but I couldn't be bothered to come up with it), if the player/entity's x position is less than the center's, we multiply their x momentum by negative 1, (inverting it), so that they get pushed in the correct direction. We do the same thing for the z axis.
• And then we just override the entity's momentum to be the final values.

Sorry for the super exaustive explanation, but this took me embarassingly long to figure out, and I hope this helps. Best of luck!

Actually, your example might be way, way easier than that. You don't need something that pushes something outwards from a central point. You just need a block that bounces something based on the face that's hit. There's only six faces that can be hit, and the player must be moving in the correct direction on that face's axis to hit it. 

You literally just need to do the collision box, like from before, but instead of calculating vectors or whatever, just determine which of the six faces the player is colliding with based on their position compared to the block's position; then reverse the correct motion vector by multiplying it by -1. (If they're colliding with the top or bottom, reverse their y velocity, if they're colliding with the east or west side, reverse x velocity, and for north or south, reverse the z velocity.) 

...That should literally do it. It won't work for diagonals, but as long as the player collides head on with the hitbox, it'll bounce them in the correct direction, keeping other velocity, (such as forwards velocity when landing on the block from above), intact. Just make sure to check that the velocity in that direction is greater than 0, (or maybe that the absolute value is greater than 0.2 or something, so it doesn't continue endlessly), and probably multiply the reversed velocity by 0.6, 0.7, etc; depending on how bouncy you want it to be. (If you don't all momentum will be maintained, and the player will be able to bounce endlessly at the same height, if it's higher than 1 they'll gain more height each time they bounce.)

Don't have an example on hand, but that should be a substantially easier solution, the only tricky part is determining which side the player's hitting.

Very nice explanation Mindthemoods :)

Nice! You should probably be able to judge direction pretty well just with positions. (If subtracting the x and z positions of the entity from the x/z positions of the block's center gives less than half a meter for both, you can probably assume they're colliding with top or bottom depending on their y position... and so on.)

Happy to help!

Highly recommend checking out Khan Academy if you just need info on specific math stuff, like trig functions. For your situation though, you probably don't need much math. You just need to know what side the player is hitting, and with how much force.

For example: if the player's x and z positions are both within 0.5 of the block's center, (if subtracting the player's x position and the block center's position is less than 0.5 and greater than -0.5), that means the player must be colliding with the top or bottom of the block. (Because the player can't be closer than 0.5 meters to the center without being inside the block if they're horizontal to it). If either x or z was greater than 0.5, that would mean they weren't aligned with the block. The same thing should work for the horizontal axes, though since the player is two blocks tall, you'll need to also test for the top section of the player.

...And if you wanted a solution that's maybe even simpler, (but not as fancy, and probably a lot more resource intensive), then try this:

• Make a procedure that runs on entity update tick. Have it first check that the entity's x, y, or z velocity has an absolute value greater than some threshold. (Something close to zero, like 0.3 or 0.4- you don't want to constantly be checking for bounciness if the entity doesn't have enough momentum to bounce.) The absolute value turns negative numbers into positive numbers, which just means that it won't take direction into account. (If the player's moving really fast up or down, positive or negative velocity, then the procedure will still trigger.) 
• Then, if the entity has negative Y velocity, (if they're moving downward), check for your bouncy-block directly below the entity. If it finds one, multiply the entity's y velocity by a negative number, (-0.6, -0.7, -0.8, depending on how bouncy you want the block to be), which will both reverse the direction, (launching them upwards), and slightly decrease their velocity. (So they don't keep bouncing forever.)
• Then you just need to do the same thing for the other six directions, just changing where it's checking for the block, and which of the velocities, (x/y/z), you're reversing/decreasing. 
• This will have more weird edge cases, since some entities are larger than one block or have odd bounding boxes, but will probably solve the issue.