Messages

Thanks llamazing! I've been wondering about this for a while too, I thought it was for a completely different reason. I feel better about mainly mixing them randomly now, lol.

You should probably know before you try coding though, I don't think Solarus has two tracks for music, so crossfading would (as far as I can tell) be impossible, since playing a new track automatically overwrites the current track. I'd recommend a quicker fade so there isn't much silence. Or embrace the silence and compose tracks like Breath of the Wild's.

Pretty cool! If you figure out how to display a shadow when something is jumping, let me know- I've tried to avoid using the jump movement because it's so hard to understand what's happening when the engine doesn't draw a shadow.

Question though- your random function thing is elegant, and I'm going to try to understand it because I don't quote yet. But my question is, would something like this work?:

Code (lua) Select Expand


function enemy:on_restarted()
local action = math.random(1, 4)
if action >2 then enemy:pause() else enemy:jump()
end



This seems simpler to me, but perhaps it's because I'm still at a pretty basic level of understanding tables and stuff in lua. Although, I guess yours is a more adaptable system, so if you were, for example, programming a game's boss and he had ten different attacks, you wouldn't need to do an "if/then" 10 times.

Ah, and a related question! It seems like streams continue pushing the hero even when she is in the falling state? Is this intended?

I'm using stream entities that are wind from fans where you're supposed to place a bomb on them and it'll blow across a hole to get a switch. But if the hero stands in the wind, she will blow into the hole and fall... except while she's falling she'll blow to the other side and be fine.

Something like hero:get_movement():stop() won't work to stop this either, because even if the hero has no movement, the streams continue to act upon the hero. Anybody know a way to keep a falling hero from being effected by streams?

No problem, that'll do

By the way, I didn't see it on the website anywhere, do you guys have a release window for 1.6?

So I'm working with some stream entities in a dungeon, and I'm realizing that my dash item allows you to bypass them pretty easily. I might just design around this, but is there a way for code to know if the hero is on a stream? I'd been thinking streams were just a type of ground and I could handle them the same way I handle dashing across holes or deep water, but since they're a map entity, that won't work.

I guess I could run code every 1ms or so that gets all the steams in a map with map:get_entities_by_type, and then checks their coordinates against the hero's. Or try map:get_entities_in_ractangle, the rectangle being the hero's 16x16 box. But running either of these constantly whenever dashing just to check for streams seems inelegant. Is there a better way?

Also, little hint, if you want to use the action key to "dash" if possible, do like so

Code (lua) Select Expand

if key == game:get_value("_keyboard_action") 

That way, if you rebind the action key, the dash action will also be rebinded

That's a great observation! Thanks, changing that in my game right away, haha.

Wouldn't hero:on_position_changed() works on this case ? It should be better to check the ground that way ?

I agree, that'd be a good way. Then you'd probably want to use hero:get_ground_below() to check to see if you're over a hole or water or lava- I only addressed holes in my script because in my game, you never gain the ability to swim and I don't have any lava, but upon further introspection I can see how these issues would also need to be addressed by other developers using this code, lol :p

That looks great! I like your big sprites, how's that going?

I was also thinking about implementing a cooldown timer the same way, so nice! I don't have magic or multiple items in my game (never figured out an item selection menu and just decided to roll with it), so I never bothered pursuing those options, but those are both great ideas, especially magic consumption. Another good option might be having a very short dash available at the start, and upgrading it throughout the game to be faster, longer, have a shorter cooldown, use less magic, etc., and designing that to be a fundamental part of your game.

I think whether or not you have the dash as its own item would have a lot to do with how you intend the player to use it in combat. Is combat designed around the player being able to dodge enemy attacks, or is this just an add-on? I've found (to me) that Link to the Past's combat isn't amazing. I image it was great for the time, and it's functional if enemies have a wide variation of different movements, attacks, patterns, weaknesses, but it's never great (maybe some bosses might reach that level). Hopefully, with abilities like dodging, an active shield (like Link's Awakening or Minish Cap), and different enemy behaviors, we can make combat more engaging for a modern audience. Side note, I think the game Blossom Tales went a long way toward more engaging combat just by not freezing the hero when they're attacking.

Awesome! Since I have several areas where pits are supposed to be obstacles and I don't want to redesign them, I'll try to stop the movement. I'm calling hero:on_state_changed(state), and if the hero's state == falling, then stopping the movement. This seems to work, hopefully it doesn't give me problems if I decide to use hero:on_state_changed(state) somewhere else!

I tried using the multievents script to format this, but I didn't know how to get the argument passed on with that syntax.

Code (lua) Select Expand


hero:register_event("on_state_changed", function()
  if state == "falling" then --some code
  end
end)

With this syntax, I don't know how to pass on the state argument



Anyway, this works, even with pits, as long as you're not calling hero:on_state_changed() anywhere else!

Code (lua) Select Expand


