[MacOS] Cannot create_host() (error 20) or join_host() (error 25) on macOS

[cortrano]

Tested both on macOS and windows. On Widows everything works well with same code

[143mailliw]

Can confirm - this error happens on my Mac too (macOS 14 on M1 Pro)

[scriptsengineer]

These error combinations confirm that steam sockets is null. I don't use Mac, but perhaps I should confirm that Steam is initializing correctly before calling these functions. I'll check if we have a similar problem on godotsteam.

[143mailliw]

These error combinations confirm that steam sockets is null. I don't use Mac, but perhaps I should confirm that Steam is initializing correctly before calling these functions. I'll check if we have a similar problem on godotsteam.

FWIW GodotSteam picks up user personas and lobbies perfectly fine.

[ntngamedev]

The bug happens in Macbook M2 Pro also.

[dev-bre]

This is still happening. Is there any way to fix the MacOS build?

[brogan89]

This is still happening. Is there any way to fix the MacOS build?

Currently, no. It seems to be an issue with ENet and not this repo. If you just using only using gdscript, then you out of luck for now I'm afraid.

In C# there are more options:
Even the vanilla Enet in C# doesn't work on macOS. The only way I got my networking working on windows, macOS, and Linux is using LiteNetLib. Raknet will probably work as well, I haven't tested that yet because LiteNetLib unblocked me. You just need to roll out your own networking stack and not use any Godot networking features.

