Messages

1

Your scripts / Re: Dialog Box script with Name Displayed

« on: December 08, 2018, 06:27:50 pm »

I fixed a bug where I had forgotten to clear the displayed name when the dialog is closed, so the old name would appear when starting a new dialog if no name was specified.

The updated script can be found in the original post.

2

Development / Re: How do you organize your quest data files?

« on: December 07, 2018, 02:52:43 am »

Do you define the world property for your maps? If so it makes sense at a minimum to split into directories based on the world, and then maybe more subdirectories on top of that as needed.

For dialogs, I first split them into directories based on which menu is used for the dialog (and the dialog_box.lua dialogs being the most prevalent don't need a dedicated directory).

In my Cythera project I had additional dialog menus for system level messages (like "do you want to save?"), and I had a sleep menu dialog that had exactly one dialog. For the regular dialogs (with NPCs), I separated them by the NPC, and in my project NPCs could travel between maps and were still considered the same entity (so it didn't make sense to separate the dialogs by map). My dialogs were also way more complicated than most Solarus quests, so the details beyond that are probably not relevant.

For scripts, I usually create a subdirectory to group related scripts together (like if there are multiple subclasses each defined by their own file). I also usually try to separate actual scripts from the data, making one file that ends in .lua and another that ends in .dat, but only when it makes sense to do so. There are multiple reasons for doing it this way:

• Data files have a separate license from the script itself
• Easier maintenance: can replace just the script file with the latest version and data remains unchanged
• Better conceptually because each quest using the script will likely customize the data but not necessarily the script. So it segregates things between the things you'll probably want to modify (the data) from the things that only advanced users will want to touch (the script itself).

3

Your scripts / Dialog Box script with Name Displayed

« on: November 23, 2018, 04:42:08 pm »

I wanted to have the name of the person speaking displayed in at the top of the dialog box, so I modified the dialog_box.lua script by Christopho (I used the one from Children of Solarus since it looked to be the most up-to-date version).




The new syntax for the dialog text uses a line beginning with '##' to specify the displayed name. Without any lines beginning with '##', no name will be displayed and the behavior of the text box is the same as it was before.

The name will also be applied to subsequent panes within the same dialog until it is changed by specifying a new name. Beginning a line '###' turns the displayed name off again.

Beginning a line with '##>' shifts the name over to the top-right side of the dialog box. This is useful if you want the player's name to appear right-justified while the names of all other NPCs are left-justified.

Finally, beginning the displayed name text with '&' signifies that the given name is actually a savegame variable key and its current value will be used for the name text that gets displayed (e.g. '##>&player_name').

Lines beginning with '##' must be the first line of a set of lines for a given pane.

Sample dialog text:

Code: Lua

1. dialog{ text = [[
2. ##Hector
3. First Pane: Beginning the line with two
4. '#' characters causes the name Hector to
5. appear at the top of the dialog.
6. Second Pane: The name Hector continues
7. to be shown in subsequent panes as well.
8.  
9. Third Pane: Note the empty line above is
10. used to complete the previous pane for
11. it to have 3 lines of text (even empty).
12. ###
13. Fourth Pane: Putting 3 '#' characters at
14. the start of a pane causes it to display
15. no name at the top of the dialog.
16. ##>Player
17. Fifth Pane: The > immediately after the
18. '#' characters causes the name to be
19. shifted over to the right.
20. Sixth Pane: This can be useful to show
21. the player's name. In this case, the
22. text shown is literally 'Player'.
23. ##>&player_name
24. Seventh Pane: Here the '&' character is
25. used to instead display the value of a
26. savegame_variable named 'player_name'.
27. ]]}
28.  

The modified script (GNU GPL v3, originally by Christopho) is attached along with a modified version of dialog_box.png (CC BY-SA 4.0, originally by Metallizer & Olivier Cléro)

4

Development / Re: Solarus Ubuntu Installation

« on: November 17, 2018, 10:39:01 pm »

From the File menu select "Load quest..." or press Ctrl-L

Navigate to and select the directory one level above the data directory of the project you want to load.

5

Development / Re: Solarus Ubuntu Installation

« on: November 17, 2018, 01:40:46 am »

For solarus go to the /build/gui/ directory and run ./solarus
For the quest editor go the the /build/ directory and run ./solarus-quest-editor

6

Your projects / Re: Some Maps I've been working on...

« on: November 16, 2018, 12:09:48 pm »

The link does still work.

@eliwolfe92 You can embed the image in the post with the image tag. Make sure you are using a url that ends in .png for each image. Right click one of the images and choose "Copy image addess" (Chrome) or "Copy Image Location" (Firefox). Syntax is:

Code: [Select]

[img]https://i.imgur.com/3DONMP8.png[/img]

Note that the original link has 6 images, and I am only displaying one of them.

7

Development / Re: Solarus Ubuntu Installation

« on: November 16, 2018, 03:56:34 am »

I ran the make command for the engine then compiled and ran the make command for the quest editor.

After running the 'make' command for the engine did you then run the 'make install' command for the engine (but before you run the 'make' command for the quest editor)? No need to run 'make install' for the quest editor, just run 'make' for it.

Also when I am ready to load the program how to I create a shortcut for it as using the terminal to load it every time is going to get tedious.

You can setup a .desktop file for that. I use the program Arronax to create the .desktop file, but you can create it using just a text editor.

8

Your scripts / Re: "End Credits" script (rolling credits)

« on: November 15, 2018, 11:24:03 pm »

Cool!

You should have it start playing a music file and then synchronize the scroll speed so that it ends as the music ends.

hmm... I don't think there is any way to get the duration of a music track from the Solarus API, though.

9

Development / Re: Solarus Ubuntu Installation

« on: November 15, 2018, 02:08:05 pm »

After compiling the solarus engine you can run the command

Code: [Select]

make install
You'll want to do this step after the make step (and while in the solarus-1.5.3/build/ directory).

That will install the solarus components in the typical locations where the quest editor compiler will look for them. Otherwise you have to manually specify where to find each component while building the quest editor, which is rather tedious.

10

Development / Re: Solarus Ubuntu Installation

« on: November 15, 2018, 05:49:40 am »

You want to do:

Code: [Select]

cd path_to_build
cmake ..
There's a file named compilation.txt inside the solarus-1.5.3 directory that details the commands to run, try checking that out if you haven't.

11

Development / Re: Solarus Ubuntu Installation

« on: November 14, 2018, 01:57:17 am »

The long list of letters, numbers and dashes isn't a terminal command and I don't know what to do with it.

Those are dependencies which need to be installed first. The terminal command to install them is:

Code: [Select]

sudo apt install libsdl2-dev libsdl2-image-dev libsdl2-ttf-dev libluajit-5.1-dev libphysfs-dev libopenal-dev libmodplug-dev libvorbis-dev qtbase5-dev qttools5-dev qttools5-dev-tools libglm-dev

"sudo cmake" isn't a command

cmake is not pre-installed on ubuntu. You can install it using

Code: [Select]

sudo apt install cmake

As for the other one I tried running the first command and it reported that I did not have permission.

I'm not following which step you are talking about here, but adding sudo before the command giving you problems may fix the permissions problem.

12

Development / API optional parameters: error using nil

« on: November 11, 2018, 03:08:49 am »

I tried making a new surface and got a strange error:

bad argument #1 to create (number, string or no value expected, got nil)

The only way I've found to get around it is the following, but it's a bit awkward:

Code: Lua

1. local surface = width and sol.surface.create(width, height) or sol.surface.create()

It's a bit strange that there'd be a distinction between a value of 'nil' and 'no value' when it comes to specifying optional values. Is there a better way to get around it while working purely in lua? i.e. is there a way to assign 'no value' to a lua variable?

For context, the value of width is being specified by a data file, and I'm wanting to use default values if the width is omitted in the data file.

13

General discussion / Re: Need Help With Enemy Scripting

« on: October 30, 2018, 02:13:25 am »

on_update() is called every 10ms which is also the minimum delay that can be set for a timer.

http://forum.solarus-games.org/index.php/topic,805.msg4379.html#msg4379

14

Development / Re: Solarus could use a UI framework

« on: October 27, 2018, 05:34:29 am »

But like, how much would you recommend against not using your old libraries?

The biggest thing I don't like about the old library is the way I was trying to cache images to reduce redundant processing, but in the end it gets too complicated and more than likely will just cause memory leaks. So I'm doing away with that mostly. The way properties are used to create new controls is significantly different too (but it is more streamlined and logical now), which means updating data files from the old library to the new one will be a significant undertaking.

However, the old library is perfectly fine for studying and better understanding how menus work.

Myself and @Vathox are trying to get an actual menu together to keep track of sidequests in Ocean's Heart (all my test players are like, I cannot keep track of all this, you need a sidequest log immediately.), and having a really tough time trying to figure it out.

If you want to send me a sketch up of what you envision the menu looking like, I'd be willing to whip something together that should at least be enough for you to take it the rest of the way.

15

Development / Re: Solarus could use a UI framework

« on: October 27, 2018, 01:15:47 am »

For one of my demo projects I did exactly what you suggest where I made a script library solely for creating ui menus, and it is broken up into scripts for each type of component (button, text field, scrollbar, etc.). That library can be found here and is fully functional, and if you run the demo quest you can even see it in action (the demo quest makes heavy use of various types of menus). I don't recommend using that ui library as it is now, though, as there are a bunch of things that I don't like about the way I implemented it.

I've been working feverishly the last few months on improving just that library and making it more universally usable. There have been some significant changes in its implementation for the better. It's going to be another few months before I'm anywhere near ready to release anything, though.

My library only deals with placing components that don't resize, which greatly simplifies things, and resizing components is not something that a solarus quest should really need anyway. The library included in the demo project only deals with mouse/keyboard interaction, but I do intend to add controller support too.

I think having some sort of ui support built-in to solarus is a good idea, even if it only covers some of the lower-level stuff.