Messages

This is so cool. It gives me nostalgia from gameboy Zelda games...
Do you intend to make a project like this with Solarus? If so, and in case you want to collaborate with others for mapping overworld and dungeons, I might join.

[vote for 2 options]

Hi pals! I am a very curious person, and I was wondering which elements of the gameplay of a Zelda-like game are more important for most of the players (which is quite subjective to each one's opinion), so I created this poll.

The result can be useful to quest makers in order to make a game with balanced gameplay/mechanics according to what most of the people want.

You can vote for 2 options, to choose the 2 options you think are more important. I think it is a bit hard to choose since all elements are very important in my opinion.

PS: do not vote random, please!

I point out that this direction fix only works correctly if the fixed animation has the same frame number than the original animation. Otherwise the frame position is reseted to the first frame each instant and the new animation would not be played since it would stay stuck at the first frame. But this can be solved just by saving in some variable the current frame position, and the remaining time of the current frame using a timer.

Hi @MetalZelda. You might still have a problem that I have, but I still have not found a solution and we will probably need to wait for some improvements of the engine.

The problem is when you sidewalk against a wall while using some weapon (your bow and fire rod, and in my case a custom sword), the hero may start the pushing animation and it cannot be avoided. An animation fix is not a solution since the hero could still push built-in blocks (he would be in "push" state), and only the first frame would be shown if the "pushing" and "walking_with_weapon" animations do not have the same number of frames (i.e., the frame position would be reseted).

If you have any idea how to solve this issue please tell me. Thanks!
(I need this to program the "sword_tapping" for my custom sword, overriding the pushing state somehow.)

In my opinion, a story writting section is not really necessary, and it is too soon for a competition section since there is few people using the engine. But the competition section may be cool in the future when many more people start using the engine.

There will be a cleaner solution for my problem when this issue is closed: https://github.com/christopho/solarus/issues/873
(it is a request of the function hero:is_walking()).

Edit: Christopho has already solved the issue (and hence my problem).

[EDIT: I was wrong, there is still a problem.]

Ok, I finally solved my problem. (And it would be better to keep the current behavior of the engine, so I will not open an issue.)

If I start a new animation while walking, that animation will not stop until the hero stops walking. Hence, after the jumping animation, what I did is just as easy (and silly) as setting the animation of the hero to the "walking" one. If the hero continues walking there is no problem since the animation is already the walking one; and if the hero suddenly stops, then the built-in behavior (with the stopped animation) is started again; so in any case there is no problem.

My personal recomendation: if an item does not freeze the hero (i.e., we unfreeze the hero immediately when starting to use the item) and changes the walking animation at the same time, then we must set the animation to the walking one when (or before) we finish using the item. (This was the case of my feather script, which does not freeze the hero and changes the walking animation to a different one.)

(If we do not set any animation and the hero keeps walking, the hero would keep the previous animation until he stops. And if we set the stopped animation when we finish using the item, in case the hero has not stopped walking, the "stopped" animation would be kept while walking until the hero stops. In both cases this is not good. So the only solution is to change the animation to the walking one when we have finished using the item.)

EDIT: I was wrong, there is still a problem. Setting the animation to the walking one only works if the hero was walking during the change of animation. But if the hero was not moving, then he would start the walking animation while he is stopped, and the built-in behavior will only start when the hero is moved...

@Christopho: How can I make the hero start the correct animation stopped/walking after the change of animation? Is there some way to know if the hero is walking or stopped without using the sprite animation?

EDIT2: I realized that there is an easy solution, using 2 equal animations jumping_stopped and jumping_walking, instead of only one, so I can know if I need the stopped or the walking animation. I will test it later. Sorry for the long posts.

@MetalZelda: you are right, this has nothing to do with "item:set_finished()".

I made a test (and I think I found a way to reproduce something related to my problem): I made a sensor and changed the animation of the hero in the event "sensor:on_activated()". Then, what happens is that if the hero walks over the sensor, the new animation (which in my case has a loop, although this does not matter) is started, but it does not end until the hero stops walking (when he stops, the "stopped" animation is set again).

I think that the problem is that if we change the animation while walking, the built-in behavior does not start until the hero stops walking.

It is great to see that this works so nice. I have improved my custom jump and custom carry items using the animation fix.

But I am still  having an issue with the animation fix in my custom jump script (which could be considered a bug). I guess that MetalZelda may be having the same issue with his item scripts.

During the custom jump the hero is unfrozen by my script, and when the jump is finished the animation fix is reseted (the variables of my script are set to nil), so the engine can use again the built-in animations: "stopped" and "walking". The "stopped" animation is then set automatically by the engine. But if the hero is already moving and has not stopped, the "walking" animation is not started, and the hero continues moving with the "stopped" animation. (When the movement is stopped and the hero starts moving again, the "walking" animation is then used by the engine and the problem disappears.) So this is a problem when the hero is moving and the engine sets the "stopped" animation instead of the "walking" one. I do not know if this has something to do with the function "item:set_finished()".

@Christopho: Should I open an issue on github for this problem?

Mmmm... maybe the engine is not calling the event "tunic_sprite:on_animation_changed()" when the hero unfreezes, or something like that. Maybe you can change the animation again after calling "hero:unfreeze()", but I am not sure that I understand your problem...

Hi! They always replace the animations, unless you set them to nil value with the setter functions.

Be careful because I redefined hero.on_created and hero.set_tunic_sprite_id (to define the events on the tunic sprite when the hero is created, and also when the tunic sprite is replaced for a new one).

Edit: yes. The direction fix and the animation fix are independent one from the other.

Hi, here is part of a script I made to (re)define some functions of the metatable of the hero. In this piece of code a few functions which allow fixing direction and walking and stopped animations are defined. The trick I am using was an idea that MetalZelda posted in an older topic (http://forum.solarus-games.org/index.php/topic,448.0.html). It was not possible until now that Christopho has improved solarus in the development version of 1.5.

My custom functions:
-The direction fix allows to walk sideways, which is useful for some weapons. The following functions are defined:

Code (Lua) Select Expand


hero:set_fixed_direction(direction)
hero:get_fixed_direction()
-The fixing animation function allows to simplify some code in case you are changing the stopped/walking animations of the tunic of the hero for some purposes. In my case, I was changing to a jumping tunic (for a custom jump) and a carrying tunic (for a custom carry that allows carrying custom entities). This now can be done without changing the tunic sprite, using the functions:

Code (Lua) Select Expand


hero:set_fixed_animations(stopped_animation, walking_animation)
hero:get_fixed_animations()

The code can be put in some script apart. Be careful since it may override some function or event of the hero metatable in case you have defined it elsewhere. The code is here:

Code (Lua) Select Expand


local hero_meta = sol.main.get_metatable("hero")

-- Function to set a fixed direction for the hero (or nil to disable it).
function hero_meta:set_fixed_direction(direction)
  self.fixed_direction = direction
  if direction then
    self:get_sprite("tunic"):set_direction(direction)
  end
end
-- Function to get a fixed direction for the hero.
function hero_meta:get_fixed_direction()
  return self.fixed_direction
end
-- Function to set fixed stopped/walking animations for the hero (or nil to disable it).
function hero_meta:set_fixed_animations(stopped_animation, walking_animation)
  self.fixed_stopped_animation = stopped_animation
  self.fixed_walking_animation = walking_animation
end
-- Function to get fixed stopped/walking animations for the hero.
function hero_meta:get_fixed_animations()
  return self.fixed_stopped_animation, self.fixed_walking_animation
end

-- Initialize events to fix direction and animation for the tunic sprite of the hero.
-- To do it, we redefine the on_created and set_tunic_sprite_id events using the hero metatable.
do
  local function initialize_fixing_functions(hero)
    -- Define events for the tunic sprite.
    local sprite = hero:get_sprite("tunic")
    function sprite:on_animation_changed(animation)
      local fixed_stopped_animation = hero.fixed_stopped_animation
      local fixed_walking_animation = hero.fixed_walking_animation
      local tunic_animation = sprite:get_animation()
      if tunic_animation == "stopped" and fixed_stopped_animation ~= nil then
        if fixed_stopped_animation ~= tunic_animation then
          sprite:set_animation(fixed_stopped_animation)
        end
      elseif tunic_animation == "walking" and fixed_walking_animation ~= nil then
        if fixed_walking_animation ~= tunic_animation then
          sprite:set_animation(fixed_walking_animation)
        end
      end
    end
    function sprite:on_direction_changed(animation, direction)
      local fixed_direction = hero.fixed_direction
      local tunic_direction = sprite:get_direction()
      if fixed_direction ~= nil and fixed_direction ~= tunic_direction then
        sprite:set_direction(fixed_direction)
      end
    end
  end
  -- Initialize fixing functions when the hero is created.
  function hero_meta:on_created()
    initialize_fixing_functions(self)
  end
  -- Initialize fixing functions for the new sprite when the sprite is replaced for a new one.
  local old_set_tunic = hero_meta.set_tunic_sprite_id -- Redefine this function.
  function hero_meta:set_tunic_sprite_id(sprite_id)
    old_set_tunic(self, sprite_id)
    initialize_fixing_functions(self)
  end
end

Hi wrightmat. Which version of Solarus are you using? There were some issues with Solarus 1.4 which are fixed in the dev version (thanks to Christopho). Make a backup and test it with the development version, so we can know if the issue comes from the engine or not. (My slime enemy works fine in the dev version, but probably not in 1.4.)

@wrightmat: Hi! Yes, of course you can use it!

I have added a previous version of the slime enemy that jumps to the sample quest. You can get it here:
https://github.com/christopho/solarus/blob/dev/sample_quest/data/enemies/slime_green.lua

I explained some things about this trajectory here (MetalZelda is using it too for his fishing rod):
http://forum.solarus-games.org/index.php/topic,572.0.html

That trajectory is the same I use for the jump of the hero (shifting the sprite).

The important part of the code is the following part (of course there are more details, like the creation of the shadow, etc, that you can check in the script of the slime enemy):

Code (Lua) Select Expand


  -- Start shift on sprite.
  local function f(t) -- Shifting function.
    return math.floor(4 * max_height * (t / jump_duration - (t / jump_duration) ^ 2))
  end
  local t = 0
  local refreshing_time = 10
  sol.timer.start(self, refreshing_time, function() -- Update shift each 10 milliseconds.
    sprite:set_xy(0, -f(t))
    t = t + refreshing_time
    if t > jump_duration then return false
      else return true
    end
  end)


Hi! I think this can be done using some of the Lua functions for strings. Probably the best option will be just using "string.match" (the function "string.find" could be useful too, but maybe worse). (I think "string.gmatch" is similar, but it gives an iterator to find patterns instead, if I am not wrong.) It should not be too hard (but I agree these things are annoying and too easy to forget). Fortunately there are good tutorials explaining how to get the patterns. Check the following links in the given order:

A very nice tutorial which I used once and found it greatly useful:
http://lua-users.org/wiki/PatternsTutorial

A manual about patterns which may help too:
http://www.lua.org/manual/5.2/manual.html#6.4.1

A list of Lua string functions (you do not need this now, but it may help for other purposes):
http://lua-users.org/wiki/StringLibraryTutorial

I cannot help you more since I have forgotten how to use the patterns, so I would need to study the tutorials again.

EDIT: you may also find some examples of uses of the "string.match" function in your dialog box script.

EDIT2: be careful because some of the characters you use (like "[" and "]") have special uses for the pattern syntax (they are called magic characters in the second link), as you can read in the tutorials. You can match them using "%" before them, i.e., with "%[" and "%]".