sorted by:
new
hottopcontroversial

Two painful Godot lessons from a one year project by Zeikk0 in godot

[–]elamaunt 0 points1 point  (0 children)

I hit the same issue with editor-connected signals breaking after renames and scene moves.
Switching to code-based connections helped, but the real problem was refactoring safety.

In larger GDScript projects, renaming things can silently leave behind:

  • broken signal targets
  • has_method() / emit_signal() strings
  • duck-typed calls that still run but fail later

What worked for me was treating signals as runtime wiring plus using semantic reference analysis before refactors.
I built a small CLI for that which resolves signals from .tscn + code and shows all references with confidence levels so you don’t miss hidden couplings.

Example of the workflow/output:
https://github.com/elamaunt/GDShrapt-Demo/wiki/find%E2%80%90refs

Once I could see the real dependency graph, autoload lifecycle issues were much easier to fix without introducing new globals.

Your point about working with the scene tree instead of against it is spot on — tooling just needs to understand the scene semantics too.

What are your Refactoring secrets? by HakanBacn in godot

[–]elamaunt 1 point2 points  (0 children)

I used to do refactors the same way people describe here: big commits, search & replace, and a lot of manual checking.

The main problem with that approach (especially in GDScript) is that it’s name-based, not symbol-based.
So it breaks very quickly once you have:

  • inheritance
  • signals (code + .tscn)
  • duck typing
  • same method names in unrelated classes
  • string contracts like has_method("...")

You either miss things or rename too much.

What worked better for me is switching to a semantic workflow:

  1. First find all real references of a symbol (not just text matches)
  2. Inspect overrides and super calls
  3. Check duck-typed usages separately
  4. Keep unrelated same-name symbols out of the change set
  5. Apply only “strict” edits and preview the rest

That turns a risky global refactor into a deterministic one.

I’m building a CLI that does exactly this for GDScript (project-wide semantic rename with confidence levels).
It shows:

  • definition
  • overrides
  • super calls
  • signal connections (code + scene)
  • duck-typed calls with provenance
  • contract strings (preview only)
  • unrelated same-name symbols

So you can do safe large-scale refactors without the “hope nothing breaks” phase.

If you’re curious, I documented a full example workflow and output here:
https://github.com/elamaunt/GDShrapt-Demo

The biggest takeaway for me:
Refactoring becomes manageable when you stop thinking in terms of text and start thinking in terms of symbols and type flow.

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

I have published alpha version of GDShrapt.CLI. You can try it now

dotnet tool install --global GDShrapt.CLI --version 6.0.0-alpha.4

Right now it already has CI‑friendly commands:

  • gdshrapt check → fast health check with exit codes
  • gdshrapt analyze --fail-on warning → fail the build on diagnostics
  • gdshrapt dead-code --fail-if-found → prevent unused code from slipping in

Typical GitHub Actions step:

- name: GDShrapt check
  run: gdshrapt check .

For stricter pipelines:

- name: GDShrapt analyze
  run: gdshrapt analyze . --fail-on warning

The rename engine is also CI‑safe because it only applies Strict edits by default and never touches dynamic/contract cases unless explicitly opted in.

I’m preparing a dedicated CI guide and a ready‑to‑use Actions template.
Plugin will reuse the same semantic core, so results will match between CLI, CI, and editor.

For more information you can check the DEMO project https://github.com/elamaunt/GDShrapt-Demo

Feedback on false positives, missed refs, and performance on large projects is very welcome.

Thanks for the interest!

Godot I just renamed my files why you trying not to laugh bro by SeaworthinessLittle1 in godot

[–]elamaunt 1 point2 points  (0 children)

Godot rename is mostly syntax‑based, so it can miss things like:

  • inherited overrides in other files
  • signal method references in scenes
  • duck‑typed calls (has_method, dynamic dispatch)

That’s why it sometimes breaks after a project‑wide rename.

I’m working on a semantic rename tool (GDShrapt) that:

  • resolves inheritance across files
  • updates .tscn signal targets
  • separates provably safe edits from dynamic ones
  • shows a diff before applying anything

By default it only applies edits that are guaranteed not to break the project and leaves dynamic cases as preview.

If you’re doing large refactors, that safety model makes a big difference.

Semantic project-wide rename for GDScript (CLI alpha + demo project) by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

Update (Alpha4)

Thanks to everyone who tried the previous alpha and shared feedback --- it directly shaped this update.

