Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.


Messages - llamazing

Pages: [1] 2 3 ... 12
1
If all you want to do is show two dialogs back-to-back then all you have to do is use the "next" property of the dialog entry. For example:
Code: (lua) [Select]
dialog{
  id = "first_dialog",
  next = "second_dialog",
  text = [[
show this dialog first.
]]}

dialog{
  id = "second_dialog",
  text = [[
Then show this dialog.
]]}

Then all you have to do is start the first dialog and the second one automatically gets shown after. Note that there is also a "next2" property for when the player selects from between 2 choices, where next2 is the dialog to display next when the second choice is selected.

2
Development / Re: stop_dialog
« on: March 08, 2019, 02:34:26 am »
I think the problem here is the context of your timer. When a dialog is active, the game is paused, and therefore your timer (which has a map context) would be paused too until you close the dialog.

3
Bugs & Feature requests / Re: Cut Vines
« on: March 05, 2019, 01:26:51 am »
Syntax highlighting is actually broken on the forums right now...

4
Your scripts / Re: Dialog Box script with Name Displayed
« on: February 26, 2019, 04:54:28 am »
Cool! Have any pics?

What other mods did you make to your dialog box script?

5
Development / Re: combos...again
« on: February 11, 2019, 02:00:41 pm »
Yes, this is very possible.

It's difficult to provide help without knowing more details about what you are trying to accomplish, though.

6
Development / Re: video mode
« on: February 11, 2019, 01:59:01 pm »
Change line 58 from:
Code: (lua) [Select]
text = sol.video.get_shader(),to:
Code: (lua) [Select]
text = sol.video.get_shader() and sol.video.get_shader():get_id() or "Normal",
If you plan on translating your game to other languages, then you should probably use string.dat entries for the names of the video modes, though.

7
Your projects / Re: Pathfinding Experiment
« on: February 11, 2019, 01:01:13 am »
I added teletransporter nodes to the master branch. Seeing the path drawn on the map while a teletransporter is used in the route is so cool!

All teletransporter type nodes get linked with every other teletransporter node on the map regardless of the layer or distance apart. To add one to your own map, simply add the custom property "node_type" with a value of "teletransporter" to an existing node (any entity with the prefix "node_").

I also added "stairs" nodes that link multiple layers. For these add the custom property "layers" with the value being a list of layers that they bridge (separated by commas, spaces or both), e.g. "1, 2". Stairs do not use the "node_type" custom property (so it's possible for a node to be both a teletransporter and stairs). Stairs are not used in my example quest and have only limited testing.

The second post is updated to give info about using the script in your own quest as well as some details about how the algorithm works.

8
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?

9
Development / Re: video mode
« on: February 08, 2019, 08:12:07 pm »
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]
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]
      if self.cursor_position == 1 then
        -- Change the video mode.
        self.video_mode_text:set_text(switch_video_mode())
      else

10
Development / Re: video mode
« on: February 08, 2019, 01:27:31 am »
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]
sol.video.set_shader("hq2x")
You want to do:
Code: (lua) [Select]
  sol.video.set_shader(sol.shader.create("hq2x"))

11
Development / Re: video mode
« on: February 07, 2019, 01:54:08 pm »
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.

12
Bugs & Feature requests / Re: libphysfs.1.dylib issue on macOS Mojave
« on: January 28, 2019, 02:56:28 pm »
Are you running the latest version of Mojave? That may solve your first problem.

No idea on the second one.

13
Development / Re: Dungeon Design as Lesson Planning
« on: January 24, 2019, 01:13:14 am »
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.

14
Your projects / Re: Pathfinding Experiment
« on: January 20, 2019, 01:48:43 am »
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).

15
Your projects / Re: Pathfinding Experiment
« on: January 13, 2019, 02:55:08 pm »
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]
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.

Pages: [1] 2 3 ... 12