-
-
Notifications
You must be signed in to change notification settings - Fork 3.5k
Description
Describe the project you are working on
godot
Describe the problem or limitation you are having in your project
- When you generate a collision_shape at runtime, you will find that it needs to take 2 physics frames to detect collisions.
- Another similar example is that the size of the child nodes can only be known in the next frame of the container node(The documentation for the container does not explicitly state this, and the documentation for the container base class is very rudimentary).
- Others(there are many more examples, but I can't recall them all at once)
The order of execution is very important, which is why we frequently use code such as if not is_node_deady(): await ready;
or call_defered ("some_method_name")
that I think it is necessary to clearly label the mechanisms of these delayed effects (through specific numerical values instead of vague explanation) to help users know how many frames they need to wait for to execute the next function.
Describe the feature / enhancement and how it helps to overcome the problem or limitation
Clarify all functions/mechanisms related to delayed effectiveness in the document by using specific numerical values(explain at which frame it takes effect, etc) instead of vague explanation(like 'it will delay taking effect') if possible.
Describe how your proposal will work, with code, pseudo-code, mock-ups, and/or diagrams
Same as above.
If this enhancement will not be used often, can it be worked around with a few lines of script?
It is a step to build a more clearer documentation, and i'm not sure how many lines of code are needed.
Is there a reason why this should be core and not an add-on in the asset library?
it's an enhancement of documentation, should be the core.