Purpose of $game_party.in_battle instead of scene_is?(Scene_Battle)

This is just mere curiousity of me. If you want to check if it's on the battle, would not that be easier if I you call SceneManager.scene_is?(Scene_Battle) instead of set the $game_party.in_battle to true? Is there any purpose of this? Or maybe it's something related with Action Battle System? I haven't look into any ABS scripts

I would like to hear opinions on why EB making the default script structure like this :)

I think that it's a convenience method, 'SceneManager.scene_is?(Scene_Battle)' is longer than '$game_party.in_battle?', especially when the current scope is within $game_party itself (you just drop the $game_party). Honestly, there are a lot of throw ups on why Enterbrain did certain things (like overwrite the core object method #class in Game_Actor...I can't stand that one).


A second possible reason was that EB was thinking long term about people writing scripts, and the structure needed to reflect this. RMXP is notorious for being difficult to edit / add scripts to, because of how clumped up the code is (aka they could have split certain methods down to two, sometimes three or four, different methods). For this reason, RPG Maker VX and Ace have a lot more...habitable code...I think that's the word for it? :p


For instance, what if someone wrote a multiple party manager, where the player could manage more than one party of actors. Meanwhile, there is another script constantly checking if the battle scene is up, and if so, deplete the HP of all actors in battle (idk, some poison effect or something?). While this seems not to be a compatibility error, if we use

then all of the parties' actors will lose HP. However, if we hold the property @in_battle for every party, only the ones with that flag set to true will deplete HP. See the difference?

To me it makes sense to expose a method to check whether the party is in battle.


If you want to check if a battler is alive, would you simply check `battler.state?(DEATH_STATE)`?


Would it be easier to just check the scene?


Maybe, but it's less modular and makes a lot of assumptions.


But then again the code base already does make a lot of assumptions (and some of them are pretty obvious at times) so it would be difficult to imagine why they decided to make some things better and some things not.

FenixFyreX: I like the second reason. Also, think of battle systems with a scene that isn't called Scene_Battle. Extensibility, as you've already said, is a good reason (actually XP's default scripts have that method, too).

I see... It's makes sense if the scope itself is for Game_Party and its instances.

Though, my question came up when I saw it's been used not only for Game_Party itself. But also in Game_Interpreter, Game_Actor to perform collapse effect, and Yanfly also used it in his Battle Engine. So check the Window_SkillList spacing. I also used the method to disable something in other class / module. Then, like cremnophobia said,... how about a battle system which is not called in Scene_Battle? They may toggle the $game_party.in_battle to true. In this case, why not checking scene class instead?

I can overcome if EB overwrite #class for Game_Actor just by making alias in class its superclass like

class Object  alias :ori_class :classendThen when I call $game_actors[1].ori_class it should return Game_Actor. So, for me it's not big deal.