Open manio143 opened 1 year ago
Would this mean that instead of having the code editor, Scripts would be treated similar to Scriptable Objects in unity? Where you would just have a serialized asset where you could easily modiy the base values of script properties?
@Doprez No, here I'm talking purely about changing how editor presents scripts to be used on entities the way they already work. For ScriptableObject (which is a horrible name btw) equivalent we would have custom data assets - assets which aren't compiled into something else, just hold data and references to other assets. See #30
Would this then allow Scripts to be distributed in nuget packages the same way that assets in the assets folder are?
I know recently I have been having to make my scripts in my nuget builds abstract because the only way to serialize the data in gamestudio is if the script comes directly from the project folder. I always make a base class in the nuget package and then inherit the properties in my current implementation.
created a new question as this thread may be unrelated to wwhat Im thinking of https://github.com/stride3d/stride/discussions/1622
So, if i understand correctly you want to change the name of the main folder to "Components" instead of code and move the code editor from where it is to inside the asset viewer, am i right?
About the second point no biggie, but i have a question about the first.
do that change of name and order will be enforced by the program?
Because if so, what would happend with the custom folders you create inside your project?
I ask that because that is the kind of behaviour than allow to use other kinds of architecture in the code part, for instance, MVC, so, although is true than controllers today are components in an entity which just that script as a component, and is also true than this new way will not change that, it is also true than keeping the code order is important to keep wherever approach to programming you want to do with your project.
Granted, you want the code to be done in an IDE as is most if not all code done already in stride3d is done this way, i do however 100% agree with that, but the question is, why change the assets/code folder distribution and not only remove the chance to open them from that part of the IDE instead?
You could make than, for instance, if somebody double click a .cs it will open the entire project in VS/Razor and that's it, i think that you may see this approach, why did you decide otherwise?
Am i losing sight of something here?
@Obsdark
So, if i understand correctly you want to change the name of the main folder to "Components" instead of code
Yes. Currently in the editor there are two virtual folders:
I want to replace Code with Components and instead of having files in there I want there to be types and only those types which have an action in the editor associated with them (i.e. adding component to an entity).
and move the code editor from where it is to inside the asset viewer, am i right?
No, the editor would stay where it is.
Because if so, what would happend with the custom folders you create inside your project?
Folder structure would be preserved - see the example at the bottom of my first post here.
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
Would become