Carrier Extension (Fantasy Grounds Unity 5E Ruleset)

[SilentRuin]

Carrier Extension (Fantasy Grounds Unity 5E Ruleset) (https://forge.fantasygrounds.com/shop/items/615/view)


Jump aboard a vehicle and move as a single group!
This stand-alone extension for Fantasy Grounds Unity allows a host to create a "carrier" link between different "carried" combat tracker PC or NPC entries. When the CT "carrier" map token is rotated or moved (host or client) all of their "carried" map tokens move or rotate with it. This includes any "carried" items that are also "carriers" themselves.

You can also give a "carried" PC or NPC combat tracker entry the action links if their "carrier" is an NPC (host). A default position will be assigned to a "carried" token around the "carrier" though holding shift will allow the "carried" token to be repositioned (host).

This extension unlocks the following functions:

Drop combat tracker (CT) entry name you want to be "carried" onto another CT entry or its map token that you want to be its "carrier" (host).
Any "carried" map token will move or rotate when its "carrier" map token is moved or rotated (host or client).
A "carrier" CT entry will have a list of "carried" CT entries with button options (host):

Make PC or NPC carried item invisible or visible independent of CT visibility.
Make carried token immobile (default), a driver (anytime it moves or rotates it does same to its "carrier" and any "carried" it has), or free (does not require holding shift key) repositioning.
Lock a "carried" item (default) so the "carried" CT entry cannot dismount or remove itself from the "carrier" (lock applies to host or client).
Remove a "carried" CT entry from the "carrier" CT entry.

A "carried" CT entry will have one button option (host or client):

Remove a "carried" CT entry from the "carrier" CT entry if the "carrier" has this "carried" CT entry unlocked.

If the "carrier" is an NPC then it can drop its action links (expand actions in CT entry) onto its "carried" CT entries (host). This allows the "carried" CT entry to execute that action with its targets while still having it applied by the "carrier" CT entry. Only a "carried" CT entry can remove an assigned action (host).
Client will only show owned or same faction as current logged in PC (identity) "carried" (actions and remove button shown only if owned) or "carrier" (no buttons) CT entries.


Updates:

[See .txt file for full list of updates and features]

V1.12 - Update - setting a carried or carrier which is not visible on CT will not show its buttons when made visible on CT. Usually only using combat groups and dragging a name onto a token not currently displayed in CT can cause this. This can now be displayed correctly by closing and opening the CT window.

V1.14 - Bug - need to update carrier data when groupvis of combat tracker changes. This will fix the workaround of having to open and close host window to fix the missing carrier buttons.

V1.15 - Update - changed all default options to what I want as I got tired of updating them all. Users can turn them off now if they don't want them.

V1.16 - Update - implemented node and childList changes to code that SW wanted.

V1.17 - Update - supported vehicle class as much as possible in the same manner as npc class.

V1.18 - Update - A Vehicle carrier CT entry link for a component can be used by dragging the link and dropping it onto a CT entry carrier tokenfield (in CT entry for carried or carrier) or dropped onto a valid map token (will then appear in carried CT entry under its carrier entry). It will add all the actions for that component. Same as could previously be done with an NPC or Vehicle CT entry link for traits, actions, Lgd Actns, LairActns, Spells, etc.

V1.19 - Bug - running a local client would have ownership detection issues - changed check to be with Session.UserName instead of User.getUserName() so the correct login user would be returned for comparison with owner when the client is running on same machine as host.

V1.20 - Update - when using "Set Common Initiative for carried entries (menu rolls only)" set to "on" it will always guarantee that the initial roll never has duplicates before it forces these common init settings. This prevents scrambled CT entries when they shared a common init roll.

V1.21 - Update - new driver option called "follow" has been added. If set you can hold shift to position carried token in some reasonable follow distance position then when the carrier moves any carried entries with the follow setting will follow in its path. This is only for single file following. Though you can have carried token defined as carrier token (with non following carried entries itself) set to follow. If you set toggle the driver option off of "Carrier follow" then the next time you move the carrier it will have all tokens snap back to their original positions based on normal carrier behavior. Best to just drop the double click the drop all carried entries token (see tooltip) if your going to do that. Per my usual standards - its good enough. Use or don't use it as you see fit. See details in .txt file.

V1.22 - Update - option "Orient token along direction of movement" defaulted to "off" will allow token orientation to be set from direction of movement as the token moves.

V1.23- Update - changed icon for "Carried follow" to be one from the CoreRPG so it would be more generic. Carrier is supported only in 5E no other ruleset. Specifically I do not support it in rulesets I don't use, for example - like 3.5E, 4E, CoreRPG, PFRPG, PFRPG2, and SFRPG. Just like my Map Parcel extension only supports 5E. Nothing else will be mentioned on this subject.

V1.24 - Bug - fixed an error due to unguarded nil. Made sure the CT visible eye icon is in synch with the CT Carrier Carried entry eye icon so both would set token visibility and carrier carried entry visibility properly.

V1.25 - Bug - At some point PCs entries in the CT stopped being able to have generic CT buttons on the clients effect them. As Carrier has such buttons I've had to force the addHolder/removeHolder of the CT's ownership when a PC is activated or deactivated myself.

V1.26 - Bug - V1.24 introduced a bug that caused a recursive call to corrupt a window on player side. Fixed.

V1.27 - Update - "Carrier; SKIPTURN" will only be applied when Carrier carried eye icon is toggled to invisible not when CT entry eye icon is toggled to invisible. That way carried entry can be made invisible without applying SKIPTURN to it.

V1.28 - Bug - stupid cut/paste error resulted in error at line 1422. Fixed.

V1.29 - Bug - with common init option the order was never really changing even though numbers generated were unique. This was because the number sample was generated based on random 20 and on large CT counts this was not a large enough random number sample to change the order. Now when common init option is set that init random number generator is based on current CT count so that sample is large enough to get unique numbers and change the order randomly. As usual with common init option you will see init much higher (if lots of CT entries visible or not). The CombatManager2.rollRandomInit code override is shared between carrier and combat groups extensions.

V1.30 - Bug - needs to be aware if common init from combat groups is in effect so it does not mess up that order. Fixed.

V1.31 - Deprecated Code - Deprecated legacy functionality I still use has been moved directly into the extensions which removes the deprecated errors. The new CT (client/host) does not easily support what I need to do and don't have time to figure it out, so for now just sticking with old way of doing things until something makes me do it differently.

V1.32 - Update - using local client confuses User.getIdentityOwner(sIdentity) calls so have to check for nil and then use sIdentity.sUser in order for it to get the local machine name (user). Only relevant if your using a local client like I do for testing. Will be part of next delivery version as this is just for me.

Watch video, read everything, understand what it is your getting BEFORE you hit the buy button. ALWAYS!

For support, please join the Grim Press Discord server: https://discord.gg/grimpress.

Extensions = RISK: This note is added to all the extensions I maintain. I want users to understand that extensions are code that is added to or overrides portions of code in the Fantasy Grounds Unity (FGU) application. When the underlying code in FGU changes it can break an extension. When you run with other extensions they can conflict by trying to overwrite the same parts of the FGU code. I will keep my extensions working with FGU changes, and the extensions I use (listed in my FGU signature) as I have direct control over those things. I cannot make the same promise with other extensions. If I am notified of an incompatibility I will attempt to resolve it - but if I cannot I will list what the known extension incompatibilities are. Understand before you get any extensions that it comes with RISK. Not just my extensions - any extension. These extensions are also maintained by me for me. I provide them outside of my own games purely to those who wish to take advantages of things I use for myself.


https://www.youtube.com/watch?v=jy2K_LBU45g

Details and full version changes (when page 1 runs out of space and is truncated) are in the .txt file linked to this page.

Note: Carrier logic will not work on the client without the host map up and running.

[ghen]

I'm already going to use this. As soon as it's available. I have a "pet" that will attach to a player but not take any commands from them. What an excellent idea and implementation. Of course it'll have the normal SR quality.

[SilentRuin]

I'm already going to use this. As soon as it's available. I have a "pet" that will attach to a player but not take any commands from them. What an excellent idea and implementation. Of course it'll have the normal SR quality.

Just waiting on approval I'll update link when the forge link becomes operational.

[SilentRuin]

Carrier Extension (Fantasy Grounds Unity 5E Ruleset) (https://forge.fantasygrounds.com/shop/items/615/view)

It's available.

[nephranka]

Thanks for this. I have been looking for a way to handle mounted combat.

I was testing this ext and found that when this ext is loaded with JFreitas' Stealth Tracker ext, the two do not work together. It took some time for me to narrow it down since it did not throw an error nor warning. It just fails silently. I did post to his thread about this as well.

[SilentRuin]

Thanks for this. I have been looking for a way to handle mounted combat.

I was testing this ext and found that when this ext is loaded with JFreitas' Stealth Tracker ext, the two do not work together. It took some time for me to narrow it down since it did not throw an error nor warning. It just fails silently. I did post to his thread about this as well.

No idea what that is. May just be incompatible - but thanks for noting it here. I'll add it to page 1. Noted in red there. My tester had 50+ extensions with no conflicts FYI.

[SilentRuin]

I've just been told by MrDDT in discord with his 50+ things that it works fine with it. So I'm removing it as a conflict for now. No idea what your seeing as you both can't have it working and not working if your using the same versions.

[MrDDT]

Thanks for this. I have been looking for a way to handle mounted combat.

I was testing this ext and found that when this ext is loaded with JFreitas' Stealth Tracker ext, the two do not work together. It took some time for me to narrow it down since it did not throw an error nor warning. It just fails silently. I did post to his thread about this as well.

I see a picture listed here with no error or anything wrong or done. What the issue? I just tested it both ST and Carriers is working fine. Plus my other 50+ exts. Can you give us a run down of what the issue is?

[SilentRuin]

I shall share the current session I'm running in SW5E that when I was working on it was "this is a pain in the..." and poof - extension time. I had 5 players on a ship that needed 3 of the players to control weapons on the ship (one of them would control the ship also) while 2 fought off a stowaway in a separate map. Solution was Carrier Extension. This let me have the ship to ship combat map have the ship carry all 5 players - allowing them to target the other ships with the weapons (actions) shared to them and also have the other two fighting on an internal map of the ship where the 3 players at station were represented as a screenshot bitmap overlayed of them sitting at their control seats (represented as combat group token on the map). That way as the turn progressed through each player they would be in the map they were operating in during their turn - then next turn - the action would move to whatever map that player resided in and I could have a seamless flow of the game through two perspectives (large ship combat and micro personal combat on ship). May not make much sense to those who don't use my extensions but this was reasoning to do this extension. When done with internal ship combat they just go back onto the map as carried entries (likely I'll make them all invisible)

52386

[SilentRuin]

Thanks for this. I have been looking for a way to handle mounted combat.

I was testing this ext and found that when this ext is loaded with JFreitas' Stealth Tracker ext, the two do not work together. It took some time for me to narrow it down since it did not throw an error nor warning. It just fails silently. I did post to his thread about this as well.

I had MrDDT try to create a new carrier link on a hunch and it indeed does not work when this extension is used with it. I'm pretty sure the problem is that this other extension is returning a true on the on drop code when it should not be - which signals all other ondrops processing that drop to cease and desist when returned true. As I respect that return code, and don't process my stuff if coming out true - like FGU ruleset code does - it won't allow you to create the link. I could break the rule on my side and process it when it says not too via the return code - but I think I'll just wait and see what the author of that extension does about it. If I have to break that rule I can, but for now I'm not going to and leave it as it should be. If another custom or override drop tells me "I've done the processing don't touch it" then that's what I'll do. Even if it means I don't function.

[nephranka]

I had MrDDT try to create a new carrier link on a hunch and it indeed does not work when this extension is used with it. I'm pretty sure the problem is that this other extension is returning a true on the on drop code when it should not be - which signals all other ondrops processing that drop to cease and desist when returned true. As I respect that return code, and don't process my stuff if coming out true - like FGU ruleset code does - it won't allow you to create the link. I could break the rule on my side and process it when it says not too via the return code - but I think I'll just wait and see what the author of that extension does about it. If I have to break that rule I can, but for now I'm not going to and leave it as it should be. If another custom or override drop tells me "I've done the processing don't touch it" then that's what I'll do. Even if it means I don't function.

Ok. With no errors just a failure to create a group, I was unsure of which one (maybe both) was causing the issue. Sorry I was not clear on the failure initially and thanks for looking into it.

[SilentRuin]

Ok. With no errors just a failure to create a group, I was unsure of which one (maybe both) was causing the issue. Sorry I was not clear on the failure initially and thanks for looking into it.

I'm told from the other thread that this has been fixed and verified by the other author. You may now go back to your normal life with extensions...

https://www.youtube.com/watch?v=8CtjhWhw2I8

[nephranka]

I'm told from the other thread that this has been fixed and verified by the other author. You may now go back to your normal life with extensions...

https://www.youtube.com/watch?v=8CtjhWhw2I8

I will not adjust my television set! Thanks!

[SilentRuin]

Bug where if you have an enemy carried and carrier visible on the Client CT (I know crazy right? Why would anyone let a foe be seen in CT when it can go in and out of LOS at anytime and be gone - except from crazy DM's clients player CTs - something I never thought to test myself - as combat groups will always have players only see same faction set in my games) will generate an error at line 650 of my code.

Fixing now.

[SilentRuin]

Bug where if you have an enemy carried and carrier visible on the Client CT (I know crazy right? Why would anyone let a not same faction be seen in CT when it can go in and out of LOS at anytime and be gone - except from crazy DM's clients player CTs - something I never thought to test myself - as combat groups will always have players only see same faction set in my games) will generate an error at line 650 of my code.

Fixing now.
Fixed.

V1.1 - Bug - if an enemy carried and/or carrier was allowed to display on player CT then it would try and trigger some of the host only logic. Now gaurded against doing that. Result was harmless console error at line 650 of my code as it terminated the attempt on client (which should never have been done and now is not).

Whenever Grim gets it out in Forge it will be V1.1.

[SilentRuin]

V1.2 - Feature - New option "Set Common Initiative for carried entries (menu rolls only)" added defaulted to "off". This option will, on menu initiative rolls only, force all carried CT entries to have the same initiative rolled as their carrier. This is much the same as the option provided in combat groups and should be used with care if both are in effect.

When my players were riding a horse (or all in one carriage) - they wanted to control the horse movement and player action at the same time - it was a bit of a pain to use the combat groups option to do that init with same group (as technically there were not in the same group) so I modified carrier to do it. It will make all carried entries (even if carriers themselves - which can get "odd" as it will do them in order of CT which can have one init when a carried item is initially checked on its carrier - but that carrier may be a carrier and have another init itself assigned - best used with only one carrier IMHO but could still be useful with multiple) have the base carriers initiative so only turn this on if you know what you want and what you are doing. Else HANDS OFF IT.

This will be on FORGE whenever Grim Press gets back from vacation to put it out there.

[SilentRuin]

V1.3 - Feature - New option "Default Driver Option" added defaulted to "Carried immobile". This option will allow any carried entry dropped on carrier to have this value as the initial setting of the driver state (Carried immobile, Carried driver, Carried no shift reposition). Previously it was always defaulted on drop to just "Carried immobile" and had to be updated manually to change it.

In my game this week had to add a bunch of different carried items into a variety of carriers. Because the default placement can make it hard to select the carrier when its the same size as the carried entries I always let all the carried entries be drivers since my players are each controlling a group. It was a royal pain to drop them all in then set each carrier entry to a driver. So making this new option so it can be whatever I want at the time of the initial drop instead of forcing me to always make everything a driver - as I like to do for my players. I have not added a default option for visibility or locked as I pretty much leave those as is usually.

[SilentRuin]

V1.4 - Bug - when dropping an NPC onto a player portrait and the NPC is not in any map - carrier will error at line 1277 with a nil value. Fixed.

[SilentRuin]

V1.5 - Bug - was not supporting dropping more than CT action line "actions" onto the carried token for its use. Now it supports all of the CT action line types (traits, actions, lair actions, legendary actions, spells, and innate spells) based on pattern matching find calls - find("actions%.") or find("%.traits%.") or find("spells%."). Also added tooltip to carrier's carried tokens so that it indicates that a CT action line of the carrier could be dropped onto it to assign the carried item that CT action line.

[SilentRuin]

V1.6 - FGU changes - Latest FGU update required changes.

Not compatible with previous LIVE. Only Current one.

[ghen]

I highly doubt this is possible inside FG, but is it possible to make carried tokens always on top? they're hard to find when the carrier is moved since the carrier is typically a larger size than the carried.

edit: after reading the documentation it seems like this is a no-go.

> There is no good way in FGU to manage overlapping map tokens so you'll just have to be aware where you place any carried map tokens relative to the carrier map token as it will hide them from selection. You will have to move the carried map tokens out from under the carrier map token to regain the ability to select them again. Only selecting and dragging a map token can get it to appear "on top" of other map tokens, but you have to be able to select it to do that.

[SilentRuin]

I highly doubt this is possible inside FG, but is it possible to make carried tokens always on top? they're hard to find when the carrier is moved since the carrier is typically a larger size than the carried.

edit: after reading the documentation it seems like this is a no-go.

> There is no good way in FGU to manage overlapping map tokens so you'll just have to be aware where you place any carried map tokens relative to the carrier map token as it will hide them from selection. You will have to move the carried map tokens out from under the carrier map token to regain the ability to select them again. Only selecting and dragging a map token can get it to appear "on top" of other map tokens, but you have to be able to select it to do that.

Correct. I replace their initial positioning via SHIFT key held down so that they always have a visible chunk showing - if I even want them showing.

[SilentRuin]

V1.7 - Update - Support for Sir Motte's theme.

[SilentRuin]

Removed as not sure it was a problem.

[SilentRuin]

V1.8 - Update - added some onMove logic to not process unnecessary token movement that is less than 1/2 a grid map unit. Added full support of players being able to use the host carrier buttons if they own the CT entry. Added toggle logic to visibility eye icon on carried entry to have the carried CT get the "Carrier; SKIPTURN" effect added with gm only viewing and the source being the CT entry that is its carrier. This allows only the carrier to get a turn, skipping the turns of any entry with this effect. Also, when removing a carried entry from the carrier it will check the CT visibility status and set the token visibility to that - unless a PC - in which case it will just be visible.

Will be up in Forge when Grim Press gets around to it.

[SilentRuin]

V1.9 - Bug - fixed some issues with V1.8 not displaying carrier buttons correctly all the time (when combat tracker window was not up and other cases).

[SilentRuin]

V1.10 - Update - new option "Do not process move when dragging token" defaulted to off. This will insure any token movement will only process on the last point - not on every point in between. This is useful for large campaigns where lag in movement or token locked movement can become an issue.

[MrDDT]

Will this conflict with anything that triggers when you get close? Like AURAs EXT?

[SilentRuin]

Will this conflict with anything that triggers when you get close? Like AURAs EXT?

If you have the carrier option on it will only effect the carrier movement making it only do the first and last movement points. Meaning that only the carried items would not interact with SAVEA, etc. type of auras unless they land on them at end of movement. The actual carrier will be effected as its still moving on the map and AURA will still be intercepting all its movement as its a separate thing. In my monday game of SW5E I have mines in play (SAVEA) and don't have this option turned on.

Now AURA - hopefully - will be getting the same option soon. I currently use a version of it with it. In that case, it will only process the last point of the move so that you will miss all the SAVEA, etc. type of auras unless you land on it. Same thing on my SW5E game, I have it off. But the speed in processing difference means when I don't have SAVEA auras around and the campaign is large, I will 100% have this turned on. Carrier does not get as much benefit as AURA does because carrier is only updating points while AURA is doing a bunch of expensive stuff.

No idea when AURA version will have this - if author elects to put it in - but my version has it and it is a huge lag killer for my players moving around in maps with auras (of the non SAVEA etc. variety). And truth be told - I can live with it not triggering for the savings I get. So bottom line, its the DM's call when to turn it on. Its defaulted to off for sure.

[MrDDT]

I'm glad it's an option, because I think this would defeat the point for most people on what Auras is doing. As the point is anything that comes in range even while moving would be triggered right away.

I do see how this could be very helpful with token lag though, if you don't use SAVEA in your AURAs, it could be very helpful for that.

[SilentRuin]

V1.11 - Bug - Skipturn effect was not checking properly to see if it already had the effect resulting in duplicates being generated. Fixed.

[SilentRuin]

V1.12 - Update - setting a carried or carrier which is not visible on CT will not show its buttons when made visible on CT. Usually only using combat groups and dragging a name onto a token not currently displayed in CT can cause this. This can now be displayed correctly by closing and opening the CT window.

This has always been there but now has a workaround (close and reopen CT window).

[SilentRuin]

V1.13 - Bug - common init option was not working properly. Fixed.

[SilentRuin]

V1.16 - Update - implemented node and childList changes to code that SW wanted.

[rocketvaultgames]

I'm seeing an issue this week where I can't use any carrier functionality. Dragging any CT Entry to any other gives: "The CT entry is already in a carried state - can only be with one carrier once"

Turning Carrier Extension Active off in options then reloading with only the Carrier extension enabled seems to fix the issue (tokens are locked to each other and move together on maps), but there is no Carrier information in the CT, thus no way to dismount (as far as I can tell) or see any of the relevant info.

[SilentRuin]

I'm seeing an issue this week where I can't use any carrier functionality. Dragging any CT Entry to any other gives: "The CT entry is already in a carried state - can only be with one carrier once"

Turning Carrier Extension Active off in options then reloading with only the Carrier extension enabled seems to fix the issue (tokens are locked to each other and move together on maps), but there is no Carrier information in the CT, thus no way to dismount (as far as I can tell) or see any of the relevant info.

I have no trouble with anything in carrier. Turn off all other extensions and make sure you have the latest version number showing in your chat window. If it works then you have some conflict you'll have to figure out yourself.

[SilentRuin]

V1.17 - Update - supported vehicle class as much as possible in the same manner as npc class.

[SilentRuin]

V1.18 - Update - A Vehicle carrier CT entry link for a component can be used by dragging the link and dropping it onto a CT entry carrier tokenfield (in CT entry for carried or carrier) or dropped onto a valid map token (will then appear in carried CT entry under its carrier entry). It will add all the actions for that component. Same as could previously be done with an NPC or Vehicle CT entry link for traits, actions, Lgd Actns, LairActns, Spells, etc.

[SilentRuin]

V1.19 - Bug - running a local client would have ownership detection issues - changed check to be with Session.UserName instead of User.getUserName() so the correct login user would be returned for comparison with owner when the client is running on same machine as host.

[SilentRuin]

V1.20 - Update - when using "Set Common Initiative for carried entries (menu rolls only)" set to "on" it will always guarantee that the initial roll never has duplicates before it forces these common init settings. This prevents scrambled CT entries when they shared a common init roll.

[jaydarkson]

Will there be LoS support? I have a group of players navigating a dungeon and the ability to have them make turns or take LoS into effect would be fantastic.

[SilentRuin]

No idea what you mean. Combat tracker (CT) tokens in map have LOS and FOW. Carrier just adds things together with a carrier CT token and carried CT tokens. It does nothing to change those tokens LOS or FOW. As long as the logged in player owns that CT token - they have the LOS and FOW available to them. Nothing to do with carrier.

For example, if I use Assistant GM and share a Vehicle class that is in the CT and map to a player - then put other CT entries on that as carrier - they have full control of the Vehicle or anything else they own. For sure I'm not getting into all the other options in carrier that give you ability to group carried and carrier so they have same init (trigger in sequence on turn) or that the carried items can all get their turns skipped so only the carrier has to be manipulated.

Personally, I don't really even use vehicle class I use NPC class for all my "vehicles" as its easier for me.

[SilentRuin]

V1.21 - Update - new driver option called "follow" has been added. If set you can hold shift to position carried token in some reasonable follow distance position then when the carrier moves any carried entries with the follow setting will follow in its path. This is only for single file following. Though you can have carried token defined as carrier token (with non following carried entries itself) set to follow. If you set toggle the driver option off of "Carrier follow" then the next time you move the carrier it will have all tokens snap back to their original positions based on normal carrier behavior. Best to just drop the double click the drop all carried entries token (see tooltip) if your going to do that. Per my usual standards - its good enough. Use or don't use it as you see fit. See details in .txt file.

Pretty powerful - but likely nobody will notice as nobody reads this stuff :)

[SilentRuin]

V1.21 delivery to forge delayed - will let you know when it gets pushed.

[SilentRuin]

V1.21 is now live on Forge.

Follow Tip: While carried tokens will follow the carrier token, players or host can still move the carried tokens (say to investigate stuff). This will be like when the no shift required for repositioning is used where they will essentially redefine their distance to follow (raw distance from carrier). But if carrier keeps moving they will head back into line also. This is a tool like all my extensions and like them all can be used in ways I did not think of both good and bad. And as in all my extensions - use at your own risk.

[MrDDT]

Really nice SR thanks.

I was playing with it and I can see a lot of good uses for this. One good use is for Familiars that are meant to be near the PC at all times. So you link them and now when you move the PC they will follow them, its really cool

[SilentRuin]

https://www.youtube.com/watch?v=Qiuq37OTFDs

[SilentRuin]

Tip: I find defaulting to carrier_follow is the way to go in options now so that all my carried stuff starts off in follow mode.

[MrDDT]

Tip: I find defaulting to carrier_follow is the way to go in options now so that all my carried stuff starts off in follow mode.

As it should be, this is the way.

[SilentRuin]

As it should be, this is the way.

And reading that in your reply I just realized I did not use carrier_driver_follow defined in my string table and it took the mistaken keyin I put in for the option. Will still work - but will be fixed to display "Carrier follow" as it should in the next release. Kind of wanted to have an option where tokens always orient in the direction they just finished moving. Not sure if it will work (as in not be to time consuming a feature) but meh - same could have been said for the follow stuff.

And I'll make that the default default for that option for next release also ;)

[SilentRuin]

V1.22 - Update - option "Orient token along direction of movement" defaulted to "off" will allow token orientation to be set from direction of movement as the token moves.

Best with facing indicator option set to "on" in FGU options.

[SilentRuin]

This shows me doing a double line marching around with one leader - arrows are followed carried to carrier - triple lines are fixed carried to carrier. Moving around they whip around corners as marching would do if orient along direction option is on.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56730&d=1679023257

[SilentRuin]

Going to put a warning here about facing of tokens when the option to orient along direction of last movement is on. FGU has this weird behavior where if map grid locking is on (defaults to on so probably is for you) a token moving will follow orthogonal movement points to reach a diagonal point. But only if you land in center of a square - not a corner. Yeah confusing. So I'll put a picture out as warning - if you use map token grid locking with this feature you will get facings when you stop moving in a diagonal direction like you see in this image. Personally - if facing is super important for me I'll turn off map locking.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56741&d=1679078566

[SilentRuin]

Another tip about orient along direction of movement option - if you are being carried in a non follow normal fashion then you should first orient the carrier in the direction of travel - then shift hold position your carried tokens around it matching that facing direction. That way when you start moving (and the carrier orientation changes the carried positions) the carried tokens won't move to different relative position from direction of movement. Confusing - but you'll see when you play around with it what I mean.

[SmackDaddy]

Thanks I noticed this behavior last night setting up a map with 3 carrier situations going on. I am trying to replicate but one of the three has a carried token that is inconsistently being put under the main carrier token and I can't figure out why.

[SilentRuin]

Thanks I noticed this behavior last night setting up a map with 3 carrier situations going on. I am trying to replicate but one of the three has a carried token that is inconsistently being put under the main carrier token and I can't figure out why.

I rarely use the default placement setting myself - once I set something to carried I immediately hold shift and reposition it. And with the default being follow now you can just position it without the shift (but that will really be the distance not the position that is used when moving). And if you have the orient on move option on then you will want to do what I said above. You used the words "I can't figure out why" so that is why I repeated my advice here - though I suspect you meant "I couldn't figure out why" :)

Don't forget the options have a default you can use for all carrier creations (default now being Carried follow in a new campaign).

[SilentRuin]

An example of what I was talking about is defined here - where each token was positioned with the same orientation as its carrier token orientation. They parade around in a 1-2-2-1 formation. Course if you don't align them initially for the non follow carried to carrier ones - you will get a nice circling with in the line march. Scrambled by any other name.

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56764&d=1679172526

[SilentRuin]

V1.23 - Update - changed icon for "Carried follow" to be one from the CoreRPG so it would be more generic. Carrier is supported only in 5E no other ruleset. Specifically I do not support it in rulesets I don't use, for example - like 3.5E, 4E, CoreRPG, PFRPG, PFRPG2, and SFRPG. Just like my Map Parcel extension only supports 5E. Nothing else will be mentioned on this subject.

[SilentRuin]

I'm not sure when it changed, or if something else is causing it, but the PC CT entries no longer get ownership assigned to match the charsheet DB entries when a PC logs in on a client. The ramification of this is that any PC that tries to have its carrier buttons updated on the client will fail to actually update them on the host as they can no longer keep them in synch in their local DB (no permission to do so). This took a long while to figure out for various reasons. Any NPC/Vehicle that is owned by the player will still work fine on keeping these button settings up to date.

For now this is an open issue - but as I have a game on Monday I'll be overriding the code myself to make the fix before it and update it here. Not a good solution as if you have anything else that does buttons on the CT to keep in synch with the host those won't work unless you have the fix. Still... needs must. My game - will go on without the headaches for sure.

[SilentRuin]

V1.24 - Bug - fixed an error due to unguarded nil. Made sure the CT visible eye icon is in synch with the CT Carrier Carried entry eye icon so both would set token visibility and carrier carried entry visibility properly.


Does not address the PC CT ownership issue yet as I'm still holding out hope SW fixes this before I have to do it myself before my game Monday.

[SilentRuin]

V1.25 - Bug - At some point PCs entries in the CT stopped being able to have generic CT buttons on the clients effect them. As Carrier has such buttons I've had to force the addHolder/removeHolder of the CT's ownership when a PC is activated or deactivated myself.

Based on replies in my other forum post about this I'm getting the impression I'm on my own with this. So doing it myself.

[SilentRuin]

Lag testing with Carrier and some marching bots going by my players last Monday seemed to work "OK". This was a pretty large test case and if I moved slow seemed to be fine. I could not whip around like I could with just a few things following but was "good enough" for a carrier with 3 following carriers each with 2 carried items each. It seemed the last row would hiccup somewhat in the following and I may look into that if its something smaller cases have going on but it did not drop dead and they did march by in order at a normal walking pace pausing to scan the characters and imply a TPK was in their future if they tried to pull any hijinks. Because in my game they are free to do what they want - with the appropriate consequences attached of course :)

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56828&d=1679672715

https://www.fantasygrounds.com/forums/attachment.php?attachmentid=56829&d=1679672736

[MrDDT]

Really awesome work dude.

[SilentRuin]

Another thing I found out in my use of carrier was that in my SW5E spaceship battles where they either outright control the ship as an NPC (no issues as they are the NPC with its vision) or are carried on the ship controlling its weapons as PCs (don't share ships vision) that I had to put a "VISION: 750 blindsight" effect on them so they could see through the ships sensors as they used its weapons. They were all set to carried invisible so I also had to delete all the SKIPTURN effects that generated so they would get their turns - and as I had a driver PC I manually set the NPC ship (actually owned and controlled by driver) to have a SKIPTURN effect in it so only the PCs got turns.

This was because if I just gave a ship a normal light that they could see with it would immediately be seen anywhere from across the space map - and my ship battle rules don't want that sort of thing unless they trigger a scan pulse (normal very long distance 3000 ft light) that will let them be seen and see farther while its turned on.

Why tell you all this? Because this is a tool and while I have options to do some common things for you - some things that are specialized you still have to do - think - trial and error to see what works in that situation. Still need you as a DM to do your job!

[SilentRuin]

An error when creating a carrier and a client is up - it will get a line 973 error in my code from a corrupted window. It seems mostly duplicatable but may be a tough timing issue. I think its been around for a while but I seem to be able to duplicate it regularly in my test campaign now. I'm currently looking at it. Once it happens the players CT will no longer be updated with any carrier stuff as its lost that window. Only shutting down the player and coming back up will fix it (till the next time some carrier is created and the window gets whacked). I'm trying to fix it now but it may take a while so posting this warning. Not sure how long this has been around but at least a few weeks.

[SilentRuin]

V1.26 - Bug - V1.24 introduced a bug that caused a recursive call to corrupt a window on player side. Fixed.

Some idiot put an incredibly hard bug to find - said idiot has hopefully fixed it.

[SilentRuin]

V1.27 - Update - "Carrier; SKIPTURN" will only be applied when Carrier carried eye icon is toggled to invisible not when CT entry eye icon is toggled to invisible. That way carried entry can be made invisible without applying SKIPTURN to it.

This whole visibility stuff is for me and my games and how I want them to play without forcing yet another option into the mix.

[SilentRuin]

Carrier Tip: I do not use follow driver option when something is riding something else - as I want them in a fixed position relative to positional placement on what they are riding. Follow is more for things that have some separation and distance between.

[SilentRuin]

V1.28 - Bug - stupid cut/paste error resulted in error at line 1422. Fixed.

Been around for a week, my players noted it repeatedly.

[SilentRuin]

If you use common init option - beware your numbers may be higher - just like the version info implies it will (to be unique init it has to be higher). For sure effects that adjust on initiative will respect the init that is placed when the effect is set (high or not) but if like me you use the roll every round option your still going to have issues with those. So if those adjustments on your effects are more important than turn order - for sure turn them off. It won't save you from the roll every round option messing you up regardless (if just raw FGU or common init is in play) unless you have Effective Initiative.

Plus if you turn on or off this effect after effect adjust on inits have been set - obviously they will not be correct (just like when you reroll init on round changes normally would not be).

Also fixed inits like lair ranges set to 20 or things like that would have to be modified by the DM to be more toward the top or bottom of your unique inits (or just don't use common init options).

[SilentRuin]

Common init option is currently defaulted to on - going to change that to off - as I'm the only one that probably uses it in my campaigns and those are the defaults delivered in the extension - which is going to be more trouble than its worth. I'll just manually turn it on in any new campaigns for myself. No version change for this will appear.

[SilentRuin]

This probably does not need to be stated - but as I just had a game that had me stumped why someone could not use the healing action on a NPC starship they were being carried by in the CT (which had been given by the DM so that they could double click on it) which did not work no matter what I did - it was because if that client does not also own the NPC/VEHICLE CT carrier node it can't write to the node's tempHP data.

So obviously, if the DM is foolish enough to share an NPC/VEHICLE carrier CT action that has some sort of writable action to the DB then it will give a warning in the console log (which you won't see unless you go look) stating that when it tried to write whatever it was to the DB node - it failed. Because they did not own the NPC/VEHICLE CT carrier node - this was the case in my particular case.

SO be warned. Not every NPC/VEHICLE carrier CT action that can be shared should be shared out to clients - any write action ones - like [HEAL: 1d4] etc. need to be only shared out if they also own the NPC/Vehicle carrier CT node.

[SilentRuin]

V1.29 - Bug - with common init option the order was never really changing even though numbers generated were unique. This was because the number sample was generated based on random 20 and on large CT counts this was not a large enough random number sample to change the order. Now when common init option is set that init random number generator is based on current CT count so that sample is large enough to get unique numbers and change the order randomly. As usual with common init option you will see init much higher (if lots of CT entries visible or not). The CombatManager2.rollRandomInit code override is shared between carrier and combat groups extensions.

[sirkerry]

Any chance of this extension working with the Pathfinder 2e ruleset?

[SilentRuin]

Any chance of this extension working with the Pathfinder 2e ruleset?

If it did, I would claim it is totally unsupported. IN fact. I do claim this. IF it worked.

[SilentRuin]

V1.30 - Bug - needs to be aware if common init from combat groups is in effect so it does not mess up that order. Fixed.

[Zeruel_Kagenie]

Testing it today in a new D&D 5e campaign with only the Carrier extension activated. The Monster Manual module is open, no others are open. No player connected.

Add a few creatures to the combat tracker. None of them had the carrier button. I added them to an image with a grid. None of the extension functions worked.

Try this while:
- Standard FGU options.
- The Carrier extension options appear within the FG options button.

(1) - Carrier Extension Active (off deletes all carrier date) [On]
(2) - Default Driver Option [Çarried follow]
(3) - Display status (carried or carrier) on map token [On]
(4) - Do not move process when dragging toke [Off]
(5) - Orient token along direction of movement [Off]
(6) - Use carrier map token orientation on carried positions [On]

Try disabling option (1) and restarting the FGU. Turn it back on and reboot and there was no change.

[MrDDT]

Testing it today in a new D&D 5e campaign with only the Carrier extension activated. The Monster Manual module is open, no others are open. No player connected.

Add a few creatures to the combat tracker. None of them had the carrier button. I added them to an image with a grid. None of the extension functions worked.

Try this while:
- Standard FGU options.
- The Carrier extension options appear within the FG options button.

(1) - Carrier Extension Active (off deletes all carrier date) [On]
(2) - Default Driver Option [Çarried follow]
(3) - Display status (carried or carrier) on map token [On]
(4) - Do not move process when dragging toke [Off]
(5) - Orient token along direction of movement [Off]
(6) - Use carrier map token orientation on carried positions [On]

Try disabling option (1) and restarting the FGU. Turn it back on and reboot and there was no change.

It's working for me.

Drag the name of one creature to another creature in the CT, does it give you the carrier options?

[SilentRuin]

Testing it today in a new D&D 5e campaign with only the Carrier extension activated. The Monster Manual module is open, no others are open. No player connected.

Add a few creatures to the combat tracker. None of them had the carrier button. I added them to an image with a grid. None of the extension functions worked.

Try this while:
- Standard FGU options.
- The Carrier extension options appear within the FG options button.

(1) - Carrier Extension Active (off deletes all carrier date) [On]
(2) - Default Driver Option [Çarried follow]
(3) - Display status (carried or carrier) on map token [On]
(4) - Do not move process when dragging toke [Off]
(5) - Orient token along direction of movement [Off]
(6) - Use carrier map token orientation on carried positions [On]

Try disabling option (1) and restarting the FGU. Turn it back on and reboot and there was no change.

I have no idea what your trying to do here. Everythying you mentioned would not trigger anything to be a carrier of anything else. Watch videos or read up on extension in .txt file. You have to actually define a carried CT entry on a carrier CT entry by dragging the CT entry name field of what you want carried on to the CT entry name field of what you want to be the carrier. Doing nothing = getting nothing.