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.


Topics - linky

Pages: [1]
1
Bugs & Feature requests / New editor 1.42 not working on old Xp PC
« on: May 24, 2015, 07:20:26 pm »
Hello,

I'm using solarus on old pcs under windows XP and the new editor version 1.42 crashes systematicaly at load with the error :

"The application failed to initialize properly (0xc000001d)"

Untill now all the previous editor's version worked fine withount problem, even if the configuration of those old pcs are completely outdated (but the last windows update are done on it). I'm using those machines for education purpose in a school and have only those pc available for this task (there is no possibility to buy new one for the moment because of limited budget reason). So unfortunately i can't use the new editor with this pcs but only at home with a more decent machine.

I imagine the new editor is requiring more ressources and graphical functions than before, but in case of, do you think there is a way to get around this problem or can you precise what is the minimal configuration to use the new version 1.42 of Solarus (maybe with minimal directX version) ?

Thank's for your help

2
Bugs & Feature requests / Litle bug in Editor 1.42 with door icon
« on: May 24, 2015, 06:47:03 pm »
Hello,

I'm trying the new editor 1.42 that is really nice and a big improvement to the previous one.

I believe there is a little bug with door item at least on my configuration. When you use contextmenu to change its direction (ie left to right), the door's icon is not updated immediatly. To make it change to the new direction you have chosen you have to go in its property pannel by double clicking on this door icon, where you can see that the new direction has really been changed but not visualy applied, and then make ok. This makes the door icon takes the good direction.

3
Bugs & Feature requests / Crash with sol.main.load_file
« on: August 05, 2014, 04:16:57 pm »
Hi,

I need some help because i am fighting with an ununderstandable problem that systematically crash solarus.

I was trying to build the elements of the hud (rupee, heart...) to understand how to do it and without any problem so far. But doing my test, i realized that when the game restart because the hero died, the hud didn't come up again.

So i look in the script of solarus DX and understood that i have to put something in a  "game:on_started" function that is called each time the game restart after the death of the hero, that will reinitialize the hud.

So i try to do so by copying the way it is done in DX and there the problem begins.

So far to include module files in the main.lua file (for example for the hud.lua) i was just using "require(filename)" that works well. But i have seen that to declare the "game:on_started" function, another way of calling a module is used with "load_file" which is an adapted version of lua "loadfile" command for solarus. So i search a lua help to try to understand this command and find this :

Code: [Select]
-- just load the module without runing it
sol.main.load_file(filename)
-- load the module and run
sol.main.load_file(filename)(some arguments)

if i have well understood the avantage of "require" is that it loads the modules only once (so preserves memory), but it doesn't seems to be able to send arguments to module's function. To be sure I try the following :

Code: [Select]
require(filename)(some arguments)

but it doesn't pass the arguments. So I then try to use the "load_file" instead as shown in the DX's script and do exactly as it (at least i think so). And then solarus begins to crash all the time.

As i have put some code inside "game:on_started" i try to undertand what part was causing the crash by removing things little by little. But it was complicated because the crash occured or not depending if i add or remove some instructions somewhere in this module or in another one called by "game:on_started", even sometimes on very simple command like "print". So it wasn't easy to localize which part was the problem because it doesn't crash with any commmand but only with some of them.

For example i have seen that i have timer called in one of my module, and i discover that if i comment it, then there's no crash (but i need this timer).

Finally i make a copy of the project and take everything out (all modules and even clean the main). Now i have a mini project with just 2 files: main.lua and a module called play.lua in the data folder. And it continue to crah my solarus (version 1.2 or 1.21).

To be sure there was not a little part of my code hidden somewhere (or in the map definition for example) that gives instability to the program, i have took back the "simple_quest" example proposed in solarus 1.2 zip file you can download on solarus site and that you try at the begining to understand the basics of solarus.

It is just composed of one map inside a house where you almost can't do anything. It was the first example i begun with, and i knew it works well. So i just took this data folder and just change the "main.lua" by mine and add my problematic module "play.lua" and then... it crash solarus. I really didn't changed anything else than this 2 files. Here they are :

