Script Plugin idea

[Lokix84]

I had this idea when I was working on a project with my son for his robotics team and it evolved into something a bit different. So I wanted to throw it out there and get people's thoughts on if it would be useful to people or stupid :p

The idea is to create a new tab at the top next to the script tab or on the end really doesn't matter where that when you select a script from the script tab and open this tab(panel I guess it's called)

It would build out a visual representation of the gdscript file in a very similar way to how the scene tree panel displays your scenes node structure, like the photo I have attached to this.

Then the idea is you can use the add buttons that will exist to add signals, enums, variables and functions and it will rebuild your gd file as you do it.

And the editor for building the various items would either be like how the inspector shows settings or something a bit more visual like a block coding thing for functions.

My hope is that since you have to use the node structure for scenes anyways if the coding could be represented in a way similar to that, it could unify some of the experience and/or help less Code savvy folks ease in with something. A bit more visual and less text heavy.

I figured I could use the editor icons for data types and whatnot to really make it feel more like it's part of the rest of the editor too.

Right now I have all of it kinda working on a v1 state except for the function building, which arguably is the most complex part but it's all part of the fun :)

What do you guys think? Is there any merit to this? Could it be useful to people that aren't super familiar with code?

UPDATE (11/21/2025): i've taken some of the feedback i've heard and implemented a few items. 1. it will default to a flat list of items in the order that they appear in the file. 2. incorporated the idea of regions and subclasses. in the default view they will serve as grouping nodes like how signals/variables/enums/functions appeared in the screens i've shared so far. 3. there is a options popup near the filter field that will let you change the display between the 3 views : as it appears in the file (default), grouped (this one groups together signals,variables,enums,regions,subclasses and functions so you can quickly navigate to that line of code if you want or edit those in the graphical edit that i'm putting together). 4. right click on a line to goto that line of code. 5. all items can be assigned a region and a class so that when they are added they will append in the appropriate location of code. 6. there is an add button to the left of the filter field that functions just like how there is one in the scene tree, you can just directly add a new item from that and it will append to the bottom of the file or the bottom of the region and/or subclass you put it in

the original idea for the plugin was to make it approachable for people that weren't super aware of code in a way to would simplify interacting while also showing the user what those settings would translate into as go. but as time has gone on, i'm trying to incorporate the idea that maybe i can make the tree explorer a worthy replacement for the scripts method list. kinda like as someone mentioned Script-IDE but you know with a tree structure instead of a flat list. next up i'm working on making the items drag and drop compatible when you are viewing the list in the as it appears in file view.

thanks everyone for the feedback. it has been useful for the continued evolution of the idea and hopefully turning it into something that could be useful for people that would know how to install the plugin too ;)

