[1.12.2] Prevent sand/gravel blocks from falling

[kevinmd88]

I'm trying to determine a way to stop blocks like sand and gravel from falling when there's nothing supportive beneath them. I found this topic in my searches: 

However unfortunately it isn't solved there.

 

I'm not aware of such an event I can subscribe to... Is there an effective way in Forge to handle this?

 

If it helps as to why I'm trying to accomplish this... I'm attempting to port over the CA-Teleport and CA-Static Bukkit plugins that Rumsey wrote for the CraftingAzeroth project over to Forge. I have finished coding for CA-Teleport (though I have not yet tested it), and my question here relates to how to adapt the plugin's onBlockPhysics handler in the Bukkit implementation.

Edited April 30, 2018 by kevinmd88
clarification

[Draco18s]

4 hours ago, kevinmd88 said:

I'm not aware of such an event I can subscribe to... Is there an effective way in Forge to handle this?

There is no hook for this.

[moonlyer]

It is possible to override vanilla sand and gravel in the registry and replace them with your own versions of sand and gravel. I believe thats the only way to stop them from falling with Forge.

[jabelar]

Yes I think you can do that. In the past there were certain substitution APIs but it never really worked well. I think with the modern registries you can directly replace entries, although I haven't tried it.

[jredfox]

you could try and replace gravel and sand blocks base class via asm(every mod that extends x class) or replace them hard coded to do your function by using the same registry name for your block

Edited May 1, 2018 by diesieben07
no

[kevinmd88]

On 4/30/2018 at 12:30 PM, moonlyer said:

It is possible to override vanilla sand and gravel in the registry and replace them with your own versions of sand and gravel. I believe thats the only way to stop them from falling with Forge.

By replacing them with my own versions, would other recipes that depend on the vanilla versions still function?

[loordgek]

if they use the sand ore dict then, yes, if they only use sand, no

Edited May 2, 2018 by loordgek

[MFMods]

 

On 4/30/2018 at 7:30 PM, moonlyer said:

It is possible to override vanilla sand and gravel in the registry and replace them with your own versions of sand and gravel. I believe thats the only way to stop them from falling with Forge.

even if it were the only way, never do that. how would you make more than 5 mods work together (even as a player, not just modder) if they liberally replaced original stuff with their own?

 

On 4/30/2018 at 2:58 PM, kevinmd88 said:

I'm trying to determine a way to stop blocks like sand and gravel from falling when there's nothing supportive beneath them.

investigate EntityFallingBlock a little. consider subscribing to event bus and reacting to entity update (or, even better, entity join world or entity enter chunk).

i can not test things now (at work) but i believe one or two simple solutions exist, which rely on tripping the falling entity before it actually gets moving.

[jabelar]

5 hours ago, MFMods said:

 

even if it were the only way, never do that. how would you make more than 5 mods work together (even as a player, not just modder) if they liberally replaced original stuff with their own?

It would work fine. What I was suggesting is replacing it in the registry. Therefore, as far as all vanilla and other mods are concerned it would be sand/gravel. That's part of the benefit of a registry. This has nothing to do with modifying base classes, so the warnings about that aren't applicable.

 

The whole point of modding is changing behavior. If there is a conflict in what the mods want to do that is a different problem -- if one mod is preventing the sand from falling and another mod wants to make it fall faster then no interface is going to help that. 

 

LexManos and PaleoCrafter (both major Forge contributors) support this approach. See their discussion here: https://github.com/MinecraftForge/MinecraftForge/issues/4079. "Overrides" in the registry are an intended feature.

[Draco18s]

Overriding items is an intended feature but only one mod can override any given item. It's a necessary sacrifice.

[MFMods]

On 5/4/2018 at 8:25 PM, jabelar said:

The whole point of modding is changing behavior. If there is a conflict in what the mods want to do that is a different problem -- if one mod is preventing the sand from falling and another mod wants to make it fall faster then no interface is going to help that. 

well, true, but that example is a bit extreme isn't it?

what if one mod wants to make horses faster, second wants to make them avoid players when untamed, third wants to add more variation in stats, fourth wants to change the way they graze grass...? good mods will do their thing without replacing the horse, thus allowing us to have all four changes. lousy mod will block other changes for the sake of their own.

 

On 5/4/2018 at 8:25 PM, jabelar said:

LexManos and PaleoCrafter (both major Forge contributors) support this approach.

hold on... i would support replacement of an object which itself holds the behavior - you're making a "better fishing" mod? you need to replace the fishing rod and the bobber. i don't have a problem with that.

 

but sand doesn't contain the falling behavior. if he replaces sand and gravel, what about mystical sand? tropical sand? fairyland sand (i'm making them up)? end-sand? they'll keep falling down (maybe up in case of end-sand). he needs to go for the falling behavior, not just the sand - if possible of course, and i very much believe that in this case it is.

 

@kevinmd88: just be sure that the x and z-motion are zero. if there is a non-vertical component, leave it be, it's not a falling block.