Code: [Select]
-- main.lua
function sol.main:on_started()

    game = sol.game.load("save1.dat")
    game:set_max_life(12)

    sol.main.load_file("play")(game)

    game:start()

end

Code: [Select]
-- play.lua

local game = ...

function game:on_started()

    -- this simple timer that does nothing make solarus crash
    sol.timer.start(100, function()  end)
     
end

For me, this very simple code crash solarus with nothing log in the error.txt file, but if i comment the call to "sol.main.load_file" the quest start on without problem.

(In my real code the game create process and game:start() are not in the main.lua but in a game_manager.lua, i just put it there to simplify at the maximum).

So probably i'm not using the command sol.main.load_file("play")(game) like it is neccessary because in DX it works without problem. But i don't see what i do wrong by comparing with the use of it in DX.

I must precise that the timer function i use in method "game:on_started" is just an example. It is one of the function that i have localized to cause the crash in some of my modules called by "game:on_started".

But in my code, even a simple "print" function" make a crash (it depends where it is put). This is not the case in this simple version because i have removed all the other modules that "game:on_started" is supposed to call when the game restart.

So i don't think the problem comes from the timer itself as the problem occurs with other functions. If i put this same timer command in the "main.lua" it runs without problem, it is only inside the "play.lua" file that it makes crash. In my real code, the timer is set in another module called by "game:on_started" so that the crash wasn't localized directly in the play module although the problem seems to come from there.

In "main.lua" i also try another variant used in DX to call load_file, but it crash the same :

Code: [Select]
-- main.lua
function sol.main:on_started()

    game = sol.game.load("save1.dat")
    game:set_max_life(12)

    local mytest = sol.main.load_file("play")
    mytest(game)

    game:start()

end

I wish to use "require" instead because it never make crash solarus, but apparently it is not possible because it can't parse the argument "game" to the module "game:on_started", although it really needs it.

So could you please help me as i don't know what to do more.

If you don't see a big big stupid error of beginer from my code that will be evident to your expert eyes, could you then try to do like me by taking your "simple_quest" given with the solarus 1.2 engine and put those two files (see attachments) in the data folder to see what happens and if it's normal.

Thanks a lot

4
Development / Some Solarus lua code understanding questions
« on: August 04, 2014, 03:24:40 pm »
Hi,

I'm trying to understand the lua code of solarus by reading the differents scripts of zelda solarus dx and i am stucked by some special trick, especially some specific to solarus. So could you please explain me some of them (apologize for the length of this post and if some of my questions are very naïve as i'm new to solarus and lua).

1) The hud code :

For each element of the hud (the rupee, the heart...) it seems you define a lua pseudo class of this element (by using the metatable) in this code that is always at the begining of the lua file (example taken from the rupee.lua in hud folder):

Code: [Select]
local rupees = {}

function rupees:new(game)

  local object = {}
  setmetatable(object, self)
  self.__index = self
  object:initialize(game)
  return object

end

and then in the hud.lua code you call this constructor to build an instance of this class for all the object of the hud, for example:

Code: [Select]
local rupees_builder = require("hud/rupees")
local menu = ruppy_builder:new(self)

I have understood what this code does, but what i don't understand is why it is necessary to create such a pseudo class as i don't think you use them elsewhere (i'm not sure of that). To my little knowledge, when you create a class, you have in mind to be able to create many instance of that class to use those objects in differents situation. But here, if i understand well, the rupee class is used only once (for the hud).

So is there a special reason why you use a more complex structure in the constitution of the hud. Because exactly the same code without the method "rupees:new" (just using the rupee table as it is), will work the same. Or the class structure is more adapted for the hud, for any reason. Otherwise maybe is it just because you plan to use this class for something else in a future version of solarus ?

2) The use of menu:

The use of the menus are not very clear to me. In the doc you explain that the utility of a menu is to allow to add some callback functions to any table that already exists (at least this is what i have understood). But is the menu itself an object created automaticaly by the engine when you call some of its function (start, stop...) and that includes the table that called the menu or does it just add some functions to the table that has called him ?

For example, still with the hud example, after having create the hud's element, you allow their showing by runing this function where you use the menu function (taken from hud.lua) :

Code: [Select]
function game:set_hud_enabled(hud_enabled)
    ...
    loop on menu...
    ...
         sol.menu.start(self, menu)
    ...
    end
end

where menu is one hud element (like the rupee) created before and placed in the hud table.

At the begining i didn't understood why the call to one of the draw function wasn't sufficient to show an item (like the rupee icon), beacause you have also to use a menu.start function for it.

For the example of the rupee, to show the icon of the rupee (near the number of money of the hero at bottom left) you use something like :

Code: [Select]
local rupee_icon_img = sol.surface.create("hud/rupee_icon.png")
rupee_icon_img:draw_region(x0, y0, width, length, dst_surface, x, y)

the first line create an image object of the icon called a "surface" in solarus environment and the second one is called to draw it on the screen. But when it is called alone nothing happens apparently. To make it works you have to put the "draw_region" in a callback function of a menu:

Code: [Select]
sol.menu.start(game,rupee_menu)

-- and somewhere create a callback function:

function rupee_menu:on_draw(dst_surface)

   rupee_icon_img:draw_region(x0, y0, width, length, dst_surface, x, y)
   
end   
   
then the image of the rupee is well displayed.

So please correct me if i'm wrong, because what i am understanding from this procedure is maybe completely idiot.

My understanding is :

In fact, unlike what i was first thinking, the "draw_region" function  display only one time the image it have to show. But as the screen is refreshed at a certain frequency by solarus engine, if you display only once, you don't really see it, as the screen is then immediatlely again redrawn and if the draw function is not called again the rupee disappears. To be sure you see it all the time, you have to called this draw function every cycle of redrawn of the screen.

So this is where the role of the menu is coming. The menu add a callback function to the rupee_menu table and each time the engine start a redraw of the screen, if it sees that a table has a callback function "on_draw" (added to the table by the menu or include in a table "menu" ?) then it will run this callback function to draw what is asked in this function.

Does it works like this or i'm completely misleading on the use of menus ?

3) Entity code:

Last thing, completely different subject, i wish to ask you if it is possible to make a lua code for the entity that appears on the map (teleporter, crystal, switch...) to customize their behavior.

For the enemy, item or custom_entity, when you create a new item of them in the quest editor, it automaticaly create a lua file that goes in their respective folder. But for the entity, it seems that when you create a new one, you can only give them a name and choose some specific properties, but you can't give their special behavior in a lua files as the other entities. This is maybe why they don't have their own folder in the quest editor like the others elements, but are placed inside the folder of the map (on the treeview at the left).

In the french tutorial videos I have seen (many thanks for them, they are really more than helpful to understand solarus), when you need to add a new behavior to an entities, you do it directly in the lua file of the map, although with other kind of sprite (enemy etc...) they have their own lua script. I works well also, but i was thinking that with large project it can become difficult to read the lua map file if we put a lot of scripts for all the differents entities added to the map. It could be more clear if they could have also their own lua files.

So even if apparently it is not proposed by the quest editor, is there a way to add some behavior to those kind of entities in an independant lua file, or is it a choice not to proposed this possibility ?

Thanks you very much for your help

5
Development / Notepad++ autocompletion for Solarus
« on: August 01, 2014, 05:15:39 pm »
Hi,

