5E - Capital Gains

[bratch9]

Regarding the merits, or lack thereof, of various design decisions. I do think it important to call out that CG doesn't use global variables. It does use local variables to represent object state, albeit in a manner that is similar to stack memory. Of course, I don't need to explain to someone with a C++ background how local and global variables couldn't be more different. As for the nature of the primary variable itself, capturing object state in a local variable is fundamental OO design. I know some folks have strong opinions about OO in general, though I think it's safe to say the ship has sailed on that discussion in the context of FG.

Of course in an ideal world the ruleset code itself would be more SOLID, which could certainly mitigate the necessity of jumping through some of the hoops we have encountered. That will continue to improve as it has been, I'm sure, so maybe some day an alternative solution to the current situation with more simplistic presentation will be viable. Until then, I'm going to stick with this style of solution wherever necessary, as the primary alternative of adding function parameters along the entire stack is much more likely to cause conflicts.

On the difference between your use of a local global to pass custom values and adding parameters..

In a normal product it would be a poor design ( you would change the full source code. ), but in this case of extension API it is probably better than passing extra variables to replaced ruleset functions. Because rulesets and other extensions are not written to cope with the extra parameters.

It would be different if the ruleset used the '...' by default, ie 'function parseEffectComp(s,...)' and always passed the '...' to sub function calls to default that all functions by design should consider the possibility of extra parameters and the need to pass those about.

BUT since the ruleset does not use the '...' by default, I do think your global version with increased compatibility is the better design than passing parameters.

-pete

[bratch9]

Hey folks, sorry for the delay on response. I'm out of town for the holiday.

When I get back next week I can certainly address the bug with ration loss not working as intended as well as bump the load order.

Also, thanks for the "..." reminder! I too often forget about that due to C-based trauma.

As for formatting suggestions (in no particular order):
The asterisk is technically optional, so feel free to exclude it for "2CURRENT". I find it to be beneficial when reading complex effect blocks to break up longer chunks, especially with decimal numbers.

I'm not immediately a fan of the proposed notation for including dice inside the effect. And given that it is not similar to any ruleset representation (in fact [STR] d6 works (sometimes)), well, I'll give it some time to grow on me before committing either way.

The use of a ":" in the effect was to avoid nesting scope notation with () and [], since that seemed like it would be cumbersome for most users. The colon matches natural language a bit closer for what is being represented. I think I'll leave this one to a vote, both here as well as asking my players. Though I should clarify that if a change is made it will be to support putting the dynamic notation (bullets 3 and 4 from the first post) in brackets to calculate and replace when the effect is added, so a multiplication factor would live inside the parenthesis.

Resources with spaces in the name are already supported by design, so if that's not working in some context it's a bug I'll happily fix.

I think I'll change the dynamic notation to have the multiplication factor in front of the resource name, which with the optional nature of the syntax will support "-Resource Name".

Comma delimiting inside the SPENT block could be useful, though I have a gut feeling that it would be such a niche case that it may not justify the complexity of the code, since the same outcome can presently be achieved with multiple blocks. I'll give it some thought.

My suggestions are just suggestions. As you say you have reasons for how they are encoded, and I gave suggestions and reason for mine. Your users can make suggestions and maybe you will implement or not.

On the dice encoding after the [] section, dice.PNG are the 5e ruleset responses to the different types. By default neither of the '[] d6' or '[]d6' evaluate to a valid 'DMG: line'

Which is why I suggested and implemented in my extension the value been inside the '[]' section. To the ruleset this still parses with the default code.

ie, [2CHA6] would parse into '2 *' the lookup for 'CHA6' which would then fail to lookup due to the 'elseif sTag == "CHA" then' which would not map it and so would be correctly skipped due to the ruleset 'nil' check.

I dont know in what 'cases' these 'sometimes' work?

But as you say, how you want to encode the token structure is upto you on this. I can only make suggestions.

-pete

[Kelrugem]

My suggestions are just suggestions. As you say you have reasons for how they are encoded, and I gave suggestions and reason for mine. Your users can make suggestions and maybe you will implement or not.

On the dice encoding after the [] section, dice.PNG are the 5e ruleset responses to the different types. By default neither of the '[] d6' or '[]d6' evaluate to a valid 'DMG: line'