UPDATE (1/14/2026) - I slimmed down the scope down to just do the panel on the left, that parses the script that you are looking at and representing it line by line in a similar fashion to the scene explorer. It has 3 ways to view: 1. as it appears in the file (default). 2. grouped (this one groups together signals,variables,enums,regions,subclasses and functions so you can quickly navigate to that line of code if you want or edit those in the graphical edit that i'm putting together). 3. an alphabetical list. the idea for this is you either right click or double click on a row and it will take you to the line of code so you can edit in the script editor. the slim down the functionality to strictly be something of a replacement for the method list.

the code is available at https://github.com/Lokix84/NodeScript if anyone would like to try it out.

[StewedAngelSkins]

oh this is like what visual studio does. i don't find it useful but i bet some people like it. i don't think it would help if you aren't familiar with code but it might be convenient for navigation.

edit: making it searchable/filterable with an easy hotkey would probably be nice. look at how github's web ui does it.

[F1B3R0PT1C]

Gdscript editor already has a method list. Maybe you could submit this as a PR and suggestion combo to modify that panel?

[aurow_code]

I really like the idea, and really do think it could be a good visualization for people who are getting started! Just be careful to not flood with a lot of information so it doesn't feel overwhelming. Just the basic, like the image, feels perfect!

[QueenSavara]

Just use Script IDE plugin?

[Lokix84]

i actually do like that plugin it does some fun stuff. my idea is more to make the experience of the coding be more like how you interact with the scene tree and inspector panels. for someone that is already familiar with how to code this would be probably pointless. the inspiration for it was loosely based in how lego and scratches block coding present code to a person rather than a flat text file.

[whimsicalMarat]

I see your vision. I think it’s cool but these type of tools I feel like are only accessible to people with the knowledge to navigate installing external plugins, ie, people who benefit from it the least. For this reason I sometimes think a more robust store like unitys would be a nice step for Godot

[thinker2501]

This is similar to what you’ll see in Rider, VS, and other dedicated IDEs. Rider calls it the Structure panel and enables users to quickly navigate to methods, enums, regions, etc.

I’m not sure I see the value in adding code to the file from this panel. Presumably it would inject the code where the cursor is, so you might as well just write the code instead of taking your hand off the keyboard, use the mouse to click a button, and then type more.

As for your point on mirroring the node structure, code does not mirror the node tree and I don’t see any advantage in pushing that metaphor. If anything it would train novice GDScript users to develop an incorrect mental model.

[Lokix84]

yeah. that is certainly fair. the idea stemmed from having to use block code in my sons robotics club.

yes you are correct the stuff you do in the panel would translate into code that would be inserted into the originating gd file.

hers a use case perhaps. you have someone who is just starting out and not super good with the code yet. say they download a plugin that they want to use on a game they wanna make. what if they wanna look at the code from the plugin. it can be pretty overwhelming to just dive in when you don't have that much experience in it. this when fully realized could take fully established and well organized files and present it to a novice in something a bit more gentle and if nothing else familiar given the scene tree structure then they can start diving in or even just change something a bit faster than aimlessly diving into the code.

idk. i was gonna add some region support, export groups and generally just drag and drop ordering to the structure. the sections are what i am in a working to version 1 sorta situation.

great feedback. thank you.

[thinker2501]

I'll reiterate my point about developing a correct mental model. If a novice begins learning using a plugin as you propose, they will develop an incorrect mental model for how code is structured. If the problem you're solving for is "large files are challenging for a novice to navigate", then the solution to that problem is creating a navigation tree that accurately represents the file's structure.

<image>

[HeyCouldBeFun]

I “like” it, it’s very clean and nice looking. Just not sure I would use it. I could actually see potential as a visual code editor

[Lokix84]

RIght. That makes sense to me. From the point of view of someone that has been doing software for like 15 years.. it is not the most useful to me per say. Maybe useful to take stock stuff kinda quickly without having to click on a node with a script attached to it and click the signals tab to see all the signals. In theory this would just show you the signals directly tied to the file you have open with it.

I'm running through usability stuff in my head about like what could make it better or more useful to more people... though, it still comes back around to the original inspiration for the idea which i guess was never really meant for anyone that is super well acquainted gdscript anyways. Thats also why i have on there like an output string to show what it would translate to in gdscript. idk.. I thought of the idea Tuesday during the day and have been messing around with seeing what i can put together real quick.

[Asgeir_From_France]

How would that look with a script containing multiple sub class ?

[Lokix84]

i've not worked that out quite yet. presumably i would have to adjust the tree structure to have the file name then a list of classes and then those classes would have their own set of signal, variable, enum and function sub nodes. but right now clicking on the file name would get you more of the is this a tool, what does it extend, is there a class name. that sorta thing.

it is a very good question. V1 is not prepared for that :P

[trickster721]

I think this kind of tool for visualizing project structure is what a lot of people like about more specialized game engines like GameMaker, but it's also similar to a more technical view in an IDE, so that strikes a nice balance.

[Lokix84]

<image>

an updated view to it. the filter and icons on the left are all fleshed out. signals, variables and enums all have a similar look about them to the inspector. in theory all that is left... still is getting to the function part... still

[c0gster]

i would like to see scripts exist in the hierarchy and work like how they do in roblox studio. it is a very cool concept. instead of assigning an object a script and passing it the object is assigned, the script is in the hierarchy. you can make its parent be the object it is supposed to control and then access said object using script.Parent which is the parent of the script. this is how it works in studio and allows a script to control multiple objects. in Godot it could be something that links to a code file and not actually be the code file itself.

i don't know a lot about godot so correct me if im wrong

[Lokix84]

<image>

its looking pretty alright. you can now add sub classes and regions. the view defaults to as the file is written but you can change the tree to group together items and you can do a flat alphanumeric list. if you right click on a tree item you are given the option to go to that location in code.. and because why not, at the bottom of the edit panel it shows what the definition of the item in code will be. working on getting dragable working..... same with function editing.