WithinAmnesia
commented
2 years ago Will this work in ~1.13 / in the future to be compatible with fractional number % as in -1.5% MP Regen and or +37.3% HP Regen? Also in ~1.13 will movement speed also be compatible with fractional % values such as -0.7% speed? These are two major features that I need to build depth in my incredulously complex armour itemization system. I am sorry for for the 'bible' of a message but I want to make an effort to show where I am coming from :-P.
If fractional number % compatibility across all area such as -/+% MP Regen and -/+% HP Regen and -/+% movement speed can be implemented in ~1.13 (in near the future) the Flare engine can used to build more itemization depth with many equipped item types and classifications. Such as ~16 different 10 armour piece sets where say each piece can be further adjusted in the set and still be different compared to greater or lesser armour types. As in say -1.0% MP Regen on the Chest armour piece descending in 0.1 increments such as -1.0%, -0.9%, -0.8% etc 10 times, each increment per 10 armour slots to end with -0.1% MP Regen on say the Wrists. This is a deeper itemization system unlike the homogeneous armour slot set values version that I am using (as seen below) as a compromise / work around without fractional numbers and % values. One second, I need to further elaborate or else my point / perspective will not make complete sense if it is simplified in what I am doing with the armour sets:
I am using different materials that have ascending power / item level:
Descending Item Level (~1-100)
-
10-35 (22.5) Copper
-
25-50 (37.5) Bronze
-
30-55 (42.5) Brass
-
30-60 (45) Nickel
-
35-60 (47.5) Cupronickel
-
50-75 (62.5) Iron
-
30-80 (55) Silver
-
65-90 (77.5) Steel
-
25-100 (62.5) Gold
-
70-100 (85) Chromium
-
75-100 (87.5) Stainless Steel
-
80-110 (95) Magnesium
-
90-115 (102.5) Black Iron
-
70-120 (95) Aluminum
-
105-130 (117.5) Black Steel
-
65-140 (102.5) Platinum
-
110-140 (125) Bismuth
-
110-160 (135) Cold Iron
-
110-180 (145) Shadow Steel
-
Matthew Gordon Roulston 8:30 PM 21 / 08 (August) / 2021
1 Item Level = 1 Armour Base.
With each armour set having different armour values per slot of 10 armour slots:
Armour Slot Ratios:
10 - 12 Torso 9 - 11 Head 8 - 10 Legs 7 - 9 Hands 6 - 8 Shoulders 5 - 6 Waist 4 - 5 Shins 3 - 4 Feet 2 - 3 Wrists 1 - 2 Arms
With different armour types based on ~Armour Weight Type / Classification:
Armour Classification Ratio: (100 / 15 + None Classification) 0.00000 - 0 - None 0.06667 - 1 - Clothing 0.13333 - 2 - Light Cloth Armour 0.20000 - 3 - Medium Cloth Armour 0.26667 - 4 - Heavy Cloth Armour 0.33333 - 5 - Light Leather Armour 0.40000 - 6 - Medium Leather Armour 0.46667 - 7 - Heavy Leather Armour 0.53333 - 8 - Light Mail Armour 0.60000 - 9 - Medium Mail Armour 0.66667 - 10 - Heavy Mail Armour 0.73333 - 11 - Light Plate Armour 0.80000 - 12 - Medium Plate Armour 0.86667 - 13 - Heavy Plate Armour 0.93333 - 14 - Massive Plate Armour 1.00000 - 15 - Gargantuan Plate Armour
-Matthew Gordon Roulston 7:14 PM 21st / 08 (August) / 2021
Which works like multipliers of diversity in that I have 19 current Item / Armour Materials x 14 Armour Classifications x 10 Armour Slots = 2,660 Different base items I have come up with.
The problem is that with so much diversity / different base armour types I end up running out of whole numbers / integers. Yet if I can use fractional numbers I can better implement my paper / book concepts into Flare. Also I am lacking the ability to use -/+% MP Regen and -/+% HP Regen to simulate a penalty (or bonus) of having a full mana / resource pool but being exhausted after fighting / moving armour in heavy equipment and fighting exhaustion inside heavier armour types.
I work in the woods on mountains in British Columbia Canada and I had the experience of multiple times packing +150 Pounds of gear and equipment up a densely forested mountain side more vertical than flat for over a hour straight up then working a full day with huge logs and very heavy blocks of cedar and packing the gear back out for another hour down the mountain side.
It works out that you can 'store' energy / stamina and have all this weight on but as soon as you start working it is a battle against how much you can sustain your work / hiking pace, you rest / stop working if you over stretch / drain that literal real life regen pace and wait until you get your resources / stamina but up to work / keep hiking while burdened.
I wanted to put this same life experience into my RPG where heavier armour types reduce the wearer's resource % regen (-/+% MP Regen) the same amount for any weight class independent of material type (20 kg of Copper is the same as 20 kg of Steel) thus I used % and standardized armour classifications independent of material types. Also I wanted to push for 10 armour slots for I experienced out in the woods in hard labour that different pieces of equipment can be mixed and matched to better optimize for a day's work.
Such real life equipment weight optimization during hard labour can work out such as taking the hard hat off when stacking / swinging an axe to split blocks and or putting on heavy Kevlar bucking pants + full visor hardhat and ear muffs and work gloves and a visi-vest while wresting with a heavy chainsaw to cut big cedar logs.
Or even commonly using different cork boots for different work scenarios. Such as using light cork boots with less shin protection and a rubber toe to timber cruise / hunt for cedar logs in the forest hiking over a large area. Or like what I tend to use with wearing heavy cork boots with a full boot up and around the shin and with steel toes and bottom plate to work hard in a small area. All of this gear mixing works in real life and I wanted to include it in the 10 armour slots.
I hope to take a page from Tolkien and breath my life experiences into the spirit of my work. Yet in the current version of Flare I am struggling without fractional % numbers and -/+% MP Regen and -/+% HP Regen to translate those life experiences into the RPG in spirit. I would like to have fractional speed penalties such as -10.2% or -16.7% or -9.5% speed for the combined values from each base armour set and to not use -% Mana Pool but -% Mana Regen or ideally -% Arbitrary Resource Regen (for resources like ~Spirit, Mana and Stamina). Although even just -/+% MP Regen and -/+% HP Regen would solve my major struggles and would be wonderous. Yet this is the best I have done within the current version of Flare so far:
Within Amnesia's Complex Armour System 'Bible' (Gist, for as more reader convenience; thank Dorkster XD) https://gist.github.com/WithinAmnesia/1fdcfbddcbc97ca8eb1dabb0540581db
Thank you for reading this :-).
dorkster
Danimal696
Presently, we have the stats
hp_percentandmp_percent. And as expressed in this forum post, there's a desire forhp_regen_percentandmp_regen_percent. If we want to implement things like #1776, I think it would be a good idea to rethink how we handle these sorts of percentage bonuses."Bonuses" is important to keep in mind with these properties. You wouldn't have something like
stat=hp_percent,...in a StatBlock file, so I don't think they should be Stats. Instead, percentages should be part of the syntax for things like Itembonusand Powerpost_effect. For example: Instead of havingbonus=hp_percent,10, we could havebonus=hp,10%.Under the hood, every stat that can have bonuses would have additional storage for a percentage bonus. The order of processing would be such that non-percentage bonuses are added to the stat first, with the percentage bonus being calculated last. The pseudo code for this would be:
Example: The player has 50 base HP and has two items; one with
bonus=hp,20and one withbonus=hp,50%:This approach would have the benefit of giving percentage bonuses to any stat. Though we may have change how some bonuses are represented in game. Some stats are themselves represented as a percentage, such as accuracy and avoidance. If an item has
bonus=accuracy,5, it is displayed in the tooltip as+5% Accuracy. We'd have to drop the percent sign there and strictly reserve it for percentage-based bonuses.EDIT: Instead of having to drop the percent sign from stats that are represented in that way, we could represent a percentage bonus as the multiplier
(100 + bonus_percent) / 100. So a 5% boost to accuracy would be printed as "×1.05 Accuracy". I think I prefer this approach as it doesn't change the existing style, only extending it.Slightly related: EffectManager also has
hpot_percentandmpot_percent. These aren't stats, but similar logic could be applied.