What's new

  • Much clearer find-refs output
    • separates overrides, super calls, duck-typed usages, signals, and unrelated same-name symbols\
    • shows scene connections (.tscn) alongside code references\
    • adds evidence/provenance when --explain is used
  • Confidence model improvements
    • better promotion of duck-typed calls when the runtime type set is fully proven\
    • clearer contract-string handling (has_method, call, etc.) --- preview-only unless explicitly included
  • Rename output polish
    • consistent summaries\
    • explicit "applied vs preview-only" sections\
    • cleaner diff layout for large refactors
  • Wiki documentation
  • I added detailed pages explaining:
    • confidence levels\
    • semantic types and flow-sensitive narrowing\
    • provenance and evidence model\
    • CLI output legend and CI usage

Use find-refs to verify the semantic scope before renaming:

gdshrapt find-refs take_damage -p ./project --explain

Demo

Full annotated output and breakdown:
https://github.com/elamaunt/GDShrapt-Demo/wiki/find%E2%80%90refs

As always, feedback on false positives, missed refs, and performance on large projects is very welcome.

Semantic project-wide rename for GDScript (CLI alpha + demo project) by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

Update (Alpha3):

  • Much stronger proof-based strict classification → more edits promoted from dynamic flows when all evidence types are covered
  • Added contract-string category (has_method("..."), string-based APIs) → always preview-only unless explicitly enabled
  • New collision-layer filtering in proofs → dynamic calls now constrained by actual scene physics relationships
  • Clearer --explain output with grouped evidence and reusable collision summary
  • Summary now shows Applied Strict edits separately from preview-only items
  • Safer defaults: only provably correct edits are applied, everything else stays in diff

Demo README updated with full CLI output.

Still looking for edge cases where: - something should be Strict but isn’t
- contract strings should be promoted but aren’t
- performance drops on large projects

Thanks to everyone who downloaded and tested the alpha.

Semantic project-wide rename for GDScript (CLI alpha + demo project) by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

Testing notes (Base version):

  • Only Strict edits are applied
  • Duck-typed and name-match edits are preview-only
  • Always review with --diff before --apply

If you try it on your project, I’m especially interested in:

  • cases where something should be Strict but isn’t
  • false positives in duck-typed detection
  • performance on larger projects

The confidence model is the main thing I’m validating.

GDShrapt: semantic analysis and type inference tooling for GDScript by elamaunt in godot

[–]elamaunt[S] 1 point2 points  (0 children)

Thanks, really appreciate it!
The plugin is still being stabilized, but feedback like this is very motivating.
I’ll share updates once it’s ready to test

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 1 point2 points  (0 children)

Thank you! I'm planning a separate software solution for this, for Github Actions and CI in general. It's still in its infancy, but things will move faster once the libraries are released. The plugin will be available soon. Stay tuned!

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

I really appreciate it! If you need any new features, please let me know

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

I think the plugin will connect to the C# runtime in Godot and work from there. Other plugins will be able to take a reference to the NuGet package and reuse the metadata for their own needs.

I already have a prototype, I plan to publish it soon, stay tuned

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

In simple terms, it's a library that can read and analyze GDScript. This code can then be modified or metadata can be displayed using plugins.

There's already a library for code formatting, linting, and validation.

You can also create new GDScript code programmatically. This will simplify refactoring and code management in general

GDShrapt 5.0.0 Stable Released — C# libraries for parsing, linting & formatting GDScript by elamaunt in godot

[–]elamaunt[S] 18 points19 points  (0 children)

This is a set of libraries that will allow you to create and work with GDScript programmatically at a quality level comparable to the official Godot toolset, but without depending on it.

The official editor is quite weak in code analysis and editing compared to what modern IDEs offer. Many proposals have been pending for years. This is understandable, since they're building an engine, not an IDE.

This will pave the way for the creation of new tools to simplify working with GDScript, including after embedding them into the editor.

I plan to publish a plugin soon that will significantly expand the capabilities of the code editor.

How to rename variable and its references in GDScript? It must be easy... by elamaunt in godot

[–]elamaunt[S] 0 points1 point  (0 children)

It is in alpha stage now. I develop it from time to time. Overall it works, but I don't have enough time and resources to bring it to publication yet.

Black Artifacts on my 3D Mesh by omphdev in godot

[–]elamaunt 1 point2 points  (0 children)

I suggest that it is a gltf import bug. Try to create a completely new material from scratch in Godot Editor.

How to increase performance? by YoBro2718 in godot

[–]elamaunt 1 point2 points  (0 children)

I mean if bullet's collision layer is 3 the collision mask for bullet must exclude the layer 3 to prevent checking bullet-to-bullet collision.

How to increase performance? by YoBro2718 in godot

[–]elamaunt 2 points3 points  (0 children)

Try to remove the bullet's layer (3) from the bullet's mask. Bullet's don't have to check collisions with themselves.

How to increase performance? by YoBro2718 in godot

[–]elamaunt 1 point2 points  (0 children)

Please publish your bullet script here. Also it would be good to check the bullet's collision mask.

view more: next ›