Messages

You will need game:set_ability("sword_knowledge", 0) or something. Most of the documentation is around the paired get_ability.

https://www.solarus-games.org/doc/latest/lua_api_game.html#lua_api_game_get_ability

Even a single script, a sprite or sound effect can be a project. Maybe project was intended to mean game but I don't think there are any rules about. I might put my big project in scripts but it has no auto/visual component at all, its entirely scripts.

Actually one of my main comments about the project actually might not work depending on the amount of display work the library does. Have you considered making the number/names of menus configurable? To use a The Legend of Zelda example, could I set up "Main Quests", "Side Quests", "Shrine Quests" and "Memories"? Is there a way to do that?

I can help with the scripting. A bit directly but also I'm working on a library (Lua Nova on GitLab) that might let you do some of the puzzles easier.

How long is it? (I'm always "open" to play-testing but length of game really effects if I can commit to it or not.)

I haven't tried this but from the documentation and my memories from the one time a looked over this part of the engine you should be able to do something like Kamigousu's solution but say you have handled the input to prevent the action from happening:

Code Select Expand

function game:on_command_pressed(command)
    if "attack" == command and stamina < 0 then
        return true
    end
    -- Anything else you want to do.
end

Also returning false doesn't do anything so you can put the condition of the if statement as the return value if you are doing nothing else in the event.

It think so but I don't think it would be a small project. Unless there is a convenient cross-compiler and we can get our hands on all the dependencies and then maybe. Even that probably will not be enough. I don't do stuff online but most browsers provide their own main loop and we have to work off of that. The editor might work because I poked around and Qt seems to have some support.

But I am not an expert I just poked around a bit when I saw this.

[EponasRider]

To EponasRider: I can confirm that the engine is all made in C++. With a lot of the Qt library. Also that Max's comments about starting small are all good.

To Max: Do you have some numbers on how long the game should take to play through and when you need the results by? I'm not sure if I have time and that might help. I'm not really a Solarus Developer (I would on the editor mostly) but I'm still another pair of eyes.

Was an issue for the engine side problem created? I can't find it if one was.

I read the whole thing and it was really good. The mission/space thing (basically, create the points of interest and then map them to rooms) seems to lend itself really well to Zelda dungeons. In fact I have seen that process reversed just to talk about the dungeons that already exist.

There are a bunch of things I think you would have to do to make an actual game out of it. More rooms (possibly randomly generated to a degree themselves), the ability to swap out the dungeon item and other polish things. The interesting one would be messing with the mission to space mapping.

For instance, could you make the multi-part lock happen in a big central room that you see before hunting down enemies to open it? Could you put the items in a loop that quickly takes you back to an area you have been to before? How about short-cuts that make traversing the first part of the dungeon easier once you have the item?

You probably can, but I wonder if there is a somewhat elegant solution to it all. I am very impressed with the current system.

[Neovyse]

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

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.

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]

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.

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.