Messages

Fixed in 1.4.

I can't reproduce the crash with the current git version. It may already be fixed, or I did not exactly reproduced what you do. Can you send me your data?

Hi!
Solarus 1.2 introduced a few incompatible changes in the Lua API, so there is one obsolete thing in the tutorials about the HUD: the surface:set_transparency_color() call. There is no more set_transparency_color() function. Instead, just use the alpha channel to have transparency, and use surface:clear() to clear a surface.
This is explained in the "Surfaces" part of the migration guide here: http://wiki.solarus-games.org/doku.php?id=upgrade_from_1.1_to_1.2#surfaces
I am pretty sure that this should only incompatibility problem with the HUD tutorials.

Yes, bosses are often complex and often composed of several enemies.

Gelidrak creates its head and tail from enemy:on_enabled(), so it probably only works if you enable him dynamically, like when the hero enters the room. There is nothing special to do on the map script.

Ganon is more complex, a lot of things are controlled from the map script: https://github.com/christopho/zsdx/blob/master/data/maps/130.lua. The script of Ganon also controls dynamic tiles from the map (the falling floor), so it will probably not work if the expected dynamic tiles do not exist on the map. So this Ganon is very specific to ZSDX, I'm not sure it can be re-used directly, except if you want to reproduce the exact same fight.

All Lua scripts run is the same thread. If several timers expires in at same cycle, I think the first one created is treated first.

It is not that obvious in fact.
A way to detect when something is not colliding is to test if entity:overlaps(other). You can do it periodically from a timer, or only when your custom block moves (from custom_block:on_position_changed())

No, but you should be able to do it manually with a collision test on switches.

Maybe it works, but the collision test is repeatedly called, starting a new movement every time?
If this is the problem, adding a boolean on the block to remember if it is already being pushed or not should work. Or maybe just checking first that the block has no movement.

It is possible to be stuck in a wall when landing, because the hole is triggered when a specific point of the hero (the 8,11 point I think, but it does not matter so much) overlaps the hole. The whole 16x16 bounding box of the hero does not have to overlap the hole. For example, a 8x8 hole is enough to fall. So what I am saying is that it is normal that the hero can land on a wall if you are not careful. The behavior is different in all 4 directions because 8,11 is not the center (actually, no point can be the exact, symmetrical center).
So this makes holes tricky indeed... Most of the time, I avoid to use the "same coordinates" setting. What you can do if you don't want to use destinations, is to calculate some correct coordinates yourself from the teletransporter:on_activated() event.

Anyway, I should check all case you are describing to see if there are bug or if the behavior is expected.

entity:test_obstacles(dx, dy, [layer]) tests only one point: the point of coordinates entity:get_x() + dx, entity:get_y() + dy. So you can use a loop to test every point of a straight line.

I have never seen this bug. I will need to check your project since it seems to be a project-specific issue.

I just fixed the code sample and the link.

Hi,
The "Failed to convert software surface" is an internal bug of the engine. Could you report it on https://github.com/christopho/solarus/issues/new please?

Anyway, you should not create a new surface in the Anim() function because you are doing it every 100 ms. There is no need to repeatedly load the same 3 PNG images over and over again. So you can put them in a local variable outside the function (even if it does not explain the crash, I think):

Code Select Expand


local Calques_Pluie = {
  sol.surface.create("meteo/pluie_1.png"),
  sol.surface.create("meteo/pluie_2.png"),
  sol.surface.create("meteo/pluie_3.png")
}

and in map:on_draw(), replace Calque_Pluie by Calques_Pluie[Meteo_Pluie_Anim].

Another small detail: if you return true at the end of the Anim() function,

Code Select Expand


sol.timer.start(map, 100, function() Anim() return true end)

can be replace by simply

Code Select Expand


sol.timer.start(map, 100, Anim)


Maybe you should not check "Save the door state", but instead save it yourself to make it different from the door state. Use game:get_value()/game:set_value() to control the saved variable, and door:set_doors_open() to control the door.

Unfortunately no, unless you recompile Solarus with the appropriate flag. But making the console available on windows without recompiling is planned  for a future release.