Problems when using SRD Summon and YEP Animated SV Battlers

bubonig

Villager
Member
Joined
Jun 1, 2020
Messages
5
Reaction score
0
First Language
English
Primarily Uses
RMMV
Everything works fine until the battle ends, and the loot is obtained. Then this error occurs (pic1)error1.png

I tried searching around but didn't find any fixes. Can this be fixed and if not, can you suggest alternative plugins?
(I only need Animated SV for changing the enemy battler size but summoning is important to me)
 

mrzo

It's a diminished chord bro
Member
Joined
Feb 23, 2020
Messages
7
Reaction score
3
First Language
en
Primarily Uses
RMMV
i had that same deal someone will help us.
 

Andar

Veteran
Veteran
Joined
Mar 5, 2013
Messages
30,907
Reaction score
7,447
First Language
German
Primarily Uses
RMMV
yes, such errors can be fixed - but they might require custom fixes that work for no one else. And you didn't give enough info to even start on one such fix.

The problem is that a lot of battle-plugins add data to the battlers - like adding different sprites instead of the original pictures and so on. And this added data is usually handled at the setup of the battle, not later.
A summoning plugin adds or changes the battler at a later time, and that means it has to know what other data was added by other plugins. If the summoning plugin does not know what other data was added, that data will be missing in the newly summoned battler - "cannot read missing data" is what your screenshot above basically says.

That is why a summoning plugin will always work only with a known set of battleplugins - often either only default battlesystem or the battlesystem that the plugin programmer has written himself/herself.
For all other cases, the summoning needs to be reprogrammed for the combination of plugins used by the other game project.

Which means you'll have to ask a moderator to move this to plugin requests, and give screenshots of your plugin manager as well as links to the websites of all the battleplugins you're using, so that whoever offers to write a compatibility patch will know exactly what plugins he has to write the patch for.
and if you change your battleplugins later that compatibility patch might have to be reprogrammed then as well.
 

bubonig

Villager
Member
Joined
Jun 1, 2020
Messages
5
Reaction score
0
First Language
English
Primarily Uses
RMMV
yes, such errors can be fixed - but they might require custom fixes that work for no one else. And you didn't give enough info to even start on one such fix.

The problem is that a lot of battle-plugins add data to the battlers - like adding different sprites instead of the original pictures and so on. And this added data is usually handled at the setup of the battle, not later.
A summoning plugin adds or changes the battler at a later time, and that means it has to know what other data was added by other plugins. If the summoning plugin does not know what other data was added, that data will be missing in the newly summoned battler - "cannot read missing data" is what your screenshot above basically says.

That is why a summoning plugin will always work only with a known set of battleplugins - often either only default battlesystem or the battlesystem that the plugin programmer has written himself/herself.
For all other cases, the summoning needs to be reprogrammed for the combination of plugins used by the other game project.

Which means you'll have to ask a moderator to move this to plugin requests, and give screenshots of your plugin manager as well as links to the websites of all the battleplugins you're using, so that whoever offers to write a compatibility patch will know exactly what plugins he has to write the patch for.
and if you change your battleplugins later that compatibility patch might have to be reprogrammed then as well.
Yeah I didn't add much info as I just wanted to know whether it was possible, and didn't want to bother someone to make a patch just for it.
 

zerobeat032

Cloaked Wanderer...
Veteran
Joined
Mar 28, 2014
Messages
286
Reaction score
305
First Language
English
Primarily Uses
RMMV
I think the problem is how the actor is called into battle from SRDude's Summon plugin. It doesn't seem to account for that extra actor and thus Animated enemies throws a fit trying to figure out what to do with them. I could be wrong of course, but that's what I've noticed in trying to figure out what the issue was myself as I've had the exact same issue.
 

Htlaets

Veteran
Veteran
Joined
Feb 1, 2017
Messages
85
Reaction score
56
First Language
English
Primarily Uses
SOLUTION FOUND IN NEXT POST

So, I've run into this problem myself (not sure if one month is considered necro).

The exact problem seems to be when the summon gets either A: desummoned, B: killed, or C: Battle ends, and thus it gets desummoned. The summon attacking and being attacked with action sequences and the like isn't a problem at all.

I've been sniffing through srd's and Yanfly's plugin's and I think I've identified the code which causes the problem:

Yanfly battlecore snippet:

Code:
BattleManager.registerSprite = function(battler, sprite) {
  if (!this._registeredSprites) this._registeredSprites = {};
  if (battler.isActor()) var id = 100000 + battler.actorId();
  if (battler.isEnemy()) var id = 200000 + battler.index();
  this._registeredSprites[id] = sprite;
};

