Jump to content

Recommended Posts

Effect Manager



This script replaces the default Effects handlers with a plugin-based

effect system. It is meant to allow developers to easily develop new

effects without having to concern with the minor details.


You can define new effects by simply registering it, defining a method,

and then note-tagging your database objects.




Get it at Hime Works!

Plugins: http://www.rpgmakervxace.net/tags/forums/effect/


Effect Request Thread - request an effect that you want to see here. Plugin developers can also look here to see what kinds of things they can write.




All effects that are written for this script are added to objects using note tags.

The basic format of the note tag is

<eff: idstring arg1 arg2 ... >

-`idstring` is the name of effect that you want to add,

-`arg1, arg2, ...` are a list of arguments that the effect requires


Instructions should be provided with the effect plugin describing what each argument represents.


By default, if you simply write the idstring of the effect, then it is assumed

to activate under any effect trigger. If you wish to specify the triggers that

it will activate under, you should write it as

<eff: idstring-TRIGGER arg1 arg2 ... >
Where `TRIGGER` is an effect trigger. You can look at the list of triggers

available in the reference list below, although a plugin may choose not to

implement every trigger available. Check with the plugin author to see what

kinds of triggers are available.







This script uses specific terminology that I have defined.


* Effect plugin

Any script that is registered to the Effect Manager are called "plugins".


* Database object

Or simply "objects". These are any objects that you can add effects to.

The default engine allows items and skills to have effects. This script

extends this to actors, class, weapons, armors, enemies, and states.


* Id String

The name of an effect. Used throughout your script and notetags.

Every plugin must have a unique idstring.


* Effect Type

Determined by the object the effect is assigned to.

For example, effects that are assigned to a weapon are "weapon effects"


* Effect Triggers

Conditions that must be satisfied in order for a trigger to active.

For example, an "attack trigger" requires your battler to be "attacking"

another target.



Effect Objects


This is a list of objects that support effects




* actor - applies to actors
* class - applies to classes
* item - applies to items/skills
* skill - applies to skills
* weapon - applies to weapons
* armor - applies to armors
* enemy - applies to enemies
* state - applies to states



Effect Triggers


This is a list of effect triggers that are currently supported:




* attack - triggered when you perform a skill on a battler
* guard - triggered when you are the target of a skill or item
* critical - triggered when a critical hit is inflicted
* level_up - when you increase a level
* level_down - when you decrease a level
* battle_start - triggered at the beginning of the battle
* battle_end - triggered at the end of the battle
* turn_start - triggered at the start of each turn
* turn_end - triggered at the end of each turn
* equip - equip trigger. When you equip a weapon/armor
* unequip - equip trigger. When you unequip a weapon/armor
* add - state trigger. When a state is added
* remove - state trigger. When a state is removed.
* global - special trigger. When an item/skill is used



For plugin developers


Tutorial will be linked separately when I write one.

For now you can look at the instructions at the top of the script, under "Plugin Developers"

Edited by Tsukihime
  • Like 3

Share this post

Link to post
Share on other sites

Might be useful to learn how to script by implementing your own effects.


Tools: Effect Manager


Effects are new to RMVX Ace.

VX and XP had their own implementations, but in Ace it is explicitly called an Effect.


Items and skills each have their own list of effects.

All effects are executed sequentially when the item/skill is used.


The nice thing about Ace's implementation is that these are not hardcoded into the item/skill itself. You are able to dynamically choose what kinds of effects you want from a list of built-in effects.


Additionally, you can create your own effects using scripts if you know how it works.

But since I have written the Effect Manager you don't really need to understand how they work from a scripting POV. Instead, you just need to be able to use them.


The RPG::UsableItem::Effect class


It is a very simple class. It provides 4 instance variables by default (which you can look up in the help file):

  • code
  • data_id
  • value1
  • value2

The code is an integer that is assigned to the effect. It is used for identification purposes.


data_id, value1, and value2 just contain information that the effect will use.


Obviously, you can define your own methods, but it should be sufficient to work with these given variables.


How effects work


Your item/skills all have a list of effects.

When you use a skill, the engine will at some point call the `item_apply` method defined in Game_Battler


 def item_apply(user, item)
   @result.used = item_test(user, item)
   @result.missed = (@result.used && rand >= item_hit(user, item))
   @result.evaded = (!@result.missed && rand < item_eva(user, item))
   if @result.hit?
     unless item.damage.none?
       @result.critical = (rand < item_cri(user, item))
       make_damage_value(user, item)
     item.effects.each {|effect| item_effect_apply(user, item, effect) }
     item_user_effect(user, item)


