Messages

I suggest to add print() instructions to debug your variables. Apparently, the y value of your particles is to high, so they all end up outside the screen, too much to the south.

The method looks good to me: make a separate file, call it with require, forward on_draw() calls to it.

There is a first error that explains why nothing happens: in your map script, the emitter variable is a local to the sensor:on_activated() function. So it is always nil in map:on_update() and map:on_draw(). Simply declare it local to the map script instead of local to a function.

Then, using on_update() is probably a bad idea because you don't know how often the engine calls map:on_update(). It will work, but the recommended way is to use a timer. With a timer you can control the delay. And since Solarus 1.2, you can repeat a timer by returning true from its callback.

Here is the windows snapshot of today's development version of Solarus 1.2.1.
entity:is_in_same_region() should now give correct results. Enjoy!

Solarus 1.2.1 is not released yet, but I can make a windows snapshot the development version.

I wrote a script that does something similar, except that in my case I re-create the enemies when changing region, even the ones that were dead. I do this only for enemies and separators that have a special prefix.

Here is what I would do in your case (this was not tested though):

Create a file maps/lib/separator_manager.lua with:

Code Select Expand


-- This script manages enemies when there are separators in a map.
-- Enemies that are prefixed by "auto_enemy" are automatically
-- reset at their initial position when taking separators prefixed by "auto_separator".

local separator_manager = {}

function separator_manager:manage_map(map)

  local enemy_places = {}

  -- Store the position and properties of enemies.
  for enemy in map:get_entities("auto_enemy") do
    local x, y, layer = enemy:get_position()
    enemy_places[#enemy_places + 1] = {
      x = x,
      y = y,
      layer = layer,
      direction = enemy:get_sprite():get_direction(),
      enemy = enemy,
    }
  end

  -- Function called when a separator was just taken.
  local function separator_on_activated(separator)

    local hero = map:get_hero()
    for _, enemy_place in ipairs(enemy_places) do
      local enemy = enemy_place.enemy

      if enemy:exists() and
          enemy:is_in_same_region(hero) then
        -- The enemy is still alive: reset its position if he is in the new active region.
        enemy:set_position(enemy_place.x, enemy_place.y, enemy_place.layer)
        enemy:get_sprite():set_direction(enemy_place.direction)
        enemy:restart()
      end
    end
  end

  for separator in map:get_entities("auto_separator") do
    separator.on_activated = separator_on_activated
  end

end

return separator_manager


To activate this script on a map, do this from the map script:

Code Select Expand


local separator_manager = require("maps/lib/separator_manager")
separator_manager:manage_map(map)


I am not sure that you have to stop enemies in other regions (and by the way, if you want to stop them, use enemy:set_enabled(false)). Just make sure that they can't get too close to the border, otherwise you could see part of their sprite and you could even attack them. When you use separators, all enemy scripts must call enemy:in_in_same_region(hero) before going toward the hero.
Another solution is to destroy all enemies except the ones of the current region. But this does directly not work for you because you don't want to resurrect the dead ones.

Other remarks:
- entity:is_in_same_region(other) is buggy in Solarus 1.2.0. It is fixed in Solarus 1.2.1, the development version. If you use the git version (branch master), you will be okay.
- With my code, perhaps the player will have time to see enemies instantly move back to their initial position, shortly after taking the separator. I have a few ideas about to fix that, but we can talk about it later if you have the problem.

Some of your suggestions were implemented in Solarus 1.2 that was released a few days ago:

• When changing the id of an item in the left selector pane, the current id could be the default in the dialog.

Done in 1.2.

• Holding "control" and using the mouse wheel could zoom the view.

Done in 1.2.

• Making some tweaks to make the editor more friendly to smaller resolutions would be helpful - I have a machine running at 1024x768 and there are times when I can't see everything in a dialog box. One example is the new "destructible" dialog - would it be possible to lay things out differently so the dialog isn't so big?

Done in 1.2. The dialog of destructibles now has a vertical scrollbar if needed.

The "X" button on tabs is not done yet, neither is the "play music" button. These improvements are planned for Solarus 1.3.

I've been following the engine from the beginning and developing very early on

Wow! That's right, I found an e-mail from you of June 2010. The engine and the API have changed a lot since then! I'm glad to realize that you successfully upgraded to each new version and always carried on

