3 ms·
>you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult). Do you mean actually pausing the game (play using th
by BlargMcLarg 4y ago
>you cannot pause the game and "view" the scene in the editor (making debug for collisions etc difficult).
Do you mean actually pausing the game (play using the editor, then pause) and then checking the remote tree? You can check the remote tree while the game is paused. I have noticed breakpoints (in C#) tend to freeze updates on the remote tree though. Additionally, you can show collision shapes during gameplay by toggling it.
>E.g. the script editor UI is weird (it has reasonable actual code editing, but the layout and how you select files is weird and really unintuitive IMO)
Big reason I use VS Code to edit. Unfortunately shaders are still best written in-engine and the shader window has a really, really annoying tendency of removing itself once selecting a different node without selecting a different shader. Funny since animation and audio tabs don't show the same behavior (the animation tab stays locked until you select another animation tree, audio behaves similarly).
>so it is easy to get lost in the embedded scenes-within-scenes
My biggest problem with scenes, I can get used to scenes-within-scenes by keeping things on a code level, but nodes tend to be fairly expensive and making things like components isn't the most intuitive in Godot coming from Unity, Unreal or anything similar. If the community was a bit more mature and bigger, someone would've probably figured out best practices to avoid these things rather it looking like a flaw in the system itself.
- mattlondon 4y agoThe remote tree is useful, but a fully visual representation in the editor would be best. It seems that I can force the game to reflect what I set in the editor , but not make the editor visually show what is happening in the game at that specific moment. E.g. imagine I am creating a platformer (for a totally hypothetical example) with a moving platform. There is a bug in the game where the player sometimes drops through the moving platform. In unity I can pause the game when the bug happens and then in the editor I can visually see all of the colliders and so on and quickly work out what is happening (e.g. perhaps the collider for the platform is too short or something and so the player misses it). In Godot it seems there is no way of doing this. Yes I can use the inspector on the remote tree, but this is not easy to visualise the colliders and their overlapping. Add in 3D and it gets even harder. Perhaps I am just missing some button somewhere? Debugging collision issues in Godot is proving to be a real pain in the backside without this feature. I guess that for Godot it just shells out a new process to run the game and the game is not running in the editor as it appears to be in unity, and that makes it hard to visualise the state in the editor.