darthlukan
October 24th, 2021, 19:05
Problem
FantasyGrounds.x86_64 fails to launch via "Launch Fantasy Grounds" button in
FantasyGroundsUpdater. Instead, the Updater continues to relaunch with no error message as to why it was unable to launch Fantasy Grounds.
Expected Behavior
Fantasy Grounds launches when clicking "Launch Fantasy Grounds" button in the Updater.
Actual Behavior
The updater will continue to "Loop": When clicking "Launch Fantasy Grounds" the updater screen will close and then return, ad nauseum. This behavior occurs after closing a successful launch of Fantasy Grounds using the workaround below and is subsequently repeatable 100% of the time.
Workaround
Execute the following:
$ rm -rf ~/.smiteworks
$ ./FGUWebInstall.bin
... [Accept License Agreement]
... [In Updater window, click "Launch Fantasy Grounds"]
... [Updater updates as expected, Fantasy Grounds launches]
System Specs
Distro: Fedora 34
Kernel: x86_64 Linux 5.14.9-200.fc34.x86_64
Shell: zsh 5.8
CPU: Intel Core i7-10850H @ 5.1GHz
GPU: Mesa Intel (R) UHD Graphics (CML GT2)
RAM: 31851MiB
Personal Note
Firstly, thank you for providing a Linux client for Fantasy Grounds via Unity! It is much appreciated and the workaround is only a minor inconvenience. Once FGU is up and running, it runs beautifully, so thank you very much!
As a former Game dev who has used Unity for production development, an issue I constantly ran into was unclean file descriptor closing in Unity 3D and games I wrote which relied on loading of local files for state retrieval experienced this same behavior until I hooked into the final stage of Unity's provided shutdown events, where I explicitly had to ensure that all buffers and file descriptors were actually closed prior to engine shutdown. This could also be an issue of FDs being properly closed, but startup routines hang up on reading the last modified timestamp (or use last modified timestamps in some other logic). Either way, if someone points me to a repo with the Linux-specific code for Fantasy Grounds, I don't mind trying to track down root cause of this issue myself in the hopes of submitting a patch to potentially fix it.
FantasyGrounds.x86_64 fails to launch via "Launch Fantasy Grounds" button in
FantasyGroundsUpdater. Instead, the Updater continues to relaunch with no error message as to why it was unable to launch Fantasy Grounds.
Expected Behavior
Fantasy Grounds launches when clicking "Launch Fantasy Grounds" button in the Updater.
Actual Behavior
The updater will continue to "Loop": When clicking "Launch Fantasy Grounds" the updater screen will close and then return, ad nauseum. This behavior occurs after closing a successful launch of Fantasy Grounds using the workaround below and is subsequently repeatable 100% of the time.
Workaround
Execute the following:
$ rm -rf ~/.smiteworks
$ ./FGUWebInstall.bin
... [Accept License Agreement]
... [In Updater window, click "Launch Fantasy Grounds"]
... [Updater updates as expected, Fantasy Grounds launches]
System Specs
Distro: Fedora 34
Kernel: x86_64 Linux 5.14.9-200.fc34.x86_64
Shell: zsh 5.8
CPU: Intel Core i7-10850H @ 5.1GHz
GPU: Mesa Intel (R) UHD Graphics (CML GT2)
RAM: 31851MiB
Personal Note
Firstly, thank you for providing a Linux client for Fantasy Grounds via Unity! It is much appreciated and the workaround is only a minor inconvenience. Once FGU is up and running, it runs beautifully, so thank you very much!
As a former Game dev who has used Unity for production development, an issue I constantly ran into was unclean file descriptor closing in Unity 3D and games I wrote which relied on loading of local files for state retrieval experienced this same behavior until I hooked into the final stage of Unity's provided shutdown events, where I explicitly had to ensure that all buffers and file descriptors were actually closed prior to engine shutdown. This could also be an issue of FDs being properly closed, but startup routines hang up on reading the last modified timestamp (or use last modified timestamps in some other logic). Either way, if someone points me to a repo with the Linux-specific code for Fantasy Grounds, I don't mind trying to track down root cause of this issue myself in the hopes of submitting a patch to potentially fix it.