Summon members

[HimeWorks]

Basic summoning system. Two different cases.

1. Battlers can call other battlers into battle
2. Summoned battlers may disappear over-time
3. Specifically for battles, summoned battlers may disappear after the battle is over

Not sure whether I will write this as a single script, or as a series of scripts.

[Selchar]

I remember trying out and extending Fomar's Aeon script with self made scriptcalls(used in damage formula instead of common events), getting it to add to the party instead of replacing, simplifying original aeon calling method, replacing aeon, and unsummon. It's a nice and simple design, but does have it's limits. The only thing I couldn't do(at the time) was disappearing over time, tho now that I think about it that itself could be solved by adding a state that removes the summon when it wears off.

Thinking about it it might be nice to see if there's a easier, possibly more compatible?(I think Fomars had some problems, don't remember what) way of doing it.

[HimeWorks]

Ya, summon state is pretty much what I'm doing. The summon sequence would add an actor and give it a summon state. When the state disappears, the summon disappears. Note that dying would also cause it to disappear by default, which may or may not be desirable.

This would apply to both in-battle and out-of-battle summons. You can summon a battler outside of battle and enter a battle, or you can summon a battler during battle and have it persist even after the battle finishes.

You would use two summon states if you want to specify whether a summon should persist or not. One state would just disappear after battle is over.

The core summon script would basically provide this state and associated logic included with the act of summoning someone and removing them from battle.

Removing a summon would basically be removing the state. You can easily create "unsummon" or "dispel" magic as a result.

[HimeWorks]

Providing functionality for replacing actors with a summon would be useful

For example, say the caster was replaced by the summon (this would be used as a transform mechanic), or the caster replaces another battler.

The replacement itself could be configured in several ways

1: temporarily replace the battler (so a temp transform)

2. Kill the battler (treat it as a sacrifice instead)

Furthermore, you can replace more than one battler. You might replace the entire party temporarily and then bring them back when the summon disappears, or you might just sacrifice your entire unit.

In order to avoid getting a game over when the summon disappears (for example, if it replaces the whole party), it is important that the unsummoning process rolls back the changes before the battle manager kicks in and determines that it's game over cause...no one's alive!

[HimeWorks]

Well, I've implemented a simple actor summoning system using states. When an actor is summoned, the summon state will be added to it. When the summon state is removed, the actor will then be removed as well.

It uses an asynchronous approach where the interpreter or skill or something requests for a summon to be added.

The party will immediately see this request and add a summon to its list of members, and then set a flag indicating that its members have changed.

The scene, which is constantly polling the party to determine whether there are any summoning jobs available, will notice that the summon flag is set. It will then proceed to update all of its windows with the new data.

This will require me to alias all relevant scenes with the new update logic. There is no reason why the scene would have to update immediately when a new summon appears. The scene can choose when it wishes to process the fact that a new summon has appeared.

Still WIP https://www.dropbox.com/sh/sz6mpw5n2d6zxi2/plBvBhleir/RMVXA%20Scripts/Summon_System.txt

[Selchar]

I attempted to make one myself, tho it ended up being an easier to use with a few changes in coding rewrite of Fomars. Anyways just tested yours there, it seems to work alright, however if a summon dies before their state disappears, they remain in battle. Reviving a summon doesn't return the summon state or make it disappear. The summon will stay until the summon state is re-applied and is removed naturally.

[HimeWorks]

Ya, originally I had a constant check to see whether the state has been removed (or rather, is no longer applied, via state?), but then I moved it into erase_state which...obviously doesn't get called when someone dies!

It's probably easiest to treat this as a special exception and just alias the die method to do something different when the summon dies.

Because for whatever reason, RM devs decided that die should just clear all the states rather than properly removing each one.

For the most part, I would prefer to just constantly poll my summons to determine whether they should be removed or not, but I don't want it to be done every frame.