Generic Actions - V1.95 - Bug - default INVACT usage where nothing followed the keyword did not support the "~". Fixed. As in "+*Dagger; INVACT: ~; INVACTR" - to insure thrown ranged weapon of this name match would consume from inventory and the melee version would not but require it to be present. V1.94 broke how CT limited effects were deactivating effects while an action performed (was doing all of them after the - prefixed effect appeared). Fixed.
I looked through this thread and didn't see anything pop-out and tell me that it was removed for some reason, but when I went to obtain the following file, I get an Error (doesn't exist): "5EAEcorrections.mod used for corrections or GAL additions I've made to overlay 5EAE modules that I use. Must remove old custom effect duplicates - there can be only one."Quote:
Originally Posted by SilentRuin
Is that file no longer needed? Thank you in advance SR!
Forgot that line was even there I have not updated it - the real links are here...
https://www.fantasygrounds.com/forum...l=1#post762948
That's where I went, and it still says the 5EAECorrections.mod has been deleted.Quote:
Originally Posted by SilentRuin
Sorry about that. All the other links were good on that page I must have screwed that one up. Fixed.Quote:
Originally Posted by SmackDaddy
Added that post reference with the drop box links (as long as they remain valid) to bottom of page 1 also.
Note on my 5Ecomponent.mod (also in as story in that module):
This module has all the supporting data I needed in my games for Generic Actions extension support of components (with help from Equipped Effects extension of course). Many of the INVACT spell components that are consumed (no ~ prefix) require the 5EAEcorrections.mod corrections of those spells so that only ONE action (effect/attack/save) is triggered for that name match. Otherwise, each matching named action on that spell will decrement an inventory item - which is to many. So this will NEVER work for all component consumption spells that give more than one action - at that point you should just use ~ prefix on INVACT components to make sure they are just verified that they are there and not consumed - or don't define anything for that spell. For now "good enough" for ones I play with as I don't yet know how to solve that problem. Using INVACT with inventory consuming components is RISKY as you have to have only one name match triggered or it will decrement to many inventory items.
To be delivered next week.
https://www.youtube.com/watch?v=IppLQdVOVSk
Due to new powers in AOE effects, among other things in my current campaign I wanted implemented, my dropbox files have all had new entries put them and/or changed. Not a big deal if you don't use these or copy from them - but figured I'd give a heads up that they have been getting updated on a daily basis of late.
https://www.fantasygrounds.com/forum...l=1#post762948
Generic Actions Layers - V1.64 - Update - If there is no GALVISIBLE effect present, and its not an NPC GMOnly CT entry - a token asset will be placed as a bitmapwidget and move with the token - otherwise it will be a map layer asset. Everything that can be a token widget asset will be a token widget asset - anything that cannot will remain as it was - a map layer. Map layers on token drag have new issues I need to prevent so no longer process click down to remove map layer assets (click release and end drag will do this now) - this was causing issues that are not easily fixed so just going to leave asset behind when a token is dragged with a map layer until it ends and the asset is deleted and replaced at new token's position. A bitmapwidget will still be dragged without suffering this "asset left behind" though temporary graphics (attacks and the like) will be left till drag ends unless a click release had cleared them earlier. Why GAL does not use timers to remove temp assets. A new option "Asset: If Carrier orient on move option will change asset orientation as moved for widgets (Can be slower)" defaulted to "off". If Carrier extension's orient on move option is one the assets (that are visually directional) will also orient as they are dragged - this can slow things down somewhat as this updated of token assets can happen frequently during moves and changes in direction.
This is a significant change to GAL. Will be letting users test this out though I have tested it on the portion of my live campaign map that pretty much made me realize map layers for moving tokens was even worse than I ever thought. Read further if you want the details on why GAL is changed...
The new GAL will no longer be attempting to delete map layers on a button down - this was to keep them from their assets from being left behind on a token drag. The risk for hitting the delete layers bug wiping out token notifications is too severe even if it rarely happens in slower processing areas with a lot of light/fx/los (as in my disastrous campaign last night). There is no good solution. So expect moving tokens to leave the asset behind till you stop moving at which point it can safely delete it and move it to the tokens current position. Most map layers will be replaced with bitmapwidgets where possible, in which case all tokens with widgets will have visible assets dragged and oriented with them on drag end. Just an FYI as this was such a seriously hard pain the neck to figure out - and a disaster to have happen. Only solution if you encounter it in current version is to turn off lighting which makes the window between when the delete layers starts and finishes a lot smaller meaning it will finish before token starts dragging and won't kill all its notifications to others what its doing.
Tip for GAL:
If you want something that is still being displayed as a map layer to be displayed as a bitmapwidget then you just need to make sure it does not have GALVISIBLE on it (usually found in Object in custom effects of the AE5E and corrected data that I use) and that it is does not have a GAL NPC named effect that is set to GMOnly. The change will be immediate. But the effect will not be visible on the client's side if the actual CT entry is still marked invisible. Which is the default for all GAL placed NPCs. The whole purpose of the GALVISIBLE was to allow an invisible NPC to still show the map layer graphics on the client - which bitmapwidgets are not capable of doing (they cannot disassociate from the CT entries visibility). If you don't actually place any GAL NPCs or use anything that sets GALVISIBLE indirectly and remove that keyword (Object custom effect for me) - then ALL your GAL assets will be displayed as bitmapwidgets. For sure the default GAL NPC named effect is not GMonly so removing any GALVISIBLE effect entry keyword from a GAL placed NPC will make it a bitmapwidget.
Just FYI.