5e Combat Enhancer (built on retired GPL Advanced Kombat extension)

[StoryWeaver]

Thank you for your rapid response.

The situation has improved a lot.
Now I have tiny status icons, no error message.
I stoped the Enhanced Images (layers for FG 3 CoreRPG+ as well so "I can clean the floor" (with Enhanced Images (layers for FG 3 CoreRPG+ running i couldn't switch to the lowest layer)

The only issue remained is the strange death icon instead of the red skull on the PC when (s)he dies. I use the same location for the app and data folder (both C:\FG in the setting panel) and there was no \tokens\host\item folder, so I just made them and copy all the pics there. (the strange thing is that it is working properly on NPCs).
Do you have some advise tp solve it as well?

Thank you in advance

A skull only appears on top of a PC token if they have failed 3 death saving throws. Before that they are treated in a different manner, as not dead until then.

PC vs NPC death.jpg

The Enhanced Images extension code is already part of this extension, therefore loading both is likely to cause overlap in functionality and error prone.
Equally as has already been mentioned, do not load the Advanced Kombat extension, it us no longer supported and has been retired. This extension is built on top of that and adds a lot of functionality and refinement to it. So again error prone trying to run both. The reason it is given as a download option is for legacy reasons, and the original post clearly states it as being retired.

That aside, hope you enjoy the extension and that it improves your overall 5e gaming experience.

[Dax Doomslayer]

OK - I'm going to bite the bullet and try this out for the first time. Is there any documentation / guidance on how to use this? Also, when loading this up, I'm getting a yellow triangle with an exclamation point on a PC that has died. I did put the "items" folder in my C:\Fantasy Grounds Data\tokes\host folder. I'm curious to see this as it looks pretty spiffy!!

[Halfront]

OK - I'm going to bite the bullet and try this out for the first time. Is there any documentation / guidance on how to use this? Also, when loading this up, I'm getting a yellow triangle with an exclamation point on a PC that has died. I did put the "items" folder in my C:\Fantasy Grounds Data\tokes\host folder. I'm curious to see this as it looks pretty spiffy!!

Be sure to read the first couple of entries in this thread for descriptions of use It's a great extension!

[StoryWeaver]

To address some of the conversation above:


Ping Functionality


I have not made any modifications to the ping code, so any issues it has are inherited from the AK extension code.
I've not made any changes to the way the extension handles image handling overall so expect it to behave similarly to what AK did in that regard.

The ping functionality is something I hardly ever use myself, I always hold down both mouse buttons and drag and point to my players. Super quick and works well, but that's a personal preference and I can appreciate other people might prefer to do it another way. And it does seem to work for the majority of times within its limitations, even it there might be a slight wait the first time around.
Currently the ping functionality only works properly as long as the players don't use background images, I may look into that at some point, but overall the ping functionality hasn't been high on the priority list.


Memory issues


Since the amazing updates SmiteWorks did with FG 3.3.7 I have not run into memory issues and it has allowed much more generous sharing of media in my games to bring things to life for the players. This extension has been tested with a few modular adventures and there have been no memory issues in those cases so far. I can't guarantee this for all modules obviously, but most games seem to be running at around 400 MB - 1.5 GB of memory usage after the original loading so nowhere close to the breaking point.

Of course we all look forward to getting our hands on FGU with a 64-bit architecture, so we can attempt loading up thousands of token graphics to drop on maps and into games. But what we have now with 3.3.7 has made a world of difference.
Long story short, I would not be worried about memory issues with loading the extension at this point, it does not use all that much memory in the first place and even if it did you'd still have a lot more to work with due to 3.3.7's memory changes.


Placement map graphics


This is something I could possibly do. But as this extension has primarily been focused on improving the flow of combat it is a question if that is something that would be better suited for another extension, thus if it would be worth investing the time into doing so.
Personally at this point I have literally hundreds of high quality downloaded maps that I've put into modules that I pick from when I need a quick map, or if I need something specific for one of my story arcs I make that in Photoshop.

That said if the demand for it is high enough, I might look into doing it.


What am I currently looking into?


As most of the core functionality seems to be working pretty well and a lot of the improvements I have wanted to see myself are already included now, I've started to consider more longer development cycle possibilities.
Keep in mind that I work on this extension in my spare time and most code and feature changes take hours up to days to complete, such is the nature of software engineering.

With that out of the way, this week I have been looking into rudimentary dynamic lighting (which would no doubt take a number of weeks to finish if I were to push ahead). So something similar to what I found here while searching the forums: https://www.youtube.com/watch?v=Xj3FwXkJ_jU

What I have so far is that I've figured out how to accomplish this in broad strokes, both from a what we have available to work with to the math involved. So I have a rough outline development pipeline for this and I've started writing code to accomplish this to some degree of success so far, including creating the additional graphics needed to work.

There are current limitations to how dynamic lighting could be accomplished from what I've read and seen so far. For one as we don't have proper drawing tools we can call upon with APIs, nor API's to read the current mask. Also as has been noted in other posts, FG is a single-thread application, so overly complicated vector fog of war calculations might hang up all the clients as they are being done over the whole group as the software can only do one thing at a time.

So what I've come down to, similar to what can be seen in the youtube video above. This could be handled by a hex by hex basis (rectangular only for now) using tokens (black, full square sized, of varying opacity) to represent areas of darkness and with some clever math extrapolated from the set grid sizes etc., to remove or replace the tokens depending on if on the GM or player side, and if vision is normal, dim or none etc. Hiding NPC's could be done similarly if outside of view, but that's something I'd worry about later if at all (it's as easy as a mouse click for the GM on the CT after all), focus on the primary functionality first, the 80/20 principle.

My main concern with this at the moment and this approach, is no doubt one of the the technical difficulty limitations that youtube video code creator must have run into as well. Is that you can only do it on a hex by hex basis, that is if you have a map that doesn't have at least one hex between walls, then you're in a tough spot. And as we all know there are plenty of maps such as that out there, castles, houses and ruins come to mind.

So I'm considering if there are other approaches I could take to this atm. Such as for example simulating a vector drawing tool by allowing the rotation and manipulation of a square token to extend out as a line across the map, then figuring out some math to calculating fog of war with that as a "wall" to vision. But then again we get back to the "single thread application" concern.


Suggestions and error reports


I do read all of your posts, suggestions and error reports equally. I always consider them. As to if it's possible to accomplish, is it within the intended scope of the extension (which might change with time), how long would it likely take, is it feasible, will it likely be made redundant with FGU, how much use would it see, how many users is it likely to affect, do I have the time available etc.

So don't hesitate to share your great ideas. The worst case scenario is that it doesn't get implemented.



Donations


Doug has come back to me on SmiteWorks behalf, and while they are not currently ready to come down with a ruling across the board, they have generously given me an explicit exception for the time being to accept donations for my work on this extension. So I quote: "For now, we will simply grant you explicit permission to accept donations for your great work on the extension as long as the extension itself remains freely available through the forums."

To this end I am in the process of setting up a PayPal.me account and I will share it here once that is set up properly.

[Trenloe]

Memory issues


Since the amazing updates SmiteWorks did with FG 3.3.7 I have not run into memory issues and it has allowed much more generous sharing of media in my games to bring things to life for the players. This extension has been tested with a few modular adventures and there have been no memory issues in those cases so far. I can't guarantee this for all modules obviously, but most games seem to be running at around 400 MB - 1.5 GB of memory usage after the original loading so nowhere close to the breaking point.

Of course we all look forward to getting our hands on FGU with a 64-bit architecture, so we can attempt loading up thousands of token graphics to drop on maps and into games. But what we have now with 3.3.7 has made a world of difference.
Long story short, I would not be worried about memory issues with loading the extension at this point, it does not use all that much memory in the first place and even if it did you'd still have a lot more to work with due to 3.3.7's memory changes.

The v3.3.7 changes certainly help. These were purely on the player side, where previously all graphics shared with the players were loaded into memory - even if they weren't opened. So the memory use on the players side, with a lot of images available (i.e. library modules with images) is equivalent to the GM side (if the same resources are active).

My main concern with this extension and memory use (and processing times) is based off Ken's comments regarding not supporting maps in modules as operations against any map had to parse through every single image the GM had access to. See "Support for module images?" below, as it's not clear what was done around this in the final version of the AK extension.

At this point, the main memory "issue" to be aware of relating to this extension is due to the image layers. When FG displays an image/map it loads all of the graphical data into memory (on the player or GM side - whichever is showing the image at that time). The amount of memory used is completely based off the pixel resolution of the image (not the file size on disk). Memory is used for every pixel in the FG image control - even if that pixel is empty. So, using image layers, open an image takes at least 3 times more memory than without the image layers - in practice it appears to be closer to 4 times. For example - opening the "Map - Abbey of Saint Markovia 1" map from Curse of Strahd takes 70MB without layers, but 280MB with. Not a huge increase, but just something to be aware - especially if you have multiple image windows open at one time - and especially if one or more of those are really big maps (over the recommended 2048x2048).


Support for module images?

I really don't know if there was additional code added to the extension after Ken mentioned this: https://www.fantasygrounds.com/forum...l=1#post411627 Because he suggest effects etc. won't show on maps in modules, but they obviously do - as does other functionality (ping, blood spatters, etc.). Maybe he found a good way to implement these for module images, or maybe he didn't restrict module images. @Styrmir - perhaps you can confirm that the code is looking at all images, both campaign based and modules based? Or is there some limit for certain CE extension operations? Or, if you're not worried about it, no problem - you're the one doing all the work on this extension (maintaining, adding new functionality, etc.), so it's essentially "yours" now...

[Felix Montmorency]

Thank you. So I misunderstood how it works.
It's a great help for combats, thank you again

[Dax Doomslayer]

OK - I've just booted this bad boy up. When loading this up, I'm getting a yellow triangle with an exclamation point on a PC token that has died. I did put the "items" folder from the zip folder in my C:\Fantasy Grounds Data\tokes\host folder. I'm assuming this isn't supposed to happen and there should be a SKULL? The death saves were not made using the automated feature but rolling in the chat box by the player if that matters...

[Egheal]

This is now clearly the best extension for FG (with the DOE Sound in another domain). Thanks a lot. Looking for your donation link. You are awesome.

[The High Druid]

"Semi-transparent easily customizable color and transparency highlight backgrounds."

Is there any way to scale the token highlights to match the "Reach" value from the combat tracker? I have a size 10 reach 10 npc and it would be nice for the highlight to show what's in melee range.

[Zacchaeus]

Is there any way to scale the token highlights to match the "Reach" value from the combat tracker? I have a size 10 reach 10 npc and it would be nice for the highlight to show what's in melee range.

Unless that was removed by the extension this functionality already exists. When you mouse over any token the reach is shown as a dark square around the token.