[ian-reeds-games] Callbacks
- From: Craig Brett <craigbrett17@xxxxxxx>
- To: ian-reeds-games@xxxxxxxxxxxxx
- Date: Sun, 21 Apr 2013 15:11:57 -0400 (EDT)
Hi all,
I'm thinking of introducing a new optional concept into some of my
scripts, something called callbacks. Essentially, this means that you
can call a script after another script automagically.
My original use case is that I want to use change_unit_type on my
Command and Conquer IFVs whenever an infantry enters them, to change it
into a new type of IFV depending on the infantry that just got in. To
do that... well... I had no idea how else to do it to be honest. But I
can imagine it would be useful, my worry is that it will be a more
complex trick in the script user's book.
I've got it working here, but I'm not sure if the syntax will be
agreeable to everyone.
So currently, I have an extra OnEnter argument to the
add_transport_capabilities, which takes the name of the script I want
to call (note that it isn't in double quotationmarks). I also have an
OnEnterArgs argument, which takes the arguments for the callback script
(or script to run afterwards) inside of curly braces. At the minute,
{0} inside the OnEnterArgs refers to the user of the skill's type, {1}
refers to the target of the skill's type.
This might be a little easier to understand with an example, so here's
my current working example.
after_create=add_transport_capabilities@ { Capacity: 1, OnEnter:
change_unit_type, OnEnterArgs: { NewType: "{0} ifv" } }
So this would allow a unit to board the IFV and once they're aboard, it
will turn into a {0} ifv. So if it's a peacekeeper, it will become a
peacekeeper ifv, a javalin soldier will turn it into a javalin soldier
ifv, etc.
This is just an idea for tackling this problem I'm knocking about. I
can understand it's slightly more complicated to write, which is why
I'm interested in hearing opinions. I also am open to suggestions on
the {0} and {1} inside of OnEnterArgs, whether it should be restricted
to the Type and if not, how would you like it to look? It could
possibly look like {0}.Type, but that does add extra complications for
people writing it.
I want to make this as open as possible, so that it's useful to more
people in more scenarios. But the more generic I make this, the more
complicated it might look.
Does anybody have any thoughts? Constructive criticism? Better
alternatives?
Thanks,
Craig
Other related posts:
