Suggestion: Carriable entities or codable destructibles

Started by Satoh, July 14, 2016, 01:12:12 AM

Previous topic - Next topic
As I try to code an entity that can be picked up and placed, I find myself becoming somewhat overwhelmed by all the cases I'd have to test for to ensure that the hero behaves correctly as though the 'carrying' state is set.

Not only do I have to make sure the entity works, but also the hero itself.

I find that it would be much simpler if it was possible to turn an entity into a carried_object, having it fire events when lifted, when released/thrown/placed/whatever, and when destroyed... If those were accessible it would be somewhat trivial to create a variety of non-standard liftables, such as those that are placed gently when let go, those that are thrown but don't explode, and even some that are destroyed immediately upon being lifted (if that was needed).

Not being able to access the hero's state directly, or pass an entity to the hero as a carried_object reference, largely prevents me from doing that.

(specifically I'm currently just trying to make an object that remains on the map when set down, and isn't automatically tossed across the room... its more difficult than I imagined when I started.)

As for a Zelda related example of an object that fits this pattern, Link's Awakening (as Diarandor reminded me) has an iron ball, which I believe was used in either a boss battle or puzzle. Link would lift it and throw it back at the boss, or try to topple a pillar with it or something, but it wasn't destroyed when it was thrown. Instead, it rolled around a little bit (and could also be pushed, like a big marble)

Hard-coding all of that behavior wouldn't be necessary, as that could largely be handled by custom_entity scripting, if it was possible tell the hero that the entity should be carried.

I feel like there are a lot of built in features that would be a lot more flexible if they had some more lua control, but most of those features can be recreated to an extent using items or entities... lifting and carrying seems to be a much more complicated problem on the other hand.

But as the title states, this is less a formal request and more of a suggestion for how the engine might be more flexible.
Patience is difficult and rarely thanked, but always appreciated, and sorely missed when absent.

I agree with this.  I created an entity sheet for my Full Hyrule tileset, including the large liftable rocks in Link to the Past, in the various color choices in my tileset, but the problem is I have no idea how to create a custom entity, which Chris says is the only way to create liftables bigger than 16 x 16.

So, if custom entities are the only way to create (for example, a 32 x 32 liftable rock, or a breakable rock that requires dashing into by the pegasus boots), and if what you say is true about not having direct access to all of the hero's different behaviors, then newcomers to LUA, or those who, like myself, have difficulty grasping knowledge without a direct audio and visual hands-on demonstration, will find anything that is not already provided for us within the smart objects, next to, if not completely, impossible without asking for help all the time.
My tilesets page can be found here:
http://absolute-hyrule-tutorials.solarus-games.org/

This feature involves too much customization, so I think the best would be to make this with scripts and not in the engine. Since many people with few programming knowledge want this kind of features, the faster could be to provide scripts for this, maybe in the "sample quest" of Solarus 1.6 whenever it is released (or in other quest), if Christopho agrees.

My own scripts for this feature are not clean since there is code for many other things mixed with this and I would have to make a new version, which is a ton of work. I do not have much free time for this these days because I am currently working on free art (which is more prioritary), but I guess I could do this before 2018 if you are patient enough.

We may also need to write some kind of documentation explaining how to use of the scripts and which events and functions are defined in them.

It is a very risky feature since it involves modifying many important scripts and functions, and bugs could appear, but since we have both the "sample quest" in Solarus and the "initial quest" in the Editor, we could add this feature in one of them and keep the other clean.
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."