Open belthesar opened 1 year ago
Yeah, I currently do not own certificates for Windows or macOS - but it is still possible to run the game on macOS by right-clicking the application and clicking "Open" (this may need to be done twice the first time around, and it should be possible even with the quarantine flag). Let me know if this works for you!
Unfortunately the Problem remains, even when removing the flag and adding an exception, as far as I can tell. The error changes to "Tabletop Club quit unexpectedly", but the Report I get is identical to that posted by OP.
If I find the time I'll compile the Godot fork and try to take a look what the issue might be.
Darn. Yeah, any help with getting the standalone macOS build working on other machines would be appreciated :+1: For those on macOS I recommend playing the game through the Itch app for the time being until this is fixed.
I have a mid 2014 Macbook pro with Big Sur. It opens and runs fine when you right-click and choose open. I would assume this problem only occurs with newer apple products then.
It fails to launch on M1/M2 based Macs because the application binary is universal (x86_64 and arm64) but the bundled libwebrtc_native.osx.release.64.dylib
library is x86_64 only.
You can force it to run under Rosetta, by selecting the app icon in the Finder, pressing Cmd-I to open the inspector and then checking the "Open using Rosetta" checkbox. After that it will run properly.
Such a cool project! Thanks for making it :)
It fails to launch on M1/M2 based Macs because the application binary is universal (x86_64 and arm64) but the bundled
libwebrtc_native.osx.release.64.dylib
library is x86_64 only.
Ahh, that explains why the game works on older systems, but not newer ones!
Looking at the official webrtc-native
library, it does look like there is an arm64 version of the library, but it is in a separate file:
[gd_resource type="GDNativeLibrary" format=2]
[resource]
singleton = true
reloadable = false
entry/OSX.64 = "res://webrtc/lib/libwebrtc_native.osx.release.64.dylib"
entry/OSX.arm64 = "res://webrtc/lib/libwebrtc_native.osx.release.arm64.dylib"
Since the main binary is universal, here's my initial solutions from nicest to not nicest:
I'll do some research on how to solve this in the near future, I can't be the only one who's had this problem surely?
I believe the command line tool lipo
can combine two separate x86_64 and arm64 binaries into one universal one. Something like this should work: lipo foo_intel.dylib foo_arm.dylib -output foo_universal.dylib -create
I've been tinkering with this today - I initially attempted to merge the two dynamic libraries together, but failed when I realised there is no second library 🤦 Even though the .tres
file references an arm64 library, only the x86_64 one exists: libwebrtc_native.osx.release.64.dylib
.
So I attempted to build it from source on my MacBook, and lo and behold, I can't get it to even compile for x86_64, let alone arm64 😭 There's several issues with building the original WebRTC library in the same branch that the rest of the platforms use.
However, that's all for version 0.5 of the library (the current stable version) - at the time of writing, there is a v1.0.0-rc1 release that includes both x86_64 and arm64 libraries for both Godot 4 and 3. I was planning to use it for v0.2.0 of the game since it will use Godot 3.5.2, but I may attempt to use it for v0.1.x to get this error fixed, even if it says Godot 3.4.x is not officially supported.
Will keep you all updated on this 👍 I'm really hoping I can get the game working on ARM sooner rather than later...
No such luck with the v1.0.0-rc1 build... the library loads fine on macOS (after correcting a spelling error), and it sends offers, answers and candidates to my Linux machine, but it just... doesn't establish the connection:
Joining game with room code IVDG...
Connecting to master server at 'wss://tabletop-club.duckdns.org:9080' with room code 'IVDG'...
Connected to the room as peer 236816019.
Peer 1 has connected.
Creating a connection for peer 1...
Joined room IVDG.
Received offer from peer 1.
Created answer for peer 1.
Received candidate from peer 1.
Received candidate from peer 1.
Received candidate from peer 1.
Unless someone can find a fix for this, I'm not sure if I am able to include an arm64 version of the WebRTC library until the game uses Godot 3.5 (which will be in v0.2.0) - until then, it looks like you can run the x86_64 version via Rosetta.
Thanks for all of the information. Looking forward to v0.2.0!
How do you do, fellow macOS users? :grin:
I've been working on the new multiplayer back-end for v0.2.0, using an updated version of the WebRTC library that includes the arm64
architecture for M1 and M2 processors.
I wanted to confirm that using the newer library actually works, so I've made a very, very, very alpha build of the update so far based on the latest commit of the 0.2-rewrite
branch, 11608b3534de5005e4183daaa156abcaea6f2ecb.
I've confirmed that it works on Intel, but I need help confirming if, on ARM, you guys are able to do the following:
NOTE: The in-game UI is very lacking at the moment, so you will probably need to run the build via the terminal, or at the very least, get the terminal output, to confirm that the networking is working as expected.
Any help with testing this is greatly appreciated! If you've got any questions, don't hesitate to ask.
Download (100MB): https://drive.google.com/file/d/1hP-5QspoP7_YKFGb9RTi1mz5kWn-aU9V/view?usp=sharing
SHA512: 18f8532e41dac587d73cde31729187bcff29075bb815a868c49a53bf673d6942876fd57a26282157205835d9a62acf2b67e3a81e669b1bf65f0b53d818bf6708
Describe the bug When launching the macOS build of Tabletop Club, the application fails to start and throws an exception.
To Reproduce Steps to reproduce the behavior:
xattr -c /path/to/release.zip
to clear the quarantine flag (without doing this, launching the extracted bundle reports that application is broken.)Expected behavior The application launches!
Screenshots n/a
Environment macOS Ventura 13.3.1 on MacBook Pro 18,3 (Apple Silicon, M1 Pro, 10 Core, 14 Core GPU)
Version v0.1.0
Additional context It appears the macOS build is failing Code Signature enforcement. This may be because the build is not made with an active Apple Developer account. When launching the application, the following exception is thrown: