Menu

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.

Show posts Menu

Messages - linky

#16
Bugs & Feature requests / Re: Little doc error
August 01, 2014, 04:37:50 PM
Hi,

I found a little other one:

http://www.solarus-games.org/doc/latest/lua_api_map.html#lua_api_map_methods

for wall entity:

1) map:create_wall(properties)
the first link (in yellow on the picture) goes to:

http://www.solarus-games.org/doc/latest/lua_api_switch.html
instead of
http://www.solarus-games.org/doc/latest/lua_api_wall.html

as indicated by the second link at the end (return value (wall)) that seems more logic.

2) the last property is again "stops_blocks" (already used above) instead of the new property "stops_projectiles".

Thanks
#17
Development / Re: Collision detection
July 29, 2014, 10:20:14 PM
Hi again,

Your solution works well, i have just added a little more to make it works also with the enemy walking around that could altough go through the stone. I have to find something to replace freeze that don't seem to exist for enemy because otherwise the enemies got definitely stucked inside the stone and use enemy:set_enabled(false). Normaly it makes disappear the enemy but it is so short that you don't see the difference.

The only very little annoyance is that the hero is shaking when come in touch with the stone because the code make him go back again and again until you stop making him forward, but it is very acceptable. You can't see it on the picture, but it works also when the stone is rotating on itself, pushing the hero backward if a larger edge of the stone comes to him. Here is the little modification that works like a charm, if it can be useful for someone :



-- This script stop the collision between two sprites with pixel precision
-- if the collision detection with binding box is not sufficient for your needs.
-- recquire to set: stone:set_traversable_by(true) otherwise binding box are used.

stone:add_collision_test("sprite",
    function(sprite, entity)
        stone:collision_do(sprite, entity)
    end)

function stone:collision_do (sprite, entity)
   
    local angle = sprite:get_angle(entity) 
    local movement = sol.movement.create("straight")
 
    movement:set_speed(300) -- higher value or sometimes hero is stucked in the sprite
    movement:set_max_distance(1) -- take the entity backward from 1px
    movement:set_angle(angle)    -- is sufficient and more natural
       
    if entity:get_type() == "hero" then
       entity:freeze()
    else
       entity:set_enabled(false) 
    end
   
    movement:start(entity, function()
        if entity:get_type() == "hero" then
           entity:unfreeze()
        else
           entity:set_enabled(true)
end
    end)
end


I don't know why the two images i have uploaded was removed so fast, so i have uploaded one new in an attachment to be sure it last more. You can see that even with a lot of simple green soldiers, none goes through the stone and pass around it.

Thanks Christopho.
#18
Bugs & Feature requests / Little doc error
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
#19
Development / Re: Collision detection
July 29, 2014, 05:34:09 PM
Hi Christopho,

Thank you very much for taking the time to answer me so precisely, especially during those summer holydays.

I have put 2 images to show in what case this kind of problem can occured :

One with a standard tile of zelda which represent the entrance to a cavern :



and the other one my ugly stone :



In its animation it is just rotating on itself around its center, so depending of the frame the hero can be closer or not from the edge of the stone. If an edge of the stone is touching the hero when it is rotating then the hero should be pushed away for example.

For the first image of the cavern, what is the most efficient way to avoid the hero being blocked by an invisble wall away from the wall of the cavern like this ?

The binding box are not of much help here. If i put it too small the hero will go inside the middle wall when coming by the middle, and with a big binding box, the hero will stay blocked away from the small wall (where there is the little horn) if he is coming from left or right as on the picture. I think the only solution is to use differents size "square blockers" under the sprite like with the trees ? Or maybe on the tileset it is more easy to create new tiles by copying this big one and cut it in 3 parts with adapted binding boxes ?


Altough, I have tried to continue to use add_collision_test combined with set_traversable_by as you proposed, but don't find what to do with.

In particular if i put "set_traversable_by() = true" to let the hero goes closer to the entity (ie without taking care of bounding box which is sometimes too far from the entity) then i detect the collision with pixel precision when the hero touch it. Then i put back "set_traversable_by = false" to avoid link continue to go further inside the entity.

But then the hero is completely stucked in the entity and can't get of it because i think the solarus engine blocked the movement of link as it is not supposed to be inside an entity (but in this situation, he is :) ).

So with standard api you propose I don't know if there is something else that can be done, especially for a very beginer like me. But don't worry about that, it's not of real use for the moment. I just wished to explore the possibilities offered with the new custom_entity to be able to create my own behavior instead of using those proposed by the engine to have furthermore flexibility in the game creation (but it has already an enormous one).

Also, i'm not sure, but i didn't find in the doc if there is an api "custom_entity:is_transversable" although it exists for the enemy:  enemy:is_traversable(). It could exists for both as a custom entity can be another type of enemy.

Thanks again.
#20
Development / Collision detection
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.