feature Param Max/Min

[Tsukihime 1,423]

Feature: Param Max/Min

-Tsukihime

 

 

This script allows you to set a custom max and min limits on parameters on your database objects, which will determine the max and min parameters for your actors/enemies in-game.

 

Download

 

Script: Download here

Required: Feature Manager

 

Usage

 

Tag your database objects with

 

<ft: param_max param_type value>
<ft: param_min param_type value>

where param_type is one of

mhp, mmp, atk, def, mat, mdf, agi, luk

 

And value is some integer.

 

If you have multiple param_max features, then the largest of all features is taken for that parameter.

Similarly, if you have multiple param_min features, then the smallest of all is taken.

Edited March 30, 2016 by Tsukihime

[Rigor Mortex 2]

This works for the most part; there aren't any bugs (at least as far as I can tell). However, this part was left out:

 

Obviously, equipment and buffs would bypass an actor's stat cap; an example would be Timmy the Priest has a "natural" Attack cap of 500, but he can still equip a weapon that gives +200 Attack so the stat becomes 700, and you can still use a spell on him that doubles Attack to raise it to 1000 (or 1400, with the aforementioned weapon).

 

Equipment and buffs do not ignore the stat cap placed by the actor's class' note box. The only workaround atm I can think of with my limited scripting knowledge is to use a tag on a weapon or state to let the person equipping it or with said state break the cap placed by the tag in their class' box, but that would allow the actor to use (permanent) parameter-boosting items to go above the intended cap. If that makes any sense. Can you add this (poorly-worded) feature to this feature?

[Tsukihime 1,423]

Updated script, use

 

<ft: param_base_max param_type value>

 

To specify base limits (before equips, features, buffs bonuses)

 

While

 

<ft: param_max param_type value>

 

Is used to go beyond the existing limits.

[pinka 7]

This script works to set a limit on parameters, for example, you shouldn't be able to have more than 300 atk at lvl 99, is this correct? or am I missing something? Because when I use the param max feature, even if my character is lvl 1, it gets max stats.

[Tsukihime 1,423]

The default limits for most stats are 999.

 

This script simply changes the limit on how high the stats can be (regardless of level, however you can use conditional features to impose such a limits)

 

I should have fixed the bug where you are getting max stats though. Are you tagging it with something like

 

<ft: param_max atk 300>

 

?

[pinka 7]

No, i tagged it with this

<ft: param_base_max mhp 9999>

Now it's working. I would have a request. Is it possible to replicate the apeiron system in Final Fantasy X? What it basically did, was allowing you to break the normal stat limit for HP and MP, which was 9.999 and 999, allowing you to get to 99.999 and 9.999 when you had that weapon equipped.

Edited November 18, 2012 by pinka

[Tsukihime 1,423]

I would assume that's what the script does. Features on weapons are only applied when you actually equip it.

Edited November 18, 2012 by Tsukihime

[estriole 323]

if in actor we set the max hp to 999

and in class we set max hp to 9999

in weapon we set max hp to 99999

in armor we set max hp to 999999

and having actor with that class equipping that armor and weapon. do it takes the highest cap?

[Tsukihime 1,423]

Yes I took the largest cap rather than taking the smallest for the max.

[Rigor Mortex 2]

There seems to be a problem with <ft: param_base_max param_type value>

 

Here's what I have put in one class' note box:

 

 

<ft: param_base_max mhp 999>

<ft: param_base_max mmp 300>

<ft: param_base_max atk 900>

<ft: param_base_max def 440>

<ft: param_base_max mat 120>

<ft: param_base_max mdf 99>

<ft: param_base_max agi 496>

<ft: param_base_max luk 257>

 

 

 

Going by the spoiler'd information, one might expect that the character's max possible stats would be 999 HP, 300 MP, 900 Attack, 440 Defense, 120 Magic Attack, 99 Magic Defense, 496 Agility, and 257 Luck, and that they wouldn't affect the class' stats as they level (unless you set their stat growth to exceed these limits). However, what actually happens is that a character with this class ends up having the above stats at all times, regardless of what their stats SHOULD be at that level - equipment and buffs seem to work as requested, though.

 

Did I enter the tags wrong, or is there something messed up in the script?

Edited November 20, 2012 by Rigor Mortex

[Tsukihime 1,423]

I've corrected a math error. Should be fine now.

[Rigor Mortex 2]

New issue: The base tags don't seem to actually prevent their designated parameters from exceeding their indicated numbers.

[Tsukihime 1,423]

That's weird, my max HP can't go beyond 999 if I set <ft: param_base_max mhp 999>

[Rigor Mortex 2]

Alright, I THOUGHT I had found the problem, using my incredibly limited scripting knowledge.

 

One of the scripts I'm using is Yanfly Engine Ace - Adjust Limits v1.00. "YEA Adjust Limits" also uses " def param_max(param_id)", so I figured that was the issue. However, after removing said script, and doing another playtest where I increased a character's Attack, they STILL ignored the base limits I had set - the only difference was that their Attack wouldn't go over 999, since Yanfly's script was how I had bypassed the program's limit.

[Tsukihime 1,423]

Test it on a new project. When my character levels, it can't go past the base param limits.

[Rigor Mortex 2]

Test it on a new project. When my character levels, it can't go past the base param limits.

 

I've done it, and leveling up works perfectly fine, as you claimed it would. OOC, I decided to try leveling up on the original project with Yanfly's script active, and level-ups still functioned properly. The only things that remain are items that permanently boost parameters (like the Power Up item in the program by default), or events that boost parameters - I had been both to get closer to the limits I'd placed with your tags in a shorter timeframe, but when I ONLY leveled up, even if the database's parameter was set to 999, the tags would prevent them from exceeding the tag's limits. So it seems that items and events that permanently boost parameters (not just equipment) ignore the param limits your script's note tags place.

[Tsukihime 1,423]

Yes, that is expected. Param_base_max only restricts only "base" parameters, which is defined by the class parameters.

Everything else is defined by param_plus.

[Rigor Mortex 2]

I really hate bugging you, but is it posible to make it so consumable items that permanently boost parameters won't let you exceed the limit you use in param_base_max? At current, consumables sort of undermine the whole thing by letting you ignore param_base_max. One way I imagine it can be done is using a tag to identify parameter boosting items from other items, like ones that grant buffs (assuming of course this is even required and there's not a simpler method to get my desired effect).

Edited November 20, 2012 by Rigor Mortex

[Tsukihime 1,423]

How are you actually adding the stat bonuses from consumable items?

 

The default script tosses everything into something called param_plus, which includes stat bonuses and equip bonuses and buff bonuses. It may be simpler to just change where those stat boosts are going.

Edited November 20, 2012 by Tsukihime

[Rigor Mortex 2]

I'm adding them with the "Grow" effect under the Other tab. An example item would be Power Up, which permanently increases Attack by 2 of whatever actor you use it on.

[Rigor Mortex 2]

Bump for help?

Edited November 27, 2012 by Rigor Mortex

[Rigor Mortex 2]

Additional bump. I understand if you're busy, but I don't want anyone to think I've given up.

[Tsukihime 1,423]

I have thought about a good way to solve this problem, but so far have not come up with anything. Currently I'm looking for a way to separate equip bonuses from stat-growth bonuses, etc.

 

The easiest way is to just hardcode a solution for you, but then that hardcoded solution may not work in general (which means there may be script conflicts)

Edited December 2, 2012 by Tsukihime