Messages

If you are using the quest editor, then just start a new line where you want the line break to occur.

If you are editing the dialogs.dat file in a text editor, then you'd do it like this:

Code (lua) Select Expand


dialog{
  id = "my_dialog",
  text = [[
You're probably wondering what's
going to happen.
]]}

Advanced users could write their own custom dialog box script that does automatically wrap text by detecting the line length and inserting line breaks appropriately. The one included with Solarus, however, requires adding manual line breaks.

You'd need a base sprite sheet for each "race" appearance (like the LPC project has Orcs, Skeletons, and the rest are human-like)...

Bringing different races into the mix that share the same clothes sprites and weapon sprites opens up a whole new can of worms (unless all the races have the same basic shape). For example, if one race has a figure that is taller than the others, then now the sub sprites need to have a vertical offset added. Not impossible by any means, but certainly more hurdles to clear. In that case, however, you'd probably be better off with making a set of sub sprites unique to each race.

I think it's also possible by drawing a surface of a particular color and using a blend mode.

Eeesh, while it is technically possible using a surface with a blend mode, you'd be much better off doing it with a shader.

So with the add blend mode you could change purple (127, 0, 255) to magenta (255, 0, 255) by adding 128 to the red component. But you cannot change purple to red using the add blend mode because it would require subtracting blue. The multiply blend mode allows you to reduce color values, i.e. multiply the blue component by 0 to result in 0. But now you're doing 2 different blend mode operations, and you'd have to figure out the correct colors to add and multiply on a pixel by pixel basis. So really it would just be as much work as creating individual sprites, but really twice as much effort because you'd need to create an "add" and "multiply" overlay unique to each sprite.

On top of that, you can't draw a surface onto a sprite directly; you'd have to draw it on the screen. So you could use transparent pixels on the blend mode surfaces anywhere where the hero sprite is not present, but if another entity were obscuring the hero then you'd have to account for it, which would not be pretty. Not to mention there would be further complications if the hero sprite used any semi-transparent pixels.

A shader is definitely the way to go here, where you could fairly easily change all pixels of any one particular color to any other specific color, and the same transformation would be applicable to all sprites in the set. Plus it has the advantage of being able to apply a shader to an individual sprite rather than to the screen. The hardest part would probably be setting up the data tables to define all the possible palette swaps.

I'd say that #2 is the best approach for this. For this you'd use hero:create_sprite(). As for rendering correctly, it would probably be easiest to make all the pieces the same size (e.g. 16x16 if that's the size of your hero) with transparent pixels where not used (and the sprites would all have the same origin). That way you wouldn't have the alignment issues.

Solution #1 could work, but as you said, all the possible permutations quickly become complicated. I'd only recommend using this method if you were only swapping out the outfit in its entirety and not dealing with subcomponents.

This is especially complicated for the hero. Let's say you had 5 possible subcomponents (hat, face, shirt, pants, boots) with 3 variants for each. That makes 15 complete sprite sets you'd have to create, and you'd need to account for all the poses as well, including the use of various items. The hero has a lot of them, so you'd have a ton of sprites to make in the end.

Solution #3 is possible with shaders that were just introduced in Solarus v1.6. Seem like more effort than it's worth to me. I suppose if you were strictly dealing with palette swaps, then it might not be too bad.

Christopho's youtube tutorials are the best resource for beginners learning how to use Solarus and an overview of its core features.

My recommendation is to do the following:

• Start off by watching Christopho's youtube tutorials
• Make a your own quest that's simple and doesn't require much scripting
• Once you're comfortable with all that, start getting into writing your own lua scripts and learning lua
• When you get stuck, ask questions on discord or on the forums
• Looking at the scripts used in existing games is also a good resource once you become more comfortable with lua

Some good resources for learning lua:
Programming in Lua (first edition) - Free electronic book, good for beginners to lua
Lua Reference Manual (lua version used by Solarus is 5.1) - Reference for standard lua functions
Solarus Quest Documentation - Reference for Solarus specific functions
lua-users tutorials - Gives examples of using standard lua functions

Solarus is extremely powerful, and the biggest limitation is your own imagination.

Okay, so thinking about your problem some more, I have a feeling that your problem is that using game:set_value() and game:get_value() is what's truncating your numbers.

If that's the case then you can do something like the following:

Original code that gets truncated

Code (lua) Select Expand


local function set_multiplier(value)
  game:set_value("multiplier", value)
end

local function get_multiplier()
  return game:get_value("multiplier")
end


How to fix it:

Code (lua) Select Expand


local function set_multiplier(value)
  game:set_value("multiplier", tostring(value))
end

local function get_multiplier()
  return tonumber(game:get_value("multiplier"))
end


So this way you'd be storing the values as a string that includes the decimal portion and it won't get truncated.

It is totally possible to do what you want.

I'm not familiar with the game:get_end_mult() function. Is that a custom function you defined yourself? If so then you must be doing something that's truncating the value, which should be fixable since it is your function.

Please post your game:get_end_mult() function. I'm guessing the problem will be obvious.

I'm having a difficult time following what you are trying to do here. Why do you want to store the multiplier value in a 'game' function like the player's life or stamina?

You should be able to do something like the following that won't truncate the multiplied value:

Code (lua) Select Expand


local multiplier = 1.25
local multiplied_value = game:get_max_life()*multiplier


You're probably going to have to post your code if you want better help than this.

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 Expand


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.

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.

Syntax highlighting is actually broken on the forums right now...

Cool! Have any pics?

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

Yes, this is very possible.

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

Change line 58 from:

Code (lua) Select Expand

text = sol.video.get_shader(),
to:

Code (lua) Select Expand

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.

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.