Terrain.CanBeDamaged

Feature Requests Engine Features
,
#1

As a ROBLOX Developer, it is currently hard to use Smooth Terrain how I’d like. Here’s why:

Intro
At the moment, Part-Terrain integration is a skill of its own. Every script needs a new module supporting the terrain, and honestly, it can be very hard to update an old place to support Smooth Terrain, though many developers, including myself, would love to use it. It’s especially annoying when every reference model you insert from the toolbox doesn’t support smooth terrain, so you have to write that module yourself.

Problem
Terrain is very hard to manage at the moment, and lots of times free models/old models have to be remade to support Smooth Terrain.

Potential Solution
Add a Terrain.CanBeDamaged Bool value to the terrain that tells the game whether terrain can be damaged by an explosion’s blast pressure. This is necessary because anchored parts don’t fall, and it is very unrealistic when the buildings float because the terrain was shot out from under it. This would allow us to use the terrain as if it were a mesh, which is much more efficient in some cases.

6 Likes
#2

Explosion already has a property ExplosionType that can be set to NoCraters.

7 Likes
#3

Yes, but there could be tons of explosions going on at once. It’s easier to just change one property rather than 100.

#4 
workspace.DescendantAdded:connect(function(obj)
   if obj:IsA("Explosion") then
      obj.ExplosionType = "NoCraters"
   end
end)

???

6 Likes
#5

If it’s this easy, why not just put it into a bool value so newbies can use it? Again, it’s just easier to disable craters in one click rather than having to write 5 lines of code every time. It also allows better usage by scripts that can change the value depending on the map.

#6

You’re asking for the same property to exist twice. I see 2 ways this could have been implemented:

  1. Add it to terrain. This forces the behavior to be one or the other.
  2. Add it to explosion. This allows a much more programmable behavior.

Clearly #2 is more favorable. When creating an explosion you should set it to behave the way you want it to. If for whatever reason you cannot do this (you’re using a free model or linked source) then @Sharksie 's solution is the proper one.

I don’t agree that duplicating the same property to different objects is a good idea. This creates a “three way switch” behavior which is not ideal.

10 Likes
#7

Your intro is sort of misleading, I thought you were going to mention that SmoothTerrain cannot be simply moved or inserted.

Anyways, being able to change the ExplosionType is enough in my opinion, adding a global variable to Smooth Terrain seems like API bloat and unnecessary.

1 Like
#8

If you’re creating the explosion, certainly you can change its ExplosionType while you’re setting the Position, Radius, BlastPressure, and other properties.

2 Likes
#9

How many games are you making where you insert so many free models that making them behave consistently is a significant task?

I feel like this is an extremely niche use case. No one is making games by inserting a bunch of free models and letting them run whatever code they want.

1 Like
#10

Although it could be entertaining to watch the virus and malware scripts duke it out for supremacy until the lag dragged everything to a halt.

10 Likes
#11

Back when insert wars were a thing, when I played them, people actually took them seriously and inserted non-OP non-virus models.

2 Likes