RMMV "this.stateOrigin().mat" vs "origin.mat"?

Frostorm

[]D[][]V[][]D aka "Staf00"
Veteran
Joined
Feb 22, 2016
Messages
1,819
Reaction score
1,581
First Language
English
Primarily Uses
RMMV
Just wondering what the difference is between:
JavaScript:
<Custom Apply Effect>
var x = this.stateOrigin(61).mat ** (1 + this.stateOrigin(61).luk / 1000);
target.addAgi(x);
target.addLuk(x);
</Custom Apply Effect>
vs something like this:
JavaScript:
<Custom Apply Effect>
var x = origin.mat ** (1 + origin.luk / 1000);
target.addAgi(x);
target.addLuk(x);
</Custom Apply Effect>
In the context of a state's notebox ofc. I feel like the 1st version is more defined, and I wonder if I should use this.stateOrigin() for every skill that applies a state.

Edit: I'm hoping it will fix an issue I had trying to create a skill that reduces a target's DEF by some amount depending on the caster's ATK for example (because origin.atk doesn't work in LTBS for some reason).
 
Last edited:

caethyril

^_^
Veteran
Joined
Feb 21, 2018
Messages
2,219
Reaction score
1,629
First Language
EN
Primarily Uses
RMMZ
It should be target.stateOrigin(61), but otherwise [Edit: this is inaccurate, see follow-up post below!] (assuming this is on state ID 61) there should be no difference in the end result.

origin is a local variable assigned to the origin of the current state on the target. I imagine the LTBS problem is due to Yanfly's state-origin-setting code not firing correctly, which could be for a number of reasons (plugin order, incompatibility, etc).
 
Last edited:

Frostorm

[]D[][]V[][]D aka "Staf00"
Veteran
Joined
Feb 22, 2016
Messages
1,819
Reaction score
1,581
First Language
English
Primarily Uses
RMMV
What would "this.stateOrigin()" do vs "target.stateOrigin()"? I got the "this.stateOrigin()" from a Yanfly tips & tricks video, but I can't seem to remember which one lol.

Edit: Did some testing and "this.stateOrigin()" seems to work just fine. Should I still change it to target instead of this? (So many states would need editing lol)
 
Last edited:

caethyril

