I suspect it directly compiles which kind of a pity since it was producing GDScript (in a template) then it would be lot easier to have it display the script . You could practice with the inspector then code yourself as far as individual code lines go. Documentation need would be a lot less.

The Godot Editor is actually made with Godot, or at least the same components that are available to use in your games. It is coded in C++, as this makes more sense for a desktop app, for performance reasons, and also because it needs to be low-level to work with OS and hardware and be cross-platform. Having the editor generate code sounds like a horrible idea, like Microsoft Front Page or those old apps that would produce spaghetti code no one could work with. But almost everything in the editor is available in the API and exposed to GDScript, meaning you can just read the documentation and do whatever you want.

Except the documentation is poor and the API . The editor generate code would just be like humans but without comments or sensible variable names because humans really did it.

@cloa513 said: Except the documentation is poor and the API .

This is simply not true. It sounds to me like you just have to spend time learning how to do things rather than blaming the tools or asking for a button to do your work for you.

@cybereality said:

@cloa513 said: Except the documentation is poor and the API .

This is simply not true. It sounds to me like you just have to spend time learning how to do things rather than blaming the tools or asking for a button to do your work for you.

When someone wrote a thread on what new features do they want, no new features please document everything and include a little code example.

I know contributors work very hard on GODOT- the work could be leveraged with little extra work needed, Try thinking of low extra effort solutions don't pigeonhole problems into high work solutions. The window integration program has died because they went that way. More than one way to solve things.

Could beginners not have to be asking the building block questions over and over? You write something and you get an error and the error description is not very helpful- phenomenon description than what is particularly the issue. Someone just wrote on another thread that you disable return a value from connect() and I find it impossible to believe that's the first few times of having that issue.

The API requires you to go up three levels to simply find location on screen of a button. Some simple stuff is well explained. Inheritance through classes doesn't everything is inherited- some are discarded and through three links to simply set up basic button formatting. Node.position doesn't work on buttons. There is GDScript help but you have to know the correct general method or to use to use an override method. Interactions are very difficult to document- you get to them and fiddle them out then.

I am asking for a button to help me learn. Putting details of what the gdscript equivalent of what the inspector is very helpful- you can fiddle with the inspector and then structure that information into a script.

Well, yeah. I'm not saying it wouldn't be helpful. I guess if you are not familiar with Godot maybe something that generated code for you would make some stuff easier. I'm just saying that, in my experience, automatic code generation is usually horrible, and leads to bad code, which is also a bad way for people to learn. You also said the documentation and API are poor, which is a false statement. It's a great design and it works well. Much easier than any other engine I've tried (and I've tried almost all of them). So the real issue sounds to me to be your lack of experience with Godot, which you could solve easily by spending more time with it, or reading books, or doing more tutorials, rather than complaining. That's all I'm saying.

Tutorials don't help me a lot with the projects that I am doing they are like board games. API documentation works well in some places and other places have dearth of documentation and those are obscure areas- we are just to getting the basic code blocks right- there are questions in the forum about what is the stylebox is- with simply duplicating the gdscript syntax equivalent to the API would . Comparisons are not really very useful really it has to be your own standard > @DaveTheCoder said:

You could make a proposal for this feature at https://github.com/godotengine/godot/issues

I tried but it wouldn't allow me to enter in the submission form- couldn't it be simpler to fill in- like a document. Clicking on form areas didn't give a cursor to fill it in.

There's the fact that Godot is an open-source project that depends on contributed work. Code and documentation comes from many different people, so it tends to be fragmented. And writing documentation is boring, so there's not enough of it.

Nonobscure areas- how about simply every single method that is available on node. Show me how to get every single method for Button if the API documentation was great- several pages with everything on it. > @cybereality said:

Well, yeah. I'm not saying it wouldn't be helpful. I guess if you are not familiar with Godot maybe something that generated code for you would make some stuff easier. I'm just saying that, in my experience, automatic code generation is usually horrible, and leads to bad code, which is also a bad way for people to learn. You also said the documentation and API are poor, which is a false statement. It's a great design and it works well. Much easier than any other engine I've tried (and I've tried almost all of them). So the real issue sounds to me to be your lack of experience with Godot, which you could solve easily by spending more time with it, or reading books, or doing more tutorials, rather than complaining. That's all I'm saying.

Everyone is actually created the robocode you say is terrible because they are produce the gdscript equivalent of the API.

@DaveTheCoder said: There's the fact that Godot is an open-source project that depends on contributed work. Code and documentation comes from many different people, so it tends to be fragmented. And writing documentation is boring, so there's not enough of it.

I wouldn't filling in some of it.

Putting details of what the gdscript equivalent of what the inspector is very helpful It already DOES this.

What am I missing here??

Could beginners not have to be asking the building block questions over and over?

Some people will ALWAYS ask before searching/reading themselves... That's not to say you shouldn't try to support them anyway and I feel the Godot docs already do a great job, but there is also a point of diminishing returns where your time is better spent elsewhere.

Right, all this stuff already exists and works in Godot if you do the basic amount of research.

... You could practice with the inspector then code yourself as far as individual code lines go.

The more I think about this the more I feel like your missing a fundamental design decision in how Godot works Namely these bits, but instancing in particular:

Basically, whatever you practice in the inspector/editor can, once you are happy with it, be saved as a .tscn and instanced into any other scene as a child.

You don't need to convert everything you did in the editor into code to be able to instance it at runtime, this would be insanely time-consuming and as you've noticed laborious. But the reason what you're trying to do is laborious is because nobody expected it to be done this way.

Instead, if you want to spawn one or more of something during runtime: Rapidly prototype it in the editor using the inspector. Save the node tree as a new scene (if you come from Unity, you can consider this now a prefab) * Instance it as many times as you need in your main game scene.

