Messages

I don't know, do you have an error message in error.txt?
Do you correctly call your hud script from somewhere?

Thank you for answering. For now, it does not work.
I kept the sprite "sprites/enemies/enemy_killed.png", but added several animations to it (Just a change of colors to test).
I simply copied / pasted the lines from enemy_killed.dat and put y = 32.
So I get two animations in enemy_killed.dat ("killed" and "test")

In   function enemy:on_dying(),   I added

Code Select Expand

sprite:set_animation("test")
This tries to work with the enemy sprite and not "enemy_killed.png"
So I put this instead.

Code Select Expand

local sprite2 = enemy:get_sprite()
sprite2:set_animation("test")
This tries to work too with the enemy sprite.and not "enemy_killed.png"

OK, so I tried another thing, I copied my new lines from enemy_killed.dat to paste them into .dat of the enemy.
It's not OK, because the enemy sprite is replaced too soon and then there is the usual animation called "killed".
Moreover, the animation is either too fast (I played with the "frame_delay") or incomplete  because the sprite is killed.

You are right... So, there is no way in the current API to access the "enemies/enemy_killed" sprite that the engine automatically created. (Unless by doing ugly funny things with sprite metatables... )

I even deleted the pixels to make transparent the "killed" animation.
I tried with  a create_sprite, but Solarus crashes and I have nothing in error log.

Code Select Expand

local sprite2 = enemy:create_sprite("enemies/enemy_killed")

What I know is that the problem exists between keyboard and chair.

This should be the preferred workaround with the current API. The engine should not crash. I reported the bug here: https://github.com/christopho/solarus/issues/635 and I will fix it for the next bugfix release.

Thanks for your patience

See the doc of enemy:on_dying(): http://www.solarus-games.org/doc/latest/lua_api_enemy.html#lua_api_enemy_on_dying
Right now, dying animations are not really customizable. There is only this "hurt style" property that can choose between 3 built-in behaviors. It will be replaced one day by a more customizable API.

In the meantime, there should be a way: instead of changing the sprite, you can change the animation. Keep the sprite "entities/enemy_killed", but add several animations to it.
And in enemy:on_dying(), pick the animation of your choice.

If you really need different sprites, another way might be to make the sprite "entities/enemy_killed" show nothing (like a transparent pixel), and In enemy:on_dying(), create a new sprite of your choice.
Untested but could work

Thanks!
You can watch the tutorials to learn how to make a game with Solarus: https://www.youtube.com/watch?v=T9mEFmRVlBQ&list=PLzJ4jb-Y0ufwPrBfO5AQMRfe2kLABQsF0

You can already react to any key pressed, not only the high-level built-in game commands: http://www.solarus-games.org/doc/latest/lua_api_game.html#lua_api_game_on_key_pressed

As Renkineko said, most of this is possible, yes. Of course, it will require a lot of Lua scripting.

Simulating several characters is possible. There is only one playable hero. If you want other characters to appear on the screen, they can be NPCs or custom entities. And when you need to change the controlled character (like in Secret of Mana?), you can swap the position of the hero with the NPC to control, and change their sprites. It will look like the hero has changed.
(The bug of tunic sprites names is fixed: now the tunic sprite of the hero can have any name).

There is no particle engine, but I don't see why we could not make one in pure Lua scripting.

Generating maps dynamically is possible because there is a file API. You can create new files in the savegames directory, and if they are valid map data files, they can be played. You just have to respect the syntax of a map file, which is properly documented: http://www.solarus-games.org/doc/latest/quest_map_data_file.html
There is only one issue: any map needs to be declared in the resource list, and the resource list cannot be modified dynamically for now (is it loaded from project_db.dat and remains fixed then). I will solve this problem, however, in the meantime, a workaround is to pre-declare a lot of maps in project_db.dat even if they don't exist yet.

I confirm wrightmat's answer.
We have an issue for this: https://github.com/christopho/solarus/issues/466
surface:get_pixels() and surface:set_pixels() is a first good solution: you could at least build your own darkness mask.

It's weird, nothing has changed for OpenAL and PhysFS in 1.3. For Lua, we switched to LuaJIT but this was in Solarus 1.2.
Did you try to clean your cmake configuration (rm CMakeCache.txt)?

Hum, yes, it is a bug I was not aware of. I added it to the bug tracker: https://github.com/christopho/solarus/issues/617
As a workaround before the next bugfix release, you have to keep the word "tunic" in the id of the tunic sprite.
The same bug also exists with the sword. You have to keep the word "sword" in the id of the sword sprite.
Thanks for the report!

Thanks! Great work! I will update the download page.

Question about future releases: can you compile with C++11 on GCW-Zero? (and other devices?)
Because we are working in a separate branch with C++11, improving the quality of the code. I am not sure yet of when I can merge this work into master, it essentially depends on how C++11-compilant compilers are.

Hi,
Ok, I will check this problem for the next bug-fix release.

Not yet. You can do the change you suggested in a previous post in Video.cpp for now.

Not that I am aware of, sorry.

This is a good remark. I don't love project_db.dat either for various reasons. Sometimes it is complicated to keep it in sync with the actual files, for example when you copy resources from another project. It is also a source of conflicts when several people create different maps/sprites/etc in the same project at the same time.

Still, it is useful to maintain a list of resources. In some of my games, I have .lua files inside the map folder that are not maps but scripts that maps can call (but okay, there is no .dat file with it in that case so the auto-detection could work).
Also, I wouldn't like to have to browse subdirectories recursively to find resources. The engine would need to do so, as well as the editor and various tool scripts like data files converters.
project_db.dat also gives a user-friendly name to each resource. However, now that maps and tilesets are identified by strings instead of integers, this is not so important as before.

So, to conclude, I have mixed feelings about project_db.dat. I might remove it in the future, yes.

Now in your use case, you can add maps dynamically into the savegame directory and forget to add them to project_db.dat. These maps will work in the engine, but not in the editor and other tools. Which is not the ideal solution, I agree.

Yeah! How far can we play the game? Do you have an estimated completion percentage?