Messages

The only thing blocking me is that Solarus doesn't seem to have a way to list all the possible items in the quest, so I can't loop through them.

Here's a bit of a hack, but you can get the names of all items in your quest by reading the contents of the project_db.dat file:

Code (lua) Select Expand

local function get_all_items()
    local all_items = {}

    local env = {}
    function env.item(properties)
        local id = properties.id
        assert(type(id)=="string", "item id must be a string")

        table.insert(all_items, id)
    end

    setmetatable(env, {__index = function() return function() end end})

    local chunk = sol.main.load_file("project_db.dat")
    setfenv(chunk, env)
    chunk()

    return all_items
end

Then you can use game:get_item(item_name) to convert the item names into item objects.

That's nifty! Excellent work.

You should consider defining the items eligible to appear in the picker as part of the item scripts with some sort of custom property rather than inside the picker script itself. Perhaps add an is_giftable() method to the item metatable?

Done!

Issue #1285 opened

Is the PNG font a recognized standard?

I don't believe so

Is it just a row of characters in a specific order?

Yes, 16 rows by 128 columns, supporting the first 2048 unicode characters.

Are only monospace fonts supported?

yes, all characters must have the same width and height.

Does it have to be 8px?

no, the total image width is a multiple of 128 and total image height is a multiple of 16. The size of each character is thus fixed based on the size of the overall png.

Are there any examples?

yes, from the alttp resource pack: https://gitlab.com/solarus-games/solarus-alttp-pack/blob/master/data/fonts/alttp.png

So after a bit of experimentation, I think the implementation is as I feared and that text_surfaces need to manually have the text key set again after a language change. This means that a list of all active text_surfaces has to be retained along with the set_text_key string it is supposed to have in order to be able to manually do the update after the language has changed.

How have people dealt with this problem in existing quests? Is it by only allowing the player to change the language while the game is not running? (and thus the only active text_surfaces are the ones displayed on the change language menu?).

Nice one!

Looks like you have a typo on line 31: "moement"

The quest documentation indicates that text_surface:set_text_key(key) is equivalent to text_surface:set_text(sol.language.get_string(key)), but is that really true?
http://www.solarus-games.org/doc/latest/lua_api_text_surface.html

If they are indeed equivalent then that would mean that the text wouldn't get updated when the language is changed and text_surface:set_text_key() would need to be called again just to update it. That doesn't seem right, could anyone confirm?

If your sound has a short loop then it should simply be a matter of having a timer looping continuously until stopped that plays the sound over and over.

If the sound has a long loop this could be problematic because once you stop the timer the sound would still continue playing until the end of the loop.

http://www.solarus-games.org/development/compilation-instructions/

I recently compiled and installed on Ubuntu. The instructions above do not list the package names for Qt5. They are:

• qtbase5-dev
• qttools5-dev
• qttools5-dev-tools

The compilation instructions included in the gitlab project do include these dependencies:
https://gitlab.com/solarus-games/solarus/blob/dev/compilation.txt

The other part that required a bit of head scratching was figuring out the name of the package for the GLM dependency for compiling the quest editor. It is libglm-dev. Compilation instructions for the quest editor can be found here:
https://gitlab.com/solarus-games/solarus-quest-editor/blob/dev/readme.md

The other thing to consider is that even if assigning sol.main.game to local game did work, you'd still have problems for the case where the player exits the game to the title screen and starts a different game, in which case the local game would have a reference to the wrong instance of the game.

The require command will just run the script, which might return a table, if you tell it to.

There's one subtlety that I'm not sure if you picked up on, and that's that the require command will only run the script once. So if the script is also required somewhere else, then instead of running the script a second time, the return values saved from the first time the require command was used will simply be passed along to wherever else the script gets required.

To see an example of this, imagine a script (print_script.lua) to be required that simply contains the line print("some text").

Now if you add require("/scripts/print_script.lua") to both main.lua and game_manager.lua then you'll only see one print statement when the game is loaded.

If instead you change it to sol.main.do_file("scripts/print_script.lua"), then this time the script will actually be run twice and you'll see two print statements. Put the sol.main.do_file statement in a map script and you'll actually see the line get printed every time the map loads, which is not the case if using require.

If the script were to return a table, then using require would result in the same table reference being returned at both places. If using do_file, then two separate table instances (that probably look identical) would be returned. Generally, using require is what you are going to want to use the majority of the time, but there may be instances where sol.main.do_file is better for what you want to accomplish.

local shop in your map is a table. backsmith() is a function in that table.

When using require, you need to have the script being required return a table. Anywhere that that script is required, it will get a reference to the table, the advantage being that the script only has to be loaded once.
EDIT: the script that gets required does not have to return a table if instead it simply defines global variables/functions

You'll want to do something like the following for your blacksmith script:

Code (lua) Select Expand

local blacksmith = {}

function blacksmith:start_dialog()
  --do stuff
end

function blacksmith:function2()
  --some other function
end

return blacksmith

The problem with this, though, is that the blacksmith script here won't be able to use any references to game since it doesn't know what that is. If the same game instance will be used everywhere you use the script then you can get away with something like the following: (be warned that every time you require the script the game will get set, and only the last one will stick, but in the case of a map it will be set every time the map loads)

Code (lua) Select Expand

local blacksmith = {}

local game

function blacksmith:set_game(current_game)
  game = current_game
end

function blacksmith:start_dialog()
  game:start_dialog("_yarrowmouth.npcs.blacksmith", function(answer)
    --blah blah
  end)
end

function blacksmith:function2()
  --some other function
end

return blacksmith

Then your map script becomes:

Code (lua) Select Expand


local blacksmith_funcs = require("scripts/shops/blacksmith")
blacksmith_funcs:set_game(game)

function blacksmith:on_interaction()
  blacksmith_funcs:start_dialog()
end

But if you're going to have multiple game instances then this solution is no good and you'll want to do something like the following instead:

Code (lua) Select Expand

local blacksmith = {}

function blacksmith:start_dialog(game)
  game:start_dialog("_yarrowmouth.npcs.blacksmith", function(answer)
    --blah blah
  end)
end

function blacksmith:function2(game)
  --some other function
end

return blacksmith

And map script:

Code (lua) Select Expand


local blacksmith_funcs = require("scripts/shops/blacksmith")

function blacksmith:on_interaction()
  blacksmith_funcs:start_dialog(game)
end

I use BBEdit which is just a fancy text editor for the mac. Has syntax highlighting and a drop-down menu that lets you jump to another function in the same file.

I think you can get a plugin for eclipse to use it for lua.

Yes, it is very possible.

Mouse coordinates are given relative to the quest window, which you'll need to convert to map coordinates. Only part of the current map will be visible on the screen, as determined by the camera.

Functions you'll need are:
sol.input.get_mouse_position()
camera:get_position_on_screen()
camera:get_position()
hero:get_position()

Updating the hero's facing direction every 1ms seems like a bad idea. That would essentially make it so that the hero is always facing the cursor. A better implementation would be to only update the direction when the mouse moves. That way the player could choose to use the arrow keys to move the hero, not ever touch the mouse, and all would be well.

Neato.