^_^
Veteran
Joined
Feb 21, 2018
Messages
2,219
Reaction score
1,629
First Language
EN
Primarily Uses
RMMZ
Oh, my mistake! :kaoblush: On closer inspection it seems to depend on the tag type. stateOrigin is, by default, defined exclusively on Game_Battler, but some tags are evaluated in a different context:
  • "Custom Timing" or "Custom Turn" tags (cf the plugin's help description), like <Custom Apply Effect>, are evaluated in a Game_Battler context. I.e. user = target = this by definition, so use whichever you prefer~

  • "Custom Action" tags, like <Custom React Effect>, are evaluated in a Game_Action context. I do not recommend using this.stateOrigin in these tags, since it will likely cause an error.
You can check the console (F8) during play to see if any errors are occurring.

As already mentioned, origin is literally just a shorthand for the origin of the state for the appropriate battler (search for var origin in YEP_BuffsStatesCore.js for details), so I think there are only a few cases when you'd want to manually call stateOrigin. :kaothx:
 

Frostorm

[]D[][]V[][]D aka "Staf00"
Veteran
Joined
Feb 22, 2016
Messages
1,819
Reaction score
1,581
First Language
English
Primarily Uses
RMMV
Is stateOrigin a Yanfly thing or a default MV thing? I recently discovered stateOrigin doesn't work (always targets the unit the state is on instead of the caster). Must be that LTBS incompatibility?

Edit: @caethyril is there an alternative for origin?
 
Last edited:

caethyril

^_^
Veteran
Joined
Feb 21, 2018
Messages
2,219
Reaction score
1,629
First Language
EN
Primarily Uses
RMMZ
Nothing like stateOrigin exists in the core scripts. It is a method defined in Yanfly's Buffs & States Core ("BSC") for battlers (i.e. actors and enemies). It is invoked as battler.stateOrigin, where battler points to an instance of Game_Battler (an actor or an enemy). The result of the method should be a pointer to the enemy/actor who applied the specified state to battler. ^-^

The state origin is the battler who used the action responsible for applying the state to the target of that action. The origin should be set when the state is applied. Actions can target battlers other than the subject of the action, so yes, what you are seeing is not normal behaviour. Whether or not it is related to LTBS is uncertain...you could do a basic check by turning off LTBS, saving your project to apply plugin changes, and testing.

this is a JavaScript keyword, not a variable. Its value depends on where it is used, i.e. it depends on the context. As I mentioned, different BSC notetags get evaluated in different contexts. For example, <Custom Apply Effect> gets evaluated in a Game_Battler context, so this in such a notetag will reference an instance of Game_Battler, meaning this.stateOrigin(123) is a valid method call that should return the enemy/actor who applied state #123 to "this" battler instance.

I know nearly nothing about LTBS. I notice it claims to be compatible with YEA_BuffStateCore, though...I assume that's a typo for YEP_BuffsStatesCore? If the author(s) is/are still active, have you asked whether they tested the origin stuff? :kaoswt:

To reiterate what I said earlier: I imagine (untested) that this incompatibility would be due to LTBS redefining the battle flow in such a way that the state origins never get set, i.e. setStateOrigin might not be being invoked.

I do not personally have the knowledge or the inclination to puzzle out a compatibility patch for so many complex plugins at present; maybe someone else can help with the details. :kaoslp:
 

Frostorm

[]D[][]V[][]D aka "Staf00"
Veteran
Joined
Feb 22, 2016
Messages
1,819
Reaction score
1,581
First Language
English
Primarily Uses
RMMV
Whether or not it is related to LTBS is uncertain...you could do a basic check by turning off LTBS, saving your project to apply plugin changes, and testing.
Yes, that was actually my 1st instinct. I have confirmed this issue only occurs while using LTBS.

I know nearly nothing about LTBS. I notice it claims to be compatible with YEA_BuffStateCore, though...I assume that's a typo for YEP_BuffsStatesCore? If the author(s) is/are still active, have you asked whether they tested the origin stuff? :kaoswt:
Unfortunately, the creator (LeCode) is inactive and has been for some time. He had plans to release a new v0.8 that would've been a complete rewrite from the ground up, but that never happened. Our resident expert on LTBS (at least on this forum) seems to be @Pharonix, but I think he may be busy w/ RL lately. The LTBS demo actually comes w/ a Yanfly patch, but I've looked in it, and it's rather short:
JavaScript:
/*
#=============================================================================
# LeTBS: Patch for Yanfly's plugins
# LeTBS_YanflyPatch.js
# By Lecode
# Version 1.0
#-----------------------------------------------------------------------------
# TERMS OF USE
#-----------------------------------------------------------------------------
# https://github.com/LecodeMV/leTBS/blob/master/LICENSE.txt
#-----------------------------------------------------------------------------
# Version History
#-----------------------------------------------------------------------------
# - 1.0 : Initial release
# - 1.1 : Make LeTBS support common events in battle
#=============================================================================
*/
var Imported = Imported || {};
Imported["LeTBS_YanflyPatch"] = true;

var Lecode = Lecode || {};
Lecode.S_TBS.YanflyPatch = {};
/*:
* @plugindesc Fixes compatibility issues with Yanfly's plugins
* @author Lecode
* @version 1.1
*

* @help
* ============================================================================
* Introduction
* ============================================================================
*
* This plugin fixes some compatibility issues with Yanfly's plugins.
*/
//#=============================================================================

if (Imported.YEP_BattleEngineCore) {

    Lecode.S_TBS.YanflyPatch.oldGameBattler_startDamagePopup = Game_Battler.prototype.startDamagePopup;
    Game_Battler.prototype.startDamagePopup = function () {
        if (!Lecode.S_TBS.commandOn) {
            Lecode.S_TBS.YanflyPatch.oldGameBattler_startDamagePopup.call(this);
        }
    };

    Sprite_Damage.prototype.setup = function (target) {
        this._result = Lecode.S_TBS.commandOn ? target.result() : target.shiftDamagePopup();
        var result = this._result;
        if (result.missed || result.evaded) {
            this.createMiss();
        } else if (result.hpAffected) {
            this.createDigits(0, result.hpDamage);
        } else if (target.isAlive() && result.mpDamage !== 0) {
            this.createDigits(2, result.mpDamage);
        }
        if (result.critical) {
            this.setupCriticalEffect();
        }
    };

    BattleManager.processVictory = function () {
        this._victoryPhase = true;
        if (this._windowLayer) this._windowLayer.x = 0;
        Yanfly.BEC.BattleManager_processVictory.call(this);
    };

    Game_Action.prototype.applyGlobal = function () {
        if (!Lecode.S_TBS.commandOn && $gameParty.inBattle()) return;
        Yanfly.BEC.Game_Action_applyGlobal.call(this);
    };

} //- YEP_BattleEngineCore

if (Imported.YEP_X_SkillCooldowns) {
    Lecode.S_TBS.YanflyPatch.oldBattleManagerTBS_stopBattle = BattleManagerTBS.stopBattle;
    BattleManagerTBS.stopBattle = function () {
        Lecode.S_TBS.YanflyPatch.oldBattleManagerTBS_stopBattle.call(this);
        $gameParty.endBattleCooldowns();
    };

    if (Imported.LeTBS_Summoning) {
        Lecode.S_TBS.YanflyPatch.oldGameTroop_increaseTurn = Game_Troop.prototype.increaseTurn;
        Game_Troop.prototype.increaseTurn = function () {
            Lecode.S_TBS.YanflyPatch.oldGameTroop_increaseTurn.call(this);
            BattleManagerTBS._summons.forEach(function (entity) {
                entity.battler().updateCooldowns();
                entity.battler().updateWarmups();
            });
        };
    }
}

Lecode.S_TBS.YanflyPatch.oldTBSEntity_onTurnStart = TBSEntity.prototype.onTurnStart;
TBSEntity.prototype.onTurnStart = function () {
    if (this._battler.onTurnStart)
        this._battler.onTurnStart();
    Lecode.S_TBS.YanflyPatch.oldTBSEntity_onTurnStart.call(this);
};
I was hoping there was an alternative to get the same functionality of origin w/o using the code, perhaps w/ eventing & v[ ]? Like how did the old school XP users do it back then if they wanted to use utility scaling for instance? (I'm assuming they didn't have convenient plugins and an origin analog)

What if I do a <Custom Execution> in the notebox of the skill that applies the state w/ something to calculate the value 1st and put it in a v[ ]? Idk, I'm just trying to attack this issue from other angles...
 
Last edited:

caethyril

^_^
Veteran
Joined
Feb 21, 2018
Messages
2,219
Reaction score
1,629
First Language
EN
Primarily Uses
RMMZ
Looks like you found a workaround over here~
Just to mention: the only reason v[x] works to reference game variables in the damage formula is that v is explicitly defined as a local variable there, pointing to the data in $gameVariables.
 

Frostorm

[]D[][]V[][]D aka "Staf00"
Veteran
Joined
Feb 22, 2016
Messages
1,819
Reaction score
1,581
First Language
English
Primarily Uses
RMMV
Yes, how I can apply that method w/ any skill/state where I would normally use origin. Your help has been invaluable, thank you.
 

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

Latest Threads

Latest Profile Posts

My computer broke yesterday, so no RPG maker for at least a week until I can get it repaired. :(
Just wanted to share how my game won 1st place in a game jam for itch.io. Everyone else used Unreal, Unity, GMS2, Godot, etc but I used RPG Maker 2003 :guffaw: It just shows that you can create a good game and it doesn't matter which engine you use
Working on cutscenes~

if your game is the first (or ONLY) in a series and still has a colon in its title, you are a bad person and I hate you...... jk.

who could ever hate BETWEEN: TWO SOULS?

Forum statistics

Threads
107,405
Messages
1,029,444
Members
139,504
Latest member
lobsterknees
Top