CustomDie definitions

[deer_buster]

Is there anyway to setup a Die or CustomDie definition that causes one of the dice macros (e.g. 1d100l5 or 1d100e96) to execute?

For example, if I wanted to add a explode low onto the d10 custom radial menu, or just wanted the d100 die out on the table (I discovered adding the d100 adds the 00-90 die 3D model to the table...nice) to have those options.

Also, when double clicking the die on the character sheet, how do we define the draginfo to have those work?

[Moon Wizard]

No, there's nothing like that for die/customdie definitions. If you wanted to do something like that, you would do what Rolemaster does, which is add a special icon to the desktop to drag which spawns the correct roll. It's an interesting idea for future considerations.

For immediate use, you would need to call dragdata.setDieList(<dice expression string>); and then call Comm.throwDice directly.

The workflow for using the new dice subsystem still needs to be worked on in both CoreRPG and client for CoreRPG flowthrough. The dice expression functionality is more of a long-term improvement that will be worked into the existing systems over time. Plus, all the ruleset code has to work in conjunction with FGC; which doesn't support expressions, die modes and other improvements.

Regards,
JPG

[deer_buster]

So a lot of Interface.getVersion checks are going to be integral to implementing new capabilities, unless a ruleset is solely post-FGU

[deer_buster]

I've added it to the wishlist...

https://fg2app.idea.informer.com/proj/?ia=128493

[deer_buster]

I guess I'll need to hold off on what I am doing anyway until you get FGU-411 fixed

[UngainlyTitan]

What about as a stopgap, add die macros to a character sheet.

[iiivsion]

Hi, testing MoreCore at the moment, the changes to dragdata are big enough to urge a redesign of the rolls I guess. I found that "some" dragdata are deprecated and as far as I understood dragdata.setDieList(<dice expression string>)/getDieList ist the way to go. Is there a good description of the changes/future design/strategy to this? Perhaps one could write a LUA abstraction layer, that "tanslates" old dragdata<->new dragdata, so that we could include it and run it at a central point to make conversion instead of cluttering version checks all over the place? - OK, think I found what I was looking for: https://fantasygroundsunity.atlassia...63662/dragdata

[damned]

FGU output looks like this:

s'onDiceLanded draginfo: ' | dragdata = { type = s'explodingDices', desc = s'Bomber Banjo', #slots = #1, slot = #1, string = s'', num = #0, diceexpr = {4d6}, dice = {4d6|d6=6=6|d6=4=4|d6=1=1|d6=3=3}, shortcut = {}, asset = {, instance = }, custom = { } }

FGC output looks like this:

s'onDiceLanded draginfo: ' | dragdata = { type = s'explodingDices', desc = s'Bomber Morgana', #slots = #1, slot = #1, string = s'', num = #0, dice = { { d6 = 6 }{ d6 = 3 }{ d6 = 3 }{ d6 = 5 } }, shortcut = { }, token = { prototype = , instance = }, custom = { } }

so instead of getting
dice = { { d6 = 6 }{ d6 = 3 }{ d6 = 3 }{ d6 = 5 } }
we got
dice = {4d6|d6=6=6|d6=4=4|d6=1=1|d6=3=3}

All the same data is there but we are going to have to update the rolls that use that in the MoreCore version...

[iiivsion]

How stable is that behavior? Does it make sense to regard it as the new fixed format and work with it?

@damned, thank you for pointing me in the right direction again; the problem is not so much with the draginfo, but with the format of dragdata.getDiceList:
[4/30/2020 1:24:37 AM] { #1 = { s'value' = #10, s'type' = s'd10', s'result' = #10 }, #2 = { s'value' = #2, s'type' = s'd10', s'result' = #2 }, #3 = { s'value' = #6, s'type' = s'd10', s'result' = #6 }, #4 = { s'value' = #7, s'type' = s'd10', s'result' = #7 }, s'expr' = s'4d10'}
New is that the s'expr'-Part is within the list of dice, which is not a dice and has no value, type or result. From a design aspect, I would have rather expected a {list of dice}{dice-expression}, so a table in a table.
Nonetheless, both broke some code and I could guess one have seen the chosen implementation as the "lesser evil" since it would still work if a check for valid dice is made and invalid dice are simply dropped. So that would also be my suggested fix: Add a check that will remove invalid dice data structures when reading the data. I'll still have to check how it is solved in '/exploding', my guess would be the list is read in a more robust way.

So good news:
Fix of the /rnk and the other legend-rolls from ikael can easily be made and are backwards compatible, only one file to change.

I attached an extension holding only the one changed file in desktop/scripts/morecore_ikael_dicemechanics.lua, so you could either patch that one file or activate the extension to get the fixed rollers and the additional 7th sea math attr+skill[k]skill-Rolls. You are free to take over any code-changes from me and do whatever you want with it. Please contact me if there should be any issues, I'll try to fix it.