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 ... 13
Development / Re: Where the pause menu is launched in XD2 ?
« on: May 31, 2019, 01:14:03 am »
You're going to have to be more specific about what steps you attempted to do...

This is how I interpret what you said; is it correct?
* You copied "scripts/menus/pause.lua" from XD2 and added it to your own quest
* You started the pause menu from your own quest, but nothing happens apart from pausing the game

If that's the case then it's because all pause.lua does is launch the various submenus (each screen you can scroll between). Try copying the following additional files to your quest and see if it works better:
* "scripts/menus/pause_inventory.lua"
* "scripts/menus/pause_map.lua"
* "scripts/menus/pause_options.lua"
* "scripts/menus/pause_quest_status.lua"

Or if that isn't the problem, then I'm guessing an error was printed to the console when you opened the pause menu. Please provide the content of that error message.

General discussion / Re: A new member joins the fray!
« on: May 27, 2019, 07:54:05 pm »
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
lua-users tutorials - Gives examples of using standard lua functions

Development / Re: Glitchy Text In Menu
« on: April 26, 2019, 11:57:09 pm »
I've noticed that Solarus v1.6 seems to be glitchy with text surfaces if text_surface:set_text() or text_surface:set_color() are called within an on_draw() function (which didn't happen in v1.5).

Try moving the self.menu_text:set_text_key() lines outside of the demo_screen:on_draw_main_demo() function and see if that helps.

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().

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:

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.

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.

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...

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"))

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.

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]
  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.

Pages: [1] 2 3 ... 13