Which is why I suggested and implemented in my extension the value been inside the '[]' section. To the ruleset this still parses with the default code.

ie, [2CHA6] would parse into '2 *' the lookup for 'CHA6' which would then fail to lookup due to the 'elseif sTag == "CHA" then' which would not map it and so would be correctly skipped due to the ruleset 'nil' check.

I dont know in what 'cases' these 'sometimes' work?

But as you say, how you want to encode the token structure is upto you on this. I can only make suggestions.

-pete

You have to write: DMG: d6 [2CHA] First the dice, then tags, the space after d6 will be interpreted as an addition. If you want to add damage types, then DMG: d6 [2CHA], slashing and so on

Or are you speaking about using 2CHA as the number of d6 you want to use? (here: the 2*CHA mod will be added as a modifier to 1d6)

[bratch9]

You have to write: DMG: d6 [2CHA] First the dice, then tags, the space after d6 will be interpreted as an addition. If you want to add damage types, then DMG: d6 [2CHA], slashing and so on

Or are you speaking about using 2CHA as the number of d6 you want to use? (here: the 2*CHA mod will be added as a modifier to 1d6)

Yes I'm only talking about the 2CHA becoming a number of dice of a dice type not a basic addition of value. Which is used by the CG extension to generate flexible dice amounts, see image in link

As I said by default 5e ruleset does not support this and we were talking about the merits or not of encoding this as either '[2CHA]d6' as per CG or as my extensions do as '[2CHA6]'.

My feeling was that the '[]' should be self contained as the 5e ruleset would see [2CHA6] as looking for 2x 'CHA6' which would fail but would still process the rest of the DMG type line. While '[2CHA]d6' breaks the parse process and stops. Both are going to cause failures to evaluate but in different ways. My point was that its very simple to have a 'space' that is hard to spot so '[2CHA] d6' and '[2CHA]d6' causing different results. While [2CHA6] is very specific if more 'cryptic' because you are not listing a 'd<n>' descriptor.

It comes back to a lot of the match type codes do searches for the likes of 'ends with ']'' which an encoding of '[2CHA]d6' breaks as now it end with ']d6' when tokens get split by ' ' separators. If you split by ' []' list of tokens to split with then the processing code is different because you are looking at start token '[' a number of tokens and then end token ']'. which is very different code to match("[(^])") { I'm sure I've got that wrong from off the top of my head, for starts with '[' and give me everything upto the end of ']' } type lua match searches used around the code and effect parses.

But how the encode works and is adjusted is up to CG, I was only making a suggestion to keep everything in the '[]' as this feel more in the spirit of the '[]' generation to 'something' exchange process of the effect line.

-pete

[rhagelstrom]

Just a my .02. If you go with [2CHA]d6 instead of [2CHA6] then you can leverage EffectManager5E.evalEffect to eval the brackets for you

[bratch9]

Just a my .02. If you go with [2CHA]d6 instead of [2CHA6] then you can leverage EffectManager5E.evalEffect to eval the brackets for you

As shown in #22 see image Dice.png the '[2CHA]d6' does not evaluate in the default 5e ruleset.

I'm not sure if the ruleset has an option to enable this parse process or if its an extension in use that allows this change ?

But my testing show, and seen in the image attached above, that the default ruleset does not process that construct. Which is why my extension added support for '[2CHA6]'.

-pete

[bratch9]

I've updated advanced spell damage and seems to be evaluating the CG effect lines and clears up the initial script error when character is open.

It does require CG to load after ASD, so I'd request a change to <loadorder>120</loadorder>

-pete

[MeAndUnique]

Just released version 1.0.3 which increases load order and fixes a bug with periodic resource loss.

[anathemort]

Thanks for your rapid attention on this, MeAndUnique! Happy to report I have updated and all is well now

[Tabarkus]

Thanks, I've been planning a 'survival' type adventure campaign and this extension will be very useful. I have a couple of requests, I'm not a coder so I don't know how practical these requests are so take them with a grain of salt.

Can you make the Resource section operate as a "drop down menu" like other sections do where you can minimize the space taken up on the Actions tab?

Can you have the Resource usage also reduce the Inventory count of things like Rations and Waterskins?