Messages

That is not the correct way to write a loop at all. It's just constantly checking map:has_entities("rope") over and over again in an endless loop that won't allow for anything else to happen in the mean time. It's doing way more processing than it needs to and wil hinder the rest of the game from being able to run properly.

Compare it to Yoshi's method that counts the number of entities present once any time one of them dies. Until one of them dies, the number of them isn't going to change, so no need to be checking it over and over again in between. See how this method is vastly better?

Nothing is broken by 1.6. sol.video.set_mode is deprecated but still supported.

Might as well fix it now since it will go away some day.

sol.video.switch_mode() does not have an equivalent function in v1.6, so you'll have to write your own.

Add the following code the the beginning of your options_menu:

Code (lua) Select Expand


local video_mode_index = 1 --index for the current video mode, default is no shader
local video_modes = { --list of shaders to use for the video mode
  false, --don't use a shader
  sol.shader.create("scale2x"),
  sol.shader.create("hq2x"),
  sol.shader.create("hq4x"),
}

--cycles between video modes
local function switch_video_mode()
  --advance to next video mode
  video_mode_index = video_mode_index + 1
  if video_mode_index > #video_modes then video_mode_index = 1 end

  --set the shader for the current video mode
  local shader = video_modes[video_mode_index] or nil
  sol.video.set_shader(shader)

  return shader and shader:get_id() or "normal" --return string naming the current video mode
end

And the code you posted becomes:

Code (lua) Select Expand


      if self.cursor_position == 1 then
        -- Change the video mode.
        self.video_mode_text:set_text(switch_video_mode())
      else

I see what you are doing wrong.

sol.video.set_shader() takes a shader object as a parameter, not a string.

So instead of:

Code (lua) Select Expand

sol.video.set_shader("hq2x")

You want to do:

Code (lua) Select Expand

  sol.video.set_shader(sol.shader.create("hq2x"))

You need to have the "hq2x" shader in data/shaders. Looks like the solarus-free-resource-pack has the shader, so copy it into your quest project.

Are you running the latest version of Mojave? That may solve your first problem.

No idea on the second one.

I like how in Zelda games they often force you to use the new item you found in that very room to get out. If you don't realize there's a new mechanic, it's at least obvious that you have to do something to get out. And since you are trapped in the room until you figure it out (and thus limiting the possible actions possible), it prevents the player from wandering around the rest of the dungeon aimlessly trying to figure out what to do next and getting frustrated.

One aspect you've barely touched on is using visual cues to guide the player to where you want them to go, both consciously and subconsciously. This could be as simple as adding lighting where you want to direct their eyes and adding shadows where you don't want them to go. Or perhaps tapering the room into a point. Or maybe just the use of colors to guide their eyes.

I discovered that running this quest on a new machine produces an error because it expects a "maps" directory to exist in the quest write directory, which won't be there on a fresh install.

If anyone was getting this error, it should be fixed now (the script now explicitly creates the directory it needs).

The project gitlab page wiki describes how the algorithm works here.

A top-level overview of the node_map.lua script can be found here. This is the one script you'll want to copy to your own quest to implement the pathfinding.

To implement in your own quest, import the scripts/node_map.lua script. Then add a network of nodes in the map you want to try it on. They can be any entity with the prefix "node_", but you'll want to use something stationary. I find custom entities with the default size and origin work well.

Nodes get linked to other nearby nodes automatically if they are on the same layer. They must be within 13 tiles (208 pixels) to be linked, although you can change this value (MAX_RANGE) in node_map.lua if you want. I created the node_range sprite to aid in determining the max distance away. Center it on an existing node to see how far away another node can be placed and still be linked. You can delete it once all your nodes are placed.

Then use the script like this:

Code (lua) Select Expand


local node_map = require"scripts/node_map"
local mapping = node_map:new_mapping(dst_x, dst_y, dst_layer) --these are the coordinates of the final destination
local next_x, next_y, next_layer, distance, action = mapping:next_node(x, y, layer) --these are the starting coordinates, returns intermediate destination for this segment of the route

So you'd call mapping:next_node() with the current position of the entity you want to move. First move the entity to the layer returned (which may be different than the present layer if currently at a "stairs" node). Then setup a target movement to the returned coordinates, unless the value of action returned is "teletransporter", in which case you'd want to instantly move the entity to the returned coordinates. The return value for action is normally nil. The distance return gives the total route distance remaining (in pixels) until reaching the final destination.

Once the entity finishes the movement, call mapping:next_node() again, this time giving the entity's (new) current position and repeat until the entity arrives at the final destination.

For it to work, the entity has to be within range of a node that's also on its current layer, and the destination has to be within range of another node in that same network (also on the same layer as that node). It's possible to have multiple groups of nodes on the same map that are not connected to each other if none of their nodes are in range of each other. A route between separate node networks will not be found unless there happens to be a teletransporter node present in both networks.