Even Steamworks.Net doesn't work on macOS, its a damn shame, but it is what it is. I don't have enough C++ knowledge to try fix it :(

[scriptsengineer]

Update 0.2.0 change steam api to steam flat api trying to solve this problem.

[D4r3NPo]

It still doesn't work on my mac : same error.
(And also by default when I download the add-on the framework files are not in the right folder so they cannot be detected )

[SueHeir]

I am also getting a Cannot host... 2 error after fixing the framework files folder locations

[scriptsengineer]

@SueHeir Just to clarify, before the update you said it worked normally, do you mention about the bug #33 or host folders?

[SueHeir]

sorry before I updated windows worked normally, mac os gave error 2 before updating, and after updating

[Lucas-gronlund]

Can also confirm that the issue persists after the update, let me know if I can help you debug on MacOS @scriptsengineer
The same code running on Windows works flawlessly

[scriptsengineer]

@Lucas-gronlund I would appreciate it if you would like to try to debug it, I don't have a Mac and that prevents me from checking what is happening here.

[jordanmichaelrushing]

I'm happy to help test on a Mac. What do you need me to do?

[jordanmichaelrushing]

@scriptsengineer do you want to hop on a Zoom and figure this out together? I'd love to figure this out as it would help speed up my development and not need to push to my Steamdeck to test out Steam connections
CC @Lucas-gronlund as well.

[scriptsengineer]

@jordanmichaelrushing Thank you for your attention, but I am currently very busy with external work, and I also don't have a Mac (which is why the bug is still open)

[garbagemule]

I came across this issue a couple of days ago, as I've also run into the same issue, on an M4-based MacBook Pro, an Intel-based MacBook Pro, and an Intel-based Hackintosh. I managed to build the plugin and tinker a bit with some of the surface-level code to see that my build was actually "working", but I'm new and/or rusty with everything involved, so I don't know where to go from here. I can confirm that the SteamNetworkingSockets() function returns null, and so does the SteamMatchmaking() function that GodotSteam uses, although it doesn't do so in GodotSteam.

@scriptsengineer is there anything I can do to help move the issue along? I could try out experimental builds and provide you with logs or such, or like @jordanmichaelrushing suggests, we could hop on a screen sharing session if you have time (I might be able to flex around your busy schedule), and you could try to debug stuff through one of my setups?

[scriptsengineer]

@garbagemule It seems very useful to me to try to see the differences between godotsteam, confirming that in godot steam the sockets work on mac?

[garbagemule]

@scriptsengineer Yes, that's my observation at least - kind of.

The SteamMatchmaking() function returns a non-null value in the pre-compiled GodotSteam with MultiplayerPeer when I call the create_lobby() function, but for some reason that same function returns null in steam-multiplayer-peer. I tried calling the function before this line and returning a different Error value if it returned null to confirm that my modification took effect. In both cases, the only bootstrapping prior to peer.create_lobby()/peer.create_host() is Steam.steamInit(false, 480) and hooking up to a few signals.

I'm making a huge assumption here that SteamMatchmaking() and SteamNetworkingSockets() both return non-null if things are working as they should, but I haven't checked if SteamNetworkingSockets() returns null in GodotSteam. I'll see if I can get it to build some time this week and check it out.

What's odd to me is how it works perfectly fine on Windows. Could it be some sort of linking/library issue on the macOS builds?

[garbagemule]

@scriptsengineer After a bit of faffing around, I managed to compile GodotSteam with MultiplayerPeer, and I inserted a call to SteamNetworkingSockets() right in the create_lobby() function, and it comes back non-null, so it looks like even the sockets are working as expected in GodotSteam. I'm not sure where to go from here, as the only thing I can really conclude from this is that the sockets work in GodotSteam with MultiplayerPeer, whereas they are null in this plugin. Open to suggestions and experiments :-)

[scriptsengineer]

@garbagemule
This is news to me, there really must be something that godotsteam must be doing differently to work on mac, maybe at startup? Or some lib that needs to be added along?

[TristanLMartin]

Finally found this thread and realized it's causing my issues as well. Does this mean that if we export our projects they will also not run for Macs?

@garbagemule is there anything that we can do to help you debug this? I would love and try and get this figured out

[garbagemule]

@scriptsengineer I'm not sure if anything needs to be done to "initialize" the Steam SDK, but I'm guessing as long as the binaries are properly linked/available, the functions in the header files should "just work". Do you know if there's a way to confirm that the build process works as intended and that the correct libraries and binaries are being used? I've already forgotten most of the stuff I had to do to get stuff working, but I recall having to rename some binaries for the build script to pick them up. I'm not sure if I used the right ones, though. I'm also not sure if the signing process is necessary for anything other than pacifying GateKeeper (my builds were very dangerous according to macOS 😁), but I skipped that part.

@TristanLMartin That's correct. We currently can't build projects that will run on macOS using this plugin. At this point in time, I think the biggest issue is that there is a huge knowledge gap between "people on macOS" and "people with Godot/Steam/C++ know-how", as well as a "hardware gap", if you will. I don't know enough about GodotSteam, the SteamSDK, and the building/linking process to effectively troubleshoot the problem, and @scriptsengineer doesn't have the necessary hardware to run experiments on. With our powers combined, we could probably figure something out, but it would be a long and arduous effort. An asynchronous workflow is definitely way too slow here. Maybe our best bet is to "recruit" one of the macOS-savvy folks over at the GodotSteam project and ask them to take a look?

[scriptsengineer]

@garbagemule @TristanLMartin
It's a good idea, we know that it's the only gdextension solution for Steam, I don't want to leave it abandoned for MacOS, although I have no way to debug/test it, I can still help with my knowledge of Steam/Godot. I believe that the Godot community is large enough to have someone who knows what happens when Steam doesn't start correctly on MacOS with gdextension.

Possibilities already raised:

• Steam Sockets not working on MacOS (there was a conversation like that on the Godotsteam discord, if you can find the link here)
• Here, gdextension is using some configuration/missing some file that Godotsteam has
• Some response or connection is being made incorrectly with Steam. In the case of Godot Steam, we have to create a lobby beforehand (maybe that influences it?)

[TristanLMartin]

And are we confident that it's not also an issue on Linux? It seems so strange that it would be a MacOS only issue

[scriptsengineer]

Updated for version 0.2.3 I hope that someone who has a mac will test for myself, Nessa versão updatei a geração de arquivos do mac para não ter assinatura, because in another lib (Inventory system) this problem was reported and then this update all returned to working normally on the mac.

https://github.com/expressobits/steam-multiplayer-peer/releases/tag/addon-0.2.3

[TristanLMartin]

Just did a quick test and same issue so far, would love to see if @garbagemule has the same issue, I will try and test it a bit more tomorrow and see if it is having an issue in the same place or something different

[aidewn]

So far, this problem still exists.

[garbagemule]

No luck with 0.2.4 for me either 🙁

I just took another nose dive into the various code bases (GodotSteam with the MultiplayerPeer module and steam-multiplayer-peer), but unfortunately I don't have anything significant to report back with. My goal going in was to try to figure out A) if there is any sort of runtime setup/linking going on, and B) if there are discrepancies in the build configuration.

Feel free to skip the fenced section of my ramblings 😛

---

First, runtime setup/linking. I think I'd need a much better understanding of "how stuff loads" in Godot to be able to really dig more into things. It looks like the primary "hook" is the register_types.{h,cpp} files, and I don't see anything particularly relevant in those. I did notice that the GodotSteam MultiplayerPeer makes a call to SteamUser() in its constructor in order to then grab the user's steam ID, so I tried replicating that in the steam-multiplayer-peer C++ code, but even that function returns null. Conversely, if I simply call Steam.getSteamID() from my gdscript, that works perfectly fine. Then I dug into what steam-multiplayer-peer does when we call create_host(), and I tried to replicate some of that in gdscript. Here, too, the functions Steam.initRelayNetworkAccess() and Steam.createListenSocketP2P() work as expected from gdscript, but not in the steam-multiplayer-peer C++ code. In other words, the GodotSteam GDExtension itself appears to be properly linked with the Steam SDK, so combined with the fact that steam-multiplayer-peer works on Windows, I'm 99% certain this is a matter of linking or interfacing with the Steam SDK rather than anything "wrong" in the C++ code.

This was a good segue to the build configurations. It looks like the MultiplayerPeer module in GodotSteam just kind of "inherits" the Steam SDK setup from the GodotSteam module itself. It uses an SCsub file rather than an SConstruct file, which I'm assuming just means it's a sub-module of sorts. It just seems to add a couple of .cpp files to the build configuration (ref), which I assume isn't significant. The GodotSteam module itself also has an SCsub file, and it adds steam_api to the LIBS environment variable (ref), which I also assume is insignificant, because if steam-multiplayer-peer didn't have access to the Steam SDK at build time, it would throw errors. I'm only mentioning it to be transparent about how clueless I am, so perhaps someone more experienced can help send me on a more constructive path 😅

The GodotSteam GDExtension and steam-multiplayer-peer have similar SConstruct files, but the former uses a nested folder structure for the compiled binaries (ref). I tried replicating that in steam-multiplayer-peer, but it didn't help (assuming I did it right). One thing I noticed was a discrepancy between the gdextension and gdextension-plugin branches. The .gdextension files differ quite a bit (ref and ref), and at first I thought maybe the bug was actually in GodotSteam GDExtension, but it looks like it's the latter version we have in the asset library, and the fact that the Steam SDK functions work at runtime with the Steam class also disproves it.

---

At this point I feel like I know just a little bit more, but it's not enough to make any headway, and I still feel like I'm stuck at square one. My usual approach in a situation like this is to cut away as much complexity as possible and try to create a minimal working setup and build from there.

In this case, I think it would be a Godot extension that uses the Steam SDK to get a user's steam ID and nothing else. If I can make that work, I think I've successfully interfaced with Steam, and perhaps I'd know enough to try to properly debug steam-multiplayer-peer. But I've never made a Godot extension, I've never worked with the Steam SDK, and I'm not particularly fond of or savvy at C++, so a minimal project like this is a pretty big undertaking in and of itself.

@scriptsengineer would this be something you'd be able to make? As long as it's super small (as little code as possible) and works on Windows and/or Linux, I would perhaps be able to work from there. It's just the whole starting up an extension and writing the C++ that's jarring to me 😁

[garbagemule]

Alright, I ended up actually trying to make an extension myself. Turns out the Godot documentation is pretty darn good, so I had the tutorial C++ GDExtension project up and running pretty quickly. I don't know that I've found any root causes, but I have made some headway!

After getting the tutorial extension running in a brand new project as per the instructions, I decided to try taking a stab at the Steam SDK. I set things up much like how it's done in steam-multiplayer-peer and the GodotSteam GDExtension, but I stripped the SConstruct file as much as I could to try to keep things minimal. I modified the tutorial extension to include a simple function that initializes Steam and returns the Steam user's ID, and it worked!

Then I added the GodotSteam GDExtension 4.4 from AssetLib, and everything still worked. But then I added Steam.steamInit(480) right before calling the new function, and that broke the Steam API. I tried removing the initialization in the tutorial extension to see if that would help, but to no avail.

I have documented the process and the sample project here: https://github.com/garbagemule/tutorial-gdextension-with-steam

I'm no longer convinced that it's purely a matter of library linking (the tutorial extension works as long as the GodotSteam GDExtension is not invoked), but perhaps instead some sort of conflict between two "components" trying to work with the Steam API at the same time. I'm assuming there is no such conflict on Windows, since it all seems to work fine there, but if someone can modify my project to also support Windows, perhaps we have a fairly "complete" minimal sample project to pass over to someone with more knowledge of the Steam API and/or macOS?

[TristanLMartin]

I thought the issue occurs when instantiating the SteamMultiplayerPeer, not when calling SteamInit or even creating a steam lobby, those seem to work for me with the GDExtension. It seems strange that an issue is happening for you when calling Steam.steamInit

For me I'm able to successfully call SteamInit, create a lobby, and then it returns an error for can't create when calling SteamMultiplayerPeer.new()