Arbitrary element type resistance as a statistic able to be modified by arbitrary primary attributes (also speed stat)

[WithinAmnesia]

Hello, I think there might be a game side or engine issue for primary attributes and how they modify the statistic of arbitrary element type resistances [also with speed]; for example:

From elements.txt "[element] id=chaos name=Chaos"

For example in stats.txt (this does not work): "#resistances

stat=chaos_resist,0 [nor "chaos" instead of "chaos_resist"] stat_per_level=chaos_resist,0 [nor "chaos" instead of "chaos_resist"] stat_per_primary=constitution,chaos_resist,1 [nor "chaos" instead of "chaos_resist"] stat_per_primary=perception,chaos_resist,2 [nor "chaos" instead of "chaos_resist"] stat_per_primary=intelligence,chaos_resist,3 [nor "chaos" instead of "chaos_resist"] stat_per_primary=charisma,chaos_resist,1 [nor "chaos" instead of "chaos_resist"]"

I pulled the 'X[element here]_resist' from the empyrean campaign with items like: [from level_4_unique.txt] "[item] id=91 name=Goblin Branch flavor=Mana flows inside its primitive exterior. INCLUDE items/base/weapons/melee/club.txt equip_flags=mental level=4 quality=unique price=500 dmg=ment,25,30 requires_stat=mental,6 bonus=dmg_ment_min,20 bonus=dmg_ment_max,20 bonus=mp_regen,10 bonus=_lightningresist,10"

Also speed does not work [my guess is with the 0.1% thing but I am unsure]. I would like to have decimal fractions such as 0.1%, 0.2%, 0.3% etc. from https://github.com/flareteam/flare-engine/issues/1784 .

Example: [from stats.txt] "#speed!

speed=7.5

stat_per_primary=strength,speed,0.1

stat_per_primary=agility,speed,0.3

stat_per_primary=constitution,speed,0.2

stat_per_primary=charisma,speed,0.1"

Also here are some relevant files of my prototype to look through: Engine: stats.txt primary_stats.txt damage_types.txt elements.txt Menu: character.txt Images/Menus: [renamed as "character.png" in Images/Menus]

Extra: Does -X_resist work as a negative resistance penalty / lower resistance? I am having issues testing positive resistances. So I am still curious as to what is possible with negative resistances and the Flare Engine. For example if there is any use for having +150% X Resistance in an element with a 90% Resistance cap? As in could be possible that this 'wasted' +60% X Resistance (from 150% capped to 90%) could possibly combat / mitigate out a say a -50% X resistance penalty (by a possible 'reduce X resistance penalty / enemy power)?

Situation A. On one hand I could see the capped 90% X Resistance (with 150% capped to 90%) being 90% -> hit with -50% res -> 40%. That just seems wrong for that would make no reason to have anything above 90% Resistance.

Situation B: On the other hand if it went (150% capped to 90%) 90% -> hit with -50% res -> (150% -50% = 100% capped to 90%) 90%. That would seem right and would still give a reason to be 'over cap' on resistances.

I am just not sure if situation A or situation B is taken into effect with the current Flare Engine. I am wondering what happens with the Flare Engine and 'over cap' resistances verses -50% resistance penalties. Also I am curious about the outcome of these interactions and what that means for game design with the Flare Engine. Here is my current prototype combat.txt to observe combat.txt .

[dorkster]

Elemental resists are missing from the stat, stat_per_level and stat_per_primary properties. There's the vulnerable property, which is the inverse of resist. So setting vulnerable=fire,75 would be the same as if stat=fire_resist,25 worked. And conversely, vulnerable=fire,125 would translate to stat=fire_resist,-25. I think the vulnerable property should be deprecated and we should only work with resists to keep things consistent. I'll work on fixing this so that all the stat properties work as expected.

I may have to double-check, but I'm pretty sure the total resistance with bonuses and debuffs is calculated before applying the cap. So you should get "situation B".

Speed is a different story. Its bonuses are not done like all the other stats. Currently, it's a percentage modifier. So if you have a base speed of 7.5 and have an item with bonus=speed,200, the calculated speed will be 200% of the base: 15. This may change with the changes planned for 1.14, but I'd have to figure out how to make it forwards compatible with existing game data.

[WithinAmnesia]

Oh thank you. I should have checked in on this earlier and not at ~4:30 AM at night / morning XD.

Okay that sounds good that supposedly ~'Situation B' should work / play out. I wonder how to show 'over cap' / 'extra resistance' like total resistance and cap resistance. I know that the floating tool tip with primary stats shows base and bonus. I wonder what could work if there is a sort of ~'hidden' over cap resistance amount. I know that some games require lots of out of game detective work just to start playing effectively. Although I would prefer if the player in game could ergonomically / intuitively / within reason / find important data / info like how the rest of the Flare style character stat menu is easily informative. As if there is any possible missing relevant resistance info if it could somehow be displayed like 'over cap %' or something to that effect to help human readability / ease of use / quality of life.

I did not know how the speed stat value was calculated; thank you for teaching that :-). What possible options are there (within reason) for speed to be able to be modified like a stat with primary attributes / help fit it into itemization? Do you have ideas that come to mind and how they interplay with the existing game / legacy data?