Unless you can somehow type hundreds of lines faster than a handful of mouse clicks, this WILL be faster than to instance what you need entirely from code, and is the reason a GUI editor exists at all, to remove the need to code everything and speed up development (this isn't PyGame), but allow you to whenever you need to.

Now in your game scene you may want to update a specific attribute at runtime, that's fine and for that see my previous post about how to identify any attribute name in the inspector and use it in code. But doing it this way ensures your code only needs to include the things that are actually likely to change at runtime, or are produced procedurally (geometry for example), and keeps typing superfluous code to a minimum.

Taking geometry as a great example , even if I generated a Mesh entirely procedurally from code, if I then wanted to attach a material with a bunch of parameters to it, I would not need to code creation of a new SpatialMaterial and write out assigning each parameter in code. I would instead prototype the material in the editor/inspector, save it as a resource, then only set the generated Mesh's material in code in 1 line.

You CAN, do it all in code if you so choose. The entire API is documented to support this and hell, the source code is open if you wanted to get down to that level. But the engine/docs aren't somehow wrong for not promoting this as the best way.... because it isn't.

@Bimbam said:

... You could practice with the inspector then code yourself as far as individual code lines go.

The more I think about this the more I feel like your missing a fundamental design decision in how Godot works Namely these bits, but instancing in particular:

Basically, whatever you practice in the inspector/editor can, once you are happy with it, be saved as a .tscn and instanced into any other scene as a child.

You don't need to convert everything you did in the editor into code to be able to instance it at runtime, this would be insanely time-consuming and as you've noticed laborious. But the reason what you're trying to do is laborious is because nobody expected it to be done this way.

Instead, if you want to spawn one or more of something during runtime: Rapidly prototype it in the editor using the inspector. Save the node tree as a new scene (if you come from Unity, you can consider this now a prefab) * Instance it as many times as you need in your main game scene.

Unless you can somehow type hundreds of lines faster than a handful of mouse clicks, this WILL be faster than to instance what you need entirely from code, and is the reason a GUI editor exists at all, to remove the need to code everything and speed up development (this isn't PyGame), but allow you to whenever you need to.

Now in your game scene you may want to update a specific attribute at runtime, that's fine and for that see my previous post about how to identify any attribute name in the inspector and use it in code. But doing it this way ensures your code only needs to include the things that are actually likely to change at runtime, or are produced procedurally (geometry for example), and keeps typing superfluous code to a minimum.

Taking geometry as a great example , even if I generated a Mesh entirely procedurally from code, if I then wanted to attach a material with a bunch of parameters to it, I would not need to code creation of a new SpatialMaterial and write out assigning each parameter in code. I would instead prototype the material in the editor/inspector, save it as a resource, then only set the generated Mesh's material in code in 1 line.

You CAN, do it all in code if you so choose. The entire API is documented to support this and hell, the source code is open if you wanted to get down to that level. But the engine/docs aren't somehow wrong for not promoting this as the best way.... because it isn't.

I tried with > @Bimbam said:

Putting details of what the gdscript equivalent of what the inspector is very helpful It already DOES this.

What am I missing here??

Could beginners not have to be asking the building block questions over and over?

Some people will ALWAYS ask before searching/reading themselves... That's not to say you shouldn't try to support them anyway and I feel the Godot docs already do a great job, but there is also a point of diminishing returns where your time is better spent elsewhere.

It is rather difficult to get the tool tips to appear- your mouse to carefully hover over the property . There should an option to have it appear when click on the value of the property because you are obviously interested in that property.

I had so much difficulties with the behavior of the GUI output. I challenged forum poster to show me exactly what I was doing wrong but they couldn't. Code mostly just works.

I had so much difficulties with the behavior of the GUI output. I challenged forum poster to show me exactly what I was doing wrong but they couldn't.

Stop the mouse on the property text and wait ~0.5s (as shown in the gif above). If you keep moving the mouse, it won't pop up.

That's it, and has been for as long as I've used Godot.

If the above does not work on your machine, I would suggest recording the screen and attaching it to a github ticket with system specifics and evidence showing you haven't done something like this in the project settings lol:

Pretty much the only thing that could potentially trip you up is some resources have a sub-resource window in the Inspector. This is an obvious shift when it happens and is shown pretty clearly below:

When this occurs, just use dot notation to access the sub resource:

@Bimbam said:

I had so much difficulties with the behavior of the GUI output. I challenged forum poster to show me exactly what I was doing wrong but they couldn't.

Stop the mouse on the property text and wait ~0.5s (as shown in the gif above). If you keep moving the mouse, it won't pop up.

That's it, and has been for as long as I've used Godot.

If the above does not work on your machine, I would suggest recording the screen and attaching it to a github ticket with system specifics and evidence showing you haven't done something like this in the project settings lol:

Pretty much the only thing that could potentially trip you up is some resources have a sub-resource window in the Inspector. This is an obvious shift when it happens and is shown pretty clearly below:

When this occurs, just use dot notation to access the sub resource:

And that's tricky to get consistently to work.

@Bimbam said:

I had so much difficulties with the behavior of the GUI output. I challenged forum poster to show me exactly what I was doing wrong but they couldn't.

Stop the mouse on the property text and wait ~0.5s (as shown in the gif above). If you keep moving the mouse, it won't pop up.

That's it, and has been for as long as I've used Godot.

If the above does not work on your machine, I would suggest recording the screen and attaching it to a github ticket with system specifics and evidence showing you haven't done something like this in the project settings lol:

Pretty much the only thing that could potentially trip you up is some resources have a sub-resource window in the Inspector. This is an obvious shift when it happens and is shown pretty clearly below:

When this occurs, just use dot notation to access the sub resource:

Also if you click on the property then tool tip doesn't appear.