LUA Variables change type if handed over between functions

[Mephisto]

Hi all,
I noticed that some variables tend to convert to a different type if handed over between different functions. For example. rRoll.nMod is an integer but further downstream in a roll it changes to a string variable and needs to be converted by "tonumber()" to an integer again. I'm curious what causes this behavior. Does anybody know? Am I making a mistake somewhere?

[damned]

This does indeed happen. Its not you.

[darrenan]

Could be you're making a mistake. LUA variables, in this case an entry in a LUA table, should only change type if it is explicitly set to a new value.

It's also possible that FG is changing these values between 'phases' of roll processing. However, nMod is a well-known field and should not be getting transformed this way. See the comment header at the top of manager_actions.lua in the CoreRPG ruleset for more details. Any fields in the roll structure other than sType, sDesc, aDice, and nMod must be included as string/string name/value pairs, and I believe if they aren't that they will be converted to strings. But again, nMod should be exempt from that.

[Moon Wizard]

This will happen during rolling; as the rRoll structure gets passed through the FGU asynchronous dice rolling system which only supports a single level table with string->string metadata saving. So, you have to make sure that anything you read from a rRoll structure could be just a string (instead of a number or boolean). Some of the fields that are used by default are already handled, such as rRoll.nMod. You can use "tonumber(x) or 0", or similar code to capture and convert back other data types.

Regards,
JPG

[Mephisto]

Thanks, that explains a lot! Indeed the nMod variable works fine but other variables are affected as described by you all.