"Blessing" System

I'm working to add a "Blessing" System to my game.
Essentially, when a player prays at a shrine,
they are given the blessing of that shrine until they pray at another shrine, at which point they receive that shrine's blessing.

This would act as a permanent Buff to one of their stats, for instance, Praying at the attack shrine means the player has a
permanent buff for attack, but that attack buff would be lost if they pray at the defense shrine.

Is there any way to do this, with or without plugins?

This should be pretty easy. Make praying at the shrine an event that grants the player a state that isn't removed when resting. I think there's a plugin out there for this (Hime, maybe). This and all of the other shrines should also call a Common Event that removes all of the state's that all of the shines bestow before applying the new one. That should be all there is to it.

To be honest, I'd just create a slot for "Blessing" in the inventory. When the player "prays" at the shrine, I'd just have the game automatically put an item in their inventory and then equip it. "Strength Blessing". Then, you can also view its effects at any time from the equip screen. I'd probably have this equipment also "lock" into the slot so a player couldn't swap it out and mess with it.

It'd be easy enough to event it and to reserve a few slots of equipment for it.
<Player Prays At Shrine>
--Unequip Blessing A
--Unequip Blessing B
--Unequip Blessing C
--Unequip Blessing D
--Remove 999 Blessing A From Inventory
--Remove 999 Blessing B From Inventory
--Remove 999 Blessing C From Inventory
--Remove 999 Blessing D From Inventory
--Add 4 Blessing E To Inventory
--Equip Blessing E to Party Member A
--Equip Blessing E to Party Member B
--Equip Blessing E to Party Member C
--Equip Blessing E to Party Member D
<Blessing E Seals Blessing Slot>

That should be pretty easy, you probably need just one variable:
Since the blessing is permanent untill you pray at another shine, all you need to do is alter the character's parameters via a normal event at the shrine; in this event the first thing you do is to check the value of said variable; at the beginning of the game it will be zero, because all variables - as we know - start at 0, and also because at the beginning of the game you haven't prayed at any shrine yet.
We make a mental scheme of which shrine equals to which variable value (example: Shrine of Attack = 1, Shrine of Defense = 2, and so on...)

At this ponint the player reaches the Attack shrine, and gets a +10 ATK (just trowing in a random number), the variable takes value "1".

The game progresses and the player now reaches the Defense shrine. He choses to pray at the defense shrine, the event will see that the variable equals 1, so this means that the player has previously visited the attack shrine, therefore the games removes the +10 ATK bonus to the player, then grants him a +10 DEF bonus (again, random value), and this time the value of the variable will be 2.

All and all, your event should look like this (assuming we are praying at the Attack Shrine:


and that's it. There's actually tons of ways to do it with eventing alone, this is an easy peasy method, but for example if you want the permanent buff to increase depending on the player's level, you may add a second variable to multiply the buff for the player's level and then increase Attack by that value... that depends on how you want this feature to work :)

make a number of states, each adding a specific buff, plus another one adding the "resist state" trait negating the whole set, and itself.
your "praying" sequence would be to first add the negation (clean the set, and clean the negation) and then add the buff.
the order in which you add the negation is important, so add the resist to itself at the end.

that's called "multiplexing": you don't need 10 variables to store data, if you can do with 2, one stating where the data will go, and another one storing the data itself.
here, it's the same thing: you don't need a set of add/remove states if one of them can be used to remove the whole set, largely because it's designed that way (you made the system to only accept one state active at any time.)

Can I change my answer?