Modify the concept of code assets in the editor
Nobody has claimed this yet.
- Dominant language
- C#
- Stars
- 7.8k
- Forks
- 1.2k
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 49
Description
Is your feature request related to a problem? Please describe.
Currently the editor iterates over all folders in a project to find C# source files and shows them under a Code folder in the project tree. Selecting that folder allows the user to browse files in the asset browser. The ScriptEditor is used to edit those c# files within the GameStudio.
One of caveats of this approach is that it focuses on source files as assets, when in many cases those files do not hold entities usable in the editor, other than for the purpose of text editing.
We've had issues (mostly around syntax highlighting) with the built in script editor before and while RoslynPad provides good usability it's not the same as using a fully fledged IDE. In my opion with Stride targeting C# developers it is often to be expected that the user would have VS/Rider installed and for those that don't we can encourage use of VS Code. Preferring use of external code editor means Stride has a smaller maintenance burden in this aspect.
Then there's the case of usability of code based assets. At the moment the primary engine entity extracted from code files is a ScriptComponent. There was recently a fix made to the drag-and-drop functionality of dragging a source file asset onto an entity in the scene to add the script component. From what I've seen there's an assumption made there that one C# file holds one script. It also missed the opportunity of allowing dragging over other types deriving from EntityComponent.
Describe the solution you'd like
If we were to leave larger code editing to an IDE, we can still keep the script editor for making minor single file scoped changes.
Those changes should focus on the code usable in the editor.
I propose dropping the source file view of code assets and transition to a component view where we extract usable types from the source files and present them in the asset view (keeping the source file chierarchy).
Editing a component (double clicking) would still open script editor as the file association would stay there.
There may be a bit to figure out how deleting the component from a source file is treated or how opening two components from one file should not open multiple editors.
Additional context
The asset structure in the asset browser
Code
MyFolder
MyScript.cs
MyMultiScript.cs
MyModel.cs
MyEntityComponent.cs
Would become
Components
MyFolder
MyScript
MyMulti1
MyMulti2
MyEntityComponent
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing the editor's asset browser Code-folder discovery, ScriptEditor association, and source-file drag-and-drop behavior described in the issue. Define how usable component types are extracted and shown under Components, including multi-component files, deletion, and opening multiple components from one file; done means the proposed component view replaces the source-file view without losing editing or scene assignment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- csharp
- Domain
- game-dev, tooling
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100