I've thought of this before as well. Although I haven't gotten around to testing it, my idea for that is to have a set of character specific items that grant those transformation attacks, each with a durability of 1. You could then set up a dialog tree that runs every time it's the player's turn and check if they have a transformation active and if they have all of the items. When the attack is selected, scripts run and update tracking variables and apply the needed transformations.
I'll update this with details later, when I'm on my computer with all of my WIPs and scripts. Now, the scripts themselves to determine if a character has the items they should are pretty straightforward. We have the "IfItemGoTo" and "IfItemRun" dialog actions that do this for us. But how do we determine whether or not it's the player's turn? Simple, really:
<Dialog branch="0" r="-1">
OnTurn/-TURN-/Information/
<Action>IfStatRun/Hero,Done,=,0,PlayersTurn</Action>
<Action>IfStatRun/Hero,Done,=,1,AIsTurn</Action>
<Action>CheckForMoreDialog/</Action>
<Reply>.../CheckForMoreDialog/</Reply>
</Dialog>
Let's break this down:
As you might know from the manual, when -TURN- is used in dialog, it gets replaced with the integer value of the current turn, with the first turn being a value of 0. Thus, by telling the dialog tree to run whenever -TURN- equals itself, we get dialog tree that runs every single time -TURN- updates.
But how do we know it's the player's turn? Take a look at the "IfStatRun" actions in the example above. This only works if you have a character that you know will appear in every map, and must be kept alive throughout the entire game. Whenever a character finishes (whether it be by attacking with an "EndTurn" or "CanMove" attack or by simply clicking "Done" or "End Turn") that character's "Done" stat gets bumped up to 1. When a new turn rolls around, it gets reset to 0. When the "Done" stat is at whatever point we need we can run whatever scripts we want.
Now regarding the items, keep in mind that it is possible to run scripts whenever an item is used or equipped by listing a script name between the <Item></Item> tags. My example for you here is
<Item name="Azure Orb" useableWith="Back" requirements="c:Hero" endsStatus="" addsStatus="" grantsAtk="" consumedAfter="0" fxLast="0" hpPlus="0" pspPlus="0" maxHPPlus="0" maxPspPlus="0" spdPlus="0" dodgePlus="0" strPlus="0" perPlus="0" psyPPlus="0" psyDPlus="0" prcResPlus="0" slshResPlus="0" crshResPlus="0" mnResPlus="0" htResPlus="0" cdResPlus="0" ltResPlus="0" shResPlus="0" poiResPlus="0" accPlus="0" ctrLimitPlus="0" commonality="1" addsTags="" image="Orb Azure" description="Grants flight when equipped">Use Azure Orb</Item>
Any time my character with the class "Hero" equips or dequips the Azure Orb item, the "Use Azure Orb" script is called. For convenience I keep it in PersistentDialog.xml. The script "Use Azure Orb" looks like this:
<Script>
Use Azure Orb
<Action>SetVal/AOrbActive,=,-VAL:AOrbActive-</Action>
<Action>IfValRun/AOrbActive,=,1,AOrbto2</Action>
<Action>IfValRun/AOrbActive,=,0,AOrbto1</Action>
<Action>IfValRun/AOrbActive,=,2,AOrbto0</Action>
</Script>
<Script>
AOrbto2
<Action>SetVal/AOrbActive,=,2</Action>
</Script>
<Script>
AOrbto1
<Action>SetVal/AOrbActive,=,1</Action>
<Action>SetStat/Hero,MoveType,=,0,flying</Action>
</Script>
<Script>
AOrbto0
<Action>SetVal/AOrbActive,=,0</Action>
<Action>SetStat/Hero,MoveType,=,0,land</Action>
</Script>
Now let's break this one down.
The first action sets "AOrbActive" equal to itself. This is a little trick I picked up to ensure that a variable is initialized before you ever use it. I learned the hard way that "IfVal" actions don't work if the variable in question hasn't been set to
something before. Fortunately if a variable get's called by its normal -VAL:- method, it always returns a number! This is important because when an uninitialized variable is called, it defaults to 0 This means we ensure that "AOrbActive" is set to
something before we ever use it.
The next three actions all run dependent on the results of the first. It's fairly self-explanatory, but I'll elaborate anyway. "AOrbActive" has a binary state, 1 or 0, on or off, true or false. But it also has a temporary state "2".
- The first time a player equips the orb, "AOrbActive" will be 0 by default. This means that "AOrbto1" gets called, setting the variable to 1 and changing the Hero's movetype to flying. This is all that happens this pass.
- When the player dequips the orb, the "Use Azure Orb" gets run again. This time "AOrbActive" is 1, or true. Now the script "AOrbto2" gets called. Why? Logic. If we simply set the variable directly to 0, it will trip the "AOrbto1" script again, and nothing will change. And if we put the action to set it to 1 after setting it to 0 we'll hit the same problem. But by setting it to 2 we bypass the script that would set it to 1, and THEN we set it to 0 and change the movetype of the Hero.
By using this method we can track when an item is equipped or not. But it doesn't have to be specific to one person. We can use -FNAME- in place of "Hero" and suddenly anyone who can equip the orb gains flight when they use it.
This is just one example of what we can do by using items! Instead of simply granting a character flight, we can do most, if not all, of the things you want to do with scripting! We can change the user's class, name, movetype, health, energy, damage, drain, sprite, etc all when an item is used or equipped. What's more is we can set all of these magical transformation items to use the same equip slot so that none of them try running at the same time. We could have a basic "Human Form" item that grants the character the stats and abilities they'd have as a human, and then every other "Form" item would replace those attacks and stats. I strongly advise against using "TeachAttack" and "TeachAttackTemp". They seem friendly, but there is
NO way to teach a character an attack for anything less than a single map. Items are the way to go on that front.
That's all I've got for you tonight. I've got a paper due Friday that I haven't started on yet, and I really need some sleep. As always, if you need any ideas or concepts refined or clarified let me know. I've been playing around with this stuff long enough that I'm slowly starting to get the hang of it, although I certainly bugged Craig for help more than I care to admit when I was starting out, and I'm more than happy to help out!
P.S.
I really only started looking at the power that item-triggered scripts wield a few days ago. When you think about it, the amount of power over Telepath Tactics given to modders and content creators is actually astounding. If you have the mind for it, the only thing you can't do is change the engine itself! I love it!
