Question: HP Plus / MP Plus Stacking

I don't actually have a save file available to check this, so I'm hoping one of you knows the answer.

So iirc you can stack HP Plus or MP Plus materia and the effect is cumulative somehow, but the exact math eludes me. So, for example, a one-star MP Plus grants you an extra 10% to your MP, so if your base was 100 MP, you would end up with 110 MP.

If you add a *second* one-star MP Plus materia, it would stack, but would it apply 10% to your base amount, or the adjusted total from above? Basically, would you end up with 120 MP or 121 MP?

Equipping the second MP- or HP Plus materia adds 10% based on your original base value, not to any newly set base since you equipped an MP- or HP Plus.

Here are the values I got just now when I confirmed this.


If a new base had been acquired after equipping the first HP Plus, then the formula would have been this when equipping the second:
1559 * 1.1 = 1714.9
From the experiment we know this not to be true. The original base HP applies.

Same result came when equipping MP Plus.


If a new MP base had been applied, then the final value would have been this:
248 * 1.1 = 272.8
As we can see, this is not the final value and so only the original MP base is applied in the actual calculation.


Additional about HP- and MP Plus, as written in Absolute Steve's guide.

HP Plus said:

Notes:
- The maximum additional HP that can be gained through Materia is +100%
- Extra HP Plus Materia over this will only help balance out extra negative percentage modifiers

Click to expand...

MP Plus said:

Notes:
- The maximum additional MP that can be gained through Materia is +100%

Click to expand...

Thanks Shademp! That was really thorough

Can't believe the game rounds it down. It's only 1HP difference but it seems odd that any sort of calculation would result in 1559.8 becoming 1559

From Terence Fergusson's FFVII Battle Mechanics Guide, in the section where he goes over the document's mathematical terminology:

[x]
The use of square brackets around a number - [3.5] for example - means that
the result must be truncated. That is, everything to the right of the
decimal point must be removed. For positive numbers, we call this rounding
down. Basically, [3.0], [3.5] and [3.8] would all equal 3, while [4.0] would
be 4. But [-3.8] would actually be -3, since we are truncating rather than
rounding down.

Click to expand...

Clearly then there are situations where FFVII rounds down (or rather, "truncates") to the closest lower integer with positive numbers, regardless of how close it is to the higher integer.


Though, from the same guide, there is a situation where the game supposedly rounds up regardless of the fraction.

The Turn Timer

Finally, the Turn Timer. This is the most complicated of the four timers,
since it is based around the relative Dex stats of the combatants.

First, we must find the normal value: the base Dex to be used for this
battle. This is calculated by taking the average *BASE* Dexterity of all
three combatants in your Battle Party, making sure to round up any fractions.
Finally, we add 50 to this average. We call this the Normal Speed.

For example, if you enter battle with Cloud at 31 Agi and Barret at 24 Agi,
then the Normal Speed would be:

Normal Speed = RU((31 + 24) / 2) + 50
= RU(55 / 2) + 50
= RU(27.5) + 50
= 28 + 50
= 78

Click to expand...

This fits with my overall impression of FFVII's internal machinery being a mess.

In programming generally calculations that are rounded to an integer will be rounded down.

This isn't because the programmers are choosing to round down. Instead it is the automatic truncation process that occurs when trying to store a result as an integer. Rather than doing a calculation to determine which way to round, it simply stores the integer part and ignores the rest.

This means that if calculations are working with negative numbers, they will be rounded up, so -2.5 would become -2.

JBedford said:

This isn't because the programmers are choosing to round down. Instead it is the automatic truncation process that occurs when trying to store a result as an integer. Rather than doing a calculation to determine which way to round, it simply stores the integer part and ignores the rest.

Click to expand...

I recently read about this and it helped finally explain why divisions didn't seem to work "properly" whenever I set my calculator to the "Programmer" setting. One will notice here that when making divisions in the Programmer setting, you never get fractions (and indeed, the result is always truncated).

When you make divisions, do you divide integers (whole numbers) or floating point numbers? Here's a short example: https://play.golang.org/p/Qci5v1wOF4

There are (some) programming languages that implicitly convert integers to floating point numbers when doing a division like that though, but it really depends on the ideas behind the language on whether that's expected behaviour or not. Javascript does it for example, but secretly it doesn't actually have integers, all numbers are floating point numbers. Which also means you can't express numbers bigger than 9007199254740991 (see hear
and here).