The last line is an effect that affects the user. Not too important.

The line above that is where effect processing actually begins. As you can see it simply iterates over each effect and applies them.


The engine determines which effect to apply by looking up the effect's code in a method table.

While you don't necessarily need to use a number as the code, well, it probably doesn't hurt to use one.


If the engine finds a valid method to call, it will call the method and that is where the effect is applied. Very straightforward.


Creating your own effect


So how can you use this information to make life easy?

Well, if you are going to use the Effect Manager, then life is easy: it takes care of all of the steps up there that the engine uses, and instead allows you to create effects in three steps


1: register your effect

2: define your method

3: tag your items/skills


So for example suppose we want to write a script that drains an enemy's HP.


You would start by registering your effect


Effect_Manager.register_effect(100, :item_effect_hp_drain, "hp_drain")


You are giving your effect a code, a method name, as well as an idstring which will be used for various things such as note tagging.


And now you have registered your effect! You can proceed to write the actual behavior.

But first, you should decide how you will want your users to note tag their items/skills.


So we go with something like this:


<eff: hp_drain 20>


The format of the notetag is very specific. It is of the form


<eff: effect_name arg1 arg2 arg3 ...>


Where the effect_name is the idstring you registered at the top, followed by a list of arguments that can be basically anything. The arguments will be thrown into an array, which will look like


["arg1", "arg2", "arg3", ...]


Of course, they won't be the string "arg1" but they will be the string representation of whatever the tag contains.


This array will be stored in value1.


So ok, now that we've decided on how users will be giving us info, we can write our effect method.


class Game_Battler < Game_BattlerBase
 def item_effect_hp_drain(user, item, effect)


This is the most basic form of your effect method.

-it has the same name as the method name you registered

-it takes three arguments


Note that the effect is applied from the target's perspective, so if Eric is attacking a slime and his attack drains HP, then the Slime will execute the hp drain effect.


Draining HP is easy to implement: subtract HP from the target, add HP to the user.

Recall that our notetag contains only one argument. In this case, it is 20. hence, value1 holds a reference to ["20"]


class Game_Battler < Game_BattlerBase
 def item_effect_hp_drain(user, item, effect)
   # store the value of the first argument in a variable, as an integer
   value = effect.value1[0].to_i

   # decrease target's HP, increase user's HP
   self.hp -= value
   user.hp += value


Obviously, there's a lot of holes in this math. What if the target has less than 50 HP. What if the user is at full health? You'll have to do some tweaking in order to handle all of these different cases, but for the most part, the skill tagged with this effect should properly perform the drain effect.


Lastly, we want to update the results of the action. For the most part, you probably just want to tell the engine to display some messages.


class Game_Battler < Game_BattlerBase
 def item_effect_hp_drain(user, item, effect)
   # store the value of the first argument in a variable, as an integer
   value = effect.value1[0].to_i

   # decrease target's HP, increase user's HP
   self.hp -= value
   user.hp += value

   # add a message to be displayed in the battle log
   @result.effect_results.push("%s drained %d HP from %s!" %[user.name, value, self.name])


The effect messages will automatically be displayed at the end of the action.




And that's all there is to creating effects.


This is the drain HP effect script:


Effect_Manager.register_effect(100, :item_effect_hp_drain, "hp_drain")

class Game_Battler < Game_BattlerBase
 def item_effect_hp_drain(user, item, effect)
   # store the value of the first argument in a variable, as an integer
   value = effect.value1[0].to_i

   # add a message to be displayed in the battle log
   self.hp -= value
   user.hp += value

   # add a message to be displayed in the battle log
   @result.effect_results.push("%s drained %d HP from %s!" %[user.name, value, self.name])

Edited by Tsukihime

Share this post

Link to post
Share on other sites

I have added a new feature to the script.

You can now define your own method for handling the RPG::UsableItem::Effect initialization.

This is done in class RPG::UsableItem


By default, I call this method


def add_effect(code, data_id, args)
 @effects.push(RPG::UsableItem::Effect.new(code, data_id, args.split))


Where `args` is just a bunch of strings.


