Messages

Yes and no. It works "almost" fine. The only problem is that I get a crash sometimes after the item falls if you walk where the shadow was removed, because the shadow entity I used was not removed correctly or something like that. I think that bug was already solved by Christopho in the development version, so my script should work in the next version (or it may become an error of my script that I should be able to correct).

I want to put my scripts on github after the next version of solarus is released (to check if it works and repair it if necessary), but I can put it now if you want. (Note that to make this script work you will also need to modify slightly the game:on_command_pressed() event, but this is not a problem.)

You can write everything directly in the event game:on_map_changed(map), but I would write a function in another script (made just for this) and call it in the event. You can do it as you prefer, that's not important.

I don't know how are your scripts. I have the event game:on_map_changed(map) defined in my game manager script, although you may have it in the main.lua. I cannot help you more, sorry.

I have never done this, so maybe this is not the best way to do it. This is what I would do, I hope it works.

Use the event teletransporter:on_activated() to set a custom state on the hero (or save the info that he is falling in some boolean variable). Then, on the method game:on_map_changed(), that you may have already defined in some of your main scripts, you call a function to simulate the falling "animation" in case it is necessary (I would save that function in some other script).

To do this function for the falling animation, you should freeze the hero, maybe make him able to traverse walls or ignore obstacles, create the shadow at his coordinates, change hero's position, start the movement and, at the end of the movement restore everything to normal.

You have a mistake in your code. Write "y = y" instead of "y = x".

@polyglot762, you have a mistake in your code. Write "y = y" instead of "y = x".

You should clarify more your question, it is quite ambiguous. Anyway, you should check Christopho's tutorials on youtube.

If you mean how to make the hero fall from a map to a different map, you may find the answer in this tutorial:
https://www.youtube.com/watch?v=4VIVdz3LPM4

Yes, I think you are right. (I wasn't sure how the mod (%) operator works with a negative numerator, so I added that #submenus term. I think your code works fine too.)

Hi!

I would use your solution too. I would try to change the animation in the event enemy:on_dying(), but I am not sure if it would work correctly since the sprites are replaced by "enemies/enemy_killed", but I don't know if that replacement is before or after the event (if it is before you should not have problems).

If that does not work, you can always use that event to remove the enemy and create other entity (temporarily) showing the dying animation you want or whatever. On the other hand, for custom entities everything is scripted, so you should not have any problem to show what you want (almost anything is possible with custom entities if you have patience to program).

It should also be possible to set an animation on an enemy depending on which weapon you use to kill it (so it would have several dying animations). One way to do this is to save in some variable (for instance, enemy.last_weapon) the name of the weapon you use to hit him each time, so that when it dies, you have in the variable the name of the last weapon that has hit the enemy, and then select the animation using the event enemy:on_dying().

Good luck with this!

I am not sure, but this could be the problem:

In the pause_submenu.lua file of Zelda Mystery of Solarus DX, in submenu:previous_submenu(), in line 125 you have

Code Select Expand


submenu_index = (submenu_index + 2) % #submenus + 1

which works fine only for 4 menus I think, but not in other cases. Try to change that line by:

Code Select Expand


submenu_index = (submenu_index + #submenus - 2) % #submenus + 1

But I am not sure at all if that will fix your problem.

EDIT: I suggest changing that line in the repository of Zelda Mystery of Solarus DX, to avoid more people having the same problem with the menus in case they copy the script. (But before we need confirmation that it works fine.)

Hi wrightmat,

I have modified the script (see the repository) so that the dialog font and font size are set using the custom function sol.language.get_dialog_font(), which is defined on the main script, and also corrected a syntax problem which could be the cause of the error you got. I think this is what you needed. Tell me if you still get some error.

I'll be happy to help with these things, and any suggestion to improve the script is welcome.

Hi! I don't have this error, and I don't see why it happens, it's very strange. Did you have it before making the changes? (We can discuss this by email if you want.)

I think the error is in the line with "surface:draw(self.dialog_surface, text_x, text_y)", but not sure, isn't it? (This could mean that some of the other surfaces has not been created correctly and is nil.)

In the script there are more text_surfaces, which are created if the commands ${surface_name} is used, so you would need to change the font in that part of the code too. (I would put all the properties of the font above, where the general properties are defined.) I will try to improve a bit the code of the file in the repository.

PS: If you find the syntax terrible, I can change it. Suggestions are welcome. (At present, ${surface_name} changes the current surface and the commands $[color] and $[(r,g,b)] change the color of the current surface. But I can make changes in the file to change the syntax.)

EDIT: I found a mistake on my code. I was using sol.text_surface.create{...} instead of sol.text_surface.create({...}), so the parentheses were missing. This may be the cause of your problem, although it is strange that I did not get an error with this.

It's already posted. I put an example of how to use the commands:

Code Select Expand


dialog{
  id = "put_the_dialog_id_here",
  text = [[
$[red]This is an ${g}$[green]example${default} to
show how the script
changes the ${y}$[(200,200,0)]colors.${default}$[white]
${y}Feel free ${g}to use or
modify it as you wish.${default}
=P
]]
}


I made the pull request. I put a link to the repository, just in case someone is interested in the script when it is posted there:
https://github.com/Nate-Devv/libsolarus-mudora

Hi there!

I have modified Christopho's dialog_box.lua file so that the dialog box allows some commands for colored text.

For this to work correctly it is required that all letters have the same width (which happens for the font I am using, but may not be true for some of the fonts you use), because letters of different colors are drawn in different text surfaces, and to align the letters I use spaces when necessary.

The syntax of the new commands is the following:

${surface_name}: change to other surface. This allows to use several colors at the same time, one for each surface. The original one is "${default}". (These surfaces are destroyed after the dialog and the default one is reseted to white color.) $[color] or $[(r,g,b)]: name of a color (red, blue,...) predefined in the function dialog_box:set_color(color), or RGB coordinates of some color. These commands only affect to the current surface.

(I was thinking that these surfaces could also be used to program other commands, for example to move letters up and down and make text vibration. I'll try to make this when I have some time.)

I'd like to share the code of the script. Should I post it here? Or maybe in the libsolarus-mudora repository?

Hi there!
I think Yruama is right. I have tested the following code and I have the same problem:

Code Select Expand


local map = ...

function switch:on_activated()
  local m
  m = sol.movement.create("path_finding")
  --m = sol.movement.create("target")
  m:set_target(map:get_entity("hero"))
  m:set_speed(64)
  m:start(NPC)
end

The NPC is on the same layer as the hero. The problem persists if I set other entity as the target. The entities are really close, so this is not a problem of distance. However, the movement works correctly if I use a movement of type "target".