I've been working on an experiment in pathfinding that has given good results. It uses a network of "navigation beacon" entities distributed on a map and calculates an optimal path to get from point A to B assuming both are in range of beacons connected in the same network.

I still have some ideas to develop things further, but it's far enough along to make a playable demo, so I thought I'd share. Screenshots won't do this one justice, so check it out if it sounds like something that would interest you.

Solarus v1.6 is required (and it indeed makes use of some cool new features ).

https://gitlab.com/llamazing/pathfinder

main.lua is trying to call game_manager:start_game(), which must not exist in your game_manager.lua script.

Is there a way to set ground1 and ground2 to a different sprite when entering a different area?

I don't know if it is possible to change the sprite itself, but it should be possible to change the animation of the sprite at least to give it a different appearance. You'll probably have to use sprite:on_animation_changed(animation) to manually change it every time it updates, though.

I'd also be curious if it's possible to set the direction of the ground based on the hero's direction. eg, when the hero faces left ground2 looks different.

I'd imagine that the following would work:

Code (lua) Select Expand


function hero:get_sprite"tunic":on_direction_changed(animation, direction)
  local ground_sprite = hero:get_sprite"ground"
  if ground_sprite then
    ground_sprite:set_direction(direction)
  end
end

You don't give your timer a context and you always return true, so it seems to me that the problem is that the timers continue to run even after you've removed the entity.

I would try either setting the timer context to your custom entity or maybe return false once the entity gets removed and see if either of those helps.

I fixed a bug where I had forgotten to clear the displayed name when the dialog is closed, so the old name would appear when starting a new dialog if no name was specified.

The updated script can be found in the original post.

Do you define the world property for your maps? If so it makes sense at a minimum to split into directories based on the world, and then maybe more subdirectories on top of that as needed.

For dialogs, I first split them into directories based on which menu is used for the dialog (and the dialog_box.lua dialogs being the most prevalent don't need a dedicated directory).

In my Cythera project I had additional dialog menus for system level messages (like "do you want to save?"), and I had a sleep menu dialog that had exactly one dialog. For the regular dialogs (with NPCs), I separated them by the NPC, and in my project NPCs could travel between maps and were still considered the same entity (so it didn't make sense to separate the dialogs by map). My dialogs were also way more complicated than most Solarus quests, so the details beyond that are probably not relevant.

For scripts, I usually create a subdirectory to group related scripts together (like if there are multiple subclasses each defined by their own file). I also usually try to separate actual scripts from the data, making one file that ends in .lua and another that ends in .dat, but only when it makes sense to do so. There are multiple reasons for doing it this way:

• Data files have a separate license from the script itself
• Easier maintenance: can replace just the script file with the latest version and data remains unchanged
• Better conceptually because each quest using the script will likely customize the data but not necessarily the script. So it segregates things between the things you'll probably want to modify (the data) from the things that only advanced users will want to touch (the script itself).

I wanted to have the name of the person speaking displayed in at the top of the dialog box, so I modified the dialog_box.lua script by Christopho (I used the one from Children of Solarus since it looked to be the most up-to-date version).




The new syntax for the dialog text uses a line beginning with '##' to specify the displayed name. Without any lines beginning with '##', no name will be displayed and the behavior of the text box is the same as it was before.

The name will also be applied to subsequent panes within the same dialog until it is changed by specifying a new name. Beginning a line '###' turns the displayed name off again.

Beginning a line with '##>' shifts the name over to the top-right side of the dialog box. This is useful if you want the player's name to appear right-justified while the names of all other NPCs are left-justified.

Finally, beginning the displayed name text with '&' signifies that the given name is actually a savegame variable key and its current value will be used for the name text that gets displayed (e.g. '##>&player_name').

Lines beginning with '##' must be the first line of a set of lines for a given pane.

Sample dialog text:

Code (lua) Select Expand


dialog{ text = [[
##Hector
First Pane: Beginning the line with two
'#' characters causes the name Hector to
appear at the top of the dialog.
Second Pane: The name Hector continues
to be shown in subsequent panes as well.

Third Pane: Note the empty line above is
used to complete the previous pane for
it to have 3 lines of text (even empty).
###
Fourth Pane: Putting 3 '#' characters at
the start of a pane causes it to display
no name at the top of the dialog.
##>Player
Fifth Pane: The > immediately after the
'#' characters causes the name to be
shifted over to the right.
Sixth Pane: This can be useful to show
the player's name. In this case, the
text shown is literally 'Player'.
##>&player_name
Seventh Pane: Here the '&' character is
used to instead display the value of a
savegame_variable named 'player_name'.
]]}


The modified script (GNU GPL v3, originally by Christopho) is attached along with a modified version of dialog_box.png (CC BY-SA 4.0, originally by Metallizer & Olivier Cléro)