I was keeping an eye on this project since the begining but just found some time to participate.
There is a task “Editor window to quickly open scenes” marked with a tag “good-first-task” so I think it’s a good starting point for me.
Before implementing this task I believe it’s better to discuss the details.
The project contains GameSceneSO assets which are kind of wrappers around the scenes. So I think we could use them in this Scene Selector as a source of information which scenes to show (as it’s said in the description of the task that not every scene in the project is required to be shown). This way we don’t need any extra scriptable objects to contain the list of the scenes to show since it would make the workflow harder.
Also I plan to add an option to hide specific scenes from the listing. Each entry will contain a toggle button which will control the visibility (similar to a visibility toggle in a Hierarchy window)
Yep, there will be a global visibility button which will unhide hidden items (or to be more precise it will just make the window ignore per-item visibility settings and show them all). I just did not reflect it on the draft.
Yes, I’m aware of that. However I don’t realize how does it relate to Scene Selector.
IMHO Your PR doesn’t correspond to this open task - “Editor window to quickly open scenes”.
Must be create separate thread to discuss your proposal regrading “to make GameSceneSO more reliable”.
It’s ok, the change to the scene retrieval is probably a PR that has a short life, we generally create a thread for features that are going to be long in development.
@dotsquid I like your idea with the change in how we fetch the scene files. I’ll leave a comment on the PR before analising it!
Hello, I also created a editor window to quickly open scenes which is scalable also, but seems that @dotsquid already created. I was ready to open a P.R but went offline for few days back.
So I was working on my idea of the ‘visibility’ toggle buttons and encountered an undesired behaviour of UnityEditorInternal.ReorderableList which I use to draw the list of scenes.
What I was thinking to do is just make the ReorderableList not draw hidden items but keeping them untouched in the list. The only way to do that is return zero height in elementHeightCallback and do nothing in drawElementCallback. Unfortunately this leads to visual issues:
An item being dragged has no content.
Dragging handles of hidden items are still being drawn.
I have inspected the source code of ReorderableList and it seems there is no way to get this problem around.
If someone have any idea how to make ReorderableList not draw specific items, please speak
Otherwise the only way to implement this is to have 2 lists: one for visible items and one for hidden items, which complicates things a lot.
I actually didn’t know about ReorderableList but searched it up and used it after seeing your screenshot. @dotsquid
So what I did is that I have two modes, one for edit and one for view. (kind of like iPhone?)
The edit mode uses ReorderableList and always shows all the scenes and their visibility. The view mode only uses GUI buttons and doesn’t show the scenes with visibility turned off.
You can check the gifs in my PR to see the details.
@cirocontinisio@canchen_unity That’s kinda disappointing that your work (which I actually appreciate and what to thank for the idea of the ‘edit mode’) was merged without any discussion.
Anyway, here is what I came up with (though it needs some polishing).
As I proposed earlier my implementation uses GameSceneSO’s to populate the list of scenes to display. I believe it has benefits against the version which retrieves the scenes from the BuildSettings: it still can display the testing scenes which should not appear in the BuildSettings list. Beside that there is no need for manual filling and clearing the list of scenes.
Another major difference is that I use EditorPrefs to store the data instead of a ScriptableObject in the Resources folder. I think this is much more preferred way to store this kind of data for 2 reasons:
this data may differ for different users: someone wants to see test scenes, someone does not. Every change in the data will lead to the change in staged files in git and will require either declining those changes or committing them. Either way it will be mess.
since those data are stored in Resources they will be included to the build which is not a good idea.
Since this PR is still not approved and merged I can’t create a PR for this feature.
The situation when someone begin new work, when others working on that case, isn’t good and also if I remember the main idea of forum use was to avoid these issues.
And I think in the future it will be good to present some procedures for organizing the work of several people on one issue. @cirocontinisio@Amel-Unity (And you didn’t mark this thread as Official? May be good idea - recommend members to set the status themselves if that’s the proper topic. You always have the right not to accept it later
I didn’t check the solution of @canchen_unity yet, but the idea @dotsquid - doesn’t base the “Scene selector” especial on Build Settings (possibility to add link not only on scenes from Build Settings) is very good and his proposal regarding the visual of “Scene selector” GUI is more interesting and have more possibilities (color marking) for future development.
But the idea of @canchen_unity to populate list from Build Settings (for init it) also very good also as “clear list”.
This idea also interesting (I didn’t see the code) but Idea is right - I spent some time with SO and believe that use it everywhere to store different data isn’t a good programming style, because it a very specific "data object: with some benefits and some limitations.
@dotsquid, sorry for making this messy.
I really like the look of your version and those color markings. And yes, the two points you mentioned really make sense. I think I’m learning a lot from you, so sorry again for causing this situation. I’ll look into the PR and see what we can do.
I’d love to see your version of the tool and learn how you implemented it.
My approach is we can create a AllScenesHolderSO scriptable object and assign SceneAssets to it. Then we can open the window and assign the scriptable object into the Scene Data field. Then buttons will populate for all scenes (except for currently open scene, if it is also in the SO). We can, obviously change scenes by clicking those.
When we close the window, the reference persists. But closing the Unity editor removes the reference, for now.
If we update the SO index, the editor window automatically updates its button, no need to reassign.
This way we can create several indexes and assign them in window.
My implementation also does not uses Scenes from build settings. So there’s no need of adding Test scenes to build settings.
feel free to ask any questions.
I also created a Video on this, but it seems i cannot upload it here like images, nor I can do on YouTube. How will I upload that Video?
I tested and merged the PR from @canchen_unity because the tool does what was required in an independent way and I liked the window made for the tool. I also saw that you both discussed the solutions on the forum and even though It wasn’t @dotsquid who opened the PR, you both contributed by giving feedback and discussing it here and I would like to thank you both for that. Merging the PR doesn’t mean that it is final, we can still open another PR to improve the current solution.
Now I saw the updates from you all during these last 2 days after the merge, here on the forum and in the comments section in Github on the GameSceneSO PR and I can see that what @dotsquid is suggesting is really a great solution. The fact that we don’t rely on BuildSettings is really a good point. For instance, we are using a lot of test scenes that we want to access via the open scenes tool, but without adding them to the build because we don’t really need them in the game. So here is what I suggest: let’s keep the discussion going on the GameSceneSO PR and once it’s fully working (We are almost there), we can merge it. Then, feel free to open a new PR for the scenes tool to make it read the SOs instead of taking it from BuildSettings and we can merge it if all is good.
He is the very powerful man, but i think he doesn’t have possibility to edit somebody else threads.
