Recent Posts

Pages: 1 2 [3] 4 5 ... 10
Development / Re: About color text dialogs
« Last post by Diarandor on April 17, 2017, 07:05:49 pm »
What do you think would be better of these options for the dialog box script? (I mean, for a new script that I will make.)
Non-nested properties (as the ones you use)? Or nested ones (like the ones of the end of my last comment)?
Development / Re: About color text dialogs
« Last post by MetalZelda on April 17, 2017, 06:53:25 pm »
That could be cool, but it could also be tricky, if we use a lot of texts effects (using different colors in the same line for example), but I agree that text properties should be exploited.

I should also give these idea to exploit the text properties, it will make things better and easier, since I am, in parallel to y project, porting the Project Zelda Engine from RPG Maker to Solarus

  -> Dialog Box style (aka graphics), allow to define at the start of the text the dialog box graphics, automatically reset to "default" at the end of the dialog (
  -> Dialog Box positionning, sometimes, the dialogbox can clip automatically depending on the hero position or other stuffs, this parameter will set the position of this dialog, no matter the hero position or such
  -> Bank system (Idea from Zefk,,806.0.html), where the system will be triggered by a text property and integrated entirely in the Dialog box script.
General discussion / Design of graphs of dungeons
« Last post by Diarandor on April 17, 2017, 05:58:19 pm »
This video explains a bit how to make a dungeon graph, which is useful to design a dungeon. It is not exactly a tutorial, but it is interesting.
Development / Re: About color text dialogs
« Last post by Diarandor on April 17, 2017, 04:44:21 pm »
I agree with @llamazing and @MetalZelda that putting names to new text surfaces in the dialog_box is really unnecessary. The idea I had in mind when I coded that was to allow to go back to the previous text surface if needed, to reduce the number of surfaces, but since the dialog box is small we should not worry about this kind of things. Better to reduce the syntax as the ones you use.

A good idea, and probably a better syntax, would be allowing to call functions in dialogs. So I propose a slight modification of the same syntax, which is even shorter:
Code: [Select]
The functions associated to each "function_identifier" would be defined in the dialog box as usual: "dialog_box:function_name()".

To avoid using long function names in the dialog box (the syntax would be too long) and at the same time keep the long name in the definition of the functions of the form "dialog_box:function_name()" (which is clearer), we could use a short identifier after the dollar symbol "$" instead of the name of the function. For this purpose, another function "dialog_box:start_function(short_id, parameters)" would be needed, just to start the convenient function assotiated to that "short id" used in the syntax.

Furthermore, to keep the dialog as clean as possible, the parameters of each function should better be given as properties of the dialog and not in the middle of the text. For instance, if the color is changed 3 times in a dialog, we would define an array of color properties, and each time $c is called, the next color of the array would be applied.

Remark: $c could be used to call a function "dialog_box:set_color(color)". This function should be overloaded to be compatible too with this other useful syntax: "dialog_box:set_color(r, g, b)", whose parameters would be sent as strings and then "dialog_box:set_color(r, g, b)" would first convert the three strings into integers and then make the color change.

An example to change color and a shaking effect:
  id = "_cannot_lift_too_heavy",
  skip = "all",
  color = {"red", "white", {200, 0, 100}},
  movement = {{"horizontal", "fast"}, nil, {"vertical", "slow"}, nil},
  text = [[
Oh là là, c'est l'$camour$c !

$cWe will $mshake$m and $mbounce$m !

I propose some short function ids (i.e., for the dialog syntax):

$0, $1, $2, $3, etc: as usual, for the "text speed"
$c: change color; allows color_id_string  or (r, g, b) as parameters
$s: change the size of the text; integer parameter
$f: change the font type; font_id_string parameter
$m: movements and shaking effects; parameters: movement_type_string, and other optional_parameters
$d: "dynamic" (i.e., continuous) color changes (rainbow color-shift, etc). parameters: effect_id_string, and others
$b: change the "beeping" sounds, which may be different for different NPCs, etc; parameter: sound_id_string
$i: draw image/icon (the width may be given as parameter if necessary). parameters: image_id_string, etc

If you have more ideas for other different effects that we may implement, or a suggestion for a different syntax, we can discuss it.

A different syntax, much clearer for translators and easier to read, but harder to code (because there could be a "nested" use), would be to use "{", "}" symbols (these could be optional) to indicate where the effects will be applied. For instance:
blablabla this $c{word} and $c{this} are in red.
Another example:
  id = "_cannot_lift_too_heavy",
  skip = "all",
  color = {"red", {200, 0, 100}},
  movement = {{"horizontal", "fast"}, {"vertical", "slow"}},
  text = [[
Oh là là, c'est l'$c{amour} !

We will $c{$m{shake} and $m{bounce}} !
Development / Re: About color text dialogs
« Last post by MetalZelda on April 17, 2017, 02:08:28 pm »
Also, another cool feature you could add to your dialogbox script is savegame value parsing.
You will find example bellow and add it if you want. But a such basic feature is very useful for a lot of possibilities.

Example: displaying values (items, time, command, etc ...)

This could be useful for some texts, displaying the current value of multiple variable for example (since $v is only 1 value)
Here, using this method, I'm displaying all item commands for using an item, keyboard and Joypad.
Good news is, you can even use color

It's plug & play for the most part
Code: [Select]
Vous obtenez l'$[red]Arc du Héros$[white]!$0
Dans le menu $[yellow]pause$[white], écran $[blue]Inventaire$[white],
assignez l'arc grâce aux touches $[red]$(item_1)$[white]
ou $[red]$(item_2)$[white].

And also, it's cheap stuff, you don't need to recreate a surface
Code: Lua
  1.  elseif current_char == "(" then
  2.             -- Predefined text (an input for example).
  3.             local next_char = line:sub(self.char_index, self.char_index)
  4.             -- The syntax is "$(text)".
  5.             local right_position = line:find (")", self.char_index, true)
  6.             local text = line:sub(self.char_index, right_position - 1)
  7.             self.char_index = right_position + 1
  9.                 -- Is the text a valid savegame value ?
  10.                 if game:get_value(text) ~= nil then
  11.                   text = game:get_value(text)
  12.                 end
  14.         -- Using $(item_1) or such (warning, do not use a savagame value), as it is in the table bellow, will display a pre-defined text_properties
  15.         -- with as value keyboard / joypad binding             
  16.                 local actions = {"item_1", "item_2", "action", "attack", "pause", "up", "down", "left", "right"}
  17.             for i = 1, #actions do
  18.                   if text == actions[i] then
  19.                     text = game:get_command_keyboard_binding(text) .. " / " .. game:get_command_joypad_binding(text)
  20.                   end
  21.                 end
  22.                 self:set_text(text)

You just need
Code: Lua
  1. function dialog_box:set_text(text)
  2.     local current_line = self.current_line_surface[self.line_index]
  3.     current_line:set_text(current_line:get_text() .. text)
  4.   end

Another example of a clever usage

$v is already used by "Skulltula d'Or"(the object caption, so when translating, the item name will be already translated), so the item dialog is.
Code: [Select]
$[red]- $v -$[white]
On dit que ces $[yellow]$v$[white] ont
la possibilité de détruire des malédictions.
Vous en avez tué $[red]$(amount_of_skulltulas)$[white] sur 100 !

The value of killed skulltulas is parsed from the code above

The next cool stuff to add is icons in texts
Your projects / Allied AI Script Project Alpha
« Last post by Zefk on April 17, 2017, 01:55:54 am »
Allied AI Project Alpha

I recently started working on a Allied AI script while working on the book project. I am panning only 2 allies like in Secret of Mana (Seiken Densetsu 2).

Finished: (All lag is due to bad gifs, the Solarus engine runs fine)
  • Basic Follower Script - The Ally custom entity follows the hero and when the ally gets stuck (hit an obstacle), it searches for the hero.

I seriously cannot believe at how easy this is to program. Thank you Christopho for the amazing functions.

Not finished:
  • Melee
  • Projectiles
  • Custom Entity Enemy
  • Enemy
Game art & music / Re: A Free Music / SFX Resource - Over 1000 Tracks
« Last post by Eric Matyas on April 17, 2017, 01:47:39 am »
Hi everyone,

Now that looping versions of most of my tracks are done, I'm back to creating brand new music and soundscapes. Got a new synth, too, so lots of new sounds are on their way. Here are some for starters:

"Sky Runner" (standard and looping)
"Cyber Teen"

"It's Always Sunny in the 80's"
"It's Raining Pixels"
"The Ice Cream Man"

"After the Invasion"

"From the Sand to the Stars"

I hope some of them are useful!  :-)
Development / Re: Disable spin Attack?
« Last post by zutokaza on April 16, 2017, 10:18:40 am »
I got it somewhat working now, but it does not disable anything. It just unfreezes the player after a spin attack.

Code: Lua
  1. function hero:on_state_changed(state)
  3.   if state == "sword spin attack" then
  4.     hero:unfreeze()
  5.   end
  6. end
Development / Re: Disable spin Attack?
« Last post by zutokaza on April 16, 2017, 07:22:12 am »
Could I get an example?

I tried this, but is fails...
Code: Lua
  1. function hero:on_state_changed("sword spin attack")
  2.   hero:unfreeze()
  3. end
Development / Re: About color text dialogs
« Last post by MetalZelda on April 16, 2017, 01:54:20 am »
There is still the spacing problem if you use a special characters such as é, è, ç, à and Asian type characters, even with a mono-spaced font, hmmm, this is one tough issue.
There is no problem when texts are in english though, but it is problematic, because, I am translating Book of Mudora in French and some texts overlap depending on if there is a special character before the colored text. This will also happen if you translate in Spanish / Russian / Asian languages.

This is the new surface's space that is problematic, the script already includes special characters it seems, but I can't figure out what is the real issue here ...
Pages: 1 2 [3] 4 5 ... 10