Arbitrary element type resistance as a statistic able to be modified by arbitrary primary attributes (also speed stat) about flare-game HOT 7 CLOSED

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...

from flare-game.

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

from flare-game.

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.

from flare-game.

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 :-).

from flare-game.

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

from flare-game.

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

from flare-game.

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'. flareteam/flare-engine@6307945 "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?

from flare-game.