Messages

1

Development / Re: Path Movement behaving weirdly

« on: April 17, 2019, 03:35:45 am »

I am not able to reproduce the problem you describe. Once the enemy starts its looking animation it doesn't seem to do anything else after. If I manually stop the movement during the path movement, then the enemy halts and the walking animation continues to be active.

Looking at the code, it seems that the only place the movement is started is in the on_restarted event(). My best guess would be that on_restarted() is getting called when you don't expect it to be. You could try adding a print statement in that event and see if it is getting triggered unexpectedly.

The other problem that is immediately obvious to me is that the look_around() function in the spotted==false condition can set chasing=false, set the path movement, then restart the enemy. But restarting the enemy will set a new path if chasing==false, so I don't think there's any point to setting the path in look_around().

2

Development / Re: Unit Testing and other questions

« on: April 13, 2019, 06:06:24 pm »

I don't know anything about frameworks like busted, but you can set up an external editor from the Solarus Quest Editor preferences on the "Text Editor" tab. Atom should be no problem, not sure about VSCode, but I'm guessing it could be made to work as well.

EDIT ZeroBrane is what the Solarus Team uses for lua debugging, so you could try that:
https://gitlab.com/solarus-games/solarus/tree/dev/work/ZBStudioPlugin

3

Bugs & Feature requests / Re: Multiple Entities Sponaneously Broken

« on: April 11, 2019, 11:40:11 pm »

So I added an animation for it now

You can't just go adding any old animation, it has to be the correct one. You should import the .dat file from the project where you got the small_key png file, then the dat file will be setup correctly and automatically get added to your quest (sprites need both the .png and .dat files to work correctly, so make sure you get both when importing).

If you simply copy the .dat file over to your project without using the import feature then it doesn't get added to your quest automatically, and in that case you will have to find the sprite in the quest tree (left sidebar of the quest editor), which will have a '?' icon. Right-click it then choose the option to add it to your quest.

4

Bugs & Feature requests / Re: Multiple Entities Sponaneously Broken

« on: April 11, 2019, 01:26:44 am »

I don't see the .dat file in that screenshot... that may be your problem.

5

Your projects / Re: AZ2R - Another Zelda 2 Remake

« on: April 10, 2019, 01:30:18 am »

What? The sleeping Zelda in Zelda II is a different Zelda from the one in the first game? This is news to me...

6

Bugs & Feature requests / Re: Multiple Entities Sponaneously Broken

« on: April 09, 2019, 02:41:13 am »

Then post the code from your on_created() event. You must have an error in there somewhere.

EDIT Also, try posting the following code in the console of the quest editor while your game is running:

Code: (lua) [Select]

print(sol.main.resource_exists("sprite", "items/dungeons/small_key"))

7

Bugs & Feature requests / Re: Multiple Entities Sponaneously Broken

« on: April 09, 2019, 01:15:43 am »

That first error indicates that line 6 of the items/dungeons/small_key.lua script encountered an error because it could not find the small key sprite located at sprites/items/dungeons/small_key.

I would start by adding that sprite to your quest. Errors that follow don't necessarily mean anything because when a script encounters an error it halts execution of the remainder of that script, so other scripts often have errors because of that script was not loaded fully.

8

Bugs & Feature requests / Re: Text wrap issue in dialog? (Editor 1.6.0)

« on: April 04, 2019, 03:58:43 am »

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]

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.

9

Your scripts / Re: Ways to think about sprites for character customization

« on: April 04, 2019, 01:58:27 am »

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.

10

Your scripts / Re: Ways to think about sprites for character customization

« on: April 03, 2019, 06:24:55 am »

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.

11

Your scripts / Re: Ways to think about sprites for character customization

« on: April 03, 2019, 02:12:18 am »

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.

12

Development / Re: What's a good starting point? (Tutorials + Learning Materials)

« on: April 03, 2019, 01:18:18 am »

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.

13

General discussion / Re: Do 'game' functions like game:get_max_life() truncate decimals?

« on: March 31, 2019, 04:18:55 am »

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]

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]

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.

14

General discussion / Re: Do 'game' functions like game:get_max_life() truncate decimals?

« on: March 31, 2019, 03:51:34 am »

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.

15

General discussion / Re: Do 'game' functions like game:get_max_life() truncate decimals?

« on: March 30, 2019, 11:59:22 pm »

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]

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.