Roll handling

[Varsuuk]

I am using MoreCore mostly for this - but while Debug.console() tracing I was confused when I saw that apparently the contents of rRoll members changed in "types".

If I am reading it correctly, I just wanted to better understand why and the driver for the change in case it is useful to understand (it is trivial to to number() the data I wanted as a number.

For example, within the registered "performAction()" handler, I call createRoll() and in there I log to console "rRoll":
Runtime Notice: s'SW) rRoll: ' | { s'aDice' = { #1 = s'd20' }, s'nMod' = #0, s'sType' = s'swthac0', s'aAttributes' = { #1 = s'ranged' }, s'sDesc' = s'Ranged Attack [ranged]' }

Then, at the next stop on the rolling train, onModHandler, I still see:
Runtime Notice: s'-- SW) roll' | { s'aDice' = { #1 = s'd20' }, s'nMod' = #0, s'sType' = s'swthac0', s'aAttributes' = { #1 = s'ranged' }, s'nThac0' = #19, s'sDesc' = s'Ranged Attack [ranged]' }

BUT then when the next log is printed, for onLandedHandler, rRoll looks like:
{ s'aDice' = { #1 = { s'result' = #13, s'type' = s'd20' } }, s'nMod' = #3, s'bSecret' = bFALSE, s'nThac0' = s'19', s'aAttributes' = s'', s'sType' = s'swthac0', s'sDesc' = s'Ranged Attack [ranged] Str bonus + 1' }

Notice that 'nThaco' when from = #19 to = '19'.

Like I said, I have no problems with this - just trying to understand what is being done so I can do better when working on it.
It appears the aDice and others were modified, besides just the number to string changes. Where can I read about this process in posts in case simpler than going through and sticking temporary "debugs" to trace and learn the flow.

Which, I am willing to do - I'm just not as used to a language/IDE where I cannot simply trace execution even if I have to remotely attach a debugger. Or one where I cannot do as easy searching across projects for method calls. Sublime so far has been decent for some lookups but not universally.

[Varsuuk]

Ah, right here at the start of my walk through is a clue:

manager_actions.lua


-- ACTION FLOW
--
-- 1. INITIATE ACTION (DRAG OR DOUBLE-CLICK)
-- 2. DETERMINE TARGETS (DROP OR TARGETING SUBSYSTEM)
-- 3. APPLY MODIFIERS
-- 4. PERFORM ROLLS (IF ANY)
-- 5. RESOLVE ACTION

-- ROLL
-- .sType
-- .sDesc
-- .aDice
-- .nMod
-- (Any other fields added as string -> string map, if possible)


I notice it seems to say that use-supplied fields should go in as a String->String mapping.
If that is where I should be, I wonder if I need to do explicit conversion tostring() if it is being converted against my intent already to string? ;)

[damned]

Note that these rolls were written over several years and some were written poorly...
Depending on where/when values are passed/received they may be converted to a string and you may have to convert it back.

[Trenloe]

Where can I read about this process in posts in case simpler than going through and sticking temporary "debugs" to trace and learn the flow.

Full details on the usual roll process here: https://www.fantasygrounds.com/forums/showthread.php?35531-Coding-dice-rolls-(actions)-in-CoreRPG

[Varsuuk]

Perfect, going to work through this so can better understand the actions going on underneath.


Right now, posted about my confusion on how to access a WindowReference field - which happened as I was trying to follow the logic of the mod handling.

[Varsuuk]

Full details on the usual roll process here: https://www.fantasygrounds.com/forums/showthread.php?35531-Coding-dice-rolls-(actions)-in-CoreRPG

PS: I posted a question on that thread regarding what needs to be done in general to allow "drag an drop" onto a target for a to-hit roll to work.


[EDIT] --> So as not to confuse folks - the applicable sections from the pinned thread were moved here as they went into to too much specific OOC material. But at the end you will see an attached file from MoreCore modified to work similar to my adapter thac0 script. So I could share what I learned.

[Varsuuk]

Thank you - will look at target actions - I am in living room - but will be back at it in 30.
[EDIT]: Heh - pressed pause on show 'cos curiosity was getting to me - yeah, verified that pass "true" in the call to MoreCore's add_roll_type() - I was pretty sure it was #2 ;)

#2 - Perhaps this is most at fault? I do not do anything to change draginfo. In fact ALL code that reference it is in one method ;). So I probably needed to do something to it (I at first read your "maintain" is "not change") and now I have a clue what to look for in other rulesets where the drag works. I'll look for how they interact with drag info and attempt to do something analogous.

[EDIT2]: So yeah, like I couldn't wait. I guess your "maintain" was the normal use of "not modify or blank at least" because 3.5 and 5E both had the only appearance of draginfo in same place as mine:



local sCmd = "swthac0";


function onInit()
CustomDiceManager.add_roll_type(sCmd, performAction, onResultHandler, true, "all",
onModHandler, "button_roll", onTotalHandler)
end


function performAction(draginfo, rActor, sParams)
Debug.console("performAction")
if sParams == "?" or string.lower(sParams) == "help" then
createHelpMessage();
else
local rRoll = createRoll(sParams);

local nodeSource = ActorManager.getCTNode(rActor)

if not nodeSource then
nodeSource = ActorManager.getCreatureNode(rActor)
end

-- Thac0 is always present and given a default when adding to the CT if not.
--
-- Documentation on CoreRPG manager_actions indicates that the preferred was to
-- pass arguments is via a string->string mapping.
rRoll.nThac0 = tostring(DB.getValue(nodeSource, "thac0"))
Debug.console(rRoll)

ActionsManager.performAction(draginfo, rActor, rRoll);
end

end



Of course the roll I based this on "thac0" from MoreCore, I could not get to drag-drop so at least I didn't bork anything PROactively ;)

[Varsuuk]

Running it with extra logging shows me the problem is that performRoll or whatever is not used. It starts from ModHandler then ResultsHandler.
Since I put Thac0 in the initial Perform thing, it is not saved anywhere and it is not present at the Mod/Results point.

So, it made "design sense" for me to put it in the preparation section because I had source available. It seems maybe my problem is as simple as I need to do all the work in onResults handler? So then in performAction I should JUST create the die roll and nothing else (or please let em know any other tips on things to also do here if they apply)

Going to try rearranging it.

---------------

EDIT: Nevermind - I just tried it and remembered why... the FIRST time rolling, the source is there with target as well. When we drag, the rSource is not present so I cannot grab Thaco from that. Hence why I thought I could stick it in dice at top.

Going to try looking at 5E again, drag drop obviously works there. They cannot be getting the "to hit" from source.

[Trenloe]

I don't want to do specific in-depth code troubleshooting in a generic thread.

What is your whole custom action handler file? When an action is dropped on a target in the combat tracker, the CoreRPG handling takes over to roll the action and then calls various handlers registered in the custom action script - modHandler, postRollHandler, resultHandler, etc.. So make sure that you have all of the relevant post roll scripts setup correctly to actually run and process the results of the roll.

[Trenloe]

Going to try looking at 5E again, drag drop obviously works there. They cannot be getting the "to hit" from source.
5E works differently - the "to hit" is the total of the d20 roll, which is compared to the AC of the target. The total of the roll is available in the result of the action in the chat window.

The usual way to make data available for later operations is to embed it in the action description - usually inside square brackets [...] So maybe you could put the original actor THAC0 in the attack description - for example: [THAC0 19] and then parse that out in your result handler.

[Trenloe]

And maybe as you're using THAC0 etc. it would be better for you to look at the 2E scripts rather than 5E? You'll see that THAC0 is put in the attack result description in the format: [THAC0(19)] along with the actual AC that the roll result hits, e.g. [AC:9 ]

I don't know which of these is then used to determine the result of any subsequent drag/drop action - in theory you can use either to calculate hit/miss, but I think (without looking at the code) that THAC0 is used.

[Varsuuk]

Cool - I am thinking 5E did help me there. I just finished going over it and realized it has nothing to do with "setting up drag". As you also indicated but I came to before seeing these last two updates.

I need to add to the roll.desc things I need in later drop to recalculate the hit/miss and any other side effects.
This is because ResultsHandler (yes, I added a Results, Mod and Total handler (though as of yet only print stuff in there)) is serving double duty. 1. It has all the source info the first time and it needs to determine the things you need from source, if any. Then it is called again and now will fail all "if rSource" checks and instead it must grab things from rRoll.desc.

So to be somewhat useful here, for drag-drop: When the ResultsHandler is called the FIRST time, it must store the date used that was dependent on SOURCE in like rRoll.desc so it can be there for the second time ResultsHandler is called. This is because the second call rSource is nil.

I'll edit this after I get it working to give example to anyone reading this how to translate the existing thaco roller in MoreCore to work with drop. Heck... maybe I can also attach it to this post for example. I am not working exactly with that file, but my additions will easily transfer to it since mine is 90% same as the original.

MUCHO Thankaroonies.

[EDIT 1]: While watching The Magicians, I got it to work :) now just have to gussy up the printed message on the "drop" version and once I do will update example. Most likely very late night since dinner/family stuff coming (was off today)

43405
Looking at 5E I made a slight mod:
43410

[EDIT 2]: Attaching the modified THAC0 script from MoreCore to support drag/drop (left lots of comments in --[[]] meant to be REMOVED after but just for info. I figured it would help those trying to get drag-n-drop working if they had a non drag-n-drop setup more if they saw what it looked like PRIOR to the modifications as well.
https://1drv.ms/u/s!AnwhQ1k_7ppfnd0rsh8Xv4v7mJlMdw?e=fQoFN9

[damned]

well done Varsuuk