For mapping, this beautiful tileset by ffomega exists: http://forum.solarus-games.org/index.php/topic,651.0.html. I mention it here, because it's really well documented (there's a website with tutorials about how to use it and there are some example maps). Apart from that, you can download a lot of tilesets with ALTTP-Graphics (see the video tutorials for more information).

I tried to do the same with thing as the rupee counter with the hearts with no avail.

If I understand this correctly, you've already tried to make a HUD for the hearts. If you show the code of this attempt then maybe I could tell why it's not working.Have you tried watching the french tutorial video yet? Maybe you would understand it even without the explanations...Oh, and in case you didn't know: you can access the source code of the games made by Solarus Team. You can find the code for the hearts here: https://github.com/christopho/zsdx/blob/dev/data/hud/hearts.lua. Perhaps this will help you?

I do also think that story is perhaps most important. Unfortunately, I feel that a lot of Zelda-Fangames don't pay enough attention to make a good storyline. Even Mystery of Solarus is quite weak considering the story Personally, I'm not really much into exploration, what I like best about Zelda games is, when they connect combat and puzzles. For example, a boss that needs both skill, strategy and thought to be defeated.

hero:set_position(switch_x + 8, switch_y + 13)(It's plus 8 and 13 because the origin point of the hero is at those coordinates)Anyway, I'd still appreciate an explanation why wall entities are behaving like this. Your explanation makes kinda sense but I'd rather expect the hero to be stuck in the wall entity than to ignore it when they overlap each other. And still this

At first I tried to use only one big wall entity and position the switch on top of this entity (see first screenshot). This didn't work at all, I could leave the switch and go wherever I want. But the wall entity was activated because it's impossible to go back to the switch again once you leave it.

and this

Quote

usually the wall entities should be disabled again after some time but now the wall entity I glitched through stays activated while the other ones are disabled correctly.

Hello there For some kind of bow-shooting minigame I wanted to keep the hero from moving. I wanted to do this by blocking all directions with wall entities. I disable them, when the map starts and enable them, when the hero activates a walkable switch.However, the wall entities are kind of acting in a weird way...(I got no clue how to insert screenshots in the text so I am going to attach them to the post)At first I tried to use only one big wall entity and position the switch on top of this entity (see first screenshot). This didn't work at all, I could leave the switch and go wherever I want. But the wall entity was activated because it's impossible to go back to the switch again once you leave it.Afterwards I tried to block the way using four different wall entities (as seen in screenshot 2). This is very strange, sometimes I can leave the switch and go anywhere, sometimes not. Returning to the switch is always impossible. I came to think that it depends on whether the hero overlaps the switch completely.Finally I extended the four entities (screenshot 3), now it is acting similar to screenshot 2 but even stranger... Sometimes I end up blocked beneath the switch and sometimes I can slip through a wall entity as I did with the four smaller ones but this breaks the disabling of the wall entities; usually the wall entities should be disabled again after some time but now the wall entity I glitched through stays activated while the other ones are disabled correctly.Does anyone know why the walls behave like this? Is this intended?

I think that using tiles as a wall is a little bit better for performance but it'll problably not matter.The wall entity is better in my opinion because it can be configured to allow pass for some entities but not for others and because it is clear that its only purpose is to be a wall.

Perhaps you could give some context? Like, where those variables are defined and when the if-condition is checked. But anyway, it would probably be less error-prone to check inside of the timer whether it should still be executed. Like this:

I haven't yet experimented with arrow switches, so I can't help you with 1). But maybe you should post your code...About 2), it is certainly possible.For example, with 2 switches it should work like this:

function switch2:on_activated() if switch1:is_activated() then --activate the dynamic tile here endendIf you have a lot of switches, you could also automatically add the on_activated() functions automatically in a for-loop. They just should be named with numbers to do this, e.g. thispuzzle_switch1, thispuzzle_switch2...

Great!!! About half of the issues I'm having occur because I keep thinking that my files would be saved when I run the quest (Visual Studio has got this behaviour). Especially because I do test my quest very often.So thank you very much for solving half of my problems all at once