Game design theory for using numbers: Whatever could be possible, it might be a good idea to use a simple to understand yet powerful to design with base 10 system of some kind; such as 0.001 to 100.000%. I find that whatever system is used, that common people like ~'human readable' / intuitive numbers / a simple way of displaying data. For example I try to use base 10 / sets of 10's in anything I do to help people use their common sense and have it better translate to understanding the fine details of the whole picture of the video game / medieval fantasy setting.

Also I find that people readily understand what 1%, 2%, 3% etc. and 0.1% 0.2%, 0.3% etc is without too much clunky loose brain arithmetic. Also for stacking values (especially anything small or under effectively ~1,000,000 values) I try to use values that are base 10 or easily dividable / common global cultural values; like base 10 or half of that as increments of 5. For example most people who have internet access can count fast in increments of 1 (1, 2, 3, 4 etc.) and increments of 5 (5, 10, 15, 20 etc.), with 2 also sort of working (2, 4, 6, 8, 10 etc.). Also with increments of 10 (10, 20, 30, 40 etc.) and anything like 1 or 5 and also 2 with more zeros on the end (like 50 or 1,000 or 500,000 or even 20,000 etc.). Yet people tend to struggle with ~'weird number sets / increments'; like anything away from 1, 5 and 2. Such as 14x13, 47x7, 13x8 etc. . That is my current understanding / why I favour using increments of 1, 5 (and sometimes 2), 0.001 to 100.000% and to avoid 'clunky numbers' like anything not close to being directly base 10 and derivatives of base 10 like 5 and 2. Also anything over the ~100,000's and most people start to just 'blank out' as the numbers get too big to think quickly / 'within reason' and just become 'number bloat'.

0.001 to 100.000 seems to be a sweet spot where the numbers function big numbers but act like small numbers for common sense. Anything such as or past 0.0001 and 100.0000 and the 'blank out' starts kicking in and it becomes 'number bloat' not before long. So to keep the numbers ~'human intuitive' / mentally ergonomic for most people base 10 is great, increments of 1, 5 and sometimes 2 also are good, stick to numbers within 0.001 and 100.000 for %, try to stay within the 100,000's to keep most people's brains from 'blank out' and to keep away 'number bloat'. I hope that makes sense and can help people make their work run smoother :-).

[Danimal696]

Ok, so my boars are resistant to ice but weak to fire: vulnerable=ice,75 vulnerable=fire,125

It becomes?: stat=ice_resist,25 stat=fire_resist,-25

[dorkster]

@Danimal696 Correct. The vulnerable property will still work for the time being, but it's recommended that you update to the new syntax.

[WithinAmnesia]

How do I get this to work in 1.13? (Note: I also got the fog of war working with 256x128 tiles). It looks legal yet I am not sure why the ~'stat_per_primary=perception,furore_resist,2' is not working? The relevant files are the same as above minus fixing a format for chaos to be the same format as the rest like 'chaos_resist' instead of some lines from earlier testing being just 'chaos'. https://github.com/flareteam/flare-engine/commit/63079456d1c962f680ac212d47c247ffa4752019 "Elemental resistances can now be used with 'stat', 'stat_per_level', and 'stat_per_primary' in StatBlock definitions." it should work though, am I missing something?

[dorkster]

What you did looks correct. I see now that this feature is broken in 1.13 :/ Working on a fix now...

[dorkster]

I've uploaded the fixed binaries to Github. It was a very minor fix, so I didn't bump the version. Just grab 1.13 from the release page again and it should work.

Now to go upload to itch.io/Sourceforge and fix some Linux packages...