5E - Capital Gains

[MeAndUnique]

Version 1.0.2 released which relocates the resource action menu item for compatibility with the CAE extension.

[nephranka]

Version 1.0.2 released which relocates the resource action menu item for compatibility with the CAE extension.

Does this also address spell info ext conflict as well. Thanks.

Edit: nevermind just saw the other thread. Thanks!

[Tabarkus]

Can this extension be used to automatically manage rations and water as resources on a long rest?

If I configure it to Gain a ration on a long rest it adds it properly, but if I configure it to Lose a ration on a long rest I get a "Handler error: 240: attempt to perform arithmetic on a string value".

I can configure the Gain using negative numbers and it subtracts properly.

[bratch9]

I've had a look into the reported conflict with ASD, reference Conflict with ASD

Because these extensions change a number of power and effect blocks of code this is a significant conflict. ASD totally replaces some of these functions, due to code changes mid way into the functions, making the inclusion of the full functions a requirement and not possible to call the original.

The reported error can be resolved by moving the CG extension to a higher load order, so that most of its functions that call into ASD replaced ruleset functions will work. But it still causes the evaluation effects function to fail.

This is because 'evalEffect' in ASD adds extra parameters and so also does not call the original function. So when CG is loaded at its current point its 'evalEffect' does not get called so it does not resolve the 'SPENT' value in the effect. And when its loaded higher this fails due to not knowing about the extra parameters and so these get dropped and that breaks the ASD 'evalEffect' function.

I can probably look further into the exact function flow for the 'evalEffect' and it might be possible to resolve this part at my side, but it would require CG be loaded at a higher priority for the other parts to function.

Could I request CG change its load order to > 110, and I'll look into the evalEffect evaluation fail, and see if I can patch in calling some of the CG code to exchange this about.

-pete

( Again I noticed CG using globals to jump things over functions, which is not a good design. But I understand its use.. Its why ASD has extra parameters to functions to pass these about which is also causing conflict issues, and is also not a good design for compatibility. Neither ways are good designs but I dont see a good way without dev ruleset changes to the effects systems to allow parameter extensions. I'm not sure if the big release due in december is going to move effects down into coreRPG and allow per rule modifications. Since the effect system started in 5E and has been pulled about into most other rulesets, its probably due a refactor into coreRPG. I've not looked at the 'test' branches to see how 'broken' extensions will be. This might be a good broken time for me to adjust how ASD works. )

[Kelrugem]

This is because 'evalEffect' in ASD adds extra parameters and so also does not call the original function. So when CG is loaded at its current point its 'evalEffect' does not get called so it does not resolve the 'SPENT' value in the effect. And when its loaded higher this fails due to not knowing about the extra parameters and so these get dropped and that breaks the ASD 'evalEffect' function.

I just skimmed through your message, but one should be able to cater for possible additional parameters of other extensions by using ... That is as in

function onInit()
   OldevalEffect = ScriptName.evalEffect;
   ScriptName.evalEffect = evalEffect;
end

function evalEffect(Old/typical variables, ...)
   local blah = OldevalEffect(Old/typical variables, ...);
   Remaining code
end

Observe the ... in the function (I mean one has to use the dots, literally) If I am not mistaken, with that one can cater for any additional parameters from other sources but depends of course always a bit on the context etc., especially if the new variables are not added at the end of the base variables, then it will probably not be possible. But I hope you get the idea In the best case MeAndUnique just has to add the dots after increasing the loadorder

I hope this helps, but I just skimmed the post

[bratch9]

I just skimmed through your message, but one should be able to cater for possible additional parameters of other extensions by using ... That is as in

function onInit()
   OldevalEffect = ScriptName.evalEffect;
   ScriptName.evalEffect = evalEffect;
end

function evalEffect(Old/typical variables, ...)
   local blah = OldevalEffect(Old/typical variables, ...);
   Remaining code
end

Observe the ... in the function (I mean one has to use the dots, literally) If I am not mistaken, with that one can cater for any additional parameters from other sources but depends of course always a bit on the context etc., especially if the new variables are not added at the end of the base variables, then it will probably not be possible. But I hope you get the idea In the best case MeAndUnique just has to add the dots after increasing the loadorder

I hope this helps, but I just skimmed the post

Thanks for the info, was not sure on the '...' capture of extra variables and how to pass them in lua. ( I'm more a c++ person, so those end up in vargs to process. )

When I get some time I'll add some debug output and try and track down the failing point of the evalEffect. ( I've got some changes in my extension I should resolve and check into git before I get too far into debug this issue. )

Its also possible that the 'format' been odd is causing the issue...

I'm testing with 'DMG: [2*SPENT:ki]d10' and I'm not a fan of the 'd10' been attached but outside the '[]' control section. So its possible I have code looking for '^]' ending a token in ']' which is now seeing ']d10' and not spotting the end of the token..

I'm also not a fan of the use of '*' for multiply. As far as I recall its possible to do [2CHAR] to get 2xChar bonus as a value.

And I'm not a fan of ':' in the [] section for the spent as its the marker for command. I'd prefer to see a () section more like other effect items like 'size(>m)' construct.

In my other extension I can generate dice which the normal effect [] section can not. But I added the dice type as an optional at the end. So [2CHR] => '2x char bonus' would become [2CHR6] => 2xChar bonus of d6...

As a suggestion I'd prefer to see the 'DMG: [2*SPENT:ki]d10' looking more like 'DMG: [2SPENT(ki)10]' as this follow more the ruleset decode structure.

Also the likes of 'ki points' does not work due to the space, and with the () section it would be easy to grab that block and trim start/end and maybe split by ','. To add support for the likes of 'SPENT(ki points, bonus)' for it to convert to 'ki point + bonus' pair of resources. ( with even maybe pre-fix '-' to allow negatives to interact. )

-pete

[anathemort]

I second pete's formatting ideas. Those elements of consistency would be a great enhancement!

[MeAndUnique]

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.

[MeAndUnique]

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.

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

We clearly have a different definition of 'global' then.

In 'manager_effect_cg.lua", your use of 'bReplace' is a global. It is set in 'evalEffect' and this calls 'evalEffectOriginal' and during some point of the 'evalEffectOriginal' function it will call your intercepted 'parseEffectComp'. In effect you are passing this around as a global.

Variables outside of a function scope or parameter list are the definition of 'global'.

Just because you choose to consider 'local bReplace = false;' as not a global because it is local to your script does not change the fact it is a global variable.

ie,

local bReplace = false; -> is a lua script 'local' global. ( You will get a per script instance of this variable. )
bSomething = false; -> is a lua system wide global which can be accessed by other scripts. ( You will get a single instance of this for the game. )

Just clearing up what I consider a global.

-pete