Open Shadowblitz16 opened 4 years ago
I don't like working in GDscript because it isn't strongly typed
GDScript is a strongly typed language, even if you don't use static type hints. Don't confuse static typing and strong typing. Python is also strongly typed. In contrast, PHP and JavaScript are weakly typed.
@Calinou my I fixed it.
I can see it as a productivity boost if you have single small monitor but if you have more than 1, external editor is probably the best option.
git
{
on new line, Godot would probably enforce auto-completion rules like this, it's not practical to add a setting for each little thingwell I only have 1 monitor and although its not small its isn't big either
- It's already implemented and maintained by someone else, doesn't rob precious dev time
it shouldn't take up too much time once its implemented as long as the gui doesn't change too much .
- It has themes and very granular theme settings
- Auto-completion and linting (errors, not style) just works
could implement this in its code editor, once its done it shouldn't need updating much
godot already has this with GDscript
- It's well integrated with
git
godot could do this and should do this anyways
- It has plugins for basically everything you'd desire
godot could implement a plugin system for the code editor and have a separate category for code editor plugins
this could even be a way to easily add more languages
- Able to see your code and scene at the same time
this really only applies to people that have 2 screens
- Can automagically run scene by configuring a hotkey
godot can run scene by clicking the debug button or by shortcut
- Can write code however you want, e.g I don't like
{
on new line, Godot would probably enforce auto-completion rules like this, it's not practical to add a setting for each little thing
I don't like this either. this could just not be implemented.
I was planing on making a gdscript suggestion about removing stuff like this
It looks really redundant to me.
godot could implement a plugin system for the code editor and have a separate category for code editor plugins
What's the point? I can see why there is GDScript support inside the editor, but there is no objective reason to create another text editor inside the game engine. GDScript editor is small and simple as the GDScript itself. If you want another language it's fine, install the text editor and plugins which are already written.
Why reinvent the bicycle? Developers should focus on real things.
It looks really redundant to me.
- It won't be so easy (and fast) to implement.
i know
- It will increase the editor size (on top of default mono size increase).
this can be lessened by supporting multipule languages
- It will surely make editor do unnecessary heavy lifting.
thats what threads are for
- It won't be as near as good as, for example, VSC+plugins
vsc plugins have never works for me as well as the godot editor has
- It will need maintenance and continuous support, and that's a time which could be better spent on something useful.
this is why you would support multiple languages and use existing linters and code servers.
godot could implement a plugin system for the code editor and have a separate category for code editor plugins
What's the point? I can see why there is GDScript support inside the editor, but there is no objective reason to create another text editor inside the game engine. GDScript editor is small and simple as the GDScript itself. If you want another language it's fine, install the text editor and plugins which are already written.
Why reinvent the bicycle? Developers should focus on real things.
why does godot support gdscript then instead of just writing a vs code plugin for it?
I want to let people know that omni sharp can probably be used to make this a bit easier
Just to let godot devs know that GDScript's built in godot editor already does a much better job then VsCode's C# has ever for me. VsCode's auto complete doesn't even work, plus you don't have Godot's builtin help docs.
Just to let godot devs know that GDScript's built in godot editor already does a much better job then VsCode's C# has ever for me. VsCode's auto complete doesn't even work, plus you don't have Godot's builtin help docs.
yeah Visual Studio is much better
I'm just saying that it probably wouldn't be that hard to make it work as well a GDScript in the builtin editor. (aka better the vs code)
also @piratesephiroth visual studio is only available on windows.
This is definitly something id be interested in. Im coming from a background, where I already know c# and would prefer to use it for godot, however. Alot of the external editors are kind of bad (Vstudio slow and clunky, vscode feels bad to use and is a pain to setup for anything that isnt web languages)
So minimal features like autocomplete or error highlighting would help alot here. It also makes the engine easier to learn since you can discover types and their members better this way. varname.x not working and having to look up in the docs to find out its called ".X" is not a good user experience imo
would also be interested in this! it'd greatly speed up development as I wouldn't have to keep checking whether my code is correct
@bappitybup Please don't bump issues without contributing significant new information. Use the :+1: reaction button on the first post instead.
Describe the project you are working on: spaceship game
Describe the problem or limitation you are having in your project: I don't like working in GDscript because it isn't statically typed and I don't like python syntax however I don't like the fact that gdscript is supported in the built in editor and mono isn't
Describe the feature / enhancement and how it helps to overcome the problem or limitation: I suggest when the mono script implementation is out of alpha and supports all the functionality that GDscript does, official support is added for it in the godot script editor.
I would like to see the following support for mono
I would guess reflection can be used for most of this to make it pretty strait forward, but this would allow users to not have to tab out to, code and then compile then tab back into the godot editor.
this speeds up workflow by at least 25% for mono users
compiling could even be done asynchronously to avoid locking up the godot editor
Describe how your proposal will work, with code, pseudocode, mockups, and/or diagrams: I don't have any mockups but basically it would work the same way other fully supported Godot languages do.
If this enhancement will not be used often, can it be worked around with a few lines of script?: this would be used alot by mono developers and although it can be worked it would take alot more then a few lines of code.
Is there a reason why this should be core and not an add-on in the asset library?: while this doesn't have to be added in the core it could be added in the same plugin as the mono support.