I have a child Light2D node, which is inside a parent node.
When the modulate of the parent node changes (e.g. becomes transparent), I want the energy of the Light2D to decrease as well.
I know I can manipulate the energy from the parent node’s script, but the Light2D node is a bit like an ECS component, so I want its logic to be something like this:
When the parent node is transparent, my own light energy can become 0.
When changing the modulate of a parent node, all its child nodes are also affected. But I didn’t find a way to detect that it itself is affected by the parent node.
So, is it possible to find a node that is affected by its parent node’s modulate?
Can a node discover its’ modulate is being affected by its parent node?
what type of node is the parent node?
either way i dont see any signal in the docs when modulate property is being changed. why dont u just create function that changes parent modulation and then you can do whatever to children?
kuligs2
It's a bit ugly...
Maybe my screenshots of the game will help explain this.
ParentNode(Night Market Roof)
-- ChildNode(Light on the Roof)
Both parent and child nodes are components that serve different purposes.
Parent node's role:
When the player walks behind the parent node, the parent node becomes transparent, mainly used for houses/roofs/etc. in this 2D top-down game. (This process is an animation)
Child node's role:
Lights which are visible at certain times of the day.
Most of the time they are independent of each other, but when the light is inside the parent node (such as a light on a roof), if the player walks behind the roof, the light should also be invisible. (Changing the parent node's modulate will not affect the energy of the child light2D node)
Currently my solution is:
ChildNode(Light) changes its energy in the _process function according to real-time conditions. So I added some extra logic in it: Change energy according to get_parent().modulate.a, the disadvantage of this solution is that it must be the first-level child of the parent node, maybe it will cause some problems in the future.
- Edited
CrayonApe If a child node is supposed to act as a pseudo ECS component it has no business messing with its parent's properties. There is no guarantee the the parent will be of the presumed type. Instead, a component should have an interface consisting of methods and properties that alter and query its state. The system that uses the component should then communicate with it exclusively through that interface. Otherwise you're breaking the principles of component modularity and encapsulation, and your component won't actually function as a component.
xyz The traditional way of communication between parent nodes and child nodes is: the parent node adjusts the child node by modifying the child node's properties, and the child node adjusts the parent node by emitting events.
In the above case, the Light node (child node) will never interact with the Roof node (parent node). Generally, if a child node is willing to change with the parent node's modulate.a, it should expose a variable that changes when the parent node's modulate.a changes.
However, since the modulate of a parent node affects all its child nodes, if there is a property specifically for displaying the final displaying alpha of a child node, it is a bit like the parent node changing the property of the child node. I think this should be the ideal solution to this problem.
A manual implementation of the above solution would be:
The child node exposes a property to manipulate its alpha property, and when the parent's modulate.a changes, the parent iterates over all its child nodes and changes this property. So wherever the child node is, its light energy should also change with the parent's fade-in and fade-out effect.
But I need to adjust the property every frame of the animation, so it would save me time if there was a property dedicated to the final alpha of the child nodes.