Messages

That's completely intended
If you open all chests, the last one contains a piece of heart. Where is that image from? I don't think there should be rupees in the chests. Maybe in an older version of the game...

It is not very useful as it currently is...
I would either improve or remove the background setting. To improve it, Zeror's suggestions are perfectly fine. It would also be a great improvement if an image loaded from a file or a tile of the tileset could be used as background (automatically repeated so that it covers the whole map). If the background setting is removed, any 8x8 tile could be used as background instead. In that case, an option like "always behind other tiles" would be cool so that "bring to back" could still be used without tiles disappearing behind the background.

I've recently changed the source image of the items sprite but it kept the old source image for all animations but the default one and the rupee item (for which I use the new sprite). I don't think it's intended but even if it is, it's not the behaviour I expected and wanted. Not so important anyway, it's just a bit annoying.

1.) Camera abilities
  -A function to center the camera on something else than the hero (an NPC, an enemy, a custom entity...)
  -A function to move the camera to a different map
  -A function to set the camera immediately to a point instead of moving it
2.) Code editor
  -A better syntax-highlighting (the one of the website is much better than the one of the code editor )
  -Save the indention of the previous line
3.) Allow to add own kinds of grounds

These are my current ideas what could be improved. If something else crosses my mind I will add it to this list

Thanks for making so much thoughts on this problem
The check for hero:get_state() == "freezed" didn't work. I think it's because only one single state can be saved and "freezed" is overwritten by "treasure". However, when I tried hero:get_state() == "treasure" instead it worked perfectly fine although it was just a wild guess. Is the "treasure" state only set for brandished treasures?

I've got an idea for another workaround. It would be like this:
1.) set_brandish_when_picked(false) is called in the on_created function and keeps this state
2.) When obtaining a variant of a rupee that hasn't been obtained yet, hero:start_treasure is called, causing the hero to brandish the treasure, no matter how the treasure is obtained.
3.) Change a global value to indicate that a treasure was created by hero:start_treasure. This is necessary because otherwise there would be an endless loop (on_obtaining starts a treasure that has an on_obtaining function that starts a treasure...)
4.) The old treasure has to be deleted so that the same treasure is not obtained twice (and the obtaining dialog is not called by the engine causing the same error as before)

This is my idea. However, I do not yet know how to do 4.)
I am not sure whether it is possible to delete a treasure when the on_obtaining function is called (in fact, I doubt it). An other way would be not to delete the treasure but
1.) Prevent rupees being added for the first treasure and
2.) Prevent the dialog being called automatically by the engine for the first treasure when the rupee comes from a chest.

Number one could be done quite easily (using the global variable from 3. to add the rupees only for the second treasure if there is any) but again, I don't have any idea how to prevent the dialog or whether this is even possible.
I know that this idea is kind of a dirty hack Well, it's just meant to be a solution until the bug is fixed in the engine. Hopefully it works

I don't really understand how this should work. Calling set_brandish_when_picked(false) in on_obtaining() doesn't affect the currently obtained rupee. So if I set the brandish to false in on_obtaining, unknown kinds of rupees won't be brandished anymore. The exception for green rupees is not really necessary, by the way.

When a kind of rupee is picked for the first time, I want my rupee system to show a message that informs the player about how much it is worth. I have tried to implement it like this:

Code ( lua) Select Expand


local item = ...

function item:on_created()
  self:set_shadow("small")
  self:set_brandish_when_picked(false)
  self:set_sound_when_picked("picked_rupee")
end

function item:on_obtaining(variant)
  local amounts = {1,5,10,20,50,100}
  local colors = {"green","blue","yellow","red","violet","orange"}
  local game = self:get_game()
  game:add_money(amounts[variant])
  local rupee_obtained = colors[variant] .. "_rupee_obtained"
  if not game:get_value(rupee_obtained) then
    game:set_value(rupee_obtained,true)
    if not (colors[variant] == "green") then
      local dialog_id = "_treasure.rupee." .. variant
      game:start_dialog(dialog_id)
    end
  end
end

This works fine for rupees that are lying around on the ground. However, when the first rupee of a color comes from a chest the game crashes because the same dialog is called twice (once by the engine, once by the item script in on_obtaining). Is there exist a way to get the origin of an item? I didn't find anything in the documentation but maybe there's a workaround? Any completely different solution is of course welcome as well

[EDIT:]

But dungeon 2 cannot be finished before visiting dungeon 4 because you need the flippers to reach the boss room.

Ok, I assumed that the dungeons should be completed in order because they are numbered. But maybe I've also misunderstood something due to my limited french knowledge.

The second dungeon boss is so easy with the second sword x)

Oh yes I was like "oh no, I'm gonna die! wait, why is the boss nearly dead now?"
Two new things:
1.) The shift-running command sometimes works when swimming and sometimes doesn't. Which one was intended?
2.) I don't know how, but I managed to screw the controls up a little bit. Because somehow caps lock is now normal speed and disabling caps lock makes the hero faster.
EDIT: I just found out that this happens when changing the caps lock outside of the game. So if I minimize the game, enable caps lock and open it again, the hero still walks with normal speed.

Hi there!
It was really a nice surprise to have a new and totally unexpected game programmed with solarus. The dungeons are a bit boring, though...
A few remarks:
1.) Somehow I can't use the hookshot when I'm still standing in the doorway. To be precise, I can use it, but it seems to be blocked by some sort of invisible obstacle.
2.) Should it really be possible to complete the third dungeon before the second? 

Another possible bug about freezing the hero: When I tried to freeze the hero when swimming, the swimming animation was replaced by the stopped one. I've attached a screenshot to this post.

It does work for me...
Are you trying this in the map script and have you written this line?

Code (lua) Select Expand

local map = ...
If your door is not a door entity but a dynamic tile, try this line

Code (lua) Select Expand

door_to_b1:set_enabled(false)
instead of map:open_doors()
Anyway, this code

Code (lua) Select Expand

if door_leftswitch:on_activated() and door_rightswitch:on_activated() then
  door_to_b1:is_opening("true")
end
can't work for the following reasons:
1.) on_activated() is a function that is called when the switch is activated. The function that tells you whether the switch is activated is called is_activated()
2.) is_opening is a function that returns a boolean value and doesn't take any parameters. So this won't have any effect.

I guess it works like this:

Code (lua) Select Expand


function door_leftswitch:on_activated()
  if door_rightswitch:is_activated() then
    map:open_doors("door_to_b1");
  end
end

function door_rightswitch:on_activated()
  if door_leftswitch:is_activated() then
    map:open_doors("door_to_b1");
  end
end


Yes, I'd appreciate this as well!

I'm not 100% sure, but maybe like this?

Code Select Expand


local map = ...

function map:on_started()
   local function restartMovement()
     movement:start(MovingFloor)
     movement:set_xy(0,96)
   end
   local movement = sol.movement.create("straight")
   movement:set_speed(64)
   movement:set_angle(math.pi)
   movement:set_ignore_obstacles()
   movement:set_max_distance(100)
   movement:start(MovingFloor,restartMovement)
 
end

I haven't tested it yet, though...