FG Spreadshirt Swag
Page 5 of 6 First ... 3456 Last
  1. #41
    Quote Originally Posted by Zygmunt Molotch View Post
    update: I'm still getting the same error with 1.1 and 4.1 of token_height

    that of course doens't mean it this ext
    Have you tried with only FullOverlay and Token height?

  2. #42
    ~~will report soon~~

    -- well we seemed to have sorted this out, will post in the other threads
    -- Aura did come in handy for that function then
    Last edited by Zygmunt Molotch; June 2nd, 2021 at 16:29.

  3. #43
    One thing I have noticed with FGU is that the lua reader is persnickety with spelling and capitalization. Combatmanager and CombatManager are two entirely separate functions. If someone has otherwise replaced the latter with the former, the latter will no longer work for those functions. First thing I would do is to make sure that I don't have unzipped rulesets (that may be prior versions) in my rulesets directory. Then I would go through every extension xml file and check to see if any of them overwrite the manager_combat.lua script and see what the callout name is to see if they changed the capitalization.

  4. #44
    Quote Originally Posted by DCrumb View Post
    One thing I have noticed with FGU is that the lua reader is persnickety with spelling and capitalization. Combatmanager and CombatManager are two entirely separate functions. If someone has otherwise replaced the latter with the former, the latter will no longer work for those functions. First thing I would do is to make sure that I don't have unzipped rulesets (that may be prior versions) in my rulesets directory. Then I would go through every extension xml file and check to see if any of them overwrite the manager_combat.lua script and see what the callout name is to see if they changed the capitalization.
    That is also the case with Classic. LUA is case sensitive.
    This is not the case here, however. You can clearly see in the script error that properly-capitalized "CombatManager" is nil.

  5. #45
    bmos, I wasn't meaning from your script. I was meaning in any of the other extensions that were loaded. If another loaded extension changed the calllout LUA might have gotten confused on which script to run.

  6. #46
    After the latest rules update I had an idea on how to incorperate fog cloud an similar:
    [CoreRPG+] Add VISMAX and VISMOD effect tags to specify maximum vision of visions and modify ranges of limited visions. (FGU)

    Ok, so if I have a token to represent the center of the fog cloud I could do an aura effect on it:
    LIGHT: 20/20 darkness
    AURA: 20 all; VISION: 5 truesight

    Ok so the LIGHT effect is to cover the area since you only see 5 feet into the fog. But the darkness light does not allow us to see anything inside.
    Next AURA effect to fix this. Truesight lets us see 5 feet in darkness.
    So in theory this can represent fog cloud an similar spells perfectly.

    But there is a problem. VISION effect does not work after "FROMAURA". This means that the aura effect gives my token with darkness light truesight 5 feet, but everybody else that comes into the radius and gets the effect FROMAURA: VISION: 5 truesight does not get 5 feet of truesight.
    Is this aura extension not compatible with LIGHT, VISION, VISMAX, and VISMOD effects?

  7. #47
    SoxMax's Avatar
    Join Date
    Mar 2021
    Location
    Massachusetts, USA
    Posts
    154
    It should work with the new effects, I wonder though typically people structure their auras with a name after the AURA portion like this:
    AURA: 20 all; Cloudvision; VISION:5 truesight
    I think you may have stumbled upon a bug/oversight with the core functionality, I'll take a look.

    EDIT: Just did some quick testing, yea that's definitely the problem. Assign the vision aura a "name" and it should work. And this is affecting other effects as well.
    Last edited by SoxMax; June 3rd, 2021 at 23:10.

  8. #48
    Quote Originally Posted by SoxMax View Post
    It should work with the new effects, I wonder though typically people structure their auras with a name after the AURA portion like this:
    AURA: 20 all; Cloudvision; VISION:5 truesight
    I think you may have stumbled upon a bug/oversight with the core functionality, I'll take a look.

    EDIT: Just did some quick testing, yea that's definitely the problem. Assign the vision aura a "name" and it should work. And this is affecting other effects as well.
    I think that is intentional as it helps find the right effect. I've added it to the readme.

  9. #49
    Very nice gentlemen. I appreciate the work you have put into this.

    Question - A lot of the negative effect auras allow a saving throw to negate the effects of the aura. Is there an option for handling this in the extension?
    Either an option to allow a save to ignore the effects of the aura?
    Or the ability to permanently remove the 'FROMAURA' effect. Based on my testing I can remove the 'FROMAURA' effect from someone but if they leave the area of the aura and re-enter it the 'FROMAURA' is applied again.

  10. #50
    Quote Originally Posted by dllewell View Post
    Very nice gentlemen. I appreciate the work you have put into this.

    Question - A lot of the negative effect auras allow a saving throw to negate the effects of the aura. Is there an option for handling this in the extension?
    Either an option to allow a save to ignore the effects of the aura?
    Or the ability to permanently remove the 'FROMAURA' effect. Based on my testing I can remove the 'FROMAURA' effect from someone but if they leave the area of the aura and re-enter it the 'FROMAURA' is applied again.
    That's a really good suggestion!
    There is nothing at the moment, but I am sure there must be a good way to implement this.

    The easiest implementation would be to stop the aura from being removed if it is already there and is set to off.
    This would also keep it from being re-added and, since it's disabled, it wouldn't impact the character that has the effect.

    The workflow for users would be:
    * Ask for saving throws upon the effect being added.
    * GM turns off the effect for those who saved.

    It would certainly also be possible to have saving throws automated, although the development time would be many times longer. It would also have a lot of edge cases as some saving throws may be required every time the character enters the aura or just once per casting of the aura.

Thread Information

Users Browsing this Thread

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

Bookmarks

Posting Permissions

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

Log in

Log in