BattleManager.getSprite = function(battler) {
  if (!this._registeredSprites) this._registeredSprites = {};
  if (battler.isActor()) var id = 100000 + battler.actorId();
  if (battler.isEnemy()) var id = 200000 + battler.index();
  return this._registeredSprites[id];
};
SRD Summon snippet:
This appears to be where the notetag info gets loaded in
Code:
const summon = $gameParty.summonActor(id, lvl, turns, introAni, exitAni, this._subjectActorId);
and
Code:
BattleManager._spriteset.registerSummonSprite(summon);
And
Code:
Spriteset_Battle.prototype.registerSummonSprite = function(battler) {
    for(let i = 0; i < this._summonSprites.length; i++) {
        const summon = this._summonSprites[i];
        if(!summon.hasBattler()) {
            battler.setBattleSprite(summon);
            summon.setBattler(battler);
            this.reorganizeSummonSprites();
            return summon;
        }
    }
Here's where the debug actually seems to fail in yanfly's animated side view enemies:
Code:
Sprite_Animation.prototype.updateSvePosition = function() {
  if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
    }
  }
};
Of course, in the debug battlecore isn't referenced at all, but the problem seems to be that the value registered isn't recognized or that there is no value passed to the "battler" property, or maybe it's the ID property? I dunno


Anyway, I'm a crap coder (took a javascript course a while back for funsies) and not terribly familiar with MV's base functions and how they tie in here, but I'm trying to fiddle with this anyway. Looking for some direction.

I'm of two minds here on how to proceed. I'd like to only mess with one end to fix it(preferably the SRD end), but I'm not sure that's possible.

A: I'm wondering if I can call the yanfly registration functions in SRD's plugin and get the plugin to spoof an "isactor" positive check to the battlecore and things would just work from there. Of course there are so many functions connected to that I don't know if it wouldn't just cause other problems and I'm not quite sure how to do so, I feel like referencing the actor switch yanfly plugin might have a registration check I can copy.

B: I'm wondering if I can just append a third conditional to the Yanfly registration implementing the "summon" type to the battlers. Though, I feel like that won't solve the problem without also changing the animated side view enemies conditional that check isenemy. And then I might have to change other yanfly plugins that do the same thing? Or maybe not, since the summon only seems to have one actual failure point.

Anywho, any pointers would be greatly appreciated.

Edit:
Actually, third possibility:
Code:
Spriteset_Battle.prototype.removeSummonSprite = function(battler) {
    this._summonSprites.forEach(function(summon) {
        if(summon.isBattler(battler)) {
            summon.setBattler(null);
        }
    }, this);
};
This is the summon removal function it seems. So, I'm wondering if this particular function wasn't at the bottom of the load order if it would be able to avoid the whole issue?

Yeah, I have very little idea of what I'm talking about, so again, help appreciated.
 
Last edited:

Htlaets

Veteran
Veteran
Joined
Feb 1, 2017
Messages
85
Reaction score
56
First Language
English
Primarily Uses
EDIT: Fix of the fix!

Yeah, so, it turns out the fix I posted before was just cuasing a syntax error that was skipping the code in question.

That being said, it wasn't causing any issues, though I imagine that function is there for something? Anyway, found a new fix that seems work? I was exploring the SRD summon core when I noticed this:

Code:
if(!Imported.YEP_BattleEngineCore) {

_.Window_BattleLog_startAction = Window_BattleLog.prototype.startAction;
Window_BattleLog.prototype.startAction = function(subject, action, targets) {
    const item = action.item();
    if(item.summonInfo) {
        this.push('performActionStart', subject, action);
        this.push('waitForMovement');
        this.push('performAction', subject, action);
        this.push('initSummonIntros', targets.clone());
        this.displayAction(subject, item);
    } else {
        _.Window_BattleLog_startAction.apply(this, arguments);
    }
};

} else {

//Random Compatibility Fixes ;-;

_.BattleManager_createFollowActions = BattleManager.createFollowActions;
BattleManager.createFollowActions = function() {
    _.BattleManager_createFollowActions.apply(this, arguments);
    if(this._action.item().summonInfo) this._logWindow.initSummonIntros(this._targets);
};

_.Window_Base_drawGauge = Window_Base.prototype.drawGauge;
Window_Base.prototype.drawGauge = function(x, y, width, rate, color1, color2) {
    if(!rate && rate !== 0) return;
    _.Window_Base_drawGauge.apply(this, arguments);
};

Game_Summon.prototype.battler = function() {
    return this.battleSprite();
};

}
Which seems to be replacing compatibility code for whether or not yanfly's battle engine code exists. I decided to just see what'd happen if the original code was changed by doing this:
Code:
if(Imported.YEP_BattleEngineCore) {
As it turns out this fixes the crashing problem. Unknown if it causes other issues, though!

Old post for posterity:
So, for the sake of people who google this later I will DP:

I fixed the problem. I might've caused another problem in doing so, but as of now it's working. The fix is simple and I'm suspicious that I might've caused other issues but I'm having a hard time figuring out how that's the case.

Here's the fix:
In Yanfly's animated side view battler plugin there's a function that is the following:
Code:
Sprite_Animation.prototype.updateSvePosition = function() {
  if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
    }
  }
};
Note: The failure point is when the sprite gets "isenemy'd" which seems to only happen when it dies/disappears for whatever reason.

