Some Ideas so I Can Help

[Cluedrew]

Hello everyone, I've been helping out a bit with some issues. Actually just some issues from GitLab. I am planning on making my own Solarus game, but for now I'm just helping out with the engine. So this year I might just continue to ask for issues, but I have some ideas to for new features/upgrades I could work on and I would like input on how useful/doable these sound.

Template Lua API: I am still learning Solarus, but I know template shenanigans. I am fairly confident I could significantly cut down on the amount of code in the API files. I haven't proven it will work yet but in my sketch of the idea I was able to create universal functions that handled many of the API functions. This could be used to replace many of the existing functions or reduce them to a single line forward if the functions are kept for clarity.

make uninstall: I know basically nothing about this except that it seemed to be missing. But I think being able to clean up for a fresh install would be nice.

Editor Metadata: This one is the biggest jump. Create a space/more space for project data that is not part of the final game. Might even go in a "meta/" or "editor/" directory beside "data/". Many I ideas I've had so far might be handled elsewhere (entities and enemies are pretty forced so stamps/prefabs aren't as useful). The one I am pretty sure hasn't been covered is multiple start scripts, only one is in the actually game but you have others for debugging & testing. Maybe some more editor configuration options would be good.

I just remembered the other crazy idea I had here, but it was some editor hooks for entities that the editor could call to help with editing. The motivating example was jumpers, the distance they sent the hero was set in a pop-up as a number. I would love to be able somehow click and drag that on the map view but that would require... I'm not sure what yet.

And that is what I have so far. The first I am pretty confident in if people want it done. Others not so much but I thought I would run them by people. And if none of them work I will ponder more ideas and take some issues in the mean time.

[Diarandor]

About the jumpers, you can open an issue to allow resizing jumpers, so that the jumpers width that you see in the Editor corresponds with their jumping distance of the jumper properties. Also, the jumpers could be shown as semitransparent, to allow seing what is below. Another option is to enlarge the jumper in that way only when the cursor is moved above the jumper. I thought that there was an issue for this, but I cannot find it.

[oclero]

You can fork the projects on Gitlab and make your modifications, and then make a merge request.

[alexgleason]

I opened the `make uninstall` issue. The reason I opened it is because I was trying to compile solarus-snap and I realized my system was pulling in resources from my local `make install`ed version of Solarus 1.6, so I couldn't verify that my Snap would actually build in a fresh machine.

The better way of solving this problem would probably be to fix solarus-snap#17. I could use help with this. I'm also quite tempted to finish making solarus-flatpak work instead because it shouldn't have this type of issue (but also has its own set of downsides).

[Cluedrew]

To alexgleason: I figured that might be the use case. I think I will do the make uninstall because I have momentum, I've found a section of the CMake FAQ that talks about how to do it and it should make testing easier in the future for any install method as well.

Not that I particularly enjoy working with CMake, it is UGLY.

On Feedback: I'm also looking for info about how useful some of these ideas would be. For instance is a one off fix for jumpers enough or are there other types of entities that could benefit from some common ground work? Would be reducing the code in the Lua API files be a good addition? I haven't been around long enough to know, so maybe I'm being excessive, it wouldn't be the first time.

[Cluedrew]

So... I have ideas again:

World Editor: There is the world option in maps, and I used them in my recent test project. They were useful but I found arranging maps in them a bit confusing (thinking through coordinates), I had some errors because I misspelled a world name and adding a map to the top was a pain. So to fix that I propose a world editor view, which shows all the maps in a world shrunk down (probably void of detail because scaling pixel art down is weird), with there size and relative position. It should allow them to be moved and new maps created at a position and of a given size.

Resource View: A view option on the editor to display resources instead of files. There are a couple of places this would reduce the number of files listed dramatically. We would either need tabs with modes to cycle through the views of the resource or the tab opened by clicking on the resource has buttons to open the other views (like the one in the map data file tab that opens the map script).

New Quest Selection: Currently when you create a new quest you select a directory and the new quest is create in that directory. The standard behaviour in most similar tools is to create a new sub-directory of that directory and put the project there, so the directory is the new file created when you create the new project. I turned my directory with my solarus stuff into a quest several times because of that disconnect. I suggest switching to that behaviour, with maybe an empty quest name selecting the current directory.

Import File: This is actually a request from my project partner. But they found adding the files to the tree and then adding them weird. Would there be a simple way to have a "import new" option that opens up a file dialogue from which you can copy/move a file into the tree and turn it into a resource in one step?

Although the in-editor documentation has me excited (for a calm sort of excitement) so I might do that. And considering how long it is open I guess it is more than a crazy idea.

[alexgleason]

> World Editor

Please this!! It would improve map creation to the same caliber as multi-tileset support in 1.6.

[wizard_wizzle (aka ZeldaHistorian)]

That world editor idea is definitely the one I'd be most excited about. That would have saved me literally days of time in my game's development, with having to set all of those values manually. If you have a lot of maps this can be incredibly difficult. And don't even TRY to add one later or re-arrange them!

[Cluedrew]

Modifying the new quest selection method is still on my list as a polish thing, or is creating quests in the wrong place just me? But it looks like world editor is the popular option.

There is a question about how to do it. The big question is do we add any overhead data (or change how some of these things are stored to the same effect), and were that will go. It might be able to be done just by scanning other data, such as looking at the maps to see what worlds exist and where maps are in them. In which case no files will have to be changed to store this information. The maps are scanned when you open the editor and any changes written back (to possibly a bunch of files) when you save.

Which does also raise the question of how you open it but it can be a menu option somewhere. And that is all I have to say about it right now.

[alexgleason]

Here is my suggestion for the world editor:

1. Quest data shouldn't be changed. It doesn't need to be changed. It seems like a bad idea that could introduce bugs. The quest files already give all the data you need.

2. Worlds shouldn't be shown in the file tree. Solarus 1.5's file tree did not reflect the actual filesystem, and in 1.6 there was a deliberate choice to make the file tree reflect *real files in the OS*. I think we should stick to that, because it's a good decision.

3. The world editor should be accessible from Tools > World editor. A dropdown of all worlds is generated from the quest data, and the user can switch between them.

4. The world editor can also be accessed from within any map, by clicking an "edit" button beside the "world" field. This would spawn a world editor tab with that dropdown already chosen.

5. The world editor should show all maps for that world, letting the user click and drag them to any position.

6. Single-clicking a map in the world editor makes it selected. The left sidebar shows that map's coordinates which can also be edited manually.

7. Double-clicking a map in the world editor opens a new tab with that map.

8. When maps are saved, the world editor is automatically refreshed.

[oclero]

I agree with aexgleason.
But isn't the world actually sort of a meta-map?

[alexgleason]

I opened a GitLab issue here: https://gitlab.com/solarus-games/solarus-quest-editor/issues/442

[Cluedrew]

I have continued the conversation to Alex's GitLab issue. Including my reply to Neovyse (short version: yes).