Slow module deactivation time?

[adminwheel3]

Can someone shed some light on what is happening in the background when I am unloading modules. I have a very beefy system - just assume it can do all the things and do them quickly. Why does it take 5-10 seconds for a module to unload with an hourglass, why do my fans spin up and why, if I click on a sequence of modules does fantasy grounds hang like I asked it to do something hard?

I don't get the feeling its taking full advantage of the platform I'm running it on, and I'm trying to understand why, so I can try and work within its constraints.

Video attached.

OS Name Microsoft Windows 11 Pro
Version 10.0.26100 Build 26100
Processor Intel(R) Core(TM) i7-14700K, 3400 Mhz, 20 Core(s), 28 Logical Processor(s)
BaseBoard Manufacturer ASUSTeK COMPUTER INC.
BaseBoard Product ROG STRIX Z790-F GAMING WIFI
BaseBoard Version Rev 1.xx
Platform Role Desktop
Installed Physical Memory (RAM) 128 GB
Total Physical Memory 128 GB
Available Physical Memory 92.6 GB
Total Virtual Memory 149 GB
Available Virtual Memory 96.3 GB
Page File Space 21.0 GB

Video Card NVIDIA GeForce RTX 4070 TI


Thanks!

[Zacchaeus]

First thing to check is whether you can reliably repeat this issue in a new campaign without extensions.

[Trenloe]

I frequently see this with large modules. I assume it's FG re-organizing the internal database structure that the module XML data was a part of - removing the module data and doing any required FG database re-organization. A similar thing can happen if the GM deletes a complex PC from the campaign.

[Moon Wizard]

It's because there are a lot of checks being done by all the various UI components to "clean up" all the UI elements related to the data you are "deleting"/"removing". The more windows that have been opened (lists, books, etc.) since you started the session will also affect the time needed (since many of those elements are cached for speed of play).

Regards,
JPG

[MrDDT]

Also note this is going to have major impact from the type of SSD/HDD you have, this is rewriting the DB.xml file and remove them from the DB and restructuring it, while it's checking any lists you've already created.

[adminwheel3]

Sounds like database stuff seems to be the general consensus. I suppose I could go back to the bad old days of creating my own character and campaign specific modules so that I'm not opening any modules that aren't actively being used during play.

Thanks for the info.

[Trenloe]

Also note this is going to have major impact from the type of SSD/HDD you have, this is rewriting the DB.xml file and remove them from the DB and restructuring it, while it's checking any lists you've already created.
The FG database is stored in memory, and FG only writes the database to the hard drive every 5 minutes as a backup in case of unexpected exits of the FG application. What @adminwheel3 is describing is all memory operations and so won't be affected directly by hard drive speed - unless FG was running high on memory use and using the OS swap file on the hard drive, highly unlikely in this case as the computer in question has 128GB of RAM.

[Trenloe]

I suppose I could go back to the bad old days of creating my own character and campaign specific modules so that I'm not opening any modules that aren't actively being used during play.
Or, don't close them during a gaming session unless you really, really want to. You have a high-spec computer, so having a bunch of modules open probably won't impact your system operation too much once opened.

[Mike Serfass]

Modules add entries to the lists of NPC, items, images, tokens, spells, etc.
If a module has hundreds of items or NPCs or a large number of big maps, it takes time to create those lists. It combines all the entries and sorts them, both when adding or removing a module.

[Nylanfs]

Also, wasn't it stated that Unity didn't natively support multi-threading so is only using one core, which can cause load issues. I could be remembering wrong though.

[Moon Wizard]

Multi-threading is used when possible; but certain actions have to occur on the main thread (such as script engine interactions (which includes database changes), texture creation, and some others).

Regards,
JPG