Page 2 of 2 First 12
  1. #11
    Updates

    • [CoreRPG+] Modifier stack drag treated as standard number value.
    • [5E] Class features that grant specializations are added to character feature list, in addition to specialization choice.
    • [5E] Divine Favor spell effect override added for PCs.
    • [DEV] windowcontrol: Added onVisibilityChanged event
    • [DEV] windowinstance: onLockChanged handler changed to onLockStateChanged event
    • [DEV][CoreRPG+] Added buttongroup_tabs_h template for horizontal tabs that uses text or string assets

  2. #12
    Updates

    • [PFRPG/3.5E/d20Mod] Fixed default PC initiative ability not being picked up by initiative roll.
    • [5E/4E/3.5E/d20Mod] Adjusted effect performance improvements to not drop out early (per Kelrugem report above).

  3. #13
    Kelrugem's Avatar
    Join Date
    Sep 2018
    Location
    Geneva, Switzerland, and Lyon, France
    Posts
    610
    cool, thanks for the updates

  4. #14
    Kelrugem's Avatar
    Join Date
    Sep 2018
    Location
    Geneva, Switzerland, and Lyon, France
    Posts
    610
    I am afraid that I have found another bug. While updating my extensions for 3.5e I wanted now to implement the new changes in manager_action_save.lua and I see that aExistingBonusByType[sBonusType] is now used to handle stacking of bonus types for the SAVE effect (beginning in line 193), therefore it gets the value aExistingBonusByType[sBonusType] = v.mod and so on But this value does not get updated when there is an effect with a higher mod found, it is only the following code then
    Code:
    elseif v.mod > aExistingBonusByType[sBonusType] then
                            nAddMod = nAddMod + v.mod - aExistingBonusByType[sBonusType];
    Directly in the next line should be a aExistingBonusByType[sBonusType] = v.mod, too, isn't it? (such that the next save effects (if any) are treated correctly)

    I tried to reproduce the error: screenshot0008.png

    (Again here the problem of that the order in the for loop is unknown (to me) and therefore I added many many 4 enhancement bonus effects to force that aExistingBonusByType["enhancement"] = 4 Oh, and ignore the open character sheet, forgot to close it for the screenshot) As one can see one accidentally gets a bonus of 24 instead of 18 (10 enhancement + 2*4 dodge). The additional six points probably come from the second 10 enhancement bonus; since aExistingBonusByType["enhancement"] is not updated after the first 10 enhancement bonus it still compares other values with the smaller bonus of 4 enhancement (and only this is then subtracted, so 10-4=6).

    At least this is how I think the problem arises Maybe I am wrong about the source of the problem, but the bonus is now surely sometimes wrongly calculated
    Last edited by Kelrugem; October 15th, 2019 at 05:46.

  5. #15
    I think there is a minor error in the feat parsing for 5e. In the manager_char.lua file, function checkFeatAdjustments, only the first ability score adjustment actually takes into account the number entered for it. It parses the number out into the nAdj variable, and then uses tonumber(nAdj) to process the score change.

    However, in all of the remaining ability score adjustments, it parses nAdj properly, but always passes a hardcoded 1 for the score adjustment, and does not use the tonumber(nAdj). This makes it so the value is entirely ignored, and the only ability score adjustment possible is a 1.

Thread Information

Users Browsing this Thread

There are currently 2 users browsing this thread. (1 members and 1 guests)

  1. bojjenclon

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  

Log in

Log in