Messages

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.

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

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 Expand

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


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

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.

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.

After compiling the solarus engine you can run the command

Code Select Expand

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.

You want to do:

Code Select Expand

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.

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 Expand

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 Expand

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.

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) Select Expand


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.

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

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.

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.

[scripts/get_resource_ids.lua]

Nice! Using llamazing's code I created a polyfill for the feature.

scripts/get_resource_ids.lua:

Code ( lua) Select Expand

-- Polyfill for sol.main.get_resource_ids(resource_type)
--   See: http://www.solarus-games.org/doc/1.6/lua_api_main.html#lua_api_main_get_resource_ids
--
-- Originally created by llamazing
--   Source: http://forum.solarus-games.org/index.php/topic,1256.msg7443.html#msg7443

function sol.main.get_resource_ids(resource_type)

btw, you should change line 7 so that it doesn't overwrite the real get_resource_ids() function once v1.6 is released. Something like the following:

Code (lua) Select Expand

sol.main.get_resource_ids = sol.main.get_resource_ids or function(resource_type)

That way if sol.main.get_resource_ids is already defined (as a function) then the first half of the conditional evaluates to true and the second half of the conditional won't be evaluated (thus your custom function is ignored and the actual API function won't be overwritten).

Note that v1.6 also allows dynamically adding new resources at runtime, so parsing the project_db.dat will no longer be a viable way to get all resource ids: issue #630

Here is an interim solution to fix the behavior using a lua script:

Code (lua) Select Expand

local text_surface_keys_list = setmetatable({}, {__mode = "k"}) --list of text surfaces to update on language change
local text_surface_meta = sol.main.get_metatable("text_surface")

local old_set_text_key = text_surface_meta.set_text_key
function text_surface_meta:set_text_key(key, ...)
    text_surface_keys_list[self] = key --add text surface to list to automatically update on language change and save key
    return old_set_text_key(self, key, ...)
end

local old_set_text = text_surface_meta.set_text
function text_surface_meta:set_text(...)
    text_surface_keys_list[self] = nil --no longer automatically update this text surface when language changed
    return old_set_text(self, ...)
end

local old_set_lang = sol.language.set_language
function sol.language.set_language(...)
    old_set_lang(...) --change the language
   
    --update text of active text surfaces assigned a text key
    for text_surface, text_key in pairs(text_surface_keys_list) do
        text_surface:set_text_key(text_key)
    end
end

I'm guessing Solarus runs on an older version?

5.1