But there's a function in SRD's summon core that would handle it, if Yanfly's sideview enemies didn't crash the game first:
Code:
Spriteset_Battle.prototype.registerSummonSprite = function(battler) {
    for(let i = 0; i < this._summonSprites.length; i++) {
        const summon = this._summonSprites[i];
        if(!summon.hasBattler()) {
            battler.setBattleSprite(summon);
            summon.setBattler(battler);
            this.reorganizeSummonSprites();
            return summon;
        }
    }
    return false;
};
Which leads us to the final, duct taped, solution:
Code:
Sprite_Animation.prototype.updateSvePosition = function() {
    if (if(summon.hasBattler()))
    {
    }
  else if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
  
    }
  }

};
Yes, I just called the SRD plugin to jump the failure and that's it.

I'm trying to think of ways this can fail, but it'd only ever come up with a summon battler, and if that works, well....

Edit:

You know, in hindsight I could've just edited the previous post. Hmmm... Whelp. It's done.
 
Last edited:

SoulOfRock

Veteran
Veteran
Joined
Mar 19, 2014
Messages
51
Reaction score
6
First Language
Spanish
Primarily Uses
EDIT: Fix of the fix!

Yeah, so, it turns out the fix I posted before was just cuasing a syntax error that was skipping the code in question.

That being said, it wasn't causing any issues, though I imagine that function is there for something? Anyway, found a new fix that seems work? I was exploring the SRD summon core when I noticed this:

Code:
if(Imported.YEP_BattleEngineCore) {

_.Window_BattleLog_startAction = Window_BattleLog.prototype.startAction;
Window_BattleLog.prototype.startAction = function(subject, action, targets) {
    const item = action.item();
    if(item.summonInfo) {
        this.push('performActionStart', subject, action);
        this.push('waitForMovement');
        this.push('performAction', subject, action);
        this.push('initSummonIntros', targets.clone());
        this.displayAction(subject, item);
    } else {
        _.Window_BattleLog_startAction.apply(this, arguments);
    }
};

} else {

//Random Compatibility Fixes ;-;

_.BattleManager_createFollowActions = BattleManager.createFollowActions;
BattleManager.createFollowActions = function() {
    _.BattleManager_createFollowActions.apply(this, arguments);
    if(this._action.item().summonInfo) this._logWindow.initSummonIntros(this._targets);
};

_.Window_Base_drawGauge = Window_Base.prototype.drawGauge;
Window_Base.prototype.drawGauge = function(x, y, width, rate, color1, color2) {
    if(!rate && rate !== 0) return;
    _.Window_Base_drawGauge.apply(this, arguments);
};

Game_Summon.prototype.battler = function() {
    return this.battleSprite();
};

}
Which seems to be replacing compatibility code for whether or not yanfly's battle engine code exists. I decided to just see what'd happen if the original code was changed by doing this:
Code:
if(Imported.YEP_BattleEngineCore) {
As it turns out this fixes the crashing problem. Unknown if it causes other issues, though!

Old post for posterity:
So, for the sake of people who google this later I will DP:

I fixed the problem. I might've caused another problem in doing so, but as of now it's working. The fix is simple and I'm suspicious that I might've caused other issues but I'm having a hard time figuring out how that's the case.

Here's the fix:
In Yanfly's animated side view battler plugin there's a function that is the following:
Code:
Sprite_Animation.prototype.updateSvePosition = function() {
  if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
    }
  }
};
Note: The failure point is when the sprite gets "isenemy'd" which seems to only happen when it dies/disappears for whatever reason.

