CPU multi-threading planned

[bmos]

I propose a solution to help those people who assume the software has locked up if they can't see a little progress bar or whatever.

Do what Discord does. Have some random messages pop up:

Acquiring parchment
Taming dragons
Getting Xanathars stamp of approval

Etc. On the loading screen.

Classic has this!!
I asked if it was planned to come to Unity and never got a reply.
It's even better because it teaches you FG, a couple tips at a time.
https://www.fantasygrounds.com/forum...orial-Messages

[Jiminimonka]

Thats all it needs until the code is optimised - which is obviously the devs know and are working on. As well as adding features and expanding way beyond what FGC was able to do.

I play twice a week with 7 people connecting to my table and I've never had one of them complaining or thinking it crashed. Some of them are under 25 years old and some of them old like me and even older.

[bmos]

Thats all it needs until the code is optimised - which is obviously the devs know and are working on. As well as adding features and expanding way beyond what FGC was able to do.

I play twice a week with 7 people connecting to my table and I've never had one of them complaining or thinking it crashed. Some of them are under 25 years old and some of them old like me and even older.

Want to trade players?
I kid, but mine definitely have been confused many times by hangs and load times. Impatience with tech is a very common pattern I see (I run an IT support company).

[Jiminimonka]

Want to trade players?
I kid, but mine definitely have been confused many times by hangs and load times. Impatience with tech is a very common pattern I see (I run an IT support company).

Oh I feel for you... Q: "my computer isn't working" A: "have you plugged it in?"....

[Weissrolf]

Impatience with tech is a very common pattern I see (I run an IT support company).

I am mostly guilty of impatient with software not making use of expensive hardware and modern design paradigms. We are still in the digital stone-ages on many fronts.

I do IT support and driver development testing and application vs. drivers vs. hardware testing, I know all the big and little pitfalls. I know end-users and I know developers (and support in between), both of which often don't interconnect. But for commercial software I am willing to give more slack to end-users, because they are the ones paying the bills. Community developers develop for themselves and the betterment of the community, once you ask for money you take up responsibility for working with end-users, for better or worse.

When a developer states something like "we have done it this way for over 10 years" as a rationale for not consider change then I know not to spend more energy into giving feedback to their product.

My players do not seem to be enticed to shell out money on FGU for the time being, though, especially with me using an Ultimate license (FGC + FGU) and buying all the modules. So they have to live with what they get and be happy about FG still being better than many other products. They are not customers and as such not entitled to request improvements. When improvements happen, they happen, when not then maybe something else comes along in the long run, they won't lose money anyway.

[Jiminimonka]

FG is better than any other VTT product out there.

The way its made extendible also is a feature. If you want change something you can make an extension to change things. If there is a big demand for an extension eventually it gets added (look thru the extension threads and see how many are deprecated because they are part of core functionality now).

Opinions of course are like, opinions.

[Kelrugem]

When a developer states something like "we have done it this way for over 10 years" as a rationale for not consider change then I know not to spend more energy into giving feedback to their product.

I think I know to which thread you refer, but then I have to say that this was not the argument A developer had good reasons for something and just said that this concept and these reasons did not change in the last 10 years That is something different, the 10 years served as emphasis. So, the reasons where the rationale, not the time how long FG handles something

[Weissrolf]

You also need to remember that Unity API is not Thread-safe, so all calls to Unity API should be done from the main Thread.

Ouch. Does FGU do rather many or rather few Unity API calls?

[Moon Wizard]

All UI display must go through main thread in order to be displayed in Unity; which is what allows full cross-platform builds.

Regards,
JPG

[Weissrolf]

So could you use the main thread for UI output and other threads (or one combined 2nd thread) for everything not directly connected to UI output?

You already use a second thread for "LOAD PART 1" anyway, so please try to keep the main UI thread alive to display some kind of progress instead of having it lock up. Also consider doing "LOAD PART 2" on its own thread while the main UI thread remains animated.

When players load/unload a module, consider doing the loading in its own thread and keep the main UI thread alive/responsive.

We users also keep wondering if ionger load-times are because of missing optimizations or because of Unity (bloat)? Or rather, can we even hope for more optimizations or is this it with Unity/FGU? Loading the very same PF2 CRB module takes 1-2s in FGC, but 6-7s in FGU (+UI freezes).