[SCRIPT HELP] Looking to alter generic portable script

Started by ffomega, January 10, 2017, 12:33:43 AM

Previous topic - Next topic
So the generic portable script in my opinion has potential.  I'd like to have this script altered slightly, in three ways:

1. generic timed portable - like a bomb.  Self-explanatory, will be destroyed within a set amount of time regardless of whether held or thrown.  Portable will stay on the ground or in the Hero's hand until the timer ends and then destroy itself

2. generic activated portable - A remote bomb that would destroy upon pressing a button.  A super bomnb that will destroy upon pressing a button or striking it with your sword, which triggers a countdown timer.  Once the timer reaches 0, the object is destroyed.

3. generic custom destructable - Like the generic timed portable, except that the object is destroyed upon throwing and landing on the ground, like any other default destructable.  this entity would be great for larger objects such as the 32 x 32 boulders

The thing is this object is originally designed to be thrown and reused once it lands, meaning it will not get destroyed.

How and where would the script need to be changed or added onto for the portabe(s) to work right
My tilesets page can be found here:
http://absolute-hyrule-tutorials.solarus-games.org/

My script is very experimental, so be careful when using it.

It should be very easy to do that. There are "custom events" (non built-in events) in the scripts for these purposes; these are functions that begin with "on_". Some of them are not defined, but some of them will be called if they are defined.

I don't recommend to modify the base script. It is better to mimic the "inheritance of objects" in Lua, somehow, and overriding/defining those "custom events" for particular subtypes of custom portable entities. I don't have time to help you with the details, though.

As an example, note that the phoenix chicken that appeared in one of my videos uses these "custom" scripted events for the customization of the falling speed, max distance reached, the behavior after falling to the ground, etc. Some "custom" events are just overriden in this case.

(Note that Christopho will probably add optional portable features to all (or some types of) entities, so my script will be unnecessary someday. But this will not happen until Solarus v1.6 is released, which will happen in one year or maybe more time.)
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."

Note that when I made my scripts to simulate "object inheritance" I used the "load_file" functions instead of "require", which is bad for fast performance. I am not sure if that "object inheritance" is possible if we use "require" instead, but probably we would need a constructor function to do this, maybe something like "...:create_custom_portable_entity(properties)". If I update the script someday (which is not planned) I might do it this way and make it compatible with Christopho's "multi_event" script; that would make the script much cleaner and easier to use.
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."

Yes it is possible to do inheritance with require().

Quote from: Christopho on January 10, 2017, 06:05:45 PM
Yes it is possible to do inheritance with require().

Good to know. Which is the best/cleanest way to do it? Is it using constructor functions?
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."


Thanks a lot! That link is very helpful.

When I coded the script I did not realize that this was possible (actually I didn't even understand metatables at that moment). My script does a lot of things in a bad and complicated way, so I should modify it in this way, someday maybe.
"If you make people think they're thinking, they'll love you. But if you really make them think, they'll hate you."

However, in new code I no longer use inheritance in Solarus quests. This is not really needed and makes it harder to read the code, so I prefer to keep it simple.