function game:on_key_pressed(key, modifiers)
  if key == "space" then
    local effect = game:get_command_effect("action")
    local state = hero:get_state()
    --make sure the conditions are right to dash and we're not doing something else or don't have the item that allows this
    if game:has_item("dandelion_charm") and effect == nil and state == "free" and game:is_suspended() == false then
      local dir = hero:get_direction()
      --convert the direction we just got into radians so straight movement can use it
      if dir == 1 then dir = (math.pi/2) elseif dir == 2 then dir = math.pi elseif dir == 3 then dir = (3*math.pi/2) end
      local m = sol.movement.create("straight")
      m:set_angle(dir)
      m:set_speed(325)
      m:set_max_distance(75) --you may want to make this into a variable so you could upgrade the dash
      m:set_smooth(true)
      hero:freeze()
--      hero:set_blinking(true, 200) --this is just a stylistic choice. It makes it move obvious that you can dash through enemies if you enable it, but in my situation the dashing animation didn't read as clearly.
      hero:get_sprite():set_animation("dash", function() hero:get_sprite():set_animation("walking") end)
      sol.audio.play_sound("swim") --this is a placeholder sound effect that everyone should have, you'd want to change it probably
      m:start(hero, function() hero:unfreeze() end)
      hero:set_invincible(true, 300) --you may want to experiment with this number, which is how long the hero is invincible for
      function m:on_obstacle_reached()
        hero:unfreeze()
      end
--this is the new code to stop the dash from going over holes.
      function hero:on_state_changed(state)
        if state == "falling" then m:stop() end
      end
    end
end


Thanks for the help!

So, I've got a fairly robust script for allowing the hero to dodge/dash around when you press the action key- basically rolling from Minish Cap, except you're invincible during it so you can dodge through enemies. If you wanted to adapt this to rolling like many zelda games have, I'm pretty sure this would work fine, just take out the hero:set_invincible() line.

Here's a youtube video of it in action

So, it's working pretty well, except it currently allows the hero to dash over holes (I'm not entirely sure why this is). I have two options for how I want to deal with that. Either I want to stop this from letting you dash over holes, or I want to allow it, but prevent the "falling into hole" sound and animation from playing. Right now, the hero will dash over a hole, but after touching the pit, the hero's animation will be "falling" until she finishes the dash and the "falling" sound effect will play.

Anybody have any ideas how to deal with this?


Anyway, here's the code. If you'd like to use it right now (be aware of the issue with holes I mentioned.) you'll need an animation for the hero called "dash", replace the item on line 6 with whatever item you want to require to allow this, and you can put this code in your game_manager script or wherever. That's where I handle all of my key press events, personally.

Code (lua) Select Expand


function game:on_key_pressed(key, modifiers)
  if key == "space" then
    local effect = game:get_command_effect("action")
    local state = hero:get_state()
    --make sure the conditions are right to dash and we're not doing something else or don't have the item that allows this
    if game:has_item("dandelion_charm") and effect == nil and state == "free" and game:is_suspended() == false then
      local dir = hero:get_direction()
      --convert the direction we just got into radians so straight movement can use it
      if dir == 1 then dir = (math.pi/2) elseif dir == 2 then dir = math.pi elseif dir == 3 then dir = (3*math.pi/2) end
      local m = sol.movement.create("straight")
      m:set_angle(dir)
      m:set_speed(325)
      m:set_max_distance(75) --you may want to make this into a variable so you could upgrade the dash
      m:set_smooth(true)
      hero:freeze()
--      hero:set_blinking(true, 200) --this is just a stylistic choice. It makes it move obvious that you can dash through enemies if you enable it, but in my situation the dashing animation didn't read as clearly.
      hero:get_sprite():set_animation("dash", function() hero:get_sprite():set_animation("walking") end)
      sol.audio.play_sound("swim") --this is a placeholder sound effect that everyone should have, you'd want to change it probably
      m:start(hero, function() hero:unfreeze() end)
      hero:set_invincible(true, 300) --you may want to experiment with this number, which is how long the hero is invincible for
      function m:on_obstacle_reached()
        hero:unfreeze()
      end
    end
end


I noticed something else in your code- the movement creation isn't inside any function, and it looks like you have an extra "end" after the code that has to do with the movement. I'd put the movement stuff in map:on_started()

Hey, just a question, what was the problem with your octorocks/what did you do to fix them? I've had a similar problem.

Just thought I'd post to say progress is going well, I'm deep into building out the next major area, half of its main quests are done, as is the mapping. This area is coming along nicely so I thought I'd do a screenshot before I rush off to work. Thanks for following!

One thing you could try is going into your main.lua script. There's some lines in there that handle key presses, I think the function is sol.main:on_key_pressed? Something like that. Anyway, that handles special keys, you can see there the format is stuff like, if key==f5 do this, if key ==escape, do this. You'll want some code like:

If key == "w" then
If game:get_ability("tunic") == 1 then game:set_ability("tunic", 2)

And vice versa. If you're still not familiar enough with Lua to notice, what I typed is not correct code (there are no "end"s for the conditional branches), so don't try copy/pasting or it'll just give you errors, haha, but that's the general idea which I think should work. You can look those methods up in the Solarus documentation and ask more questions of you don't understand them : )

I'm not 100% sure how y-order works, but would you maybe want the entity to follow the hero's coordinates, but Y+1 so it's slightly "lower"/south/in-front-of the hero?