Kirb

So here is a problem I'm running into:

Let's say I have two different Status Values: MP, and OVERFLOW.

MP is a range from 0-100, and whenever MP reaches 100, the MP 'goes into' OVERFLOW, increasing OVERFLOW by 1, and MP lowering back down to 0 and starting over.

The idea is that every point in OVERFLOW is worth 100MP. Seems easy enough so far.

But here's where things get tricky. I'm trying to make the below scenarios work:

---

Scenario 1:

I have 5 MP, and 1 OVERFLOW. (So, 105 MP total) I lose 30 MP. But since I only had 5MP, and 1 OVERFLOW, I should lose that 1 OVERFLOW; and be left with 75MP, in this situation.

----

Scenario 2:

I have 80 MP, and 2 OVERFLOW. (So, 280 MP total).

I get damaged for 50 MP, and my MP goes down to 30MP, and my OVERFLOW is unaffected.

------

Scenario 3:

I have 90 MP, and 1 OVERFLOW (so, 190 MP total).

I gain 50 MP.

As a result, I end up with 2 OVERFLOW, and 40 MP.

------

Scenario 4:

I have 50 MP, and 3 OVERFLOW (so, 350 MP total). The Max amount of OVERFLOW I can have is 3.

I gain 80 MP.

As a result, since OVERFLOW is currently maxed out and I can't gain any more MP, I now have 100 MP, and keep my OVERFLOW at 3.

If I lose an OVERFLOW point, and gain 1 more MP, all of my current MP will go into a new OVERFLOW point.

------


I've tried to create a system within ORK where I can get something like this working (note: ORK does not like it when you have two status values being Barriers of each other), but I've run into a dead end, I think.

I feel like Barriers ALMOST get it for me, but lacks the two-way overflow mechanic required for it.

Any ideas?

UserName

Well in each attack abilities that consume MP, you call an event that checks for the MP of the user, I'm pretty sure all 3 scenarios can be achieved with a couple of check status nodes.

Megami

You could almost do this by just keeping all your MP in a single pool and setting up your UI so that it displays bars as units of 100 with the remainder in the final gauge, using a formula to divide up the total.

I'm experimenting with the way you outlined the structure to see what I can come up with. I'll make a tutorial post if I come up with anything that works in all the scenarios you posed!

Kirb

@UserName I've tried a bunch of different hacky solutions involving check status and Auto Apply/Remove Status Effects, etc etc, but none that quite get all four scenarios right.

@Megami

Yeah, that was same thought I had as well, originally. The biggest tricky problem is that the gauge for MP has to be the first bar to be filled, and to be depleted, before touching any of the 100MP 'units'.

It'd be super rad if you could help find a solution, it's been banging around in the back of my head for the last day or two. :D

Megami

@Kirb I've been poking at this and eliminating pathways that don't work for a while. I have a functioning workaround for diminishing MP so far, with a seperate MP management Event called as part of the Ability casting, and a second MP gauge that is barriered by the first.; It's not the most elegant and I haven't worked out the UI, but haven't tackled restoring yet. How are you doing on your research?

hellwalker

Can you do this with two formulas?
For example you could have two parent formulas

1) OF Damage (Add this to ability's status value change "OF Damage")
if Current MP - Damage < 0 Result = -1
So you lose one overflow if damages gets you bellow 0.


2) MP Damage (Add this to ability's status value change "MP Damage")
if Current MP - Damage < 0 then Result =100-Damage+CurrentMP
else Result = CurrentMP - Damage

So if damage get's you bellow 0, you get 100 (Total MP) - Whatever damage would slip past 0 MP mark. (100-Damage+CurrentMP)


And adding to Ability's Target Changes


Idea is you calculate and apply them separately. You could do reverse with adding MP.

Kirb

Thanks everyone!

@hellwalker

Super elegant idea! This method does definitely work, although I did have to make a few changes to fit it into my systems.

There's only one remaining problem that I can see with this solution, and that is when you have Zero OF, and your MP is brought below 0. With this current logic, even if I have 0 MP and 0 OF, and get hit for 20 MP, I magically get 80 MP. (And vice versa, when I have reached max OF, and reach over 100MP, it starts the gauge over instead of staying at 100MP)



So I added a quick condition:

IF Formula is Less than 0, AND if current OF !> 0,

THEN Set MP to 0. This would make the MP gauge simply be damaged down to 0 without restarting up at the top again.

------------------

However, because this formula is calculated seperately, the OVERFLOW formula has already completed; it thinks that OVERFLOW is currently at 0 instead of 1, setting MP to 0 instantly.

Any ideas on how to implement this check for bottoming out and topping off?

Kirb

Found a way for the Damaging Side of things:

At the beginning of the OF Damage Formula, I quickly store the value of the Player's current OF value. This ensures that the MP formula will be using the correct pre-calculation value.

Strangely, this method does not seem to work on keeping MP at 100 if OF is full. Will continue experimenting. :)

Edit:

Got it! Required some finagling and a few hacky tweaks, but it's in and works great.
Big thanks to everyone.

hellwalker

I'm glad I could help. Cheers!
Though for OF, would clamping the status value in ORK settings (Min/Max value) work?
After that I guess you could add checks in MP for Min/Max OF.

Kirb

Hmm.. I think I might still run into the calculation order issue. OF is gonna be an upgradable stat, so it would need to change dynamically with whatever the current maximum is, as well.

Pleased as punch to have it all working as it should and without needing to hack apart the UI as well. Cheers again. :D