The timer callback is persistent indeed. However, the callback you pass to the timer is a function value, not a string. Its name has no importance: the timer stores its code. (All functions are anonymous in Lua, but you can assign a function to a variable). So the end_race_lost function that you declare on the second map has no effect. The one of the first map is the one called, even if you are in the second map. This is why you have the bug.

So, if I understand correctly, torch_1, torch_2 and torch_3 exist on both maps? And you want to unlight them? If yes, here is what you can do:

Code Select Expand

sol.audio.play_sound("wrong")
game:set_value("i1028", 4)
local map = game:get_map()
map:get_entity("torch_1"):get_sprite():set_animation("unlit")
map:get_entity("torch_2"):get_sprite():set_animation("unlit")
map:get_entity("torch_3"):get_sprite():set_animation("unlit")
game.race_timer = nil

This callback should work for both maps

PS: "i1028" is a poor savegame variable name, you can use more meaningful names for your savegame variables. ZSDX use this kind of names for historical reasons (in very old Solarus versions, savegame variables were identified by numbers only).

In your function end_race_lost, you are probably looking up names that refer to map entities from the previous map. Since that map is not running anymore, this does not work.

For example, assuming that you have a map entity called my_npc in the map where the timer is created:

Code Select Expand

local function end_race_lost
  sol.audio.play_sound("too_late")
  my_npc:get_sprite():set_animation("walking")
end

It does not make sense to access my_npc when its map is no longer the current map.
But here is what happens exactly: the name my_npc was not declared before: therefore, it is resolved lazily when the function end_race_lost is executed. This generates the cryptic error that you get. In 1.3, it will get a nil value instead of this weird error message.

There is a way to access it anyway:

Code Select Expand


local some_npc_safe = some_npc  -- Resolve the entity while the map is still running.
local function end_race_lost
  sol.audio.play_sound("too_late")
  some_npc_safe:get_sprite():set_animation("walking")
end

or if you prefer:

Code Select Expand


local some_npc = map:get_entity("some_npc")  -- Resolve the entity while the map is still running.
local function end_race_lost
  sol.audio.play_sound("too_late")
  some_npc:get_sprite():set_animation("walking")
end

Anyway, in your case, I don't think you really want to access entities from the previous map. So instead, you should probably just check if the map is the current one, with something like:

Code Select Expand


local function end_race_lost
  sol.audio.play_sound("too_late")
  if map == game:get_map() then  -- If this is still the current map.
    some_npc:get_sprite():set_animation("walking")
  end
end

Hi,

There seems to be a bug in the engine: when you declare a global variable in a map script, and try to access it from another map script, it is nil. So this is not a timer problem.
I never found this bug before because I don't use global variables

I am going to fix it, but in the meantime, what you can do is declaring this variable in the game object. This is also better because you will avoid a global variable.

Code Select Expand

game.race_timer = sol.timer.start(game, 140000, end_race_lost)
game.race_timer:set_with_sound(true)

Code Select Expand

if game.race_timer ~= nil then

EDIT: fixed! https://github.com/christopho/solarus/issues/507
Thanks for the report.

Welcome to the forum!
Glad to see that you are interested in our work

Hi,

fixed8.fon is a font that we used in Zelda Mystery of Solarus DX. With SDL 2, there is a bug and for some reason this font cannot be loaded. Its license was unclear anyway so I replaced it by this one.
You can do the same in your game, or simply remove it if you don't use it.
See this commit to know how to do the change.

I will update the migration guide.

Hi,
Wow that was fast
Which exact version of SDL2 is used? SDL 2.0.0 is known to be buggy, and SDL 2.0.1 works fine on PCs.

Are you in fullscreen when you have the bug?
By default, in windowed mode, the "normal" video mode uses a window size of 640x320 indeed. But this should not impact fullscreen.

Can you try this patch: https://github.com/christopho/solarus/commit/5ffb8333634a4623b35c240bfa116ca79eee1109
This is a commit that vlag did to fix a bug similar to what you describe. (I reverted it for now though because it introduced other problems.).

No idea, sorry. I don't have an Android.

Another idea: I haven't tested this, but maybe you could move the camera, and from the camera callback, teleport the hero at the camera position. This way, the camera will not return at its initial position.