Turbo - Multiple Rulesets

[rhagelstrom]

Turbo optimized the performance of the Fantasy Grounds effect processing. It has shown an average performance improvement of 590% in the 5E ruleset's getEffectsByType function. One may see perfromance degreation in FG effects processing when:


Actors in the CT have more than 15 effects active
CT is overloaded with Actors
Extensions are loaded which increase the load on the FG effects processing system


Turbo has been adapted to support various rulesets, including 5E, 4E, 3.5E/PFRPG, 2E, PFRPG2, and SFRPG, and can be customized to support additional rulesets. Performance gains in rulesets other than 5E are expected to be similar. While performance gains with Turbo may be mostly imperceptible, any improvement will help reduce the perceivable performance impacts caused by other sources.

A full report on analysis can be viewed FG Effect Processing Performance Improvements (https://github.com/rhagelstrom/Turbo/raw/main/FG%20Effect%20Processing%20Performance%20Improveme nts.pdf)

[EllivasKram]

Seems to good to be true. I know performance was also being looked at by smiteworks themselves. There must be some negative to this extn ?

[rhagelstrom]

The negative would be its an extension and all the same gotchas there. Other than that anyone is free to run experiments themselves.

[EllivasKram]

What extn’s do you use and so we know you have in effect tested

[rhagelstrom]

The white paper details how the testing was done and what the results where. The constant in the entire thing was Better Combat Effects Gold because that is where the test harness was for my experiment. What other extensions that were also running was not consistant across the tests but the results showed that running with Turbo consistently outperformed the results when Turbo wasn't running. By not consistent I mean whatever extensions where loaded were the normal load out for that particular game. That all being said if anyone wants to run their own experiment to validate or invalidate my results go for it, that is what science is all about.

[MrDDT]

What extn’s do you use and so we know you have in effect tested

I've been testing this for a few months now and it's noticeable with higher levels of play using a lot of effects in the CT. I also use a ton of exts and never had an issue with Turbo causing an error or conflict.

I use windows so my testing data is not useful for the raw data, but I can tell you turning it on and off with 6 PCs in the CT with 15+ effects on each of them is noticeable, so I believe it's likely doing what it's meant to be doing while I was testing it.


EDIT: I got a few questions about what I meant about windows testing; Yes this works if you are using Windows OS; the issue came up in how we tracked data for how fast it was getting the information vs non turbo on effects. Windows OS was not able to get the data so precise in the information, where as other OS's was able to get very fast data tracking.
If you read the report you will see more of what this is talking about. However, It is noticeable as I said under very high effects processing to be effective, and the other OS data tracking proved it.

[EllivasKram]

I will test myself. I’m just hoping I’m not going to be walking naked in the steeets with all my players saying im wearing a most wonderful cloak

[bmos]

A number of my extensions for PFRPG and some other extensions for 5E I've looked at already have compatibility code in place to take advantage of this extension :)
I get the concern of too good to be true, but there is absolutely room for optimization in some of these massive functions. The question is just which ones to focus on. When it comes to extensions and complex CTs, this one has a pretty noticeable impact in certain situations.

[BushViper]

I'm emphatically jumping on this train with hopes that it will continue to grow and improve as the performance of FGU is THE primary issue that I (and many others) have with the platform.

At this point, many of us, couldn't care less about shiny new features if the fundamental performance problems aren't significantly improved.

Furthermore, MANY of us are done with being gaslit and dogpiled on the forums by SW fanboys as well as SW employees themselves when legitimate issues are raised. The "send me your log file" request is a meme at this point.

The minority is vocal, but the silent majority are not idiots and they're witness to these exchanges and SW is objectively damaging their brand as a consequence.

Anyway, I'm extremely appreciative that this work is taking place.

[Lo Zeno]

Well I gave it a go downloading the extension from rhagelstrom's github repo, and damn the difference IS impressive, at least in a high-level 5e campaign I run with one of my groups. The characters have complex races from MMOTM and a good number of magic items, and we use Aridhro's Automatic Effects modules so we have plenty of effects on each character: the improvement is more than noticeable, it's actually impressive.

[EllivasKram]

I use pretty much the entire range of Team Twohy’s extns and quite a few other from the FORGE. No issues with other extns and yes with a heavy load of NPC’s and 6x players connected with effects active a pleasant experience with no performance issue.

In fact a trouble free pleasent evening was had.

The only thing a similar turbo extn could be fixing is the sometimes sluggish approved movement of player tokens when using locked movement. Sometimes my players report they move like they’re over encumbered slugs.

So I highly recommend this extn to all

Maybe a extn that’s allows force VSYNC and imagequality of connected clients.

[bmos]

Maybe a extn that’s allows force VSYNC and imagequality of connected clients.It would be nice to be able to choose a new default for those (or better yet add them to the UI!). Unfortunately those APIs are not exposed to community devs, so it's up to SmiteWorks to improve that behavior.

[mapleybacons]

Very neat extension and very welcome at my tables. Great work!


A reduction in processing loops is expected to be significantly more efficient, with a 100% or more
improvement, and to eliminate the sluggishness when the Combat Tracker (CT) actors have a significant
number of effects, extensions are enabled that, in totality, add a large number of new tags, or extensions
are enabled that enable overloading of the CT with a large number of actors.


Really wondering what the difference in processing approach is here and if it's comprehensive enough that SmiteWorks could incorporate it into the FGU client itself instead of via extension.

[plap3014]

looking good!

find it!

[rhagelstrom]

Version Update: 1.1
Feature: Added slash command /turbo_test to test if turbo is active
Fixed: Typo preventing from turbo running with PFRPG2
Fixed: Script Error 2E

To test if turbo is active in your ruleset, the following slash command can be used and a turbo message will be displayed on success:
/turbo_test
If the test fails, either there is an extension conflict or Turbo is disabled via the options.

Note: Active in ruleset CoreRPG means Turbo is Active for CoreRPG, however if your ruleset uses an alternative effects manager then Turbo is likely idle. There is no way to automatically detect an alternative effects manager.

[Maldev]

G'Day there.
Have just discovered an issue with Turbo and lighting effects.
4e d&d
Win 10
16gig ram
Turbo extension only

Proceedure
Lightning= None
1/ I add a light to a token on the map using effects, or add an light effect to the CT.
2/ No light appears on the map.
57277
3/ When I click to turn the light off in the CT, a light now appears on the map.
4/ Each attempt to turn it off adds a token light in the Image lighting.
57278
5/ When I delete the light in the combat tracker, the light stays on. (As there are now multiple token lights)
57279

Regards

[tnnlynch]

I ran into an issue with PF1E, Turbo loaded and two other extensions ( Kelrugem's "Extended automation and overlays" & ""Extended automation and Alternative overlays"). When rolling for a random encounter using the dice button an error is generated. I was able to reproduce this with a minimal set of extensions (these three) and using the bestiary random encounter tables. Removing Turbo from my test campaign at startup eliminated the error.

"[ERROR] Script execution error: [string "Full OverlayPackage:..s/manager_actions.lua"]:37: attempt to perform arithmetic on local 'nAdvantage' (a nil value)".

If I can provide more information let me know. If you think I should post this to Kelrugem as well I can.

Thanks
Tom

[rhagelstrom]

Version Update: 1.2
Fixed: CoreRPG issue with token lights
Fixed: 3.5E/PFRPG Issue with Kelrugem overlays

Sorry for the delay as I've been busy. I think this should resolve the above two issues. Please let me know if you still have any issues. If you are still having problems with token lights, try removing and re-adding the Actor to the CT.

[tnnlynch]

Appreciate the update. My issue has been resolved.
Thanks,
Tom

[Maldev]

Version Update: 1.2
Fixed: CoreRPG issue with token lights
Fixed: 3.5E/PFRPG Issue with Kelrugem overlays

Sorry for the delay as I've been busy. I think this should resolve the above two issues. Please let me know if you still have any issues. If you are still having problems with token lights, try removing and re-adding the Actor to the CT.

G'day, No worries :)
Yep- Issue resolved. Good job!
Cheers

[Kelrugem]

Version Update: 1.2
Fixed: CoreRPG issue with token lights
Fixed: 3.5E/PFRPG Issue with Kelrugem overlays

Sorry for the delay as I've been busy. I think this should resolve the above two issues. Please let me know if you still have any issues. If you are still having problems with token lights, try removing and re-adding the Actor to the CT.

Thanks a lot :)

[cristmo]

I'm testing this extension with PFRPG and Kelrugem Overlay: it works like a charm!

So far, I've only found a bug with the "nodex" effect: if you use "IF: nodex" or "IFT: nodex", nothing happens.
Looking into the code, I've found that Turbo extension looks for a "nodex" status, but ofc this status doesn't exist, since it's just a group of statuses mapped in Kelrugem extension (nodex = flat-footed, helpless, etc.).

As a workaround solution, I've overloaded the GetMatchedEffects function (from Turbo extension), to force a loop in case of "nodex" status:

function newGetMatchedEffects(rActor, sTag)
local aReturn = {};
-- DMC Kelrugem nodex management
sTag = sTag:upper();
if sTag == 'NODEX' then
-- Loop all nodex states (flat-footed, helpless, etc.)
for _, sNodex in ipairs(DataCommon2.tnodex) do
local aReturnNodex = {};
aReturnNodex = oldGetMatchedEffects(rActor, sNodex);
for _,v in ipairs(aReturnNodex) do
table.insert(aReturn, v);
end
end
else
aReturn = oldGetMatchedEffects(rActor, sTag);
end
return aReturn;
end

With this modification, "nodex" works correctly.

I don't know if it's better to modify Turbo GetMatchedEffects function, or Kelrugem extension. Anyway, it would be a great thing if you could fix this behavior.

Regards

[rhagelstrom]

I'm testing this extension with PFRPG and Kelrugem Overlay: it works like a charm!

So far, I've only found a bug with the "nodex" effect: if you use "IF: nodex" or "IFT: nodex", nothing happens.
Looking into the code, I've found that Turbo extension looks for a "nodex" status, but ofc this status doesn't exist, since it's just a group of statuses mapped in Kelrugem extension (nodex = flat-footed, helpless, etc.).

As a workaround solution, I've overloaded the GetMatchedEffects function (from Turbo extension), to force a loop in case of "nodex" status:

function newGetMatchedEffects(rActor, sTag)
local aReturn = {};
-- DMC Kelrugem nodex management
sTag = sTag:upper();
if sTag == 'NODEX' then
-- Loop all nodex states (flat-footed, helpless, etc.)
for _, sNodex in ipairs(DataCommon2.tnodex) do
local aReturnNodex = {};
aReturnNodex = oldGetMatchedEffects(rActor, sNodex);
for _,v in ipairs(aReturnNodex) do
table.insert(aReturn, v);
end
end
else
aReturn = oldGetMatchedEffects(rActor, sTag);
end
return aReturn;
end

With this modification, "nodex" works correctly.

I don't know if it's better to modify Turbo GetMatchedEffects function, or Kelrugem extension. Anyway, it would be a great thing if you could fix this behavior.

Regards
I’ll take a look and push an update or work with kel to get this resolved. Thanks for the report

[Montis]

According to Trenloe on Discord, this extension breaks a lot of the new PF2E ruleset (R19) code. As with all the new additions it could really use a little speed-me-up, is there a possibility you could look at possible compatibility issues?

[rhagelstrom]

According to Trenloe on Discord, this extension breaks a lot of the new PF2E ruleset (R19) code. As with all the new additions it could really use a little speed-me-up, is there a possibility you could look at possible compatibility issues?

Sure I'll take a look to see what is going on. Thanks for the report

[rhagelstrom]

Version Update 1.3:
Fixed - PFRPG2 updated to support R19

[Baron28]

Does this extension work with the Dungeon Crawl Classics ruleset? If not, any plans that it will?

[rhagelstrom]

Does this extension work with the Dungeon Crawl Classics ruleset? If not, any plans that it will?

Depends. If it's EffectsManager is straight CoreRPG then yes. If it has its own custom EffectsManager like the major rulesets do, then no. Given I don't own the ruleset I don't have any way to support it but I'm willing to work with the converter/maintainer. The mod to support ruleset is literally I think 6 lines of code.

[DonE66]

Does this only help the server side or is there also benefit for clients to install?

[rhagelstrom]

The extension is loaded via the Host when they load the table. Nothing for clients to install.

[DonE66]

Thanks

[rhagelstrom]

Version Update: 1.4
nil check for possible script error when using Polymorphism extension

[rhagelstrom]

Version Update: 1.5

Maintenance: PFRPG2 update for ruleset changes. Support PFRPG2-Legacy

Ruleset updated allowed me to clean up the PFRPG2 code and now should be pretty insulated from future ruleset updates. Thanks @Trenloe

[Trenloe]

Ruleset updated allowed me to clean up the PFRPG2 code and now should be pretty insulated from future ruleset updates. Thanks @Trenloe
Sorry it took a few weeks to make the change. I was trying to find where we'd discussed it to let you know! I think I got all instances of function calls with the effect script, if I missed anything please let me know.

[Wulfgangrpg]

does this work for D&D 5e

[MrDDT]

does this work for D&D 5e

Yea

[Trenloe]

does this work for D&D 5e
Yes. The supported rulesets are listed in post #1.

[Whitsend]

Hi All.
I was just recently was asked if I thought Turbo helped.
And I was unable to quantify my answer......qualitatively I believe the answer to be YES.

Playing a couple of different campaigns with PFR1

I uploaded this mod to see if I could notice a performance gain.
I "THINK" my group has noticed an improvement....but my experiment is muddied by our also switching to LAN (TCP/IP) rather than a cloud campaign.

More, I do think it helps when in the midst of large combats (ie a recent one when there was the party and 30 other NPC's on the map at one time).
I'll be running a gaming session this weekend without it to see if anyone notices a slow down....then again with it on to again see if anyone notices.
Will post my "subjective" results.
I've tried parsing its' impact via system load but FGU only sucks up 7-9% of my processor when loading and 11-15% when the game is fully up and active...so I'm really not showing the load there with turbo up, and turbo off.

Any other suggestions on how I can quantify any improvements?

[MrDDT]

You will see the biggest improvements when actors in the CT have a lot of effects on them.