But there's a function in SRD's summon core that would handle it, if Yanfly's sideview enemies didn't crash the game first:
Code:
Spriteset_Battle.prototype.registerSummonSprite = function(battler) {
    for(let i = 0; i < this._summonSprites.length; i++) {
        const summon = this._summonSprites[i];
        if(!summon.hasBattler()) {
            battler.setBattleSprite(summon);
            summon.setBattler(battler);
            this.reorganizeSummonSprites();
            return summon;
        }
    }
    return false;
};
Which leads us to the final, duct taped, solution:
Code:
Sprite_Animation.prototype.updateSvePosition = function() {
    if (if(summon.hasBattler()))
    {
    }
  else if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
  
    }
  }

};
Yes, I just called the SRD plugin to jump the failure and that's it.

I'm trying to think of ways this can fail, but it'd only ever come up with a summon battler, and if that works, well....

Edit:

You know, in hindsight I could've just edited the previous post. Hmmm... Whelp. It's done.
I dont understand, what i need to do :v change what line or what? e.e
 

Htlaets

Veteran
Veteran
Joined
Feb 1, 2017
Messages
85
Reaction score
56
First Language
English
Primarily Uses
I dont understand, what i need to do :v change what line or what? e.e
Ah, I copied the code post change there. You'll find a line that says:
if(!Imported.YEP_BattleEngineCore) {
Get rid of the !, everything will work just fine with yanflys plugins once you do that, oddly enough, since the part that actually breaks seems to be the part added to make things compatible.
 

bubonig

Villager
Member
Joined
Jun 1, 2020
Messages
5
Reaction score
0
First Language
English
Primarily Uses
RMMV
It still doesn't seem to be working
 
Last edited:

41728280

Veteran
Veteran
Joined
May 31, 2020
Messages
239
Reaction score
71
First Language
Chinese
Primarily Uses
RMMV
I would like to ask, is the problem solved?
Which section of the above code should be used?
Add it to the code of the plugin?
Or use it to overwrite the code in the plugin?
Which plugin is the code about? YEP or SRD plug-in?
Sorry, I don’t quite understand, I hope to answer. . .
 

bubonig

Villager
Member
Joined
Jun 1, 2020
Messages
5
Reaction score
0
First Language
English
Primarily Uses
RMMV
I would like to ask, is the problem solved?
Which section of the above code should be used?
Add it to the code of the plugin?
Or use it to overwrite the code in the plugin?
Which plugin is the code about? YEP or SRD plug-in?
Sorry, I don’t quite understand, I hope to answer. . .
Well it didn't work for me, but it worked for him. He changed a line in SRD plugin.
 

41728280

Veteran
Veteran
Joined
May 31, 2020
Messages
239
Reaction score
71
First Language
Chinese
Primarily Uses
RMMV
Well it didn't work for me, but it worked for him. He changed a line in SRD plugin.
I really can't understand what he is talking about. I removed the following code in the Animated SV Battlers plug-in of yanfly. Both the Summon plug-in and the SV plug-in can work, but I don’t know what the impact will be.
JavaScript:
Yanfly.SVE.Sprite_Animation_updatePosition =
  Sprite_Animation.prototype.updatePosition;
Sprite_Animation.prototype.updatePosition = function() {
  Yanfly.SVE.Sprite_Animation_updatePosition.call(this);
  this.updateSvePosition();
};

Sprite_Animation.prototype.updateSvePosition = function() {
  if (typeof this._target.parent._battler != 'undefined' && this._target.parent._battler.isEnemy() && typeof this._target.parent._mainSprite != 'undefined'){
    if (this._animation.position !== 3) {
      if (this._animation.position === 0) {
        this.y += this._target.parent._mainSprite.height - this._target.parent.texture.height;
      } else if (this._animation.position === 1) {
        this.y += (this._target.parent._mainSprite.height - this._target.parent.texture.height) / 2;
      }
    }
  }
};
 

Users Who Are Viewing This Thread (Users: 0, Guests: 1)

Latest Threads

Latest Posts

Latest Profile Posts

Ami
--- Diary ---

M.Mage: It's the F.Mage's Diary. While she isn't here,i can read it.

May, 10: I'm hurt after the battle with the Minotaur. But luckily,F.Healer heal me with her Heal-2. That why,i Fall in Love with her.

M.Mage: Eh???
So... some of my Desktop hardware has kicked it apparently (still trying to figure out what and how at the moment :/ ) .... yay?
Stream will be live shortly with some Darkest Dungeon! Feel free to drop by!
Made a HUGE (YYOOOOJJ) Update to Monstructs and moving towards a Steam Early Access release!
A skill type called: "Rumagic". The intention is Magic with Rum(that pirates drink)
Does it sound strange in English?

Forum statistics

Threads
104,221
Messages
1,004,799
Members
135,736
Latest member
moenimael
Top