|
|
|
 |
Reply From: |
gozul |
you actually can, I had the same problem you need to do:
“$CollisionShape2D.set_disabled(true)”
The “set” part is necessary, a bit confusing, I know.
What I would want to know is if there is any difference in doing it like this or with “set_deferred”.
This is incorrect. There is no property called set_disabled
, so this will produce an error.
You can either do
$CollisionShape2D.disabled = true
or call the setter
$CollisionShape2D.set_disabled(true)
Although the former is standard practice; properties are directly accessible.
It may be you’re confused by the need to use set_deferred()
when a property of a physics object needs to be changed during the physics processing step. Since that’s not allowed, the change must be deferred to the end of physics processing.
set_deferred
takes two arguments: the property name, and the new value:
$CollisionShape2D.set_deferred("disabled", true)
kidscancode | 2021-02-02 18:48
Oh, I’m sorry I did meant to write:
“$CollisionShape2D.set_disabled(true)”
I edited my comment to avoid confusion for future readers. That was me typing it wrong as I am using it in my game xD
But I am still not sure of “set_ deferred”, is it better to use it than “set_disabled” in general. Or you should choose one or the other depending on if you need it sync to physics or not?
They’re the same thing, it’s just that you’re not allowed to disable collision during the physics step - if you do, you’ll get the message that you need to defer it.
kidscancode | 2021-02-06 17:56