However, if you take your idstring that you registered for the effect and defined a method like


def add_effect_IDSTRING(code, data_id, args)
 # do stuff with args
 @effects.push(RPG::UsableItem::Effect.new(code, data_id, args)


You can then do your type casting.


So following from the HP drain example, I might define the following method


class RPG::UsableItem
 # remember that the idstring is "hp_drain"
 def add_effect_hp_drain(code, data_id, args)
   args = args.split
   args[0] = args[0].to_i
   @effects.push(RPG::UsableItem::Effect.new(code, data_id, args)


Now I have typecasted the list of arguments appropriately so that during run-time, I don't need to do all that ugly type casting.


I pass in the data_id, but that is currently pretty useless. I only left it in there cause the Effect object wants it...

Share this post

Link to post
Share on other sites

Wowsers! This is pretty neato sweeto! Do you plan on doing this for features too? I guess features would be a bit harder since they don't have immediate effects and probably have to be checked for in various places, but still I personally make a lot of "pseudo-features" for things anyway. Also, interestingly, even skills and items can have features, even if there is no way to enter them by default.

Share this post

Link to post
Share on other sites

Actually, features is pretty much the same thing. Except it doesn't have the ugly method table defined inside a method. So technically registering features is even easier.


After all, what matters is you being able to define a feature and register it with the engine. After that, it's not something I would have to care about because you are able to perform your own data queries and the engine will give you what you need assuming you have properly tagged your stuff.


The format will be similar:


<ft: idstring args>


I'm considering whether to have you explicitly enter a data_id, because data_id is like subcategories inside a category (eg: elements: fire,water,earth, ...). With Effects, I just didn't bother with data ID's, though maybe it's not a good idea...


Thoughts? Of course since you have unlimited args, you can always just specify the first arg as the data ID no real issue there.


Another issue I've been having was the fact that I'm using a code to identify each method. This is only because that's how the default scripts does it and is in fact kind of unnecessary. It will ultimately lead to a lot of conflicts if enough people were submitting their own effects.


Actually it might not even be necessary to keep the code to an integer and just allow you to use anything you want: symbols, strings, ...


EDIT: OK, integer code restriction gone. You can use anything you want as long as it is hashable.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

tsuki. since i see there alot of your new script using this effect manager. it would be nice to put all the link to them in this topic. it will make people more interested in what this script can do. just label them as addon and put it on first page :D. really great script this is. especially devour and strip equip. it's really interesting concept.

Share this post

Link to post
Share on other sites

Good idea. Should probably open a new wiki article solely for Effect scripts (the master list is getting big) and see if it'll become a fad.

Share this post

Link to post
Share on other sites

and after quick look. even mr bubble start making script using this script too. wiki would be a great idea. :D. maybe in one year we will get really lots of effects for people to choose. :D. maybe i will try to make some effect after learning how to use your system. but i haven't got any idea what kind of effect i want to create yet :P.

Share this post

Link to post
Share on other sites

Several changes/additions.


1: when registering your effect, you only need to pass in an idstring. You'll use this idstring throughout the plugin (notetags, method names, etc)


2: extended effects to weapons, armors, and states. The following method definition formats are available


# tag items/skills and they will call this method
def item_effect_idstring(user, item, effect)

# tag weapons and they will call this method
def weapon_effect_idstring(user, weapon, effect)

# tag armors and they will call this method
def armor_effect_idstring(user, armor, effect)


States are special because they can be triggered at different times: when a state is added, when it is removed, etc.


So far I have implemented the following:


# triggered when state is added
def state_effect_idstring_add(state, effect)

# trigged when state is removed
def state_effect_idstring_remove(state, effect)


It is up to you to decide which is most appropriate for your effect.

Sometimes you might want the same effect to be tagged on different objects. Note that you only have one note tag to work with though.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

do the old effect (gold toss, etc) script still works or need to update it to new version? i already save all of them and it would be troublesome if yes LOL.

Share this post

Link to post
Share on other sites

Yes, I've changed the API although not significantly so most of it is just a one line change.

Share this post

Link to post
Share on other sites

This is an awesome script and it holds many possibilities, too.

Thanks so much for coding this; it's going to be a huge help!

Share this post

Link to post
Share on other sites

First, I have added an experimental feature called "effect callbacks" which will be stored in scenes.

An example implementation is in my Golden Touch effect.




It is experimental because so far, all it does is provide basic functionality to get it working.

Unfortunately it is up to you to make sure your script doesn't crash because you allowed your user to use something in a battle scene, but then you suddenly went to the map scene. Perhaps it will be refined in the future.


The idea is that sometimes you may have effects that should call another scene.


But then once you call the scene, your effect is done.

So the effect callback allows you to pass your effect to the target scene, as well as a particular method to call.


Every scene supports effect callbacks, though you probably will want to define your own custom scene for your callback handling. This is pretty simple since you likely will just need to inherit one of the existing classes, call your scene something unique, and then replace methods that you need to change. Probably need to grab some windows as well, but it is the same idea.


To set an effect callback, first call the new scene, then set the scene's effect callback.

Here is an example (well, it is a bad example. Just refer to the golden touch effect)


class Game_Battler

 def item_global_effect_tester(effect)
   SceneManager.scene.set_effect_callback(:some_method, effect) # pass the effect over

class Scene_CustomScene < Scene_Base

 def on_item_ok
   if @effect_callback
   return_scene # go back to where we were, though maybe not needed 

 def some_method
   p 'now my effect can be triggered here'
   p @effect.value1
   p 'and the effect is available as well'


To reduce conflict, you should probably add your effect's idstring to your custom windows and scenes.


note that effects are applied AFTER the item is used. This is not the same as command inputting, so the skill is *used*, all costs are applied, and THEN the effect is executed.




Second, I have run into an issue when it comes to using effects.

For example, suppose I have a state with a state_add effect and a state_remove effect.




The current way of tagging is just


<eff: idstring args>


But...that means the same arguments are used for BOTH methods.

Which may not be desirable, and it is immediately obvious in my Common Event effect, where the state add event will very likely be different from the state remove effect.


Another example is the an effect having triggers for weapon_passive, weapon_attack, weapon_guard, etc.

If you just tag the weapon like above, the effect will be executed everytime the battle starts, you attack, or you get attacked, when you really only wanted it to trigger when you attack.


This is what I am planning to do, and will likely do it unless someone has a better idea.

It is a fact that all of my effect triggers have standard names.




attack - when you attack (use a weapon)
guard - when you are attacked (by item/skill)
passive - at the beginning of battle


Suffixes (mainly for states)


add - when state added
remove - when state removed
turn_end - at the end of the turn


So you can note-tag with prefix/suffix to specify particular trigger(s)


<eff: attack_idstring ... >


The default note-tag would basically say *any* trigger is valid, whereas adding prefixes/suffixes will specify certain triggers.


Of course this means if you wanted ONLY attack or guard effects but not passive, you MUST specify every single one of them, even if it redundant.


<eff: attack_idstring arg1 arg2>
<eff: guard_idstring arg1 arg2>


This might be a small price to pay for having more specific triggers.



Edited by Tsukihime

Share this post

Link to post
Share on other sites

Effect Manager 2.0 is now out!


I am currently writing up new documentation for my effect manager, including all of the new stuff I have added but have neglected to describe in detail (such as different effect triggers as well as effect call backs).


Several important changes have been made, which may or may not affect you.

I decided to bump up the version to 2 because I have standardized a lot of things.


The changes have been made with backwards compatibility in mind, so 99% of the effects that have been written should work without an issue. Of course, some things just had to go, but they are not very significant.


There is one change that I wanted to make..but am not too sure whether I want to actually do it, and that is passing the item that was used to your effect. There was no requirement for this, so no plugins had this in the method signature, and adding this would require changes to every plugin out there.


I have formally put together some terminology that I will use when I am talking about effects.

They are just to sound cool for the most part.


Effect Type


The "type" of effect is defined by the object that it is assigned to.

  • A "weapon" effect is any effect that is assigned to a weapon.
  • An "armor" effect is any effect that is assigned to an armor.
  • A "state" effect is any effect that is assigned to a state.

And so on. The default engine comes with "item" effects, which are effects assigned to both items or skills. For now, that will remain this way.


Effect Trigger


This is the condition that must be met in order for an effect to activate.

It was introduced some time ago, where you had things like "weapon_attack" or "armor_guard" effects. The "attack" and "guard" parts were the actual triggers. So for example a "weapon_attack" trigger means that effect will only activate when the battler is performing an attack (with a skill).


Here is a current list of triggers that are supported:


* attack      - triggered when you perform a skill on a battler
* guard       - triggered when you are the target of a skill or item
* passive     - triggered at the beginning of the battle
* turn_end    - triggered at the end of each turn
* critical    - triggered when a critical hit is inflicted
* add         - state trigger. When a state is added
* remove      - state trigger. When a state is removed.
* global      - special trigger. When an item/skill is used


All methods should have a trigger with the exception of item effects. They are special only because the default engine doesn't have a trigger at the end of those, so it is implied that if your item/skill effect does not have a trigger, it is activated when you successfully hit your target.


List of Changes/Features


1. Effect names cannot have hyphens


If you used symbols for your effect names, then it is fine because you couldn't have hyphens in symbols.

However if you were using a string...well, you should convert your hyphens to underscores because hyphens mean something else now.


But I don't think that is much of an issue since I have not seen any effect names with hyphens.


2. Effect triggers are now available in note tags.


Suppose you have a state effect that calls a common event whenever it is added or removed.

When the state is added, you want to call common event 5.

When the state is removed, you want to call common event 6.


You can now assign these effects to your state as follows:


<eff: common_evt-add 5>
<eff: common_evt-remove 6>


The hyphen is used to separate the effect name from the effect trigger.

If no trigger is specified in your note-tag, then the assumption is that *any* trigger is valid.


3. Effect triggers in method names are now standardized


Previously, I was somewhat inconsistent with the method names. You could have something like




Where "global" and "attack" are both triggers...but they're defined in different places.

In v2.0, this is not allowed. The format of the method is officially formatted as





-TYPE is one of the effect types listed above

-IDSTRING is the name of your effect that you registered

-TRIGGER is one of the effect triggers listed above


4. Some things about triggers


An attack trigger activates triggers that the attacker has.

A critical trigger activates triggers that the attacker has.

A guard trigger activates triggers that the defender has.


Maybe in the future I will add support for "critical_guard", which should activate when the attacker successfully pulls off a critical attack, and the defender's effects are triggered as a result.

Share this post

Link to post
Share on other sites

ouch... when i think this has stop evolving and starting to use it to write my own code. IT EVOLVE AGAIN OMG! :D.

not to mention i only download the 1.6 version yesterday.

of course it's a good thing. i just hope that the changes didn't break my code (but even it break it doesn't matter since i only write small code thanks to your great manager. that won't be hard to modify instead of 1000++ lines of script :D)


edit: btw about the golden touch. i found it interesting concept. but i guess it would be better if it use SceneManager.return when we press cancel instead of when item ok. and displaying the money gained in same scene (maybe using new window in Scene_Golden Touch or just use yanfly gab window). so we can sell the item many times in one golden touch ability. (so we have alternative to selling things than shop :D). the current version only let us sell one item in one golden touch skill >.

Edited by estriole

Share this post

Link to post
Share on other sites

The changes are only related to method names (trigger at the end) and effect names (no hyphens) everything else is the same.


The golden touch skill is specifically to convert a particular item into gold.

Perhaps a "call shop" effect could be used to call a shop. Or use a common event to call a shop; same thing.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

the gold multiplier is the one that make that skill interesting instead of just regular call shop :D. but of course it's tiring process if we have to activate skill, convert one item, activate skill, convert one item. i would rather just sell it at shop rather than doing that tiring process over and over even if i get 10x value for the item LOL.

Share this post

Link to post
Share on other sites

Combine call shop with something like http://www.rpgmakervxace.net/topic/7903-haggle-rate where you set the price rate when you call the shop and then remove the price rate.


Use an effect to set the party's haggle rate, and then have the callback reset the haggle rate.

You will probably want to use a common event to set up the actual shop contents and fetch it from there somehow.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

ah ic. but i think i will modify your golden touch scene instead. it's because i like the simplicity. :D.


and i have another suggestion for you. if i recall you have thread somewhere "Request your effect". i couldn't find it. so i think it would be better if you could link it to this thread top post :D. it will easier for people who interested in using your effect script to made request.. and also easier for scripter who want to try using this manager but still have no idea what to make. they could find idea there from someone who really need them :D.


and a little bit information about your banish effect. it doesn't work if using victor animated battle. problem with some actor set pose method. but the error only show when we banishing the actor. if we banish the enemy it work beautifully. the problem is not at the script fault but at victor side i guess. the script didn't recognize the actor is hidden when setting the hurt pose(i think).

Share this post

Link to post
Share on other sites

You should test the effect callbacks to see if there are things you can't accomplish easily.

Also you may find things that could be added to make things more flexible.


For example, when I think of having to use a common event, you're sort of stuck there since I don't have any effect callback support for that so once you call a common event there is no way to get a reference to the effect.


Which means I should probably store it in $game_temp in case you need to store that effect globally.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

another report.

if used with mr bubble autolife script. mr bubble script must below this script to make it work. just some information.

Share this post

Link to post
Share on other sites

i manage to mod the golden touch script. i post my modified version in your golden touch thread.

it doesn't go back to scene map or battle but stay at the scene golden touch for more 'touching' :P

and for the money display i use yanfly gab window for showing the gold received. (so we don't need to back to scene map or battle)


i also made some mod to your effect - change graphic to make it have two tags

<eff: change_enemy_graphic enemy_id permanent?>

<eff: change_actor_graphic actor_id permanent?>

to make it able to use to change the enemy and actor graphic. (actually it's two effect but i put it in one script)


and it works for victor animated battle if using charset mode.

i post it in your effect change graphic thread. btw you forgot to tag the change graphic with effect. so it's not shown in the search result :D.


and finally... after practicing with two of your effect. i write my own original effect. share the pain state

if someone hit battler that have share the pain state

every battler with the 'same' share the pain state will received damage as well. (you can make different share the pain state)


edit: omg. i just realize the above post is also mine. sorry for double post. (i don't know this categories as double post or not since the topic is different and the day already passed but if yes sorry)

Edited by estriole

Share this post

Link to post
Share on other sites

Using the gab window there is pretty cool. It also looks more realistic.


And yes I only started tagging my effects after I did a couple so I probably missed a couple.


I have implemented equip/unequip effect triggers, which will trigger any weapon/armor effects on equip/unequip.


They have the following specs:


Effect Type

Effect Triggers
-equip: triggered when you equip an item
-unequip: triggered when you unequip an item

Method signature format

weapon_effect_IDSTRING_equip(equip, effect)
weapon_effect_IDSTRING_unequip(equip, effect)



Also, there is on effect trigger called "passive" which I designated as "on battle start". I am renaming that to "auto" because I am probably going to treat passive effects as something completely different.

Edited by Tsukihime

Share this post

Link to post
Share on other sites

nice... so this will evolve once more :D.

if there's on battle start effect... it would be really awesome. auto states just doesn't enough to do some crazy thing :D. hmm i guess i could have some idea on battle start effect. so could you put it available for actor, class, weapon, armor, state, and hopefully skill (if actor learn the skill it will activate auto battle start effect). is that hard?.


some idea i have maybe. have a skill that when learned. at battle start damage all enemy by 100 hp. or poison them. or anything. neat. :P.

in game people could treat it as passive auto skill. i think i see some game use that feature before just forget what game.


oh my god. after writing above i have more idea... how about turn end or turn start effect trigger (i guess i should stop asking too much >.<). so the effect will execute after turn end or start of the turn.


in above idea. skill that deal 100hp damage to all enemies every turn end

Share this post

Link to post
Share on other sites

Ok so I have added the following triggers









Right now it is very trivial to add new triggers I just need to write one line of code each for aliasing, calling my check, and the actual checker.



I am still trying to make my code less chunky (went from 1300 to 700 already, but could be better). Might hold off on triggers until I figure out a way to stop writing redundant code for every trigger.


I've had passive effects in mind for some time but I am just not sure when they should be triggered. I can't just say "they should ALWAYS be triggered" because you're throwing yourself into an infinite loop.


Turn end and battle start (auto) triggers are already available.

Turn start will probably be added as well in the future since it is trivial.


Actually most triggers are trivial to add.


The next "major" change I will be making is to preserve certain states even after you die so that you can implement things like auto-life or zombie-resurrection after certain amount of turns have passed or something.




ok, well, I have made my code less chunkier.

I just did what Features was doing and just defined "effect_objects" method and deleted 100 lines of code.


I have added "turn_start" trigger.

I changed the "auto" again to "battle_start" now to be consistent with "battle_end" effects.



Edited by Tsukihime

Share this post

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

  • Recently Browsing   0 members

    No registered users viewing this page.

Top ArrowTop Arrow Highlighted