I didn't find around a notepad++ language file for Solarus (maybe it already exists somewhere ?) to have autocompletion. So i made one, as i think it can help at least the beginers to know easily the existing functions or methods, or just verify their parameters and of course to script more quickly long function's name. It is made from the solarus 1.2 doc website, so it should be uptodate so far (http://www.solarus-games.org/doc/latest/index.html).

Some people don't like much this kind of help, but it may be useful to some others, so here it is. It's the first one i make, so please excuse me if it is not made properly as it should or if it is incomplete. Also there is certainly some errors in it as it is difficult to test them all, so if you find errors by using it please don't hesitate to tell.

For those who don't know, you can activate autocompletion in notepad++ in the preferences (see picture 3).

As far i have understood, the file language must have the same name that the extension for which this language file should be applied. So the file is named "lua.xml" and has to be put in the plugins\APIs folder of notepad++. Normaly it is automatically recognized by notepad++ when you open a lua files as those of Solarus scripts.

Remark: It means that if you already have a more general lua.xml files applying to general lua language it wil replace it. If you then use lua files back for another environement that Solarus, you will have to change it again as lua is widely used for a lot of different applications.


Limitation:

1) First I have removed the begining "sol." extension on every functions and methods otherwise it gives too more results each time you begin with sol., so i thought it was not much effective.

2) In the case of showing the parameters of the functions (see picture 2), there is apparently a limitation in Scintilla/notepad++ autocompletion to recognize function's name separated with dot like "sol.main.load_settings". So only "load_settings" will be recognized.

To avoid this problem i have add those two versions (with and without the part with dot: "main.sol."). So the autocompletion mechanism propose the complete function "sol.main.load_settings" that allow to choose it without writing it all, and then after writing the "(" it show also the different parameters accesible for this function.

But this doesn't work when the function exists under different objects with different parameters:

For example timer.start should show :
sol.timer.start([context], delay, callback)

but will show:
sol.timer.start(context, menu, [on_top])

because only the end "start" function is recognized and taken from "sol.menu.start(context, menu, [on_top])" that comes first in the file, as again the begining "sol.main.timer." is not recognized.

I don't know if there is a solution to this problem, but it affects only a few functions, so it shouldn't be a big deal.

Thanks.


6
Bugs & Feature requests / Little doc error
« on: July 29, 2014, 05:56:31 pm »
Hello,

I'm not sure, but i think there is a very little mistake in this page of the documentation (a "coquille" as you say in french) :

http://www.solarus-games.org/doc/latest/lua_api_text_surface.html

when describing the first function :

sol.text_surface.create([properties]):

the name of the optional properties are written in french instead of the real name of the properties which are spelled in english :

horizontal_alignement    instead of    horizontal_alignment
vertical_alignement        instead of    vertical_alignment

I have copied them directly on this page without thinking, to use them in my code, but then got an error by the engine and realized the mistake. But it is ok in the Table of contents to the right. Not very important of course, but could mislead some newcomers like me.

Thanks

7
Development / Collision detection
« on: July 28, 2014, 01:32:12 am »
Hello to all,

I am a beginer in Solarus scripting and I wish to ask you if it is possible to do the following.

I'm trying to use custom_entity to define my own entity behavior, but i don't know how to avoid the collision between the hero and the custom entity. The sprite of my entity (a stone) is big (64px width) and has irregular shape (definitely not square) and I need to avoid the hero can traverse it as it is supposed to be a plain object.

If I have well understood the collision detection of solarus engine works only on square shape. For example in the first tutorial you show how to put a black protection square under trees or houses on the low layer because it has a "ground" type as wall, so the solarus engine tells the hero not to go on the square area.

But with a sprite that has an irregular shape this is not very satisfactory as if the protection square is too small the hero can go a little inside the edge of the sprite and if the square is larger then at some edge the hero is stuck away from the entity as if it is stopped by an invisible wall.

I then thought that I could put many little protection square to try to cover all the surface of the entity approximately along the edge instead of using just one big, but as my sprite is animated, the protection is ok only on one frame and then completely wrong for the next frame.

Its why i then try to use the lua method "add_collision_test" that works well to detect a collision between the sprite of the hero and my custom entity, and this time at the pixel precision as you say on the doc. But then what ?

In the callback function, after having detected that the hero is coming inside a sprite it should not, what can i do to say to the hero not to go further more inside the sprite of the entity ? Is it possible to take back the control of the movement of the hero instead of let the solarus engine doing it ?

To resume my point, is it possible to script a more precise collision detection system to stop the hero when the shape of the sprite is really not square and animated ?

Thank you very much for your help.

Pages: [1]